Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 6495 Cisco Systems
Updates: 3971 S. Krishnan
Category: Standards Track Ericsson
ISSN: 2070-1721 A. Kukec
Enterprise Architects
February 2012
Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
Gagliano, et al. Standards Track [Page 1]
RFC 6495 SEND Name Type Registry February 2012
Table of Contents
1. Introduction
SEcure Neighbor Discovery (SEND) [RFC3971] utilizes X.509v3 certificates that include the [RFC3779] extension for IPv6 addresses to certify a router's authority over an IPv6 prefix for the NDP (Neighbor Discovery Protocol). The Trust Anchor (TA) option in Section 6.4.3 of [RFC3971] allows the identification of the Trust Anchor selected by the host. In that same section, two name types were defined: the DER Encoded X.501 Name and a Fully Qualified Domain Name (FQDN).
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Gagliano, et al. Standards Track [Page 2]
RFC 6495 SEND Name Type Registry February 2012 3. Name Type Fields in the ICMPv6 TA Option Defined in This DocumentThe following Name Type fields in the ICMPv6 TA option are defined:
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 the certification path was found. Also, following the specification defined in [RFC3971], if the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificate. In this case, the router SHOULD include the TA options that were solicited.
Gagliano, et al. Standards Track [Page 3]
RFC 6495 SEND Name Type Registry February 2012 5. IANA ConsiderationsIANA has updated the "Trust Anchor option (Type 15) Name Type field" registry to include the following values:
+---------+--------------------------------------------------+
| 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
6. 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 a TA by a host, the router will send to this host an incomplete list of certificates, causing the SEND validation to fail.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Gagliano, et al. Standards Track [Page 4]
RFC 6495 SEND Name Type Registry February 2012
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,