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?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
