Subject: Re: [Geopriv] [geopriv] #19: Distinguish identity cases as being LCP-like, not LCP

From: Alissa Cooper <[email-masked]>
Date: Sat, 10 Oct 2009 20:40:36 +0100

Martin,
It has been awhile in coming, but I've taken a look at the new text  
you suggest and also a look back at the rest of the text of identity- 
extensions. I have some thoughts below about how to clarify the  
effects of identity extensions in the context of the current  
discussion about what LCPs and "LCP policy" are and are not. I don't  
think this document can be written without mentioning LCPs or LCP  
policy, but on the other hand I've made some recommendations for how  
to make it clearer that HELD with identity extensions implemented is  
not an LCP.
Thoughts?
Best,
Alissa

== Section 1 ==
> In a location configuration protocol (LCP), the location
>    being requested is the requestor's location.  This fact can make  
> the
>    problem of identifying the Device simpler for LCPs,

s/simpler/simple
> An important characteristic of this addition to the HELD protocol is
>    that it also expands the potential scope of HELD beyond that of an
>    LCP.  The scope of an LCP is limited to the interaction between a
>    Device and a LIS.  That is, an LCP is limited to the Device
>    retrieving information about their own location.  With this  
> addition,
>    authorized third party location recipients (LRs) are able to make
>    requests that include identifiers to retrieve location information
>    about a particular Device.

Replace with:
An important characteristic of this addition is that the HELD protocol  
with identity extensions implemented is not considered an LCP.  The  
scope of an LCP is limited to the interaction between a Device and a  
LIS, and LCPs can guarantee the identity of Devices without additional  
authorization checks.  Neither of these is true for HELD with identity  
extensions. Furthermore, identity extensions allow authorized third  
party location recipients (LRs) to make requests that include  
identifiers to retrieve location information about a particular Device.
> The usage of HELD for purposes beyond the Device-LIS interaction

Replace with: The usage of HELD identifiers

== Section 1.1 ==

> The use of additional identifiers in HELD falls into two categories.  
> A Device can use these parameters to provide additional  
> identification information to a LIS. Identification information,  
> such as the MAC address of the interface card of a Target, can be  
> used to reduce the time required to determine the location by a LIS.  
> In other cases, a LIS might require Device identification before any  
> location information can be generated.

>  A third party LR can be granted authorization to make requests for  
> a given Device. In particular, network services can be permitted to  
> retrieve location for a Device that is unable to acquire location  
> information for itself (see Section 6.3 of [I-D.ietf-ecrit- 
> phonebcp]). This allows use of location-dependent applications -  
> particularly essential services like emergency calling - where  
> Devices do not support a location configuration protocol (LCP) or  
> they are unable to successfully retrieve location information.

Replace with:
The use of additional identifiers in HELD falls into two categories:
1. A Device can use these parameters to provide additional  
identification information about itself to a LIS. [leave remaining  
para as is]
2. A third-party LR can be granted authorization ... [leave remaining  
para as is]

== Section 5 (based on text suggested below) ==
> The authorization model for a location configuration protocol assumes
> that the LR is also the Target, and that providing that LR with  
> information
>  about its own location is allowed.  We call this property "LCP  
> policy".

Replace with:

Location configuration protocols make use of an authorization model  
known as "LCP policy," which permits only Targets to be the recipients  
of their own locations.

== Section 5.1 ==

I think Section 5.1 should be about Target requests, and section 5.2  
should be about third-party requests. That is the order that the two  
are in for the entire document, so no sense in switching them in this  
section.

I would recommend naming section 5.1 "Target Requests" or "Targets  
Requesting Their Own Locations."

> When Device identity is used, the "LCP policy" not applicable when
>   identity information is provided.   The Geopriv security and privacy
>   considerations [I-D.ietf-geopriv-arch] are applicable.

> A policy that is similar to the LCP policy might be appropriate if the
>   Device identity provided can be determined to be the same as the
>   authenticated requester identity.  A Rule Maker, in setting local
> policy, might choose to permit such a request based on similar basic
> motivations.

Replace with:

When a Target uses identity extensions to obtain its own location,  
HELD can no longer be considered an LCP. The authorization policy that  
the LIS uses to respond to these requests must be provisioned by one  
or more Rule Makers. In the case that the LIS exclusively provides  
Targets with their own locations, the LIS can still be said to be  
following the "LCP policy." In all cases, the Geopriv security and  
privacy considerations [I-D.ietf-geopriv-arch] are applicable.

