Geopriv folks,
With respect to Pasi's DISCUSS on discovery, I've discussed this with Richard and he suggested that I attempt to close this issue before the meeting.
I propose to alter the existing text on this section as below.
If, however, you feel that authenticating based on the AUS (the U-NAPTR input) as described in RFC 3958 is a better solution, don't refrain from letting the WG know this. Input either way would be greatly appreciated.
(After removing the DNSSEC note prior to this)
[...] Using the
domain name in the URI is more compatible with existing HTTP client
software, which authenticate servers based on the domain name in the
URI.
+ LIS authentication based on the domain name from the URI depends on
+ integrity protection of the DNS queries used in U-NAPTR resolution. DNS
+ security (DNSSEC) [RFC4033] provides some integrity protection for DNS
+ records. Alternatively, if authoritative servers and resolvers are
+ located within the access network, physical or link layer security might
+ be employed to protect against modification of DNS records.
This is consistent with the recommendations for DHCP, where we are relying on similar mechanisms.
--Martin
...
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
> > Sent: Thursday, 18 March 2010 4:42 AM
> > To: Thomson, Martin; iesg@ietf.org
> > Cc: geopriv@ietf.org
> > Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
...
> >
> > I agree that ease of implementation is an important concern.
> However,
> > for HELD one would think that security is also an important concern.
> > Unlike normal HTTPS, the current draft essentially assumes that DNS
> is
> > secure -- otherwise, the client cannot really authenticate the LIS.
> >
> > While DHCP is also relying on a "secure network" to some degree, the
> > draft does note that the input to U-NAPTR resolution could come from
> > other (possibly more secure) sources.
> >
> > The correct approach to NAPTR resolution and TLS certificates
> (compare
> > NAPTR input against the certificate) is also used in other places
> > (like draft-ietf-sip-domain-certs), so it's clearly not impossible to
> > implement either.
> >
> > I would hope this topic gets discussed in the GEOPRIV WG in Anaheim.
> >
> > If others agree that it's OK to assume a "secure network" (even
> > when DHCP is not used), then at the very least, the document needs
> > to much more clearly highlight this assumption (and the resulting
> > limited applicability).
> >
> > Best regards,
> > Pasi
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
