Subject: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05

From: Robert Sparks <[email-masked]>
Date: Fri, 5 Dec 2008 09:52:55 -0600

This is a GEOPRIV Working Group Last Call for comments on
draft-ietf-geopriv-lbyr-requirements-05
(http://www.ietf.org/internet-drafts/draft-ietf-geopriv-lbyr-requirements-05.txt 
)

Please send your comments no later than Friday Dec 19, 2008.

RjS
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 26 Dec 2008 22:39:05 +0200

Hi Roger, 
Hi Robert, 

I re-read the document and I have a few minor text suggestions: 

I wonder why you use the term "location server" instead of "Location
Information Server". 
In
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-08.txt
we have used the term LIS instead of LS. 
There was a long discussion about this topic and we agreed to use that
term. For now, I did not make any changes regarding the LIS vs. LS
aspect. 

FROM:

   Location-by-Value (LbyV):  The mechanism of representing location
      either in configuration or conveyance protocols, (i.e., the actual
      included location value).

TO:

   Location-by-Value (LbyV):  Location information in the format of a
PIDF-LO
      (or related encoding) 

FROM:

   Location-by-Reference (LbyR):  The mechanism of representing location
      by means of a location URI for use in either a location
      configuration, conveyance, or dereferencing protocol, and which
      refers to a fully specified location.

TO:

   Location-by-Reference (LbyR):  A location URI pointing to location
information 

FROM:

   Location Dereference Protocol:  A protocol which is used by a client
      to query a location dereference server, based on location URI
      input and which returns location information.

TO:

   Location Dereference Protocol:  A protocol that is used by a client
      to query a location server, based on the location URI
      input and which returns location information.

FROM:

   Location URI:  An identifier which serves as a pointer to a location
      record on a remote host (e.g., LIS).  Used within an Location-by-
      Reference mechanism, a location URI is provided by a location
      configuration server, and is used as input by a dereference
      protocol to retrieve location from a dereference server.

TO:

   Location URI:  An identifier that serves as a pointer to a location
      information. A location URI is provided by a location
      server, and is later used as input by a dereference
      protocol to retrieve location information.

FROM:

                    +-----------+  Geopriv      +-----------+
                    |           |  Location     | Location  |
                    |    LIS    +---------------+ Recipient |
                    |           |  Dereference  |           |
                    +-+---+-----+  Protocol (3) +----+------+
                     *    |                        --
         Rulemaker  *     | Geopriv              --
         Policy    *      | Location           --
         Exchange *       | Configuration    --
            (1b) *        | Protocol       --
                *         | (1a)         --      Geopriv
               *          |            --        Using Protocol
     + - - - -*- - - - - -|- - - -+  --          (e.g., SIP)
     |+------+----+ +-----+-----+ |--            (2)
      | Rulemaker | | Target /  |--
     ||  / owner  | | End Host  + |
      |           | |           |
     |+-----------+ +-----------+ |

     |       User of Target       |
     + - - - - - - - - - - - - - -+

To make this figure more generic I would also add a box that talks about
the Rulemaker being outside the Target. 
Additionally, I would only use the term "Rulemaker" instead of
"Rulemaker / owner" because I don't really understand what owner in this
context means. 

FROM:

   (1a).  Target requests reference from server; and receives back, a
   location URI in server response

   (1b).  Rulemaker policy is consulted (interface out of scope)

   (2).  Target conveys reference to recipient (out of scope)

   (3).  Recipient dereferences location URI, by a choice of methods,
   including a request/response (e.g., HTTP) or publish/subscription
   (e.g., SIP SUBSCRIBE/NOTIFY)

TO:

   (1a).  Target requests reference from the location server; and
receives back, a
   location URI in the location server response message

   (1b).  Rulemaker policy is consulted (interface out of scope)

   (2).  Target conveys reference to location recipient (out of scope)

   (3).  Recipient dereferences location URI, for example using HTTP or
SIP

FROM:

   An example scenario of how this might work, is where the Target
   obtains a location URI in the form of a subscription URI (e.g., a SIP
   URI) via HELD (a Geopriv layer 7 location configuration protocol).

TO:

   An example scenario of how this might work, is where the Target
   obtains a location URI in the form of a subscription URI (e.g., a SIP
   URI) via a location configuration protocol.

