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).
セキュアな近隣探索（SEND）はICMPv6のトラストアンカーオプションで名前タイプフィールドを定義します。このドキュメントでは、証明書のサブジェクトキー識別子（スキー）に基づいて、新しい名前タイプのフィールドを指定します。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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).
セキュアな近隣探索（SEND）[RFC3971]は、[RFC3779]はIPv6の拡張は、NDP（近隣探索プロトコル）のためのIPv6プレフィックス上でルータの権限を証明するためにアドレスを含めるのX.509v3証明書を利用しています。 [RFC3971]のセクション6.4.3にトラストアンカー（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）内でのみ一意です。その結果、CAの間での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.
この文書では、TAのX.509証明書を識別するために、SKI 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].
標準アクションまたはIESG承認に「トラストアンカーオプション（タイプ15）名前タイプフィールド」標準アクションから登録手続きを変更することで最終的に、このドキュメントの更新[RFC3971] [RFC5226]。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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に設定されている場合の、セクション4.8.2で説明したように、名前タイプフィールドは、サブジェクト公開鍵のDER符号化されたASN.1ビット列の値の160ビットSHA-1ハッシュを含んでいます[RFC6487]。実装は、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].
タイプフィールド253と254に名前を付け、[RFC3692]の指針につき、実験としてマークされています。
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 SENDオプションによって識別されます。 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) |
+---------+--------------------------------------------------+
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はまた、[RFC5226]標準アクションまたはIESG承認に「トラストアンカーオプション（タイプ15）の名前を入力フィールド」レジストリのための登録手続きを変更しました。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]リン、C.、ケント、S.、およびK.ソ、 "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.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]ヒューストン、G.、マイケルソン、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]ガリアーノ、R.、クリシュナン、S.、および "セキュア近隣探索のための証明書プロファイルおよび証明書の管理（SEND）" A. Kukec、RFC 6494、2012年2月。
Authors' Addresses
著者のアドレス
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, 1180 Switzerland
ロケガリアーノシスコシステムズアベニューデUttins 5ロル、1180年スイス
EMail: rogaglia@cisco.com
メールアドレス：rogaglia@cisco.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：+1 514 345 7900 x42871メール：suresh.krishnan@ericsson.com
Ana Kukec Enterprise Architects 46/525 Collins St Melbourne, VIC 3000 Australia
アナKukecエンタープライズアーキテクト525分の46コリンズセントメルボルン、VIC 3000オーストラリア
EMail: ana.kukec@enterprisearchitects.com
メールアドレス：ana.kukec@enterprisearchitects.com