SEND SKI name types: Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
New SEND Trust Anchor name types that identify a trust anchor by a hash of its Subject Key Identifier.
Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields", RFC 6495, DOI 10.17487/RFC6495, February 2012, <https://www.rfc-editor.org/info/rfc6495>.
@misc{rfc6495,
series = {Request for Comments},
number = 6495,
howpublished = {RFC 6495},
publisher = {RFC Editor},
doi = {10.17487/RFC6495},
url = {https://www.rfc-editor.org/info/rfc6495},
author = {R. Gagliano and S. Krishnan and A. Kukec},
title = {{Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields}},
pagetotal = 5,
year = 2012,
month = feb,
} RFC text
Contents
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
Abstract
SEcure Neighbor Discovery (SEND) defines the Name Type field in the
ICMPv6 Trust Anchor option. This document specifies new Name Type
fields based on certificate Subject Key Identifiers (SKIs).
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6495.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
3. Name Type Fields in the ICMPv6 TA Option Defined in This
Document . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Processing Rules for Routers . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
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).
In any Public Key Infrastructure, the subject name of a certificate
is only unique within each Certification Authority (CA).
Consequently, a new option to identify TAs across CAs is needed.
In [RFC6494], the certificate profile described in [RFC6487] is
adopted for SEND. In these documents, the Subject field in the
certificates is declared to be meaningless and the subjectAltName
field is not allowed. On the other hand, the Subject Key Identifier
(SKI) extension for the X.509 certificates is defined as mandatory
and non-critical.
This document specifies new Name Type fields in the SEND TA option
that allows the use of the SKI X.509 extension to identify TA X.509
certificates. This document also defines experimental and reserved
Name Types values.
Finally, this document updates [RFC3971] by changing the "Trust
Anchor option (Type 15) Name Type field" registration procedures from
Standards Action to Standards Action or IESG Approval [RFC5226].
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].
3. Name Type Fields in the ICMPv6 TA Option Defined in This Document
The following Name Type fields in the ICMPv6 TA option are defined:
Name Type Description
0 Reserved
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
Name Type field values 0 and 255 are marked as reserved. This means
that they are not available for allocation.
When the Name Type field is set to 3, the Name Type field contains a
160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string
of the subject public key, as described in Section 4.8.2 of
[RFC6487]. Implementations MAY support SHA-1 SKI 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-384, or SHA-512.
Implementations MAY support SHA-224, SHA-256, SHA-384, and SHA-512
SKI name types.
Name Type fields 253 and 254 are marked as experimental, per guidance
in [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
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.
5. IANA Considerations
IANA 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
IANA has also modified the registration procedures for the "Trust
Anchor option (Type 15) Name Type field" registry to Standards Action
or IESG Approval [RFC5226].
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.
For experimental values of the Name Type field, the guidance given in
[RFC3692] about the use of experimental values needs to be followed.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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
Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure 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.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
February 2012.
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, February 2012.
Authors' Addresses
Roque Gagliano
Cisco Systems
Avenue des Uttins 5
Rolle, 1180
Switzerland
EMail: rogaglia@cisco.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Ana Kukec
Enterprise Architects
46/525 Collins St
Melbourne, VIC 3000
Australia
EMail: ana.kukec@enterprisearchitects.com
AI ELI5
On this page
§1Why New Name Types
SEcure Neighbor Discovery (SEND, RFC 3971) uses X.509v3 certificates with the RFC 3779 extension to certify a router's authority over an IPv6 prefix. The Trust Anchor (TA) option lets a host identify the trust anchor it selected, and RFC 3971 defined two name types: a DER Encoded X.501 Name and a Fully Qualified Domain Name.
A certificate subject name is only unique within each Certification Authority, so a way to identify TAs across CAs is needed. In the certificate profile adopted for SEND by RFC 6494 and RFC 6487, the Subject field is declared meaningless and subjectAltName is not allowed, but the Subject Key Identifier (SKI) extension is mandatory and non-critical.
Two different authorities can have the same name, so names are not enough. A key fingerprint is different for each one.
§2The New Name Type Values
The Name Type field in the ICMPv6 TA option gets these values: 3 SHA-1 SKI, 4 SHA-224 SKI, 5 SHA-256 SKI, 6 SHA-384 SKI and 7 SHA-512 SKI. Values 0 and 255 are reserved and not available for allocation, and 253-254 are experimental per RFC 3692.
Type 3 carries a 160-bit SHA-1 hash of the DER-encoded ASN.1 bit string of the subject public key, as described in Section 4.8.2 of RFC 6487. Types 4 to 7 use SHA-224, SHA-256, SHA-384 and SHA-512 respectively. Implementations MAY support these name types.
Each number says which fingerprint recipe was used. A few numbers are kept back for testing or for later.
- 0Reserved — Not available for allocation.
- 3SHA-1 SKI — 160-bit SHA-1 hash of the subject public key.
- 4SHA-224 SKI — SKI hashed with SHA-224.
- 5SHA-256 SKI — SKI hashed with SHA-256.
- 6SHA-384 SKI — SKI hashed with SHA-384.
- 7SHA-512 SKI — SKI hashed with SHA-512.
- 253-254Experimental — Experimental use.
- 255Reserved — Not available for allocation.
§3Router Processing Rules
If the TA option is represented as an SKI, the SKI MUST equal the X.509 SKI extension in the trust anchor's certificate. The router SHOULD include the TA options in the advertisement for which the certification path was found.
As in RFC 3971, if the router cannot find a path to the requested anchor, it SHOULD send an advertisement without any certificate, and SHOULD include the TA options that were solicited.
The router checks that the fingerprint matches the real authority. If it cannot find the authority, it says so without sending any certificate.
§4IANA and Security Considerations
IANA updated the "Trust Anchor option (Type 15) Name Type field" registry with the values above. The registration procedure changed from Standards Action to Standards Action or IESG Approval.
The hashes have reasonable random properties, giving reasonably unique identifiers. If two identical identifiers occur in the same validation path, the router stops fetching certificates after the first one. If that certificate was configured as a TA by a host, the router sends an incomplete list and SEND validation fails.
The official list of numbers was updated. If two authorities ever got the same fingerprint, the check could fail, which is why the hashes need to be nearly unique.