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

Versions: 00 01 02 03 04

Network Working Group                                     S. Chakrabarti
Internet-Draft                                              Unaffiliated
Intended status: Informational                                 R. Cragie
Expires: August 5, 2011                                             PG&E
                                                                P. Duffy
                                                                   Cisco
                                                           Y. Ohba (Ed.)
                                                                 Toshiba
                                                                A. Yegin
                                                                 Samsung
                                                        February 1, 2011


Protocol for Carrying Authentication for Network Access (PANA) Extension
                              for Key Wrap
                       draft-ohba-pana-keywrap-02

Abstract

   This document specifies an extension to PANA (Protocol for carrying
   Authentication for Network Access) for secure delivery of keys from a
   PAA (PANA Authentication Agent) to a PaC (PANA Client).

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 5, 2011.

Copyright Notice

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

   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



Chakrabarti, et al.      Expires August 5, 2011                 [Page 1]


Internet-Draft                PANA Key Wrap                February 2011


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Specification of Requirements . . . . . . . . . . . . . . . 3
   2.  Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Key Encryption Key  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  ZigBee-Network-Key AVP  . . . . . . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Example Usage - ZigBee . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7




























Chakrabarti, et al.      Expires August 5, 2011                 [Page 2]


Internet-Draft                PANA Key Wrap                February 2011


1.  Introduction

   PANA [RFC5191] as a UDP-based protocol to perform EAP authentication
   between a PaC (PANA Client) and a PAA (PANA Authentication Agent).

   This document specifies an extension for PANA [RFC5191] to securely
   distribute keys from a PAA (PANA Authentication Agent) to a PaC (PANA
   Client) using AES Key Wrap with Padding algorithm [RFC5649].  A
   typical usage for this extension is group key distribution.  For
   example, a ZigBee Network Key is a group key that is shared among
   members of a ZigBee network and used for bootstrapping IEEE 802.15.4
   link-layer ciphering between adjacent ZigBee nodes.

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

   Upon successful PANA authentication, a key wrap AVP MAY be placed in
   the PAR message, which will have the header 'C' (Complete) bit set
   and contain a Result-Code AVP indicating PANA_SUCCESS.  A key wrap
   AVP MUST be of type OctetString, MUST contain exactly one key of a
   specific type, and MAY be defined as a standard or vendor-specific
   AVP.  A distinct AVP code MUST be defined for each key type.

   When a key needs to be updated in the access phase a PANA ping
   exchange is used.  There are two modes for key update; pull mode and
   push mode.  In the pull mode, the PaC sends a PANA-Notification-
   Request message with the 'P' (Ping) bit set and the PAA responds with
   a PANA-Notification-Answer message with the 'P' (Ping) bit set and
   carrying a key wrap AVP if there is a new key.  In the push mode, the
   PAA sends a PANA-Notification-Request message with the 'P' (Ping) bit
   set and carrying a key wrap AVP to the PaC, and the PaC returns a
   PANA-Notification-Answer message with the 'P' (Ping) bit set to the
   PAA.


3.  Key Encryption Key

   PANA_KEY_ENC_KEY is used for encrypting a key to be delivered to teh
   PaC.  AES Key Wrap with Padding algorithm as specified in [RFC5649]
   is used as the key encryption algorithm.  PANA_KEY_ENC_KEY is derived



Chakrabarti, et al.      Expires August 5, 2011                 [Page 3]


Internet-Draft                PANA Key Wrap                February 2011


   from MSK as follows.

   PANA_KEY_ENC_KEY = the first 256 bits of
         prf+(MSK, "Key Encryption Key" | SID | KID)
         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  "Key Encryption Key" 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.


4.  ZigBee-Network-Key AVP

   The ZigBee-Network-Key AVP (Vendor-Id 37244 (ZigBee Alliance, Inc),
   AVP Code 1) is a vendor-specific key wrap AVP, carrying an encrypted
   128-bit Network Key used in the ZigBee IP network over which PANA is
   operating.


5.  Security Considerations

   Implementations must protect the PANA_KEK_ENC_KEY.  Implementations
   must not use the PANA_KEK_ENC_KEY for other purposes than wrapping
   keys in key wrap AVPs and must not use wrapped keys for other
   purposes than their intended usages.  Compromise of the
   PANA_KEK_ENC_KEY may result in the disclosure of all keys that have
   been wrapped with the PANA_KEK_ENC_KEY, which may lead to the
   compromise of all traffic protected with those wrapped keys.

   According to [RFC5649], the effective security provided to data
   protected with the wrapped key is determined by the weaker of the
   algorithm associated with the key encryption key and the algorithm
   associated with the wrapped key.  PANA_KEY_ENC_KEY is the key
   encryption key and associated with AES-256.  For ZigBee Network Key
   as the wrapped key, the length of the Network Key is 128 bits, and
   therefore at most 128 bits protection is provided to any data that
   depends on the Network Key.





Chakrabarti, et al.      Expires August 5, 2011                 [Page 4]


Internet-Draft                PANA Key Wrap                February 2011


6.  IANA Considerations

   This document has no actions for IANA.


7.  Acknowledgments

   TBD.


8.  References

8.1.  Normative References

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

   [RFC5649]  Housley, R. and M. Dworkin, "Advanced Encryption Standard
              (AES) Key Wrap with Padding Algorithm", RFC 5649,
              September 2009.

8.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [I-D.ietf-6lowpan-nd]
              Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
              Discovery Optimization for Low-power and Lossy Networks",
              draft-ietf-6lowpan-nd-15 (work in progress),
              December 2010.

   [I-D.ohba-pana-relay]
              Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA) Relay Element", draft-ohba-pana-relay-02
              (work in progress), October 2010.

   [ianaweb]  IANA, "Number assignment",  http://www.iana.org.





Chakrabarti, et al.      Expires August 5, 2011                 [Page 5]


Internet-Draft                PANA Key Wrap                February 2011


Appendix A.  Example Usage - ZigBee

   In this section, we show how PRE is used in ZigBee IP use case.

   In ZigBee IP, Joining Node (JN) is the PaC, Parent Node (PN) is the
   PRE (PANA Relay Element) [I-D.ohba-pana-relay] and 6LBR
   [I-D.ietf-6lowpan-nd] is the PAA.  IPv6 link-local addresses of these
   nodes are generated from their EUI-64 MAC addresses.  The overall
   ZigBee IP bootstrapping procedure using PANA with PRE is shown in
   Figure 1.

   JN(PaC)                    PN(PRE)                6LBR(PAA)
   --------                ------------               -------
      IEEE 802.15.4 Active Scan
   1.  <---------------------->
                RS/RA
   2.  <---------------------->

   3.    /--------------------+---------------------------\
        /   PANA with PRE                                  \
       /    (ZigBee-Network-Key AVP carried in              \
       \    PAR sent from PAA with 'C' (Complete) bit set & /
        \   Result-Code=PANA_SUCCESS)                      /
         \--------------------+---------------------------/

        Enable IEEE 802.15.4 ciphering
        using Network Key
   4. <----------------------->

            LoWPAN NS/NA
   5. <----------------------->

   (IP traffic using the global address of JN can go through
    PN after Step 5.)


    Figure 1: Example Call Flow for Bootstrapping ZigBee IP using PANA
                              and Network Key

   Step 1: JN performs network discovery and selection based on IEEE
   802.15.4 beacon request and response exchange through which PN's
   EUI-64 MAC address is known to JN.

   Step 2: JN performs IPv6 Router Discovery and obtains a global prefix
   of the ZigBee IP network.  Router Soliciatation and Router
   Advertisement messages are unprotected.

   Step 3: JN performs PANA authentication through PN as the PRE.  JN



Chakrabarti, et al.      Expires August 5, 2011                 [Page 6]


Internet-Draft                PANA Key Wrap                February 2011


   uses its IPv6 link-local address for PANA.  The PRE uses its IPv6
   link-local address to communicate with the PaC (JN) and uses its IPv6
   global address to communicate with the PAA (6LBR).  Upon successful
   PANA authentication, Network Key, or a group key to bootstrap link-
   layer ciphering is securely transported from 6LBR to JN.  Network Key
   is encrypted in a ZigBee-Network-Key AVP in a PAR message sent from
   PAA with the 'C' (Complete) bit set and a Result-Code AVP indicating
   PANA_SUCCESS.

   Step 4: Link-layer ciphering is enabled between JN and PN using
   Network Key. Note that PN also has Network Key that was obtained when
   PN joined the ZigBee IP network and perfomed PANA authentication as a
   JN.

   Step 5: Once link-layer ciphering is enabled between JN and PN, JN
   configures an IPv6 global address using the prefix obtained in Step
   2, and performs an IPv6 Neighbor Solicitation and Neighbor
   Advertisement exchange of 6LoWPAN Neighbor Discovery
   [I-D.ietf-6lowpan-nd] to regesiter the global address with PN.  IP
   traffic using the global address of JN can go through PN after
   successful registration.


Authors' Addresses

   Samita Chakrabarti
   Unaffiliated

   Email: samitac2@gmail.com


   Robert Cragie
   Pacific Gas & Electric
   Gridmerge Ltd., 89 Greenfield Crescent
   Wakefield, WF4 4WA
   UK

   Email: robert.cragie@gridmerge.com


   Paul Duffy
   Cisco Systems
   200 Beaver Brook Road
   Boxborough, MA 01719
   USA

   Email: paduffy@cisco.com




Chakrabarti, et al.      Expires August 5, 2011                 [Page 7]


Internet-Draft                PANA Key Wrap                February 2011


   Yoshihiro Ohba
   Toshiba Corporate Research and Development Center
   1 Komukai-Toshiba-cho
   Saiwai-ku, Kawasaki, Kanagawa  212-8582
   Japan

   Phone: +81 44 549 2127
   Email: yoshihiro.ohba@toshiba.co.jp


   Alper Yegin
   Samsung
   Istanbul
   Turkey

   Email: alper.yegin@yegin.org



































Chakrabarti, et al.      Expires August 5, 2011                 [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/