Internet Engineering Task Force (IETF) Y. Ohba
Request for Comments: 5807 Toshiba
Category: Standards Track A. Yegin
ISSN: 2070-1721 Samsung
March 2010
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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]定义了另一个被称为实施点（EP）的实体，该实体位于接入网络中，允许访问授权PAC（数据流量），同时根据PANA认证和授权结果阻止其他实体的访问（图1）。EP和PAA可以在相同的设备或单独的设备上实现。
RADIUS,
Diameter,
+-----+ PANA +-----+ LDAP, API, etc. +-----+
| PaC |<----------------->| PAA |<------------------->| AS |
+-----+ +-----+ +-----+
^ ^
| |
| +-----+ |
IKE, +-------->| EP |<--------+ ANCP, API, etc.
4-way handshake, +-----+
etc. .
.
.
v
Data traffic
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]。使用加密访问控制时，需要在PaC和EP之间运行安全关联协议[RFC3748]。完成安全关联协议后，将启用链路层或网络层每数据包安全性（例如，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
本文档定义了安全关联协议使用的PaC EP主密钥（PEMK），作为PaC和EP之间的预共享密钥，以在接入网络中启用加密过滤器。PEMK的定义是为了保证EPs之间的加密独立性，EPs是通过PANA身份验证跨不同地址启动的
families. This document also describes a guideline for distributing PEMKs from the PAA to EP.
家庭。本文件还描述了将PEMs从PAA分配给EP的指南。
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].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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请求消息中携带的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是一个四个八位字节的会话标识符[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的标识符。前两个八位字节表示AddressType，其中包含[IANAADFAM]中定义的地址族。其余的八位字节对地址值进行编码。这个
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用于区分地址值的剩余八位字节的内容和格式。地址族和地址值的组合使用保证了PEMK在多个EP之间的密码独立性，这些EP是通过跨多个地址族的PANA身份验证引导的。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.
Pemname=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.
在一个PaC和一个EP之间使用一个PEMK。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]，特考虑以下事项。第3节描述了其他AAA密钥管理要求，如密钥生存期、密钥范围、密钥上下文和密钥名称。
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播发与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.
当EP与PAA在同一设备上实现时，不需要使用任何协议将PEMK从PAA分配给EP。
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的设备上实施，则需要协议将PEMK从PAA分配给EP。这种密钥分发协议可能取决于使用PANA的体系结构和部署。PEMK的密钥分发协议必须确保PEMK被加密，完整性和重播受到保护，PAA和EP之间存在安全关联，其中安全关联必须以加密方式绑定到PaC已知的PAA和EP的身份。
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.，“互联网密钥交换（IKEv2）协议”，RFC43062005年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 51912008年5月。
[SHS] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", NIST FIPS PUB 180-2, August 2002.
[SHS]美国商务部国家标准与技术研究所，“安全哈希标准”，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.和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）框架的协议”，RFC 51932008年5月。
[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.
[PANA-IPSEC]Parthasarathy，M.，“PANA启用基于IPSEC的访问控制”，正在进行的工作，2005年7月。
Authors' Addresses
作者地址
Yoshihiro Ohba Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan
日本神奈川川崎Komukai Toshiba cho Saiwai ku东芝公司研发中心1号，邮编：212-8582
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Phone: +81 44 549 2230
EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Samsung Istanbul Turkey
土耳其伊斯坦布尔阿尔珀·耶金酒店
EMail: alper.yegin@yegin.org
EMail: alper.yegin@yegin.org