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

[Cullen Jennings <[e-mail]>]

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.


On Apr 1, 2008, at 2:04 PM, Mary Barnes wrote:
> 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:[e-mail]]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv