< draft-ietf-geopriv-held-identity-extensions-02.txt   draft-ietf-geopriv-held-identity-extensions-03.txt >
Geopriv J. Winterbottom Geopriv J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: Standards Track Andrew Corporation Intended status: Standards Track Andrew Corporation
Expires: June 12, 2010 H. Tschofenig Expires: August 27, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Barnes R. Barnes
BBN Technologies BBN Technologies
December 9, 2009 February 23, 2010
Use of Device Identity in HTTP-Enabled Location Delivery (HELD) Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
draft-ietf-geopriv-held-identity-extensions-02 draft-ietf-geopriv-held-identity-extensions-03
Abstract Abstract
When a Location Information Server receives a request for location When a Location Information Server receives a request for location
information (using the locationRequest message), described in the information (using the locationRequest message), described in the
base HTTP Enabled Location Delivery (HELD) specification, it uses the base HTTP Enabled Location Delivery (HELD) specification, it uses the
source IP address of arriving message as a pointer to the location source IP address of the arriving message as a pointer to the
determination process. This is sufficient in environments where the location determination process. This is sufficient in environments
location of a Device can be determined based on its IP address. where the location of a Device can be determined based on its IP
address.
Two additional use cases are addresses by this document. In the Two additional use cases are addressed by this document. In the
first, location configuration requires additional or alternative first, location configuration requires additional or alternative
identifiers from the source IP address provided in the request. In identifiers from the source IP address provided in the request. In
the second, an entity other than the Device requests the location of the second, an entity other than the Device requests the location of
the Device. the Device.
This document extends the HELD protocol to allow the location request This document extends the HELD protocol to allow the location request
message to carry Device identifiers. Privacy and security message to carry Device identifiers. Privacy and security
considerations describe the conditions where requests containing considerations describe the conditions where requests containing
identifiers are permitted. identifiers are permitted.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 12, 2010. This Internet-Draft will expire on August 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applications . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7 2. Device Identity . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7 2.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 7
3.1.1. Subjective Network Views . . . . . . . . . . . . . . . 7 2.1.1. Subjective Network Views . . . . . . . . . . . . . . . 8
3.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9 2.1.2. Transient Identifiers . . . . . . . . . . . . . . . . 9
3.2. Identifier Format and Protocol Details . . . . . . . . . . 9 2.2. Identifier Format and Protocol Details . . . . . . . . . . 9
4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. IP Address . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11 3.3. TCP or UDP Port Number . . . . . . . . . . . . . . . . . . 11
4.4. Network Access Identifier . . . . . . . . . . . . . . . . 12 3.4. Network Access Identifier . . . . . . . . . . . . . . . . 12
4.4.1. Using NAI for Location Configuration . . . . . . . . . 12 3.4.1. Using NAI for Location Configuration . . . . . . . . . 12
4.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Hostname . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Fully Qualified Domain Name . . . . . . . . . . . . . . . 14
4.7. Directory Number . . . . . . . . . . . . . . . . . . . . . 14 3.7. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14
4.8. Cellular Telephony Identifiers . . . . . . . . . . . . . . 14 3.8. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 14
4.9. DHCP Unique Identifier . . . . . . . . . . . . . . . . . . 14 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 16 4.1. Targets Requesting Their Own Location . . . . . . . . . . 16
5.1. Targets Requesting Their Own Location . . . . . . . . . . 16 4.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17
5.1.1. Security Considerations for NAI use in WiMAX 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Networks . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18
5.2. Third-Party Requests . . . . . . . . . . . . . . . . . . . 17 5.2. Targets Requesting Their Own Location . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19
6.1. Identifier Suitability . . . . . . . . . . . . . . . . . . 18 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Targets Requesting Their Own Location . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
6.3. Third-Party Requests . . . . . . . . . . . . . . . . . . . 19 7.1. URN Sub-Namespace Registration for
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23 urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 23
8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 23
8.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24 7.3. Registration of HELD 'badIdentifier' Error Code . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative references . . . . . . . . . . . . . . . . . . . 26 9.1. Normative references . . . . . . . . . . . . . . . . . . . 26
10.2. Informative references . . . . . . . . . . . . . . . . . . 27 9.2. Informative references . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Protocols for requesting and providing location information require a Protocols for requesting and providing location information require a
way for the requestor to specify the location that should be way for the requestor to specify the location that should be
returned. In a location configuration protocol (LCP), the location returned. In a location configuration protocol (LCP), the location
being requested is the requestor's location. This fact can make the being requested is the requestor's location. This fact can make the
problem of identifying the Device simple, since IP datagrams that problem of identifying the Device simple, since IP datagrams that
carry the request already carry an identifier for the Device, namely carry the request already carry an identifier for the Device, namely
skipping to change at page 4, line 34 skipping to change at page 4, line 34
This document extends the HELD protocol to support the inclusion of This document extends the HELD protocol to support the inclusion of
additional identifiers for the Device in HELD location requests. An additional identifiers for the Device in HELD location requests. An
XML schema is defined that provides a structure for including these XML schema is defined that provides a structure for including these
identifiers in HELD requests. identifiers in HELD requests.
An important characteristic of this addition is that the HELD An important characteristic of this addition is that the HELD
protocol with identity extensions implemented is not considered an protocol with identity extensions implemented is not considered an
LCP. The scope of an LCP is limited to the interaction between a 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 Device and a LIS, and LCPs can guarantee the identity of Devices
without additional authorization checks. Neither of these is true without additional authorization checks. A LIS identifies the Device
for HELD with identity extensions. Furthermore, identity extensions making the LCP request using the source addressing on the request
allow authorized third-party location recipients (LRs) to make packets, using return routability to ensure that these identifiers
requests that include identifiers to retrieve location information are not spoofed.
about a particular Device.
HELD with identity extensions allows a requester 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 requester 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 obviously introduces a new set of The usage of identifiers in HELD obviously introduces a new set of
privacy concerns. In an LCP, the requester can be implicitly privacy concerns. In an LCP, the requester can be implicitly
authorized to access the requested location information, because it authorized to access the requested location information, because it
is their own location. In contrast, a third-party LR must be is their own location. In contrast, a third-party LR must be
explicitly authorized when requesting the location of a Device. explicitly authorized when requesting the location of a Device.
Establishing appropriate authorization and other related privacy Establishing appropriate authorization and other related privacy
concerns are discussed in Section 5. concerns are discussed in Section 4.
1.1. Applications 1.1. Applications
The use of additional identifiers in HELD falls into two categories: 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 requester 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 Location configuration: A Device can use these parameters to
identify itself to a LIS. Identification information other than identify itself to a LIS. Identification information other than
IP might be needed to determine the location of a Device. an IP address might be needed to determine the location of a
Device.
Due to the risk that an identifier might be spoofed by a Device, A LIS can authorize location configuration requests using a policy
identifiers MUST NOT be used unless specific information is that allows Devices to acquire their own location (see
provided for that identifier describing how the identifier is used Section 4.1). If an unauthorized third-party falsifies addressing
and what measures are used to prevent spoofing. 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 provides this information for the network access This document describes a mechanism that provides assurances that
identifier (NAI) for use in WiMAX networks. All other identifiers the requester and included Device identity are the same for the
described are solely for use in third-party requests. 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 requester.
Third-party requests: A third-party location recipient can be Third-party requests: A third-party location recipient can be
granted authorization to make requests for a given Device. In granted authorization to make requests for a given Device. In
particular, network services can be permitted to retrieve location particular, network services can be permitted to retrieve location
for a Device that is unable to acquire location information for for a Device that is unable to acquire location information for
itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This
allows use of location-dependent applications - particularly allows use of location-dependent applications - particularly
essential services like emergency calling - where Devices do not essential services like emergency calling - where Devices do not
support a location configuration protocol or they are unable to support a location configuration protocol or they are unable to
successfully retrieve location information. successfully retrieve location information.
This document does not describe how a third party acquires an This document does not describe how a third party acquires an
identifier for a Device, or how that third-party is authenticated identifier for a Device, nor how that third-party is authorized by
by a LIS. These issues MUST be resolved before permitting a a LIS. It is critical that these issues are resolved before
third-party request. A pre-arranged contract between the third- permitting a third-party request. A pre-arranged contract between
party, a Rule Maker and the LIS operator is necessary to use the third-party, a Rule Maker and the LIS operator is necessary to
device identifiers in this fashion. This contract MUST include use Device identifiers in this fashion. This contract must
how the request is authenticated and the set of identifiers (and include how the request is authenticated and the set of
types of identifiers) that the third-party is authorized to use in identifiers (and types of identifiers) that the third-party is
requests. authorized to use in requests.
Note that this is not intended to preclude the definition of Automated mechanisms to ensure privacy constraints are respected
mechanisms that replace this requirement with automated means of are possible.
establishing these constraints.
2. Terminology 1.2. Terminology
This document uses the term Location Information Server (LIS) and This document uses the term Location Information Server (LIS) and
location configuration protocol (LCP) as described in location configuration protocol (LCP) as described in
[I-D.ietf-geopriv-l7-lcp-ps] and [I-D.ietf-geopriv-arch]. [I-D.ietf-geopriv-l7-lcp-ps] and [I-D.ietf-geopriv-arch].
The term Device is used specifically as the subject of an LCP, The term Device is used specifically as the subject of an LCP,
consistent with [I-D.ietf-geopriv-http-location-delivery]. This consistent with [I-D.ietf-geopriv-http-location-delivery]. This
document also uses the term Target to refer to any entity that might 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 be a subject of the same location information. Target is used in a
more general sense, including the Device, but also any nearby entity, 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 such as the user of a Device. A Target has a stake in setting
authorization policy on the use of location information. Both Device authorization policy on the use of location information. Both Device
and Target are defined in [I-D.ietf-geopriv-arch]. and Target are defined in [I-D.ietf-geopriv-arch].
The term "requester" is used in this document to refer to the entity
making a HELD request.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Device Identity 2. Device Identity
Identifiers are used as the starting point in location determination. Identifiers are used as the starting point in location determination.
They should not be confused with measurement information They should not be confused with measurement information
([I-D.thomson-geopriv-held-measurements]). Measurement information ([I-D.thomson-geopriv-held-measurements]). Measurement information
is information about a Device and the time varying details of its is information about a Device and the time varying details of its
network attachment. Identifiers might be associated with a different network attachment. Identifiers might be associated with a different
Device over time, but the their purpose is to identify the Device, Device over time, but their purpose is to identify the Device, not to
not to describe its environment or network attachment. describe its environment or network attachment.
3.1. Identifier Suitability 2.1. Identifier Suitability
Use of any identifier MUST only be allowed if it identifies a single Use of any identifier MUST only be allowed if it identifies a single
Device at a particular time. In some circumstances, certain of these Device at the time that location is determined. The LIS is
identifiers are either temporary or could potentially identify responsible for ensuring that location information is correct for the
multiple devices. Identifiers that are transient or ambiguous could Device, which includes ensuring that the identifier is uniquely
be exploited by an attacker to either gain information about another attributable to the Device.
device or to coerce the LIS into producing misleading information.
The identifiers described in this section MUST only be used where 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. that identifier is used as the basis for location determination.
Considerations relating to the use of identifiers for a Device Considerations relating to the use of identifiers for a Device
requesting its own location are discussed in Section 5 of requesting its own location are discussed in Section 5 of
[I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of [I-D.ietf-geopriv-l7-lcp-ps]; this section discusses use of
identifiers for authorized third-party requests. identifiers for authorized third-party requests.
It is tempting for a LIS implementation to allow alternative It is tempting for a LIS implementation to allow alternative
identifiers for convenience or some other perceived benefit. identifiers for convenience or some other perceived benefit. The
However, care needs to be taken to ensure that the binding between LIS is responsible for ensuring that the identifier used in the
the indicated identifier and the identifier that is used for request does not refer to a Device other than the one for which it
location determination is unique and not subject to attacks. determines location.
Identifiers can have a different meaning to different entities on a Some identifiers are always uniquely attributable to a single Device.
network. An identifier in one network context might have a However, other identifiers can have a different meaning to different
completely different meaning in a different context. Errors in entities on a network. This is especially true for IP addresses
perspective arise in both topology (all network entities have a [RFC2101], but this can be true for other identifiers to varying
subjective view of the network) and time (the network changes over degrees. Non-uniqueness arises from both topology (all network
time). entities have a subjective view of the network) and time (the network
changes over time).
3.1.1. Subjective Network Views 2.1.1. Subjective Network Views
Subjective views of the network mean that the identifier a requests Subjective views of the network mean that the identifier a requester
uses to refer to one physical entity could actually apply to a uses to refer to one physical entity could actually apply to a
different physical entity when used in a different network context. different physical entity when used in a different network context.
Unless an authorized third-party requester and LIS operate in the Unless an authorized third-party requester and LIS operate in the
same network context, each could have a different subjective view of same network context, each could have a different subjective view of
the meaning of the identifier. the meaning of the identifier.
Where subjective views differ, the third-party receives information Where subjective views differ, the third-party receives information
that is correct only within the network context of the LIS. The that is correct only within the network context of the LIS. The
location information provided by the LIS is probably misleading: the location information provided by the LIS is probably misleading: the
requester believes that the information relates to a different entity requester believes that the information relates to a different entity
than it was generated for. than it was generated for.
Authorization policy can be affected by a subjective network view if Authorization policy can be affected by a subjective network view if
it is applied based on an identifier, or it's application depends on it is applied based on an identifier, or its application depends on
identifiers. The subjective view presented to the LIS and Rule Maker identifiers. The subjective view presented to the LIS and Rule Maker
need to agree for the two entities to understand policy on the same 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 terms. For instance, it is possible that the LIS could apply the
incorrect authorization policy if it selects the policy using a incorrect authorization policy if it selects the policy using a
subjective identifier. Alternatively, it may use the correct policy subjective identifier. Alternatively, it may use the correct policy
but apply it incorrectly if subjective identifiers are used. but apply it incorrectly if subjective identifiers are used.
In IP networks, network address translation (NAT) and other forms In IP networks, network address translation (NAT) and other forms
of address modification create network contexts. Entities on of address modification create network contexts. Entities on
either side of the point where modification occurs have a either side of the point where modification occurs have a
skipping to change at page 9, line 5 skipping to change at page 9, line 14
to determine an appropriate response. to determine an appropriate response.
The residential gateway scenario in Section 3.1 of The residential gateway scenario in Section 3.1 of
[I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a [I-D.ietf-geopriv-l7-lcp-ps] is a particular example of where a
subjective view is permitted. The LIS knowingly provides Devices on subjective view is permitted. The LIS knowingly provides Devices on
the remote side of the residential gateway with location information. the remote side of the residential gateway with location information.
The LIS provides location information with appropriate uncertainty to The LIS provides location information with appropriate uncertainty to
allow for the fact that the residential gateway serves a small allow for the fact that the residential gateway serves a small
geographical area. geographical area.
3.1.2. Transient Identifiers 2.1.2. Transient Identifiers
Some identifiers are temporary and can, over the course of time, be Some identifiers are temporary and can, over the course of time, be
assigned to different physical entities. An identifier that is assigned to different physical entities. An identifier that is
reassigned between the time that a request is formulated by a reassigned between the time that a request is formulated by a
requester and when the request is received by the LIS causes the LIS requester and when the request is received by the LIS causes the LIS
to locate a different entity than the requester intended. The to locate a different entity than the requester intended. The
response from the LIS might be accurate, but the request incorrectly response from the LIS might be accurate, but the request incorrectly
associates this information with the wrong subject. associates this information with the wrong subject.
A LIS should be configured with information about any potentially A LIS should be configured with information about any potentially
skipping to change at page 9, line 27 skipping to change at page 9, line 36
changes have occurred. A LIS must not provide location information changes have occurred. A LIS must not provide location information
if the identifier it uses might refer to a different Device. If an 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 identifier might have been reassigned recently, or it is likely to be
reassigned, it is not suitable as an identifier. reassigned, it is not suitable as an identifier.
It's possible that some degree of uncertainty could persist where It's possible that some degree of uncertainty could persist where
identifiers are reassigned frequently; the extent to which errors identifiers are reassigned frequently; the extent to which errors
arising from using transient identifiers are tolerated is a matter arising from using transient identifiers are tolerated is a matter
for local policy. for local policy.
3.2. Identifier Format and Protocol Details 2.2. Identifier Format and Protocol Details
XML elements are used to express the Device identity. The "target" XML elements are used to express the Device identity. The "device"
element is used as a general container for identity information. element is used as a general container for identity information.
This document defines a basic set of identifiers. An example HELD This document defines a basic set of identifiers. An example HELD
request, shown in Figure 1, includes an IP version 4 address. request, shown in Figure 1, includes an IP version 4 address.
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8"> responseTime="8">
<locationType exact="true">geodetic</locationType> <locationType exact="true">geodetic</locationType>
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="4">192.0.2.5</ip> <ip v="4">192.0.2.5</ip>
</device> </device>
</locationRequest> </locationRequest>
Figure 1 Figure 1
A LIS that supports this specification echoes the "target" element in A LIS that supports this specification echoes the "device" element in
a successful HELD response, including the identifiers that were used a successful HELD response, including the identifiers that were used
as the basis for location determination. Absence of this indication as the basis for location determination. Absence of this indication
means that the location information was generated using the source IP means that the location information was generated using the source IP
address in the request. address in the request.
If an identifier is invalid, not supported by the LIS, or the A "badIdentifier" HELD error code indicates that the requester is not
requester is not authorized to use that identifier, a HELD error authorized to use that identifier or that the request contains an
response of "badIdentifier". This code is registered in Section 8.3. 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 If the LIS requires an identifier that is not provided in the
request, the desired identifiers MAY be identified in the HELD error request, the desired identifiers MAY be identified in the HELD error
response, using the "requiredIdentifiers" element. This element response, using the "requiredIdentifiers" element. This element
contains a list of XML qualified names [W3C.REC-xml-names11-20060816] contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
that identify the identifier elements required by the LIS. Namespace that identify the identifier elements required by the LIS. Namespace
prefix bindings for the qualified names are taken from document prefix bindings for the qualified names are taken from document
context. Figure 2 shows an example error indicating that the context. Figure 2 shows an example error indicating that the
requester needs to include a MAC address (Section 4.2) if the request requester needs to include a MAC address (Section 3.2) if the request
is to succeed. is to succeed.
<error xmlns="urn:ietf:params:xml:ns:geopriv:held" <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="badIdentifier"> code="badIdentifier">
<message xml:lang="en">MAC address required</message> <message xml:lang="en">MAC address required</message>
<requiredIdentifiers <requiredIdentifiers
xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
mac mac
</requiredIdentifiers> </requiredIdentifiers>
</error> </error>
Figure 2 Figure 2
4. Identifiers 3. Identifiers
A limited selection of identifiers are included in this document. A limited selection of identifiers are included in this document.
The basic Device identity schema allows for the inclusion of elements The basic Device identity schema allows for the inclusion of elements
from any namespace, therefore additional elements can be defined from any namespace, therefore additional elements can be defined
using different XML namespaces. using different XML namespaces.
4.1. IP Address 3.1. IP Address
The "ip" element can express a Device identity as an IP address. An The "ip" element can express a Device identity as an IP address. The
optional "v" attribute identifies the IP version. The element uses "v" attribute identifies the IP version with a single hexadecimal
the textual format specific to the indicated IP version. digit. The element uses the textual format specific to the indicated
IP version.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:DB8::1:ea7:fee1:d1e</ip> <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>
</device> </device>
In situations where location configuration does not require In situations where location configuration does not require
additional identifiers, using IP address as an identifier enables additional identifiers, using IP address as an identifier enables
authorized third-party requests. authorized third-party requests.
4.2. MAC Address 3.2. MAC Address
The media access control (MAC) address used by the IEEE 802 family of The media access control (MAC) address used by the IEEE 802 family of
access technologies is an identifier that is assigned to a particular access technologies is an identifier that is assigned to a particular
network device. A MAC address is a unique sequence that is either 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 assigned at the time of manufacture of a Device, or assigned by a
local administrator. A MAC address rarely changes; therefore, a MAC local administrator. A MAC address rarely changes; therefore, a MAC
address is an appropriate identifier for a Device. address is an appropriate identifier for a Device.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<mac>A0-12-34-56-78-90</mac> <mac>A0-12-34-56-78-90</mac>
</device> </device>
A LIS that operates on the same layer 2 segment as a Device sees the 3.3. TCP or UDP Port Number
MAC address of the Device and can authenticate the device in that
fashion. If a router is interposed between LIS and Device, other
means of authentication are required.
4.3. TCP or UDP Port Number
On its own, a TCP or UDP port number is insufficient to uniquely On its own, a TCP or UDP port number is insufficient to uniquely
identify a single host, but in combination with an IP address, it can identify a single host, but in combination with an IP address, it can
be used in some environments to uniquely identify a Device. be used in some environments to uniquely identify a Device.
Use of a particular port number can be transient; often significantly Use of a particular port number can be transient; often significantly
more than use of any given IP address. However, widespread use of more than use of any given IP address. However, widespread use of
network address translation (NAT) means that some Devices cannot be network address translation (NAT) means that some Devices cannot be
uniquely identified by IP address alone. An individual Device might uniquely identified by IP address alone. An individual Device might
be identified by a flow of packets that it generates. Providing that 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 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 individual target on the remote side of the NAT might be able to be
identified uniquely. identified uniquely.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<ip v="6">2001:DB8::1:ea7:fee1:d1e</ip> <ip v="4">192.0.2.75</ip>
<udpport>51393</udpport> <udpport>51393</udpport>
</device> </device>
Use of port numbers is especially reliant on the value remaining Use of port numbers is especially reliant on the value remaining
consistent over time. consistent over time.
4.4. Network Access Identifier 3.4. Network Access Identifier
A Network Access Identifier (NAI) [RFC4282] is an identifier used in A Network Access Identifier (NAI) [RFC4282] is an identifier used in
network authentication in a range of networks. The identifier network authentication in a range of networks. The identifier
establishes a user identity within a particular domain. Often, establishes a user identity within a particular domain. Often,
network services use an NAI in relation to location records, tying network services use an NAI in relation to location records, tying
network access to user authentication and authorization. network access to user authentication and authorization.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<nai>user@example.net</nai> <nai>user@example.net</nai>
</device> </device>
skipping to change at page 12, line 41 skipping to change at page 12, line 37
cannot be expressed using XML. Therefore, this expression of NAI cannot be expressed using XML. Therefore, this expression of NAI
permits escaping. Non-unicode characters (and any other character) permits escaping. Non-unicode characters (and any other character)
are expressed using a backslash ('\') followed by two hexadecimal are expressed using a backslash ('\') followed by two hexadecimal
digits representing the value of a single octet. digits representing the value of a single octet.
The canonical representation of an NAI is the sequence of octets that The canonical representation of an NAI is the sequence of octets that
is produced from the concatenation of UTF-8 encoded sequences of is produced from the concatenation of UTF-8 encoded sequences of
unescaped characters and octets derived from escaped components. unescaped characters and octets derived from escaped components.
This sequence MUST conform to the constraints in [RFC4282]. This sequence MUST conform to the constraints in [RFC4282].
4.4.1. Using NAI for Location Configuration 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 In a WiMAX network, an IP address is not sufficient information for a
LIS to locate a Device. The procedure described in LIS to locate a Device. The following procedure, described in more
[WiMAX-T33-110-R015v01-B] relies on an NAI to identify the Device. detail in [WiMAX-T33-110-R015v01-B], relies on an NAI to identify the
Device.
Third-party requests in a WiMAX network always require the inclusion Location requests in a WiMAX network always require the inclusion of
of an NAI. However, if a LIS receives a request that does not come an NAI. However, if a LIS receives a request that does not come from
from an authenticated and authorized third-party requester, it can an authenticated and authorized third-party requester, it can treat
treat this request as a location configuration request. this request as a location configuration request.
After receiving a location request that includes an NAI, the LIS After receiving a location request that includes an NAI, the LIS
sends a "Location-Requestor-Authentication-Protocol" access request sends a "Location-Requestor-Authentication-Protocol" access request
message to the Authentication, Authorization and Accounting (AAA) message to the Authentication, Authorization and Accounting (AAA)
server. This request containing a "MS-Identity-Assertion" parameter server. This request includes an "MS-Identity-Assertion" parameter
containing the NAI. containing the NAI.
The AAA server consults network policy and if the request is The AAA server consults network policy and if the request is
permitted, the response includes the IP address that is currently permitted, the response includes the IP address that is currently
assigned to the Device. If this IP address matches the source IP assigned to the Device. If this IP address matches the source IP
address of the HELD location request, the location request is address of the HELD location request, the location request can be
permitted; otherwise, the request is rejected. 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 IP address spoofing protections that are This relies on the same IP address spoofing protections that are
required by [I-D.ietf-geopriv-http-location-delivery]. In addition, required by [I-D.ietf-geopriv-http-location-delivery]. In addition,
the request made of the AAA uses the Diameter protocol [RFC3588], and the request made of the AAA uses either Diameter [RFC3588] or RADIUS
therefore relies on the security of the Diameter exchange. In order [RFC2865], and therefore relies on the protections provided by those
to rely on the access request, the AAA server MUST be authenticated protocols. In order to rely on the access request, the AAA server
to be a trusted entity for the purpose of providing a link between MUST be authenticated to be a trusted entity for the purpose of
the NAI and IP address. The Diameter exchange MUST also be protected providing a link between the NAI and IP address. The AAA protocol
from modification. Some part of these protections can be provided MUST also provide protection from modification and replay attacks to
through use of IPsec [RFC4301] or TLS [RFC5246], as mandated in ensure that data cannot be altered by an attacker.
[RFC3588].
4.5. URI 3.5. URI
A Device can be identified by a URI. Any URI can be used providing A Device can be identified by a URI. Any URI can be used providing
that the requester and LIS have a common understanding of the that the requester and LIS have a common understanding of the
semantics implied by use of the URI. semantics implied by use of the URI.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri>sip:user@example.net;gr=kjh29x97us97d</uri> <uri>sip:user@example.net;gr=kjh29x97us97d</uri>
</device> </device>
Particular care needs to be taken in ensuring that a particular URI 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 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 multiple destinations. For example, a SIP address of record URI can
correspond to a service subscription rather than a single Device. correspond to a service subscription rather than a single Device.
4.6. Hostname A "tel:" URI [RFC3966] can be used identify a Device by telephone
number:
A domain name can be used as the basis for identification using the
"hostname" element.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<hostname>host.example.net</hostname> <uri>tel:800-555-1111;extension=1234;phone-context=+1</uri>
</device> </device>
A domain name does not always correspond to a single IP address or 3.6. Fully Qualified Domain Name
host. If this is the case, a domain name is not a suitable
identifier.
4.7. Directory Number
Telephony devices are typically identified by the number that is used A fully-qualified domain name can be used as the basis for
to reach them. Within enterprises, where globally accessible identification using the "fqdn" element.
telephone numbers might not be used, a directory number is the usual
form of identification.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<dn>7515</dn> <fqdn>host.example.net</fqdn>
</device> </device>
4.8. Cellular Telephony Identifiers This IDN-aware domain name slot [I-D.ietf-idnabis-defs] 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 A range of different forms of mobile station identifiers are used for
different cellular telephony systems. Elements are defined for these different cellular telephony systems. Elements are defined for these
identifiers. The following identifiers are defined: identifiers. The following identifiers are defined:
msisdn: The Mobile Subscriber Integrated Services Digital Network msisdn: The Mobile Station International Subscriber Dial Number
Number (MSISDN) is an E.164 number between 6 and 15 digits long. (MSISDN) is an E.164 number between 6 and 15 digits long.
imsi: The International Mobile Subscriber Identity (IMSI) an imsi: The International Mobile Subscriber Identity (IMSI) an
identifier associated with all GSM and UMTS mobile subscribers. identifier associated with all GSM and UMTS mobile subscribers.
imei: The International Mobile Equipment Identifier (IMEI) is a imei: The International Mobile Equipment Identifier (IMEI) is a
unique device serial number up to 15 digits long. unique device serial number up to 15 digits long.
min: The Mobile Identification Number (MIN) is a unique number min: The Mobile Identification Number (MIN) is a unique number
assigned to CDMA handsets. assigned to CDMA handsets.
mdn: The Mobile Directory Number (MDN) is an E.164 number, with mdn: The Mobile Directory Number (MDN) is an E.164 number, with
usage similar to MSISDN. usage similar to MSISDN.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<msisdn>11235550123</msisdn> <msisdn>11235550123</msisdn>
</device> </device>
4.9. DHCP Unique Identifier 3.8. DHCP Unique Identifier
The Dynamic Host Configuration Protocol (DHCP) uses a binary The Dynamic Host Configuration Protocol (DHCP) uses a binary
identifier for its clients. The DHCP Unique Identifier (DUID) is identifier for its clients. The DHCP Unique Identifier (DUID) is
expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The DHCPv6 and follows the format defined in Section 9 of [RFC3315]. The
"duid" element includes the binary value of the DUID expressed in "duid" element includes the binary value of the DUID expressed in
hexadecimal. hexadecimal.
<device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<duid>1234567890AaBbCcDdEeFf</duid> <duid>1234567890AaBbCcDdEeFf</duid>
</device> </device>
5. Privacy Considerations 4. Privacy Considerations
Location configuration protocols can make use of an authorization Location configuration protocols can make use of an authorization
model known as "LCP policy", which permits only Targets to be the model known as "LCP policy", which permits only Targets to be the
recipients of their own locations. In effect, an LCP server (that 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 LIS) follows a single rule policy that states that the Target
is the only authorized Location Recipient. is the only authorized Location Recipient.
The security and privacy considerations of the base HELD protocol The security and privacy considerations of the base HELD protocol
[I-D.ietf-geopriv-http-location-delivery] are applicable, except as [I-D.ietf-geopriv-http-location-delivery] are applicable. However,
they relate to return routability. 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.
5.1. Targets Requesting Their Own Location 4.1. Targets Requesting Their Own Location
When a Target uses identity extensions to obtain its own location, When a Target uses identity extensions to obtain its own location,
HELD can no longer be considered an LCP. The authorization policy HELD can no longer be considered an LCP. The authorization policy
that the LIS uses to respond to these requests must be provisioned by that the LIS uses to respond to these requests must be provisioned by
one or more Rule Makers. one or more Rule Makers.
In the case that the LIS exclusively provides Targets with their own In the case that the LIS exclusively provides Targets with their own
locations, the LIS can still be said to be following the "LCP locations, the LIS can still be said to be following the "LCP
policy". In all cases, the Geopriv security and privacy policy". In all cases, the Geopriv security and privacy
considerations [I-D.ietf-geopriv-arch] are applicable. considerations [I-D.ietf-geopriv-arch] are applicable.
The spoofing protections provided when using HELD with identity The spoofing protections provided when using HELD with identity
extensions to provide Targets with their own locations differ from extensions to provide Targets with their own locations differ from
the protections inherent in an LCP. For an LCP, return routability the protections inherent in an LCP. For an LCP, return routability
is considered sufficient protection against spoofing. For a is considered sufficient protection against spoofing. For a similar
similarly policy to be used, specific measures MUST be defined to policy to be used, specific measures MUST be defined to protect
protect against spoofing of the alternative identifier. This against spoofing of the alternative identifier. This document
document defines this for an NAI when used in WiMAX networks (see defines this for an NAI when used in WiMAX networks (see
Section 4.4.1), but for no other identifier. Section 3.4.1), but for no other identifier.
A Rule Maker might require additional verification that the A Rule Maker might require an assurance that the identifier is owned
identifier is owned by the requester. Verification that depends on by the requester. Any multi-stage verification process that includes
return routability can only provide weaker assurances than those a return routability test cannot provide any stronger assurance than
provided by return routability; therefore, policy might require the return routability alone; therefore, policy might require the use of
use of additional, independent methods of verification. additional, independent methods of verification.
Care is required where a direct one-to-one relationship between Care is required where a direct one-to-one relationship between
requester and Device identity does not exist. If identifiers are not requester and Device identity does not exist. If identifiers are not
identical, the use of HELD identity extensions to provide Targets uniquely attributable to a single Device, the use of HELD identity
with their own locations could be exploited by an attacker. extensions to provide Targets with their own locations could be
exploited by an attacker.
For example, it is not appropriate to provide Targets with their It might be possible in some networks to establish multiple
own locations under these terms where a requester is authenticated concurrent sessions using the same credentials. For instance,
by NAI and the supplied Device identity is a MAC address, even if Devices with different MAC addresses might be granted concurrent
that MAC address is currently registered with the network under access to a network using the same NAI. It is not appropriate to
the given NAI. In this case, the requester might be requesting provide Targets with their own locations based on NAI in this
from a different MAC address registered under the same NAI. The 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
registered to the NAI. The MAC address potentially identifies a
different Device to the one that is making the request. The
correct way of gaining authorization is to establish a policy that correct way of gaining authorization is to establish a policy that
permits this particular request as a third party request. permits this particular request as a third-party request.
5.1.1. Security Considerations for NAI use in WiMAX Networks
Section 4.4.1 discusses the implications of using an NAI as an Section 3.4.1 discusses the implications of using an NAI as an
identifier for location requests made of a LIS serving a WiMAX identifier for location requests made of a LIS serving a WiMAX
network. Additional security considerations are discussed in network. Additional security considerations are discussed in
[WiMAX-T33-110-R015v01-B]. [WiMAX-T33-110-R015v01-B].
5.2. Third-Party Requests 4.2. Third-Party Requests
The LCP policy does not allow requests made by third parties. If a The LCP policy does not allow requests made by third parties. If a
LIS permits requests from third parties using Device identity, it LIS permits requests from third parties using Device identity, it
assumes the rule of a Location Server (LS). As a Location Server, assumes the rule of a Location Server (LS). As a Location Server,
the LIS MUST explicitly authorize requests according to the policies the LIS MUST explicitly authorize requests according to the policies
that are provided by Rule Makers, including the Target. The LIS MUST that are provided by Rule Makers, including the Target. The LIS MUST
also authenticate requesters according to the agree authorization also authenticate requesters according to any agreed-upon
policy. authorization policy.
An organization that provides a LIS that allows third party requests An organization that provides a LIS that allows third party requests
must provide a means for a Rule Maker to specify authorization must provide a means for a Rule Maker to specify authorization
policies as part of the LIS implementation (e.g, in the form of policies as part of the LIS implementation (e.g, in the form of
access control lists). Authorization must be established before access control lists). Authorization must be established before
allowing third party requests for the location of any Target. Until allowing third party requests for the location of any Target. Until
an authorization policy is established, the LIS MUST reject requests an authorization policy is established, the LIS MUST reject requests
by third parties (that is, the default policy is "deny all"). by third parties (that is, the default policy is "deny all").
When the LIS is operated by an access network, the relationship When the LIS is operated by an access network, the relationship
skipping to change at page 18, line 5 skipping to change at page 18, line 5
potential Rule Maker, this presents a problem. However, the process potential Rule Maker, this presents a problem. However, the process
of establishing network access usually results in a form of agreement of establishing network access usually results in a form of agreement
between the Target and the network provider. This process offers a between the Target and the network provider. This process offers a
natural vehicle for establishing location privacy policies. natural vehicle for establishing location privacy policies.
Establishing authorization policy might be a manual process, an Establishing authorization policy might be a manual process, an
explicit part of the terms of service for the network, or an explicit part of the terms of service for the network, or an
automated system that accepts formal authorization policies (see automated system that accepts formal authorization policies (see
[RFC4745], [RFC4825]). This document does not mandate any particular [RFC4745], [RFC4825]). This document does not mandate any particular
mechanism for establishing an authorization policy. mechanism for establishing an authorization policy.
6. Security Considerations 5. Security Considerations
The security considerations in The security considerations in
[I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
server authentication, confidentiality and protection from server authentication, confidentiality and protection from
modification. These protections apply to both Target requests for modification. These protections apply to both Target requests for
their own locations and requests made by third parties. their own locations and requests made by third parties.
All HELD requests containing identity MUST be authenticated by the All HELD requests containing identity MUST be authenticated by the
LIS. How authentication is accomplished and what assurances are LIS. How authentication is accomplished and what assurances are
desired is a matter for policy. desired is a matter for policy.
The base HELD protocol uses return reachability of an IP address The base HELD protocol uses return reachability of an IP address
implied by the requester being able to successfully complete a TCP implied by the requester being able to successfully complete a TCP
handshake. It is RECOMMENDED that any means of authentication handshake. It is RECOMMENDED that any means of authentication
provide at least this degree of assurance. For requests that include provide at least this degree of assurance. For requests that include
Device identity, the LIS MUST support authentication of TLS clients. Device identity, the LIS MUST support HTTP digest authentication.
Unauthenticated location requests containing Device identity can be
challenged with an HTTP 401 (Unauthorized) response or rejected with
an HTTP 403 (Forbidden) response.
6.1. Identifier Suitability 5.1. Identifier Suitability
Transient and ambiguous identifiers can be exploited by malicious Transient and ambiguous identifiers can be exploited by malicious
requests and are not suitable as a basis for identifying a Device. requests and are not suitable as a basis for identifying a Device.
Section 3.1 provides further discussion on this subject. Section 2.1 provides further discussion on this subject.
Identifier transience of can lead to incorrect location information Identifier transience can lead to incorrect location information
being provided. An attacker could exploit the use of transient being provided. An attacker could exploit the use of transient
identifiers. In this attack, the attacker either knows of a re- identifiers. In this attack, the attacker either knows of a re-
allocation of that identifier or is able to force the identifier to allocation of that identifier or is able to force the identifier to
be re-allocated during the processing of the request. be re-allocated during the processing of the request.
An attacker could use this to acquire location information for 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- 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 allocation occurs between the time where authorization is granted and
location information is granted. location information is granted.
Ambiguous identifiers present a similar problem. An attacker could Ambiguous identifiers present a similar problem. An attacker could
legitimately gain authorization to use a particular identifier. legitimately gain authorization to use a particular identifier.
Since an ambiguous identifier potentially refers to multiple Devices, Since an ambiguous identifier potentially refers to multiple Devices,
if authorization is granted for one of those Devices, an attacker if authorization is granted for one of those Devices, an attacker
potentially gains access to location information for all of those potentially gains access to location information for all of those
Devices. Devices.
6.2. Targets Requesting Their Own Location 5.2. Targets Requesting Their Own Location
Requests made by a Device for its own location are covered by the Requests made by a Device for its own location are covered by the
same set of protections offered by HELD. These requests might be same set of protections offered by HELD. These requests might be
authorized under a policy similar to the "LCP policy" that permits a authorized under a policy similar to the "LCP policy" that permits a
Target access to location information about itself. Target access to location information about itself.
Identity information provided by the Device is private data that Identity information provided by the Device is private data that
might be sensitive. The Device provides this information in the might be sensitive. The Device provides this information in the
expectation that it assists the LIS in providing the Device a expectation that it assists the LIS in providing the Device a
service. The LIS MUST NOT use identity information for any other service. The LIS MUST NOT use identity information for any other
purpose other than serving the request that includes that purpose other than serving the request that includes that
information. information.
6.3. Third-Party Requests 5.3. Third-Party Requests
Requests from third parties have the same requirements for server Requests from third parties have the same requirements for server
authentication, confidentiality and protection from modification as authentication, confidentiality and protection from modification as
Target requests for their own locations. However, because the third- Target requests for their own locations. However, because the third-
party needs to be authorized, the requester MUST be authenticated by party needs to be authorized, the requester MUST be authenticated by
the LIS. In addition, third-party requests MUST be explicitly the LIS. In addition, third-party requests MUST be explicitly
authorized by a policy that is established by a Rule Maker. authorized by a policy that is established by a Rule Maker.
More detail on the privacy implications of third-party requests are More detail on the privacy implications of third-party requests are
covered in Section 5. covered in Section 4.
7. XML Schema 6. XML Schema
<?xml version="1.0"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id" targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id" xmlns:id="urn:ietf:params:xml:ns:geopriv:held:id"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- Device Identity --> <xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:id">
HELD Device Identity
</xs:appinfo>
<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
published RFC and remove this note.]] -->
This document defines Device identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="device" type="id:deviceIdentity"/> <xs:element name="device" type="id:deviceIdentity"/>
<xs:complexType name="deviceIdentity"> <xs:complexType name="deviceIdentity">
<xs:sequence> <xs:sequence>
<xs:any namespace="##any" processContents="lax" <xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:element name="requiredIdentifiers" type="id:qnameList"/> <xs:element name="requiredIdentifiers" type="id:qnameList"/>
<xs:simpleType name="qnameList"> <xs:simpleType name="qnameList">
skipping to change at page 20, line 42 skipping to change at page 21, line 4
<xs:attribute name="v" use="optional"> <xs:attribute name="v" use="optional">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]"/> <xs:pattern value="[\da-fA-F]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:extension> </xs:extension>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
<xs:element name="mac" type="id:macAddress"/> <xs:element name="mac" type="id:macAddress"/>
<xs:simpleType name="macAddress"> <xs:simpleType name="macAddress">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}"/> <xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="udpport" type="id:portNumber"/> <xs:element name="udpport" type="id:portNumber"/>
<xs:element name="tcpport" type="id:portNumber"/> <xs:element name="tcpport" type="id:portNumber"/>
<xs:simpleType name="portNumber"> <xs:simpleType name="portNumber">
<xs:restriction base="xs:nonNegativeInteger"> <xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="65535"/> <xs:maxInclusive value="65535"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="nai" type="xs:token"/> <xs:element name="nai" type="id:naiType"/>
<xs:simpleType name="naiType">
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="dn" type="id:digits"/>
<xs:simpleType name="digits">
<xs:restriction base="xs:token"> <xs:restriction base="xs:token">
<xs:pattern value="[\d]+"/> <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:restriction>
</xs:simpleType> </xs:simpleType>
<xs:element name="hostname" type="id:domainName"/> <xs:element name="uri" type="xs:anyURI"/>
<xs:simpleType name="domainName"> <xs:element name="fqdn" type="xs:token"/>
<xs:restriction base="xs:token">
<!-- the following pattern does not include whitespace;
whitespace is added only to conform to document
formatting restrictions -->
<xs:pattern value="([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="duid" type="xs:hexBinary"/> <xs:element name="duid" type="xs:hexBinary"/>
<xs:element name="msisdn" type="id:e164"/> <xs:element name="msisdn" type="id:e164"/>
<xs:element name="imsi" type="id:e164"/> <xs:element name="imsi" type="id:e164"/>
<xs:element name="imei" type="id:digit15"/> <xs:element name="imei" type="id:digit15"/>
<xs:element name="min" type="id:digit10"/> <xs:element name="min" type="id:digit10"/>
<xs:element name="mdn" type="id:e164"/> <xs:element name="mdn" type="id:e164"/>
<xs:simpleType name="e164"> <xs:simpleType name="e164">
<xs:restriction base="id:digit15"> <xs:restriction base="id:digit15">
skipping to change at page 22, line 4 skipping to change at page 22, line 6
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="digit15"> <xs:simpleType name="digit15">
<xs:restriction base="id:digits"> <xs:restriction base="id:digits">
<xs:maxLength value="15"/> <xs:maxLength value="15"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="digit10"> <xs:simpleType name="digit10">
<xs:restriction base="id:digits"> <xs:restriction base="id:digits">
<xs:length value="10"/> <xs:length value="10"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
8. IANA Considerations 7. IANA Considerations
This document registers an XML namespace and schema with IANA in This document registers an XML namespace and schema with IANA in
accordance with guidelines in [RFC3688]. It also creates a new accordance with guidelines in [RFC3688]. It also creates a new
registry for device identity types, and stipulates how new types are registry for Device identity types, and stipulates how new types are
to be added. to be added.
8.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:id urn:ietf:params:xml:ns:geopriv:held:id
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:id", as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:id URI: urn:ietf:params:xml:ns:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group
(geopriv@ietf.org), James Winterbottom (geopriv@ietf.org), James Winterbottom
(james.winterbottom@andrew.com). (james.winterbottom@andrew.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
skipping to change at page 23, line 45 skipping to change at page 23, line 45
<body> <body>
<h1>Namespace for HELD Device Identity Parameters</h1> <h1>Namespace for HELD Device Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:id</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:id</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
with the RFC number for this specification.]] with the RFC number for this specification.]]
<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p> <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
8.2. XML Schema Registration 7.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:id URI: urn:ietf:params:xml:schema:geopriv:held:id
Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
James Winterbottom (james.winterbottom@andrew.com). James Winterbottom (james.winterbottom@andrew.com).
Schema: The XML for this schema can be found as the entirety of Schema: The XML for this schema can be found as the entirety of
Section 7 of this document. Section 6 of this document. [IANA Note: The pattern attribute for
naiType does not contain whitespace.]
8.3. Registration of HELD 'badIdentifier' Error Code 7.3. Registration of HELD 'badIdentifier' Error Code
This section registers the "badIdentifier" error code in the "Geopriv This section registers the "badIdentifier" error code in the "Geopriv
HELD Registries, Error codes for HELD" IANA registry. HELD Registries, Error codes for HELD" IANA registry.
badIdentifier This error code indicates that the Device identifiers badIdentifier This error code indicates that a Device identifier
used in the HELD request were either: not supported by the LIS, used in the HELD request was either: not supported by the LIS,
badly formatted, or that the requester was not authorized to make badly formatted, or not one for which the requester was authorized
a erquest for that identifier. to make a request.
9. Acknowledgements 8. Acknowledgements
The authors wish to thank the NENA VoIP location working group for The authors wish to thank the NENA VoIP location working group for
their assistance in the definition of the schema used in this their assistance in the definition of the schema used in this
document. Special thanks go to Barbara Stark, Guy Caron, Nadine document. Special thanks go to Barbara Stark, Guy Caron, Nadine
Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input Abbott, Jerome Grenier and Martin Dawson. Bob Sherry provided input
on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for on use of URIs. Thanks to Adam Muhlbauer and Eddy Corbett for
providing further corrections. Bernard Aboba provided extensive providing further corrections. Bernard Aboba provided excellent
feedback on use cases and the security model; Bernard, along with feedback on use cases and the security model; Bernard, along with
Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis Alan DeKok, also helped resolve an issue with NAIs. Ray Bellis
provided motivation for the protocol port parameters. Marc Linsner provided motivation for the protocol port parameters. Marc Linsner
and Alissa Cooper provided guidance and text (respectively) that and Alissa Cooper provided guidance and text (respectively) that
greatly clarified the discussion relating to LCPs. Thanks to Jon greatly clarified the discussion relating to LCPs. Thanks to Jon
Peterson and Cullen Jennings for forcing us to be practical. Peterson and Cullen Jennings for forcing us to be practical.
10. References 9. References
10.1. Normative references 9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
skipping to change at page 26, line 42 skipping to change at page 26, line 46
draft-ietf-geopriv-http-location-delivery-16 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009. progress), August 2009.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
progress), July 2009. progress), July 2009.
[W3C.REC-xml-names11-20060816] [W3C.REC-xml-names11-20060816]
Hollander, D., Layman, A., Bray, T., and R. Tobin, Hollander, D., Tobin, R., Bray, T., and A. Layman,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web "Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, Consortium Recommendation REC-xml-names11-20060816,
August 2006, August 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
[WiMAX-T33-110-R015v01-B] [WiMAX-T33-110-R015v01-B]
WiMAX Forum, "Protocols and Procedures for Location Based WiMAX Forum, "Protocols and Procedures for Location Based
Services", WiMAX Forum Network Architecture T33-110- Services", WiMAX Forum Network Architecture T33-110-
R015v01-B, May 2009. R015v01-B, May 2009.
10.2. Informative references 9.2. Informative references
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Configuration Protocol Option for Coordinate-based
Location Configuration Information", RFC 3825, July 2004. Location Configuration Information", RFC 3825, July 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
Protocol (DHCP) Leasequery", RFC 4388, February 2006. Protocol (DHCP) Leasequery", RFC 4388, February 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
skipping to change at page 27, line 39 skipping to change at page 27, line 48
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.ietf-idnabis-defs]
Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
draft-ietf-idnabis-defs-13 (work in progress),
January 2010.
[I-D.ietf-geopriv-arch] [I-D.ietf-geopriv-arch]
Barnes, R., Lepinski, M., Cooper, A., Morris, J., Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications", Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-01 (work in progress), draft-ietf-geopriv-arch-01 (work in progress),
October 2009. October 2009.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-13 (work in progress), draft-ietf-ecrit-phonebcp-14 (work in progress),
July 2009. January 2010.
[I-D.thomson-geopriv-held-measurements] [I-D.thomson-geopriv-held-measurements]
Thomson, M. and J. Winterbottom, "Using Device-provided Thomson, M. and J. Winterbottom, "Using Device-provided
Location-Related Measurements in Location Configuration Location-Related Measurements in Location Configuration
Protocols", draft-thomson-geopriv-held-measurements-05 Protocols", draft-thomson-geopriv-held-measurements-05
(work in progress), October 2009. (work in progress), October 2009.
[TS.3GPP.23.271] [TS.3GPP.23.271]
3GPP, "Functional stage 2 description of Location Services 3GPP, "Functional stage 2 description of Location Services
(LCS)", 3GPP TS 23.271 8.0.0, December 2008. (LCS)", 3GPP TS 23.271 8.0.0, December 2008.
skipping to change at page 29, line 15 skipping to change at page 29, line 15
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
Martin Thomson Martin Thomson
Andrew Corporation Andrew Corporation
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com Email: martin.thomson@andrew.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
 End of changes. 108 change blocks. 
237 lines changed or deleted 294 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/