Internet DRAFT - draft-sarikaya-solace-setup-framework
draft-sarikaya-solace-setup-framework
Core B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track Y. Ohba
Expires: March 21, 2013 Toshiba
R. Moskowitz
Verizon Business Systems
Z. Cao
China Mobile
R. Cragie
Pacific Gas and Electric
September 17, 2012
Framework for Securely Setting Up Smart Objects
draft-sarikaya-solace-setup-framework-00
Abstract
This document describes a framework for initially configuring smart
objects securely. Initial setup architecture, communication channel
and bootstrap security methods are described.
Status of this Memo
This Internet-Draft is submitted 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 21, 2013.
Copyright Notice
Copyright (c) 2012 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
Sarikaya, et al. Expires March 21, 2013 [Page 1]
Internet-Draft draft-sarikaya-solace September 2012
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Bootstrapping Architecture . . . . . . . . . . . . . . . . . . 4
3.1. Areas of Boostrapping . . . . . . . . . . . . . . . . . . 4
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 5
4. Bootstrap Security Method . . . . . . . . . . . . . . . . . . 6
4.1. None . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Asymmetric with User Authentication, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Asymmetric with Certificate Authority, Followed by
Symmetric . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Cryptographically Generated Address Based Address
Ownership Verification . . . . . . . . . . . . . . . . . . 6
5. Secure Bootstrapping System Level Objectives . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. EAP, PANA, HIP-DEX and 802.1X . . . . . . . . . . . . . . . . 9
7.1. EAP Authentication Framework . . . . . . . . . . . . . . . 9
7.2. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. HIP-DEX . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Sarikaya, et al. Expires March 21, 2013 [Page 2]
Internet-Draft draft-sarikaya-solace September 2012
1. Introduction
IP-based constrained devices in the Internet of Things (IOT) are
being used in Machine-to-Machine (M2M) applications ranging from
building automation to production environments to smart metering to
personal area networks (PAN). Constrained devices in these
applications may be very different "things" such as a temperature
sensor, a luminaire, or an RFID tag and might interact with each
other, with a smart phone, or with backend services. The
introduction of IPv6 and web services as fundamental building blocks
enables these devices to be networked and at the same time it
introduces security vulnarabilities [I-D.garcia-core-security].
Bootstrapping is any processing required before the network can
operate. Typically this will require a number of settings to be
transferred between nodes at all layers. This could include anything
from link-layer information (i.e., wireless channels, link-layer
encryption keys) to application-layer information (i.e., network
names, application encryption keys).
Bootstrapping is complete when settings have been securely
transferred prior to normal operation in the network.
The bootstrapping problem is not specific to any MAC or PHY. This
problem exists across any two nodes which have no previous knowledge
of each other. In particular, this problem is complicated when the
nodes are resource-constrained and may not have an advanced user
interface. The IETF is instrumental in defining standards which will
be used by the Internet of Things (IOT). Ensuring these standards
can be used across nodes and networks requires some form of
bootstrapping which the sensor nodes can use [ROMER04].
Existing standards will be used as much as possible in this document.
The method proposed here should work across many different underlying
layers. It could be used to allow two nodes on the same physical
network to join at the physical layer, or allow two nodes on an
incompatible physical network to join at the IPv6 layer.
The document continues in Section 3 on bootstrapping architecture, in
Section 4 on allowable security methods in bootstrapping, in
Section 5 on system level objectives of securely setting up the
constrained nodes.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Sarikaya, et al. Expires March 21, 2013 [Page 3]
Internet-Draft draft-sarikaya-solace September 2012
document are to be interpreted as described in [RFC2119].
3. Bootstrapping Architecture
3.1. Areas of Boostrapping
In order to provide a flexible architecture, the bootstrapping method
is split into five distinct areas and two distinct phases. The five
areas are a 'user interface', 'bootstrap profile', 'security method',
'bootstrap protocol', and the 'communications channel'.
The phases are provisioning phase and bootstrapping phase. In the
provisioning phase, statically configured parameters (e.g.,
certificates) needed for the bootstrapping phase is provisioned. In
the bootstrapping phase, dynamically configured information is set up
using the statically configured information provided in the
provisioning phase.
Two nodes communicate through some channel. For our purposes this is
split into the 'control channel' and 'data channel'. The control
channel is used for the bootstrap protocol, and the data channel is
used during normal network operation. A node may support multiple
control or data channels. When the control and data channels are the
same, the bootstrapping is done In Band (IB). When the control and
data channels are different, the bootstrapping is performed Out Of
Band (OOB). An 802.15.4 network for instance would use an 802.15.4
control channel for IB bootstrapping, but a control channel of
perhaps IrDA or USB for OOB bootstrapping.
The 'bootstrap profile', i.e. statically configured parameters during
the provisioning phase, defines what information should be exchanged
during the process. A single node may run the protocol multiple
times with different profiles. If the user wishes to associate a new
lightswitch, the protocol is first run with the '802.15.4 Wireless
Profile', through which it learns the channel and PAN-ID. The node
then runs a 'Security Exchange Profile' to learn the needed
encryption keys. Finally it runs a 'Lightswitch Association Profile'
through which it learns which light to associate with.
An example of the 'bootstrap profile' attribute is the
'administrative domain name'. 'Bootstrap profiles' are required to
be modified when the corresponding administrative domains are
changed, a.k.a. recommissioning. In recommissioning, the domains are
administratively repartitioned and nodes are therefore
recommissioned.
The 'security method' defines supported security methods for
Sarikaya, et al. Expires March 21, 2013 [Page 4]
Internet-Draft draft-sarikaya-solace September 2012
bootstrapping. The supported security methods will depend on the
control channel and bootstrap profile. In one node if the control
channel is secure, then a simple clear-text security method is
supported. For example when a physical connection between two nodes
is used, the control channel is considered secure. However when the
control channel is not secure, this clear-text security method is not
supported. The 'bootstrap profile' additionally defines allowed
security methods. Higher security nodes may outlaw ever performing a
clear-text exchange, even if the control channel is deemed secure.
The 'bootstrap protocol' defines the actual messages exchanged during
bootstrapping. The messages are used to transfer between nodes data,
node information, and network state. The selected security method
runs on top of the control channel, such as EAP-GPSK etc.
3.2. Architecture
Security bootstrapping architecture is structured in a hierarchy of
nodes going from the least resource constraint to the most resource
constraint. At the top there is a root node. The root node is
called Coordinator or Trust Center in Zigbee and 6LowPAN Border
Router (6LBR) in 6LoWPAN ND.
At the next level there are interior Routers. Routers are able to
run a routing protocol between other routers and the root. Routers
are called 6LowPAN Routers (6BR) in 6LoWPAN ND.
At the lowest level there are the nodes. The nodes do not run a
routing protocol. They can connect to the nearest router over a
single radio link. The nodes are called End Devices in Zigbee and
hosts in 6LoWPAN ND.
Routers first join the network as a node and go through security
bootstrapping operations in order to create a Master Session Key
(MSK). Next, routers execute routing protocol, e.g. [RFC6550]
specific steps to create session keys with their neighbors and to
establish upstream and downstream next hop parents.
At each node hierarachy level described above, there are lower-layer
and higher-layer protocols to bootstrap their ciphering keys, where
the lower-layer refers to layers below IP layer including IEEE
802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer
refers to IP layer and the above. In general, required bootstrapping
procedures depend on the bootstrapping protocols to use.
Sarikaya, et al. Expires March 21, 2013 [Page 5]
Internet-Draft draft-sarikaya-solace September 2012
4. Bootstrap Security Method
The bootstrap security method defines allowable security methods. A
node may choose to support or use a subset of these methods. This is
NOT the security architecture used for the application, but only the
security used during bootstrapping. Typically some high-security
method is used to generate a shared secret, which then switches to
simplier symmetric encryption to secure the actual bootstrapping
channel. The techniques negotiated should take advantage of hardware
resources available, such as hardware encryption accelerators on an
end node.
4.1. None
This is the simplist security method. No encryption or
authentication is provided, messages are exchanged completely in
clear-text. It is assumed some other layer provides security, such
as a physical connection between devices.
4.2. Asymmetric with User Authentication, Followed by Symmetric
A Diffie-Hellman style key exchange is used to generate a shared
secret. The authentication will be provided by the user, by
confirming cryptographic signatures between two devices. With the
shared secret generated through the DH, some symmetric encryption is
used to secure the actual bootstrapping channel.
4.3. Asymmetric with Certificate Authority, Followed by Symmetric
Public key exchanges are used (aka: DH again), but with a Certificate
Authority. Once a shared secret exists, symmetric encryption is used
to secure the actual bootstrapping channel.
4.4. Cryptographically Generated Address Based Address Ownership
Verification
A node may generate the global unique address using different
techniques other than the stateless address autoconfiguration. For
example, Cryptographically Generated Addresses (CGA) [RFC3972] is a
type of global unique address that can be used to verify the address
ownership. When the node uses CGA, it MUST execute SeND protocol
[RFC3971]. In a 6LOWPAN network, a modified 6LOWPAN ND Protocol
[I-D.ietf-6lowpan-nd] must be executed between the node and the edge
router.
Sarikaya, et al. Expires March 21, 2013 [Page 6]
Internet-Draft draft-sarikaya-solace September 2012
5. Secure Bootstrapping System Level Objectives
Authentication/ reauthentication: nodes joining the network MUST at
the first place authenticate to the trust center. In order to
achieve secure multi-hop routing, the node MUST authenticate to its
upstream and downstream neighbors. A bootstrapping solution MUST
support re-authentication of resource-constrained devices and re-
keying of dynamically generated keys.
Data Confidentiality: the data communication between two endpoints
MAY be encrypted using the derived key, avoiding being eavesdropped
by a non-trusted third part.
Data Integrity: the data communication between two endpoints MUST NOT
be altered by some intermediate nodes. The nodes should be able to
detect the non-integral data.
Keys and key freshness: the keys used for data communication MUST
have a lifetime, in order to keep their freshness. A bootstrapping
solution MUST support both symmetric and asymmetric key
authentication. If distribution of a key to be used for a resource-
constrained device is required, a bootstrapping solution MUST support
secure key distribution to prevent the key from eavesdropping,
alternation and replay attacks.
Multi domain support: A bootstrapping solution MUST be able to allow
resource-constrained devices that may be subscribed to different
administrative domains to be connected to the same access network at
the same time.
Multi domain support: A bootstrapping solution MUST be able to allow
resource-constrained devices to be recommissioned. Recommissioning a
device is defined to be (1) an resource-constrained device is
administratively switched to a different domain, or (2) acting a new
role with a different function set, or (3) both administrative domain
and function set are modified.
Identities: A bootstrapping solution MUST be able to allow a
resource-constrained device to use various types of identities used
for authentication, including device identities, user identities or
combinations of different types of identities. Also a bootstrapping
solution MUST be able to allow a resource-constrained device to
change its identities used for authentication over time.
Authentication infrastructure: A bootstrapping solution MUST be able
to operate with or without an authentication infrastructure.
Sarikaya, et al. Expires March 21, 2013 [Page 7]
Internet-Draft draft-sarikaya-solace September 2012
6. Security Considerations
When security bootstrapping resource constraint nodes is undertaken,
several attacks are possible and security bootstrapping methods
described in this document do not protect the nodes against such
attacks. These attacks are similar to the ones described in
[RFC3971] and mainly stem from unsecured link layer. Link layer must
be secured on each node before the node can begin security
bootstrapping.
If a bootstrapping protocol does not rely on a pre-shared key for
peer authentication, it must rely on an online or offline third-party
(e.g., an authentication server, a key distribution center in
Kerberos, a certification authority in PKI, a private key generator
in ID-based cryptography and so on) to prevent man-in-the-middle
attacks during peer authentication. Depending on use cases, a
resource-constrained device may not always have access to an online
third-party for peer authentication.
Depending on use cases, a bootstrapping protocol may deal with
authorization separately from authentication in terms of timing and
signaling path. For example, two resource-constrained devices A and
B may perform mutual authentication using authentication credentials
provided by an offline third-party X whereas resource-constrained
device A obtains authorization for running a particular application
with resource-constrained device B from an online third-party Y
before or after the authentication. In some use cases,
authentication and authorization are tightly coupled, e.g.,
successful authentication also means successful authorization. A
bootstrapping protocol supports various types of authentication and
authorization or different bootstrapping protocols may be used for
different types of authentication and authorization.
If authorization information includes cryptographic keys, a special
care must be taken for dealing with the keys, e.g., guidelines for
AAA-based key management are described in [RFC4962]. A
recommissioning use case may require revocation and re-installation
of authentication credentials (i.e., a certificate or a shared secret
and identity information, etc.) to a large number of resource-
constrained devices that are already deployed. Re-installation of
authentication credentials must be as secure as the initial
installation regardless of whether the re-installation is done
manually or automatically.
If resource-constrained devices use a multicast group key for peer
authentication or message authentication or encryption, the group key
must be securely distributed to the current members of the group for
both initial key distribution and key update. Protocols designed for
Sarikaya, et al. Expires March 21, 2013 [Page 8]
Internet-Draft draft-sarikaya-solace September 2012
group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and
MIKEY [RFC3830] may be used for group key distribution.
Alternatively, key wrap attributes for securely encapsulating group
key may be defined in network access authentication protocols such as
PANA [RFC5191] and EAP-TTLSv0 [RFC5281]. Those protocols use an end-
to-end, point-to-point communication channel with a pair-wise
security association between a key distribution center and each key
recipient. Further considerations may be needed for more efficient
group key management to support a large number of resource-
constrained devices.
7. EAP, PANA, HIP-DEX and 802.1X
7.1. EAP Authentication Framework
EAP is an authentication protocol that supports a number of
authentication algorithms called EAP methods [RFC5247]. EAP messages
can be transported in different layers: using 802.1X, EAP messages
are carried in Layer 2 and using PANA in IP or Layer 3 between EAP
peer and the authenticator. EAP messages between the authenticator
and authentication server are carried using AAA protocols (RADIUS or
Diameter). The associated AAA server address of each resource-
constrained device is assigned by the domain administrator. In the
recommissioning case, another AAA server is reassigned to devices by
the domain administrator if the device is switched to another domain.
At the end of a successful EAP method execution a master session key
(MSK) is generated at both the EAP peer and EAP server.
Authenticator receives MSK from EAP server at the end of EAP method
execution using key transport. MSK is used in deriving a session key
between the node and the authenticator using a protocol called secure
association protocol (SAP). Derivation of the session key terminates
bootstrapping of a node.
Additional keying material derived between EAP client and server that
is exported by the EAP method is called Extended Master Session Key
(EMSK). EMSK is not used in session key derivation but it could be
used for the needs of other applications in higher layer protocols.
In the architecture introduced in Section 3.2 the node or router is
the peer and the root is the authenticator. When the supplicant and
authenticator are one hop away the authenticator can be reached
directly. However, this is rarely the case. In other cases the
authenticator authenticates neighboring supplicants first. The
router nodes that are authenticated become relay authenticators in
the next phase and they relay authentication messages from the
supplicants to the authenticator and vice versa. This continues
Sarikaya, et al. Expires March 21, 2013 [Page 9]
Internet-Draft draft-sarikaya-solace September 2012
until all nodes are authenticated.
EAP is a lock-step protocol, i.e. it executes in pairs of EAP-Request
messages sent by the server and EAP-Response messages sent by the
peer. At the end, the server indicates the status of authentication,
usually by EAP-Success message which also carries the MSK. The first
EAP-Request/Response pair is used for the server to request the
identity and the peer to provide it. In the other pairs of EAP
exchanges EAP method is executed.
Several EAP methods have been standardized each for different
purposes. To authenticate devices with certificates, EAP Transport
Layer Security (TLS) v1.2 specified in [RFC5216] which supports
certificate-based mutual authentication is used.
Zigbee Alliance's Smart Energy Profile 2.0 Application Protocol
Specification [SE2.0] mandates each device to be factory programmed
with a certificate. The certificate is bound to a unique network ID,
e.g. the device's MAC address or EUI-64 address. During EAP-Identity
exchange the EAP peer provides its EUI-64 address as an identity to
EAP server. This enables the server to validate the device
certificate.
There are three bootstrapping scenarios using EAP.
1. Use of EAP for bootstrapping link-layer security.
In this case, EAP is used for network access authentication to
bootstrap link-layer ciphering. Security for higher-layer (i.e.,
IP layer and above) protocols is bootstrapped from an IB or OOB
mechanism other than EAP.
2. Use of EAP for bootstrapping higher-layer security.
In this case, EAP is used as an OOB mechanism for higher-layer
authentication to bootstrap ciphering keys for one or more
higher-layer protocols independently of network access
authentication. When bootstrapping Constrained Application
Protocol (CoAP) security with DTLS protection, a PSK (Pre-Shared
Key) credential in the combined usage of DTLS (Datagram Transport
Layer Security) [RFC4347] and PSK mode of TLS [RFC4279] is
derived from EAP key material and DTLS ciphering keys are
generated as a result of a successful DTLS handshake. Similarly,
when bootstrapping CoAP security with IPsec ESP protection, a PSK
credential of IKEv2 [RFC5996] is derived from EAP key material
and IPsec ESP ciphering keys are generated as a result of a
successful IKEv2 handshake.
Sarikaya, et al. Expires March 21, 2013 [Page 10]
Internet-Draft draft-sarikaya-solace September 2012
The ability to bootstrap multiple higher-layer protocols from a
single execution of PANA authentication is important to save the
computational resources for resource-constrained devices
especially where public-key based authentication is used.
3. Use of EAP for bootstrapping both link-layer and higher-layer
security.
This case is the combination of the other two cases, and the most
optimized way for bootstrapping resource-constrained devices.
This case is only applicable where both the network access
authentication and the higher-layer authentication use the same
authentication server with the same authentication credentials.
The second and third scenarios are generally referred to as Single
Sign-On in Section 4.2.2.2 of [NISTIR7628VOL1], where the root keys
for higher-layer protocols can be derived from EAP EMSK (Extended
Master Session Key) as an USRK (Usage-Specific Root Key) [RFC5295].
7.2. PANA
PANA (Protocol for carrying Authentication for Network Access)
[RFC5191] defines an EAP transport over UDP where a PANA Client (PaC)
is an EAP peer and a PANA Authentication Agent (PAA) is an EAP
authenticator.
PANA can achieve the authentication, key freshness and data
confidentiality objectives of security bootstrapping.
Multi domain operation is intrinsically supported due to the use of
EAP and AAA.
Even though PANA architecture consisting of PaC, PAA and AAA Server
is generic enough to be used in security bootstrapping, the
architecture introduced in Section 3.2 requires a new element called
PANA Relay Element (PRE). PRE is needed to enable PANA messaging
between a PaC and PAA because the two nodes cannot reach each other
by means of regular IP routing since only a link-local IPv6 address
can be used by PaC prior to the completion of a succesful
authentication.
PRE which is one hop away from PaC receives PANA messages and relays
the message contents (payload) by encapsulating it in a message
parameter called Attribute Value Pair (AVP). PRE also needs to send
header contents such as PaC's IP address and UDP port number in a
different AVP. PRE has IP routing established with PAA which could
be several hops away. PAA sends its reply messages in which the
payload is encapsulated in an AVP. It also adds the AVP containing
Sarikaya, et al. Expires March 21, 2013 [Page 11]
Internet-Draft draft-sarikaya-solace September 2012
PaC's IP address and UDP port number. PRE creates a link local PDU
using these AVPs and sends it to PaC [I-D.ohba-pana-relay].
The requirements for the use of PANA as a bootsrapping protocol can
be stated as follows:
o A new entity called PANA Relay Element may be added to the PANA
architecture. Behaviour of PANA Relay Element needs to be
defined. New AVPs needed for PANA Relay Element operation for
properly relaying messages from the client to the authenticator
and vice versa are required to be specified.
o An extension to PANA to securely distribute keys from the PANA
Authentication Agent to the PANA Client using AES Key Wrap with
Padding algorithm needs to be defined. This is needed in order to
use PANA for multicast group key distribution.
7.3. HIP-DEX
[RFC4423] introduces the Host Identity Protocol (HIP) where the Host
Identity (HI) is a Cryptographic key (RSA, DSA, or ECC). A 128-bit
length Host Identity Tag (HIT) is derived from the HI (hashed) and
functions as an IPv6 address (/128 prefix) for applications. A four-
packet Peer-to-Peer Host Identity Protocol Base EXchange (HIP BEX)
establishes a security association (SA, similar to IKE), indexed by
the HITs, but independent of the IP address. So HIP can be
considered as a shim layer between the transport(TCP/UDP) and IP,
providing authentication, data confidentiality, mobility in one
basket.
As with IKE, HIP is typically used as a Key Management Protocol (KMP)
for ESP. However, HIP is independent of IP and ESP and can be used
for a KMP for any secure communication protocol at any level. Thus
HIP can provide keying material for the MAC, IP, and Transport
layers. HIP can be run directly over the MAC in an Ethernet Frame or
within an Information Element in a MAC control frame. HIP can be run
over UDP, traversing firewalls, and push keys over to Transport
security protocols like SRTP or (D)TLS. Further, HIP could start on
the MAC, then be enveloped over UDP after the first link.
The HIP-BEX involves many crypto primitives that are difficult to run
on constrained nodes. HIP Diet Exchange (HIP-DEX)
[I-D.moskowitz-hip-rg-dex] is a way to make HIP lightweight.
Basically, HIP-DEX a variant of the HIP-BEX specifically designed to
use as few crypto primitives as possible yet still provide the same
class of security features as HIP-BEX.
HIP-DEX can be used for mutual authentication between two endpoints.
Sarikaya, et al. Expires March 21, 2013 [Page 12]
Internet-Draft draft-sarikaya-solace September 2012
After mutual authentication, the two endpints establish a shared
secret, which is fresh and fed into the encryption algorithm for data
confidentiality. So HIP-DEX can achieve the authentication, key
freshness and data confidentiality objectives of security
bootstrapping.
When a node wants to authenticate to the network using HIP and Diet-
HIP, it should be able to complete the HIP-BEX or HIP-DEX with the
trust anchor or some delegate. In HIP, it does not matter how many
domains, and nodes can authenticate each other as long as they have
the secret.
In the architecture introduced in Section 3.2 the node and router
could be the HIP end-points. Or the router could be a HIP Rendezvous
Server, with the node registering to the rendezvous server (RVS)
[RFC5204] to be reachable by other nodes. Typically the initial
interaction will have the node be the HIP DEX Initiator with the
router being the Responder. Using the RVS function on a Router any
node could be the Initiator with any other Responder node. As long
as there is IP connectivity between the Initiator and Responder, they
can be multiple hops away from each other. Alternatively if the
first hop from the Initiator has knowledge of the IP address of the
Responder, it can act as a MAC/IP gateway for HIP.
An important requirement for the HIP-DEX to work in the architecture,
the initiator should be able to get the IP address of the responder
or have a gateway function as a forwarder. The IP address can be
obtained from a 3rd party source like DNS of Distributed Hash Table
(DHT), from local configuration, or from an RVS.
7.4. 802.1X
IEEE 802.1X defines how EAP packets can be transported over in Layer
2, i.e. Ethernet frames [802.1x] by encapsulating EAP packets into
EAP Over Lan (EAPOL) frames between EAP peer, called supplicant and
the authenticator. EAPOL can also be used in 802.11 wireless links.
To enable IEEE 802.15.4 devices to use EAP authentication, EAP
packets encapsulated in EAPOL frames can be carried as payload in
802.15.4 data frames [802.15.4]. EAPOL is well defined and widely
used and it lends itself to be easily carried in 802.15.4 data
frames. For this, Frame Type subfield of the Frame Control Field of
IEEE 802.15.4 MAC header needs to be set to a special value to
indicate the type of the payload, i.e. 802.1X encapsulated EAP
packets. EAPOL packets are encoded following common EAPOL PDU
structure defined in [802.1x] into the data payload field of 802.15.4
data frames.
Sarikaya, et al. Expires March 21, 2013 [Page 13]
Internet-Draft draft-sarikaya-solace September 2012
Authentication proceeds as follows: authenticator authenticates the
supplicants that are on the next hop first. This enables a secure
link between the authenticator and these first-hop nodes. The
architecture introduced in Section 3.2 requires a new entity called
Relay Authenticator. First-hop nodes or router become Relay
Authenticators in the next phase of authentication. Relay
Authenticators tunnel EAPOL frames to the authenticator in the secure
link established. This way all the supplicants are gradually
authenticated.
After the keys are established from a successful EAP method (such as
PSK mode of TLS), the node runs neighbor discovery protocol to get an
IPv6 address assigned [I-D.ietf-6lowpan-nd]. Data transfer can be
secured using DTLS or IPSec. Keys derived from EAP TLS are used in
either generating DTLS ciphering keys after a successful DTLS
handshake or IPSec ESP ciphering keys after a successful IKEv2
handshake.
802.1X can achieve the authentication, key freshness and data
confidentiality objectives of security bootstrapping.
Multi domain operation is intrinsically supported due to the use of
EAP and AAA. In order to support a device recommissioning case
whereby the device's administrative domain is modified, after a new
AAA server address assigned and a successful 802.1X method execution,
the old set of device 'name and password' MUST be overwritten into
the device by a new set of 'name and password' that are assigned by
the domain administrator. The device MUST be rebooted to execute EAP
method again for authentication and a new master session key MUST be
generated.
It should be noted that currently 802.15.4 does not allow
multiplexing multiple protocols on the same link like ethernet does.
However this might change in the future.
The requirements for the use of 802.1X defined EAPOL as a
bootsrapping protocol can be stated as follows:
o A special value in the Frame Type subfield of the Frame Control
Field of IEEE 802.15.4 MAC header to indicate the type of the
payload,
o Link Layer Multicast Group addresses for 802.15.4 corresponding to
EAPOL Group Address Assignments defined in Table 11.1 of [802.1x],
especially to be used in EAPOL-Start packet.
o Which MAC frames of beacon, data, acknowledgment and MAC command
as defined in [802.15.4] with what security levels are mapped to
Sarikaya, et al. Expires March 21, 2013 [Page 14]
Internet-Draft draft-sarikaya-solace September 2012
controlled port, which MAC frames with what security levels are
mapped to uncontrolled port and which MAC frames are never mapped
to any of controlled/uncontrolled port (i.e., the payload of those
frames are used by the MAC-layer ieself and never used by upper
layers).
o A new entity called Relay Authenticator may be added to the 802.1x
architecture. Behaviour of Relay Authenticator needs to be
defined.
8. IANA Considerations
This memo includes no request to IANA.
9. Acknowledgements
TBD.
10. References
10.1. Normative References
[802.15.4]
IEEE Std 802.15.4-2006, "Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low Rate
Wireless Personal Area Networks (WPANs)", September 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
Sarikaya, et al. Expires March 21, 2013 [Page 15]
Internet-Draft draft-sarikaya-solace September 2012
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
10.2. Informative References
[802.1x] IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network
Access Control", February 2010.
[I-D.garcia-core-security]
Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-04 (work
in progress), March 2012.
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress),
August 2012.
[I-D.moskowitz-hip-rg-dex]
Moskowitz, R., "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-rg-dex-06 (work in progress),
May 2012.
[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-03
(work in progress), February 2011.
[NISTIR7628VOL1]
The Smart Grid Interoperability Panel - Cyber Security
Working Group, "Guidelines for Smart Grid Cyber Security:
Vol. 1, Smart Grid Cyber Security Strategy, Architecture,
and High-Level Requirements", NISTIR 7628, vol. 1, 2010.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
Sarikaya, et al. Expires March 21, 2013 [Page 16]
Internet-Draft draft-sarikaya-solace September 2012
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279,
December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
August 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
Sarikaya, et al. Expires March 21, 2013 [Page 17]
Internet-Draft draft-sarikaya-solace September 2012
[ROMER04] Romer, K. and F. Mattern, "The design space of wireless
sensor networks", IEEE Wireless Communications, vol. 11,
no. 6, pp. 54-61, December 2004.
[SE2.0] ZigBee Alliance, "Smart Energy Profile 2.0 Technical
Requirements Document", April 2010.
Authors' Addresses
Behcet Sarikaya
Huawei USA
5340 Legacy Dr.
Plano, TX 75024
Email: sarikaya@ieee.org
Yoshihiro Ohba
Toshiba
Tokyo, Japan
Email: yoshihiro.ohba@toshiba.co.jp
Robert Moskowitz
Verizon Business Systems
15210 Sutherland
Oak Park, MI 48237
Email: rgm@labs.htt-consult.com
Zhen Cao
China Mobile
Beijing, China
Email: caozhen@chinamobile.com
Robert Cragie
Pacific Gas and Electric
89 Greenfield Crescent
Wakefield, UK WF4 4WA
Email: robert.cragie@gridmerge.com
Sarikaya, et al. Expires March 21, 2013 [Page 18]
