GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6155

Internet Engineering Task Force (IETF) J. Winterbottom Request for Comments: 6155 M. Thomson Category: Standards Track Andrew Corporation ISSN: 2070-1721 H. Tschofenig

                                                Nokia Siemens Networks
                                                             R. Barnes
                                                      BBN Technologies
                                                            March 2011
  Use of Device Identity in HTTP-Enabled Location Delivery (HELD)

Abstract

 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.  This is sufficient in environments
 where the location of a Device can be determined based on its IP
 address.
 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.
 This document extends the HELD protocol to allow the location request
 message to carry Device identifiers.  Privacy and security
 considerations describe the conditions where requests containing
 identifiers are permitted.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6155.

Winterbottom, et al. Standards Track [Page 1] RFC 6155 HELD Identity March 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Winterbottom, et al. Standards Track [Page 2] RFC 6155 HELD Identity March 2011

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1.  Applications . . . . . . . . . . . . . . . . . . . . . . .  5
   1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
 2.  Device Identity  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.1.  Identifier Suitability . . . . . . . . . . . . . . . . . .  7
     2.1.1.  Subjective Network Views . . . . . . . . . . . . . . .  7
     2.1.2.  Transient Identifiers  . . . . . . . . . . . . . . . .  9
     2.1.3.  Network Interfaces and Devices . . . . . . . . . . . .  9
   2.2.  Identifier Format and Protocol Details . . . . . . . . . .  9
 3.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.1.  IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
   3.2.  MAC Address  . . . . . . . . . . . . . . . . . . . . . . . 11
   3.3.  Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
   3.4.  Network Access Identifier  . . . . . . . . . . . . . . . . 12
     3.4.1.  Using NAI for Location Configuration . . . . . . . . . 13
   3.5.  URI  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   3.6.  Fully Qualified Domain Name  . . . . . . . . . . . . . . . 14
   3.7.  Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
   3.8.  DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 15
 4.  Privacy Considerations . . . . . . . . . . . . . . . . . . . . 15
   4.1.  Targets Requesting Their Own Location  . . . . . . . . . . 16
   4.2.  Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   5.1.  Identifier Suitability . . . . . . . . . . . . . . . . . . 18
   5.2.  Targets Requesting Their Own Location  . . . . . . . . . . 18
   5.3.  Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
 6.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19
 7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   7.1.  URN Sub-Namespace Registration for
         urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 21
   7.2.  XML Schema Registration  . . . . . . . . . . . . . . . . . 22
   7.3.  Registration of HELD 'badIdentifier' Error Code  . . . . . 22
 8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 25

Winterbottom, et al. Standards Track [Page 3] RFC 6155 HELD Identity March 2011

1. Introduction

 Protocols for requesting and providing location information require a
 way for the requestor to specify the location that should be
 returned.  In a Location Configuration Protocol (LCP), the location
 being requested is the requestor's location.  This fact can make the
 problem of identifying the Device simple, since IP datagrams that
 carry the request already carry an identifier for the Device --
 namely, the source IP address of an incoming request.  Existing LCPs,
 such as HTTP-Enabled Location Delivery (HELD) [RFC5985] and DHCP
 ([RFC3825], [RFC4776]) rely on the source IP address or other
 information present in protocol datagrams to identify a Device.
 Aside from the datagrams that form a request, a Location Information
 Server (LIS) does not necessarily have access to information that
 could further identify the Device.  In some circumstances, as shown
 in [RFC5687], additional identification information can be included
 in a request to identify a Device.
 This document extends the HELD protocol to support the inclusion of
 additional identifiers for the Device in HELD location requests.  An
 XML schema is defined that provides a structure for including these
 identifiers in HELD requests.
 An important characteristic of this addition is that the HELD
 protocol with identity extensions implemented is not considered an
 LCP.  The scope of an LCP is limited to the interaction between a
 Device and a LIS, and LCPs can guarantee the identity of Devices
 without additional authorization checks.  A LIS identifies the Device
 making the LCP request using the source addressing on the request
 packets, using return routability to ensure that these identifiers
 are not spoofed.
 HELD with identity extensions allows a requestor to explicitly
 provide identification details in the body of a location request.
 This means that location requests can be made in cases where
 additional Device identity checks are necessary, and in cases where
 the requestor is not the Device itself.  Third-party Location
 Recipients (LRs) are able to make requests that include identifiers
 to retrieve location information about a particular Device.
 The usage of identifiers in HELD introduces a new set of privacy
 concerns.  In an LCP, the requestor can be implicitly authorized to
 access the requested location information, because it is their own
 location.  In contrast, a third-party LR must be explicitly
 authorized when requesting the location of a Device.  Establishing
 appropriate authorization and other related privacy concerns are
 discussed in Section 4.

Winterbottom, et al. Standards Track [Page 4] RFC 6155 HELD Identity March 2011

