draft-ietf-6lo-mle-hip-dex-00.txt   draft-ietf-6lo-mle-hip-dex-01.txt 
Network Working Group Y. Ohba, Ed. Network Working Group Y. Ohba, Ed.
Internet-Draft Toshiba Internet-Draft Toshiba
Intended status: Experimental November 24, 2015 Intended status: Experimental April 19, 2016
Expires: May 27, 2016 Expires: October 21, 2016
An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol
Diet Exchange (HIP DEX) Diet Exchange (HIP DEX)
draft-ietf-6lo-mle-hip-dex-00 draft-ietf-6lo-mle-hip-dex-01
Abstract Abstract
HIP DEX (Host Identity Protocol Diet EXchange) is a light-weight key HIP DEX (Host Identity Protocol Diet EXchange) is a light-weight key
exchange protocol designed for constrained devices. MLE (Mesh Link exchange protocol designed for constrained devices. MLE (Mesh Link
Establishment) is defined for establishing and configuring secure Establishment) is defined for establishing and configuring secure
links in IEEE 802.15.4 mesh networks. This document defines an links in IEEE 802.15.4 mesh networks. This document defines an
extension of MLE protocol to encapsulate HIP DEX key exchange extension of MLE protocol to encapsulate HIP DEX key exchange
protocol messages. protocol messages.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 27, 2016. This Internet-Draft will expire on October 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1.3. Convention . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Convention . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Establishment Phase . . . . . . . . . . . . . . . . . . . 4 3. Key Establishment Phase . . . . . . . . . . . . . . . . . . . 4
4. Key Update Phase . . . . . . . . . . . . . . . . . . . . . . 6 4. Key Update Phase . . . . . . . . . . . . . . . . . . . . . . 6
5. Key Materials . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Key Materials . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Pair-wise Key . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Pair-wise Key . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . 7
6. MLE Security . . . . . . . . . . . . . . . . . . . . . . . . 8 6. MLE Security . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Certificate Revocation . . . . . . . . . . . . . . . . . . . 8 7. Certificate Revocation . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. MLE TLV Types . . . . . . . . . . . . . . . . . . . . . . 9 9.1. MLE TLV Types . . . . . . . . . . . . . . . . . . . . . . 10
9.2. HIP Parameter . . . . . . . . . . . . . . . . . . . . . . 10 9.2. HIP Parameter . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. External Informative References . . . . . . . . . . . . 11 11.2. External Informative References . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
HIP DEX (Host Identity Protocol Diet EXchange) HIP DEX (Host Identity Protocol Diet EXchange) [I-D.ietf-hip-dex] is
[I-D.moskowitz-hip-dex] is a light-weight key exchange protocol a light-weight key exchange protocol designed for constrained
designed for constrained devices. HIP DEX builds on the HIP Base devices. HIP DEX builds on the HIP Base EXchange (HIP BEX)
EXchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] and inherits the [I-D.ietf-hip-rfc5201-bis] and inherits the transport-agnostic
transport-agnostic property of HIP BEX. property of HIP BEX.
MLE (Mesh Link Establishment) MLE (Mesh Link Establishment) [I-D.ietf-6lo-mesh-link-establishment]
[I-D.kelsey-6lo-mesh-link-establishment] is defined for establishing is defined for establishing and configuring secure links in IEEE
and configuring secure links in IEEE 802.15.4 mesh networks. MLE 802.15.4 mesh networks. MLE assumes that shared keys to secure link-
assumes that shared keys to secure link-layer frames and MLE messages layer frames and MLE messages exchanged between a pair of nodes are
exchanged between a pair of nodes are pre-configured between the pre-configured between the nodes. Therefore, a key exchange protocol
nodes. Therefore, a key exchange protocol is required in order to is required in order to dynamically configure the required shared
dynamically configure the required shared keys. While such a key keys. While such a key exchange protocol can be run outside MLE,
exchange protocol can be run outside MLE, sequentially running a key sequentially running a key exchange protocol and MLE as separate
exchange protocol and MLE as separate protocols requires more message protocols requires more message roundtrips. For example, running a
roundtrips. For example, running a HIP DEX 4-way handshake followed HIP DEX 4-way handshake followed by an MLE 3-way handshake requires
by an MLE 3-way handshake requires 3.5 message roundtrips. 3.5 message roundtrips.
In this document, an extension to the MLE protocol for encapsulating In this document, an extension to the MLE protocol for encapsulating
HIP DEX messages is defined in order to realize optimized key HIP DEX messages is defined in order to realize optimized key
exchange and link establishment for IEEE 802.15.4 mesh networks. exchange and link establishment for IEEE 802.15.4 mesh networks.
1.1. Requirement Language 1.1. Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
skipping to change at page 4, line 20 skipping to change at page 4, line 20
and UR roles for a pair of nodes may be determined independently of and UR roles for a pair of nodes may be determined independently of
the EI and ER roles that have been taken by the nodes. the EI and ER roles that have been taken by the nodes.
All MLE messages used for the extension defined in this document All MLE messages used for the extension defined in this document
SHOULD NOT be protected by link-layer so that a key exchange can be SHOULD NOT be protected by link-layer so that a key exchange can be
done regardless of the security state of the link-layer. A node that done regardless of the security state of the link-layer. A node that
implements this specification MUST allow sending and receiving MLE implements this specification MUST allow sending and receiving MLE
messages not secured by the link-layer. messages not secured by the link-layer.
Secured 802.15.4 MAC frames and MLE messages that use keys Secured 802.15.4 MAC frames and MLE messages that use keys
established via HIP DEX MUST use a 5-octet Frame Counter so that the established via HIP DEX MUST use a 5-octet Frame Counter. An MLE
Frame Counter does not reach its maximum value throughout the Frame Counter is always carried in the Frame Counter field in the Aux
lifetime of a node. An MLE Frame Counter is always carried in the Header of any secured MLE frame. Note that [IEEE802154e] supports
Frame Counter field in the Aux Header of any secured MLE frame. 5-octet MAC Frame Counter for CSMA (Carrier Sense Multiple Access)
and uses 5-octet ASN (Absolute Slot Number) as MAC Frame Counter for
TSCH (Time-Slotted Channel Hopping) MAC.
Other than the rules described in this document, the rules defined in Other than the rules described in this document, the rules defined in
[I-D.kelsey-6lo-mesh-link-establishment] are preserved. [I-D.ietf-6lo-mesh-link-establishment] are preserved.
3. Key Establishment Phase 3. Key Establishment Phase
A message exchange diagram for Key Establishment Phase is shown in A message exchange diagram for Key Establishment Phase is shown in
Figure 1. Figure 1.
(EI) (ER) (EI) (ER)
--> Advertisement [HIP{DEX-I1}, Link Quality] --> Advertisement [HIP{DEX-I1}, Link Quality]
<-- Advertisement [HIP{DEX-R1}, Link Quality] <-- Advertisement [HIP{DEX-R1}, Link Quality]
skipping to change at page 5, line 9 skipping to change at page 5, line 13
Figure 1: Key Establishment Phase Figure 1: Key Establishment Phase
An EI sends an MLE Advertisement message containing a HIP TLV and a An EI sends an MLE Advertisement message containing a HIP TLV and a
Link Quality TLV to an ER. The HIP TLV carries a DEX-I1 packet. How Link Quality TLV to an ER. The HIP TLV carries a DEX-I1 packet. How
an EI discovers an ER is outside the scope of this document. an EI discovers an ER is outside the scope of this document.
The ER receives the MLE Advertisement message containing a DEX-I1 The ER receives the MLE Advertisement message containing a DEX-I1
packet from the EI and sends an MLE Advertisement message containing packet from the EI and sends an MLE Advertisement message containing
a HIP TLV and a Link Quality TLV to the EI. The HIP TLV carries a a HIP TLV and a Link Quality TLV to the EI. The HIP TLV carries a
DEX-R1 packet. The DEX-R1 packet MUST contain mandatory R1 DEX-R1 packet. The DEX-R1 packet MUST contain mandatory R1
parameters specified in [I-D.moskowitz-hip-dex]. The DEX-R1 packet parameters specified in [I-D.ietf-hip-dex]. The DEX-R1 packet MAY
MAY contain optional R1 parameters specified in contain optional R1 parameters specified in [I-D.ietf-hip-dex] and a
[I-D.moskowitz-hip-dex] and a CERT parameter defined in [RFC6253]. CERT parameter defined in [RFC6253].
The EI receives the MLE Advertisement message from the ER and sends a The EI receives the MLE Advertisement message from the ER and sends a
secured MLE Link Request message containing HIP, Source Address, secured MLE Link Request message containing HIP, Source Address,
Mode, Timeout and Challenge TLVs to the ER. The HIP TLV carries a Mode, Timeout and Challenge TLVs to the ER. The HIP TLV carries a
DEX-I2 packet. The DEX-I2 packet MUST contain mandatory I2 DEX-I2 packet. The DEX-I2 packet MUST contain mandatory I2
parameters specified in [I-D.moskowitz-hip-dex] including an parameters specified in [I-D.ietf-hip-dex] including an ENCRYPTED_KEY
ENCRYPTED_KEY parameter wrapping a session key material of the EI. parameter wrapping a session key material of the EI. The DEX-I2
The DEX-I2 packet MUST also contain an ENCRYPTED parameter wrapping packet MUST also contain an ENCRYPTED parameter wrapping group key
group key materials of the EI. The DEX-I2 packet MAY contain materials of the EI. The DEX-I2 packet MAY contain optional I2
optional I2 parameters specified in [I-D.moskowitz-hip-dex] and a parameters specified in [I-D.ietf-hip-dex] and a CERT parameter
CERT parameter defined in [RFC6253]. The MLE Link Request message is defined in [RFC6253]. The MLE Link Request message is protected by
protected by the EI's group MLE key (see section Section 5.2) derived the EI's group MLE key (see section Section 5.2) derived from the
from the EI's group key materials. EI's group key materials.
The ER receives the MLE Link Request message from the EI and extracts The ER receives the MLE Link Request message from the EI and extracts
the EI's session key material wrapped in the ENCRYPTED_KEY parameter the EI's session key material wrapped in the ENCRYPTED_KEY parameter
and the EI's group key materials wrapped in the ENCRYPTED parameter. and the EI's group key materials wrapped in the ENCRYPTED parameter.
Then the ER sends a secured MLE Link Accept and Request message Then the ER sends a secured MLE Link Accept and Request message
containing HIP, LLFC, MLFC, Source Address, Mode Timeout, Response containing HIP, LLFC, MLFC, Source Address, Mode Timeout, Response
and Challenge TLVs to the EI. The HIP TLV carries a DEX-R2 packet. and Challenge TLVs to the EI. The HIP TLV carries a DEX-R2 packet.
The DEX-R2 packet MUST contain R2 parameters specified in The DEX-R2 packet MUST contain R2 parameters specified in
[I-D.moskowitz-hip-dex] including an ENCRYPTED_KEY parameter wrapping [I-D.ietf-hip-dex] including an ENCRYPTED_KEY parameter wrapping a
a session key material of the ER. The DEX-R2 packet MUST also session key material of the ER. The DEX-R2 packet MUST also contain
contain an ENCRYPTED parameter wrapping group key materials of the an ENCRYPTED parameter wrapping group key materials of the ER. The
ER. The DEX-R2 packet MAY contain optional R2 parameters specified DEX-R2 packet MAY contain optional R2 parameters specified in
in [I-D.moskowitz-hip-dex]. Note that the MIC field of the MLE Link [I-D.ietf-hip-dex]. Note that the MIC field of the MLE Link Request
Request message is verified after the ER successfully extracts the message is verified after the ER successfully extracts the EI's group
EI's group key materials. key materials.
The EI receives the MLE Link Accept and Request message from the ER The EI receives the MLE Link Accept and Request message from the ER
and extracts the ER's session key material wrapped in the and extracts the ER's session key material wrapped in the
ENCRYPTED_KEY parameter and the ER's group key materials wrapped in ENCRYPTED_KEY parameter and the ER's group key materials wrapped in
the ENCRYPTED parameter. Then the EI sends a secured MLE Link Accept the ENCRYPTED parameter. Then the EI sends a secured MLE Link Accept
message containing LLFC TLV, MLFC and Response TLVs to the ER. If a message containing LLFC TLV, MLFC and Response TLVs to the ER. If a
pair-wise key is used by the link-layer, the EI also creates a Pair- pair-wise key is used by the link-layer, the EI also creates a Pair-
wise Key SA with the session key generated by the pair of session key wise Key SA with the session key generated by the pair of session key
materials of the EI and ER as specified in [I-D.moskowitz-hip-dex]. materials of the EI and ER as specified in [I-D.ietf-hip-dex]. Note
Note that the MIC field of the MLE Link Accept and Request message is that the MIC field of the MLE Link Accept and Request message is
verified after the EI successfully extracts the ER's group key verified after the EI successfully extracts the ER's group key
materials. materials.
The ER receives the MLE Link Accept message from the EI. If a pair- The ER receives the MLE Link Accept message from the EI. If a pair-
wise key is used by the link-layer, the EI creates a Pair-wise Key SA wise key is used by the link-layer, the EI creates a Pair-wise Key SA
with the session key generated by the pair of session key materials with the session key generated by the pair of session key materials
of the EI and ER as specified in [I-D.moskowitz-hip-dex]. of the EI and ER as specified in [I-D.ietf-hip-dex].
In addition to initial key establishment time, Key Establishment
Phase is also entered when an outgoing MAC Frame Counter or an
outgoing MLE Frame Counter of a node reaches its maximum value (this
is almost unlikely to happen with 5-octet Frame Counter, though). In
this case, the node MUST first update its HIP-DEX certificate before
re-entering Key Establishment Phase. How a HIP-DEX certificate is
updated is out of the scope of this document.
4. Key Update Phase 4. Key Update Phase
In Key Update Phase, group key materials are updated. In Key Update Phase, group key materials are updated.
Since the 5-octet Frame Counter space is large enough considering the A Key Update Phase is invoked when a peer node that shares the group
maximum bandwidth of 250Kbps in 802.15.4 [IEEE802154] to make an key is revoked. Both link-layer Frame Counters and MLE Frame
assumption that a Frame Counter does not reach its maximum value Counters are not reset in the Key Update Phase. A message exchange
throughout the lifetime of a node, a mechanism for updating a pair- diagram for group key update is shown in Figure 2.
wise key is not defined in this document. Both link-layer Frame
Counters and MLE Frame Counters are not reset in the Key Update
Phase.
Updating a group key may happen when a node that shares the group key
is revoked. A message exchange diagram for group key update is shown
in Figure 2.
(UI) (UR1)..(URn) (UI) (UR1)..(URn)
// Update 1st peer // Update 1st peer
----> Update Request [HIP{DEX-UPDATE}, MLFC, Source Address]* ----> Update Request [HIP{UPDATE}, MLFC, Source Address]*
<---- Update [HIP{DEX-UPDATE}, MLFC, Source Address]* <---- Update [HIP{UPDATE}, MLFC, Source Address]*
.. .. .. ..
// Update n-th peer // Update n-th peer
-----------> Update Request [HIP{DEX-UPDATE}, MLFC, Source Address]* -----------> Update Request [HIP{UPDATE}, MLFC, Source Address]*
<----------- Update [HIP{DEX-UPDATE}, MLFC, Source Address]* <----------- Update [HIP{UPDATE}, MLFC, Source Address]*
// Key switch notification (multicast) // Key switch notification (multicast)
----> .. --> Update [LLFC, MLFC]* ----> .. --> Update [LLFC, MLFC]*
Figure 2: Group Key Update Figure 2: Group Key Update
First, a UI performs the following exchange for each UR: First, a UI performs the following exchange for each UR:
o The UI sends an MLE Update Request message containing HIP, MLFC, o The UI sends an MLE Update Request message containing HIP, MLFC,
Source Address and MIC TLVs to a UR. The HIP TLV carries a DEX- Source Address and MIC TLVs to a UR. The HIP TLV carries a HIP
UPDATE packet containing SEC, MAC and ENCRYPTED parameters. The UPDATE packet containing SEQ, HIP_MAC and ENCRYPTED parameters.
ENCRYPTED parameter wraps new group key materials of the UI. The ENCRYPTED parameter wraps new group key materials of the UI.
o The UR receives the MLE Update Request message from the UI, o The UR receives the MLE Update Request message from the UI,
extracts UI's new group key materials from the ENCRYPTED extracts UI's new group key materials from the ENCRYPTED
parameter, activates the UI's new group key materials for incoming parameter, activates the UI's new group key materials for incoming
frames, and sends an MLE Update message containing HIP, MLFC and frames, and sends an MLE Update message containing HIP, MLFC and
Source Address TLVs, where the HIP TLV carries a DEX-UPDATE packet Source Address TLVs, where the HIP TLV carries a HIP UPDATE packet
containing ACK and MAC parameters. Note that the MIC field of the containing ACK and HIP_MAC parameters. Note that the MIC field of
MLE Update message is verified after the UR successfully extracts the MLE Update message is verified after the UR successfully
the UI's new group key materials. extracts the UI's new group key materials.
Once MLE Update Request and Update exchange is completed for all URs, Once MLE Update Request and Update exchange is completed for all URs,
the UI activates the UI's new group key materials for outgoing frames the UI activates the UI's new group key materials for outgoing frames
by multicasting an MLE Update message containing LLFC and MLFC TLVs. by multicasting an MLE Update message containing LLFC and MLFC TLVs.
The MLE Update message is protected by the UI's group MLE key (see The MLE Update message is protected by the UI's group MLE key (see
section Section 5.2) derived from the UI's new group key materials. section Section 5.2) derived from the UI's new group key materials.
When a UR receives the multicast MLE Update message, If the received When a UR receives the multicast MLE Update message, If the received
message is valid, the UR deactivates the UI's old group key materials message is valid, the UR deactivates the UI's old group key materials
for incoming frames. for incoming frames.
skipping to change at page 7, line 28 skipping to change at page 7, line 34
A UR that did not receive the multicast MLE Update message may A UR that did not receive the multicast MLE Update message may
deactivate the UI's old group key materials for incoming frames when deactivate the UI's old group key materials for incoming frames when
it receives a valid MAC frame protected by the link-layer key derived it receives a valid MAC frame protected by the link-layer key derived
from the UI's new group key materials. from the UI's new group key materials.
5. Key Materials 5. Key Materials
5.1. Pair-wise Key 5.1. Pair-wise Key
The first 16 octets of the session key corresponding to the HIP DEX The first 16 octets of the session key corresponding to the HIP DEX
Pair-wise SA [I-D.moskowitz-hip-dex] is used as the pairwise link- Pair-wise SA [I-D.ietf-hip-dex] is used as the pairwise link-layer
layer key used for securing unicast link-layer frames with Key key used for securing unicast link-layer frames with Key Identifier
Identifier Mode 0x00. Mode 0x00.
An encrypted session key material is contained in an ENCRYPTED_KEY An encrypted session key material is contained in an ENCRYPTED_KEY
parameter of HIP when the session key is distributed during Key parameter of HIP when the session key is distributed during Key
Establishment Phase. Establishment Phase.
5.2. Group Keys 5.2. Group Keys
Group key materials are created by a node and distributed to peer Group key materials are created by a node and distributed to peer
nodes. nodes.
skipping to change at page 8, line 23 skipping to change at page 8, line 28
A GroupMLEKey MUST be used for securing MLE messages with Key A GroupMLEKey MUST be used for securing MLE messages with Key
Identifier Mode 0x03 sent by the node that created the group key Identifier Mode 0x03 sent by the node that created the group key
material. material.
The group key materials are contained in an GROUP_KEY_MATERIALS The group key materials are contained in an GROUP_KEY_MATERIALS
parameter of HIP, where the GROUP_KEY_MATERIALS parameter MUST be parameter of HIP, where the GROUP_KEY_MATERIALS parameter MUST be
encrypted in an ENCRYPTED parameter of HIP. encrypted in an ENCRYPTED parameter of HIP.
6. MLE Security 6. MLE Security
As described in [I-D.kelsey-6lo-mesh-link-establishment], MLE As described in [I-D.ietf-6lo-mesh-link-establishment], MLE security
security reuses that of IEEE 802.15.4, i.e., AES-CCM* [IEEE802154]. reuses that of IEEE 802.15.4, i.e., AES-CCM* [IEEE802154]. Since
Since some of the MLE messages (i.e., MLE Link Accept and Request and some of the MLE messages (i.e., MLE Link Accept and Request and MLE
MLE Accept messages carrying DEX-I2 and DEX-R2 packets, respectively, Accept messages carrying DEX-I2 and DEX-R2 packets, respectively, and
and unicast MLE Update Request and Update messages carrying a DEX- unicast MLE Update Request and Update messages carrying a DEX-UPDATE
UPDATE packet) require to be sent unencrypted and only authentication packet) require to be sent unencrypted and only authentication is
is needed, MIC-64 (Security Level 2) or MIC-128 (Security Level 3) is needed, MIC-64 (Security Level 2) or MIC-128 (Security Level 3) is
used to secure MLE messages. MIC-64 is the default security level used to secure MLE messages. MIC-64 is the default security level
for securing MLE messages used in this document. GroupMLEKey (see for securing MLE messages used in this document. GroupMLEKey (see
section Section 5.2) with Key Identifier Mode 0x03 and a 5-octet section Section 5.2) with Key Identifier Mode 0x03 and a 5-octet
Frame Counter MUST be used for any secured MLE message. Frame Counter MUST be used for any secured MLE message.
7. Certificate Revocation 7. Certificate Revocation
Any MLE message used in this document MAY also contain a CRL Any MLE message used in this document MAY also contain a CRL
(Certificate Revocation List) TLV in which CertificateList defined in (Certificate Revocation List) TLV in which CertificateList defined in
[RFC5280] is encoded in the Value field. A complete CRL or a delta [RFC5280] is encoded in the Value field. A complete CRL or a delta
CRL is contained in a CRL TLV. A node that receives a valid MLE CRL is contained in a CRL TLV. A node that receives a valid MLE
message containing a CRL TLV revokes certificates specified in the message containing a CRL TLV revokes certificates specified in the
TLV and deletes all pair-wise and group keys associated with the TLV and deletes all pair-wise and group keys associated with the
revoked certificates. A node MUST reject a CERT parameter for a revoked certificates. A node MUST reject a CERT parameter for a
revoked certificate in Key Establishment Phase. revoked certificate in Key Establishment Phase.
When a CRL TLV is carried in a multicast Update message and forwarded When a CRL TLV is carried in a multicast Update message and forwarded
multiple hops, MPL [I-D.ietf-roll-trickle-mcast] MAY be used. In multiple hops, MPL [RFC7731] MAY be used. In this case, the
this case, the multicast Update message MUST be secured at the link multicast Update message MUST be secured at the link layer and MUST
layer and MUST NOT be secured by MLE as specified in NOT be secured by MLE as specified in
[I-D.kelsey-6lo-mesh-link-establishment]. Detailed MPL parameters [I-D.ietf-6lo-mesh-link-establishment]. Detailed MPL parameters for
for the multicast-based CRL distribution are out of the scope of this the multicast-based CRL distribution are out of the scope of this
document. document.
In order to reduce the size of a CRL, there are several guidelines. In order to reduce the size of a CRL, there are several guidelines.
A delta CRL should be used whenever applicable. Expired certificates A delta CRL should be used whenever applicable. Expired certificates
should be excluded from a CRL. A short lived (e.g., one month) should be excluded from a CRL. A short lived (e.g., one month)
certificate may be used (at the cost of increased frequency of certificate may be used (at the cost of increased frequency of
certificate updates). Hierarchically formed CAs may be used where certificate updates). Hierarchically formed CAs may be used where
each CA is expected to sign only a small number of certificates. each CA is expected to sign only a small number of certificates.
8. Security Considerations 8. Security Considerations
The MLE extension defined in this document uses HIP DEX for key The MLE extension defined in this document uses HIP DEX for key
management of computation or memory constrained sensor/actuator management of computation or memory constrained sensor/actuator
devices, and thus it inherits all security considerations made for devices, and thus it inherits all security considerations made for
HIP DEX [I-D.moskowitz-hip-dex]. HIP DEX [I-D.ietf-hip-dex].
In order to mitigate security weakness caused by lack of Perfect In order to mitigate security weakness caused by lack of Perfect
Forward Secrecy (PFS) in HIP DEX, it is RECOMMENDED to use this MLE Forward Secrecy (PFS) in HIP DEX, it is RECOMMENDED to use this MLE
extension in conjunction with an additional mechanism to update extension in conjunction with an additional mechanism to update
public/private key pairs and renew HIP DEX SAs using new public/ public/private key pairs and renew HIP DEX SAs using new public/
private key pairs whenever necessary. private key pairs whenever necessary.
In both Key Establishment Phase and Key Update Phase, MLE messages In both Key Establishment Phase and Key Update Phase, MLE messages
are secured using a group key instead of a pairwise key in order to are secured using a group key instead of a pairwise key in order to
optimize message roundtrips since a group key establishment requires optimize message roundtrips since a group key establishment requires
skipping to change at page 9, line 46 skipping to change at page 10, line 10
attack described above. Note that authentication of the MLE message attack described above. Note that authentication of the MLE message
carrying a DEX-I2, DEX-R2 or DEX-UPDATE packet is possible by carrying a DEX-I2, DEX-R2 or DEX-UPDATE packet is possible by
validating MIC of the MLE message after extracting the authentication validating MIC of the MLE message after extracting the authentication
key (i.e., GroupMLEKey) from the HIP DEX packet. key (i.e., GroupMLEKey) from the HIP DEX packet.
9. IANA Considerations 9. IANA Considerations
9.1. MLE TLV Types 9.1. MLE TLV Types
The following MLE TLV types are to be assigned by IANA based on the The following MLE TLV types are to be assigned by IANA based on the
policy described in [I-D.kelsey-6lo-mesh-link-establishment]: policy described in [I-D.ietf-6lo-mesh-link-establishment]:
o HIP-DEX (Value: 9, Length: Variable, Meaning: HIP DEX packet, o HIP-DEX (Value: 9, Length: Variable, Meaning: HIP DEX packet,
Reference: this document). Reference: this document).
o CRL (Value: 10, Length: Variable, Meaning: Certificate Revocation o CRL (Value: 10, Length: Variable, Meaning: Certificate Revocation
List, Reference: this document). List, Reference: this document).
9.2. HIP Parameter 9.2. HIP Parameter
The following HIP Parameter is assigned based on the policy described The following HIP Parameter is assigned based on the policy described
skipping to change at page 10, line 37 skipping to change at page 10, line 50
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", RFC 6253, DOI 10.17487/RFC6253, May 2011, Certificates", RFC 6253, DOI 10.17487/RFC6253, May 2011,
<http://www.rfc-editor.org/info/rfc6253>. <http://www.rfc-editor.org/info/rfc6253>.
[I-D.moskowitz-hip-dex] [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
February 2016, <http://www.rfc-editor.org/info/rfc7731>.
[I-D.ietf-hip-dex]
Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-dex-04 (work in progress), July 2015. draft-ietf-hip-dex-02 (work in progress), March 2016.
[I-D.ietf-hip-rfc5201-bis] [I-D.ietf-hip-rfc5201-bis]
Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
"Host Identity Protocol Version 2 (HIPv2)", draft-ietf- "Host Identity Protocol Version 2 (HIPv2)", draft-ietf-
hip-rfc5201-bis-20 (work in progress), October 2014. hip-rfc5201-bis-20 (work in progress), October 2014.
[I-D.kelsey-6lo-mesh-link-establishment] [I-D.ietf-6lo-mesh-link-establishment]
Kelsey, R., "Mesh Link Establishment", draft-kelsey-6lo- Kelsey, R., "Mesh Link Establishment", draft-ietf-6lo-
mesh-link-establishment-00 (work in progress), July 2015. mesh-link-establishment-00 (work in progress), December
2015.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-12 (work in progress), June 2015.
11.2. External Informative References 11.2. External Informative References
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", June 2011. Wireless Personal Area Networks", June 2011.
[IEEE802154e]
IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks - Amendment 1: MAC
sublayer (Amendment to IEEE Std 802.15.4-2011)", April
2012.
Author's Address Author's Address
Yoshihiro Ohba (editor) Yoshihiro Ohba (editor)
Toshiba Electronics Asia Toshiba Electronics Asia
20 Pasir Panjang Road, #12-25/28, Mapletree Business City 20 Pasir Panjang Road, #12-25/28, Mapletree Business City
117439 117439
Singapore Singapore
Phone: +65 6278 5252 Phone: +65 6278 5252
Email: yoshihiro.ohba@toshiba.co.jp Email: yoshihiro.ohba@toshiba.co.jp
 End of changes. 29 change blocks. 
104 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/