[要約] RFC 5807は、PANAクライアントとエンフォースメントポイント間のマスターキーの定義に関する仕様です。目的は、PANAセッションのセキュリティを確保するために、クライアントとエンフォースメントポイント間で共有されるキーを定義することです。
Internet Engineering Task Force (IETF) Y. Ohba
Request for Comments: 5807 Toshiba
Category: Standards Track A. Yegin
ISSN: 2070-1721 Samsung
March 2010
Definition of Master Key between PANA Client and Enforcement Point
パナクライアントと執行ポイントの間のマスターキーの定義
Abstract
概要
This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families.
このドキュメントでは、ネットワークアクセス（PANA）に認証を運ぶためにプロトコルのクライアント間で使用されるマスターキーと、ブートストラップ下層の暗号化のための施行ポイントを定義します。マスターキーは、パナ認証が成功した結果、拡張可能な認証プロトコルのマスターセッションキーから派生しています。マスターキーは、さまざまなアドレスファミリでパナ認証からブートストラップされた執行ポイント間の暗号化の独立性を保証します。
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/rfc5807.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5807で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 5
3.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Guideline for Distributing PEMK from PAA to EP . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
The Protocol for carrying Authentication for Network Access (PANA) [RFC5191] is designed to facilitate network access authentication and authorization of clients in access networks. It carries Extensible Authentication Protocol (EAP) [RFC3748] between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the PAA functions as an authentication gateway to the Authentication Server (AS). The PANA framework [RFC5193] defines an another entity referred to as an Enforcement Point (EP), which resides in the access network and allows access (data traffic) of authorized PaCs while preventing access of others depending on the PANA authentication and authorization result (Figure 1). The EP and PAA may be implemented on the same device or separate devices.
ネットワークアクセス（PANA）[RFC5191]の認証を運ぶためのプロトコルは、ネットワークアクセス認証とアクセスネットワーク内のクライアントの承認を促進するように設計されています。PANAクライアント（PAC）とPANA認証エージェント（PAA）の間で拡張可能な認証プロトコル（EAP）[RFC3748]を運びます。PAAは、認証サーバー（AS）への認証ゲートウェイとして機能します。PANAフレームワーク[RFC5193]は、アクセスネットワークに存在し、許可されたPACのアクセス（データトラフィック）のアクセス（データトラフィック）を許可しながら、パナの認証と認証結果に応じて他のアクセスを防ぐことを許可する別のエンティティを定義します（EP）。図1）。EPとPAAは、同じデバイスまたは個別のデバイスに実装できます。
RADIUS,
Diameter,
+-----+ PANA +-----+ LDAP, API, etc. +-----+
| PaC |<----------------->| PAA |<------------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE, +-------->| EP |<--------+ ANCP, API, etc.
4-way handshake, +-----+
etc. .
.
.
v
Data traffic
Figure 1: PANA Functional Model
図1：パナ機能モデル
The EP uses non-cryptographic or cryptographic filters to selectively allow and discard data packets. These filters may be applied at the link-layer or the IP-layer [PANA-IPSEC]. When cryptographic access control is used, a secure association protocol [RFC3748] needs to run between the PaC and EP. After completion of the secure association protocol, link- or network-layer per-packet security (for example, IPsec ESP) is enabled for integrity protection, data origin authentication, replay protection, and optionally confidentiality protection.
EPは、非暗号化または暗号化フィルターを使用して、データパケットを選択的に許可および破棄します。これらのフィルターは、リンク層またはIP層[PANA-IPSEC]で適用できます。暗号化アクセス制御を使用する場合、安全な関連付けプロトコル[RFC3748]がPACとEPの間で実行する必要があります。Secure Association Protocolの完了後、リンクまたはネットワークレイヤーパケットあたりのセキュリティ（たとえば、IPSEC ESP）は、整合性保護、データ起源認証、リプレイ保護、およびオプションの機密性保護のために有効になります。
This document defines the PaC-EP Master Key (PEMK) that is used by a secure association protocol as the pre-shared secret between the PaC and EP to enable cryptographic filters in the access network. The PEMK is defined to guarantee cryptographic independence among EPs bootstrapped from PANA authentication across different address families. This document also describes a guideline for distributing PEMKs from the PAA to EP.
このドキュメントでは、Accessネットワークで暗号化フィルターを有効にするために、PACとEPの間の事前共有秘密として安全な関連付けプロトコルによって使用されるPAC-EPマスターキー（PEMK）を定義します。PEMKは、さまざまなアドレスファミリでパナ認証からブートストラップされたEPS間の暗号化の独立性を保証するために定義されています。このドキュメントでは、PAAからEPにPEMKを配布するためのガイドラインについても説明しています。
This document does not specify a mechanism for a PaC to know whether the lower layer requires a secure association protocol or the pre-shared secret for the secure association protocol needs to be bootstrapped from PANA authentication. Such a mechanism may be defined by each lower-layer protocol.
このドキュメントでは、下層が安全な関連付けプロトコルを必要とするかどうかを知るためのPACのメカニズムは指定されていません。このようなメカニズムは、各低層プロトコルによって定義される場合があります。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document reuses the following terms defined in [RFC5191]: PaC (PANA Client), PAA (PANA Authentication Agent), EP (Enforcement Point), MSK (Master Session Key), PANA Session, and Session Identifier.
このドキュメントは、[RFC5191]で定義されている次の用語を再利用します：PAC（PANAクライアント）、PAA（PANA認証エージェント）、EP（執行ポイント）、MSK（マスターセッションキー）、PANAセッション、およびセッション識別子。
A PEMK (PaC-EP Master Key) is derived from an available MSK. The PEMK is 64 octets in length and is calculated as follows:
PEMK（PAC-EPマスターキー）は、利用可能なMSKから派生しています。PEMKの長さは64オクテットで、次のように計算されます。
PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID) where | denotes concatenation.
pemk = prf（msk、 "ietf pemk" | sid | kid | epid）where |連結を示します。
o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-random function used for the prf+ function is specified in the PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' (Start) bit set.
o PRF関数はIKEV2 [RFC4306]で定義されています。PRF関数に使用される擬似ランダム関数は、「S」（START）ビットセットを備えたPANA-Auth-Requestメッセージに掲載されたPRFアルゴリズムAVPで指定されています。
o "IETF PEMK" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).
o 「IETF PEMK」は、非ヌル終端文字列のASCIIコード表現です（周囲の二重引用符は除く）。
o SID is a four-octet Session Identifier [RFC5191].
o SIDは、4オクテットのセッション識別子[RFC5191]です。
o KID is the content of the Key-ID AVP [RFC5191] associated with the MSK.
o KIDは、MSKに関連するKey-ID AVP [RFC5191]の内容です。
o EPID is the identifier of the EP. The first two octets represents the AddressType, which contains an Address Family defined in [IANAADFAM]. The remaining octets encode the address value. The length of the address value is determined by the AddressType. The AddressType is used to discriminate the content and format of the remaining octets for the address value. The use of the combination of address family and address value guarantees the cryptographic independence of PEMKs among multiple EPs that are bootstrapped from PANA authentication across multiple address families. How a PaC discovers an EPID is out of the scope of this document.
o EPIDはEPの識別子です。最初の2つのオクテットは、[ianaadfam]で定義されたアドレスファミリを含むaddressTypeを表します。残りのオクテットはアドレス値をエンコードします。アドレス値の長さは、アドレスタイプによって決定されます。アドレスタイプは、アドレス値の残りのオクテットのコンテンツと形式を区別するために使用されます。アドレスファミリとアドレス値の組み合わせの使用は、複数のアドレスファミリでパナ認証からブートストラップされている複数のEPS間のPEMKの暗号化の独立性を保証します。PACがEPIDを発見する方法は、このドキュメントの範囲外です。
The key name of the PEMK is defined as follows.
PEMKのキー名は次のように定義されています。
PEMKname = SHA1(EPID | SID | KID), where SHA1 denotes the SHA-1 algorithm specified in [SHS]. Inclusion of the EPID, SID, and KID provides uniqueness of PEMK names among multiple PaC-EP pairs under a given PAA.
pemkname = sha1（epid | sid | kid）、sha1は[shs]で指定されたSha-1アルゴリズムを示します。EPID、SID、およびKIDを含めると、特定のPAAの下で複数のPAC-EPペア間でPEMK名の独自性が提供されます。
One PEMK is used between one PaC and one EP. A PEMK MUST NOT be shared among multiple PaCs or EPs.
1つのPEMKが1つのPACと1つのEPの間で使用されます。PEMKは、複数のPACまたはEPS間で共有してはなりません。
A PEMK is used as the pre-shared key of the secure association protocol in the scope of the PEMK. A PEMK MUST NOT be used for any other usage.
PEMKは、PEMKの範囲内の安全な関連プロトコルの事前共有キーとして使用されます。PEMKは、他の使用に使用してはなりません。
The lifetime of a PEMK MUST be less than or equal to the lifetime of the MSK from which it is derived. At the end of the lifetime, the PEMK and its associated states MUST be deleted.
PEMKの寿命は、MSKの生涯以下である必要があります。寿命の終わりには、PEMKとそれに関連する状態を削除する必要があります。
The following considerations are specifically made to follow the Authentication, Authorization, and Accounting (AAA) key management guidance [RFC4962]. Other AAA key management requirements such as key lifetime, key scope, key context, and key name are described in Section 3.
以下の考慮事項は、認証、承認、会計（AAA）の主要な管理ガイダンス[RFC4962]に従うために特別に作成されています。キーライフタイム、キースコープ、キーコンテキスト、キー名などのその他のAAAキー管理要件は、セクション3で説明されています。
Since the device identifier of the EP is involved in the key derivation function, Channel Binding on a PEMK is made between the PaC and PAA at the time when the PEMK is generated. If a malicious EP advertises a different device identifier than that registered with the PAA, the malicious attempt will not succeed since the secure association protocol will fail due to the difference in the PEMK values calculated by the PaC and the EP.
EPのデバイス識別子はキー導出関数に関与しているため、PEMKが生成された時点でPACとPAAの間でPEMKのチャネル結合が作成されます。悪意のあるEPがPAAに登録されたものとは異なるデバイス識別子を宣伝する場合、PACとEPによって計算されたPEMK値の違いにより、安全な関連プロトコルが失敗するため、悪意のある試みは成功しません。
When an EP is implemented on the same device as the PAA, no protocol needs to be used for distributing a PEMK from the PAA to the EP.
PAAと同じデバイスにEPが実装されている場合、PAAからEPにPEMKを配布するためにプロトコルを使用する必要はありません。
In the case where the EP is implemented on a separate device from the PAA, a protocol is needed to distribute a PEMK from the PAA to the EP. Such a key distribution protocol may depend on the architecture and deployment using PANA. A key distribution protocol for a PEMK MUST ensure that the PEMK is encrypted as well as integrity and replay protected, with a security association between the PAA and EP, where the security association MUST be cryptographically bound to the identities of the PAA and EP known to the PaC.
PAAから別のデバイスにEPが実装されている場合、PAAからEPにPEMKを配布するにはプロトコルが必要です。このような重要な分布プロトコルは、パナを使用したアーキテクチャと展開に依存する場合があります。PEMKの主要な分布プロトコルは、PEMKが暗号化され、整合性とリプレイが保護されていることを確認する必要があります。PAAとEPのセキュリティ協会は、セキュリティ協会がPAAのアイデンティティとEPのアイデンティティに暗号化されなければなりません。PAC。
We would like to thank Jari Arkko, Basavaraj Patil, Pasi Eronen, Russ Mundy, Alexey Melnikov, and all members of the PANA working group for their valuable comments to this document.
Jari Arkko、Basavaraj Patil、Pasi Eronen、Russ Mundy、Alexey Melnikov、およびPanaワーキンググループのすべてのメンバーに、この文書への貴重なコメントに感謝します。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.
[RFC5191] Forsberg、D.、Ohba、Y.、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスの認証を運ぶためのプロトコル（PANA）」、RFC 5191、2008年5月。
[SHS] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", NIST FIPS PUB 180-2, August 2002.
[SHS]国立標準技術研究所、米国商務省、「Secure Hash Standard」、Nist Fips Pub 180-2、2002年8月。
[IANAADFAM] IANA, "Address Family Numbers", http://www.iana.org.
[ianaadfam] iana、「アドレスファミリー番号」、http：//www.iana.org。
[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月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。and B. Aboba、「認証、認可、会計（AAA）主要管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Framework", RFC 5193, May 2008.
[RFC5193] Jayaraman、P.、Lopez、R.、Ohba、Y.、Parthasarathy、M。、およびA. Yegin、「ネットワークアクセス（PANA）フレームワーク（PANA）フレームワークの認証を運ぶためのプロトコル」、RFC 5193、2008年5月。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.
[Pana-IPSEC] Parthasarathy、M。、「IPSECベースのアクセス制御を可能にするパナ」、2005年7月の作業。
Authors' Addresses
著者のアドレス
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
ヨシヒロ大統領企業研究開発センター1 Komukai-Toshiba-Cho Saiwai-ku、川崎、Kanagawa 212-8582日本
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
Alper Yegin Samsung Istanbul Turkey
EMail: alper.yegin@yegin.org