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.
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.
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.
--Martin
Caveats:
I'm not fluent in most of these languages and their API documentation. It's possible that I've missed something.
I didn't look at API support for X.509. Java and OpenSSL have decent APIs, others mostly don't expose these.
It appears that some implementations validate on subject CN rather than subjectAltName. I'm hoping that this was just the sample code.
> -----Original Message-----
> From: Thomson, Martin
> Sent: Friday, 19 February 2010 10:57 AM
> To: 'Pasi Eronen'; iesg@ietf.org
> Cc: geopriv@ietf.org
> Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
>
> I remember having this exact discussion with someone in the past, but I
> can't find reference to it in the WG archives or meeting minutes, so it
> may have been a hallway conversation.
>
> 3958 uses the _input_ to DDDS to validate the authenticated identity of
> the server, even if the server is at a different domain.
>
> LoST specifically states that the name in the _output_ of DDDS is used
> to validate server identity. This makes a lot of sense for LoST
> because an N-to-1 deployment arrangement is expected. But there's a
> problem with 3958 that isn't clear.
>
> The vagueness in Sec8 should be fixed, but the problem is thus - I can
> build a discovery element, then take the output of that and feed it to
> an HTTP stack. Normally, the only input the HTTP client takes is a
> URL. The server is authenticated against the domain name in the URL.
> While it is possible in some implementations to provide your own server
> authentication logic, very many implementations do not allow this.
> Given the current implementations of HELD clients, I am aware of maybe
> only one (a Java-based client) that could possibly authenticate based
> on a different name than what was in the URL.
>
> The 3958 choice was also going to place some cumbersome restrictions on
> those deploying a LIS into an ISP. Small businesses and home customers
> are expected to rely on ISP-provided location infrastructure. For the
> ISP, this could mean that adding new customers requires that they add
> new names to the subjectAltName of their LIS certificate. The
> alternative is that the customers report the name of the ISP in their
> DHCP options, which is probably easier, but less friendly to those
> people; in most cases depends on access to the new option.
>
> If the IESG believes that the 3958 approach is best, then I'm happy to
> accept that conclusion. I would prefer to retain the existing
> mechanism. It is my view that - while the choice made for 3958 is the
> "most secure" - it's the least practical.
>
> --Martin
>
> > -----Original Message-----
> > From: Pasi Eronen [mailto:pasi.eronen@nokia.com]
> > Sent: Thursday, 18 February 2010 9:46 PM
> > To: iesg@ietf.org
> > Cc: geopriv-chairs@tools.ietf.org; draft-ietf-geopriv-lis-
> > discovery@tools.ietf.org
> > Subject: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery
> >
> > Discuss:
> > I have reviewed draft-ietf-geopriv-lis-discovery-13, and have one
> > concern that I'd like to discuss before recommending approval of the
> > document:
> >
> > While relying on DHCP seems unavoidable here, normally HTTPS does not
> > rely on DNS to work securely. I'd like to see a better rationale for
> > ignoring important security advice from the NAPTR specifications
> (most
> > of Section 8 of RFC 3958). "More compatible with existing HTTP client
> > software" seems rather vague, especially considering we're talking
> > about new HELD client software, and not e.g. existing web browsers.
> >
> > LoST (RFC 5222) did use this approach, too, but only after concluding
> > that the approach recommended in RFC 3958 would not have worked well
> > in that particular context (where large number of inputs map to a
> > very small number of LoST servers, and the LoST server is not even
> > aware of all the possible inputs). Here the situation seems quite
> > different: the location server needs to be aware of the access
> networks
> > that have delegated to it (in order to properly determine the
> > location).
> >
> > Comment:
> > The regexp in Section 4 is wrong; "*." should be ".*"
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
