Skip to main content

Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2010-12-13
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-12-13
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-12-13
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-12-13
06 (System) IANA Action state changed to Waiting on Authors from On Hold
2010-12-10
06 (System) IANA Action state changed to On Hold from In Progress
2010-12-10
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-12-09
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-12-09
06 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2010-12-08
06 (System) IANA Action state changed to In Progress
2010-12-08
06 Amy Vezza IESG state changed to Approved-announcement sent
2010-12-08
06 Amy Vezza IESG has approved the document
2010-12-08
06 Amy Vezza Closed "Approve" ballot
2010-12-08
06 Amy Vezza Approval announcement text regenerated
2010-12-08
06 Robert Sparks Ballot writeup text changed
2010-12-07
06 Dan Romascanu
[Ballot comment]
Section 3.2 includes the following statement:

  The media access control (MAC) address used by the IEEE 802 family of
  access technologies …
[Ballot comment]
Section 3.2 includes the following statement:

  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.

Actually MAC addresses are assigned to network interfaces that connect devices to the IEEE LAN - these are typically fixed on devices but not always. I recommend to make the text more accurate and clear on this aspect.
2010-12-07
06 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2010-12-02
06 Cindy Morgan State changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer.
2010-12-02
06 Sean Turner
[Ballot comment]
I support Tim's discuss.

The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then …
[Ballot comment]
I support Tim's discuss.

The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier.  I see the general guidance in Section 2- just curious why only FQDN got this special treatment.

In Section 3.7, I says:

Each identifier contains a string of decimal digits with a length as specified.

But, the imsi and min identifier descriptions don't include length constraints.  Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions).

Please remove "Note that" from the last paragraph of the Security considerations.  Normative language should not be in a note.
2010-12-02
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss
2010-12-02
06 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2010-12-02
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2010-12-02
06 Adrian Farrel
[Ballot comment]
I support Dan's Discuss.
draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface".
Although …
[Ballot comment]
I support Dan's Discuss.
draft-ietf-georiv-arch is (somewhat) careful in its definition of "device" and I do not think it means "network interface".
Although it is true that network interfaces do not currently wander independent of devices (and if they did, they might need to be independently trackable) some care is needed in the wording to make the association clear.
2010-12-01
06 Sean Turner
[Ballot comment]
I support Tim's discuss.

The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then …
[Ballot comment]
I support Tim's discuss.

The FQDN section specifically mentions that if the FQDN doesn't correspond to a singular IP address or host then it's not suitable. Should this be repeated in the other sections? e.g., if the URI doesn't specifically refer to a particular device, then a URI is not a suitable identifier.  I see the general guidance in Section 2- just curious why only FQDN got this special treatment.

In Section 3.7, I says:

Each identifier contains a string of decimal digits with a length as specified.

But, the imsi and min identifier descriptions don't include length constraints.  Seems like they all should (they're in the schema I guess just copy the values forward to the descriptions).
2010-12-01
06 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
06 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-11-30
06 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2010-11-28
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2010-11-15
06 Alexey Melnikov
[Ballot comment]
2.2.  Identifier Format and Protocol Details

  If the LIS requires an identifier that is not provided in the
  request, the desired …
[Ballot comment]
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.

Is there an IANA registry for these?


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 description sufficient for providing interoperability?
2010-11-15
06 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2010-11-14
06 (System) New version available: draft-ietf-geopriv-held-identity-extensions-06.txt
2010-11-10
06 Robert Sparks Telechat date has been changed to 2010-12-02 from 2010-11-18
2010-10-27
06 Tim Polk
[Ballot discuss]
This discuss expands upon one of the comments in Alexey's ballot position.

In section 5. Security Considerations, paragraphs 2 and 3 state:

  …
[Ballot discuss]
This discuss expands upon one of the comments in Alexey's ballot position.

In section 5. Security Considerations, paragraphs 2 and 3 state:

  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.

  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
  [RFC2617].  Unauthenticated location requests containing Device
  identity can be challenged with an HTTP 401 (Unauthorized) response
  or rejected with an HTTP 403 (Forbidden) response.

However, RFC 5985 states:

  A Device that conforms to this specification MAY choose not to
  support HTTP authentication [RFC2617] or cookies [RFC2965].

