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
PANAクライアントと施行ポイント間のマスターキーの定義
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）及び施行ポイントの認証を実施するためのプロトコルのクライアントの間で使用されるマスターキーを定義します。マスターキーは、成功したPANA認証の結果として、拡張認証プロトコルのマスターセッションキーから導出されます。マスターキーは、別のアドレスファミリーと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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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]のための認証を搬送するためのプロトコルは、アクセスネットワーク内のネットワークアクセス認証とクライアントの認証を容易にするように設計されています。これは、拡張認証プロトコル（EAP）PANAクライアント（PAC）とPANA認証エージェント（PAA）との間の[RFC3748]を運ぶ場合認証サーバ（AS）に認証ゲートウェイとしてPAA機能します。 PANAフレームワーク[RFC5193]は別のエンティティを定義するPANA認証及び認可結果に応じて、他のアクセスを防止しつつ、（許可の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：PANA機能モデル
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の間で実行する必要があります。セキュアアソシエーションプロトコルの完了後、リンク - またはネットワーク層パケットごとのセキュリティ（例えば、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.
この文書は、アクセスネットワーク内の暗号化フィルタを有効にするのPaCとEPの間で事前共有秘密としてセキュアアソシエーションプロトコルによって使用されるPAC-EPマスタ鍵（のPemK）を定義します。 PemKは異なるアドレスファミリ間でPANA認証からブートストラップのEPの間で暗号独立性を保証するために定義されています。この文書はまた、EPにPAAからPEMKsを配布するためのガイドラインを説明しています。
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が下位層が安全関連プロトコルを必要としたり、安全な協会プロトコルの事前共有秘密はPANA認証からブートストラップする必要があるかどうかを知るようにするための機構が指定されていません。そのような機構は、各下位層プロトコルによって定義されてもよいです。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）|連結を示しています。
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」（スタート）と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は」非NULLの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に関連付けられたキー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
O EPIDはEPの識別子です。最初の2つのオクテット[IANAADFAM]で定義されたアドレスファミリーが含まAddressTypeにを表します。残りのオクテットは、アドレス値を符号化します。ザ・
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.
アドレス値の長さは、AddressTypeにすることによって決定されます。 AddressTypeには、アドレス値の残りのオクテットの内容と形式を識別するために使用されます。アドレスファミリとアドレス値の組み合わせの使用は、複数のアドレスファミリー間でPANA認証からブートストラップされている複数のEP間PEMKsの暗号独立性を保証します。 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.
SHA1は[SHS]で指定されたSHA1アルゴリズムを示し（KID EPID | | SID）、PEMKname = SHA1。 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.
一つのPemKは、一つのPaCと1枚のEPの間で使用されています。 PemKのは、複数のPaCのかのEPの間で共有されてはいけません。
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のデバイス識別子を鍵導出機能に関与しているので、チャンネルのPemKが発生した時点でのPaCとPAAとの間に形成されているのPemKに結合します。悪質な場合は
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は、セキュアアソシエーションプロトコルが原因のPaCとEPによって算出のPemK値の差に失敗するので、悪意のある試みは成功しないであろう、PAAに登録されるものとは異なるデバイス識別子を広告します。
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.
EPはPAAと同じデバイス上に実装された場合、何らのプロトコルはEPにPAAからの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.
EPはPAAから別のデバイスに実装されている場合には、プロトコルは、EPにPAAからのPemKを配布するために必要とされます。そのような鍵配布プロトコルは、PANAを使用してアーキテクチャと実装に依存してもよいです。 PemKのための鍵配布プロトコルは、のPemKがセキュリティアソシエーションを暗号的に知られているPAAとEPのIDにバインドする必要があり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.
私たちは、この文書に彼らの貴重なコメントのためにヤリArkko、Basavarajパティル、パシEronen、ラス・マンディ、アレクセイ・メルニコフ、およびPANAワーキンググループのすべてのメンバーに感謝したいと思います。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（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]フォースバーグ、D.、オオバ、Y.、パティル、B.、Tschofenig、H.、およびA. Yegin、RFC 5191、2008年5月 "ネットワークアクセス（PANA）の認証を搬送するプロトコル"。
[SHS] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", NIST FIPS PUB 180-2, August 2002.
標準技術[SHS]国立研究所、米国商務省が、2002年8月、NIST FIPS PUB 180-2の「ハッシュ標準セキュア」。
[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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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。および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.、ロペス、R.、オオバ、Y.、パルタサラティ、M.、およびA. Yegin、RFC 5193、2008年05月 "ネットワークアクセス（PANA）フレームワークのための認証を搬送するプロトコル"。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.
[PANA-IPSEC]パルタサラティ、M.、進歩、2005年7月ワーク "のIPsecベースのアクセス制御を有効にするPANA"。
Authors' Addresses
著者のアドレス
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
よしひろ おｈば としば こｒぽらて れせあｒｃｈ あんｄ でゔぇぉｐめんｔ せんてｒ １ こむかいーとしばーちょ さいわいーく、 かわさき、 かながわ ２１２ー８５８２ じゃぱん
Phone: +81 44 549 2230 EMail: yoshihiro.ohba@toshiba.co.jp
電話：+81 44 549 2230 Eメール：yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
アルパースティラーサムスンイスタンブールトルコ
EMail: alper.yegin@yegin.org
メールアドレス：alper.yegin@yegin.org