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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 28 Jan 2009 21:19:59 -0600

This got munched by the list because it was too big.  I trimmed the responses.

From: Thomson, Martin 
Sent: Thursday, 29 January 2009 12:00 PM
To: 'Bernard Aboba'; [email-masked]
Subject: RE: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

I totally agree with all that you’ve said here.  I’m just not sure that this level of detail is warranted.  Let me see if I can abstract the process a little.

Step 1:  Determine who is asking (the requester).  Client authentication might have been used*, which will accomplish this.  Alternatively, if the requester is not authenticated in any way, we use the source IP address as their identity.

Step 2:  Determine who they are asking about (the target).   If there is no identity parameter, they are asking about themselves.

Step 3:  Make an authorization decision.  We assume a default rule that says that hosts are automatically authorized to request information for themselves**.  The policy that is applied might extend this to include a set of targets that a requester is authorized to request location for.

However, this doesn’t allow for the case where the requester is asking about their own location where the link isn’t immediately apparent.  It makes sense to check to see if they really are asking for their own location.  So check for a link between the requester identity and the target identity.

If a link can be established, then the requester becomes authorized under the default rule.  As you point out, there are range of options for establishing this link; however, I don’t see the value in attempting to enumerate these.  What would be helpful is making it clear that the link needs to be strong; any weakness in the method used to establish the linkage could be exploited.

The link MUST be unequivocal—the same identifier (or set thereof) cannot also potentially identify another requester.  For instance, if the IP is not unique within the given context, then it alone is not sufficient basis for establishing this link.

[[Note that within certain constrained contexts duplicate identifiers can be used successfully.  If a requester provides a MAC address that could also indicate another device, as long as the information provided to the requester pertains only to them, authorization by the default rule is still possible.  The concern only arises if the LIS is unable to adequately distinguish between the two potential targets based on the available identifiers.  Note also that the LIS can use other information, such as the ingress network interface to help here.]]

Would it help if the above were included in the draft?

I see no need for a distinction between infrastructure and personal equipment, except in the policy that is applied.  A fairly simple means of establishing this distinction is through the policy.  Some requesters might be authorized to request for certain target identities.  If the target identifiers were easily distinguished, maybe by OUI, then the policy could indicate this.

Cheers,

Martin

*It might be that there is an unstated assumption that the means of authentication is out of scope.  The use cases presented so far concentrate purely on pre-arrangement, which allows for advance negotiation of authentication methods and the like.  Based on these, I don’t see a strong need to provide a great deal more information on this mechanism.  On the contrary, I think that more experience might be necessary before we can go there.

** This isn’t entirely true.  The work on location hiding doesn’t assume that targets are completely authorized to retrieve their own location.  Nonetheless, it still retains a watered-down version of this basic rule.

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, 29 January 2009 10:36 AM
To: Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

Martin Thomson said:

"What if the LIS asked you to prove that you have a given IP address though a reachability test, then acquired proof by some other means that the identifier and IP address were coincident.  Would it be unreasonable to attribute a similar degree of surety to the identifier as the surety derived from the reachability test?  Of course it can only be weaker, but whether that additional step embodies an unbearable risk I’ll leave to the person whose neck is on the line. "

The LIS can obtain the IP address of the requester from the source address in the HELD request. 
The source IP address has implicitly passed a "return reachability" test, since a TCP 3-way handshake had to
be completed in order for a HELD request to be received by the LIS.  Given this, if a different
IP address is included in the HELD extension, then the LIS knows that this represents a "third party"
request.  

Knowing whether the IP address argument is "first party" or "third party" is useful, but that's
only a first step.  Unfortunately, confirming IP address reachability doesn't help to determine
the validity of other identifiers such as the MAC address, network access NAI, etc. 

If the LIS is not on the same LAN as the requester, the original source MAC address will have
been replaced by the MAC address of the router, so that the LIS won't have a way of 
determining whether the MAC address in the extended HELD request was also used as the
original source MAC address of the frame sent by the requester. 

"if the LIS could acquire the identifier itself so easily, there would scarcely be a point to the use case. "

The issue is really whether the identifier represents Personally Identifiable Information (PII) or not,
and whether the LIS can determine whether the requester is authorized to obtain the location
of the device associated with that PII.   

The MAC address case is perhaps the most tricky, since a MAC address could represent the
location of network infrastructure not associated with a person (e.g. the BSSID of a 
stationary AP installed and owned by the enterprise).  In such a case, one might argue that 
such a MAC address would not represent PII.  However, if the MAC address were associated 
with a mobile device owned by an employee and likely to be in close proximity to them, then
we might come to a different conclusion. 

In determining whether to answer a request made with a MAC address as a parameter, the
LIS could first attempt to determine whether a MAC address in a HELD extended request
was an infrastructure or personal address.   If it was determined to be an infrastructure
address, then different guidelines might apply.  

If the MAC address was determined to be person, then several approaches might be
used for the LIS to determine if the assertion was "third party" or "first party":

1.  In WiMAX or IEEE 802.1ar with IEEE 802.1X-REV, then the requester might have previously
presented a certificate which included the MAC address as a parameter, and the AAA server
may have been required to verify that the MAC address in use matched the one authorized
in the supplicant certificate.  In that case, the MAC address in the request could be mapped
to an NAI, and then it could be determined whether the authenticated identity utilized in the
HELD request was authorized to query information on that NAI, and if so, whether the
request was considered "first party" (e.g. the NAI and authenticated identity were closely
related) or "third party".  

2. By looking at existing  IP adress/MAC address bindings, such as those provided by 
MIB II, LLDP-MED notifications,  DHCP lease data, etc.   If the MAC address provided in 
the HELD request has a 1-1 binding  to the source IP address, this implies that the MAC 
address has been asserted by  the sender at the IP layer as well as in HELD.   

This isn't really an indication of "ownership" or "authorization" -- just a confirmation of 
consistency.  If the same MAC address also shows bindings to other IP addresses (perhaps 
on other LANs), then the binding is no longer "1-1" and it may not be possible for the 
LIS to confirm whether the MAC address is "first party" -- and in such a situation it may
be wisest to fail authorization or raise an alarm. 

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