idnits 2.17.1 draft-ohba-pana-keywrap-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 1, 2011) is 4826 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2464' is defined on line 191, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-03) exists of draft-ohba-pana-relay-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chakrabarti 3 Internet-Draft Unaffiliated 4 Intended status: Informational R. Cragie 5 Expires: August 5, 2011 PG&E 6 P. Duffy 7 Cisco 8 Y. Ohba (Ed.) 9 Toshiba 10 A. Yegin 11 Samsung 12 February 1, 2011 14 Protocol for Carrying Authentication for Network Access (PANA) Extension 15 for Key Wrap 16 draft-ohba-pana-keywrap-02 18 Abstract 20 This document specifies an extension to PANA (Protocol for carrying 21 Authentication for Network Access) for secure delivery of keys from a 22 PAA (PANA Authentication Agent) to a PaC (PANA Client). 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 5, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 60 2. Basic Operation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Key Encryption Key . . . . . . . . . . . . . . . . . . . . . . 3 62 4. ZigBee-Network-Key AVP . . . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Example Usage - ZigBee . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 PANA [RFC5191] as a UDP-based protocol to perform EAP authentication 75 between a PaC (PANA Client) and a PAA (PANA Authentication Agent). 77 This document specifies an extension for PANA [RFC5191] to securely 78 distribute keys from a PAA (PANA Authentication Agent) to a PaC (PANA 79 Client) using AES Key Wrap with Padding algorithm [RFC5649]. A 80 typical usage for this extension is group key distribution. For 81 example, a ZigBee Network Key is a group key that is shared among 82 members of a ZigBee network and used for bootstrapping IEEE 802.15.4 83 link-layer ciphering between adjacent ZigBee nodes. 85 1.1. Specification of Requirements 87 In this document, several words are used to signify the requirements 88 of the specification. These words are often capitalized. The key 89 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 90 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 91 are to be interpreted as described in [RFC2119]. 93 2. Basic Operation 95 Upon successful PANA authentication, a key wrap AVP MAY be placed in 96 the PAR message, which will have the header 'C' (Complete) bit set 97 and contain a Result-Code AVP indicating PANA_SUCCESS. A key wrap 98 AVP MUST be of type OctetString, MUST contain exactly one key of a 99 specific type, and MAY be defined as a standard or vendor-specific 100 AVP. A distinct AVP code MUST be defined for each key type. 102 When a key needs to be updated in the access phase a PANA ping 103 exchange is used. There are two modes for key update; pull mode and 104 push mode. In the pull mode, the PaC sends a PANA-Notification- 105 Request message with the 'P' (Ping) bit set and the PAA responds with 106 a PANA-Notification-Answer message with the 'P' (Ping) bit set and 107 carrying a key wrap AVP if there is a new key. In the push mode, the 108 PAA sends a PANA-Notification-Request message with the 'P' (Ping) bit 109 set and carrying a key wrap AVP to the PaC, and the PaC returns a 110 PANA-Notification-Answer message with the 'P' (Ping) bit set to the 111 PAA. 113 3. Key Encryption Key 115 PANA_KEY_ENC_KEY is used for encrypting a key to be delivered to teh 116 PaC. AES Key Wrap with Padding algorithm as specified in [RFC5649] 117 is used as the key encryption algorithm. PANA_KEY_ENC_KEY is derived 118 from MSK as follows. 120 PANA_KEY_ENC_KEY = the first 256 bits of 121 prf+(MSK, "Key Encryption Key" | SID | KID) 122 where | denotes concatenation. 124 o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- 125 random function used for the prf+ function is specified in the 126 PRF-Algorithm AVP carried in a PANA-Auth-Request message with 'S' 127 (Start) bit set. 129 o "Key Encryption Key" is the ASCII code representation of the non- 130 NULL terminated string (excluding the double quotes around it). 132 o SID is a four-octet Session Identifier [RFC5191]. 134 o KID is the content of the Key-ID AVP [RFC5191] associated with the 135 MSK. 137 4. ZigBee-Network-Key AVP 139 The ZigBee-Network-Key AVP (Vendor-Id 37244 (ZigBee Alliance, Inc), 140 AVP Code 1) is a vendor-specific key wrap AVP, carrying an encrypted 141 128-bit Network Key used in the ZigBee IP network over which PANA is 142 operating. 144 5. Security Considerations 146 Implementations must protect the PANA_KEK_ENC_KEY. Implementations 147 must not use the PANA_KEK_ENC_KEY for other purposes than wrapping 148 keys in key wrap AVPs and must not use wrapped keys for other 149 purposes than their intended usages. Compromise of the 150 PANA_KEK_ENC_KEY may result in the disclosure of all keys that have 151 been wrapped with the PANA_KEK_ENC_KEY, which may lead to the 152 compromise of all traffic protected with those wrapped keys. 154 According to [RFC5649], the effective security provided to data 155 protected with the wrapped key is determined by the weaker of the 156 algorithm associated with the key encryption key and the algorithm 157 associated with the wrapped key. PANA_KEY_ENC_KEY is the key 158 encryption key and associated with AES-256. For ZigBee Network Key 159 as the wrapped key, the length of the Network Key is 128 bits, and 160 therefore at most 128 bits protection is provided to any data that 161 depends on the Network Key. 163 6. IANA Considerations 165 This document has no actions for IANA. 167 7. Acknowledgments 169 TBD. 171 8. References 173 8.1. Normative References 175 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 176 RFC 4306, December 2005. 178 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 179 Yegin, "Protocol for Carrying Authentication for Network 180 Access (PANA)", RFC 5191, May 2008. 182 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 183 (AES) Key Wrap with Padding Algorithm", RFC 5649, 184 September 2009. 186 8.2. Informative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 192 Networks", RFC 2464, December 1998. 194 [I-D.ietf-6lowpan-nd] 195 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 196 Discovery Optimization for Low-power and Lossy Networks", 197 draft-ietf-6lowpan-nd-15 (work in progress), 198 December 2010. 200 [I-D.ohba-pana-relay] 201 Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 202 Yegin, "Protocol for Carrying Authentication for Network 203 Access (PANA) Relay Element", draft-ohba-pana-relay-02 204 (work in progress), October 2010. 206 [ianaweb] IANA, "Number assignment", http://www.iana.org. 208 Appendix A. Example Usage - ZigBee 210 In this section, we show how PRE is used in ZigBee IP use case. 212 In ZigBee IP, Joining Node (JN) is the PaC, Parent Node (PN) is the 213 PRE (PANA Relay Element) [I-D.ohba-pana-relay] and 6LBR 214 [I-D.ietf-6lowpan-nd] is the PAA. IPv6 link-local addresses of these 215 nodes are generated from their EUI-64 MAC addresses. The overall 216 ZigBee IP bootstrapping procedure using PANA with PRE is shown in 217 Figure 1. 219 JN(PaC) PN(PRE) 6LBR(PAA) 220 -------- ------------ ------- 221 IEEE 802.15.4 Active Scan 222 1. <----------------------> 223 RS/RA 224 2. <----------------------> 226 3. /--------------------+---------------------------\ 227 / PANA with PRE \ 228 / (ZigBee-Network-Key AVP carried in \ 229 \ PAR sent from PAA with 'C' (Complete) bit set & / 230 \ Result-Code=PANA_SUCCESS) / 231 \--------------------+---------------------------/ 233 Enable IEEE 802.15.4 ciphering 234 using Network Key 235 4. <-----------------------> 237 LoWPAN NS/NA 238 5. <-----------------------> 240 (IP traffic using the global address of JN can go through 241 PN after Step 5.) 243 Figure 1: Example Call Flow for Bootstrapping ZigBee IP using PANA 244 and Network Key 246 Step 1: JN performs network discovery and selection based on IEEE 247 802.15.4 beacon request and response exchange through which PN's 248 EUI-64 MAC address is known to JN. 250 Step 2: JN performs IPv6 Router Discovery and obtains a global prefix 251 of the ZigBee IP network. Router Soliciatation and Router 252 Advertisement messages are unprotected. 254 Step 3: JN performs PANA authentication through PN as the PRE. JN 255 uses its IPv6 link-local address for PANA. The PRE uses its IPv6 256 link-local address to communicate with the PaC (JN) and uses its IPv6 257 global address to communicate with the PAA (6LBR). Upon successful 258 PANA authentication, Network Key, or a group key to bootstrap link- 259 layer ciphering is securely transported from 6LBR to JN. Network Key 260 is encrypted in a ZigBee-Network-Key AVP in a PAR message sent from 261 PAA with the 'C' (Complete) bit set and a Result-Code AVP indicating 262 PANA_SUCCESS. 264 Step 4: Link-layer ciphering is enabled between JN and PN using 265 Network Key. Note that PN also has Network Key that was obtained when 266 PN joined the ZigBee IP network and perfomed PANA authentication as a 267 JN. 269 Step 5: Once link-layer ciphering is enabled between JN and PN, JN 270 configures an IPv6 global address using the prefix obtained in Step 271 2, and performs an IPv6 Neighbor Solicitation and Neighbor 272 Advertisement exchange of 6LoWPAN Neighbor Discovery 273 [I-D.ietf-6lowpan-nd] to regesiter the global address with PN. IP 274 traffic using the global address of JN can go through PN after 275 successful registration. 277 Authors' Addresses 279 Samita Chakrabarti 280 Unaffiliated 282 Email: samitac2@gmail.com 284 Robert Cragie 285 Pacific Gas & Electric 286 Gridmerge Ltd., 89 Greenfield Crescent 287 Wakefield, WF4 4WA 288 UK 290 Email: robert.cragie@gridmerge.com 292 Paul Duffy 293 Cisco Systems 294 200 Beaver Brook Road 295 Boxborough, MA 01719 296 USA 298 Email: paduffy@cisco.com 299 Yoshihiro Ohba 300 Toshiba Corporate Research and Development Center 301 1 Komukai-Toshiba-cho 302 Saiwai-ku, Kawasaki, Kanagawa 212-8582 303 Japan 305 Phone: +81 44 549 2127 306 Email: yoshihiro.ohba@toshiba.co.jp 308 Alper Yegin 309 Samsung 310 Istanbul 311 Turkey 313 Email: alper.yegin@yegin.org