Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for Generic LLN Environments

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 . 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 () 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 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, , , , , , and ). MIKEY and its related RFC extensions have however primarily focused on the support of the SRTP and related Session Initiation Protocol (SIP) call scenarios . 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 of end-to-end security, simplicity, efficiency, tunneling (even beyond integration with Session Description Protocol (SDP) or RTCP ), and independence of underlying transport. In so doing it offers an excellent base for a generic key management protocol for Low-power Lossy Network (LLN) application. Key management protocols are also difficult to design and validate (see 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 , several key distribution methods have been described for MIKEY, including: Symmetric key distribution as defined in (MIKEY-PSK) Asymmetric key distribution as defined in (MIKEY-RSA) Diffie-Hellman key agreement protected by digital signatures as defined in (MIKEY-DHSIGN) Diffie-Hellman key agreement protected by symmetric pre-shared keys as defined in (MIKEY-DHHMAC) Asymmetric key distribution (based on asymmetric encryption) with in-band certificate provision as defined in (MIKEY-RSA-R) 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 for an earlier assessment). This specification proposes a new extension that is focused on a new domain of application.

This document specifies is 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) and configurations that are particular to more constrained communications devices and using MIKEY's general extensibility 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 with necessary augmentation for AMIKEY as indicated: The security protocol used to protect the actual data traffic. Examples of security protocols are IPsec and SRTP. For generic LLNs, security protocols may include secure versions of protocols such as RPL . Data Security Association information for the security protocol, including a TEK and a set of parameters/policies. Crypto Session, uni- or bidirectional data stream(s) protected by a single instance of a security protocol. For AMIKEY the concept of a crypto-session is expanded to allow definition of a particular protocol layer, logical device interface, or other communications association for which key management support is provided. Crypto Session Bundle, collection of one or more Crypto Sessions, which can have common TGKs (see below) and security parameters. Crypto Session ID, unique identifier for the CS within a CSB. For AMIKEY the CS ID is used to identify a specific protocol layer, logical device interface or other communications association for which AMIKEY is being used to support key management (establishment of re-keying update). Crypto Session Bundle ID, unique identifier for the CSB. For AMIKEY the CSB ID in conjunction with the Timestamp filed is used as a unique key management exchange message reference identifier. This identifier will allow for the acknowledged key management message exchanges where applicable. The ID plus timestamp will also support the filtering of repeated or redundant AMIKEY messages when key management occurs over an unreliable transport network. TEK Generation Key, a bit-string agreed upon by two or more parties, associated with CSB. From the TGK, Traffic-Encrypting Keys can then be generated without needing further communication. Traffic-Encrypting Key, the key used by the security protocol to protect the CS (this key may be used directly by the security protocol or may be used to derive further keys depending on the security protocol). The TEKs are derived from the CSB's TGK. The following definitions have been added to the ones from specifically related to supporting AMIKEY: The Key Index (KI) is used as identifier to allow for reference to the key(s) that are associated with a given CS. Where TEKs may be updated over time a TGK can be associated with a KI that is transported as a payload within the AMIKEY message from the Initiator. Any TEK generated from the AMIKEY TGK shall be assigned the key index value associated with the TGK. Within general LLN protocol communications related to a given CS (device layer protocol or interface), to ensure security association synchronization reference can be made to the key index that is being applied for the given protocol security. Following successfully TGK key establishment communicating devices can verify security contexts through reference to maintained KI (see ). The Key Source Identifier (KSI) is used as a logical identifier to allow for refernece to the entity associated with the origination of a given TGK. Where TEKs are dynamically generated or updated, each TGK can be associated with a specific key source. The KSI, when used, is transported as a payload within the AMIKEY message from the entity responsible for the TGK origination (see ).

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 to 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 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 for which special changes are proposed. 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 . 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 usage. The notation of Section number followed by "x.x. " is used is this document for Sections specifically meant to align with . Section numbers followed by with additional heading text indicates some new element or clarification introduced by this specification. Section numbers followed by without further heading text implies no change to 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 ).

This section provides an overview of AMIKEY. Material from MIKEY 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 , Section 2.3, the procedure of setting up a CSB and creating a TEK (and Data SA), is done in accordance with : A set of security parameters and TGK(s) are agreed upon for the Crypto Session Bundle. This is done by one of many alternative key transport/exchange mechanisms (see , Section 3, as well as subsequent extension RFCs). The TGK(s) is used to derive (in a cryptographically secure way) a TEK for each Crypto Session or associated security protocol. The TEK, together with the security protocol parameters, represent the Data SA, which is used as the input to the security protocol(s).