I would delete the following paragraph as the same information is also
presented further below: 

   Because a location URI is a pointer to the Target's location, it is
   important that it be constructed in such a way that it does not
   unintentionally reveal any usable information about the Target it
   represents.  For example, it is important to prevent adversaries from
   obtaining any information that may be revealed about a Target by
   direct examination of the location URI itself, (e.g., names,
   identifiers, etc.), some determinable pattern or syntax (e.g.,
   sequence of numbers), or guessable codes (e.g., weak encryption).
   Therefore, each location URI must be constructed with security
   safeguards in mind.

FROM:

   1. Access control authorization model:  Access to the location URI is
      limited by policy.  In this case, the Rule Maker (owner/Target) is
      able to provide authorization policies to the LIS during this
      stage, or through some other parallel mechanism (e.g., interface
      1b., Figure 1.).  Policies are attached to a location URI through
      an (undisclosed) mechanism.

   2. Possession authorization model:  The possession authorization
      model is described as having no authentication and/or
      authorization requirement aside from only possessing the location
      URI itself.  In this case, possession implies authorization.
      Access to the location URI is limited by distribution only.
      Whoever possesses the location URI has the ability to dereference
      it.  Possession authorization models may be used within specified
      domains only, or might be used across wide open public networks.

TO:

   1. Access control authorization model:  Access to the location URI is
      limited by policy.  In this model it is assumed that the rulemaker

      provides authorization policies to the LIS and these policies 
      are attached to a location URI and control the dereferencing
process.

   2. Possession authorization model:  The possession authorization
      model is described as not having policies associated to the
location
      URI  from only possessing the location
      URI itself.  In this case, possession implies authorization.
      Access to the location URI is limited by distribution only.
      Whoever possesses the location URI has the ability to dereference
      it.  Possession authorization models may be used within specified
      domains only, or might be used across wide open public networks.

FROM:

It is important to protect the actual location information from
   an intermediate node (despite the fact that in the possession model
   there would be nothing to prevent an interceptor from seeking to
   dereference the location URI). 

TO:

It is important to protect the actual location information from
   an intermediate node.

The statement you made is not correct as the protocol for conveying the
reference could experience confidentiality protection. 

Obfuscating the location URI
   safeguards against the undetected stripping off of what would
   otherwise be evident location information, since it forces a
   dereference operation by the location dereference server, an
   important step for the purpose of providing statistics, audit trails,
   and general logging for many different kinds of location based
   services.

Not sure what exactly that means. 

Each of these two general protocols has
   multiple specific protocol implementations.  Location configuration
   protocols include, HELD, DHCP, and LLDP-MED, whereas current location
   dereferencing protocols include HELD Deref, HTTP GET, and SIP
   SUBSCRIBE/NOTIFY.  

It would be useful to provide references to all these protocols. The
other alternative is to delete the sentence.

I would delete the following sentence: 

Because each of these specific protocol
   implementations has its own unique client and server interactions,
   the requirements here are not intended to state what a client or
   server is expected to do, but rather which requirements must be met
   separately by any location configuration protocol or location
   dereference protocol, for the purposes of using a location URI.

FROM:

   C1. Location URI support:  The configuration protocol MUST support a
      location reference in URI form.

      Motivation: It is helpful to have a consistent form of key for the
      LbyR mechanism.

TO:

   C1. Location URI support:  The location configuration protocol MUST
support a
      location reference in URI form. 

      Motivation: A standardized location reference mechanism increases
interoperability. 

I wonder whether we could delete requirement C4 or reword it a bit: 

FROM:

   C4. Location Information Masking:  The location URI form MUST,
      through randomization and uniqueness, ensure that any location
      specific information embedded within the location URI itself is
      kept obscure during location configuration.

      Motivation: It is important to keep any location information
      masked from a casual observing node.

TO:

   C4. Location Information Masking:  The location URI MUST,
      through randomization and uniqueness, ensure that the location
      URI does not contain location information specific components.

      Motivation: It is important to keep any location information
      masked from a casual observing node.

FROM:

   C5. User Identity Protection:  The location URI MUST NOT contain any
      user identifying information that identifies the user, device or
      address of record, (e.g., which includes phone extensions, badge
      numbers, first or last names, etc.), within the URI form.

      Motivation: It is important to protect caller identity or contact
      address from being included in the form of the location URI itself
      when it is generated.

