Subject: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 1 Feb 2009 19:09:49 -0600

> You could stash an identifier in the cert,
> but	
> I'm guessing that isn't interesting.

I think that this demonstrates a key misunderstanding.  If a requester uses crypto (PKI or whatever) to demonstrate that they are "X", and "X" is what the LIS uses to determine location, this is an LCP.

It doesn't take a logician to recognize that the question:
  I am "X", where is "X"?
...is the same as "Where am I?".

Bernard pointed out cases where you don't validate that "X" == source IP.  In these cases, the "X" is a MAC address, which can be cryptographically authenticated.

This is the case that I propose is retained.  I don't intend to provide reams of text, but also see no strong reason not to--in general--prevent this.

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Saturday, 31 January 2009 7:52 AM
> To: 'Stark, Barbara'; 'Marc Linsner'; Thomson, Martin; [email-masked]
> Subject: RE: [Geopriv] Security considerations for draft-winterbottom-
> geopriv-held-identity-extensions
> 
> I also agree with Marc
> 
> Confining the discussion to just the LCP case:
> 
> Identity of the requester is not particularly interesting.  If I
> deployed
> PKI for example, I could tell that Martin Thomson was asking for his
> location, but that doesn’t tell me what identifier I use to map to his
> location.  Just because I know  it’s Martin asking doesn’t mean, for an
> LCP,
> that I trust any identifier he happens to give me, other than the IP
> address
> that I got from his packet.  You could stash an identifier in the cert,
> but	
> I'm guessing that isn't interesting.
> 
> All I get to use to derive the identifier is what is delivered in the
> request.  For an L7 LCP, that is, precisely, the IP address.  If the
> LIS was
> on the same L2 as the requester, then you might have another
> identifier.
> 
> Bernard supposes that there are cases where the LIS can’t lookup the
> identifier actually associated with location using the IP address.  I
> claim
> that since you must validate the identifier you use against the IP
> address,
> that the only circumstance where sending the identifier makes any sense
> is
> if the lookup from identifier to IP address is one way.  I find that
> pretty
> hard to fathom.  Even in an enterprise, you would use the DHCP server
> to go
> from IP address to mac address, and then use mac address to switch
> port.  I
> think you HAVE to do that, you can’t just have the LCP client send MAC
> address at L7.  You MUST verify that the client’s IP address matches
> the MAC
> address he sent you.  If you can verify, you can do the lookups from
> the IP
> address without using the identity extension.
> 
> Again, all of this is LCP only.  With third party, we have trust
> arrangements that work without this backchecking.
> 
> Brian
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Stark, Barbara
> Sent: Friday, January 30, 2009 2:12 PM
> To: Marc Linsner; Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Security considerations for
> draft-winterbottom-geopriv-held-identity-extensions
> 
> I tend to agree with Marc on this.
> In the generic case, for any identity that a LIS is able to provide
> location
> for, you would want to have a privacy policy. That policy would state
> who is
> authorized to request location (and maybe some can only request city
> while
> others get exact). In creating this policy, it would make sense in most
> cases (but not all) to include the authentication information
> (certificate,
> shared secret, whatever) of the Target as an entity that can request
> location. But in doing it this way, the Target looks just like any
> other
> party requesting location.
> 
> An entity requesting location info provides authentication info which
> is
> matched up against privacy policy of whatever they’re asking location
> for.
> Whether that authenticated identity belongs to the target itself or
> someone
> else isn’t relevant, because what they can get access to is defined by
> the
> authorizations associated with the authenticated ID within the policy.
> There
> is no need to further associate authentication info as somehow
> belonging to
> the same device whose location is being requested. That provides no
> additional info. Either the authenticated ID is authorized or it isn’t.
> Barbara
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Marc Linsner
> Sent: Friday, January 30, 2009 1:39 PM
> To: Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Security considerations for
> draft-winterbottom-geopriv-held-identity-extensions
> 
> Martin,
> 
> I don’t understand the role of PKI in the LCP use case.  The LIS
> doesn’t
> know John Doe.  The LIS doesn’t care that John Doe owns mac address
> x.y.z.
>   The LIS cares that IP address a.b.c. belongs to mac address x.y.z.
>  Any
> other usage is not LCP, it’s third party which falls under the policy
> set by
> the rulemaker.
> 
> -Marc-
> 
> 
> 
> 
> On 1/29/09 7:49 PM, "Thomson, Martin" <[email-masked]>
> wrote:
> Hi Marc,
> 
> Did you miss the bit where I mentioned that validation doesn’t
> necessarily
> involve checking that: owner-of-IP == owner-of-alternative?  If the
> requester can prove that they own the identifier (I hear that PKI helps
> here), then the validation consists of a certificate check.
> 
> Cheers,
> Martin
> 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of Marc Linsner
> Sent: Friday, 30 January 2009 11:44 AM
> To: Bernard Aboba; [email-masked]
> Subject: Re: [Geopriv] Security considerations for
> draft-winterbottom-geopriv-held-identity-extensions
> 
> OK, I’ll retract the idea that all requests with identity extensions be
> treated as third party, but only while you read the next paragraph.
> 
> I’m not arguing about the usefulness of alternate identifiers in the
> pursuit
> of location determination.  I’m simply stating that since an alternate
> identifier supplied by a LCP requestor MUST be validated prior to
> releasing
> location information to such requestor, having that requestor supply
> such
> alternate identifier is a useless step. The LIS can simply discover the
> alternate identifier via the same mechanism used by the proposed
> identifier
> extension validation process.  This enables the requestor to utilize
> the LCP
> mechanism described in draft-ietf-geopriv-http-location-delivery-12.txt
> without having to play the guessing game called ‘alternate
> identifiers’.
> 
> Hence, having a requestor supply the identity extension in the pursuit
> of
> the LCP request is not necessary and should not be supported.
>  Therefore, if
> a request is submitted with an identity extension embedded, it must be
> a
> third party request.  Now, I’m back to my assertion that all requests
> containing identity extension MUST be considered a third party request.
> 
> -Marc-
> 
> 
> On 1/29/09 6:43 PM, "Bernard Aboba" <[email-masked]> wrote:
> 
> The issue is that in many access networks, IP address assignment is
> handled
> separately from network access authentication.  As a result, a LIS may
> not
> keep track of location by IP address at all, but may be better prepared
> to
> return a location in response to an alternative identifier such as a
> MAC
> address or username.
> 
> 
> 
> For such systems, being forced to treat all alternate identies as
> "third
> party" would prevent support for location from being deployed at all.
>  This
> seems silly particularly if the location request is authenticated with
> an
> identity that maps easily to the username used for network access.
>   Such a
> scheme will both readily allow the differentiation of "first party" and
> "third party" requests as well as fitting very well with the majority
> of
> backend AAA systems deployed today, with a high level of security and
> location privacy.
> 
> 
> 
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, 30 January 2009 2:15 AM
> To: Bernard Aboba; Thomson, Martin; [email-masked]
> Subject: Re: [Geopriv] Security considerations for
> draft-winterbottom-geopriv-held-identity-extensions
> 
> 
> 
> Martin, Bernard,
> 
> I’m still perplexed about the verification process applied to determine
> whether the request is LCP or third party.  If in fact, the proposed
> verification process exonerates the request as LCP, what’s the point of
> identity extensions for LCP?  The LIS can simply gather the required
> extended identity information via the same process.  The draft states
> that
> if the verification check fails, the LCP request fails and it’s treated
> as
> third party.
> 
> I’m not convinced by:
> 
> “ Note:  This might seem to negate much of the advantage provided by
>       the inclusion of identity parameters for the LCP case.  However,
>       checking that the identity information is correct is generally
>       more feasible than acquiring the information in the first place”
> 
> Simply treating all requests with identity extensions as third party
> seems
> easier. Hence, a host requesting it’s own location doesn’t have to
> worry
> about identity extensions (ala less code), it’s up to the LIS to figure
> out
> what is needed and where to get it.
> 
> -Marc-
> 
> …
> 
> 
> 
> -----------------------------------------------------------------------
> -----
> --------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> -----------------------------------------------------------------------
> -----
> --------------------
> [mf2]
> ________________________________________
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> -----------------------------------------------------------------------
> -----
> --------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> -----------------------------------------------------------------------
> -----
> --------------------
> [mf2]
> ________________________________________
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 2 Feb 2009 10:15:07 -0500