| TEK | : Security protocol parameters (policies) |derivation| : (see [RFC3830], Section 4) +----------+ : TEK | : v v Data SA | v +-------------------+ | Crypto Session | |(Security Protocol)| +-------------------+ ]]> 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 , Section 6.5, 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.

| Key || : : || Mgmt. || Key Exchange (TGK) || Mgmt. || : : || Entity || : : || Entity || : : |+--------+| : : |+--------+| : : | Security | Node i : : Node j | Security | : : | Services | : : | Services | : : | Entity | : : | Entity | : : +----------+ : : +----------+ : : | : : | : : | +-----------+: :+-----------+ | : : | (CSi)+--->| Protocol-i|: :| Protocol-i|<---+(CSi) | : : | | +-----------+: :+-----------+ | | : : | | +-----------+ : : +-----------+ | | : : | (CS7)|->|Application| : : |Application|<-|(CS7) | : : | | +-----------+ : : +-----------+ | | : : | | +-----------+ : : +-----------+ | | : : | (CS4)|->| Transport | : : | Transport |<-|(CS4) | : : | | +-----------+ : : +-----------+ | | : : +------| : : |------+ : : | +-----------+ : : +-----------+ | : : (CS3)|->| Network | : : | Network |<-|(CS3) : : | +-----------+ : : +-----------+ | : : | +-----------+ : : +-----------+ | : : (CS2)|->| L2 | : : | L2 |<-|(CS2) : : | +-----------+ : : +-----------+ | : : | +-----------+ : : +-----------+ | : : (CS1)+->| L1 | : : | L1 |<-+(CS1) : : +-----------+ : : +-----------+ : :...........................: :...........................: ]]> 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 , 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 Section and Subsections detail the proposed additions to the MIKEY specification to support the AMIKEY extension. The Section heading outline of the MIKEY specification is used to indicate the delta changes made by the AMIKEY extension.

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-XCBC-PRF-128 algorithm as specified in .

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 ) and may be public or private/vendor-specific.

For AMIKEY the default pseudo random function shall be AES-XCBC-PRF-128 . Note: AES-XCBC-PRF-128 aligns with HMAC-SHA1 and HMAC-MD5 as PRFs.

For AMIKEY the cs-id values shall be as defined in this specification (see ).

Change from default PRF to the default AMIKEY PRF given in 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-XCBC-PRF-128 .

For AMIKEY it shall be MANDATORY to implement the new default AES-XCBC-PRF-128 PRF specified in (See 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 above). The applied Counter shall be the IV defined in , 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 , 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 of this specification).

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 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.

version (8 bits): the version number of MIKEY. version = 0x01 refers to MIKEY as defined and maintained in . version = 0x03 (to be assigned by IANA) shall be used to refer to AMIKEY as defined and maintained in this document. data type (8 bits): describes the type of message (e.g., public-key transport message, verification message, error message). See latest IANA registered values. No additional values are specified for AMIKEY (TBD). next payload (8 bits): identifies the payload that is added after this payload. See latest IANA registered values. For AMIKEY a new next payload value is assigned to carry the Key Index parameter (see also ). Next Payload Value Section Last payload 0 - ... Key Index n as given by the AMIKEY specification (value to be assigned by IANA). Key act time m as given by the AMIKEY specification (value to be assigned by IANA) V (1 bit): flag to indicate whether a verification message is expected or not (this only has meaning when it is set by the Initiator). PRF func (7 bits): indicates the PRF function that has been/will be used for key derivation; for AMIKEY a new value, 2, has been specified to indicate the PRF that must be supported for LLNs. PRF Function Value Comments AES-XCBC-PRF-128 2 As specified in and that shall be mandatory for AMIKEY (AMIKEY value to be assigned by IANA) CSB ID (32 bits): identifies the CSB (generated as specified in ); for AMIKEY this field is used as a message reference identifier to allow for duplicate detection where message exchanges occur over an unreliable transport network. #CS (8 bits): indicates the number of Crypto Sessions that will be handled within the CBS; for AMIKEY this field indicates the number of protocol layers, logical device interfaces, or other communications associations that are being configured or managed within the current key management message exchange. CS ID map type (8 bits): specifies the method of uniquely mapping. Crypto Sessions to the security protocol sessions; for AMIKEY a new value, 3, has been specified to indicate the Generic-LLN map type that must be supported for LLNs. 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) CS ID map info (variable length): identifies the crypto session(s) for which the SA should be created. For AMIKEY the GENERIC_LLN map type (defined in below) is used to specify the security association for the individual protocol layers, logical device interfaces, or other communications associations for which key management is being provided.

For the Generic_LLN map type, the CS ID map info consists of #CS (see ) 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.

