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
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
主题密钥标识符（SKI）安全邻居发现（发送）名称类型字段
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).
安全邻居发现（SEND）在ICMPv6信任锚选项中定义名称类型字段。本文档基于证书使用者密钥标识符（SKI）指定新的名称类型字段。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
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).
安全邻居发现（SEND）[RFC3971]利用X.509v3证书（包括IPv6地址的[RFC3779]扩展）来验证路由器对NDP（邻居发现协议）IPv6前缀的权限。[RFC3971]第6.4.3节中的信任锚（TA）选项允许识别主机选择的信任锚。在同一节中，定义了两种名称类型：DER编码的X.501名称和完全限定域名（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.
在任何公钥基础设施中，证书的使用者名称仅在每个证书颁发机构（CA）中是唯一的。因此，需要一个新的选项来识别CAs中的TA。
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.
在[RFC6494]中，发送采用[RFC6487]中描述的证书配置文件。在这些文档中，证书中的Subject字段被声明为无意义，并且不允许subjectAltName字段。另一方面，X.509证书的主题密钥标识符（SKI）扩展被定义为强制性和非关键性的。
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.
本文档在SEND TA选项中指定了新的名称类型字段，允许使用SKI X.509扩展来标识TA X.509证书。本文档还定义了实验名称类型和保留名称类型值。
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].
最后，本文件通过将“信任锚选项（类型15）名称类型字段”注册程序从标准行动更改为标准行动或IESG批准[RFC5226]来更新[RFC3971]。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following Name Type fields in the ICMPv6 TA option are defined:
在ICMPv6 TA选项中定义了以下名称类型字段：
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
名称类型说明0保留3 SHA-1主题密钥标识符（SKI）4 SHA-224主题密钥标识符（SKI）5 SHA-256主题密钥标识符（SKI）6 SHA-384主题密钥标识符（SKI）7 SHA-512主题密钥标识符（SKI）253-254保留
Name Type field values 0 and 255 are marked as reserved. This means that they are not available for allocation.
名称类型字段值0和255标记为保留。这意味着它们不可分配。
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.
当名称类型字段设置为3时，名称类型字段包含主题公钥的DER编码ASN.1位字符串值的160位SHA-1散列，如[RFC6487]第4.8.2节所述。实现可能支持SHA-1 SKI名称类型。
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.
当名称类型字段设置为4、5、6或7时，哈希函数将分别为：SHA-224、SHA-256、SHA-384或SHA-512。实现可能支持SHA-224、SHA-256、SHA-384和SHA-512 SKI名称类型。
Name Type fields 253 and 254 are marked as experimental, per guidance in [RFC3692].
根据[RFC3692]中的指南，名称类型字段253和254标记为实验性字段。
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.
如[RFC3971]所述，TA由发送TA选项标识。如果TA选项表示为SKI，则SKI必须等于信任锚证书中的X.509 SKI扩展。路由器应在找到认证路径的公告中包含TA选项。此外，根据[RFC3971]中定义的规范，如果路由器无法找到到请求的锚的路径，则应发送不带任何证书的播发。在这种情况下，路由器应包括请求的TA选项。
IANA has updated the "Trust Anchor option (Type 15) Name Type field" registry to include the following values:
IANA已更新“信任锚选项（类型15）名称类型字段”注册表，以包括以下值：
+---------+--------------------------------------------------+
| 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) |
+---------+--------------------------------------------------+
+---------+--------------------------------------------------+
| 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
表1:ICMPv6 TA选项中的新名称类型字段值
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].
IANA还将“信任锚选项（类型15）名称类型字段”注册表的注册程序修改为标准行动或IESG批准[RFC5226]。
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.
本文档中用于计算SKI的哈希函数具有合理的随机属性，以便提供合理的唯一标识符。同一验证路径中的两个相同标识符将导致路由器在获取第一个证书后停止获取证书。如果主机将向上证书配置为TA，路由器将向该主机发送不完整的证书列表，导致发送验证失败。
For experimental values of the Name Type field, the guidance given in [RFC3692] about the use of experimental values needs to be followed.
对于名称类型字段的实验值，需要遵循[RFC3692]中关于实验值使用的指南。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779]Lynn，C.，Kent，S.，和K.Seo，“IP地址和AS标识符的X.509扩展”，RFC 3779，2004年6月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，2012年2月。
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)", RFC 6494, February 2012.
[RFC6494]Gagliano，R.，Krishnan，S.，和A.Kukec，“安全邻居发现（SEND）的证书配置文件和证书管理”，RFC 64942012年2月。
Authors' Addresses
作者地址
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, 1180 Switzerland
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle，1180瑞士
EMail: rogaglia@cisco.com
EMail: rogaglia@cisco.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St Melbourne, VIC 3000 Australia
澳大利亚维多利亚州墨尔本柯林斯街46/525号Ana Kukec Enterprise Architects，邮编：3000
EMail: ana.kukec@enterprisearchitects.com
EMail: ana.kukec@enterprisearchitects.com