Subject: Re: [Geopriv] DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 2 Mar 2010 09:20:51 +0800

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.
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'; [email-masked]
> Cc: [email-masked]
> 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:[email-masked]]
> > Sent: Thursday, 18 February 2010 9:46 PM
> > To: [email-masked]
> > Cc: [email-masked]; draft-ietf-geopriv-lis-
> > [email-masked]
> > 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 ".*"

---

From: <[email-masked]>
Date: Wed, 17 Mar 2010 18:42:06 +0100

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

Python httplib/urllib2 don't appear to check the certificate 
at all, so it's very easy :-)

> 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

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 18 Mar 2010 07:25:13 +0800

I'll talk to the chairs and make sure that we get time to discuss this.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, 18 March 2010 4:42 AM
> To: Thomson, Martin; [email-masked]
> Cc: [email-masked]
> > Java Jakarta HTTP Client - Seems possible using the methods from
> above,
> > with a little more work.
> > PHP - Doesn't appear to be possible.  Uses libcurl, but doesn't
> expose
> > the necessary API.
> > Wget - Not possible.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 19 Mar 2010 08:23:34 +0800

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

...

> > Subject: RE: DISCUSS and COMMENT: draft-ietf-geopriv-lis-discovery

...

> > I agree that ease of implementation is an important concern.

> However,

> > Unlike normal HTTPS, the current draft essentially assumes that DNS

> is

> > The correct approach to NAPTR resolution and TLS certificates

> (compare

> _______________________________________________

> Geopriv mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/geopriv

---

From: <[email-masked]>
Date: Thu, 25 Mar 2010 17:53:30 +0100

Sean will be taking over my DISCUSS (and you'll have to continue the
discussion with him), but I would like to note that I would really
like to see better arguments than "it's simpler to implement with some
HTTP libraries" for ignoring this important security advice from RFC
3958. To me it looks like someone implementing HELD and this discovery
mechanism can pick one of the many libraries that does support this,
and this is not something that e.g. would have to work with all
currently deployed web browsers.

LoST had a quite reasonable description (RFC 5222, Section 18) why the
approach recommended in RFC 3958 would not actually work in the
deployment scenarios envisioned for LoST. But it seems the deployment
considerations would HELD would be quite different, and the same
argument does not apply here.

Best regards,
Pasi

> From: ext Thomson, Martin [mailto:[email-masked]] 
> Sent: 19 March, 2010 02:24
> To: [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: Domain name authentication in draft-ietf-geopriv-lis-discovery
> 
> 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.
>
> 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.
>
>
  >    
>+   located within the access network, physical or link layer security might
<+   be employed to protect against modification of DNS records. 

--Martin

...
...