CS ID (8 bits): specifies the CS ID used to identify a given security protocol; for AMIKEY, when used in conjunction with the Generic-LLN map type, values 0-127 shall be reserved for assignment (by IANA) to specific protocol layer, logical device interface, or other communications association security protocols while values 128-255 shall be Reserved for Private Use. 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 #P (8 bits): indicates the number of security policies provided for the crypto session (given by the CS ID) for which key management is being provided. In response messages, #P SHALL always be exactly 1. So if #P = 0 in an initial message, a security profile MUST be provided in the response message. If #P > 0, one of the suggested policies SHOULD be chosen in the response message. If needed, the suggested policies MAY be changed. Ps (variable length): lists the policies for the crypto session for which key management is being provided. It SHALL contain exactly #P policies, each having the specified Prot type (see .

Policy_no_i (8 bits): a policy_no that corresponds to the policy_no of a SP payload. In response messages, the policy_no may refer to a SP payload in the initial message. The policy numbers should be listed in increasing order.

This section shall apply entirely as specified for MIKEY in with the addition of the specific message authentication code algorithms given below for AMIKEY. MAC alg (8 bits): specifies the authentication algorithm used. MAC alg Value Comments Length (bits) NULL 0 restricted usage , Section 4.2.4 0 HMAC-SHA-1-160 1 Mandatory, , Section 4.2.4 160 HMAC-SHA-256-256 2 Mandatory, , Section 4.2.4 256 AES-CBC-MAC-32 3 Mandatory for AMIKEY, see 32 AES-CBC-MAC-64 4 Mandatory for AMIKEY, see 64 AES-CBC-MAC-128 5 Mandatory for AMIKEY, see 128 (Values for AMIKEY to be assigned by IANA) MAC (variable length): the message authentication code of the entire message. 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 , 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. The Device MAC Address is used to allow a MAC address to be referenced as the unique entity identifier for correspondents in a key management exchange.

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 , Section 6.10, with a new security protocol (Generic-LLN) as defined below.

Next payload (8 bits): Identifies the payload that is added after this payload. See Section 6.1 of for more details. Policy no (8 bits): Each security policy payload must be given a distinct number for the current MIKEY session by the local peer. This number is used to map a cryptographic session to a specific policy (see also Section 6.1.1 of ). Prot type (8 bits): This value defines the security protocol; For AMIKEY an additional value shall be assigned as given below. Prot Type Value Comments Generic_LLN 3 As specified for AMIKEY Policy param length (16 bits): This field defines the total length of the policy parameters for the selected security protocol. Policy param (variable length): This field defines the policy for the specific security protocol. The Policy param part is built up by a set of Type/Length/Value (TLV) payloads. For each security protocol, a set of possible type/value pairs can be negotiated as defined.

Type (8 bits): Specifies the type of the parameter. Length (8 bits): Specifies the length of the Value field (in bytes). Value (variable length): Specifies the value of the 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-XCBC-PRF-128 0

For AMIKEY the Key Index (KI) payload is used to specify the value of the key index associated with a given TGK.

Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. KI len (8 bits): indicates the length of the key source identifier field. KI value (variable length): indicates the value of the key index to be assigned to any CS TEK generated from the transported TGK.

For AMIKEY 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 specifies the use of an 8-byte KSI).

Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. KSI len (8 bits): indicates the length of the key source identifier field. KSI value (variable length): specifies the logical identifier assigned to the Source or Originator of a given TGK.

For AMIKEY the Key Activation time payload is used to specify the time at which a new key derived from a communicated TGK shall become active for the associated device protocol or interface. The Key Activation time is used only when needed to specify a delay or future activation of an updated key. The format of this AMIKEY information element type shall be the same as that of the Timestamp payload (T) .

Next payload (8 bits): identifies the payload that is added after this payload. See Section 6.1 for values. TS type (8 bits): indicates the timestamp type use to convey the time at which a new derived TEK shall become active (See Section 6.6 ). TS value (variable length): the timestamp value of the specified TS type (See Section 6.6 ).

As in , 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 (, 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 . 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): Common Header payload (6.1.) Version Next payload (6.1.b) Key index Key source identifier Key activation time Prf func (6.1.c) AES-XCBC-PRF-128 CS ID map type (6.1.d) Generic_LLN-ID MAC alg (6.2.b) AES-CBC-MAC-32 AES-CBC-MAC-64 AES-CBC-MAC-128 ID payload (6.7.a) IPv6 Address Device MAC Address Proto type (6.10) Generic_LLN Generic_LLN policy (6.10.2) Policy parameters (6.10.2.a) G_LLN encr alg (6.10.2.b) G_LLN auth alg (6.10.2.c) G_LLN prf (6.10.2.d)

The authors would like to acknowledge the review and comments from Rene Struik.