[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 5807

PANA Working Group                                               Y. Ohba
Internet-Draft                                                   Toshiba
Intended status: Standards Track                                A. Yegin
Expires: July 11, 2010                                           Samsung
                                                         January 7, 2010


   Definition of Master Key between PANA Client and Enforcement Point
                        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

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 11, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Ohba & Yegin              Expires July 11, 2010                 [Page 1]

Internet-Draft              PaC-EP Master Key               January 2010


   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 BSD License.


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.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7





















Ohba & Yegin              Expires July 11, 2010                 [Page 2]

Internet-Draft              PaC-EP Master Key               January 2010


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

                                                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
   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
   bootstrapped from PANA authentication across different address
   families.  This document also describes a guideline for distributing



Ohba & Yegin              Expires July 11, 2010                 [Page 3]

Internet-Draft              PaC-EP Master Key               January 2010


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


2.  Terminology

   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 = 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  SID is a four-octet Session Identifier [RFC5191].

   o  KID is the content of the Key-ID AVP [RFC5191] associated with the
      MSK.

   o  EPID is the identifier of the EP.  The first two octets represents
      the AddressType, which contains an Address Family defined in



Ohba & Yegin              Expires July 11, 2010                 [Page 4]

Internet-Draft              PaC-EP Master Key               January 2010


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

3.1.  Key Name of PEMK

   The key name of the PEMK is defined as follows.

   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.

3.2.  Scope of PEMK

   One PEMK is used between one PaC and one EP.  A PEMK MUST NOT be
   shared among multiple PaCs or EPs.

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

3.4.  Lifetime of 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.


4.  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 3.

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



Ohba & Yegin              Expires July 11, 2010                 [Page 5]

Internet-Draft              PaC-EP Master Key               January 2010


   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.

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

   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.


5.  IANA Considerations

   This document has no actions for IANA.


6.  Acknowledgments

   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.


7.  References

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




Ohba & Yegin              Expires July 11, 2010                 [Page 6]

Internet-Draft              PaC-EP Master Key               January 2010


   [SHS]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Secure Hash Standard", NIST
              FIPS PUB 180-2, August 2002.

   [IANAADFAM]
              IANA, "Address Family Numbers",
               http://www.iana.org/assignments/address-family-numbers.

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


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


   Alper Yegin
   Samsung
   Istanbul
   Turkey

   Email: alper.yegin@yegin.org






Ohba & Yegin              Expires July 11, 2010                 [Page 7]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/