>
> 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