Where IP reachability is not an appropriate means of authentication, the only
authentication mechanism that MUST be required by the LIS is optional for
the Device.  Should digest authentication be a MUST for the Device?
The combination of digest authentication and TLS seems a straightforward solution.
Alternatively, TLS client authentication is a more complex solution but
might be more scalable.
2010-10-27
06 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2010-10-27
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2010-10-27
06 Russ Housley State changed to IESG Evaluation - Defer from IESG Evaluation by Russ Housley
2010-10-27
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo
2010-10-27
06 Stewart Bryant [Ballot comment]
I agree with the discusses already posted, but no additional issues.
2010-10-27
06 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant
2010-10-27
06 Robert Sparks State changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party by Robert Sparks
2010-10-26
06 Dan Romascanu [Ballot comment]
I support the issues raised by Alexey in his DISCUSS.
2010-10-26
06 Dan Romascanu
[Ballot discuss]
In Section 3.2:

  The media access control (MAC) address used by the IEEE 802 family of
  access technologies is an identifier …
[Ballot discuss]
In Section 3.2:

  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.

Actually MAC addresses are not assigned to devices but to network interfaces that connect devices to a physical segment. There may be more than one MAC address per device in the case of devices with multiple network interfaces, and even more MAC addresses per one physical interface in some cases (for example one MAC address per VLAN). The scheme works but only for the globally unique addresses which are guaranteed to be unique and any of the MAC addresses on the device interfaces can be used to identify the device.
2010-10-26
06 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2010-10-26
06 Lars Eggert
[Ballot comment]
Section 3.6., paragraph 4:
>    A domain name does not always correspond to a single IP address or
>    host.  If …
[Ballot comment]
Section 3.6., paragraph 4:
>    A domain name does not always correspond to a single IP address or
>    host.  If this is the case, a domain name is not a suitable
>    identifier.

  Right. Domain names are also clearly context specific (split-horizon
  DNS, etc.)
2010-10-26
06 Lars Eggert
[Ballot discuss]
Section 3.3., paragraph 0:
> 3.3.  TCP or UDP Port Number

  DISCUSS: There are transport protocols other than TCP and UCP, i.e., …
[Ballot discuss]
Section 3.3., paragraph 0:
> 3.3.  TCP or UDP Port Number

  DISCUSS: There are transport protocols other than TCP and UCP, i.e.,
  SCTP and DCCP. But let's take a step back - is there *really* a use
  case for identifying devices based on what is basically a socket ID?
  If yes, then you need to extend this to support SCTP and DCCP (note
  that DCCP has service codes in addition to port numbers.) This will be
  ugly and complex, hence the question whether anybody actually really
  needs this urgently.
2010-10-26
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2010-10-23
06 Alexey Melnikov
[Ballot comment]
I am still thinking about the following issues, so for now this is a Comment (but I can upgrade it to DISCUSS):


2.2.  …
[Ballot comment]
I am still thinking about the following issues, so for now this is a Comment (but I can upgrade it to DISCUSS):


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.

Is there an IANA registry for these?


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 description sufficient for providing interoperability?
2010-10-23
06 Alexey Melnikov
[Ballot discuss]
Thank you for addressing most of my comments from my early AD review.

There are a couple of minor things that I would …
[Ballot discuss]
Thank you for addressing most of my comments from my early AD review.

There are a couple of minor things that I would still like to discuss before recommending approval of this document.



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 ([RFC0791] for IPv6,

Should be IPv4.

I would actually suggest referencing IPv4/IPv6 address ABNF from RFC 3986.

  [RFC4291] for IPv6).



3.7.  Cellular Telephony Identifiers

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.
2010-10-23
06 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2010-10-22
06 Robert Sparks Placed on agenda for telechat - 2010-10-28 by Robert Sparks
2010-10-22
06 Robert Sparks [Ballot Position Update] New position, Yes, has been recorded for Robert Sparks
2010-10-22
06 Robert Sparks Ballot has been issued by Robert Sparks
2010-10-22
06 Robert Sparks Created "Approve" ballot
2010-10-20
05 (System) New version available: draft-ietf-geopriv-held-identity-extensions-05.txt
2010-10-13
06 Robert Sparks State changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead by Robert Sparks
2010-10-13
06 Amy Vezza State changed to Waiting for AD Go-Ahead from In Last Call by Amy Vezza
2010-10-07
06 Amanda Baber
IANA understands that, upon approval of this document, three IANA
Actions must be completed.

First, in the namespace registry of the IETF XML document repository …
IANA understands that, upon approval of this document, three IANA
Actions must be completed.

First, in the namespace registry of the IETF XML document repository
located at

http://www.iana.org/assignments/xml-registry/ns.html

a new registration is to be made:

ID: geopriv:held:id
URN: urn:ietf:params:xml:ns:geopriv:held:id
Registration template:

URI: urn:ietf:params:xml:ns:geopriv:held:id

Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com).

XML:

BEGIN




HELD Device Identity Parameters


Namespace for HELD Device Identity Parameters


urn:ietf:params:xml:ns:geopriv:held:id


See RFC-to-be.


END
Reference: RFC-to-be

Second, in the schema registry of the IETF XML document repository
located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new registration is to be made.

