Network Working Group R. Cragie Internet-Draft PG&E Intended status: Informational P. Duffy Expires: February 4, 2012 Cisco Y. Ohba (Ed.) Toshiba A. Yegin Samsung August 3, 2011 Protocol for Carrying Authentication for Network Access (PANA) Extension for Key Wrap draft-ohba-pana-keywrap-03 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 February 4, 2012. 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Cragie, et al. Expires February 4, 2012 [Page 1] Internet-Draft PANA Key Wrap August 2011 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 . . . . . . . . . . . . . . . . . . . . . . 4 4. Key-Wrap-Algorithm AVP . . . . . . . . . . . . . . . . . . . . 4 5. ZigBee-Network-Key AVP . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Cragie, et al. Expires February 4, 2012 [Page 2] Internet-Draft PANA Key Wrap August 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 a key wrap algorithm negotiated between the PAA and PaC. 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 In the Authentication and Authorization phase, a PAA and a PaC negotiate on a key wrap algorithm. A PAA that uses a key wrap AVP MUST include one or more Key-Wrap-Algorithm AVPs in the initial PANA- Auth-Request message with the 'S' (Start) bit set. The PaC, if it supports a key wrap AVP, then selects one key wrap algorithm from these AVPs carried in the initial PANA-Auth-Request, and it responds with the initial PANA-Auth-Answer message carrying one Key-Wrap- Algorithm AVP for the selected algorithm. 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. The key data carried in the key wrap AVP is encrypted by a key encryption key (see Section 3) using the negotiated key wrap algorithm (see Section 4). 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 Cragie, et al. Expires February 4, 2012 [Page 3] Internet-Draft PANA Key Wrap August 2011 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 the PaC. PANA_KEY_ENC_KEY is derived from MSK as follows. PANA_KEY_ENC_KEY = the first N 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 N is the bit length of the PANA_KEY_ENC_KEY. The value of N depends on the key wrap algorithm. For AES Key Wrap with Padding algorithm, N=256. 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. Key-Wrap-Algorithm AVP The Key-Wrap-Algorithm AVP (AVP Code 12 (*needs IANA allocation*)) is used for conveying the identifier of a key wrap algorithm used for encrypting a key carried in a key wrap AVP. The AVP data is of type Unsigned32. The following key wrap algorithm identifiers are defined in this document. AES_KEY_WRAP_WITH_PADDING_256 1 AES Key Wrap with Padding algorithm with a 256-bit key encryption key as specified in [RFC5649]. Cragie, et al. Expires February 4, 2012 [Page 4] Internet-Draft PANA Key Wrap August 2011 AES_CCM 2 AES-CCM (Counter with Cipher Block Chaining-Message Authentication Code) key wrap algorithm. The formatting and counter generation function of AES-CCM as specified in Appendix A of [NIST_SP800_38C] is used, with the following parameters: n, octet length of nonce, is 12. t, octet length of MAC, is 16. q, octet length of message length field, is 3. The 12-bit nonce is formed as 4-octet Session ID, followed by 4-octet Key-Id, followed by 4-octet Sequence Number. The Session ID and Sequence Number values must be the same as those in the PANA message carrying the key wrap AVP. The Key-Id value must be the same as the one used for deriving the PANA_KEY_ENC_KEY. The formatting function output blocks B0, B1, ..., Br are encoded as OctetString data in the Value field of a key wrap AVP, with no Associated Data. All PANA implementations that support this specification MUST support AES_KEY_WRAP_WITH_PADDING_256 [RFC5649]. 5. 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 of type OctetString, carrying encrypted 17-octet key data which consists of a 1-octet Network Key Sequence Number followed by a 16-octet Network Key used in the ZigBee IP network over which PANA is operating. 6. Security Considerations Implementations must protect the PANA_KEY_ENC_KEY. Implementations must not use the PANA_KEY_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_KEY_ENC_KEY may result in the disclosure of all keys that have been wrapped with the PANA_KEY_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 Cragie, et al. Expires February 4, 2012 [Page 5] Internet-Draft PANA Key Wrap August 2011 associated with the wrapped key. In this document, PANA_KEY_ENC_KEY is the key encryption key. For ZigBee Network Key as the wrapped key, the length of the Network Key is 128 bits, therefore, with the PANA_KEY_ENC_KEY of at least 128 bits in length, at most 128 bits protection is provided to any data that depends on the Network Key. 7. IANA Considerations As described in Section 4, and following the new IANA allocation policy on PANA AVPs [RFC5872], a standard AVP Code of 12 needs to be assigned for Key-Wrap-Algorithm AVP. Also, the key wrap algorithm identifier namespace for Key-Wrap- Algorithm AVP needs to be managed by IANA. The value of 1 (AES_KEY_WRAP_WITH_PADDING_256) and 2 (AES_CCM) are used in this document. Allocating additional values can be done on IETF Review or IESG Approval [RFC5226]. 8. Acknowledgments The authors would like to thank Michael StJohns and Vlad Gherghisan for their valuable comments. 9. References 9.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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm", RFC 5649, September 2009. [RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA)", RFC 5872, May 2010. Cragie, et al. Expires February 4, 2012 [Page 6] Internet-Draft PANA Key Wrap August 2011 [NIST_SP800_38C] "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST SP800-38C, May 2004. 9.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. [ianaweb] IANA, "Number assignment", http://www.iana.org. Authors' Addresses 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 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 Cragie, et al. Expires February 4, 2012 [Page 7] Internet-Draft PANA Key Wrap August 2011 Alper Yegin Samsung Istanbul Turkey Email: alper.yegin@yegin.org Cragie, et al. Expires February 4, 2012 [Page 8]