[要約] RFC 6786は、PANA属性値ペアのプロトコルを暗号化するための方法について説明しています。このRFCの目的は、ネットワークアクセスの認証を保護するためのセキュリティ手法を提供することです。
Internet Engineering Task Force (IETF) A. Yegin
Request for Comments: 6786 Samsung
Category: Standards Track R. Cragie
ISSN: 2070-1721 Gridmerge Ltd.
November 2012
Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs
ネットワークアクセスの認証を実行するためのプロトコルの暗号化（PANA）属性と値のペア
Abstract
概要
This document specifies a mechanism for delivering the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs (AVPs) in encrypted form.
このドキュメントでは、ネットワークアクセス（PANA）属性と値のペア（AVP）の認証を運ぶためのプロトコルを暗号化された形式で配信するメカニズムを指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6786.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6786で入手できます。
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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................2
2. Details .........................................................3
3. Encryption Keys .................................................3
4. Encryption-Algorithm AVP ........................................4
4.1. AES128_CTR Encryption Algorithm ............................5
5. Encryption-Encap AVP ............................................6
6. Encryption Policy ...............................................6
6.1. Encryption Policy Specification ............................7
7. Security Considerations .........................................8
7.1. AES-CTR Security Considerations ............................9
8. IANA Considerations .............................................9
8.1. PANA AVP Codes .............................................9
8.2. PANA Encryption-Algorithm AVP Values .......................9
8.3. PANA AVP Codes Encryption Policy ..........................10
9. Acknowledgments ................................................10
10. Normative References ..........................................10
PANA [RFC5191] is a UDP-based protocol to perform an Extensible Authentication Protocol (EAP) authentication between a PANA Client (PaC) and a PANA Authentication Agent (PAA).
PANA [RFC5191]は、PANAクライアント（PaC）とPANA認証エージェント（PAA）の間で拡張認証プロトコル（EAP）認証を実行するためのUDPベースのプロトコルです。
Various types of payload are exchanged as part of the network access authentication and authorization. These payloads are carried in PANA Attribute-Value Pairs (AVPs). AVPs can be integrity protected using the AUTH AVP when EAP authentication generates cryptographic keying material. AVPs are transmitted in the clear (i.e., not encrypted).
さまざまなタイプのペイロードが、ネットワークアクセスの認証と承認の一部として交換されます。これらのペイロードは、PANA属性値ペア（AVP）で伝送されます。 AVPは、EAP認証が暗号化キー生成情報を生成するときに、AUTH AVPを使用して整合性を保護できます。 AVPは平文で送信されます（つまり、暗号化されません）。
Certain payload types need to be delivered privately (e.g., network keys, private identifiers, etc.). This document defines a mechanism for applying encryption to selected AVPs.
特定のペイロードタイプは、プライベートに配信する必要があります（ネットワークキー、プライベート識別子など）。このドキュメントでは、選択したAVPに暗号化を適用するメカニズムを定義しています。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document extends the AVP set defined in Section 8 of [RFC5191] by defining two new AVPs: the Encryption-Algorithm AVP (see Section 4) and the Encryption-Encap AVP (see Section 5). Two new encryption keys, PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY, are defined to encrypt AVPs from the PaC to the PAA and AVPs from the PAA to the PaC, respectively (see Section 3).
このドキュメントは、[RFC5191]のセクション8で定義されたAVPセットを拡張し、暗号化アルゴリズムAVP（セクション4を参照）と暗号化エンキャップAVP（セクション5を参照）の2つの新しいAVPを定義します。 2つの新しい暗号化キー、PANA_PAC_ENCR_KEYとPANA_PAA_ENCR_KEYは、それぞれPaCからPAAへのAVPとPAAからPaCへのAVPを暗号化するために定義されています（セクション3を参照）。
When encryption is needed, the required algorithm is negotiated as follows: the PAA SHALL send the initial PANA-Auth-Request carrying one or more Encryption-Algorithm AVPs supported by it. The PaC SHALL select one of the algorithms from this AVP, and it SHALL respond with the initial PANA-Auth-Answer carrying one Encryption-Algorithm AVP for the selected algorithm. Once PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY have been generated, a PANA message MAY contain an Encryption-Encap AVP.
暗号化が必要な場合、必要なアルゴリズムは次のようにネゴシエートされます。PAAは、サポートする1つ以上の暗号化アルゴリズムAVPを運ぶ最初のPANA-Auth-Requestを送信する必要があります（SHALL）。 PaCはこのAVPからアルゴリズムの1つを選択するものとし（SHALL）、選択したアルゴリズムに対して1つの暗号化アルゴリズムAVPを伝送する最初のPANA-Auth-Answerで応答するものとします（SHALL）。 PANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYが生成されると、PANAメッセージにEncryption-Encap AVPが含まれる場合があります。
PANA_PAC_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PaC to the PAA.
PANA_PAC_ENCR_KEYは、PaCからPAAへのPANAメッセージで送信されるEncryption-Encap AVPのAVPペイロードを暗号化するために使用されます。
PANA_PAC_ENCR_KEY SHALL be computed according to the following formula:
PANA_PAC_ENCR_KEYは、次の式に従って計算する必要があります。
PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID)
Pan_pach_ncir_kiy = prof +（musk、 "itf pana pachnsir" | e_par | e_pan | pach_nons | pa_nons | ki_id
PANA_PAA_ENCR_KEY is used for encrypting the AVP payload of the Encryption-Encap AVP sent in a PANA message from the PAA to the PaC. PANA_PAA_ENCR_KEY SHALL be computed according to the following formula:
PANA_PAA_ENCR_KEYは、PAAからPaCへのPANAメッセージで送信されるEncryption-Encap AVPのAVPペイロードを暗号化するために使用されます。 PANA_PAA_ENCR_KEYは、次の式に従って計算する必要があります。
PANA_PAA_ENCR_KEY = prf+(MSK, "IETF PANA PAA Encr" | I_PAR | I_PAN | PaC_nonce | PAA_nonce | Key_ID)
Pan_pa_ncir_kiy = prof +（Musk、 "itf pana pa ncir" | e_par | e_pan | pach_nons | pa_nons | kiy_id）
In both cases:
両方の場合において：
- The prf+ function is defined in the Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996].
- prf +関数は、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC5996]で定義されています。
- The pseudo-random function (PRF) to be used for the prf+ function SHALL be negotiated using the PRF-Algorithm AVP in the initial PANA-Auth-Request and PANA-Auth-Answer exchange with the 'S' (Start) bit set as described in Section 4.1 of [RFC5191].
- prf +関数に使用される疑似ランダム関数（PRF）は、最初のPANA-Auth-RequestおよびPANA-Auth-Answer交換でPRF-Algorithm AVPを使用してネゴシエートされ、 'S'（開始）ビットが次のように設定されます。 [RFC5191]のセクション4.1で説明されています。
- MSK is the master session key (MSK) generated by the EAP method [RFC3748]. PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY MUST be recalculated whenever a new MSK is generated by the EAP method.
- MSKは、EAPメソッド[RFC3748]によって生成されるマスターセッションキー（MSK）です。 PANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYは、新しいMSKがEAPメソッドによって生成されるたびに再計算する必要があります。
- "IETF PANA PaC Encr" and "IETF PANA PAA Encr" are the ASCII code representations of the respective non-NULL terminated strings (excluding the double quotes around them).
- 「IETF PANA PaC Encr」および「IETF PANA PAA Encr」は、それぞれのNULL以外で終了する文字列（それらを囲む二重引用符を除く）のASCIIコード表現です。
- I_PAR and I_PAN are the initial PANA-Auth-Request and PANA-Auth-Answer messages (the PANA header and the following PANA AVPs) with the 'S' (Start) bit set, respectively.
- I_PARとI_PANは、最初のPANA-Auth-RequestメッセージとPANA-Auth-Answerメッセージ（PANAヘッダーと次のPANA AVP）であり、それぞれ「S」（開始）ビットが設定されています。
- PaC_nonce and PAA_nonce are values of the Nonce AVP carried in the first non-initial PANA-Auth-Answer and PANA-Auth-Request messages in the authentication and authorization phase or the first PANA-Auth-Answer and PANA-Auth-Request messages in the re-authentication phase, respectively.
- PaC_nonceおよびPAA_nonceは、認証および承認フェーズの最初の非初期PANA-Auth-AnswerおよびPANA-Auth-Requestメッセージ、または最初のPANA-Auth-AnswerおよびPANA-Auth-Requestメッセージで運ばれるNonce AVPの値です。それぞれ再認証フェーズ。
- Key_ID is the value of the Key-Id AVP.
- Key_IDは、Key-Id AVPの値です。
The length of PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY depends on the encryption algorithm in use.
PANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYの長さは、使用している暗号化アルゴリズムによって異なります。
The Encryption-Algorithm AVP (AVP code 13) is used for conveying the encryption algorithm to be used with the Encryption-Encap AVP. The AVP value data is of type Unsigned32.
暗号化アルゴリズムAVP（AVPコード13）は、Encryption-Encap AVPで使用される暗号化アルゴリズムを伝達するために使用されます。 AVP値データのタイプはUnsigned32です。
Only one encryption algorithm identifier AES128_CTR (code 1) is identified by this document. Encryption algorithm identifier values other than 1 are reserved for future use. Future specifications are allowed to extend this list.
このドキュメントでは、1つの暗号化アルゴリズム識別子AES128_CTR（コード1）のみが識別されています。 1以外の暗号化アルゴリズム識別子の値は、将来の使用のために予約されています。今後の仕様では、このリストを拡張することができます。
AES128_CTR: 1
AES128_CTR：1
In the absence of an application profile specifying otherwise, all implementations SHALL support AES128_CTR.
特に指定しないアプリケーションプロファイルがない場合、すべての実装はAES128_CTRをサポートする必要があります（SHALL）。
The AES128_CTR encryption algorithm uses the AES-CTR (Counter) mode of operation as specified in [NIST_SP800_38A] using the AES-128 block cipher. The formatting function and counter generation function, as specified in Appendix A of [NIST_SP800_38C], are used with the following parameters:
AES128_CTR暗号化アルゴリズムは、AES-128ブロック暗号を使用して、[NIST_SP800_38A]で指定されているAES-CTR（カウンター）動作モードを使用します。 [NIST_SP800_38C]の付録Aで指定されているフォーマット関数とカウンター生成関数は、次のパラメーターと共に使用されます。
n = 12, q = 3
n = 12、q = 3
The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session ID, and a 4-octet Sequence Number in that order where each 4-octet value is encoded in network byte order. The Session ID and Sequence Number values SHALL be the same as those in the PANA message carrying the key Encryption-Encap AVP. The Key-Id value SHALL be the same as the one used for deriving PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY. The output blocks of the encryption processing are encoded as OctetString data in the Value field of a Encryption-Encap AVP.
12オクテットのナンスは、4オクテットのKey-Id、4オクテットのセッションID、4オクテットのシーケンス番号の順に構成され、各4オクテットの値はネットワークバイトオーダーでエンコードされます。セッションIDとシーケンス番号の値は、キーEncryption-Encap AVPを運ぶPANAメッセージの値と同じである必要があります。 Key-Id値は、PANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYの導出に使用されるものと同じである必要があります。暗号化処理の出力ブロックは、Encryption-Encap AVPのValueフィールドのOctetStringデータとしてエンコードされます。
Note that the first counter block used for encryption is Ctr_1, where "_1" denotes "subscript 1" as described in Appendix A.3 of [NIST_SP800_38C]. For example, given the following:
[NIST_SP800_38C]の付録A.3で説明されているように、暗号化に使用される最初のカウンターブロックはCtr_1です。「_ 1」は「添え字1」を示します。たとえば、次の場合：
Key-Id = 0x55667788, Session ID = 0xaabbccdd, Sequence Number = 0x11223344
Key-Id = 0x55667788、セッションID = 0xaabbccdd、シーケンス番号= 0x11223344
The first counter block used for encryption will be:
暗号化に使用される最初のカウンターブロックは次のとおりです。
0x0255667788aabbccdd11223344000001
where the initial 0x02 represents the Flags field of the counter block.
ここで、最初の0x02は、カウンターブロックのFlagsフィールドを表します。
The nonce meets the requirement of uniqueness-per-key usage provided that the sequence number does not wrap. Therefore, for the purpose of generating new keys:
nonceは、シーケンス番号が折り返されない限り、キーごとの一意性の要件を満たします。したがって、新しいキーを生成するために：
- If Encryption-Encap AVPs are being sent from the PaC to the PAA and the sequence number is about to wrap, the PaC SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191].
- Encryption-Encap AVPがPaCからPAAに送信されており、シーケンス番号がラップしようとしている場合、[RFC5191]のセクション4.3で説明されているように、PaCはPANA再認証を開始する必要があります（SHALL）。
- If Encryption-Encap AVPs are being sent from the PAA to the PaC and the sequence number is about to wrap, the PAA SHALL initiate PANA re-authentication as described in Section 4.3 of [RFC5191].
- Encryption-Encap AVPがPAAからPaCに送信され、シーケンス番号がラップしようとしている場合、PAAは[RFC5191]のセクション4.3で説明されているように、PANA再認証を開始する必要があります（SHALL）。
Re-authentication ensures the generation of a new MSK [RFC3748] and thus a new PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY.
再認証により、新しいMSK [RFC3748]が生成されるため、新しいPANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYが生成されます。
The Encryption-Encap AVP (AVP code 12) is used to encrypt one or more PANA AVPs. The format of the Encryption-Encap AVP depends on the negotiated encryption algorithm.
Encryption-Encap AVP（AVPコード12）は、1つ以上のPANA AVPを暗号化するために使用されます。 Encryption-Encap AVPの形式は、ネゴシエートされた暗号化アルゴリズムによって異なります。
When the negotiated encryption algorithm identifier is AES128_CTR (code 1), AVP data payload is occupied by the encrypted AVPs.
ネゴシエートされた暗号化アルゴリズム識別子がAES128_CTR（コード1）である場合、AVPデータペイロードは暗号化されたAVPによって占有されます。
There SHALL be only one Encryption-Encap AVP in a PANA message. All AVPs that require encryption SHALL be encapsulated within the Encryption-Encap AVP.
PANAメッセージには、Encryption-Encap AVPが1つだけ存在する必要があります。暗号化を必要とするすべてのAVPは、Encryption-Encap AVP内にカプセル化される必要があります。
The Encryption-Encap AVP uses either PANA_PAC_ENCR_KEY or PANA_PAA_ENCR_KEY, and the encryption algorithm negotiated by the Encryption-Algorithm AVP. The Encryption-Encap AVP SHALL only be used if the EAP method generates cryptographic keys (specifically, the MSK [RFC3748]).
Encryption-Encap AVPは、PANA_PAC_ENCR_KEYまたはPANA_PAA_ENCR_KEYのいずれかと、Encryption-Algorithm AVPによってネゴシエートされた暗号化アルゴリズムを使用します。 Encryption-Encap AVPは、EAP方式が暗号化キー（具体的には、MSK [RFC3748]）を生成する場合にのみ使用する必要があります（SHALL）。
The Encryption-Encap AVP MAY be used in a PANA message from the PaC to the PAA when the encryption algorithm has been successfully negotiated and once PANA_PAC_ENCR_KEY has been generated.
Encryption-Encap AVPは、暗号化アルゴリズムが正常にネゴシエートされ、PANA_PAC_ENCR_KEYが生成されると、PaCからPAAへのPANAメッセージで使用される場合があります。
The Encryption-Encap AVP MAY be used in a PANA message from the PAA to the PaC when the encryption algorithm has been successfully negotiated and once PANA_PAA_ENCR_KEY has been generated.
Encryption-Encap AVPは、暗号化アルゴリズムが正常にネゴシエートされ、PANA_PAA_ENCR_KEYが生成されると、PAAからPaCへのPANAメッセージで使用される場合があります。
The Encryption-Encap AVP MAY be used in the very first PANA message carrying the Result-Code AVP set to PANA_Success value and any subsequent message within the same PANA session.
Encryption-Encap AVPは、Result-Code AVPがPANA_Success値に設定された最初のPANAメッセージと、同じPANAセッション内の後続のメッセージで使用される場合があります。
The specification of any AVP SHOULD state that the AVP either shall or shall not be encrypted using the Encryption-Encap AVP. The specification of an AVP MAY state that the AVP may (or may not) be encrypted using the Encryption-Encap AVP. The specification SHOULD use a table in the format specified in Section 6.1. If the specification of an AVP is silent about whether the AVP shall or shall not be encrypted using the Encryption-Encap AVP, this implies that the AVP MAY be encrypted using the Encryption-Encap AVP.
AVPの仕様には、AVPがEncryption-Encap AVPを使用して暗号化されるか、または暗号化されないことが記載されている必要があります。 AVPの仕様は、AVPがEncryption-Encap AVPを使用して暗号化される場合とされない場合があることを示す場合があります。仕様では、セクション6.1で指定された形式のテーブルを使用する必要があります（SHOULD）。 AVPの仕様が、Encryption-Encap AVPを使用してAVPを暗号化するかどうかについてサイレントである場合、これは、AVPがEncryption-Encap AVPを使用して暗号化される可能性があることを意味します。
This section defines a table format for the specification of whether an AVP shall or shall not be encrypted using the Encryption-Encap AVP.
このセクションでは、AVPがEncryption-Encap AVPを使用して暗号化されるかどうかを指定するためのテーブル形式を定義します。
The table uses the following symbols:
この表では次の記号を使用しています。
Y: The AVP SHALL be encrypted using the Encryption-Encap AVP. If the AVP is encountered not encrypted using the Encryption-Encap AVP, it SHALL be considered invalid and the message containing the AVP SHALL be discarded.
Y：AVPは、Encryption-Encap AVPを使用して暗号化する必要があります（SHALL）。 Encryption-Encap AVPを使用して暗号化されていないAVPが検出された場合、AVPは無効と見なされ（SHALL）、AVPを含むメッセージは破棄されるものとします（SHALL）。
N: The AVP SHALL NOT be encrypted using the Encryption-Encap AVP. If the AVP is encountered encrypted using the Encryption-Encap AVP, it SHALL be considered invalid and the message containing the AVP SHALL be discarded.
N：AVPは、Encryption-Encap AVPを使用して暗号化してはなりません（SHALL NOT）。 Encryption-Encap AVPを使用して暗号化されたAVPが検出された場合、そのAVPは無効であると見なされ（SHALL）、AVPを含むメッセージは破棄される必要があります（SHALL）。
X: The AVP MAY be encrypted using the Encryption-Encap AVP. If the AVP is encountered either encrypted or not encrypted using the Encryption-Encap AVP, it SHALL be considered valid.
X：AVPは、Encryption-Encap AVPを使用して暗号化される場合があります。 Encryption-Encap AVPを使用してAVPが暗号化されているか、暗号化されていない場合、AVPは有効であると見なされます。
The legitimate occurrence of unencrypted AVPs and AVPs after decryption and unencapsulation SHALL be subject to the AVP Occurrence Table (Figure 4 in [RFC5191]).
暗号化されていないAVPおよび暗号化解除とカプセル化解除後のAVPの正当な発生は、AVP発生テーブルの対象となるものとします（[RFC5191]の図4）。
The following table shows the encryption requirements for the existing AVPs defined in [RFC5191]:
次の表は、[RFC5191]で定義されている既存のAVPの暗号化要件を示しています。
Attribute Name |Enc|
----------------------+---+
AUTH | N |
EAP-Payload | X |
Integrity-Algorithm | N |
Key-Id | N |
Nonce | N |
PRF-Algorithm | N |
Result-Code | N |
Session-Lifetime | X |
Termination-Cause | X |
----------------------+---+
The following table shows the encryption requirements for the AVPs defined in [RFC6345]:
次の表は、[RFC6345]で定義されているAVPの暗号化要件を示しています。
Attribute Name |Enc|
----------------------+---+
PaC-Information | N |
Relayed-Message | N |
----------------------+---+
The following table shows the encryption requirements for the AVPs defined in this document:
次の表は、このドキュメントで定義されているAVPの暗号化要件を示しています。
Attribute Name |Enc|
----------------------+---+
Encryption-Algorithm | N |
Encryption-Encap | N |
----------------------+---+
The following table is an example showing the encryption requirements for a newly defined AVP, Example-AVP:
次の表は、新しく定義されたAVP、Example-AVPの暗号化要件を示す例です。
Attribute Name |Enc|
----------------------+---+
Example-AVP | Y |
----------------------+---+
The guidance for specifying the encryption requirements for a newly defined AVP is as follows:
新しく定義されたAVPの暗号化要件を指定するためのガイダンスは次のとおりです。
Y: If the payload needs privacy against eavesdroppers (e.g., carrying a secret key).
Y：ペイロードが盗聴者に対するプライバシーを必要とする場合（たとえば、秘密鍵を運ぶ）。
N: If the payload may need to be observed by on-path network elements (i.e., subject to deep packet inspection).
N：ペイロードをパス上のネットワーク要素で監視する必要がある場合（詳細なパケット検査の対象）。
X: If neither concern applies.
X：どちらの懸念も当てはまらない場合。
PANA_PAC_ENCR_KEY and PANA_PAA_ENCR_KEY are secret keys shared between the PaC and the PAA. They SHALL NOT be used for purposes other than those specified in this document. Compromise of these keys would lead to compromise of the secret information protected by these keys.
PANA_PAC_ENCR_KEYおよびPANA_PAA_ENCR_KEYは、PaCとPAAの間で共有される秘密鍵です。このドキュメントで指定されている以外の目的で使用することはできません。これらの鍵の侵害は、これらの鍵によって保護されている秘密情報の侵害につながります。
The use of AES-CTR encryption has its own security considerations, which are detailed in the Security Considerations section of [RFC3686]. Specifically:
AES-CTR暗号化の使用には、独自のセキュリティに関する考慮事項があります。これについては、[RFC3686]のセキュリティに関する考慮事項のセクションで詳しく説明しています。具体的には：
- The nonce specified in Section 4.1 meets the requirement of uniqueness-per-key usage.
- セクション4.1で指定されたnonceは、キーごとの一意性の使用の要件を満たしています。
- Section 4.1 of [RFC5191] states that if the EAP method generates cryptographic keys, an AUTH AVP will always be present in every PANA message after key generation. Therefore, an Encryption-Encap AVP will always be sent in conjunction with an AUTH AVP. This meets the requirement of a companion authentication function.
- [RFC5191]のセクション4.1は、EAP方式が暗号鍵を生成する場合、鍵の生成後、AUTH AVPがすべてのPANAメッセージに常に存在することを述べています。したがって、Encryption-Encap AVPは常にAUTH AVPと共に送信されます。これは、コンパニオン認証機能の要件を満たしています。
As described in Sections 4 and 5, and following the IANA allocation policy on PANA messages [RFC5872], two PANA AVP codes and one set of AVP values have been registered. An additional encryption policy for AVP codes has also been registered.
セクション4と5で説明されているように、PANAメッセージ[RFC5872]のIANA割り当てポリシーに従って、2つのPANA AVPコードと1セットのAVP値が登録されています。 AVPコードの追加の暗号化ポリシーも登録されています。
The following AVP codes have been registered in the "AVP Codes" sub-registry of the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry:
次のAVPコードは、「ネットワークアクセスの認証を実行するためのプロトコル（PANA）パラメータ」レジストリの「AVPコード」サブレジストリに登録されています。
o A standard AVP code of 12 for the Encryption-Encap AVP.
o Encryption-Encap AVPの標準AVPコード12。
o A standard AVP code of 13 for the Encryption-Algorithm AVP.
o 暗号化アルゴリズムAVPの標準AVPコード13。
The following AVP values representing the encryption algorithm identifier for the Encryption-Algorithm AVP code have been assigned in the "Encryption-Algorithm (AVP Code 13) AVP Values" sub-registry under the "Protocol for Carrying Authentication for Network Access (PANA) Parameters" registry":
暗号化アルゴリズムAVPコードの暗号化アルゴリズム識別子を表す次のAVP値は、「ネットワークアクセス（PANA）の認証を行うためのプロトコル」パラメーターの下の「暗号化アルゴリズム（AVPコード13）AVP値」サブレジストリに割り当てられています。 「レジストリ」：
o An AVP value of 1 for AES128_CTR.
o AES128_CTRのAVP値は1。
o All other AVP values (0, 2-4294967295) are unassigned.
o 他のすべてのAVP値（0、2-4294967295）は割り当てられていません。
The registration procedures are IETF Review or IESG Approval in accordance with [RFC5872].
登録手順は、[RFC5872]に基づくIETFレビューまたはIESG承認です。
The additional encryption policy defined in Section 6.1 has been added as a column labeled "Enc" in the "AVP Codes" sub-registry and has been applied to all existing AVP codes and those defined in this specification.
セクション6.1で定義された追加の暗号化ポリシーが「AVPコード」サブレジストリの「Enc」というラベルの付いた列として追加され、すべての既存のAVPコードとこの仕様で定義されたものに適用されました。
The authors would like to thank Yoshihiro Ohba, Yasuyuki Tanaka, Adrian Farrel, Brian Carpenter, Yaron Sheffer, Ralph Droms, Stephen Farrell, Barry Leiba, and Sean Turner for their valuable comments.
著者は、貴重なコメントを寄せてくれた大場良弘、田中康之、エイドリアンファレル、ブライアンカーペンター、ヤロンシェファー、ラルフドロムス、スティーブンファレル、バリーレイバ、ショーンターナーに感謝します。
[NIST_SP800_38A] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", December 2001.
[NIST_SP800_38A] Dworkin、M。、「ブロック暗号モードの操作の推奨：方法と手法」、2001年12月。
[NIST_SP800_38C] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", May 2004.
[NIST_SP800_38C] Dworkin、M。、「ブロック暗号化動作モードの推奨：認証と機密性のためのCCMモード」、2004年5月。
[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月。
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[RFC3686] Housley、R。、「IPsecカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンターモードの使用」、RFC 3686、2004年1月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Ed。、Patil、B.、Tschofenig、H。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）」、RFC 5191、2008年5月。
[RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5872, May 2010.
[RFC5872] Arkko、J。およびA. Yegin、「IANA Rules for the Protocol for Carry Authentication for Network Access（PANA）」、RFC 5872、2010年5月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC6345] Duffy、P.、Chakrabarti、S.、Cragie、R.、Ohba、Y.、Ed。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）Relay Element」、RFC 6345、8月2011。
Authors' Addresses
著者のアドレス
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsungイスタンブールトルコ
EMail: alper.yegin@yegin.org
Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent Wakefield, WF4 4WA United Kingdom
Robert Cragie Gridmerge Ltd. 89 Greenfield Crescent Wakefield、WF4 4WAイギリス
EMail: robert.cragie@gridmerge.com