Subject: Re: [Geopriv] WGLC: draft-ietf-geopriv-http-location-delivery-05.txt - cullen comments

From: "Mary Barnes" <[email-masked]>
Date: Tue, 1 Apr 2008 16:04:29 -0500

Group and Cullen,

Are you all okay with the simplified text Richard has proposed for the
current section 10.1.1?  I believe it addresses the concerns raised by
Cullen and Hannes on the security section.  I would rather get the
feedback now and be able to ship the -06 than to receive feedback after
the -06 is out. 

Thanks,
Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, March 24, 2008 3:50 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Cullen Jennings; GEOPRIV
Subject: Re: WGLC: draft-ietf-geopriv-http-location-delivery-05.txt -
cullen comments

Cullen, Mary,

When I suggested the text for 10.1.1, para 3, I had momentarily
forgotten about RFC 2818 and the iPAddress subjectAltName.  We do need
slightly more than "Use RFC 2818", since RFC 2818 only applies to the
HTTP binding, and we also want to say that the same checks should be
available for other bindings.  I suggest that section 10.1.1 be
condensed to the following:

"
This document assumes that the LIS to be contacted is identified either
by an IP address or a domain name, as is the case for a LIS discovered
via [ID.ietf-geopriv-lis-discovery].  When the HELD transaction is
conducted using TLS [RFC2246], the LIS can authenticate its identity
(either as a domain name or as an IP address) to the client by
presenting a certificate containing that identifier as a subjectAltName
(i.e., as an iPAddress or dNSName, respectively).  (In the case of the
HTTP binding described above, this is exactly the authentication
described by [RFC2818])  Any binding of HELD MUST be capable of being
transacted over TLS so that the client can request the above
authentication, and a LIS implementation for a binding MUST include this
feature.  Note that in order for the presented certificate to be valid
at the client, the client must be able to validate the certificate; in
particular, the validation path of the certificate must end in one of
the client's trust anchors, even if that trust anchor is the LIS
certificate itself.
"

Good catch, Cullen, thanks.
--RB

> Section 10.1.1, 3rd para. I find all this pretty hand wavy to 
> understand how reverse DNS lookups to to find a host name then hope 
> the server certificate matches the hostname will actually achieve the 
> security goals. In scenarios that I have heard about  where people 
> don't want to use a DNS name for the LIS, it is because they want it 
> to work without DNS. I would think a better solution for LIS that 
> don't want to have a DNS name would be to say that if the LIS was 
> identified by a IP address and TLS was used, then the certificate 
> needed to have the servers IP address as one of the entries of type
ipAddress in the SubjectAltName.
> If we did this, servers with IP addresses would work petty much like 
> servers with DNS names and for the cases where the LIS was identified 
> with an IP address, and no DNS would be used.
> [MB]  This is a good point and I welcome feedback from others (Richard

> in particular, whom I've cc'ed) on this topic. We did not have the 
> reverse DNS lookups as part of the security solution until this 
> version, so this is all new text, with some new concepts. [/MB]

[RLB]
Cullen: Good point.  I had momentarily forgotten about RFC 2818 when I
suggested this mechanisms, and in fact, your suggestion is what's
actually in RFC 2818.  This part should just say "Use RFC 2818
mechanisms to authenticate that the LIS you're talking to corresponds to
the DNS name or IP address you used to contact it".
[/RLB]

> 
> Section 10.1.1, 3rd para, last sentence and last point in section
> 10.3: The IP Spoofing issues. This doc normatively references and 
> suggests domains SHOULD do the things in [5] and [9] (RFC 2827 and 
> 3704). This worried me because it is pretty clear that lots of 
> networks will not follow this advice and I started thinking about how 
> much worse does the security of LOST get if you don't do either of 
> these. I'm not actually convinced that it makes much difference. If an

> attacker can only spoof a source address but can't change the routing 
> such that the responses to that address come back to them, as the 
> document discuss, there is no big deal because a request is not routed

> to them. To be more specific, the attacker does not even manage to set
up a TCP connection.
> Now clearly 2827 is a general good idea but not sure it actually is 
> relevant to this document. I think it would be worth considering if 
> this makes sense or not and if this could just be removed.
> [MB] I'm slightly confused by your reference to LOST above, but see 
> your point about considering whether this concept is useful for HELD. 
> And, per the point above, would appreciate feedback from others as to 
> whether this should be removed. [/MB]

_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Apr 2008 18:58:30 -0700

Sorry was on vacation last week (or trying to be) and just read this.  
Richard's text for the IP Address issue looks good to me.