1.1. Applications

 This document defines a means to explicitly include Device identity
 information in the body of a HELD location request.  This identity
 information is used to identify the Device that is the subject (or
 Target) of the location request.  If Device identity is present, the
 identity of the requestor in the form of the source IP address is not
 used to identify the subject of the request.
 Device identifiers in HELD can be used for two purposes:
 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
    this policy unless specific measures are taken to prevent this
    type of attack.
    This document describes a mechanism that provides assurances that
    the requestor and included Device identity are the same for the
    Network Access Identifier (NAI) in a WiMAX network.  The LIS MUST
    treat requests containing other identifiers as third-party
    requests, unless it is able to ensure that the provided Device
    identity is uniquely attributable to the requestor.
 Third-party requests:  A third-party Location Recipient can be
    granted authorization to make requests for a given Device.  In
    particular, network services can be permitted to retrieve location
    for a Device that is unable to acquire location information for
    itself (see Section 6.3 of [EMERGENCY-CALLING]).  This allows use
    of location-dependent applications -- particularly essential
    services like emergency calling -- where Devices do not support a
    location configuration protocol or they are unable to successfully
    retrieve location information.
    This document does not describe how a third party acquires an
    identifier for a Device, nor how that third party is authorized by
    a LIS.  It is critical that these issues are resolved before
    permitting a third-party request.  A pre-arranged contract between
    the third party, a Rule Maker, and the LIS operator is necessary
    to use Device identifiers in this fashion.  This contract must

Winterbottom, et al. Standards Track [Page 5] RFC 6155 HELD Identity March 2011

    include how the request is authenticated and the set of
    identifiers (and types of identifiers) that the third party is
    authorized to use in requests.
    Automated mechanisms to ensure that privacy constraints are
    respected are possible.  For instance, a policy rules document
    could be used to express the agreed policy.  Formal policy
    documents, such as the common policy [RFC4745], can be applied in
    an automated fashion by a LIS.

1.2. Terminology

 This document uses the term Location Information Server (LIS) and
 Location Configuration Protocol (LCP) as described in [RFC5687] and
 [GEOPRIV-ARCH].
 The term Device is used specifically as the subject of an LCP,
 consistent with [RFC5985].  This document also uses the term Target
 to refer to any entity that might be a subject of the same location
 information.  Target is used in a more general sense, including the
 Device, but also any nearby entity, such as the user of a Device.
 A Target has a stake in setting authorization policy on the use of
 location information.  A Rule Maker is the term used for the role
 that makes policy decisions about authorization, determining what
 entities are permitted to receive location and how that information
 is provided.
 Device, Target, and Rule Maker are defined in [GEOPRIV-ARCH].
 The term "requestor" is used in this document to refer to the entity
 making a HELD request.
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

2. Device Identity

 Identifiers are used as the starting point in location determination.
 Identifiers might be associated with a different Device over time,
 but their purpose is to identify the Device, not to describe its
 environment or network attachment.

Winterbottom, et al. Standards Track [Page 6] RFC 6155 HELD Identity March 2011

2.1. Identifier Suitability

 Use of any identifier MUST only be allowed if it identifies a single
 Device at the time that location is determined.  The LIS is
 responsible for ensuring that location information is correct for the
 Device, which includes ensuring that the identifier is uniquely
 attributable to the Device.
 Some identifiers can be either temporary or could potentially
 identify multiple Devices.  Identifiers that are transient or
 ambiguous could be exploited by an attacker to either gain
 information about another Device or to coerce the LIS into producing
 misleading information.
 The identifiers described in this document MUST only be used where
 that identifier is used as the basis for location determination.
 Considerations relating to the use of identifiers for a Device
 requesting its own location are discussed in Section 5 of [RFC5687];
 this section discusses use of identifiers for authorized third-party
 requests.
    It is tempting for a LIS implementation to allow alternative
    identifiers for convenience or some other perceived benefit.  The
    LIS is responsible for ensuring that the identifier used in the
    request does not refer to a Device other than the one for which it
    determines location.
 Some identifiers are always uniquely attributable to a single Device.
 However, other identifiers can have a different meaning to different
 entities on a network.  This is especially true for IP addresses
 [RFC2101], but this can be true for other identifiers to varying
 degrees.  Non-uniqueness arises from both topology (all network
 entities have a subjective view of the network) and time (the network
 changes over time).

2.1.1. Subjective Network Views

 Subjective views of the network mean that the identifier a requestor
 uses to refer to one physical entity could actually apply to a
 different physical entity when used in a different network context.
 Unless an authorized third-party requestor and LIS operate in the
 same network context, each could have a different subjective view of
 the meaning of the identifier.

