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
