Network Working Group S. Chakrabarti Internet-Draft IP Infusion Intended status: Informational R. Cragie Expires: March 26, 2011 PG&E P. Duffy Cisco Y. Ohba (Ed.) Toshiba A. Yegin Samsung September 22, 2010 Protocol for Carrying Authentication for Network Access (PANA) Extension for Key Wrap draft-ohba-pana-keywrap-00 Abstract This document specifies an extension to PANA (Protocol for carrying Authentication for Network Access) for secure delivery of keys generated indepependently of EAP (Extensible Authentication Protocol) key material 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 March 26, 2011. Copyright Notice Copyright (c) 2010 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 Chakrabarti, et al. Expires March 26, 2011 [Page 1] Internet-Draft PANA Key Wrap September 2010 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 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 . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Appendix A. Example Usage - ZigBee . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Chakrabarti, et al. Expires March 26, 2011 [Page 2] Internet-Draft PANA Key Wrap September 2010 1. Introduction PANA (Protocol for carrying Authentication for Network Access) [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 (Protocol for carrying Authentication for Network Access) [RFC5191] to securely distribute keys generated indepependently of EAP (Extensible Authentication Protocol) key material 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 success PANA authentication, a key wrap AVP MAY be is contained in a PAR message with the 'C' (Complete) bit set and a Result-Code AVP indicating PANA_SUCCESS. A key wrap AVP MUST contain exactly one key of a specific type. A key wrap AVP of type OctetString, and defined as a standard or vendor-specific AVP. A distinct AVP Code (under a specific Vendor-Id in the case of vendor-specific key wrap AVP) shall be used for a key wrap AVP for a specific type of key. 3. Key Encryption Key PANA_KEY_ENC_KEY is used for encrypting a key that is generated independently of the MSK and its descendant keys. AES Key Wrap with Padding algorithm as specified in [RFC5649] is used as the key encryption algorithm. PANA_KEY_ENC_KEY is derived from MSK as follows. PANA_KEY_ENC_KEY = the first 256 bits of prf+(MSK, "Key Encryption Key" | SID | KID) where | denotes concatenation. Chakrabarti, et al. Expires March 26, 2011 [Page 3] Internet-Draft PANA Key Wrap September 2010 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 to be allocated by IANA for "ZigBee Alliance", 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. 6. IANA Considerations A new SMI Network Management Private Enterprise Code [ianaweb] for "ZigBee Alliance" needs to be allocated for Vendor-Id field of ZigBee-Network-Key AVP. Chakrabarti, et al. Expires March 26, 2011 [Page 4] Internet-Draft PANA Key Wrap September 2010 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-13 (work in progress), September 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-00 (work in progress), September 2010. [ianaweb] IANA, "Number assignment", http://www.iana.org. Appendix A. Example Usage - ZigBee In this section, we show how PFE is used in ZigBee IP use case. In ZigBee IP, Joining Node (JN) is the PaC, Parent Node (PN) is the Chakrabarti, et al. Expires March 26, 2011 [Page 5] Internet-Draft PANA Key Wrap September 2010 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 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 Chakrabarti, et al. Expires March 26, 2011 [Page 6] Internet-Draft PANA Key Wrap September 2010 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 IP Infusion 1188 Arquest Street Sunnyvale, CA USA Email: samitac@ipinfusion.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 March 26, 2011 [Page 7] Internet-Draft PANA Key Wrap September 2010 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 March 26, 2011 [Page 8]