Winterbottom, et al. Standards Track [Page 7] RFC 6155 HELD Identity March 2011

 Where subjective views differ, the third party receives information
 that is correct only within the network context of the LIS.  The
 location information provided by the LIS is probably misleading: the
 requestor believes that the information relates to a different entity
 than it was generated for.
 Authorization policy can be affected by a subjective network view if
 it is applied based on an identifier or if its application depends on
 identifiers.  The subjective view presented to the LIS and Rule Maker
 need to agree for the two entities to understand policy on the same
 terms.  For instance, it is possible that the LIS could apply the
 incorrect authorization policy if it selects the policy using a
 subjective identifier.  Alternatively, it may use the correct policy
 but apply it incorrectly if subjective identifiers are used.
    In IP networks, network address translation (NAT) and other forms
    of address modification create network contexts.  Entities on
    either side of the point where modification occurs have a
    different view of the network.  Private use addresses [RFC1918]
    are the most easily recognizable identifiers that have limited
    scope.
 A LIS can be configured to recognize scenarios where the subjective
 view of a requestor or Rule Maker might not coincide with the view of
 the LIS.  The LIS can either provide location information that takes
 the view of the requestor into account, or it can reject the request.
    For instance, a LIS might operate within a network that uses a
    private address space, with NAT between that network and other
    networks.  A third-party request that originates in an external
    network with an IP address from the private address space might
    not be valid -- it could be identifying an entity within another
    address space.  The LIS can be configured to reject such requests,
    unless it knows by other means that the request is valid.
    In the same example, the requestor might include an address from
    the external space in an attempt to identify a host within the
    network.  The LIS could use knowledge about how the external
    address is mapped to a private address, if that mapping is fixed,
    to determine an appropriate response.
 The residential gateway scenario in Section 3.1 of [RFC5687] is a
 particular example of where a subjective view is permitted.  The LIS
 knowingly provides Devices on the remote side of the residential
 gateway with location information.  The LIS provides location
 information with appropriate uncertainty to allow for the fact that
 the residential gateway serves a small geographical area.

Winterbottom, et al. Standards Track [Page 8] RFC 6155 HELD Identity March 2011

2.1.2. Transient Identifiers

 Some identifiers are temporary and can, over the course of time, be
 assigned to different physical entities.  An identifier that is
 reassigned between the time that a request is formulated by a
 requestor and when the request is received by the LIS causes the LIS
 to locate a different entity than the requestor intended.  The
 response from the LIS might be accurate, but the request incorrectly
 associates this information with the wrong subject.
 A LIS should be configured with information about any potentially
 temporary identifiers.  It can use this information to identify when
 changes have occurred.  A LIS must not provide location information
 if the identifier it uses might refer to a different Device.  If an
 identifier might have been reassigned recently, or it is likely to be
 reassigned, it is not suitable as an identifier.
 It's possible that some degree of uncertainty could persist where
 identifiers are reassigned frequently; the extent to which errors
 arising from using transient identifiers are tolerated is a matter
 for local policy.

2.1.3. Network Interfaces and Devices

 Several of the identifiers in this document are used to identify a
 network interface.  A Device can have multiple network interfaces.
 Uniquely identifying any network interface is assumed to be
 sufficient to identify the Device.  When a network interface is
 identified, the goal is to identify the Device that is immediately
 attached to the network interface.
 Most network interfaces remain physically attached to a particular
 Device, though a network interface might be physically separable from
 the Device.  By identifying a network interface, any Device that is
 intended to be identified could change.

2.2. Identifier Format and Protocol Details

 XML elements are used to express the Device identity.  The "device"
 element is used as a general container for identity information.
 This document defines a basic set of identifiers.  An example HELD
 request, shown in Figure 1, includes an IP version 4 address.

Winterbottom, et al. Standards Track [Page 9] RFC 6155 HELD Identity March 2011

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="8">
     <locationType exact="true">geodetic</locationType>
     <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="4">192.0.2.5</ip>
     </device>
   </locationRequest>
              Figure 1: HELD Request with Device Identity
 A LIS that supports this specification echoes the "device" element in
 a successful HELD response, including the identifiers that were used
 as the basis for location determination.  Absence of this indication
 means that the location information was generated using the source IP
 address in the request.
 A "badIdentifier" HELD error code indicates that the requestor is not
 authorized to use that identifier or that the request contains an
 identifier that is badly formatted or not supported by the LIS.  This
 code is registered in Section 7.3.
 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
 requestor needs to include a media access control (MAC) address
 (Section 3.2) and IP address (Section 3.1) if the request is to
 succeed.
   <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 ip
     </requiredIdentifiers>
   </error>
          Figure 2: HELD Error Requesting Device Identifiers

Winterbottom, et al. Standards Track [Page 10] RFC 6155 HELD Identity March 2011

3. Identifiers

 A limited selection of identifiers are included in this document.
 The basic Device identity schema allows for the inclusion of elements
 from any namespace; therefore, additional elements can be defined
 using different XML namespaces.

3.1. IP Address

 The "ip" element can express a Device identity as an IP address
 ([RFC0791], [RFC4291]).  The "v" attribute identifies the IP version
 with a single hexadecimal digit.  The element uses the textual format
 specific to the indicated IP version.  The textual format for IP
 version 4 and version 6 addresses MUST conform to the grammar defined
 in [RFC3986] ("IPv4address" and "IPv6address", respectively).  IP
 version 6 addresses SHOULD conform to the formatting conventions in
 [RFC5952].
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <ip v="6">2001:db8::1:ea7:fee1:d1e</ip>
   </device>
 In situations where location configuration does not require
 additional identifiers, using an IP address as an identifier enables
 authorized third-party requests.

