One document matched: draft-ohba-pana-pemk-02.txt
Differences from draft-ohba-pana-pemk-01.txt
PANA Working Group Y. Ohba
Internet-Draft Toshiba
Expires: April 27, 2009 October 24, 2008
Definition of Master Key between PANA Client and Enforcement Point
draft-ohba-pana-pemk-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2009.
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 across different types of lower-layers.
Ohba Expires April 27, 2009 [Page 1]
Internet-Draft PaC-EP Master Key October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3
2. PaC-EP Master Key . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Key Name of PEMK . . . . . . . . . . . . . . . . . . . . . 4
2.2. Scope of PEMK . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Context of PEMK . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Lifetime of PEMK . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
3.1. Channel Binding . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Guideline for distributing PEMK from PAA to EP . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Ohba Expires April 27, 2009 [Page 2]
Internet-Draft PaC-EP Master Key October 2008
1. Introduction
PANA (Protocol for carrying Authentication for Network Access)
[RFC5191] is designed to facilitate network access authentication and
authorization of clients in access networks. It carries EAP
[RFC3748] between a PaC (PANA Client) and a PAA (PANA Authentication
Agent) 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 EP (Enforcement Point) which resides
in the access network and allows access (data traffic) of authorized
PaCs while preventing access by others depending on the PANA
authentication and authorization result. The EP and PAA may be
implemented on the same device or separate devices.
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 [I-D.ietf-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.
This document defines 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
across different lower-layer types. This document also describes
guideline for distributing PEMKs from the PAA to 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.
1.1. Specification of Requirements
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].
Ohba Expires April 27, 2009 [Page 3]
Internet-Draft PaC-EP Master Key October 2008
2. PaC-EP Master Key
A PEMK (PaC-EP Master Key) is derived from the available MSK. The
PEMK is 64 octets in length and it is calculated as follows:
PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID)
where | denotes concatenation.
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 "IETF PEMK" is the ASCII code representation of the non-NULL
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 PANA session identifier [RFC5191].
o KID is the content of the PANA Key-ID AVP associated with the MSK
[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 address family
and address value guarantees the cryptographic independence of
PEMKs among multiple EPs across multiple lower-layer protocols.
How a PaC configures an EPID is out of the scope of this document.
2.1. Key Name of PEMK
The key name of the PEMK is defined as follows.
PEMKname = MD5(EPID | SID | KID), where MD5 denotes Message-Digest
algorithm 5 hash function.
2.2. Scope of PEMK
A PEMK is used between a PaC and an EP. A PEMK MUST NOT be shared
among multiple PaCs or EPs.
Ohba Expires April 27, 2009 [Page 4]
Internet-Draft PaC-EP Master Key October 2008
2.3. Context of PEMK
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.
2.4. Lifetime of PEMK
The lifetime of a PEMK MUST be no greater than the lifetime of the
MSK.
3. Security Considerations
The following considerations are specifically made to follow the AAA
key management guidance [RFC4962]. Other AAA key management
requirements such as key lifetime, key scope, key context and key
name are described under Section 2.
3.1. Channel Binding
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 is 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.
3.2. Guideline for distributing PEMK from PAA to EP
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. It
is assumed that an EP is implemented on the same device as the PAA
when the device identifier of the EP is equals to a link-layer
address or an IP address of the PAA. Otherwise, it is assumed that
the EP is implemented on a separate device from the PAA.
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 lower-layer
protocol over which PANA operates. 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.
Ohba Expires April 27, 2009 [Page 5]
Internet-Draft PaC-EP Master Key October 2008
4. IANA Considerations
This document has no actions for IANA.
5. Acknowledgments
TBD.
6. References
6.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[IANAADFAM]
IANA, "Address Family Numbers",
http://www.iana.org/assignments/address-family-numbers.
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[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.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA Enabling IPsec based Access
Control", draft-ietf-pana-ipsec-07 (work in progress),
July 2005.
Ohba Expires April 27, 2009 [Page 6]
Internet-Draft PaC-EP Master Key October 2008
Author's Address
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Ohba Expires April 27, 2009 [Page 7]
Internet-Draft PaC-EP Master Key October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Ohba Expires April 27, 2009 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 05:34:27 |