> Aspects of the security and privacy considerations of the base HELD
>   protocol [I-D.ietf-geopriv-http-location-delivery] are applicable  
> if an
>   LCP-like policy is used.

I don't understand what this means. All aspects? Some aspects? If so,  
which ones?

> The spoofing protections provided when using LCP-like policy differ  
> from
>   an LCP policy.  In the LCP policy return routability is considered
>   sufficient protection against spoofing.

Replace with:

The spoofing protections provided when using HELD with identity  
extensions to provide Targets with their own locations differ from the  
protections inherent in an LCP.  For LCPs, return routability is  
considered
   sufficient protection against spoofing.

>  If identifiers are not identical,
>   then the existence of an LCP-like policy could be exploited by an
>   attacker.
>
>  For example, it is not appropriate to apply LCP-like policy under
> these terms

Replace with:

  If identifiers are not identical, the use of HELD identity  
extensions to provide Targets with their own locations could be  
exploited by an
   attacker.

  For example, it is not appropriate to provide Targets with their own  
locations under these terms

== Section 6 ==

> These protections apply to both LCP requests and the requests made  
> by third parties.

Replace with:
These protections apply to both Target requests for their own  
locations and requests made by third parties.

== Section 6.2 ==
Again, I would leave the old order (Target requests first) and call  
this "Target Requests" or "Targets Requesting Their Own Locations."
> Requests made by a Device in the context of a LCP-like requests are
>   covered by the same set of protections offered by HELD.  LCP-like
>   requests might be authorized under a policy similar to the "LCP  
> policy"
>   that permits a Target access to location information about itself.

Replace with:
Requests made by a Device for its own location are
   covered by the same set of protections offered by HELD.  These
   requests might be limited by an authorization policy similar to the  
"LCP policy"
   that permits only a Target with access to location information  
about itself.

== Section 6.3 ==
> Requests from third parties have the same requirements for server  
> authentication, confidentiality and protection from modification as  
> LCP requests.

Replace with:
Requests from third parties have the same requirements for server  
authentication, confidentiality and protection from modification as  
Target requests for their own locations.

On Sep 16, 2009, at 9:38 PM, geopriv issue tracker wrote:

> #19: Distinguish identity cases as being LCP-like, not LCP
> --------------------------------------- 
> +------------------------------------
> Reporter:  [email-masked]  |        Owner:  [email-masked]
>     Type:  defect                     |       Status:  new
> Priority:  major                      |    Milestone:
> Component:  held-identity-extensions   |      Version:
> Severity:  Active WG Document         |   Resolution:
> Keywords:  identity lcp               |
> --------------------------------------- 
> +------------------------------------
>
> Comment(by [email-masked]):
>
> = Proposed changes summary =
>
> I've taken some of this from the current debate on identity.  I  
> think that
> this addresses the shared concerns without falling into the traps that
> Richard identified.  It's somewhat generic guidance, but I think  
> that it
> hits the all the necessary points.
>
> This primarily affects Section 5 ([http://tools.ietf.org/html/draft-ietf-
> geopriv-held-identity-extensions-00#section-5 Privacy]).  Section  
> 5.2 is
> largely rewritten with this goal in mind.
>
> Minor changes also in Section 6.2 ([http://tools.ietf.org/html/draft-ietf-
> geopriv-held-identity-extensions-00#section-6.2 Security/LCP]).
>
> == 5 Privacy ==
>
> ''Unchanged text; minor editorial/stylistic change in the note,  
> which will
> likely be removed once the geopriv-arch document is updated with the
> Device/Target clarifications''
>
>  The authorization model for a location configuration protocol assumes
> that
>  the LR is also the Target, and that providing that LR with  
> information
>  about its own location is allowed.  We call this property "LCP  
> policy".
>  In effect, an LCP server (that is, the LIS) follows a single rule  
> policy
>  that states that the Target is the only authorized Location  
> Recipient.
>
>     Note: HELD explicitly states that the Target is a Device and not a
>     person.  When discussing privacy, Targets other than a Device  
> have a
>     stake in protecting privacy.  Therefore, the more general term of
>     Target - any potential subject of location information - is used  
> in
>     place of Device.
>
> === 5.1 Third Party Requests ===
>
> ''Unchanged text, moved from the bottom of the old Section 5''
>
>   The LCP policy does not allow requests made by third parties.  If  
> a LIS
>   permits requests from third parties using Device identity, it  
> assumes
> the
>   rule of a Location Server (LS).  As a Location Server, the LIS MUST
>   explicitly authorize requests according to the policies that are
> provided
>   by Rule Makers, including the Target.  This includes  
> authentication of
>   requesters where required by the authorization policies.
>
>   An organization that provides a LIS that allows third party requests
> must
>   provide a means for a Rule Maker to specify authorization policies  
> as
>   part of the LIS implementation (e.g, in the form of access control
>   lists).  Authorization must be established before allowing third  
> party
>   requests for the location of any Target.  Until an authorization  
> policy
>   is established, the LIS MUST reject requests by third parties  
> (that is,
>   the default policy is "deny all").
>
>   When the LIS is operated by an access network, the relationship  
> between
>   the Target and the LIS can be transient.  However, the process of
>   establishing network access usually results in a form of agreement
>   between the Target and the network provider.  This process offers a
>   natural vehicle for establishing location privacy policies.
> Establishing
>   authorization policy might be a manual process, an explicit part  
> of the
>   terms of service for the network, or an automated system that  
> accepts
>   formal authorization policies (see [RFC4745], [RFC4825]).  This  
> document
>   does not mandate any particular mechanism for establishing an
>   authorization policy.
>
> === 5.2 Location Configuration-like Requests ===
>
> ''Changed text''
>
>   When Device identity is used, the "LCP policy" not applicable when
>   identity information is provided.   The Geopriv security and privacy
>   considerations [I-D.ietf-geopriv-arch] are applicable.
>
>   A policy that is similar to the LCP policy might be appropriate if  
> the
>   Device identity provided can be determined to be the same as the
>   authenticated requester identity.  A Rule Maker, in setting local
> policy,
>   might choose to permit such a request based on similar basic
> motivations.
>
>   Aspects of the security and privacy considerations of the base HELD
>   protocol [I-D.ietf-geopriv-http-location-delivery] are applicable  
> if an
>   LCP-like policy is used.  Issues related to construction of the  
> PIDF-LO
>   document and the security protections provided by transport are
>   identical.
>
>   The spoofing protections provided when using LCP-like policy  
> differ from
>   an LCP policy.  In the LCP policy return routability is considered
>   sufficient protection against spoofing.  A similar degree of  
> assurance
> is
>   required if a similar policy is to be used.
>
>   A Rule Maker might require additional verification that the  
> identifier
> is
>   owned by the requester.  Verification that depends on return  
> routability
>   can only provide weaker assurances than those provided by return
>   routability; therefore, policy might require the use of additional,
>   independent methods of verification.
>
>   Care is required where a direct one-to-one relationship between
> requester
>   and Device identity does not exist.  If identifiers are not  
> identical,
>   then the existence of an LCP-like policy could be exploited by an
>   attacker.
>
>     For example, it is not appropriate to apply LCP-like policy under
> these
>     terms where a requester is authenticated by NAI and the supplied
> Device
>     identity is a MAC address, even if that MAC address is currently
>     registered with the network under the given NAI.  In this case,  
> the
>     requester might be requesting from a different MAC address  
> registered
>     under the same NAI.  The correct way of gaining authorization is  
> to
>     establish a policy that permits this particular request as a third
>     party request.
>
> == 6.2 Location Configuration Protocol-like Requests ==
>
> ''To retain consistent ordering, this will be switched with Section  
> 6.3
> (Third Party Requests)''
>
>   Requests made by a Device in the context of a LCP-like requests are
>   covered by the same set of protections offered by HELD.  LCP-like
>   requests might be authorized under a policy similar to the "LCP  
> policy"
>   that permits a Target access to location information about itself.
>
> ''Unchanged''
>   Identity information provided by the Device is private data that  
> might
> be
>   sensitive.  The Device provides this information in the  
> expectation that
>   it assists the LIS in providing the Device a service.  The LIS  
> MUST NOT
>   use identity information for any other purpose other than serving  
> the
>   request that includes that information.
>
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/19#comment:1 
> >
> geopriv <http://tools.ietf.org/geopriv/>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: Marc Linsner <[email-masked]>
Date: Tue, 13 Oct 2009 08:28:54 -0400

Alissa,

> known as "LCP policy," which permits only Targets to be the recipients

GeoPriv should not set-in-stone "LCP Policy".  That's up to the RuleMaker.
We can assume the RuleMaker's policy for a target knowing it's own location
is different from a 3rd party policy, and we can posture the request as
such, but as Laura Leiss has stated for a long time, the Rulemaker will
ultimately decide whether a target will see it's own location or not.

-Marc-

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 13 Oct 2009 21:16:17 +0100

So am I right in thinking that if it said

>> Location configuration protocols [can|may|might] make use of an  
>> authorization model
>> known as "LCP policy,"

that would be better?

Alissa

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Oct 2009 18:46:52 -0500

Thanks Alissa,

I've taken a sweep through and each of these represents an improvement.  Apart from some very minor editorial changes, I've taken all these proposals verbatim.

I'll post an update to the draft shortly, after responding on the other issue.

Thanks,
Martin

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Sunday, 11 October 2009 6:41 AM
> To: Thomson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] [geopriv] #19: Distinguish identity cases as
> being LCP-like, not LCP
> 
> Martin,
> > Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/19#comment:1
> > >

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

---

From: Marc Linsner <[email-masked]>
Date: Wed, 14 Oct 2009 08:26:10 -0400

Alissa,

I don't disagree with this.  But I view it a little differently.  I view
that there is a demark between the LCP and the policy engine, hence the LCP
doesn't 'use' a particular policy.  The LCP is simply the communication
protocol that presents a location request to the policy engine.  Hence, if,
the LIS can authenticate a request as coming from a target by some other
means, not using a LCP, the same 'LCP Policy' would be used.  So, the policy
isn't tied to the communication protocol, but in the case of a request
coming in via a LCP, the process required to authenticate the requester as
the target are taken care of by the communication protocol.

If this makes any sense.....

To carry this thought a little further.  Someone *could* build a LS/LIS that
includes a DHCP front-end, a SIP front-end, and a HELD front-end.  Any
request coming to this LS/LIS would be evaluated based on the protocol it
arrived on, the authentication of the requester, and then a policy chosen
that fits the posture of the request.  Hence, a common policy engine that is
demarked from the communication protocol.

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 Oct 2009 22:21:12 -0400

Hey Marc,

> doesn't 'use' a particular policy.  

I think you're a little too focused on mechanism here.  When one says 
that "X enforces Y policy", all that really means is that "X behaves in 
such a way that Y policy is satisfied".  The NAT in my home gateway 
enforces a default-deny policy on incoming TCP connections not because 
it has some policy engine that looks at a SYN and makes a decision, but 
just because that's how it works.  If you've got a DHCP or HELD server 
that blindly responds to requests from a host with information on that 
host's location, then it's enforcing the LCP policy just by virtue of 
the way it acts.

In that spirit, I think Alissa's proposed text makes sense.  Maybe an 
additional sentence or two would be helpful to explain that applying a 
policy doesn't imply specific policy machinery?

(Note that none of the above rules out having some policy engine in any 
case, e.g., to support more sophisticated policy or multi-protocol 
operations (as you suggest).  It's just that the LCP policy is the one 
that's really easy to implement.)

--Richard

> The LCP is simply the communication

---

From: "geopriv issue tracker" <[email-masked]>
Date: Mon, 19 Oct 2009 01:08:26 -0000

#19: Distinguish identity cases as being LCP-like, not LCP
---------------------------------------+------------------------------------
 Reporter:  martin.thomson@…           |        Owner:  martin.thomson@…         
     Type:  defect                     |       Status:  closed                   
 Priority:  major                      |    Milestone:                           
Component:  held-identity-extensions   |      Version:                           
 Severity:  Active WG Document         |   Resolution:  fixed                    
 Keywords:  identity lcp               |  
---------------------------------------+------------------------------------
Changes (by martin.thomson@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/19#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 20 Oct 2009 08:43:53 +0100

I think I get what you're saying, and it's probably right that the  
protocol is not what uses the authorization policy -- it's the LIS  
that uses the authorization policy. So maybe the phrase in question  
would make more sense if it said, "A LIS functioning at one end of a  
location configuration protocol may make use of an authorization model  
known as 'LCP policy,' . . ."

Alissa

---

From: "geopriv issue tracker" <[email-masked]>
Date: Thu, 29 Oct 2009 00:22:25 -0000

Comment(by martin.thomson@…):

 Note: changes in -01 are as recommended by Alissa here:
 http://www.ietf.org/mail-archive/web/geopriv/current/msg08017.html

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/19#comment:3>
geopriv <http://tools.ietf.org/geopriv/>