3.2. MAC Address

 The MAC address used by network interfaces attached to the IEEE LAN
 [IEEE802].  A MAC address is a unique sequence that is either
 assigned at the time of manufacture of the interface, or assigned by
 a local administrator.  A MAC address is an appropriate identifier
 for the Device that uses the network interface as long as the two
 remain together (see Section 2.1.3).
 A MAC address can be represented as a MAC-48, EUI-48, or EUI-64
 address ([IEEE802], or an extended unique identifier [EUI64]) using
 the hexadecimal representation defined in [IEEE802].
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <mac>A0-12-34-56-78-90</mac>
   </device>
 A locally assigned MAC address is not guaranteed to be unique outside
 the administrative domain where it is assigned.  Locally assigned MAC
 addresses can only be used within this domain.

Winterbottom, et al. Standards Track [Page 11] RFC 6155 HELD Identity March 2011

3.3. Port Numbers

 A host might only be known by a flow of packets that it is sending or
 receiving.  On its own, a port number is insufficient to uniquely
 identify a single host.  In combination with an IP address, a port
 number can be used to uniquely identify a Device in some
 circumstances.
 Use of a particular port number can be transient; often significantly
 more than use of any given IP address.  However, widespread use of
 network address translation (NAT) means that some Devices cannot be
 uniquely identified by IP address alone.  An individual Device might
 be identified by a flow of packets that it generates.  Providing that
 a LIS has sufficient knowledge of the mappings used by the NAT, an
 individual target on the remote side of the NAT might be able to be
 identified uniquely.
 Port numbers are defined for UDP [RFC0768], TCP [RFC0793], SCTP
 [RFC4960], and DCCP [RFC4340].
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <ip v="4">192.0.2.75</ip>
     <udpport>51393</udpport>
   </device>
 Use of port numbers is especially reliant on the value remaining
 consistent over time.

