draft-ietf-geopriv-lis-discovery-05.txt   draft-ietf-geopriv-lis-discovery-06.txt 
GEOPRIV M. Thomson GEOPRIV M. Thomson
Internet-Draft J. Winterbottom Internet-Draft J. Winterbottom
Intended status: Standards Track Andrew Intended status: Standards Track Andrew
Expires: June 20, 2009 December 17, 2008 Expires: August 8, 2009 February 4, 2009
Discovering the Local Location Information Server (LIS) Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-05 draft-ietf-geopriv-lis-discovery-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 20, 2009. This Internet-Draft will expire on August 8, 2009.
Copyright Notice
Copyright (c) 2009 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.
Abstract Abstract
A method is described for the discovery of a Location Information A method is described for the discovery of a Location Information
Server. The method uses a Dynamic Host Configuration Protocol (DHCP) Server. The method uses a Dynamic Host Configuration Protocol (DHCP)
option. DHCP options are defined for both IPv4 and IPv6 DHCP. A option. DHCP options are defined for both IPv4 and IPv6 DHCP. A
URI-enabled NAPTR (U-NAPTR) method is described for use where the URI-enabled NAPTR (U-NAPTR) method is described for use where the
DHCP option is unsuccessful. This document defines a U-NAPTR DHCP option is unsuccessful. This document defines a U-NAPTR
Application Service for a LIS, with a specific Application Protocol Application Service for a LIS, with a specific Application Protocol
for the HTTP Enabled Location Delivery (HELD) protocol. for the HTTP Enabled Location Delivery (HELD) protocol.
Table of Contents Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
1.1. DHCP Discovery . . . . . . . . . . . . . . . . . . . . . . 3 1.1. DHCP Discovery . . . . . . . . . . . . . . . . . . . . . . 3
1.2. U-NAPTR Discovery . . . . . . . . . . . . . . . . . . . . 3 1.2. U-NAPTR Discovery . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 5 2. LIS Discovery Using DHCP . . . . . . . . . . . . . . . . . . . 5
2.1. LIS Authentication . . . . . . . . . . . . . . . . . . . . 5 2.1. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 5
2.2. DHCPv4 Option for a LIS Address . . . . . . . . . . . . . 6 2.2. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 5
2.3. DHCPv6 Option for a LIS Address . . . . . . . . . . . . . 7 2.3. LIS Authentication . . . . . . . . . . . . . . . . . . . . 6
3. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 9 2.3.1. DHCPv4 Option for a LIS Certificate Fingerprints . . . 7
3.1. Determining a Domain Name . . . . . . . . . . . . . . . . 10 2.3.2. DHCPv6 Option for a LIS Certificate Fingerprints . . . 9
4. Overall Discovery Procedure . . . . . . . . . . . . . . . . . 11 3. U-NAPTR for LIS Discovery . . . . . . . . . . . . . . . . . . 10
4.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 12 3.1. Determining a Domain Name . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4. Overall Discovery Procedure . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 4.1. Virtual Private Networks (VPNs) . . . . . . . . . . . . . 13
6.1. Registration of DHCPv4 and DHCPv6 Option Codes . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.2. Registration of a Location Server Application Service 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Registration of DHCPv4 and DHCPv6 LIS URI Option Codes . . 15
6.3. Registration of a Location Server Application Protocol 6.2. Registration of DHCPv4 and DHCPv6 LIS Certificate
Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 14 Fingerprints Option Codes . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Registration of a Location Server Application Service
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 6.4. Registration of a Location Server Application Protocol
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Tag for HELD . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. DHCP LIS URI Option Examples . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
A.1. LIS URI Only . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. LIS URI with Fingerprint . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Overview 1. Introduction and Overview
The location of a device is a useful and sometimes necessary part of The location of a device is a useful and sometimes necessary part of
many services. A Location Information Server (LIS) is responsible many services. A Location Information Server (LIS) is responsible
for providing that location information to devices with an access for providing that location information to devices with an access
network. The LIS uses knowledge of the access network and its network. The LIS uses knowledge of the access network and its
physical topology to generate and serve location information to physical topology to generate and serve location information to
devices. devices.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
a public IP address and for directly or indirectly providing a LIS a public IP address and for directly or indirectly providing a LIS
service. service.
2. LIS Discovery Using DHCP 2. LIS Discovery Using DHCP
DHCP allows the access network provider to specify the address of a DHCP allows the access network provider to specify the address of a
LIS as part of network configuration. If the device is able to LIS as part of network configuration. If the device is able to
acquire a LIS URI using DHCP then this URI is used directly; the acquire a LIS URI using DHCP then this URI is used directly; the
U-NAPTR process is not necessary if this option is provided. U-NAPTR process is not necessary if this option is provided.
This document registers DHCP options for a LIS address for both IPv4 This document registers DHCP options for a LIS URI for both IPv4 and
and IPv6. IPv6. A second option for both DHCP versions is also registered to
convey a fingerprint of the certificate expected to be used by the
LIS.
2.1. LIS Authentication 2.1. DHCPv4 Option for a LIS Address
The DHCP LIS URI option includes an optional authentication method This section defines a DHCP for IPv4 (DHCPv4) option for the address
for the LIS. If an https: URI is provided for the LIS, the option of a LIS.
can optionally include a fingerprint of the server certificate. The
device can use this fingerprint to authenticate the server.
HTTP over TLS [RFC2818] describes how a host can be authenticated 0 1 2 3
based on an expected domain name. Relying exclusively on a domain 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
name for authentication is not appropriate for a LIS, since the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
domain name associated with the access network might not be known. | LIS_URI | Length | |
Indeed, it is often innapropriate to attempt to assign any particular +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
domain name to an access network. . .
. LIS URI .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DHCPv4 LIS URI Option Example
LIS_URI: The IANA assigned option number (TBD). [[IANA/RFC-Editor
Note: Please replace TBD with the assigned DHCPv4 option code.]]
Length: The length of the entire LIS URI option in octets.
LIS URI: The address of the LIS. The URI MUST NOT be terminated by
a zero octet.
The DHCPv4 version of this URI SHOULD NOT exceed 255 octets in
length, but MAY be extended by concatenating multiple option
values, as described in [RFC3396].
2.2. DHCPv6 Option for a LIS Address
This section defines a DHCP for IPv6 (DHCPv6) option for the address
of a LIS. The DHCPv6 option for this parameter is similarly
formatted to the DHCPv4 option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LIS_URI | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. LIS URI .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCPv6 LIS URI Option
OPTION_LIS_URI: The IANA assigned option number (TBD). [[IANA/
RFC-Editor Note: Please replace TBD with the assigned DHCPv6
option code.]]
Length: The length of the LIS URI option in octets.
The semantics and format of the remainder of the LIS URI option
are identical to the DHCPv4 option, except for the larger
allowance for URI length granted by the 16 bit length field.
DHCPv6 prohibits concatenation of option values.
2.3. LIS Authentication
HTTP over TLS [RFC2818] describes how a host is authenticated based
on an expected domain name using public key infrastructure. Relying
exclusively on a domain name for authentication is not appropriate
for a LIS, since the domain name associated with the access network
might not be known. Indeed, it is often inappropriate to attempt to
assign any particular domain name to an access network.
This specification defines an alternative means of establishing an This specification defines an alternative means of establishing an
expected identity for the server that uses a certificate fingerprint. expected identity for the server that uses a certificate fingerprint.
The DHCP option includes a fingerprint for the server certificate One or more fingerprints for the server certificate used by the LIS
that is offered by the LIS when the associated URI is accessed. is included in a second DHCP option. The client uses the fingerprint
information provided by the DHCP server to authenticate the LIS when
it establishes a TLS session.
An access network operator is still able to nominate authentication A fingerprint is generated by applying a cryptographic hash function
based on a domain name. If no fingerprint information is included, to the DER-encoded certificate. The hash algorithm used for
the device MUST authenticate the server using the method described in generating the fingerprint is identified by a textual name taken from
Section 3.1 of RFC 2818 [RFC2818]. If a fingerprint exists, the the IANA registry "Hash Function Textual Names" established in
domain name method MUST NOT be used. [RFC4572]. Implementations MUST support the SHA-1 algorithm, using
the label "sha-1".
The output of multiple hash functions MAY be included. This provides
a means to upgrade hash functions without affecting backward
compatibility. If a hash algorithm is indicated, but not supported
by a device, it MUST use the first fingerprint that is produced by an
algorithm that the device supports. Other fingerprint values MAY be
checked. If any supported fingerprint does not match, the LIS MUST
be considered unauthenticated. If none of the specified hash
algorithms are supported by the device, it MUST consider the LIS to
be unauthenticated.
A client SHOULD request the LIS certificate fingerprint option at the
same time as the LIS URI option. Without the LIS certificate
fingerprint option a client cannot authenticate the LIS.
The certificate fingerprint can be ignored if the LIS URI doesn't The certificate fingerprint can be ignored if the LIS URI doesn't
indicate a protocol that supports exchange of certificates (such as indicate a protocol that supports exchange of certificates (such as
http:). The LIS MUST be considered unauthenticated. http:). Unless the information used in the certificate fingerprint
option is used, the LIS MUST be considered unauthenticated.
Note: Whether the device goes on to use the information provided by Note: Whether the device goes on to use the information provided by
an unauthenticated LIS depends on device policy. A device might an unauthenticated LIS depends on device policy. A device might
choose to continue with alternative methods of discovery before choose to continue with alternative methods of discovery before
falling back to an unauthenticated LIS. falling back to an unauthenticated LIS.
The mechanism to generate a fingerprint is to take the hash of the An access network operator is able to nominate authentication based
DER-encoded certificate using a cryptographically strong algorithm. on a domain name by omitting fingerprints. If a zero-length
The hash algorithm used for generating the fingerprint is identified fingerprint option is provided, the device MUST authenticate the
by a textual name taken from the IANA registry "Hash Function Textual server using the method described in Section 3.1 of RFC 2818
Names" defined in [RFC4572]. Implementations MUST support SHA-1 as [RFC2818]. If a fingerprint exists, the domain name method MUST NOT
the hash algorithm and use the label "sha-1" to identify the SHA-1 be used.
algorithm.
Multiple fingerprints MAY be included. If a hash algorithm is
indicated, but not supported by a device, it MUST choose the first
algorithm that it supports. If any supported fingerprint does not
match, the LIS MUST be considered as unauthenticated. If no hash
algorithm is supported by the device, it MUST consider the LIS to be
unauthenticated.
2.2. DHCPv4 Option for a LIS Address 2.3.1. DHCPv4 Option for a LIS Certificate Fingerprints
This section defines a DHCP for IPv4 (DHCPv4) option for the address This section defines a DHCP for IPv4 (DHCPv4) option for LIS
of a LIS. certificate fingerprints.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LIS_URI | Length | F-Code(1) | F-Length | | LIS_CERT_FP | Length | Hash-Type-Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Hash-Type-Len | Hash-Type ... . Hash-Type .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fingerprint-Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F-Code(0) | URI . | F'print-Len | |
+-+-+-+-+-+-+-+-+ |
. .
. Fingerprint-Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont.) ... . (Hash-Type-Len through Fingerprint-Value Repeated) .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: DHCPv4 LIS URI Option Example Figure 3: DHCPv4 LIS Certificate Fingerprints Option Example
LIS_URI: The IANA assigned option number (TBD). [[IANA/RFC-Editor
Note: Please replace TBD with the assigned DHCPv4 option code.]]
Length: The length of the entire LIS URI option in octets.
F-Code: A single octet indicates the type of data that follows:
fingerprint or URI. A value of 1 indicates that the following
data includes a certificate fingerprint. A value of 0 indicates
that no more supplementary data is included and the URI follows.
An "F-Code" with a value of 0 MUST be included.
Values other than zero or one MAY be ignored. Any other value LIS_CERT_FP: The IANA assigned option number (TBD). [[IANA/
MUST be specified in a standards track RFC that SHOULD establish RFC-Editor Note: Please replace TBD with the assigned DHCPv4
an IANA registry. option code.]]
F-Length: If the "F-Code" is non-zero, it MUST be followed by an Length: The length of the entire LIS certificate fingerprints option
octet that indicates the length, in octets, of the data. This in octets. This option MAY be zero length, indicating the absence
value includes the sum of the lengths of: "Hash-Type-Len", of fingerprint information.
"Hash-Type", and "Fingerprint-Value".
Hash-Type-Len: The length, in octets, of the "Hash-Type" field. Hash-Type-Len: The length, in octets, of the "Hash-Type" field.
Hash-Type: A text tag that identifies the hash algorithm used to Hash-Type: A text tag that identifies the hash algorithm used to
generate the fingerprint. The set of values are defined in the generate the fingerprint. The set of values are defined in the
"Hash Function Textual Names" IANA registry [RFC4572]. "Hash Function Textual Names" IANA registry [RFC4572].
Fingerprint-Value: The octet values of the certificate fingerprint. F'print-Len: The length, in octets of the "Fingerprint-Value" field.
The length of this field is defined by the hash algorithm and MUST
match the remainder of the fingerprint data. If this does not
equal the value of "F-Length" less the length "Hash-Type-Len" and
"Hash-Type", the fingerprint MUST be considered invalid.
Note: An invalid fingerprint is not equivalent to no fingerprint.
URI: The address of the LIS. The URI takes the remainder of the Fingerprint-Value: The octet values of the certificate fingerprint.
DHCP option. The URI MUST NOT be NULL terminated. An invalid fingerprint is not equivalent to no fingerprint. If
this value is not the expected length of the hash function output,
the fingerprint MUST be considered invalid.
The DHCPv4 version of this URI SHOULD NOT exceed 225 octets in The four fields, "Hash-Type-Len", "Hash-Type", "F'print-Len" and
length, but MAY be extended by concatenating multiple option "Fingerprint-Value" MAY be repeated. Each repetition includes a
values, as described in [RFC3396]. different hash type, except for hashes that produce values longer
than 2040 bits (255 octets), for which the "Fingerprint-Value" is
concatenated to derive the value.
2.3. DHCPv6 Option for a LIS Address 2.3.2. DHCPv6 Option for a LIS Certificate Fingerprints
This section defines a DHCP for IPv6 (DHCPv6) option for the address This section defines a DHCP for IPv6 (DHCPv6) option for LIS
of a LIS. The DHCPv6 option for this parameter is similarly certificate fingerprints. The DHCPv6 option for this parameter is
formatted to the DHCPv4 option. similarly formatted to the DHCPv4 option.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LIS_URI | Length | | OPTION_LIS_CERT_FP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F-Code(1) | F-Length | Hash-Type-Len | Hash-Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fingerprint-Value ... | Hash-Type-Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. Hash-Type .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F-Code(0) | URI . | F'print-Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. Fingerprint-Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI (cont.) ... . (Hash-Type-Len through Fingerprint-Value Repeated) .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCPv6 LIS URI Option Figure 4: DHCPv6 LIS Certificate Fingerprints Option
OPTION_LIS_URI: The IANA assigned option number (TBD). [[IANA/
OPTION_LIS_CERT_FP: The IANA assigned option number (TBD). [[IANA/
RFC-Editor Note: Please replace TBD with the assigned DHCPv6 RFC-Editor Note: Please replace TBD with the assigned DHCPv6
option code.]] option code.]]
Length: The length of the LIS URI option in octets. Length: The length of the LIS certificate fingerprints option in
octets.
The format of remainder of the LIS URI option is identical to the The semantics of remainder of the LIS URI option are identical to
DHCPv4 option. the DHCPv4 option. As shown, length fields are extended to 16
bits, removing the need for concatenation to accomodate values
longer than 255 octets in length. DHCPv6 prohibits concatenation
of option values.
3. U-NAPTR for LIS Discovery 3. U-NAPTR for LIS Discovery
U-NAPTR resolution for a LIS takes a domain name as input and U-NAPTR resolution for a LIS takes a domain name as input and
produces a URI that identifies the LIS. This process also requires produces a URI that identifies the LIS. This process also requires
an Application Service tag and an Application Protocol tag, which an Application Service tag and an Application Protocol tag, which
differentiate LIS-related NAPTR records from other records for that differentiate LIS-related NAPTR records from other records for that
domain. domain.
Section 6.2 defines an Application Service tag of "LIS", which is Section 6.3 defines an Application Service tag of "LIS", which is
used to identify the location service for a particular domain. The used to identify the location service for a particular domain. The
Application Protocol tag "HELD", defined in Section 6.3, is used to Application Protocol tag "HELD", defined in Section 6.4, is used to
identify a LIS that understands the HELD protocol identify a LIS that understands the HELD protocol
[I-D.ietf-geopriv-http-location-delivery]. [I-D.ietf-geopriv-http-location-delivery].
The NAPTR records in the following example demonstrate the use of the The NAPTR records in the following example demonstrate the use of the
Application Service and Protocol tags. Iterative NAPTR resolution is Application Service and Protocol tags. Iterative NAPTR resolution is
used to delegate responsibility for the LIS service from used to delegate responsibility for the LIS service from
"zonea.example.net." and "zoneb.example.net." to "zonea.example.net." and "zoneb.example.net." to
"outsource.example.com.". "outsource.example.com.".
zonea.example.net. zonea.example.net.
skipping to change at page 9, line 44 skipping to change at page 10, line 44
"" ; regex "" ; regex
outsource.example.com. ; replacement outsource.example.com. ; replacement
) )
outsource.example.com. outsource.example.com.
;; order pref flags ;; order pref flags
IN NAPTR 100 10 "u" "LIS:HELD" ( ; service IN NAPTR 100 10 "u" "LIS:HELD" ( ; service
"!*.!https://lis.example.org:4802/?c=ex!" ; regex "!*.!https://lis.example.org:4802/?c=ex!" ; regex
. ; replacement . ; replacement
) )
Figure 3: Sample LIS:HELD Service NAPTR Records Figure 5: Sample LIS:HELD Service NAPTR Records
Details for the "LIS" Application Service tag and the "HELD" Details for the "LIS" Application Service tag and the "HELD"
Application Protocol tag are included in Section 6. Application Protocol tag are included in Section 6.
U-NAPTR MUST only be used if the DHCP LIS URI option is not U-NAPTR MUST only be used if the DHCP LIS URI option is not
available. available.
An https: LIS URI that is a product of U-NAPTR MUST be authenticated An https: LIS URI that is a product of U-NAPTR MUST be authenticated
using the domain name method described in Section 3.1 of RFC 2818 using the domain name method described in Section 3.1 of RFC 2818
[RFC2818]. [RFC2818].
skipping to change at page 13, line 19 skipping to change at page 14, line 19
responsible for providing location information and this information responsible for providing location information and this information
is critical to a number of network services; furthermore, a host does is critical to a number of network services; furthermore, a host does
not necessarily have a prior relationship with a LIS. Several not necessarily have a prior relationship with a LIS. Several
methods are described here that can limit the probablity of, or methods are described here that can limit the probablity of, or
provide some protection against, such an attack. provide some protection against, such an attack.
The address of a LIS is usually well-known within an access network; The address of a LIS is usually well-known within an access network;
therefore, interception of messages does not introduce any specific therefore, interception of messages does not introduce any specific
concerns. concerns.
If DHCP is used, the integrity of DHCP options is limited by the The integrity of DHCP options is limited by the security of the
security of the channel over which they are provided. Physical channel over which they are provided. Physical security and
security and separation of DHCP messages from other packets are separation of DHCP messages from other packets are commonplace
commonplace methods that can reduce the possibility of attack within methods that can reduce the possibility of attack within an access
an access network; alternatively, DHCP authentication [RFC3118] can network; alternatively, DHCP authentication [RFC3118] can provide a
provide a degree of protection against modification. degree of protection against modification.
Section 2.3 describes how a LIS is authenticated by clients, using
either certificate fingerprints or a domain name certificate.
An attacker could attempt to compromise the U-NAPTR resolution. A An attacker could attempt to compromise the U-NAPTR resolution. A
more thorough description of the security considerations for U-NAPTR more thorough description of the security considerations for U-NAPTR
applications is included in [RFC4848]. applications is included in [RFC4848].
In addition to considerations related to U-NAPTR, it is important to In addition to considerations related to U-NAPTR, it is important to
recognize that the output of this is entirely dependent on its input. recognize that the output of this is entirely dependent on its input.
An attacker who can control the domain name is therefore able to An attacker who can control the domain name is therefore able to
control the final URI. Any mechanism for automatically determining control the final URI.
such a domain name MUST consider such attacks.
6. IANA Considerations 6. IANA Considerations
6.1. Registration of DHCPv4 and DHCPv6 Option Codes 6.1. Registration of DHCPv4 and DHCPv6 LIS URI Option Codes
The IANA is requested to assign an option code for the DHCPv4 option The IANA has assigned an option code of (TBD) for the DHCPv4 option
for a LIS address, as described in Section 2.2 of this document. for a LIS URI, as described in Section 2.1 of this document.
The IANA is requested to assign an option code for the DHCPv6 option The IANA has assigned an option code of (TBD) for the DHCPv6 option
for a LIS address, as described in Section 2.3 of this document. for a LIS URI, as described in Section 2.2 of this document.
6.2. Registration of a Location Server Application Service Tag 6.2. Registration of DHCPv4 and DHCPv6 LIS Certificate Fingerprints
Option Codes
The IANA has assigned an option code of (TBD) for the DHCPv4 option
for a LIS certificate fingerprints, as described in Section 2.3.1 of
this document.
The IANA has assigned an option code of (TBD) for the DHCPv6 option
for a LIS certificate fingerprints, as described in Section 2.3.2 of
this document.
6.3. Registration of a Location Server Application Service Tag
This section registers a new S-NAPTR/U-NAPTR Application Service tag This section registers a new S-NAPTR/U-NAPTR Application Service tag
for a LIS, as mandated by [RFC3958]. for a LIS, as mandated by [RFC3958].
Application Service Tag: LIS Application Service Tag: LIS
Intended usage: Identifies a service that provides a host with its Intended usage: Identifies a service that provides a host with its
location information. location information.
Defining publication: RFCXXXX Defining publication: RFCXXXX
Related publications: HELD [I-D.ietf-geopriv-http-location-delivery] Related publications: HELD [I-D.ietf-geopriv-http-location-delivery]
Contact information: The authors of this document Contact information: The authors of this document
Author/Change controller: The IESG Author/Change controller: The IESG
6.3. Registration of a Location Server Application Protocol Tag for 6.4. Registration of a Location Server Application Protocol Tag for
HELD HELD
This section registers a new S-NAPTR/U-NAPTR Application Protocol tag This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as for the HELD [I-D.ietf-geopriv-http-location-delivery] protocol, as
mandated by [RFC3958]. mandated by [RFC3958].
Application Service Tag: HELD Application Service Tag: HELD
Intended Usage: Identifies the HELD protocol. Intended Usage: Identifies the HELD protocol.
skipping to change at page 15, line 4 skipping to change at page 16, line 14
Application Service Tag: HELD Application Service Tag: HELD
Intended Usage: Identifies the HELD protocol. Intended Usage: Identifies the HELD protocol.
Applicable Service Tag(s): LIS Applicable Service Tag(s): LIS
Terminal NAPTR Record Type(s): U Terminal NAPTR Record Type(s): U
Defining Publication: RFCXXXX Defining Publication: RFCXXXX
Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery] Related Publications: HELD [I-D.ietf-geopriv-http-location-delivery]
Contact Information: The authors of this document Contact Information: The authors of this document
Author/Change Controller: The IESG Author/Change Controller: The IESG
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Leslie Daigle for her work on The authors would like to thank Leslie Daigle for her work on
U-NAPTR; Peter Koch for his feedback on the DNS aspects of this U-NAPTR; Peter Koch for feedback on how not to use DNS for discovery;
document; Andy Newton for constructive suggestions with regards to Andy Newton for constructive suggestions with regards to document
document direction; Hannes Tschofenig and Richard Barnes for input direction; Hannes Tschofenig and Richard Barnes for input and
and reviews; Dean Willis for constructive feedback; Pasi Eronen for reviews; Dean Willis for constructive feedback; Pasi Eronen for the
the certificate fingerprint concept. certificate fingerprint concept; Ralph Droms, David W. Hankins,
Damien Neil, and Bernie Volz for DHCP option format.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
skipping to change at page 17, line 41 skipping to change at page 18, line 41
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006. Option", RFC 4704, October 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-10 (work in draft-ietf-geopriv-http-location-delivery-12 (work in
progress), October 2008. progress), January 2009.
[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.
8.2. Informative References 8.2. Informative References
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
skipping to change at page 19, line 5 skipping to change at page 20, line 5
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[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-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), June 2008. progress), June 2008.
Appendix A. DHCP LIS URI Option Examples
A.1. LIS URI Only
Figure 4 shows an example LIS URI option for DHCPv6 in hexadecimal
form. This example is the simplest form, with an http: URI and no
fingerprint information.
Hexadecimal representation of LIS option, including the leading
DHCPv4 option code and length octets: [[IANA/RFC-Editor Note: Please
replace instances of "??:??" in the following example with the
hexadecimal representation of the IANA allocated DHCPv6 option code;
replace "???" with the decimal representation of the IANA allocated
DHCPv6 option code.]]
??:??:00:1d:00:68:74:74:70:3a:2f:2f:6c:69:73:2e:65:78:61:6d:
70:6c:65:2e:6f:72:67:3a:34:38:30:31:2f
Octet Value Description
------- ------- --------------------------------------------------
00-01 ??:?? LIS URI Option Code (???)
02 00:1d Option Length = 29
03 00 F-Code = 0 (URI)
04- 68:74:74:70:3a:2f:2f:6c:69:73:2e:65:78:61:6d:70:
-1f 6c:65:2e:6f:72:67:3a:34:38:30:31:2f
- LIS URI = "http://lis.example.org:4801/"
Figure 4: Example of a Simple LIS URI Option
A.2. LIS URI with Fingerprint
Figure 5 shows an example LIS URI option for DHCPv4 in hexadecimal
form. This example shows the inclusion of two fingerprints, the
first based on SHA-256, and the second based on SHA-1.
Hexadecimal representation of LIS option, including the leading
DHCPv4 option code and length octets: [[IANA/RFC-Editor Note: Please
replace two instances of "??" in the following example with the
hexadecimal representation of the IANA allocated DHCPv4 option code;
replace "???" with the decimal representation of the IANA allocated
DHCPv4 option code.]]
??:69:01:28:07:73:68:61:2d:32:35:36:49:20:77:6f:6e:64:65:72:
20:69:66:74:68:69:73:20:77:69:6c:6c:20:62:65:20:6e:6f:74:69:
63:65:64:3f:01:1a:07:73:68:61:2d:31:39:39:62:6f:74:74:6c:65:
73:6f:66:62:65:65:72:6f:6e:74:68:65:00:68:74:74:70:73:3a:2f:
2f:6c:69:73:2e:65:78:61:6d:70:6c:65:2e:6f:72:67:3a:34:38:30:
32:2f:3f:63:3d:65:78
Octet Value Description
------- ------- --------------------------------------------------
00 ?? LIS URI Option Code (???)
01 6a Option Length = 106
02 01 F-Code = 1 (Fingerprint)
03 28 F-Length = 40
04 07 Hash-Type-Len = 7
05-0b 73:68:61:2d:32:35:36
- Hash-Type = "sha-256"
0c- 49:20:77:6f:6e:64:65:72:20:69:66:74:68:69:73:20:
-2b 77:69:6c:6c:20:62:65:20:6e:6f:74:69:63:65:64:3f
- Fingerprint-Value (SHA-256 output)
2c 01 F-Code = 1 (Fingerprint)
2d 1a F-Length = 26
2e 07 Hash-Type-Len = 5
2f-33 73:68:61:2d:31
- Hash-Type = "sha-1"
34- 39:39:62:6f:74:74:6c:65:73:6f:
-47 66:62:65:65:72:6f:6e:74:68:65
- Fingerprint-Value (SHA-1 output)
48 00 F-Code = 0 (URI)
49- 68:74:74:70:73:3a:2f:2f:6c:69:73:2e:65:78:61:6d:70:
-6a 6c:65:2e:6f:72:67:3a:34:38:30:32:2f:3f:63:3d:65:78
- LIS URI = "https://lis.example.org:4802/?c=ex"
Figure 5: Example LIS URI Option with Fingerprint Data
Authors' Addresses Authors' Addresses
Martin Thomson Martin Thomson
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2915 Phone: +61 2 4221 2915
Email: martin.thomson@andrew.com Email: martin.thomson@andrew.com
skipping to change at page 22, line 4 skipping to change at line 709
James Winterbottom James Winterbottom
Andrew Andrew
PO Box U40 PO Box U40
Wollongong University Campus, NSW 2500 Wollongong University Campus, NSW 2500
AU AU
Phone: +61 2 4221 2938 Phone: +61 2 4221 2938
Email: james.winterbottom@andrew.com Email: james.winterbottom@andrew.com
URI: http://www.andrew.com/ URI: http://www.andrew.com/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 48 change blocks. 
230 lines changed or deleted 235 lines changed or added

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