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]