3.4. Network Access Identifier

 A Network Access Identifier (NAI) [RFC4282] is an identifier used in
 network authentication in a range of networks.  The identifier
 establishes a user identity within a particular domain.  Often,
 network services use an NAI in relation to location records, tying
 network access to user authentication and authorization.
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <nai>user@example.net</nai>
   </device>
 The formal grammar for NAI [RFC4282] permits sequences of octets that
 are not valid UTF-8 [RFC3629] sequences.  These sequences cannot be
 expressed using XML.  Therefore, this expression of NAI permits
 escaping.  Sequences of octets that do not represent a valid UTF-8
 encoding can be expressed using a backslash ('\') followed by two
 case-insensitive hexadecimal digits representing the value of a
 single octet.

Winterbottom, et al. Standards Track [Page 12] RFC 6155 HELD Identity March 2011

 The canonical representation of an NAI is the sequence of octets that
 is produced from the concatenation of UTF-8 encoded sequences of
 unescaped characters and octets derived from escaped components.  The
 resulting sequence of octets MUST conform to the constraints in
 [RFC4282].
 For example, the NAI "f<U+FC>\<0xFF>@bar.com" that includes the UTF-8
 encoded u-umlaut character (U+FC) and an invalid UTF-8 octet (0xFF)
 might be represented as "f\c3\bc\5c\90@bar.com", though the u-umlaut
 character might be included directly.

3.4.1. Using NAI for Location Configuration

 An NAI in WiMAX is uniquely attributable to a single Device at any
 one time.  An NAI either identifies a Device or a service
 subscription, neither of which can have multiple active sessions.
 In a WiMAX network, an IP address is not sufficient information for a
 LIS to locate a Device.  The following procedure relies on an NAI to
 identify the Device.  This procedure and the messages and parameters
 is relies upon are defined in [WiMAX-T33-110-R015v01-B].
 Location requests in a WiMAX network always require the inclusion of
 an NAI.  However, if a LIS receives a request that does not come from
 an authenticated and authorized third-party requestor, it can treat
 this request as a location configuration request.
 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
 containing the NAI.
 The AAA server consults network policy, and if the request is
 permitted, the response includes the IP address that is currently
 assigned to the Device.  If this IP address matches the source IP
 address of the HELD location request, the location request can be
 authorized under the LCP policy (see Section 4.1).  Otherwise, the
 request must be treated as a third-party request.
 This relies on the same protections against IP address spoofing that
 are required by [RFC5985].  In addition, the request made of the AAA
 uses either Diameter [RFC3588] or RADIUS [RFC2865], and therefore
 relies on the protections provided by those protocols.  In order to
 rely on the access request, the AAA server MUST be authenticated to
 be a trusted entity for the purpose of providing a link between the

Winterbottom, et al. Standards Track [Page 13] RFC 6155 HELD Identity March 2011

 NAI and IP address.  The AAA protocol MUST also provide protection
 from modification and replay attacks to ensure that data cannot be
 altered by an attacker.

3.5. URI

 A Device can be identified by a URI [RFC3986].  Any URI can be used
 providing that the requestor and LIS have a common understanding of
 the semantics implied by use of the URI.
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <uri>sip:user@example.net;gr=kjh29x97us97d</uri>
   </device>
 Particular care needs to be taken in ensuring that a particular URI
 only refers to a single Device.  In many cases, a URI can resolve to
 multiple destinations.  For example, a SIP address of record URI can
 correspond to a service subscription rather than a single Device.
 A "tel:" URI [RFC3966] can be used to identify a Device by telephone
 number:
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
   </device>

3.6. Fully Qualified Domain Name

 A fully qualified domain name can be used as the basis for
 identification using the "fqdn" element.
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <fqdn>host.example.net</fqdn>
   </device>
 This domain name slot, which is aware of Internationalized Domain
 Names for Applications (IDNA) [RFC5890], is formed from any sequence
 of valid U-labels or NR-LDH-labels.
 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.

3.7. Cellular Telephony Identifiers

 A range of different forms of mobile station identifiers are used for
 different cellular telephony systems.  Elements are defined for these
 identifiers.  The following identifiers are defined:

Winterbottom, et al. Standards Track [Page 14] RFC 6155 HELD Identity March 2011

 msisdn:  The Mobile Station International Subscriber Dial Number
    (MSISDN) [E.213] is an E.164 number [E.164] between 6 and 15
    digits long.
 imsi:  The International Mobile Subscriber Identity (IMSI)
    [TS.3GPP.23.003] is an identifier associated with all GSM (Global
    System for Mobile Communications) and UMTS (Universal Mobile
    Telecommunications System) mobile subscribers between 6 and 15
    digits in length.
 imei:  The International Mobile Equipment Identifier (IMEI)
    [TS.3GPP.23.003] is a unique device serial number up to 15 digits
    long.
 min:  The Mobile Identification Number (MIN) [TIA.EIA.IS-2000-6] is a
    10-digit unique number assigned to CDMA handsets.
 mdn:  The Mobile Directory Number (MDN) is an E.164 number [E.164],
    with usage similar to MSISDN.
 Each identifier contains a string of decimal digits with a length as
 specified.
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <msisdn>11235550123</msisdn>
   </device>

3.8. DHCP Unique Identifier

 The Dynamic Host Configuration Protocol (DHCP) uses a binary
 identifier for its clients.  The DHCP Unique Identifier (DUID) is
 expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
 DHCPv6 and follows the format defined in Section 9 of [RFC3315].  The
 "duid" element includes the binary value of the DUID expressed in
 hexadecimal.
   <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <duid>1234567890AaBbCcDdEeFf</duid>
   </device>

4. Privacy Considerations

 Location configuration protocols can make use of an authorization
 model known as "LCP policy", which permits only Targets to be the
 recipients of their own locations.  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.

Winterbottom, et al. Standards Track [Page 15] RFC 6155 HELD Identity March 2011

 The security and privacy considerations of the base HELD protocol
 [RFC5985] are applicable.  However, the considerations relating to
 return routability do not apply to third-party requests.  Return
 routability may also not apply to requests from Targets for their own
 location, depending on the anti-spoofing mechanisms employed for the
 identifier.

4.1. Targets Requesting Their Own Location

 When a Target uses identity extensions to obtain its own location,
 HELD can no longer be considered an LCP.  The authorization policy
 that the LIS uses to respond to these requests must be provisioned by
 one or more Rule Makers.
 In the case that the LIS exclusively provides Targets with their own
 locations, the LIS can still be said to be following the "LCP
 policy".  The "LCP policy" concept and further security and privacy
 considerations can be found in [GEOPRIV-ARCH].
 The spoofing protections provided when using HELD with identity
 extensions to provide Targets with their own locations differ from
 the protections inherent in an LCP.  For an LCP, return routability
 is considered sufficient protection against spoofing.  For a similar
 policy to be used, specific measures MUST be defined to protect
 against spoofing of the alternative identifier.  This document
 defines this for an NAI when used in WiMAX networks (see
 Section 3.4.1), but for no other identifier.
 A Rule Maker might require an assurance that the identifier is owned
 by the requestor.  Any multi-stage verification process that includes
 a return routability test cannot provide any stronger assurance than
 return routability alone; therefore, policy might require the use of
 additional, independent methods of verification.
 Care is required where a direct one-to-one relationship between
 requestor and Device identity does not exist.  If identifiers are not
 uniquely attributable to a single Device, the use of HELD identity
 extensions to provide Targets with their own locations could be
 exploited by an attacker.
    It might be possible in some networks to establish multiple
    concurrent sessions using the same credentials.  For instance,
    Devices with different MAC addresses might be granted concurrent
    access to a network using the same NAI.  It is not appropriate to
    provide Targets with their own locations based on the NAI in this
    case.  Neither is it appropriate to authenticate a Device using
    NAI and allow that Device to provide an unauthenticated MAC
    address as a Device identifier, even if the MAC address is

Winterbottom, et al. Standards Track [Page 16] RFC 6155 HELD Identity March 2011

    registered to the NAI.  The MAC address potentially identifies a
    different Device than the one that is making the request.  The
    correct way of gaining authorization is to establish a policy that
    permits this particular request as a third-party request.
 Section 3.4.1 discusses the implications of using an NAI as an
 identifier for location requests made of a LIS serving a WiMAX
 network.  Additional security considerations are discussed in
 [WiMAX-T33-110-R015v01-B].

4.2. Third-Party Requests

 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.  The LIS MUST
 also authenticate requestors according to any agreed-upon
 authorization policy.
 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.  As the Target is a
 potential Rule Maker, this presents a problem.  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] and [RFC4825]).  This document does not mandate any
 particular mechanism for establishing an authorization policy.

