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

["geopriv issue tracker" <[e-mail]>]

#19: Distinguish identity cases as being LCP-like, not LCP
---------------------------------------+------------------------------------
 Reporter:  [e-mail]  |        Owner:  [e-mail]
     Type:  defect                     |       Status:  new                      
 Priority:  major                      |    Milestone:                           
Component:  held-identity-extensions   |      Version:                           
 Severity:  Active WG Document         |   Resolution:                           
 Keywords:  identity lcp               |  
---------------------------------------+------------------------------------

Comment(by [e-mail])

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