< draft-ohba-pana-pemk-03.txt   draft-ohba-pana-pemk-04.txt >
PANA Working Group Y. Ohba PANA Working Group Y. Ohba
Internet-Draft Toshiba Internet-Draft Toshiba
Intended status: Standards Track A. Yegin Intended status: Standards Track A. Yegin
Expires: March 12, 2010 Samsung Expires: July 11, 2010 Samsung
September 8, 2009 January 7, 2010
Definition of Master Key between PANA Client and Enforcement Point Definition of Master Key between PANA Client and Enforcement Point
draft-ohba-pana-pemk-03 draft-ohba-pana-pemk-04
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 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2010. This Internet-Draft will expire on July 11, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document defines a master key used between a client of the described in the BSD License.
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 Extensible
Authentication Protocol as a result of successful PANA
authentication. The master key guarantees cryptographic independence
among enforcement points across different types of lower-layers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 4
2. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 4 3. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 5
2.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5 3.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 3.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5
3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.2. Guideline for distributing PEMK from PAA to EP . . . . . . 5 4.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Guideline for distributing PEMK from PAA to EP . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
PANA (Protocol for carrying Authentication for Network Access) PANA (Protocol for carrying Authentication for Network Access)
[RFC5191] is designed to facilitate network access authentication and [RFC5191] is designed to facilitate network access authentication and
authorization of clients in access networks. It carries EAP authorization of clients in access networks. It carries EAP
[RFC3748] between a PaC (PANA Client) and a PAA (PANA Authentication [RFC3748] between a PaC (PANA Client) and a PAA (PANA Authentication
Agent) where the PAA functions as an authentication gateway to the Agent) where the PAA functions as an authentication gateway to the
Authentication Server (AS). The PANA framework [RFC5193] defines an Authentication Server (AS). The PANA framework [RFC5193] defines an
another entity referred to as an EP (Enforcement Point) which resides another entity referred to as an EP (Enforcement Point) which resides
in the access network and allows access (data traffic) of authorized in the access network and allows access (data traffic) of authorized
PaCs while preventing access of others depending on the PANA PaCs while preventing access of others depending on the PANA
authentication and authorization result. The EP and PAA may be authentication and authorization result (Figure 1). The EP and PAA
implemented on the same device or separate devices. may be implemented on the same device or separate devices.
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
The EP uses non-cryptographic or cryptographic filters to selectively The EP uses non-cryptographic or cryptographic filters to selectively
allow and discard data packets. These filters may be applied at the allow and discard data packets. These filters may be applied at the
link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic link-layer or the IP-layer [I-D.ietf-pana-ipsec]. When cryptographic
access control is used, a secure association protocol [RFC3748] needs access control is used, a secure association protocol [RFC3748] needs
to run between the PaC and EP. After completion of the secure to run between the PaC and EP. After completion of the secure
association protocol, link or network layer per-packet security (for association protocol, link or network layer per-packet security (for
example IPsec ESP) is enabled for integrity protection, data origin example IPsec ESP) is enabled for integrity protection, data origin
authentication, replay protection and optionally confidentiality authentication, replay protection and optionally confidentiality
protection. protection.
This document defines PaC-EP Master Key (PEMK) that is used by a This document defines PaC-EP Master Key (PEMK) that is used by a
secure association protocol as the pre-shared secret between the PaC secure association protocol as the pre-shared secret between the PaC
and EP to enable cryptographic filters in the access network. The and EP to enable cryptographic filters in the access network. The
PEMK is defined to guarantee cryptographic independence among EPs PEMK is defined to guarantee cryptographic independence among EPs
across different lower-layer types. This document also describes a bootstrapped from PANA authentication across different address
guideline for distributing PEMKs from the PAA to EP. families. This document also describes a guideline for distributing
PEMKs from the PAA to EP.
This document does not specify a mechanism for a PaC to know whether This document does not specify a mechanism for a PaC to know whether
the lower-layer requires a secure association protocol or the pre- the lower-layer requires a secure association protocol or the pre-
shared secret for the secure association protocol needs to be shared secret for the secure association protocol needs to be
bootstrapped from PANA authentication. Such a mechanism may be bootstrapped from PANA authentication. Such a mechanism may be
defined by each lower-layer protocol. defined by each lower-layer protocol.
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. PaC-EP Master Key 2. Terminology
A PEMK (PaC-EP Master Key) is derived from the available MSK. The 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.
3. PaC-EP Master Key
A PEMK (PaC-EP Master Key) is derived from an available MSK. The
PEMK is 64 octets in length and it is calculated as follows: PEMK is 64 octets in length and it is calculated as follows:
PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID) PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID)
where | denotes concatenation. where | denotes concatenation.
o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo-
random function used for the prf+ function is specified in the random function used for the prf+ function is specified in the
PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S'
(Start) bit set. (Start) bit set.
o "IETF PEMK" is the ASCII code representation of the non-NULL o "IETF PEMK" is the ASCII code representation of the non-NULL
terminated string (excluding the double quotes around it). terminated string (excluding the double quotes around it).
o MSK is a Master Session Key generated by EAP and exported to PANA. o SID is a four-octet Session Identifier [RFC5191].
o SID is a four-octet PANA session identifier [RFC5191].
o KID is the content of the PANA Key-ID AVP associated with the MSK o KID is the content of the Key-ID AVP [RFC5191] associated with the
[RFC5191]. MSK.
o EPID is the identifier of the EP. The first two octets represents o EPID is the identifier of the EP. The first two octets represents
the AddressType, which contains an Address Family defined in the AddressType, which contains an Address Family defined in
[IANAADFAM]. The remaining octets encode the address value. The [IANAADFAM]. The remaining octets encode the address value. The
length of the address value is determined by the AddressType. The length of the address value is determined by the AddressType. The
AddressType is used to discriminate the content and format of the AddressType is used to discriminate the content and format of the
remaining octets for the address value. The use of address family remaining octets for the address value. The use of the
and address value guarantees the cryptographic independence of combination of address family and address value guarantees the
PEMKs among multiple EPs across multiple lower-layer protocols. cryptographic independence of PEMKs among multiple EPs that are
How a PaC discovers an EPID is out of the scope of this document. bootstrapped from PANA authentication across multiple address
families. How a PaC discovers an EPID is out of the scope of this
document.
2.1. Key Name of PEMK 3.1. Key Name of PEMK
The key name of the PEMK is defined as follows. The key name of the PEMK is defined as follows.
PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest PEMKname = SHA1(EPID | SID | KID), where SHA1 denotes the SHA-1
algorithm 5 hash function. 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.
2.2. Scope of PEMK 3.2. Scope of PEMK
A PEMK is used between a PaC and an EP. A PEMK MUST NOT be shared One PEMK is used between one PaC and one EP. A PEMK MUST NOT be
among multiple PaCs or EPs. shared among multiple PaCs or EPs.
2.3. Context of PEMK 3.3. Context of PEMK
A PEMK is used as the pre-shared key of the secure association 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 protocol in the scope of the PEMK. A PEMK MUST NOT be used for any
other usage. other usage.
2.4. Lifetime of PEMK 3.4. Lifetime of PEMK
The lifetime of a PEMK MUST be less than or equal to the lifetime of The lifetime of a PEMK MUST be less than or equal to the lifetime of
the MSK. the MSK from which it is derived. At the end of the lifetime, the
PEMK and its associated states MUST be deleted.
3. Security Considerations 4. Security Considerations
The following considerations are specifically made to follow the AAA The following considerations are specifically made to follow the AAA
key management guidance [RFC4962]. Other AAA key management key management guidance [RFC4962]. Other AAA key management
requirements such as key lifetime, key scope, key context and key requirements such as key lifetime, key scope, key context and key
name are described under Section 2. name are described under Section 3.
3.1. Channel Binding 4.1. Channel Binding
Since the device identifier of the EP is involved in the key Since the device identifier of the EP is involved in the key
derivation function, Channel Binding on a PEMK is made between the 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 PaC and PAA at the time when the PEMK is generated. If a malicious
EP advertises a different device identifier than that is registered EP advertises a different device identifier than that is registered
with the PAA, the malicious attempt will not succeed since the secure with the PAA, the malicious attempt will not succeed since the secure
association protocol will fail due to the difference in the PEMK association protocol will fail due to the difference in the PEMK
values calculated by the PaC and the EP. values calculated by the PaC and the EP.
3.2. Guideline for distributing PEMK from PAA to EP 4.2. Guideline for distributing PEMK from PAA to EP
When an EP is implemented on the same device as the PAA, no protocol 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. needs to be used for distributing a PEMK from the PAA to the EP.
In the case where the EP is implemented on a separate device from the 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 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 EP. Such a key distribution protocol may depend on the architecture
and deployment using PANA. A key distribution protocol for a PEMK and deployment using PANA. A key distribution protocol for a PEMK
MUST ensure that the PEMK is encrypted as well as integrity and MUST ensure that the PEMK is encrypted as well as integrity and
replay protected, with a security association between the PAA and EP, replay protected, with a security association between the PAA and EP,
where the security association MUST be cryptographically bound to the where the security association MUST be cryptographically bound to the
identities of the PAA and EP known to the PaC. identities of the PAA and EP known to the PaC.
4. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. Acknowledgments 6. Acknowledgments
TBD. 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.
6. References 7. References
6.1. Normative References 7.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[SHS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", NIST
FIPS PUB 180-2, August 2002.
[IANAADFAM] [IANAADFAM]
IANA, "Address Family Numbers", IANA, "Address Family Numbers",
http://www.iana.org/assignments/address-family-numbers. http://www.iana.org/assignments/address-family-numbers.
6.2. Informative References 7.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and [RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and
A. Yegin, "Protocol for Carrying Authentication for A. Yegin, "Protocol for Carrying Authentication for
 End of changes. 32 change blocks. 
68 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/