The fallacy in your logic is that "I am Martin, where is mac address a2.12.11.22.11.2c?" is not the same as "where am I"?  I can validate that you are Martin, I cannot validate that Martin uses that mac address.  Perhaps I missed something, but I didn't see a case where you could cryptographically connect, say, a login ID or cert to a mac address where you couldn't connect it to an IP address.

Bernard's example was:
>On the other hand, if network access were authenticated (as it would be for 
>WiMAX, IEEE 802.11 and IEEE 802.1X wired), then there already exists a 
>mapping between User-Name and location (e.g. 
>NAS-Identifier/NAS-IP-Address/NAS-IPv6-Address)
>via RADIUS accounting.  This is widely deployed already, since almost 
>every shipping AAA server makes this information accessible in some form.
I believe that is login ID to IP address.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Sunday, February 01, 2009 8:10 PM
> To: Brian Rosen; Stark, Barbara; Marc Linsner; [email-masked]
> I think that this demonstrates a key misunderstanding.  If a requester
> uses crypto (PKI or whatever) to demonstrate that they are "X", and "X"
> is what the LIS uses to determine location, this is an LCP.
> 
> Bernard pointed out cases where you don't validate that "X" == source
> IP.  In these cases, the "X" is a MAC address, which can be
> cryptographically authenticated.
> 
> This is the case that I propose is retained.  I don't intend to provide
> reams of text, but also see no strong reason not to--in general--
> prevent this.
> 
> -------------------------
> -------------------------
> [mf2]