One document matched: draft-alexander-roll-mikey-lln-key-mgmt-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3605.xml">
<!ENTITY RFC3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC3830 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml">
<!ENTITY RFC4107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4442 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4442.xml">
<!ENTITY RFC4493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4493.xml">
<!ENTITY RFC4563 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4563.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC4650 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4650.xml">
<!ENTITY RFC4738 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4738.xml">
<!ENTITY RFC5197 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5197.xml">
<!ENTITY RFC5410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5410.xml">
<!ENTITY RFC6043 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6043.xml">
<!ENTITY RFC6267 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6267.xml">
<!ENTITY I-D.ietf-roll-rpl SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-rpl-19.xml">
<!ENTITY I-D.ietf-roll-security-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-roll-security-framework-06.xml">
<!ENTITY I-D.ietf-msec-mikey-ecc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-msec-mikey-ecc-03.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-alexander-roll-mikey-lln-key-mgmt-02"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" hey will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters -->
<title abbrev="MIKEY Extension for LLN">Adapted Multimedia Internet KEYing
(AMIKEY): An extension of Multimedia Internet KEYing (MIKEY) Methods for
Generic LLN Environments</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Roger K. Alexander" initials="R.K." surname="Alexander">
<organization>Cooper Power Systems</organization>
<address>
<postal>
<street>20201 Century Blvd. Suite 250</street>
<!-- Reorder these if your country does things differently -->
<city>Germantown</city>
<region>Maryland</region>
<code>20874</code>
<country>USA</country>
</postal>
<email>roger.alexander@cooperindustries.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tzeta Tsao" initials="T." surname="Tsao">
<organization>Cooper Power Systems</organization>
<address>
<postal>
<street>20201 Century Blvd. Suite 250</street>
<!-- Reorder these if your country does things differently -->
<city>Germantown</city>
<region>Maryland</region>
<code>20874</code>
<country>USA</country>
</postal>
<email>tzeta.tsao@cooperindustries.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="July" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Networking Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>LLN, ROLL, security, key management</keyword>
<!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<abstract>
<t>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).</t>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 <xref
target="RFC4107"></xref>. 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 (<xref
target="I-D.ietf-roll-rpl"></xref>) that employs security as well as to
other secured communications layer protocols.</t>
<t>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 <xref target="RFC3830"></xref> 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, <xref target="RFC4442"></xref>, <xref
target="RFC4563"></xref>, <xref target="RFC4650"></xref>, <xref
target="RFC4738"></xref>, <xref target="RFC5410"></xref>, <xref
target="RFC6043"></xref> and <xref target="RFC6267"></xref>). MIKEY and
its related RFC extensions have however primarily focused on the support
of the SRTP and related Session Initiation Protocol (SIP) call scenarios
<xref target="RFC3711"></xref>.</t>
<t>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.</t>
<section anchor="motivation" title="Motivation">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>MIKEY has met its original stated design goals <xref
target="RFC3830"></xref> of end-to-end security, simplicity,
efficiency, tunneling (even beyond integration with Session
Description Protocol (SDP) <xref target="RFC4566"></xref> or RTCP
<xref target="RFC3605"></xref>), 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
<xref target="RFC4107"></xref> guidelines) providing a further
motivation for reliance on an established protocol like MIKEY that has
had the benefit of wider operational deployment and evaluation.</t>
</section>
<section title="MIKEY Key Management Methods Background">
<t>As noted in <xref target="RFC5197"></xref>, several key
distribution methods have been described for MIKEY, including: <list
style="symbols">
<t>Symmetric key distribution as defined in <xref
target="RFC3830"></xref> (MIKEY-PSK)</t>
<t>Asymmetric key distribution as defined in <xref
target="RFC3830"></xref> (MIKEY-RSA)</t>
<t>Diffie-Hellman key agreement protected by digital signatures as
defined in <xref target="RFC3830"></xref> (MIKEY-DHSIGN)</t>
<t>Diffie-Hellman key agreement protected by symmetric pre-shared
keys as defined in <xref target="RFC4650"></xref>
(MIKEY-DHHMAC)</t>
<t>Asymmetric key distribution (based on asymmetric encryption)
with in-band certificate provision as defined in <xref
target="RFC4738"></xref> (MIKEY-RSA-R)</t>
</list></t>
<t>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 <xref target="RFC5197"></xref>for
an earlier assessment). This specification proposes a new extension
that is focused on a new domain of application.</t>
</section>
<section title="Adapting MIKEY to General LLNs">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Terminology and Definitions">
<t>The following definitions have been taken from <xref
target="RFC3830"></xref> with necessary augmentation for AMIKEY as
indicated:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="(Data) Security Protocol"><vspace /> 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
<xref target="I-D.ietf-roll-rpl"></xref>.</t>
<t hangText="Data SA"><vspace /> Data Security Association
information for the security protocol, including a TEK and a set
of parameters/policies.</t>
<t hangText="CS">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.</t>
<t hangText="CSB">Crypto Session Bundle, collection of one or more
Crypto Sessions, which can have common TGKs (see below) and
security parameters.</t>
<t hangText="CS ID">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).</t>
<t hangText="CSB ID"><vspace /> 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.</t>
<t hangText="TGK">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.</t>
<t hangText="TEK">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.</t>
</list></t>
<t>The following definitions have been added to the ones from <xref
target="RFC3830"></xref> specifically related to supporting
AMIKEY:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Key Index"><vspace />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 <xref
target="key-index"></xref>).</t>
<t hangText="Key Source Identifier"><vspace />The Key Source
Identifier (KSI) is used as a logical identifier to allow for
reference 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 <xref
target="key-source"></xref>).</t>
</list></t>
</section>
<section title="Document Outline">
<t><xref target="overview"></xref> 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.</t>
<t>Sections <xref format="counter" target="extension-elem"></xref> to
<xref format="counter" target="mgmt-func"></xref> 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 <xref target="RFC3830"></xref>
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 <xref
target="RFC3830"></xref> for which special changes are proposed.</t>
<t><xref target="payload"></xref> includes the specific protocol
specification elements that are needed to extend MIKEY for the support
of the generic LLN key management requirements.</t>
<t>The remaining document sections are place-holders for standard RFC
draft sections.</t>
</section>
<section title="Section Headings Notation">
<t>This document is written as a delta document to <xref
target="RFC3830"></xref>. 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 <xref target="RFC3830"></xref> usage.</t>
<t>The notation of Section number followed by <xref
target="RFC3830"></xref> "x.x. <xref target="RFC3830"></xref>" is used
is this document for Sections specifically meant to align with <xref
target="RFC3830"></xref>. Section numbers followed by <xref
target="RFC3830"></xref> with additional heading text indicates some
new element or clarification introduced by this specification. Section
numbers followed by <xref target="RFC3830"></xref> without further
heading text implies no change to <xref target="RFC3830"></xref> and
is used only to align and maintain the current document headings
structure.</t>
<t>The new parameters introduced in this specification are made
consistent with the MIKEY recommendations (see Section 4.2.9 <xref
target="RFC3830"></xref>).</t>
</section>
</section>
<section anchor="overview" title="AMIKEY Overview">
<t>This section provides an overview of AMIKEY. Material from MIKEY
<xref target="RFC3830"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>As specified in <xref target="RFC3830"></xref>, Section 2.3, the
procedure of setting up a CSB and creating a TEK (and Data SA), is done
in accordance with <xref target="fig1"></xref>: <list style="numbers">
<t>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 <xref target="RFC3830"></xref>,
Section 3, as well as subsequent extension RFCs).</t>
<t>The TGK(s) is used to derive (in a cryptographically secure way)
a TEK for each Crypto Session or associated security protocol.</t>
<t>The TEK, together with the security protocol parameters,
represent the Data SA, which is used as the input to the security
protocol(s).</t>
</list></t>
<figure align="center" anchor="fig1"
title="Overview of MIKEY (and AMIKEY extension) key management procedure">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------------+
| 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)|
+-------------------+
]]></artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<t>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.</t>
<t>As considered for the device security model discussed in <xref
target="I-D.ietf-roll-security-framework"></xref>, Section 6.5, <xref
target="fig1b"></xref> 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.</t>
<figure align="center" anchor="fig1b"
title="Overview of AMIKEY multi-protocol key management context">
<preamble></preamble>
<artwork align="left"><![CDATA[
............................. .............................
: +----------+ : : +----------+ :
: |+--------+| : : |+--------+| :
: || 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) :
: +-----------+ : : +-----------+ :
:...........................: :...........................:
]]></artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<t>MIKEY can be used to update TEKs and the Crypto Sessions in a current
Crypto Session Bundle (see <xref target="RFC3830"></xref>, 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.</t>
</section>
<section anchor="extension-elem" title="AMIKEY Key Management Signaling">
<t>The following subsections detail the proposed additions to the MIKEY
specification <xref target="RFC3830"></xref> to support the AMIKEY
extension.</t>
<t>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.</t>
<t>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 <xref
target="fig1c"></xref>.</t>
<figure align="center" anchor="fig1c"
title="(Client) requested key assignment">
<preamble></preamble>
<artwork align="left"><![CDATA[
Key Assignment Key
Initiator ReQuestor
+-----+ +------+
| I | | Q |
+-----+ +------+
Q_MESSAGE
<-----------------------------------------
I_MESSAGE
----------------------------------------->
]]></artwork>
<postamble></postamble>
</figure>
<t>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 <xref
target="fig1d"></xref>.</t>
<figure align="center" anchor="fig1d"
title="(Server) initiated key assignment">
<preamble></preamble>
<artwork align="left"><![CDATA[
Key Assignment Key
Initiator Responder
+-----+ +------+
| I | | R |
+-----+ +------+
I_MESSAGE
----------------------------------------->
[Optional] R_MESSAGE
<-----------------------------------------
]]></artwork>
<postamble></postamble>
</figure>
<section title="Pre-shared key">
<t>The AMIKEY signaling flow and message information content for the
Pre-shared key (PSK) method is as shown in <xref
target="fig1e"></xref> below, in which "[]" indicates optional
messages or elements:</t>
<figure align="center" anchor="fig1e"
title="Signaling exchange and message content for the PSK method">
<preamble></preamble>
<artwork align="left"><![CDATA[
Requestor
Q_MESSAGE =
[<---] HDR, T, [IDq], V
Initiator Responder
I_MESSAGE =
HDR, T, RAND, [IDi],[IDr],
{SP}, KEMAC --->
R_MESSAGE =
[<---] HDR, T, [IDr], V
]]></artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC3830"></xref> Section 5.2 for
the exact definition of the Verification MAC calculation and <xref
target="RFC3830"></xref> Section 6.9 for payload definition.</t>
<t>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.</t>
<t>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 <xref target="common-hdr"></xref>).</t>
<t>For AMIKEY the pre-shared key method is mandatory to implement.</t>
</section>
<section title="Public-Key Encryption">
<t>For the public-key encryption method, the signaling exchange and
message content is similar to that of the PSK case as shown in <xref
target="fig1f"></xref> below:</t>
<figure align="center" anchor="fig1f"
title="Signaling exchange and message content for the PK method">
<preamble></preamble>
<artwork align="left"><![CDATA[
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
]]></artwork>
<postamble></postamble>
</figure>
<t>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 <xref
target="RFC3830"></xref> for the exact definition of the Signature
calculation). The message SHALL be sent in cleartext, authenticated by
the signature.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref
target="common-hdr"></xref>).</t>
<t>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.</t>
<t>The Initiator message SHALL indicate that the Responder message is
not required when a Requestor message has been used to initiate the
key exchange.</t>
<t>For AMIKEY the public key method is mandatory to implement.</t>
</section>
<section title="[RFC3830] Diffie-Hellman Key Exchange">
<t>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 <xref target="RFC3830"></xref>
even with a key client-server network infrastructure.</t>
<t>For AMIKEY this method is optional to implement.</t>
</section>
</section>
<section anchor="mgmt-func"
title="[RFC3830] Selected Key Management Functions">
<t>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 <xref
target="RFC4493"></xref>.</t>
<section title="[RFC3830] Key Calculation">
<section title="[RFC3830] Assumptions">
<t>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 <xref
target="map-type"></xref>) and may be public or
private/vendor-specific.</t>
</section>
<section anchor="default-prf" title="Default PRF Description">
<t>For AMIKEY the default pseudo random function shall be AES-CMAC
<xref target="RFC4493"></xref>. Note: AES-CMAC aligns with HMAC-SHA1
and HMAC-MD5 as PRFs.</t>
</section>
<section title="[RFC3830] Generating Keys from TGK">
<t>For AMIKEY the cs-id values shall be as defined in this
specification (see <xref target="map-type"></xref>).</t>
</section>
<section anchor="gen-key-from-env-pre"
title="[RFC3830] Generating Keys for MIKEY Messages from an Envelope/Pre-shared Key">
<t>Change from default PRF to the default AMIKEY PRF given in <xref
target="default-prf"></xref> of this specification.</t>
<t>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).</t>
</section>
</section>
<section title="[RFC3830] Pre-defined Transforms and Timestamp Formats">
<section title="Hash Functions">
<t>For AMIKEY the default hash function shall be AES-CMAC <xref
target="RFC4493"></xref>.</t>
</section>
<section title="Pseudo-Random Number Generator">
<t>For AMIKEY it shall be MANDATORY to implement the new default
AES-CMAC PRF specified in <xref target="RFC4493"></xref> (See <xref
target="default-prf"></xref> of this specification).</t>
</section>
<section title="[RFC3830] Key Data Transport Encryption">
<t>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 <xref target="gen-key-from-env-pre"></xref> above).
The applied Counter shall be the IV defined in <xref
target="RFC3830"></xref>, Section 4.2.3.</t>
</section>
<section anchor="mac-function"
title="[RFC3830] MAC Verification Message Function">
<t>For AMIKEY AES-CCM-64 shall be the defined default for key
message authentication. The Counter used shall be the IV defined in
<xref target="RFC3830"></xref>, Section 4.2.3.</t>
</section>
</section>
<section title="[RFC3830] Certificates, Policies and Authorization"></section>
<section title="[RFC3830] Retrieving the Data SA">
<t>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
<xref target="map-type"></xref> of this specification).</t>
</section>
</section>
<section title="[RFC3830] Behavior and Message Handling">
<section title="[RFC3830] General"></section>
<section title="[RFC3830] Creating a message">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="payload" title="[RFC3830] Payload Encoding">
<t>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
<xref target="RFC3830"></xref> 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.</t>
<t>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.</t>
<section anchor="common-hdr"
title="[RFC3830] Common Header Payload (HDR)">
<t>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.</t>
<figure align="center" anchor="fig2" title="Common Header [RFC3830]">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>version (8 bits): the version number of MIKEY.</t>
<t>version = 0x01 refers to MIKEY as defined and maintained in
<xref target="RFC3830"></xref>.</t>
<t>version = 0x03 (to be assigned by IANA) shall be used to refer
to AMIKEY as defined and maintained in this document.</t>
<t>data type (8 bits): describes the type of message (e.g.,
public-key transport message, verification message, error
message). See latest IANA registered values. For AMIKEY new data
type values are used to specify the additional PSK and PK method
Requestor messages (to be assigned by IANA).</t>
</list></t>
<texttable title="Table 6.1.a">
<ttcol align="left">Data Type</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comment</ttcol>
<c>PSK Request</c>
<c>i</c>
<c>Requestor's pre-shared key message (AMIKEY)</c>
<c>PK Request</c>
<c>j</c>
<c>Requestor's public key message (AMIKEY)</c>
<postamble></postamble>
</texttable>
<t><list style="symbols">
<t>next payload (8 bits): identifies the payload that is added
after this payload. See latest IANA registered values.</t>
</list></t>
<t>For AMIKEY a new next payload value is assigned to carry the Key
Index parameter (see also <xref target="key-index"></xref>).</t>
<texttable title="Table 6.1.b">
<ttcol align="left">Next Payload</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Section</ttcol>
<c>Last payload</c>
<c>0</c>
<c>-</c>
<c>...</c>
<c></c>
<c></c>
<c>Key Index</c>
<c>n</c>
<c><xref target="key-index"></xref> as given by the AMIKEY
specification (value to be assigned by IANA).</c>
<c>Key Source ID</c>
<c>m</c>
<c><xref target="key-source"></xref> as given by the AMIKEY
specification (value to be assigned by IANA)</c>
<postamble></postamble>
</texttable>
<t><list style="symbols">
<t>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).</t>
<t>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.</t>
</list></t>
<texttable title="Table 6.1.c">
<ttcol align="left">PRF Function</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<c>AES-CMAC</c>
<c>2</c>
<c>As specified in <xref target="RFC4493"></xref> and that shall be
mandatory for AMIKEY</c>
<postamble></postamble>
</texttable>
<t>(AMIKEY value to be assigned by IANA)</t>
<t><list style="symbols">
<t>CSB ID (32 bits): identifies the CSB (generated as specified in
<xref target="RFC3830"></xref>); 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.</t>
<t>#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.</t>
<t>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.</t>
</list></t>
<texttable title="Table 6.1.d">
<ttcol align="left">CS ID Map Type</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<c>Generic_LLN-ID</c>
<c>3</c>
<c>As specified in this document and as mandatory for AMIKEY</c>
<postamble></postamble>
</texttable>
<t>(AMIKEY value to be assigned by IANA)</t>
<t><list style="symbols">
<t>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 <xref target="map-type"></xref>
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.</t>
</list></t>
<section title="[RFC3830] SRTP ID"></section>
<section anchor="map-type" title="The Generic_LLN-ID Map Type">
<t>For the Generic_LLN map type, the CS ID map info consists of #CS
(see <xref target="common-hdr"></xref>) 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.</t>
<figure align="center" anchor="fig3" title="Generic_LLN-ID Map Type">
<preamble></preamble>
<artwork align="left"><![CDATA[
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>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.</t>
</list></t>
<t>Note: A combination of public and private CS IDs can be specified
within a given CSB when combined key management is being
applied.</t>
<t>The following values are currently specified in this document
(for example, with values to be assigned by IANA):</t>
<texttable title="Table 6.1.e">
<ttcol align="left">CS ID</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<c>Reserved</c>
<c>0</c>
<c></c>
<c>Generic PHY Layer</c>
<c>1</c>
<c></c>
<c>Generic Link Layer</c>
<c>2</c>
<c></c>
<c>Generic Network Layer</c>
<c>3</c>
<c></c>
<c>Generic Transport Layer</c>
<c>4</c>
<c></c>
<c>Generic Application Layer</c>
<c>7</c>
<c></c>
<c>RPL Protocol</c>
<c>20</c>
<c></c>
<c>...</c>
<c></c>
<c></c>
<c>Reserved values</c>
<c>128-255</c>
<c>Reserved for private use</c>
<postamble></postamble>
</texttable>
<t><list style="symbols">
<t>#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.</t>
<t>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 <xref target="sp-payload"></xref>.</t>
</list></t>
<figure align="center" anchor="fig4" title="Policies">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>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.</t>
</list></t>
</section>
</section>
<section title="[RFC3830] Key Data Transport Payload (KEMAC)">
<t>This section shall apply entirely as specified for MIKEY in <xref
target="RFC3830"></xref> with the addition of the specific message
authentication code algorithms given below for AMIKEY.</t>
<t><list style="symbols">
<t>MAC alg (8 bits): specifies the authentication algorithm
used.</t>
</list></t>
<texttable title="Table 6.2.b">
<ttcol align="left">MAC alg</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<ttcol align="center">Length (bits)</ttcol>
<c>NULL</c>
<c>0</c>
<c>restricted usage <xref target="RFC3830"></xref>, Section
4.2.4</c>
<c>0</c>
<c>HMAC-SHA-1-160</c>
<c>1</c>
<c>Mandatory, <xref target="RFC3830"></xref>, Section 4.2.4</c>
<c>160</c>
<c>HMAC-SHA-256-256</c>
<c>2</c>
<c>Mandatory, <xref target="RFC3830"></xref>, Section 4.2.4</c>
<c>256</c>
<c>AES-CBC-MAC-32</c>
<c>3</c>
<c>Mandatory for AMIKEY, see <xref target="mac-function"></xref></c>
<c>32</c>
<c>AES-CBC-MAC-64</c>
<c>4</c>
<c>Mandatory for AMIKEY, see <xref target="mac-function"></xref></c>
<c>64</c>
<c>AES-CBC-MAC-128</c>
<c>5</c>
<c>Mandatory for AMIKEY, see <xref target="mac-function"></xref></c>
<c>128</c>
<postamble></postamble>
</texttable>
<t>(Values for AMIKEY to be assigned by IANA)</t>
<t><list style="symbols">
<t>MAC (variable length): the message authentication code of the
entire message.</t>
</list></t>
<t>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.</t>
</section>
<section title="[RFC3830] Envelope Data Payload (PKE)"></section>
<section title="[RFC3830] DH Data Payload (DH)"></section>
<section title="[RFC3830] Signature Payload (SIGN)"></section>
<section title="[RFC3830] Timestamp Payload (T)"></section>
<section title="ID Payload (ID)">
<t>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 <xref
target="RFC3830"></xref>, Section 6.7.</t>
<texttable title="Table 6.7.a">
<ttcol align="left">ID Type</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<c>IPv6 Address</c>
<c>4</c>
<c>As specified for AMIKEY</c>
<c>Device MAC Address</c>
<c>5</c>
<c>As specified for AMIKEY</c>
<c>Other (TBD)</c>
<c>n</c>
<c>As specified for AMIKEY</c>
<postamble></postamble>
</texttable>
<t>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 <xref target="RFC3830"></xref>).</t>
<t>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 <xref
target="RFC4291"></xref> the ID len value will be set to zero and no
ID data included in the value field (see <xref
target="RFC3830"></xref>).</t>
<t>Note: The ID payload may be used by a supported security protocol
as implicit Key Source Identifier (see <xref
target="key-source"></xref>) for referencing key origination.</t>
</section>
<section title="[RFC3830] Cert Hash Payload (CHASH)"></section>
<section title="[RFC3830] Ver msg payload (V)"></section>
<section anchor="sp-payload" title="Security Policy (SP) Payload">
<t>The Security Policy payload defines a set of policies that apply to
a specific security protocol.</t>
<t>For AMIKEY the definition is based on the same security policy
payload definition in <xref target="RFC3830"></xref>, Section 6.10,
with a new security protocol (Generic-LLN) as defined below.</t>
<figure align="center">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>Next payload (8 bits): Identifies the payload that is added
after this payload. See Section 6.1 of <xref
target="RFC3830"></xref> for more details.</t>
<t>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 <xref
target="RFC3830"></xref>).</t>
<t>Prot type (8 bits): This value defines the security protocol;
For AMIKEY an additional value shall be assigned as given
below.</t>
</list></t>
<texttable title="Table 6.10">
<ttcol align="left">Prot Type</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="center">Comments</ttcol>
<c>Generic_LLN</c>
<c>3</c>
<c>As specified for AMIKEY</c>
<postamble></postamble>
</texttable>
<t><list style="symbols">
<t>Policy param length (16 bits): This field defines the total
length of the policy parameters for the selected security
protocol.</t>
<t>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.</t>
</list></t>
<figure align="center" anchor="fig7" title="Policy Parameter">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>Type (8 bits): Specifies the type of the parameter.</t>
<t>Length (8 bits): Specifies the length of the Value field (in
bytes).</t>
<t>Value (variable length): Specifies the value of the
parameter.</t>
</list></t>
<section title="[RFC3830] SRTP Policy"></section>
<section title="AMIKEY Generic_LLN Policy">
<t>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.</t>
<texttable title="Table 6.10.2.a">
<ttcol align="center">Type</ttcol>
<ttcol align="left">Meaning</ttcol>
<ttcol align="left">Possible Values</ttcol>
<c>0</c>
<c>Encryption algorithm</c>
<c>See below</c>
<c>1</c>
<c>Encryption key length</c>
<c>Depends on cipher used</c>
<c>2</c>
<c>Authentication algorithm</c>
<c>See below</c>
<c>3</c>
<c>Authentication key length</c>
<c>Depends on MAC used</c>
<c>4</c>
<c>Generic LLN PRF</c>
<c>See below</c>
<c>5</c>
<c>Encryption off/on</c>
<c>0 if off, 1 if on</c>
<postamble></postamble>
</texttable>
<t>For the Encryption algorithm, a one byte length is sufficient.
For AMIKEY the currently defined possible Values are:</t>
<texttable title="Table 6.10.2.b">
<ttcol align="left">G_LLN encr alg</ttcol>
<ttcol align="center">Value</ttcol>
<c>NULL</c>
<c>0</c>
<c>AES-CM-128</c>
<c>1</c>
<postamble></postamble>
</texttable>
<t>For the Authentication algorithm, a one byte length is
sufficient. For AMIKEY the currently defined possible Values
are:</t>
<texttable title="Table 6.10.2.c">
<ttcol align="left">G_LLN auth alg</ttcol>
<ttcol align="center">Value</ttcol>
<ttcol align="left">Comments</ttcol>
<c>NULL</c>
<c>0</c>
<c>Not recommended for operational use</c>
<c>AES-CBC-MAC-32</c>
<c>1</c>
<c></c>
<c>AES-CBC-MAC-64</c>
<c>2</c>
<c></c>
<c>AES-CBC-MAC-128</c>
<c>3</c>
<c></c>
<c>RSA-SHA-256 Sig</c>
<c>4</c>
<c></c>
<postamble></postamble>
</texttable>
<t>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.</t>
<t>For the Generic_LLN pseudo-random function, a one byte length is
also sufficient. For AMIKEY the currently defined possible Values
are:</t>
<texttable title="Table 6.10.2.d">
<ttcol align="left">Generic_LLN PRF</ttcol>
<ttcol align="center">Value</ttcol>
<c>AES-CMAC</c>
<c>0</c>
<postamble></postamble>
</texttable>
</section>
</section>
<section title="[RFC3830] RAND Payload (RAND)"></section>
<section title="[RFC3830] Error Payload (ERR)"></section>
<section title="[RFC3830] Key Data Sub-Payload">
<t>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 <xref target="key-valid"></xref>).</t>
</section>
<section anchor="key-valid" title="[RFC3830] Key Validity Data">
<t>For AMIKEY the Key Validity Data element shall be used to specify
the activation time and validity period of an assigned TGK.</t>
<t>For AMIKEY, the key validity (KV) period for a TGK/TEK shall be
specified using the KV Interval type (see <xref
target="RFC3830"></xref> Section 6.13).</t>
<t>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.</t>
</section>
<section title="[RFC3830] General Extension Payload"></section>
<section anchor="key-index" title="Key Index Payload">
<t>For AMIKEY the Key Index (KI) payload is used to specify the value
of the key index associated with a given TGK.</t>
<figure align="center" anchor="fig8" title="Key Index">
<preamble></preamble>
<artwork align="left"><![CDATA[
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>Next payload (8 bits): identifies the payload that is added
after this payload. See Section 6.1 <xref target="RFC3830"></xref>
for values.</t>
<t>KI len (8 bits): indicates the length of the key source
identifier field.</t>
<t>KI value (variable length): indicates the value of the key
index to be assigned to any CS TEK generated from the transported
TGK.</t>
</list></t>
</section>
<section anchor="key-source" title="Key Source Identifier Payload">
<t>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 <xref target="I-D.ietf-roll-rpl"></xref> specifies the use of
an 8-byte KSI).</t>
<figure align="center" anchor="fig8b" title="Key Source Identifier">
<preamble></preamble>
<artwork align="left"><![CDATA[
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>Next payload (8 bits): identifies the payload that is added
after this payload. See Section 6.1 <xref target="RFC3830"></xref>
for values.</t>
<t>KSI len (8 bits): indicates the length of the key source
identifier field.</t>
<t>KSI value (variable length): specifies the logical identifier
assigned to the Source or Originator of a given TGK.</t>
</list></t>
</section>
<!--
<section anchor="key-act-time" title="Key Activation Time Payload">
<t>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)
<xref target="RFC3830"></xref>.</t>
<figure align="center" anchor="fig9"
title="Key Activation Time Payload">
<preamble></preamble>
<artwork align="left"><![CDATA[
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 ! TS type ! TS value (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure>
<t><list style="symbols">
<t>Next payload (8 bits): identifies the payload that is added
after this payload. See Section 6.1 <xref target="RFC3830"></xref>
for values.</t>
<t>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 <xref target="RFC3830"></xref>).</t>
<t>TS value (variable length): the timestamp value of the
specified TS type (See Section 6.6 <xref
target="RFC3830"></xref>).</t>
</list></t>
</section>
-->
</section>
<section title="[RFC3830] Transport Protocols">
<t>As in <xref target="RFC3830"></xref>, 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.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
<section title="[RFC3830] Groups"></section>
<section title="Additional Specification Considerations">
<t>Work had been previously initiated in developing support for an
ECC-based asymmetric key management method (<xref
target="I-D.ietf-msec-mikey-ecc"></xref>, expired). In the context of
LLNs application and subject to IPR considerations, related AMIKEY
requirements may be developed.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>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 <xref target="RFC2434"></xref>.</t>
<t>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): <list style="symbols">
<t>Common Header payload (6.1.) <list style="symbols">
<t>Version</t>
</list></t>
<t>Data type (6.1.a) <list style="symbols">
<t>AMIKEY PSK Request msg</t>
<t>AMIKEY PK Request msg</t>
</list></t>
<t>Next payload (6.1.b) <list style="symbols">
<t>Key index</t>
<t>Key source identifier</t>
</list></t>
<t>Prf func (6.1.c) <list style="symbols">
<t>AES-CMAC</t>
</list></t>
<t>CS ID map type (6.1.d) <list style="symbols">
<t>Generic_LLN-ID</t>
</list></t>
<t>MAC alg (6.2.b) <list style="symbols">
<t>AES-CBC-MAC-32</t>
<t>AES-CBC-MAC-64</t>
<t>AES-CBC-MAC-128</t>
</list></t>
<t>ID payload (6.7.a) <list style="symbols">
<t>IPv6 Address</t>
<t>Device MAC Address</t>
</list></t>
<t>Proto type (6.10) <list style="symbols">
<t>Generic_LLN</t>
</list></t>
<t>Generic_LLN policy (6.10.2) <list style="symbols">
<t>Policy parameters (6.10.2.a)</t>
<t>G_LLN encr alg (6.10.2.b)</t>
<t>G_LLN auth alg (6.10.2.c)</t>
<t>G_LLN prf (6.10.2.d)</t>
</list></t>
</list></t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Acknowledgements" title="Acknowledgments">
<t>The authors would like to acknowledge the review and comments from
Rene Struik and Stephen Farrell.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2434;
&RFC3830;
&RFC4493;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3605;
&RFC3711;
&RFC4107;
&RFC4291;
&RFC4442;
&RFC4563;
&RFC4566;
&RFC4650;
&RFC4738;
&RFC5197;
&RFC5410;
&RFC6043;
&RFC6267;
<!-- <reference anchor="SP800-38A">
<front>
<title>NIST Special Publication 800-38A, Recommendation for Block
Cipher Modes of Operation</title>
<author></author>
<date month="Dec." year="2001" />
</front>
<seriesInfo name="US"
value="National Institute of Standards and Technology" />
</reference> -->
&I-D.ietf-roll-rpl;
&I-D.ietf-roll-security-framework;
&I-D.ietf-msec-mikey-ecc;
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
<!-- Keep this comment at the end of the file
Local variables:
mode: xml
sgml-omittag:nil
sgml-shorttag:nil
sgml-namecase-general:nil
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
| PAFTECH AB 2003-2026 | 2026-04-22 23:03:12 |