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]