Subject: [Geopriv] Early IESG-type review of draft-ietf-geopriv-held-identity-extensions-04.txt

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Oct 2010 18:43:10 +0100

Hi,
Robert asked me to comment on escaping, but I ended up doing full 
IESG-type review of the document.

Note that I still need to check a couple of things (and may end up 
changing some Comments to Discusses and vice versa), in particular I 
haven't checked the XML schema.

---------------------
1.1.  Applications

   Location configuration:  A Device can use these parameters to
      identify itself to a LIS.  Identification information other than
      an IP address might be needed to determine the location of a
      Device.

      A LIS can authorize location configuration requests using a policy
      that allows Devices to acquire their own location (see
      Section 4.1).  If an unauthorized third-party falsifies addressing
      on request packets to match the provided Device identity, the
      request might be erroneously authorized under this policy.
      Requests containing Device identity must not be authorized using

Comment: s/must not/MUST NOT?

      this policy unless specific measures are taken to prevent this
      type of attack.

2.2.  Identifier Format and Protocol Details

   If the LIS requires an identifier that is not provided in the
   request, the desired identifiers MAY be identified in the HELD error
   response, using the "requiredIdentifiers" element.  This element
   contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
   that identify the identifier elements required by the LIS.  Namespace
   prefix bindings for the qualified names are taken from document
   context.  Figure 2 shows an example error indicating that the
   requester needs to include a MAC address (Section 3.2) if the request
   is to succeed.

DISCUSS DISCUSS: Is there an IANA registry for these?

     <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
            code="badIdentifier">
       <message xml:lang="en">MAC address required</message>
       <requiredIdentifiers
           xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         mac

DISCUSS: How can multiple values ("a list") be specified?
(I haven't checked the XML schema yet, so the answer might be obvious.)

       </requiredIdentifiers>
     </error>

3.1.  IP Address

   The "ip" element can express a Device identity as an IP address.  The
   "v" attribute identifies the IP version with a single hexadecimal
   digit.  The element uses the textual format specific to the indicated
   IP version.

DISCUSS: This needs a reference for the IPv4 and IPv6 representations.

     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>

Should this be using uppercase (as per one of the recent documents IESG
approved)?

     </device>

   In situations where location configuration does not require
   additional identifiers, using IP address as an identifier enables
   authorized third-party requests.

3.2.  MAC Address

   The media access control (MAC) address used by the IEEE 802 family of
   access technologies is an identifier that is assigned to a particular
   network Device.  A MAC address is a unique sequence that is either
   assigned at the time of manufacture of a Device, or assigned by a
   local administrator.  A MAC address rarely changes; therefore, a MAC
   address is an appropriate identifier for a Device.

DISCUSS: Does this need a reference and specific format definition?

3.4.  Network Access Identifier

   The formal grammar for NAI [RFC4282] permits invalid Unicode,

DISCUSS: Did you mean "invalid UTF-8 sequences"? "invalid Unicode" means 
something quite different.

   which
   cannot be expressed using XML.  Therefore, this expression of NAI
   permits escaping.  Non-unicode characters (and any other character)

s/Non-unicode characters (and any other character)/Invalid UTF-8 sequences

   are expressed using a backslash ('\') followed by two hexadecimal
   digits representing the value of a single octet.

[I see. This is indeed quite hackish, but I don't have a better proposal
at the moment. But I have to ask if this interacts with the slash
escaping allowed in NAI syntax (as per RFC 4282)?]

DISCUSS: Are hex values case-insensitive? I.e., is "\AA" the same as
"\aa" or "\aA"?

   The canonical representation of an NAI is the sequence of octets that
   is produced from the concatenation of UTF-8 encoded sequences of

This needs a reference to UTF-8 (RFC 3629). (Or add it earlier, if one
of my changes above is applied.)

   unescaped characters and octets derived from escaped components.
   This sequence MUST conform to the constraints in [RFC4282].

3.4.1.  Using NAI for Location Configuration

   After receiving a location request that includes an NAI, the LIS
   sends a "Location-Requestor-Authentication-Protocol" access request
   message to the Authentication, Authorization and Accounting (AAA)
   server.  This request includes an "MS-Identity-Assertion" parameter

DISCUSS: Is this attribute discussed somewhere in more details?
A reference to the document that defines it is needed here.

   containing the NAI.

3.5.  URI

   A Device can be identified by a URI.  Any URI can be used providing

DISCUSS: This needs a Normative reference to the URI spec (RFC 3986).

   that the requester and LIS have a common understanding of the
   semantics implied by use of the URI.

3.7.  Cellular Telephony Identifiers

DISCUSS: Each identifier in this section needs a Normative reference to
the document which defines its format. Alternatively, the format needs 
to be defined in full in this document.

5.  Security Considerations

   All HELD requests containing identity MUST be authenticated by the
   LIS.  How authentication is accomplished and what assurances are
   desired is a matter for policy.

Is this enough? Should this be referencing TLS-server-identity document?

   The base HELD protocol uses return reachability of an IP address
   implied by the requester being able to successfully complete a TCP
   handshake.  It is RECOMMENDED that any means of authentication
   provide at least this degree of assurance.  For requests that include
   Device identity, the LIS MUST support HTTP digest authentication.

DISCUSS: This needs a Normative reference to the RFC that defined HTTP
Digest.

   Unauthenticated location requests containing Device identity can be
   challenged with an HTTP 401 (Unauthorized) response or rejected with
   an HTTP 403 (Forbidden) response.

5.3.  Third-Party Requests

   However, because the third-
   party needs to be authorized, the requester MUST be authenticated by
   the LIS.

DISCUSS DISCUSS: How?

7.  IANA Considerations

   It also creates a new
   registry for Device identity types, and stipulates how new types are
   to be added.

DISCUSS: Actually it doesn't. Where is this information defined?