[要約] RFC 6495は、SEcure Neighbor Discovery (SEND)プロトコルのSubject Key Identifier (SKI) Name Type Fieldsに関する仕様です。このRFCの目的は、SENDプロトコルで使用されるSKIフィールドの構造と使用方法を定義することです。
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).
Secure Neighbor Discovery（SEND）は、ICMPV6 Trustアンカーオプションの名前タイプフィールドを定義します。このドキュメントは、証明書の主題キー識別子（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.
このドキュメントは、インターネットエンジニアリングタスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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).
Secure Neighbor Discovery（SEND）[RFC3971]は、IPv6アドレスの[RFC3779]拡張機能を含むX.509V3証明書を利用して、NDPのIPv6プレフィックス（近隣発見プロトコル）に対するルーターの権限を認証します。[RFC3971]のセクション6.4.3のTrust Anchor（TA）オプションにより、ホストが選択したトラストアンカーの識別が可能になります。その同じセクションでは、2つの名前のタイプが定義されました：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]で説明されている証明書プロファイルが送信に採用されています。これらのドキュメントでは、証明書の主題フィールドは無意味であると宣言されており、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.
このドキュメントは、Ski X.509拡張機能を使用してTA X.509証明書を識別できるSEND TAオプションの新しい名前タイプフィールドを指定します。このドキュメントは、実験的および予約された名前タイプの値も定義します。
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].
最後に、このドキュメントは、「Trust Anchor Option（Type 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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
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]。実装は、SHA-1スキー名タイプをサポートする場合があります。
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スキー名の種類をサポートする場合があります。
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はSend TAオプションによって識別されます。TAオプションがスキーとして表されている場合、スキーはトラストアンカーの証明書のX.509スキーエクステンションに等しくなければなりません。ルーターには、認証パスが見つかった広告にTAオプションを含める必要があります。また、[RFC3971]で定義されている仕様に従って、ルーターが要求されたアンカーへのパスを見つけることができない場合、証明書なしで広告を送信する必要があります。この場合、ルーターには勧誘されたTAオプションを含める必要があります。
IANA has updated the "Trust Anchor option (Type 15) Name Type field" registry to include the following values:
IANAは、「Trust Anchor Option（Type 15）Name Type Field」レジストリを更新して、次の値を含めました。
+---------+--------------------------------------------------+
| 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を計算し、合理的に一意の識別子を提供するために合理的なランダムプロパティを持っています。同じ検証パスの2つの同一の識別子により、最初の証明書が取得されたら、ルーターが証明書の取得を停止します。上向きの証明書がホストによって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アドレスおよび識別子としての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、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年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、「Secure Neighbor Discovery（Send）の証明書プロファイルと証明書管理」、RFC 6494、2012年2月。
Authors' Addresses
著者のアドレス
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, 1180 Switzerland
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
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St Melbourne, VIC 3000 Australia
Ana Kukec Enterprise Architects 46/525 Collins St Melbourne、Vic 3000 Australia
EMail: ana.kukec@enterprisearchitects.com