| Networking Working Group | R.K. Alexander |
| Internet-Draft | T. Tsao |
| Intended status: Standards Track | Cooper Power Systems |
| Expires: March 03, 2013 | September 2012 |
Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments
draft-alexander-roll-mikey-lln-key-mgmt-04
Multimedia Internet Keying (MIKEY) is a key management protocol used for real-time applications. As standardized within RFC3830 it defines four key distribution methods, including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange, with allowances for ready protocol extension. A number of additional methods have been developed and continue to be built from the base protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility and more general applicability, MIKEY and its related extensions have primarily focused on the support of the Secure Real-time Transport Protocol (SRTP).
This document specifies a simple adaptation of the MIKEY specification to allow the base protocol and its various key management mode extensions to be readily applied in more general environments beyond the multimedia SRTP domain. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure and introduces a set of message extensions to the base specification to allow the MIKEY key management methods to be applied within Low-power and Lossy Networks (LLNs) and other general constrained-device networks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
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 03, 2013.
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 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.
Any sufficiently large scale network offering security services requires an automated key management mechanism for the exchange of keys and the update of related security credentials [RFC4107]. Key management may be needed for individual session exchanges or for the long-term control and update of security parameters from which session keys may be derived. In many Low-power and Lossy Networks (LLN) and other constrained-device environments, key management emphasis is often on the management of long-term keys. This may automatically follow network associations based on device pre-configuration or may be based on specified key lifetimes or administrative or event-driven need for key credential changes. This would apply to the case of a network routing protocol like RPL ([RFC6550]) that employs security as well as to other secured communications layer protocols.
Multimedia Internet Keying (MIKEY) is a key management protocol that has been used for real-time applications both for peer-to-peer and group communications. The capabilities of the protocol lend themselves just as readily to the management of long-term keys as to per-session or per association key control. MIKEY [RFC3830] defines four key distribution methods including pre-shared keys, public-key encryption, and Diffie-Hellman key exchange. Given its design simplicity, efficiency and flexibility a number of additional modes and extensions have indeed been developed and continue to be built from the base protocol (see for example, [RFC4442], [RFC4563], [RFC4650], [RFC4738], [RFC5410], [RFC6043] and [RFC6267]). MIKEY and its related RFC extensions have however primarily focused on the support of the SRTP and related Session Initiation Protocol (SIP) call scenarios [RFC3711].
This document specifies an adaptation of the MIKEY protocol specification to allow the base protocol and its various key management mode extensions to be more generally applied to LLN environments. In particular, the document defines a repurposing of the MIKEY multimedia crypto sessions structure to allow optional support for simultaneous management of multiple protocol or device interface key. The specification also introduces a set of message extensions to the base MIKEY protocol to allow its key management methods to be applied within generic LLN and constrained-device networks.
Key distribution describes the process of delivering cryptographic keys to the required communicating parties. The MIKEY protocol has defined the mechanisms for establishing the security context used by SRTP however the mechanisms for security parameter negotiation and update is just as readily extended to LLN protocols.
The flexibly to employ different key distribution methods according to available network infrastructure and particular operating scenarios together with the compact efficiency of its binary specification makes MIKEY well suited for general LLN use. The wide range of key management support extending from light-weight, low latency half round-trip pre-shared key distribution methods to multi-exchange Diffie-Hellman key agreements protected with digital signatures or pre-shared keys offers great flexibility to meet the needs of diverse LLN application environments.
The option to embed the MIKEY key management messages within an existing network signaling protocol or to be directly transported or UDP or TCP (using port 2269) also increases the ability to apply the methods in more general LLN domains.
MIKEY has met its original stated design goals [RFC3830] of end-to-end security, simplicity, efficiency, tunneling (even beyond integration with Session Description Protocol (SDP) [RFC4566] or RTCP [RFC3605]), and independence of underlying transport. In so doing it offers an excellent base for a generic key management protocol for LLN application. Key management protocols are also difficult to design and validate (see [RFC4107] guidelines) providing a further motivation for reliance on an established protocol like MIKEY that has had the benefit of wider operational deployment and evaluation.
As noted in [RFC5197], several key distribution methods have been described for MIKEY, including:
Further extensions to MIKEY comprising algorithm enhancements and new payload definitions have since been defined generally motivated by the specific problems associated with SIP signaling and associated multimedia use case scenarios (see [RFC5197]for an earlier assessment). This specification proposes a new extension that is focused on a new domain of application.
This document specifies a set of additional message information elements to the base MIKEY protocol that provide both algorithm and message payload extensions. These additions allow the adapted protocol to be used directly for key transport and security policy specification between communications generic network entities. Furthermore, through integration within the base MIKEY specification it will allow current and future key methods and extensions to be utilized outside of the current multimedia environment.
The developed protocol adaption includes the specification of alternative default algorithms (in particular AES-based as widely available in emerging device hardware) and configurations that are particular to more constrained communications devices. MIKEY's general extensibility is also used to define new elements applicable to the LLN environment.
An important element of the protocol extension is the re-use of the MIKEY crypto-session structure to apply to individual device communications protocol layers or interfaces instead of applying to multimedia streams. By maintaining this base protocol structure and re-purposing associated message identifiers, the specification minimizes the protocol changes needed for network adaptation.
As with the original specification the intent is to allow MIKEY messages to be embedded into existing communications signaling protocols or to be independently transported between communicating entities over UDP or TCP transport connections.
Note: While MIKEY and its extensions provide a variety of choices in terms of modes of operation, implementations for a given LLN application domain will be able to simplify node behavior by operating in a single mode. To ensure necessary interoperability within the LLN environment, mandatory methods within the Adapted MIKEY protocol (AMIKEY), akin to those of MIKEY, shall be specified.
The following definitions have been taken from [RFC3830] with necessary augmentation for AMIKEY as indicated:
The following definitions have been added to the ones from [RFC3830] specifically related to supporting AMIKEY:
Section 2 provides a brief general system overview of key management as introduced in MIKEY specification. This section generalizes the context in which the Adapted MIKEY (AMIKEY) protocol extension is applied. It also provides a reference to the common key management operating base of MIKEY and AMIKEY.
Sections 3 to 4 go into further detail by identifying the specific section and subsection extensions and enhancements needed to support the MIKEY protocol adaptation. These Sections mirror those of MIKEY [RFC3830] and are used to show the necessary commonality and make reference to specific changes would be required for AMIKEY. Reference is made only to the applicable Sections and Subsections of [RFC3830] for which special changes are proposed.
Section 6 includes the specific protocol specification elements that are needed to extend MIKEY for the support of the generic LLN key management requirements.
The remaining document sections are place-holders for standard RFC draft sections.
This document is written as a delta document to [RFC3830]. For ease of cross-reference and to maintain consistency with the MIKEY specification document structure, Section heading and Table and Figure numbers are maintained consistent with the [RFC3830] usage.
The notation of Section number followed by [RFC3830] "x.x. [RFC3830]" is used is this document for Sections specifically meant to align with [RFC3830]. Section numbers followed by [RFC3830] with additional heading text indicates some new element or clarification introduced by this specification. Section numbers followed by [RFC3830] without further heading text implies no change to [RFC3830] and is used only to align and maintain the current document headings structure.
The new parameters introduced in this specification are made consistent with the MIKEY recommendations (see Section 4.2.9 [RFC3830]).
This section provides an overview of AMIKEY. Material from MIKEY [RFC3830] is also repeated to clearly establish the common context in which MIKEY can be applied to LLN environments with the simple extension to the Adapted MIKEY (AMIKEY) specification.
The objective of the AMIKEY extension is exactly the same as that of MIKEY - "to produce a data security association (SA) for a security protocol, including a Traffic-Encrypting Key (TEK), which is derived from a TEK Generation Key (TGK), and used as input for the security protocol." In the case of AMIKEY the objective is support generic security protocols and particularly those that may be associated with LLNs.
AMIKEY uses the specified MIKEY mechanisms and features to "support the possibility of establishing keys and parameters for more than one security protocol (or for several instances of the same security protocol) at the same time." In MIKEY the Crypto Session Bundle (CSB), which derives from the multimedia (multi-stream) context, is used to denote this collection of one or more Crypto Sessions that can have a common TGK and security parameters, but that obtain distinct TEKs from MIKEY.
In the AMIKEY extension, the concept of CSB is used to provide the option of simultaneously establishing multiple SAs on a given device. The individual Crypto Session (CS) SAs may be associated with different device layer or device interface security protocols. AMIKEY further uses the flexibility of the MIKEY specification to allow separate security policies to be defined in the SA established for each security protocol. The distribution mechanisms defined by MIKEY for re-keying and updating of established security associations is hence also directly applied. The ability to establish and maintain multiple SAs through a single key management association provides an important efficiency element in LLN domains.
As specified in [RFC3830], Section 2.3, the procedure of setting up a CSB and creating a TEK (and Data SA), is done in accordance with Figure 1:
+-----------------+
| CSB |
| Key transport | (see [RFC3830], Section 3)
| /exchange |
+-----------------+
| :
| TGK :
v :
+----------+ :
CS ID ->| TEK | : Security protocol parameters (policies)
|derivation| : (see [RFC3830], Section 4)
+----------+ :
TEK | :
v v
Data SA
|
v
+-------------------+
| Crypto Session |
|(Security Protocol)|
+-------------------+
Figure 1: Overview of MIKEY (and AMIKEY extension) key management procedure
For generic LLNs that are the focus of this document, the default algorithms applied in the generation of the TEK for each protocol is defined within this AMIKEY specification. An additional MIKEY message extension is also specified to define the security protocol parameters (policies) for generic LLNs.
Whereas MIKEY CS IDs are associated with multimedia streams and have no intrinsic designation, in this specification the CS IDs are assigned values (public or private/vendor-specific) that are used to identify security protocols associated with specific device protocol layers or device interfaces.
As considered for the device security model discussed in [I-D.ietf-roll-security-framework], Section 6.5, Figure 2 provides an overview of the key management context introduced by the AMIKEY extension defined in this specification. The multi-protocol key management capability (through the particular use of the MIKEY CS-IDs) allows for the efficient, simultaneous management and update of one or more protocol layer security parameters.
............................. .............................
: +----------+ : : +----------+ :
: |+--------+| : : |+--------+| :
: || AMIKEY || : AMIKEY : || AMIKEY || :
: || Key |<========================================>| Key || :
: || Mgmt. || Key Exchange (TGK) || Mgmt. || :
: || Entity || : : || Entity || :
: |+--------+| : : |+--------+| :
: | Security | Node i : : Node j | Security | :
: | Services | : : | Services | :
: | Entity | : : | Entity | :
: +----------+ : : +----------+ :
: | : : | :
: | +-----------+: :+-----------+ | :
: | (CSn)+--->| Protocol-n|: :| Protocol-n|<---+(CSn) | :
: | | +-----------+: :+-----------+ | | :
: | | +-----------+ : : +-----------+ | | :
: | (CS7)|->|Application| : : |Application|<-|(CS7) | :
: | | +-----------+ : : +-----------+ | | :
: | | +-----------+ : : +-----------+ | | :
: | (CS4)|->| Transport | : : | Transport |<-|(CS4) | :
: | | +-----------+ : : +-----------+ | | :
: +------| : : |------+ :
: | +-----------+ : : +-----------+ | :
: (CS3)|->| Network | : : | Network |<-|(CS3) :
: | +-----------+ : : +-----------+ | :
: | +-----------+ : : +-----------+ | :
: (CS2)|->| L2 | : : | L2 |<-|(CS2) :
: | +-----------+ : : +-----------+ | :
: | +-----------+ : : +-----------+ | :
: (CS1)+->| L1 | : : | L1 |<-+(CS1) :
: +-----------+ : : +-----------+ :
:...........................: :...........................:
Figure 2: Overview of AMIKEY multi-protocol key management context
As in the base MIKEY specification, the security protocol can either use the TEK directly, or, if supported, derive further session keys from the TEK. It is however up to the targeted security protocol and the associated security policy to define how the TEK is used.
MIKEY can be used to update TEKs and the Crypto Sessions in a current Crypto Session Bundle (see [RFC3830], Section 4.5). This is done by executing the transport/exchange phase once again to obtain a new TGK (and consequently derive new TEKs) or to update some other specific CS parameters.
The following subsections detail the proposed additions to the MIKEY specification [RFC3830] to support the AMIKEY extension.
The MIKEY defined key management modes consist of a single (or half) round trip signaling exchange between network peers. In conjunction with the peer-to-peer modes, AMIKEY incorporates support for client-server infrastructures while retaining the maximum single round trip key signaling exchange.
For AMIKEY, a client device may request a key assignment or update by sending a request message (Q_MESSAGE) to a key management server (KMS). The request message is protected by a pre-shared secret or a public key. The server initiates the key assignment and completes the exchange by sending a key Initiator message (I_MESSAGE) correspondingly protected by a pre-shared secret or a public key. Mutual authentication and key assignment confirmation is achieved at the requesting device upon receipt of the Initiator message. This signaling mode is shown in Figure 3.
Key Assignment Key
Initiator ReQuestor
+-----+ +------+
| I | | Q |
+-----+ +------+
Q_MESSAGE
<-----------------------------------------
I_MESSAGE
----------------------------------------->
Figure 3: (Client) requested key assignment
A KMS may also autonomously initiate a key assignment or update by sending a key Initiator message (I_MESSAGE) to a client, protected by a pre-shared secret or a public key. As dictated by the KMS, a key response message (R_MESSAGE) is returned by the key client (Responder) where mutual authentication and assignment confirmation is required. This key management signaling mode is shown in Figure 4.
Key Assignment Key
Initiator Responder
+-----+ +------+
| I | | R |
+-----+ +------+
I_MESSAGE
----------------------------------------->
[Optional] R_MESSAGE
<-----------------------------------------
Figure 4: (Server) initiated key assignment
As shown, the AMIKEY message flows will typically consist of a request followed by a response in the form on a Requestor-Initiator or Initiator-Responder exchange. It is the responsibility of the Requestor or the Initiator, respectively to ensure reliability of the key assignment signaling exchange. If a response is not received within a timeout interval the Requestor/Initiator needs to retransmit the request or abandon the connection. The timeout interval and the number of retries before a connection is abandoned shall be implementation defined according to the particular network application.
The AMIKEY signaling flow and message information content for the Pre-shared key (PSK) method is as shown in Figure 5 below, in which "[]" indicates optional messages or elements:
Requestor
Q_MESSAGE =
[<---] HDR, T, [IDq], V
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
Figure 5: Signaling exchange and message content for the PSK method
The format of the AMIKEY pre-shared key Requestor message (Q_MESSAGE) will follow that of the standard MIKEY Initiator and Responder messages (I_MESSAGE and R_MESSAGE, respectively). Beyond the header (HDR) and Timestamp (T) information elements, the message will include the Identity of the Requestor IDq and the message verification, V. The entire message SHALL be authenticated by V and sent in cleartext. The Requestor IDq MAY be left out only when it can be expected that the peer already knows the other party's ID (otherwise it cannot look up the pre-shared key). For example, this could be the case if the ID can be extracted from the signaling protocol in which the key management message is embedded.
The Initiator's message securely transports one or more TGKs (carried in the KEMAC) and a set of security parameters (SPs) to the Responder using the pre-shared key to protect the message and its sub-payloads.
The Responder message MAY be sent in response to a key assignment initiated by the Initiator I_MESSAGE. Since the verification message V from the Responder is optional, the Initiator indicates in the HDR whether it requires a verification message or not from the Responder. The verification message, V, is a MAC computed over the Responder's entire message, the timestamp (the same as the one that was included in the Initiator's message), and the two parties identities, using the authentication key. See [RFC3830] Section 5.2 for the exact definition of the Verification MAC calculation and [RFC3830] Section 6.9 for payload definition.
The Initiator message SHALL indicate that the Responder message is not required when a Requestor message has been used to initiate the key exchange. In that case mutual authentication will be provided through the Initiator message sent in response to the triggering Requestor message.
Where the key assignment is triggered by the AMIKEY Requestor message, the timestamp, T, of the Initiator message shall be the same as the one that was included in the Requestor's message. The CS ID map info of the Requestor message HDR will specify the requested protocol key(s) to be assigned (see Section 6.1).
For AMIKEY the pre-shared key method is mandatory to implement.
For the public-key encryption method, the signaling exchange and message content is similar to that of the PSK case as shown in Figure 6 below:
Requestor
Q_MESSAGE =
[<---] HDR, T, [IDq|CERTq], SIGNq
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi|CERTi],
[IDr], (SP), KEMAC,
[CHASH], PKE, SIGNi --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
Figure 6: Signaling exchange and message content for the PK method
The AMIKEY public key Requestor message follows the standard MIKEY format. Beyond the header (HDR) and Timestamp (T) information elements, the message may include the Identity or Certificate of the Requestor [IDq|CERTq] and a message Signature, SIGNq. The SIGNq is a signature covering the entire Requestor's AMIKEY message, Q_MESSAGE, using the Requestor's (private) signature key (see Section 5.2 [RFC3830] for the exact definition of the Signature calculation). The message SHALL be sent in cleartext, authenticated by the signature.
The Requestor IDq and certificate SHOULD be included, but the CERTq MAY be left out when it can be expected that the peer can obtain the certificate in some other manner from the Requestor ID. The ID may be left out when it can be expected that the peer already knows the other party's ID.
The Initiator's message securely transports one or more TGKs and a set of security parameters to the Responder. This is done using an envelope approach where the TGKs are encrypted (and integrity protected) with keys derived from a randomly/pseudo-randomly chosen "envelope key". The envelope key is sent to the Responder encrypted with the public key of the Responder.
Where the key assignment is triggered by the Requestor message, the timestamp, T, of the Initiator message shall be the same as the one that was included in the Requestor's message. As for the PSK method, the CS ID map info of the Requestor message HDR will specify the requested protocol key(s) to be assigned (see Section 6.1).
The Responder message MAY be sent in response to a key assignment initiated by the Initiator I_MESSAGE. The indication of the requirement to send the Responder verification message V as well as its calculation shall be the same as in the pre-shared key mode. The timestamp in a Responder message will be the same as the one that was included in the Initiator message.
The Initiator message SHALL indicate that the Responder message is not required when a Requestor message has been used to initiate the key exchange.
For AMIKEY the public key method is mandatory to implement.
For the Diffie-Hellman key exchange method, the peer-to-peer association in which both devices contribute equally to the key generation will be the same as given in [RFC3830] even with a key client-server network infrastructure.
For AMIKEY this method is optional to implement.
The following sub-sections provide examples of how AMIKEY can be used to support key management for the RPL routing protocol [RFC6550].
The process of a node joining a secured RPL instance is described in Section 10.2 of the RPL specification [RFC6550]. Where the DODAG operates in "authenticated mode", as indicated by the "A" bit being set in the DODAG Configuration option of the DIO messages, a joining node is required to access a key server to obtain the current key for securing RPL messages. AMIKEY is intended to support the requirements of the key management protocol that allows RPL nodes to be able to obtain (and receive) the dynamic DODAG security key (see Section 3.2.3 of [RFC6550]). For AMIKEY, the security of the key management protocol exchanges between the nodes and the key server may be based on a pre-shared key (PSK), public key (PKE) or Diffie-Hellman (DH) method as described in Section 3.
Figure 7 illustrates how AMIKEY may be employed to obtain the DODAG security key. The figure depicts how the joining node uses AMIKEY to request the DODAG key when a pre-shared key is used for securing the key management exchange with the key server.
Joining Node RPL Router Key Server
| | |
| 1. Secure DIS (KI=0) | |
|----------------------------->| |
| | |
| 2. Secure DIO (KI=0,"A"bit set) |
|<-----------------------------| |
| | |
| |
| 3. AMIKEY: Q_MESSAGE (HDR, T, IDq, V) |
|========================================================>|
| 4. AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC) |
|<========================================================|
| |
|
| 5. Secure DIS (KI=n) |
|----------------------------->|
| |
| 6. Secure DIO (KI=n) |
|<-----------------------------|
| |
Figure 7: Key Assignment with AMIKEY in the RPL Join Process
The particular information elements of the AMIKEY Q_MESSAGE include:
The particular information elements of the AMIKEY I_MESSAGE include:
Note: In conjunction with RPL, AMIKEY can also be applied to support proactive key assignment/update by the key server using an I_MESSAGE and R_MESSAGE exchange as discussed in Section 3.
The RPL security key for a DODAG operating in authenticated mode may be updated one or more times during the lifetime of the DODAG. Such key updates are initiated by the key server and pushed to individual RPL nodes using the AMIKEY protocol.
Figure 8 illustrates how AMIKEY is employed for the key update. The scenario assumes a pre-shared key (PSK) for securing the key management exchange between the RPL nodes and the key server. Public key encryption (PKE) or Diffie-Hellman (DH) methods may also be used as described in Section 3.
RPL Node i RPL Node j Key Server
| | |
| 1. Secure DIO | |
| (KI=n,"A"bit set) | |
|------------------------->| |
| | |
| 2. Secure DAO (KI=n) | |
|<-------------------------| |
| | |
| 3. Secure DAO ACK (KI=n) | |
|------------------------->| |
~ ~ |
~ ~ |
| |
| 4a. AMIKEY: I_MESSAGE (HDR,T,RAND,IDi,{SP},KEMAC) |
|<===========================================================|
| |
| 5a. AMIKEY: R_MESSAGE (HDR,T,IDr V) |
|===========================================================>|
| |
| | 4b. AMIKEY: I_MESSAGE |
| | (HDR,T,RAND,IDi,{SP},KEMAC) |
| |<================================|
| | 5b. AMIKEY: R_MESSAGE |
| | (HDR,T,IDr V) |
| |================================>|
~ ~
~ ~
| |
| 6. Secure DIO |
| (KI=n+1,"A"bit set) |
|------------------------->|
| |
| 7. Secure DAO (KI=n+1) |
|<-------------------------|
| |
| 8. Secure DAO ACK |
| (KI=n+1) |
|------------------------->|
| |
Figure 8: Key Update during RPL Operation Using AMIKEY
The particular information elements of the AMIKEY I_MESSAGE include:
The particular information elements of the AMIKEY R_MESSAGE include:
Note: In an ad hoc network there is the potential for nodes that have received a DODAG key update to initiate routing exchanges with nodes that have not yet received the update. This situation will be detected by the mis-match between the node's maintained DODAG key index and that of its corresponding peer. Where a received RPL message is secured by a key different from that maintained by the recipient node it will not be possible to verify the authenticity or validity of the message. To avoid potential denial of service attacks from forged or purported Secure RPL messages, a RPL node should silently discard such messages if it has not received an updated key. One consequence is the potential for broken RPL associations when the key update is not sufficiently synchronized across the DODAG. A key activation time can be used to limit the potential for such routing disruptions during the key update. The Key Activation time in the form of a UTC clock time or future count can be specified through the AMIKEY Key Validity information element (see [RFC3830] Key data sub-payload, Section 6.13).
A node recovering from reset and receiving Secure DIO messages with a Key Index different from the one currently maintained can revert its status to a non-routing (leaf) node. The node can then initiate an AMIKEY key request to the key server to obtain the current DODAG key.
For AMIKEY all the key derivation functionality defined in MIKEY shall be based on a new default Pseudo-Random Function (PRF) given by the AES-based, AES-CMAC algorithm as specified in [RFC4493].
For AMIKEY cs_id is defined so that session represents a protocol layer, logical device interface, or communications association. The cs-id values shall be as defined in this specification (see Section 6.1.2) and may be public or private/vendor-specific.
For AMIKEY the default pseudo random function shall be AES-CMAC [RFC4493]. Note: AES-CMAC aligns with HMAC-SHA1 and HMAC-MD5 as PRFs.
For AMIKEY the cs-id values shall be as defined in this specification (see Section 6.1.2).
Change from default PRF to the default AMIKEY PRF given in Section 4.1.2 of this specification.
Note: For AMIKEY, the Authentication key constant SHALL be used for generating the single TEK in the case of authenticated encryption algorithms (such as AES-CCM).
For AMIKEY the default hash function shall be AES-CMAC [RFC4493].
For AMIKEY it shall be MANDATORY to implement the new default AES-CMAC PRF specified in [RFC4493] (See Section 4.1.2 of this specification).
As in MIKEY the default and mandatory-to-implement key transport encryption shall be AES in Counter mode using a 128-bit key (derived as defined in Section 4.1.4 above). The applied Counter shall be the IV defined in [RFC3830], Section 4.2.3.
For AMIKEY AES-CCM-64 shall be the defined default for key message authentication. The Counter used shall be the IV defined in [RFC3830], Section 4.2.3.
For AMIKEY the retrieval of a Data SA will depend on the security protocol. The support for different security protocols shall be explicitly identified through the use of public CS ID values (see Section 6.1.2 of this specification).
For AMIKEY where the key exchange is triggered by a Requestor, the messages from the Requestor MUST use a unique timestamp. The Initiator does not create a new timestamp but uses the timestamp used by the Requestor.
When the key exchange is not triggered by a Requestor, the messages from the Initiator MUST use a unique timestamp. The Responder does not create a new timestamp, but uses the timestamp used by the Initiator.
The generic LLN security protocol parameters may be transported between peers as part of a key establishment or re-keying exchange. Based on IANA registration, MIKEY currently only defines two payloads for transporting the security policy information (see Section 6.10 of [RFC3830] and [RFC4442]). This section describes the extension of MIKEY to allow the transport of Generic LLN security policy information and associated key(s) as well as applicable PRF used for key derivation.
This section describes, in detail, the payload for support of the Generic LLN security protocol(s) specified by the Adapted MIKEY protocol. As in RFC3830, for all encoding, network byte order is always used, and the sign ~ indicates a variable length field.
The Common Header payload MUST always be present as the first payload in each message. The Common Header includes a general description of the exchange message.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! version ! data type ! next payload !V! PRF func ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! CSB ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! #CS ! CS ID map type! CS ID map info ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Common Header [RFC3830]
| Data Type | Value | Comment |
|---|---|---|
| PSK Request | i | Requestor's pre-shared key message (AMIKEY) |
| PK Request | j | Requestor's public key message (AMIKEY) |
For AMIKEY a new next payload value is assigned to carry the Key Index parameter (see also Section 6.16).
| Next Payload | Value | Section |
|---|---|---|
| Last payload | 0 | - |
| ... | ||
| Key Index | n | Section 6.16 as given by the AMIKEY specification (value to be assigned by IANA). |
| Key Source ID | m | Section 6.17 as given by the AMIKEY specification (value to be assigned by IANA) |
| PRF Function | Value | Comments |
|---|---|---|
| AES-CMAC | 2 | As specified in [RFC4493] and that shall be mandatory for AMIKEY |
(AMIKEY value to be assigned by IANA)
| CS ID Map Type | Value | Comments |
|---|---|---|
| Generic_LLN-ID | 3 | As specified in this document and as mandatory for AMIKEY |
(AMIKEY value to be assigned by IANA)
For the Generic_LLN map type, the CS ID map info consists of #CS (see Section 6.1) number of blocks or segments, where each segment maps policies (and a key) to a specific protocol layer, logical device interface or other communications association security protocol.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! CS ID ! #P ! Ps (OPTIONAL) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Generic_LLN-ID Map Type
Note: A combination of public and private CS IDs can be specified within a given CSB when combined key management is being applied.
The following values are currently specified in this document (for example, with values to be assigned by IANA):
| CS ID | Value | Comments |
|---|---|---|
| Reserved | 0 | |
| Generic PHY Layer | 1 | |
| Generic Link Layer | 2 | |
| Generic Network Layer | 3 | |
| Generic Transport Layer | 4 | |
| Generic Application Layer | 7 | |
| RPL Protocol | 20 | |
| ... | ||
| Reserved values | 128-255 | Reserved for private use |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Policy_no_i ! Policy_no_n ! ... ! Policy_no_#P ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Policies
This section shall apply entirely as specified for MIKEY in [RFC3830] with the addition of the specific message authentication code algorithms given below for AMIKEY.
| MAC alg | Value | Comments | Length (bits) |
|---|---|---|---|
| NULL | 0 | restricted usage [RFC3830], Section 4.2.4 | 0 |
| HMAC-SHA-1-160 | 1 | Mandatory, [RFC3830], Section 4.2.4 | 160 |
| HMAC-SHA-256-256 | 2 | Mandatory, [RFC3830], Section 4.2.4 | 256 |
| AES-CBC-MAC-32 | 3 | Mandatory for AMIKEY, see Section 4.2.4 | 32 |
| AES-CBC-MAC-64 | 4 | Mandatory for AMIKEY, see Section 4.2.4 | 64 |
| AES-CBC-MAC-128 | 5 | Mandatory for AMIKEY, see Section 4.2.4 | 128 |
(Values for AMIKEY to be assigned by IANA)
For AMIKEY the use of AES-CBC-MAC-n may be applied in conjunction with the AES-CM encryption as given by the Encr alg field. This authenticated encryption shall be applied using an AES-CCM-n implementation.
For AMIKEY the range of ID types shall be extended to allow for an expanded array of communications protocol entities that may be key management participants. The IDs are carried within the key management message ID payload field with the TLV format as specified in [RFC3830], Section 6.7.
| ID Type | Value | Comments |
|---|---|---|
| IPv6 Address | 4 | As specified for AMIKEY |
| Device MAC Address | 5 | As specified for AMIKEY |
| Other (TBD) | n | As specified for AMIKEY |
The IPv6 Address ID type is used to allow an IPv6 Address to be referenced as the unique entity identifier of the key management correspondents. To directly reference the IPv6 Address of the exchanged packets, the ID len value will be set to zero and no ID data included in the value field (see [RFC3830]).
The Device MAC Address is used to allow an IEEE 48-bit MAC address to be referenced as the unique entity identifier for correspondents in a key management exchange. To directly reference the MAC Address of the exchanged packets, where the IPv6 address has been derived from the device MAC address in conformance with [RFC4291] the ID len value will be set to zero and no ID data included in the value field (see [RFC3830]).
Note: The ID payload may be used by a supported security protocol as implicit Key Source Identifier (see Section 6.17) for referencing key origination.
The Security Policy payload defines a set of policies that apply to a specific security protocol.
For AMIKEY the definition is based on the same security policy payload definition in [RFC3830], Section 6.10, with a new security protocol (Generic-LLN) as defined below.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next payload ! Policy no ! Prot type ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ length (cont) ! Policy param ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prot Type | Value | Comments |
|---|---|---|
| Generic_LLN | 3 | As specified for AMIKEY |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Type ! Length ! Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Policy Parameter
This policy specifies the parameters for the Generic_LLN (G_LLN) protocol for which key management is being provided. The types/values that can be negotiated are defined by the following table for the known, assigned CS ID values. For Vendor-specific, private CS ID values the applicable policy specification for a given crypto session will be left to the communicating parties.
| Type | Meaning | Possible Values |
|---|---|---|
| 0 | Encryption algorithm | See below |
| 1 | Encryption key length | Depends on cipher used |
| 2 | Authentication algorithm | See below |
| 3 | Authentication key length | Depends on MAC used |
| 4 | Generic LLN PRF | See below |
| 5 | Encryption off/on | 0 if off, 1 if on |
For the Encryption algorithm, a one byte length is sufficient. For AMIKEY the currently defined possible Values are:
| G_LLN encr alg | Value |
|---|---|
| NULL | 0 |
| AES-CM-128 | 1 |
For the Authentication algorithm, a one byte length is sufficient. For AMIKEY the currently defined possible Values are:
| G_LLN auth alg | Value | Comments |
|---|---|---|
| NULL | 0 | Not recommended for operational use |
| AES-CBC-MAC-32 | 1 | |
| AES-CBC-MAC-64 | 2 | |
| AES-CBC-MAC-128 | 3 | |
| RSA-SHA-256 Sig | 4 |
Note: Since authentication is mandatory for operational protocol security, where Encryption is set "on" by the Generic_LLN policy, authenticated encryption, AES-CCM-n, with the MAC size given by the selected authentication algorithm, or AES-CM with authentication given by the identified Signature algorithm, shall be applied.
For the Generic_LLN pseudo-random function, a one byte length is also sufficient. For AMIKEY the currently defined possible Values are:
| Generic_LLN PRF | Value |
|---|---|
| AES-CMAC | 0 |
For AMIKEY, the key validity (KV) period for a TGK/TEK shall be specified using the KV Interval type indicating a potential key start and expiration time (see Section 6.14).
For AMIKEY the Key Validity Data element shall be used to specify the activation time and validity period of an assigned TGK.
For AMIKEY, the key validity (KV) period for a TGK/TEK shall be specified using the KV Interval type (see [RFC3830] Section 6.13).
The corresponding Valid From (VF) and Valid To (VT) information elements that define the applicable key lifetime may be specified using the Timestamp Counter type to specify time in seconds from the time given by included key message timestamp (T). A VF Length of zero (indicating Counter value of 0) specifies an immediate key activation time. A VT Counter value of all 1s indicates infinite key validity or no expiration time.
For AMIKEY the Key Index (KI) payload is used to specify the value of the key index associated with a given TGK.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! KI len ! KI value (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Key Index
For AMIKEY, where an explicit reference is required, the Key Source Identifier payload is used to provide a logical reference to the entity associated with the origination of a given TGK. The specification of the Key Source Identifier (KSI) shall be given by the supported security protocol (for example, the secured RPL routing protocol [RFC6550] specifies the use of an 8-byte KSI).
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! KSI len ! KSI value (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Key Source Identifier
As in [RFC3830], AMIKEY may be integrated within session establishment or other system signaling protocols or may be directly transported over UDP or TCP. Where AMIKEY messages are integrated into other LLN-related signaling protocols its transport shall be defined as part of those protocols.
A primary motivation for this RFC is the security that comes from a re-use of the key management methods and framework developed for MIKEY. The extensive deployment and on-going development provides the benefit of much wider vetting and validation essential to assuring greater security.
Work had been previously initiated in developing support for an ECC-based asymmetric key management method ([I-D.ietf-msec-mikey-ecc], expired). In the context of LLNs application and subject to IPR considerations, related AMIKEY requirements may be developed.
This document defines several new name spaces associated with the AMIKEY payloads. This section summarizes the name spaces for which IANA is requested to manage the allocation of values. IANA is requested to record the pre-defined values defined in the given sections for each name space. IANA is also requested to manage the definition of additional values in the future. Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus and values in the range 241-255 are reserved for Private Use, according to [RFC5226].
The name spaces for the new fields identified in this document are requested to be managed by IANA (in bracket is the reference to the table with the initially registered values):
The authors would like to acknowledge the review and comments from Rene Struik and Stephen Farrell.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC3830] | Arkko, J., Carrara, E., Lindholm, F., Naslund, M. and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [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. |