TO:

   C5. User Identity Protection:  The location URI MUST NOT contain 
      information that identifies the user or device. Examples include
      phone extensions, badge numbers, first or last names.

      Motivation: It is important to protect caller identity or contact
      address from being included in the form of the location URI itself
      when it is generated.

C7 is the same as C2. Hence, delete C7. 

   C7. Validity Interval Indication:  A location configuration protocol
      MUST provide an indication of the location URI validity interval
      (i.e., expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and when it must be
      refreshed.

I would phrase this requirement a bit differently:

FROM:

   C8. Location only:  The location URI MUST NOT point to any
      information about the Target other than it's location.

      Motivation: A user should have the option to control how much
      information is revealed about them.  This provides that control by
      not forcing the inclusion of other information with location,
      (e.g., to not include any identification information in the
      location URI.)

TO:

   C8. Selective disclosure:  The location configuration protocol
      MUST provide a mechanism to control what information is being 
      disclosed about the Target. 

      Motivation: The rulemaker has to be in control of how much
information 
      is revealed during the dereferencing step as part of the privacy
features. 

FROM:

 C9. Location URI Not guessable:  Where location URIs are used
      publicly, any location URI MUST be constructed using properties of
      uniqueness and cryptographically random sequences so that it is
      not guessable.  (Note that the number of bits depends to some
      extent on the number of active location URIs that might exist at
      the one time; 128-bit is most likely enough for the near term.)

      Motivation: Location URIs need to guard against any observing node
      or individual stripping off meaningful information about the
      Target.

TO: 

   C9. Location URI Not guessable:  As a default, the location
configuration 
      protocol MUST return location URIs that are random and unique
throughout 
      the indicated lifetime. A location URI with 128-bits of randomness

      is RECOMMENDED. 

      Motivation: Location URIs should be constructed in such a way that

      an adversary cannot guess them and dereference them without having

      ever obtained them from the Target. 

I don't quite understand C10. 

   C10.  Location URI Optional:  In the case of user-provided
      authorization policies, where anonymous or non-guessable location
      URIs are not warranted, the location configuration protocol MAY
      support optional location URI forms.

      Motivation: Users don't always have such strict privacy
      requirements, but may opt to specify their own location URI, or
      components thereof.

I would delete C11 as the location configuration protocol cannot really
tell the authorization model the Target / Rulemaker is going to apply. I
could get a Location URI and then upload it to a presence server. The
presence server could operate based on my authorization policies. The
initial LbyR would follow a possession model but the entire system would
still be an authorization model. 
 
   C11.  Location URI Authorization Model:  The location configuration
      protocol SHOULD indicate whether the requested location URI
      conforms to the access control authorization model or the
      possession authorization model.

      Motivation: Downstream dereference clients and servers need to
      know whether a location URI provided by the location configuration
      protocol conforms to an access control authorization model or a
      possession authorization model.

C12 is the same as C7 and C2. hence, I suggest to delete C12. 

   C12.  Location URI Lifetime:  A location URI SHOULD have an
      associated expiration lifetime (i.e., validity interval), and MUST
      have an validity interval if used with the possession
      authorization model.

      Motivation: If a location URI is unintentionally leaked, then the
      amount of time that the reference can be potentially used by an
      unknown attacker (or, casual observer) needs to be limited.

D2 is phrased incorrectly. I guess what you would like to say is that
the lifetime of the location URI that is being provided via the Location
Configuration Protocol should also be made available to the Location
Recipient so that he knows how long derefencing is possible. This is not
really a requirement for the Location Dereferencing Protocol but rather
to the Location Conveyance protocol that passes the LbyR (and
potentially the lifetime around) unless you suggest that the location
URI should already indicate the lifetime as a URI parameter. 

In any case, D2 should be deleted. 

   D2. Validity Interval Indication:  A location dereference protocol
      MUST provide an indication of the location URI validity interval
      (i.e., expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and what time it will no
      longer be usable.

D6 is essentially the same as D2. Delete D6.

   D6. Validity Interval Indication:  A dereference protocol MUST
      provide an indication of the location URI validity interval (i.e.,
      expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and when it must be
      refreshed.

I suggest to delete D7 since this is not in control of the Location
Dereferencing Protocol to decide about the style of the URI. 
Instead, it is the Location Server that controls this aspect when
crafting the location URI and this is already covered in the previous
requirements. 

   D7. Location URI anonymized:  Any location URI whose dereference will
      not be subject to authentication and access control MUST be
      anonymized.

      Motivation: The dereference protocol must define an anonymized
      format for location URIs.  This format must identify the desired
      location information via a random token with at least 128 bits of
      entropy (rather than some kind of explicit identifier, such as an
      IP address).

Same as D7, delete. 

   D8. Location Information Masking:  The location URI form MUST,
      through randomization and uniqueness, ensure that any location
      specific information embedded within the location URI itself is
      kept obscure during location URI dereferencing.

      Motivation: It is important to keep any location information
      masked from a casual observing node, requiring instead a discrete
      dereference operation in order to return location information.

I wonder whether this requirement makes sense as we are stating
requirements for the protocol and not for the correctness of the
implementation. In some sense you are asking the implementation to
actually enforce the authorization policies the rulemaker has uploaded.
I think a solution document should say that in the Security
Considerations section but that's about it. 

My suggestion: delete it 

   D9. Location Privacy:  The location dereference protocol MUST support
      the application of privacy rules to the dissemination of a
      requested location object.

      Motivation: The dereference server must obey all provisioned
      privacy rules that apply to a requested location object.

FrOM:

   D10.  Location Confidentiality:  The dereference protocol MUST
      support encryption of messages sent between the location
      dereference client and the location dereference server, and MAY
      alternatively provide messaging unencrypted.

      Motivation: Environmental and local configuration policy will
      guide the requirement for encryption for certain transactions.  In
      some cases, encryption may be the rule, in others, it may be
      acceptable to send and receive messages without encryption.

TO:

   D10.  Location Confidentiality:  The location dereference protocol
MUST
      support confidentiality protection of messages sent between the 
	  Location Recipient and the location server.

      Motivation: The location URI indicates what type of security
protocol 
	  has to be provided. An example is a location URI using a HTTPS
URI scheme.
	  
regarding D11: When dereferencing takes place and the client
authentication 
is demanded then the authorization can implicitly be inferred. I would
delete 
this requirement as it does not get the Location Recipient too far to
know 
what authorization model is being applied. If you consider the HTTP
environment 
then you will notice that there you see what authorization model is
being applied
when you try to access the resource being a URL and you are being
challenged. 

    D11.  Location URI Authorization Model:  The location dereference
      protocol SHOULD indicate whether the requested location URI
      conforms to the access control authorization model or the
      possession authorization model.

      Motivation: Downstream dereference clients need to know whether a
      location URI provided by the location configuration protocol
      conforms to an access control authorization model or a possession
      authorization model in order to save time processing dereference
      attempts.

FROM:
	  
	     A location URI, regardless of its construction, if public,
by itself,
   implies no safeguard against anyone being able to dereference and get
   the location.  The method of constructing the location URI form to
   include randomization along with encryption does help prevent some
   potential pattern guessing.  In the case of one time use location
   URIs, (referred to as a pawn ticket), the argument can be made that
   possession implies permission, and location URIs that are public are
   protected only by privacy rules enforced at the dereference server.

   TO:
   
   The method of constructing the location URI  to
   include randomized components helps to prevent adversaries from 
   obtaining location information without ever retrieving a location
URI.  
   In the possession model, a location URI, regardless of its
construction, 
   if made publically available, implies no safeguard against anyone
being able to 
   dereference and get the location. Care has to be paid when
distribution such 
   a location URI to the trusted location recipients. When this aspect
is of concern then 
   the authorization model has to be chosen. Even in this model care has
to be 
   taken on how to construct the authroization policies to ensure that
only those 
   parties have access to location information that are considered
trustworthy enough 
   to enforce the basic rule set that is attached to location
information in a PIDF-LO 
   document. 

Ciao
Hannes
	  
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Robert Sparks
>Sent: 05 December, 2008 17:53
>To: GEOPRIV
>Subject: [Geopriv] WGLC: draft-ietf-geopriv-lbyr-requirements-05
>