draft-ietf-csi-send-name-type-registry-03.txt   draft-ietf-csi-send-name-type-registry-04.txt 
Network Working Group R. Gagliano Network Working Group R. Gagliano
Internet-Draft LACNIC Internet-Draft Cisco Systems
Updates: 3971 (if approved) S. Krishnan Updates: 3971 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: October 10, 2010 A. Kukec Expires: November 19, 2010 A. Kukec
University of Zagreb University of Zagreb
April 08, 2010 May 18, 2010
SEND Name Type field Registry Subject Key Identifier (SKI) SEND Name Type fields.
draft-ietf-csi-send-name-type-registry-03 draft-ietf-csi-send-name-type-registry-04
Abstract Abstract
SEcure Neighbor Discovery (SEND) defines the Name Type field in the SEcure Neighbor Discovery (SEND) defines the Name Type field in the
Trust Anchor option. This document request to IANA the creation and ICMPv6 Trust Anchor option. This document specifies new Name Type
management of a registry for this field. This document also fields based on certificate Subject Key Identifiers (SKI).
specifies a new Name Type field based on a certificate Subject Key
Identifier (SKI).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 10, 2010. This Internet-Draft will expire on November 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SEND SKI trust anchor option Name Type field. . . . . . . . . . 5 3. Name Type fields in the ICMPv6 TA option defined in this
3.1. Processing Rules for Routers . . . . . . . . . . . . . . . 5 document . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Processing Rules for Routers . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements notation 1. Requirements notation
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] .
2. Introduction 2. Introduction
SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3 SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3
certificates that include the [RFC3779] extension for IPv6 addresses certificates that include the [RFC3779] extension for IPv6 addresses
to certify a router authority over an IPv6 prefix for NDP (Neighbor to certify a router's authority over an IPv6 prefix for the NDP
Discovery Protocol). The Trust Anchor Option in section 6.4.3 of RFC (Neighbor Discovery Protocol). The Trust Anchor (TA) Option in
3971 allows the identification of the Trust Anchor (TA) selected by section 6.4.3 of [RFC3971] allows the identification of the Trust
the host. In that same section, two name types were defined: the DER Anchor selected by the host. In that same section, two name types
Encoded X.501 Name and a Fully Qualified Domain Name (FQDN). This were defined: the DER Encoded X.501 Name and a Fully Qualified Domain
document request to IANA the creation and management of a registry Name (FQDN).
for this field.
In any Public Key Infrastructure, the subject name of a certificate In any Public Key Infrastructure, the subject name of a certificate
is only unique within each CA. Consequently, a new option to is only unique within each CA. Consequently, a new option to
identify TAs across CAs is needed. identify TAs across CAs is needed.
In [I-D.ietf-csi-send-cert] the certificate profile described in In [I-D.ietf-csi-send-cert] the certificate profile described in
[I-D.ietf-sidr-res-certs] is adopted for SEND. In these documents, [I-D.ietf-sidr-res-certs] is adopted for SEND. In these documents,
the Subject field in the certificates are declared to be meaningless the Subject field in the certificates is declared to be meaningless
and the subjectAltName field is not allowed. On the other hand, the and the subjectAltName field is not allowed. On the other hand, the
Subject Key Identifier (SKI) extension for the X.509 certificates is Subject Key Identifier (SKI) extension for the X.509 certificates is
defined as mandatory and non-critical. defined as mandatory and non-critical.
This document specifies a new Name Type field in the SEND TA option This document specifies new Name Type fields in the SEND TA option
that allows to use of the SKI X.509 extension to identify TA X.509 that allows the use of the SKI X.509 extension to identify TA X.509
certificates. certificates. This document also defines experimental and reserved
Name Types values.
3. SEND SKI trust anchor option Name Type field. Finally, this document updates the [RFC3971] by changing the Name
Type field in the ICMPv6 Trust Anchor option registration procedures
from Standards Action to Standards Action or IESG Approval.
Name Type 3. Name Type fields in the ICMPv6 TA option defined in this document
3 SHA-1 Subject Key Identifier (SKI) The following Name Type fields in the ICMPv6 TA option are defined:
The Key Identifier used here is the 160-bit SHA-1 hash of the value Name Type Description
of the DER-encoded ASN.1 bit string of the subject public key, as 0 Reserved
described in Section 4.2.1.2 of [RFC5280]. 3 SHA-1 Subject Key Identifier (SKI).
4 SHA-224 Subject Key Identifier (SKI).
5 SHA-256 Subject Key Identifier (SKI).
6 SHA-384 Subject Key Identifier (SKI).
7 SHA-512 Subject Key Identifier (SKI).
253-254 Experimental
255 Reserved
3.1. Processing Rules for Routers Name Type field values 0 and 255 are marked as reserved. This means
that they are not available for allocation.
As specified in RFC 3971, a TA is identified by the SEND TA option. When the Name Type field is set to 3, the Name Type field contains a
If the TA option is represented as a SHA-1 SKI, then the SKI must be 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string
equal to the SKI extension in the trust anchor's certificate of the subject public key, as described in Section 3.9.2 of
calculated as described in [draft-ietf-sidr-res-certs-17]. The [I-D.ietf-sidr-res-certs]. Implementations MAY support SHA-1 SKY
name type.
When the Name Type field is set to 4,5,6 or 7, the hash function will
respectively be: SHA-224, SHA-256, SHA-284 or SHA-512.
Implementations MAY support SHA-224, SHA-256, SHA-284 and SHA-512
name types.
Name Type fields 253 and 254 are marked as experimental, following
[RFC3692].
4. Processing Rules for Routers
As specified in [RFC3971], a TA is identified by the SEND TA option.
If the TA option is represented as a SKI, then the SKI MUST be equal
to the X.509 SKI extension in the trust anchor's certificate. The
router SHOULD include the TA option(s) in the advertisement for which router SHOULD include the TA option(s) in the advertisement for which
the certification path was found. Also, following [RFC3971] the certification path was found. Also, following [RFC3971]
specification, if the router is unable to find a path to the specification, if the router is unable to find a path to the
requested anchor, it SHOULD send an advertisement without any requested anchor, it SHOULD send an advertisement without any
certificate. In this case, the router SHOULD include the TA options certificate. In this case, the router SHOULD include the TA options
that were solicited. that were solicited.
4. IANA Considerations 5. IANA Considerations
IANA is requested to create and maintain a new registry entitled IANA is requested to update the Name Type field in the ICMPv6 Trust
"SEND Name Type field in ICMP TA option". This registry records Name Anchor option registry by adding the following values:
Type fields for the ICMP Trust Anchor option (15) defined in the RFC
3971.
The initial values for the "SEND Name Type field in ICMP TA option" +---------+----------------------------------------------------+
registry are: | Value | Description |
+---------+----------------------------------------------------+
| 0 | Reserved ( Section 3 ) |
| | |
| 3 | SHA-1 Subject Key Identifier (SKI) ( Section 3 ) |
| | |
| 4 | SHA-224 Subject Key Identifier (SKI) ( Section 3 ) |
| | |
| 5 | SHA-256 Subject Key Identifier (SKI) ( Section 3 ) |
| | |
| 6 | SHA-384 Subject Key Identifier (SKI) ( Section 3 ) |
| | |
| 7 | SHA-512 Subject Key Identifier (SKI) ( Section 3 ) |
| | |
| 253-254 | Experimental use ( Section 3 ) |
| | |
| 255 | Reserved ( Section 3 ) |
+---------+----------------------------------------------------+
+---------+------------------------------------------------+ Table 1: New Name Type field values in the ICMPv6 TA option
| Value | Description |
+---------+------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | DER Encoded X.501 Name (RFC 3971) |
| | |
| 2 | FQDN (RFC 3971) |
| | |
| 3 | SHA-1 Subject Key Identifier (SKI) (Section 3) |
| | |
| 253-254 | Experimental use |
| | |
| 255 | Reserved |
+---------+------------------------------------------------+
Table 1: Initial SEND Name Type field ICMP TA option registry. IANA is also requested to modify the registration procedures for the
Name Type field in the ICMPv6 Trust Anchor option registry to
Standard Action or IESG Approval.
New assignments of Name Type field is through Standards Action. 6. Security Considerations
5. Security Considerations The hash functions referenced in this document to calculate the SKI
have reasonable random properties in order to provide reasonably
unique identifiers. Two identical identifiers in the same validation
path will cause the router to stop fetching certificates once the
first certificate has been fetched. In the case that the upward
certificate was configured as TA by a host, the router will send to
this host an incomplete list of certificates, causing the SEND
validation to fail.
No security considerations. For experimental values of the Name Type field, the guidance given in
[RFC3692] about the use of experimental values needs to be followed.
6. Normative References 7. Normative References
[I-D.ietf-csi-send-cert] [I-D.ietf-csi-send-cert]
Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
profile and certificate management for SEND", profile and certificate management for SEND",
draft-ietf-csi-send-cert-03 (work in progress), draft-ietf-csi-send-cert-03 (work in progress),
March 2010. March 2010.
[I-D.ietf-sidr-res-certs] [I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-17 (work in progress), draft-ietf-sidr-res-certs-18 (work in progress), May 2010.
September 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.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
Authors' Addresses Authors' Addresses
Roque Gagliano Roque Gagliano
LACNIC Cisco Systems
Rambla Rep Mexico 6125 Avenue des Uttins 5
Montevideo, 11400 Rolle, 1180
Uruguay Switzerland
Email: roque@lacnic.net Email: rogaglia@cisco.com
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Phone: +1 514 345 7900 x42871 Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
 End of changes. 31 change blocks. 
75 lines changed or deleted 115 lines changed or added

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