5. Security Considerations

 The security considerations in [RFC5985] describe the use of
 Transport Layer Security (TLS) [RFC5246] for server authentication,
 confidentiality, and protection from modification.  These protections
 apply to both Target requests for their own locations and requests
 made by third parties.

Winterbottom, et al. Standards Track [Page 17] RFC 6155 HELD Identity March 2011

 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 requestor 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 requestor 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.
 HELD [RFC5985] does not mandate that Devices implement
 authentication.  A LIS SHOULD NOT send a HTTP 401 response if the
 Device does not include Device identity.

5.1. Identifier Suitability

 Transient and ambiguous identifiers can be exploited by malicious
 requests and are not suitable as a basis for identifying a Device.
 Section 2.1 provides further discussion on this subject.
 Identifier transience can lead to incorrect location information
 being provided.  An attacker could exploit the use of transient
 identifiers.  In this attack, the attacker either knows of a
 re-allocation of that identifier or is able to force the identifier
 to be re-allocated during the processing of the request.
 An attacker could use this to acquire location information for
 another Device or to coerce the LIS to lie on its behalf if this
 re-allocation occurs between the time where authorization is granted
 and location information is granted.
 Ambiguous identifiers present a similar problem.  An attacker could
 legitimately gain authorization to use a particular identifier.
 Since an ambiguous identifier potentially refers to multiple Devices,
 if authorization is granted for one of those Devices, an attacker
 potentially gains access to location information for all of those
 Devices.

5.2. Targets Requesting Their Own Location

 Requests made by a Device for its own location are covered by the
 same set of protections offered by HELD.  These requests might be
 authorized under a policy similar to the "LCP policy" that permits a
 Target access to location information about itself.

Winterbottom, et al. Standards Track [Page 18] RFC 6155 HELD Identity March 2011

 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.

5.3. Third-Party Requests

 Requests from third parties have the same requirements for server
 authentication, confidentiality, and protection from modification as
 Target requests for their own locations.  However, because the third
 party needs to be authorized, the requestor MUST be authenticated by
 the LIS.  In addition, third-party requests MUST be explicitly
 authorized by a policy that is established by a Rule Maker.
 More detail on the privacy implications of third-party requests are
 covered in Section 4.

6. XML Schema

 <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
   <xs:annotation>
     <xs:appinfo
         source="urn:ietf:params:xml:schema:geopriv:held:id">
       HELD Device Identity
     </xs:appinfo>
     <xs:documentation
         source="http://www.rfc-editor.org/rfc/rfc6155.txt">
       This document defines Device identity elements for HELD.
     </xs:documentation>
   </xs:annotation>
   <xs:element name="device" type="id:deviceIdentity"/>
   <xs:complexType name="deviceIdentity">
     <xs:sequence>
       <xs:any namespace="##any" processContents="lax"
               minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>
   <xs:element name="requiredIdentifiers" type="id:qnameList"/>

