> -----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
>
> Martin Thomson wrote:
> >
> > Looking more at the server authentication problem, my biggest
> > concern is with the difficulty in implementing the RFC 3958 mandated
> > authentication method.
> >
> > I've done a little research on a few of the more common HTTP client
> > modules, of the sort that would likely be used to implement HELD.
> >
> > The question is how difficult it is to make an HTTP over TLS request
> > where the domain name used to authenticated the server does not match
> > the domain name in the URL.
> >
> > Java HttpUrlConnection - It seems that it's relatively easy.
> > Java Jakarta HTTP Client - Seems possible using the methods from
> above,
> > with a little more work.
> > VB/C# .Net HttpWebRequest - Doesn't appear to be possible. Socket
> > access is possible, but seems to require implementing, ground up.
>
> It looks like the ICertificatePolicy interface would allow doing this
> (but haven't tried it).
>
> > C/C++ libcurl - Seems possible if OpenSSL is used; it's difficult to
> > say how hard this would be without investigating in more detail.
> > PHP - Doesn't appear to be possible. Uses libcurl, but doesn't
> expose
> > the necessary API.
> > Wget - Not possible.
> > Ruby Net::HTTP - Doesn't appear to be possible.
> > Python httplib - Doesn't appear to be possible.
>
> Python httplib/urllib2 don't appear to check the certificate
> at all, so it's very easy :-)
>
> > Javascript XmlHTTPRequest - Not possible.
> > Objective C NSURLConnection - Doesn't appear to be possible.
> > Perl libwww - Doesn't appear to be possible.
> >
> > I conclude that unless you intend to implement in Java, there's a lot
> > of code to write. Most APIs abstract this away.
> >
> > Making it hard to implement discourages people from even trying.
> Then,
> > someone who does all the hard work cannot benefit from reusing
> > thoroughly debugged code.
>
> 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