ID: geopriv:held:id
URI: urn:ietf:params:xml:schema:geopriv:held:id
Filename: As documented in Section 6 of the approved document
Reference: RFC-to-be

Third, in the HELD Error Codes subregistry of the Geopriv HTTP Enabled
Location Delivery (HELD) Parameters registry located at:

http://www.iana.org/assignments/held-parameters/held-parameters.xhtml

a new registration is to be made:

code: badIdentifier
description: This error code indicates that a Device identifier used in
the HELD request was either: not supported by the LIS, badly formatted,
or not one for which the requester was authorized to make a request.
reference: RFC-to-be

IANA understands that these three actions are all that need to be
completed upon approval of the document.
2010-09-28
06 Amy Vezza Last call sent
2010-09-28
06 Amy Vezza State changed to In Last Call from Last Call Requested by Amy Vezza
2010-09-28
06 Robert Sparks Last Call was requested by Robert Sparks
2010-09-28
06 (System) Ballot writeup text was added
2010-09-28
06 (System) Last call text was added
2010-09-28
06 (System) Ballot approval text was added
2010-09-28
06 Robert Sparks State changed to Last Call Requested from Publication Requested by Robert Sparks
2010-06-22
06 Amy Vezza
The GEOPRIV working group requests publication of draft-ietf-geopriv-
held-identity-extensions-04 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd …
The GEOPRIV working group requests publication of draft-ietf-geopriv-
held-identity-extensions-04 as Proposed Standard.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for this document is Alissa Cooper. The Shepherd
has personally reviewed this version of the document, and believes it
is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been thoroughly reviewed by a range of WG members,
and has also received substantial attention from the emergency calling
community. It received an early SECDIR review (http://www.ietf.org/mail-archive/web/geopriv/current/msg08064.html
). As it was reviewed a number of times prior to working group
adoption, I do not have concerns about the depth or breadth of reviews
performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document would likely benefit from further security review, as
security concerns have been the focal point of most of the discussion
about the document. I am confident with the security model as is, but
it may be helpful to confirm within the security community since the
SECDIR review was several draft versions ago.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no special concerns about this document. It is a very necessary
piece of the HELD architecture, and the working group has refined it
at length so as to comply with appropriate security and privacy
standards. Several interoperable implementations of this specification
(or parts of it) exist and have been tested within the emergency
calling community.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is general consensus within the working group behind this
document. Those within the group who had raised strong concerns over
the years about various security aspects have agreed that those
concerns have been resolved.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any extreme discontent or potential appeals related
to this document.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

I have personally verified that the document satisfies all nits.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are split into normative and informative. There are no
downward references or references to documents with unclear status.
There are two I-Ds in the normative references section, draft-ietf-
geopriv-http-location-delivery and draft-ietf-idnabis-defs, both of
which are in the RFC Editor's Queue.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists, and provides instructions for
IANA to register a sub-namespace in the HELD namespace and a registry
of device identity types. The name for the new registry is reasonable
and the initial contents are defined.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

All of the XML in the document validates correctly.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

When a Location Information Server receives a request for location
information (using the locationRequest message), described in the base
HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of the arriving message as a pointer to the location
determination process. Two additional use cases are addressed by this
document. In the first, location configuration requires additional or
alternative identifiers from the source IP address provided in the
request. In the second, an entity other than the Device requests the
location of the Device.

Working Group Summary

This document has been discussed at length within the working group,
with a particular focus on security and privacy. There is WG consensus
that this document describes an important piece of the HELD
architecture and that it has addressed concerns raised previously.

Document Quality

The HELD extensions described in this document are simple to read and
understand. Multiple revisions of this document have made for a
straightforward but comprehensive discussion of relevant security and
privacy issues.
2010-06-22
06 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2010-06-22
06 Amy Vezza [Note]: 'The Document Shepherd for this document is Alissa Cooper (acooper@cdt.org).' added by Amy Vezza
2010-06-21
04 (System) New version available: draft-ietf-geopriv-held-identity-extensions-04.txt
2010-02-24
03 (System) New version available: draft-ietf-geopriv-held-identity-extensions-03.txt
2009-12-09
02 (System) New version available: draft-ietf-geopriv-held-identity-extensions-02.txt
2009-10-22
06 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Donald Eastlake.
2009-10-19
01 (System) New version available: draft-ietf-geopriv-held-identity-extensions-01.txt
2009-09-18
06 Samuel Weiler Request for Early review by SECDIR is assigned to Donald Eastlake
2009-09-18
06 Samuel Weiler Request for Early review by SECDIR is assigned to Donald Eastlake
2009-09-07
00 (System) New version available: draft-ietf-geopriv-held-identity-extensions-00.txt