Winterbottom, et al. Standards Track [Page 19] RFC 6155 HELD Identity March 2011

   <xs:simpleType name="qnameList">
     <xs:list itemType="xs:QName"/>
   </xs:simpleType>
   <xs:element name="ip" type="id:ipAddress"/>
   <xs:complexType name="ipAddress">
     <xs:simpleContent>
       <xs:extension base="xs:token">
         <xs:attribute name="v" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:token">
               <xs:pattern value="[\da-fA-F]"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:extension>
     </xs:simpleContent>
   </xs:complexType>
   <xs:element name="mac" type="id:macAddress"/>
   <xs:simpleType name="macAddress">
     <xs:restriction base="xs:token">
       <xs:pattern
   value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:element name="udpport" type="id:portNumber"/>
   <xs:element name="tcpport" type="id:portNumber"/>
   <xs:element name="sctpport" type="id:portNumber"/>
   <xs:element name="dccpport" type="id:portNumber"/>
   <xs:simpleType name="portNumber">
     <xs:restriction base="xs:nonNegativeInteger">
       <xs:maxInclusive value="65535"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:element name="nai" type="id:naiType"/>
   <xs:simpleType name="naiType">
     <xs:restriction base="xs:token">
       <xs:pattern
           value="([^\\]|\\[\dA-Fa-f]{2})*
                  (@([A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*\.)+
                   [A-Za-z\d]([A-Za-z\d\-]*[A-Za-z\d])*)?"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:element name="uri" type="xs:anyURI"/>

Winterbottom, et al. Standards Track [Page 20] RFC 6155 HELD Identity March 2011

   <xs:element name="fqdn" type="xs:token"/>
   <xs:element name="duid" type="xs:hexBinary"/>
   <xs:element name="msisdn" type="id:e164"/>
   <xs:element name="imsi" type="id:e164"/>
   <xs:element name="imei" type="id:digit15"/>
   <xs:element name="min" type="id:digit10"/>
   <xs:element name="mdn" type="id:e164"/>
   <xs:simpleType name="digits">
     <xs:restriction base="xs:token">
       <xs:pattern value="[\d]+"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="e164">
     <xs:restriction base="id:digit15">
       <xs:minLength value="6"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="digit15">
     <xs:restriction base="id:digits">
       <xs:maxLength value="15"/>
     </xs:restriction>
   </xs:simpleType>
   <xs:simpleType name="digit10">
     <xs:restriction base="id:digits">
       <xs:length value="10"/>
     </xs:restriction>
   </xs:simpleType>
 </xs:schema>

7. IANA Considerations

 This document registers an XML namespace and schema with IANA in
 accordance with guidelines in [RFC3688].

7.1. URN Sub-Namespace Registration for

    urn:ietf:params:xml:ns:geopriv:held:id
 This section registers a new XML namespace,
 "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
 [RFC3688].
 URI: urn:ietf:params:xml:ns:geopriv:held:id
 Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
    James Winterbottom (james.winterbottom@andrew.com).

Winterbottom, et al. Standards Track [Page 21] RFC 6155 HELD Identity March 2011

 XML:
 BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     <head>
       <title>HELD Device Identity Parameters</title>
     </head>
     <body>
       <h1>Namespace for HELD Device Identity Parameters</h1>
       <h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
       <p>See <a href="http://www.rfc-editor.org/rfc/rfc6155.txt">
          RFC 6155</a>.</p>
     </body>
   </html>
 END

7.2. XML Schema Registration

 This section registers an XML schema as per the guidelines in
 [RFC3688].
 URI:  urn:ietf:params:xml:schema:geopriv:held:id
 Registrant Contact:  IETF, GEOPRIV working group (geopriv@ietf.org),
    James Winterbottom (james.winterbottom@andrew.com).
 Schema:  The XML for this schema can be found as the entirety of
    Section 6 of this document.

7.3. Registration of HELD 'badIdentifier' Error Code

 This section registers the "badIdentifier" error code in the IANA
 maintained "HELD Error Codes" sub-registry of the "Geopriv HTTP
 Enabled Location Delivery (HELD) Parameters" registry.
 badIdentifier  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 requestor was authorized
    to make a request.

8. Acknowledgements

 The National Emergency Number Association (NENA) VoIP location
 working group provided assistance in the definition of the schema
 used in this document.  Special thanks go to Barbara Stark, Guy

Winterbottom, et al. Standards Track [Page 22] RFC 6155 HELD Identity March 2011

 Caron, Nadine Abbott, Jerome Grenier, and Martin Dawson.  Bob Sherry
 provided input on use of URIs.  Thanks to Adam Muhlbauer and Eddy
 Corbett for providing further corrections.  Bernard Aboba provided
 excellent feedback on use cases and the security model; Bernard,
 along with Alan DeKok, also helped resolve an issue with NAIs.  Ray
 Bellis provided motivation for the protocol port parameters.  Marc
 Linsner and Alissa Cooper provided guidance and text (respectively)
 that greatly clarified the discussion relating to LCPs.  Thanks to
 Jon Peterson and Cullen Jennings for forcing this to be practical.

9. References

9.1. Normative References

 [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.
 [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
            September 1981.
 [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
            RFC 793, September 1981.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
            Leach, P., Luotonen, A., and L. Stewart, "HTTP
            Authentication: Basic and Digest Access Authentication",
            RFC 2617, June 1999.
 [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
            "Remote Authentication Dial In User Service (RADIUS)",
            RFC 2865, June 2000.
 [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
            and M. Carney, "Dynamic Host Configuration Protocol for
            IPv6 (DHCPv6)", RFC 3315, July 2003.
 [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
            Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
            10646", STD 63, RFC 3629, November 2003.
 [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
            January 2004.

Winterbottom, et al. Standards Track [Page 23] RFC 6155 HELD Identity March 2011

 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66,
            RFC 3986, January 2005.
 [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
            Network Access Identifier", RFC 4282, December 2005.
 [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.
 [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
            Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
 [RFC4361]  Lemon, T. and B. Sommerfeld, "Node-specific Client
            Identifiers for Dynamic Host Configuration Protocol
            Version Four (DHCPv4)", RFC 4361, February 2006.
 [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
            RFC 4960, September 2007.
 [RFC5890]  Klensin, J., "Internationalized Domain Names for
            Applications (IDNA): Definitions and Document Framework",
            RFC 5890, August 2010.
 [RFC5985]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
            RFC 5985, September 2010.
 [W3C.REC-xml-names11-20060816]
            Hollander, D., Tobin, R., Layman, A., and T. Bray,
            "Namespaces in XML 1.1 (Second Edition)", World Wide Web
            Consortium Recommendation REC-xml-names11-20060816,
            August 2006,
            <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
 [IEEE802]  IEEE, "IEEE Standard for Local and Metropolitan Area
            Networks: Overview and Architecture", IEEE 802,
            February 2002.
 [EUI64]    IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
            Registration Authority", March 1997,
            <http://standards.ieee.org/regauth/oui/tutorials/
            EUI64.html>.
 [E.164]    ITU-T, "E.164 : The international public telecommunication
            numbering plan", ITU-T Recommendation E.164,
            February 2005,
            <http://www.itu.int/rec/T-REC-E.164-200502-I/en>.

Winterbottom, et al. Standards Track [Page 24] RFC 6155 HELD Identity March 2011

 [E.213]    ITU-T, "E.213 : Telephone and ISDN numbering plan for land
            mobile stations in public land mobile networks (PLMN)",
            ITU-T Recommendation E.213, November 1988,
            <http://www.itu.int/rec/T-REC-E.213-198811-I/en>.
 [TS.3GPP.23.003]
            3GPP, "Numbering, addressing and identification", 3GPP
            TS 23.003 9.4.0, September 2010,
            <http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
 [TIA.EIA.IS-2000-6]
            TIA/EIA, "Analog Signaling Standard for CDMA 2000 Spread
            Spectrum Systems",  TIA/EIA/IS-2000-6-C, May 2002.
 [WiMAX-T33-110-R015v01-B]
            WiMAX Forum, "Protocols and Procedures for Location Based
            Services", WiMAX Forum Network Architecture T33-110-
            R015v01-B, May 2009.
 [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
            Address Text Representation", RFC 5952, August 2010.

9.2. Informative References

 [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
            E. Lear, "Address Allocation for Private Internets",
            BCP 5, RFC 1918, February 1996.
 [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
            Address Behaviour Today", RFC 2101, February 1997.
 [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
            Configuration Protocol Option for Coordinate-based
            Location Configuration Information", RFC 3825, July 2004.
 [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
            RFC 3966, December 2004.
 [RFC4745]  Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
            Polk, J., and J. Rosenberg, "Common Policy: A Document
            Format for Expressing Privacy Preferences", RFC 4745,
            February 2007.
 [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
            (DHCPv4 and DHCPv6) Option for Civic Addresses
            Configuration Information", RFC 4776, November 2006.

Winterbottom, et al. Standards Track [Page 25] RFC 6155 HELD Identity March 2011

 [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
            Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
 [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
            (TLS) Protocol Version 1.2", RFC 5246, August 2008.
 [RFC5687]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
            Location Configuration Protocol: Problem Statement and
            Requirements", RFC 5687, March 2010.
 [GEOPRIV-ARCH]
            Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
            Tschofenig, H., and H. Schulzrinne, "An Architecture for
            Location and Location Privacy in Internet Applications",
            Work in Progress, October 2010.
 [EMERGENCY-CALLING]
            Rosen, B. and J. Polk, "Best Current Practice for
            Communications Services in support of Emergency Calling",
            Work in Progress, October 2010.

Winterbottom, et al. Standards Track [Page 26] RFC 6155 HELD Identity March 2011

Authors' Addresses

 James Winterbottom
 Andrew Corporation
 Andrew Building (39)
 Wollongong University Campus
 Northfields Avenue
 Wollongong, NSW  2522
 AU
 Phone: +61 2 4221 2938
 EMail: james.winterbottom@andrew.com
 Martin Thomson
 Andrew Corporation
 Andrew Building (39)
 Wollongong University Campus
 Northfields Avenue
 Wollongong, NSW  2522
 AU
 Phone: +61 2 4221 2915
 EMail: martin.thomson@andrew.com
 Hannes Tschofenig
 Nokia Siemens Networks
 Linnoitustie 6
 Espoo  02600
 Finland
 Phone: +358 (50) 4871445
 EMail: Hannes.Tschofenig@gmx.net
 URI:   http://www.tschofenig.priv.at
 Richard Barnes
 BBN Technologies
 9861 Broken Land Pkwy, Suite 400
 Columbia, MD  21046
 USA
 Phone: +1 410 290 6169
 EMail: rbarnes@bbn.com

Winterbottom, et al. Standards Track [Page 27]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6155.txt · Last modified: 2011/03/12 01:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki