[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc5807                                        
PANA Working Group                                               Y. Ohba
Internet-Draft                                                   Toshiba
Expires: May 20, 2008                                           A. Yegin
                                                                 Samsung
                                                       November 17, 2007


   Definition of Master Key between PANA Client and Enforcement Point
                        draft-ohba-pana-pemk-01

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 May 20, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines PaC-EP Master Key (PEMK), a master key used
   between a PANA client and an enforcement point, for bootstrapping
   lower-layer ciphering.  A PEMK is derived from EAP Master Session Key
   as a result of successful PANA authentication.  The PEMK is defined
   to guarantee cryptographic independence among enforcement points
   across different types of lower-layers.




Ohba & Yegin              Expires May 20, 2008                  [Page 1]


Internet-Draft              PaC-EP Master Key              November 2007


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 . . . . . . . . . . . . . . . . . . . . . . 4
     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 . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
































Ohba & Yegin              Expires May 20, 2008                  [Page 2]


Internet-Draft              PaC-EP Master Key              November 2007


1.  Introduction

   PANA (Protocol for carrying Authentication for Network Access)
   [I-D.ietf-pana-pana] 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
   [I-D.ietf-pana-framework] 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 TKIP, 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 & Yegin              Expires May 20, 2008                  [Page 3]


Internet-Draft              PaC-EP Master Key              November 2007


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, "PaC-EP master key" | SID | KID | EPDID)

   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  MSK is a Master Session Key generated by EAP and exported to PANA.

   o  SID is a four-octet PANA session identifier [I-D.ietf-pana-pana].

   o  KID is the content of the PANA Key-ID AVP associated with the MSK
      [I-D.ietf-pana-pana].

   o  EP-Device-ID is the identifier of the EP.  The first two octets of
      EP-Device-ID represents the AddressType, which contains an Address
      Family defined in [IANAADFAM].  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
      the identifier of the EP is out of the scope of this document.

2.1.  Key Name of PEMK

   The key name of the PEMK is defined as follows.

   TBD.

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.

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.







Ohba & Yegin              Expires May 20, 2008                  [Page 4]


Internet-Draft              PaC-EP Master Key              November 2007


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 between the PEMK
   calculated by the PaC and the PEMK calculated by the PAA and
   distributed to 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.  The HOKEY (Handover
   Keying) key distribution protocol [I-D.ietf-hokey-key-mgm] is such a
   key distribution protocol.


4.  IANA Considerations

   This document has no actions for IANA.



Ohba & Yegin              Expires May 20, 2008                  [Page 5]


Internet-Draft              PaC-EP Master Key              November 2007


5.  Acknowledgments

   TBD.


6.  References

6.1.  Normative References

   [I-D.ietf-pana-pana]
              Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", draft-ietf-pana-pana-18 (work in
              progress), September 2007.

   [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.

   [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.

   [I-D.ietf-pana-framework]
              Jayaraman, P., Ohba, Y., Parthasarathy, M., and A. Yegin,
              "Protocol for Carrying Authentication for Network Access
              (PANA) Framework", draft-ietf-pana-framework-10 (work in
              progress), September 2007.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA Enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-07 (work in progress),
              July 2005.

   [I-D.ietf-hokey-key-mgm]
              Nakhjiri, M. and Y. Ohba, "Derivation, delivery and



Ohba & Yegin              Expires May 20, 2008                  [Page 6]


Internet-Draft              PaC-EP Master Key              November 2007


              management of EAP based keys for handover and  re-
              authentication", draft-ietf-hokey-key-mgm-01 (work in
              progress), November 2007.


Authors' Addresses

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscateway, NJ  08854
   USA

   Phone: +1 732 699 5365
   Email: yohba@tari.toshiba.com


   Alper E. Yegin
   Samsung Advanced Institute of Technology
   Istanbul,
   Turkey

   Phone: +90 533 348 2402
   Email: alper.yegin@yegin.org



























Ohba & Yegin              Expires May 20, 2008                  [Page 7]


Internet-Draft              PaC-EP Master Key              November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Ohba & Yegin              Expires May 20, 2008                  [Page 8]