idnits 2.17.1 draft-alexander-roll-mikey-lln-key-mgmt-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2012) is 4244 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Optional' is mentioned on line 595, but not defined == Missing Reference: 'IDq' is mentioned on line 620, but not defined == Missing Reference: 'IDi' is mentioned on line 625, but not defined == Missing Reference: 'IDr' is mentioned on line 691, but not defined == Missing Reference: 'CHASH' is mentioned on line 689, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group R. Alexander 3 Internet-Draft T. Tsao 4 Intended status: Standards Track Cooper Power Systems 5 Expires: March 16, 2013 September 12, 2012 7 Adapted Multimedia Internet KEYing (AMIKEY): An extension of Multimedia 8 Internet KEYing (MIKEY) Methods for Generic LLN Environments 9 draft-alexander-roll-mikey-lln-key-mgmt-04 11 Abstract 13 Multimedia Internet Keying (MIKEY) is a key management protocol used 14 for real-time applications. As standardized within RFC3830 it 15 defines four key distribution methods, including pre-shared keys, 16 public-key encryption, and Diffie-Hellman key exchange, with 17 allowances for ready protocol extension. A number of additional 18 methods have been developed and continue to be built from the base 19 protocol (see for example, RFC4442, RFC4563, RFC4650, RFC4738, 20 RFC5410, RFC6043 and RFC6267. However, in spite of its extensibility 21 and more general applicability, MIKEY and its related extensions have 22 primarily focused on the support of the Secure Real-time Transport 23 Protocol (SRTP). 25 This document specifies a simple adaptation of the MIKEY 26 specification to allow the base protocol and its various key 27 management mode extensions to be readily applied in more general 28 environments beyond the multimedia SRTP domain. In particular, the 29 document defines a repurposing of the MIKEY multimedia crypto 30 sessions structure and introduces a set of message extensions to the 31 base specification to allow the MIKEY key management methods to be 32 applied within Low-power and Lossy Networks (LLNs) and other general 33 constrained-device networks. 35 Requirements Language 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 39 "OPTIONAL" in this document are to be interpreted as described in RFC 40 2119 [RFC2119]. 42 Status of this Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on March 16, 2013. 59 Copyright Notice 61 Copyright (c) 2012 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 78 1.2. MIKEY Key Management Methods Background . . . . . . . . . 6 79 1.3. Adapting MIKEY to General LLNs . . . . . . . . . . . . . . 7 80 1.4. Terminology and Definitions . . . . . . . . . . . . . . . 7 81 1.5. Document Outline . . . . . . . . . . . . . . . . . . . . . 9 82 1.6. Section Headings Notation . . . . . . . . . . . . . . . . 10 83 2. AMIKEY Overview . . . . . . . . . . . . . . . . . . . . . . . 10 84 3. AMIKEY Key Management Signaling . . . . . . . . . . . . . . . 14 85 3.1. Pre-shared key . . . . . . . . . . . . . . . . . . . . . . 15 86 3.2. Public-Key Encryption . . . . . . . . . . . . . . . . . . 17 87 3.3. [RFC3830] Diffie-Hellman Key Exchange . . . . . . . . . . 18 88 3.4. Example of AMIKEY Applied to RPL . . . . . . . . . . . . . 18 89 3.4.1. AMIKEY Key Assignment for RPL Join Process . . . . . . 18 90 3.4.2. AMIKEY Key Update for RPL Authenticated Mode . . . . . 21 91 4. [RFC3830] Selected Key Management Functions . . . . . . . . . 25 92 4.1. [RFC3830] Key Calculation . . . . . . . . . . . . . . . . 25 93 4.1.1. [RFC3830] Assumptions . . . . . . . . . . . . . . . . 25 94 4.1.2. Default PRF Description . . . . . . . . . . . . . . . 25 95 4.1.3. [RFC3830] Generating Keys from TGK . . . . . . . . . . 25 96 4.1.4. [RFC3830] Generating Keys for MIKEY Messages from 97 an Envelope/Pre-shared Key . . . . . . . . . . . . . . 25 98 4.2. [RFC3830] Pre-defined Transforms and Timestamp Formats . . 25 99 4.2.1. Hash Functions . . . . . . . . . . . . . . . . . . . . 25 100 4.2.2. Pseudo-Random Number Generator . . . . . . . . . . . . 25 101 4.2.3. [RFC3830] Key Data Transport Encryption . . . . . . . 26 102 4.2.4. [RFC3830] MAC Verification Message Function . . . . . 26 103 4.3. [RFC3830] Certificates, Policies and Authorization . . . . 26 104 4.4. [RFC3830] Retrieving the Data SA . . . . . . . . . . . . . 26 105 5. [RFC3830] Behavior and Message Handling . . . . . . . . . . . 26 106 5.1. [RFC3830] General . . . . . . . . . . . . . . . . . . . . 26 107 5.2. [RFC3830] Creating a message . . . . . . . . . . . . . . . 26 108 6. [RFC3830] Payload Encoding . . . . . . . . . . . . . . . . . . 26 109 6.1. [RFC3830] Common Header Payload (HDR) . . . . . . . . . . 27 110 6.1.1. [RFC3830] SRTP ID . . . . . . . . . . . . . . . . . . 29 111 6.1.2. The Generic_LLN-ID Map Type . . . . . . . . . . . . . 29 112 6.2. [RFC3830] Key Data Transport Payload (KEMAC) . . . . . . . 31 113 6.3. [RFC3830] Envelope Data Payload (PKE) . . . . . . . . . . 32 114 6.4. [RFC3830] DH Data Payload (DH) . . . . . . . . . . . . . . 32 115 6.5. [RFC3830] Signature Payload (SIGN) . . . . . . . . . . . . 32 116 6.6. [RFC3830] Timestamp Payload (T) . . . . . . . . . . . . . 32 117 6.7. ID Payload (ID) . . . . . . . . . . . . . . . . . . . . . 32 118 6.8. [RFC3830] Cert Hash Payload (CHASH) . . . . . . . . . . . 33 119 6.9. [RFC3830] Ver msg payload (V) . . . . . . . . . . . . . . 33 120 6.10. Security Policy (SP) Payload . . . . . . . . . . . . . . . 33 121 6.10.1. [RFC3830] SRTP Policy . . . . . . . . . . . . . . . . 34 122 6.10.2. AMIKEY Generic_LLN Policy . . . . . . . . . . . . . . 34 123 6.11. [RFC3830] RAND Payload (RAND) . . . . . . . . . . . . . . 36 124 6.12. [RFC3830] Error Payload (ERR) . . . . . . . . . . . . . . 36 125 6.13. [RFC3830] Key Data Sub-Payload . . . . . . . . . . . . . . 36 126 6.14. [RFC3830] Key Validity Data . . . . . . . . . . . . . . . 36 127 6.15. [RFC3830] General Extension Payload . . . . . . . . . . . 36 128 6.16. Key Index Payload . . . . . . . . . . . . . . . . . . . . 36 129 6.17. Key Source Identifier Payload . . . . . . . . . . . . . . 37 130 7. [RFC3830] Transport Protocols . . . . . . . . . . . . . . . . 38 131 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 132 9. [RFC3830] Groups . . . . . . . . . . . . . . . . . . . . . . . 38 133 10. Additional Specification Considerations . . . . . . . . . . . 38 134 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 135 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 136 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 137 13.1. Normative References . . . . . . . . . . . . . . . . . . . 40 138 13.2. Informative References . . . . . . . . . . . . . . . . . . 40 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 141 1. Introduction 143 Any sufficiently large scale network offering security services 144 requires an automated key management mechanism for the exchange of 145 keys and the update of related security credentials [RFC4107]. Key 146 management may be needed for individual session exchanges or for the 147 long-term control and update of security parameters from which 148 session keys may be derived. In many Low-power and Lossy Networks 149 (LLN) and other constrained-device environments, key management 150 emphasis is often on the management of long-term keys. This may 151 automatically follow network associations based on device pre- 152 configuration or may be based on specified key lifetimes or 153 administrative or event-driven need for key credential changes. This 154 would apply to the case of a network routing protocol like RPL 155 ([RFC6550]) that employs security as well as to other secured 156 communications layer protocols. 158 Multimedia Internet Keying (MIKEY) is a key management protocol that 159 has been used for real-time applications both for peer-to-peer and 160 group communications. The capabilities of the protocol lend 161 themselves just as readily to the management of long-term keys as to 162 per-session or per association key control. MIKEY [RFC3830] defines 163 four key distribution methods including pre-shared keys, public-key 164 encryption, and Diffie-Hellman key exchange. Given its design 165 simplicity, efficiency and flexibility a number of additional modes 166 and extensions have indeed been developed and continue to be built 167 from the base protocol (see for example, [RFC4442], [RFC4563], 168 [RFC4650], [RFC4738], [RFC5410], [RFC6043] and [RFC6267]). MIKEY and 169 its related RFC extensions have however primarily focused on the 170 support of the SRTP and related Session Initiation Protocol (SIP) 171 call scenarios [RFC3711]. 173 This document specifies an adaptation of the MIKEY protocol 174 specification to allow the base protocol and its various key 175 management mode extensions to be more generally applied to LLN 176 environments. In particular, the document defines a repurposing of 177 the MIKEY multimedia crypto sessions structure to allow optional 178 support for simultaneous management of multiple protocol or device 179 interface key. The specification also introduces a set of message 180 extensions to the base MIKEY protocol to allow its key management 181 methods to be applied within generic LLN and constrained-device 182 networks. 184 1.1. Motivation 186 Key distribution describes the process of delivering cryptographic 187 keys to the required communicating parties. The MIKEY protocol has 188 defined the mechanisms for establishing the security context used by 189 SRTP however the mechanisms for security parameter negotiation and 190 update is just as readily extended to LLN protocols. 192 The flexibly to employ different key distribution methods according 193 to available network infrastructure and particular operating 194 scenarios together with the compact efficiency of its binary 195 specification makes MIKEY well suited for general LLN use. The wide 196 range of key management support extending from light-weight, low 197 latency half round-trip pre-shared key distribution methods to multi- 198 exchange Diffie-Hellman key agreements protected with digital 199 signatures or pre-shared keys offers great flexibility to meet the 200 needs of diverse LLN application environments. 202 The option to embed the MIKEY key management messages within an 203 existing network signaling protocol or to be directly transported or 204 UDP or TCP (using port 2269) also increases the ability to apply the 205 methods in more general LLN domains. 207 MIKEY has met its original stated design goals [RFC3830] of end-to- 208 end security, simplicity, efficiency, tunneling (even beyond 209 integration with Session Description Protocol (SDP) [RFC4566] or RTCP 210 [RFC3605]), and independence of underlying transport. In so doing it 211 offers an excellent base for a generic key management protocol for 212 LLN application. Key management protocols are also difficult to 213 design and validate (see [RFC4107] guidelines) providing a further 214 motivation for reliance on an established protocol like MIKEY that 215 has had the benefit of wider operational deployment and evaluation. 217 1.2. MIKEY Key Management Methods Background 219 As noted in [RFC5197], several key distribution methods have been 220 described for MIKEY, including: 222 o Symmetric key distribution as defined in [RFC3830] (MIKEY-PSK) 224 o Asymmetric key distribution as defined in [RFC3830] (MIKEY-RSA) 226 o Diffie-Hellman key agreement protected by digital signatures as 227 defined in [RFC3830] (MIKEY-DHSIGN) 229 o Diffie-Hellman key agreement protected by symmetric pre-shared 230 keys as defined in [RFC4650] (MIKEY-DHHMAC) 232 o Asymmetric key distribution (based on asymmetric encryption) with 233 in-band certificate provision as defined in [RFC4738] 234 (MIKEY-RSA-R) 236 Further extensions to MIKEY comprising algorithm enhancements and new 237 payload definitions have since been defined generally motivated by 238 the specific problems associated with SIP signaling and associated 239 multimedia use case scenarios (see [RFC5197]for an earlier 240 assessment). This specification proposes a new extension that is 241 focused on a new domain of application. 243 1.3. Adapting MIKEY to General LLNs 245 This document specifies a set of additional message information 246 elements to the base MIKEY protocol that provide both algorithm and 247 message payload extensions. These additions allow the adapted 248 protocol to be used directly for key transport and security policy 249 specification between communications generic network entities. 250 Furthermore, through integration within the base MIKEY specification 251 it will allow current and future key methods and extensions to be 252 utilized outside of the current multimedia environment. 254 The developed protocol adaption includes the specification of 255 alternative default algorithms (in particular AES-based as widely 256 available in emerging device hardware) and configurations that are 257 particular to more constrained communications devices. MIKEY's 258 general extensibility is also used to define new elements applicable 259 to the LLN environment. 261 An important element of the protocol extension is the re-use of the 262 MIKEY crypto-session structure to apply to individual device 263 communications protocol layers or interfaces instead of applying to 264 multimedia streams. By maintaining this base protocol structure and 265 re-purposing associated message identifiers, the specification 266 minimizes the protocol changes needed for network adaptation. 268 As with the original specification the intent is to allow MIKEY 269 messages to be embedded into existing communications signaling 270 protocols or to be independently transported between communicating 271 entities over UDP or TCP transport connections. 273 Note: While MIKEY and its extensions provide a variety of choices in 274 terms of modes of operation, implementations for a given LLN 275 application domain will be able to simplify node behavior by 276 operating in a single mode. To ensure necessary interoperability 277 within the LLN environment, mandatory methods within the Adapted 278 MIKEY protocol (AMIKEY), akin to those of MIKEY, shall be specified. 280 1.4. Terminology and Definitions 282 The following definitions have been taken from [RFC3830] with 283 necessary augmentation for AMIKEY as indicated: 285 (Data) Security Protocol 286 The security protocol used to protect the actual data traffic. 287 Examples of security protocols are IPsec and SRTP. For generic 288 LLNs, security protocols may include secure versions of 289 protocols such as RPL [RFC6550]. 291 Data SA 292 Data Security Association information for the security 293 protocol, including a TEK and a set of parameters/policies. 295 CS Crypto Session, uni- or bidirectional data stream(s) protected 296 by a single instance of a security protocol. For AMIKEY the 297 concept of a crypto-session is expanded to allow definition of 298 a particular protocol layer, logical device interface, or other 299 communications association for which key management support is 300 provided. 302 CSB Crypto Session Bundle, collection of one or more Crypto 303 Sessions, which can have common TGKs (see below) and security 304 parameters. 306 CS ID Crypto Session ID, unique identifier for the CS within a CSB. 307 For AMIKEY the CS ID is used to identify a specific protocol 308 layer, logical device interface or other communications 309 association for which AMIKEY is being used to support key 310 management (establishment of re-keying update). 312 CSB ID 313 Crypto Session Bundle ID, unique identifier for the CSB. For 314 AMIKEY the CSB ID in conjunction with the Timestamp filed is 315 used as a unique key management exchange message reference 316 identifier. This identifier will allow for the acknowledged 317 key management message exchanges where applicable. The ID plus 318 timestamp will also support the filtering of repeated or 319 redundant AMIKEY messages when key management occurs over an 320 unreliable transport network. 322 TGK TEK Generation Key, a bit-string agreed upon by two or more 323 parties, associated with CSB. From the TGK, Traffic-Encrypting 324 Keys can then be generated without needing further 325 communication. 327 TEK Traffic-Encrypting Key, the key used by the security protocol 328 to protect the CS (this key may be used directly by the 329 security protocol or may be used to derive further keys 330 depending on the security protocol). The TEKs are derived from 331 the CSB's TGK. 333 The following definitions have been added to the ones from [RFC3830] 334 specifically related to supporting AMIKEY: 336 Key Index 337 The Key Index (KI) is used as identifier to allow for reference 338 to the key(s) that are associated with a given CS. Where TEKs 339 may be updated over time a TGK can be associated with a KI that 340 is transported as a payload within the AMIKEY message from the 341 Initiator. Any TEK generated from the AMIKEY TGK shall be 342 assigned the key index value associated with the TGK. Within 343 general LLN protocol communications related to a given CS 344 (device layer protocol or interface), to ensure security 345 association synchronization reference can be made to the key 346 index that is being applied for the given protocol security. 347 Following successfully TGK key establishment communicating 348 devices can verify security contexts through reference to 349 maintained KI (see Section 6.16). 351 Key Source Identifier 352 The Key Source Identifier (KSI) is used as a logical identifier 353 to allow for reference to the entity associated with the 354 origination of a given TGK. Where TEKs are dynamically 355 generated or updated, each TGK can be associated with a 356 specific key source. The KSI, when used, is transported as a 357 payload within the AMIKEY message from the entity responsible 358 for the TGK origination (see Section 6.17). 360 1.5. Document Outline 362 Section 2 provides a brief general system overview of key management 363 as introduced in MIKEY specification. This section generalizes the 364 context in which the Adapted MIKEY (AMIKEY) protocol extension is 365 applied. It also provides a reference to the common key management 366 operating base of MIKEY and AMIKEY. 368 Sections 3 to 4 go into further detail by identifying the specific 369 section and subsection extensions and enhancements needed to support 370 the MIKEY protocol adaptation. These Sections mirror those of MIKEY 371 [RFC3830] and are used to show the necessary commonality and make 372 reference to specific changes would be required for AMIKEY. 373 Reference is made only to the applicable Sections and Subsections of 374 [RFC3830] for which special changes are proposed. 376 Section 6 includes the specific protocol specification elements that 377 are needed to extend MIKEY for the support of the generic LLN key 378 management requirements. 380 The remaining document sections are place-holders for standard RFC 381 draft sections. 383 1.6. Section Headings Notation 385 This document is written as a delta document to [RFC3830]. For ease 386 of cross-reference and to maintain consistency with the MIKEY 387 specification document structure, Section heading and Table and 388 Figure numbers are maintained consistent with the [RFC3830] usage. 390 The notation of Section number followed by [RFC3830] "x.x. 391 [RFC3830]" is used is this document for Sections specifically meant 392 to align with [RFC3830]. Section numbers followed by [RFC3830] with 393 additional heading text indicates some new element or clarification 394 introduced by this specification. Section numbers followed by 395 [RFC3830] without further heading text implies no change to [RFC3830] 396 and is used only to align and maintain the current document headings 397 structure. 399 The new parameters introduced in this specification are made 400 consistent with the MIKEY recommendations (see Section 4.2.9 401 [RFC3830]). 403 2. AMIKEY Overview 405 This section provides an overview of AMIKEY. Material from MIKEY 406 [RFC3830] is also repeated to clearly establish the common context in 407 which MIKEY can be applied to LLN environments with the simple 408 extension to the Adapted MIKEY (AMIKEY) specification. 410 The objective of the AMIKEY extension is exactly the same as that of 411 MIKEY - "to produce a data security association (SA) for a security 412 protocol, including a Traffic-Encrypting Key (TEK), which is derived 413 from a TEK Generation Key (TGK), and used as input for the security 414 protocol." In the case of AMIKEY the objective is support generic 415 security protocols and particularly those that may be associated with 416 LLNs. 418 AMIKEY uses the specified MIKEY mechanisms and features to "support 419 the possibility of establishing keys and parameters for more than one 420 security protocol (or for several instances of the same security 421 protocol) at the same time." In MIKEY the Crypto Session Bundle 422 (CSB), which derives from the multimedia (multi-stream) context, is 423 used to denote this collection of one or more Crypto Sessions that 424 can have a common TGK and security parameters, but that obtain 425 distinct TEKs from MIKEY. 427 In the AMIKEY extension, the concept of CSB is used to provide the 428 option of simultaneously establishing multiple SAs on a given device. 429 The individual Crypto Session (CS) SAs may be associated with 430 different device layer or device interface security protocols. 431 AMIKEY further uses the flexibility of the MIKEY specification to 432 allow separate security policies to be defined in the SA established 433 for each security protocol. The distribution mechanisms defined by 434 MIKEY for re-keying and updating of established security associations 435 is hence also directly applied. The ability to establish and 436 maintain multiple SAs through a single key management association 437 provides an important efficiency element in LLN domains. 439 As specified in [RFC3830], Section 2.3, the procedure of setting up a 440 CSB and creating a TEK (and Data SA), is done in accordance with 441 Figure 1: 443 1. A set of security parameters and TGK(s) are agreed upon for the 444 Crypto Session Bundle. This is done by one of many alternative 445 key transport/exchange mechanisms (see [RFC3830], Section 3, as 446 well as subsequent extension RFCs). 448 2. The TGK(s) is used to derive (in a cryptographically secure way) 449 a TEK for each Crypto Session or associated security protocol. 451 3. The TEK, together with the security protocol parameters, 452 represent the Data SA, which is used as the input to the security 453 protocol(s). 455 +-----------------+ 456 | CSB | 457 | Key transport | (see [RFC3830], Section 3) 458 | /exchange | 459 +-----------------+ 460 | : 461 | TGK : 462 v : 463 +----------+ : 464 CS ID ->| TEK | : Security protocol parameters (policies) 465 |derivation| : (see [RFC3830], Section 4) 466 +----------+ : 467 TEK | : 468 v v 469 Data SA 470 | 471 v 472 +-------------------+ 473 | Crypto Session | 474 |(Security Protocol)| 475 +-------------------+ 477 Figure 1: Overview of MIKEY (and AMIKEY extension) key management 478 procedure 480 For generic LLNs that are the focus of this document, the default 481 algorithms applied in the generation of the TEK for each protocol is 482 defined within this AMIKEY specification. An additional MIKEY 483 message extension is also specified to define the security protocol 484 parameters (policies) for generic LLNs. 486 Whereas MIKEY CS IDs are associated with multimedia streams and have 487 no intrinsic designation, in this specification the CS IDs are 488 assigned values (public or private/vendor-specific) that are used to 489 identify security protocols associated with specific device protocol 490 layers or device interfaces. 492 As considered for the device security model discussed in 493 [I-D.ietf-roll-security-framework], Section 6.5, Figure 2 provides an 494 overview of the key management context introduced by the AMIKEY 495 extension defined in this specification. The multi-protocol key 496 management capability (through the particular use of the MIKEY CS- 497 IDs) allows for the efficient, simultaneous management and update of 498 one or more protocol layer security parameters. 500 ............................. ............................. 501 : +----------+ : : +----------+ : 502 : |+--------+| : : |+--------+| : 503 : || AMIKEY || : AMIKEY : || AMIKEY || : 504 : || Key |<========================================>| Key || : 505 : || Mgmt. || Key Exchange (TGK) || Mgmt. || : 506 : || Entity || : : || Entity || : 507 : |+--------+| : : |+--------+| : 508 : | Security | Node i : : Node j | Security | : 509 : | Services | : : | Services | : 510 : | Entity | : : | Entity | : 511 : +----------+ : : +----------+ : 512 : | : : | : 513 : | +-----------+: :+-----------+ | : 514 : | (CSn)+--->| Protocol-n|: :| Protocol-n|<---+(CSn) | : 515 : | | +-----------+: :+-----------+ | | : 516 : | | +-----------+ : : +-----------+ | | : 517 : | (CS7)|->|Application| : : |Application|<-|(CS7) | : 518 : | | +-----------+ : : +-----------+ | | : 519 : | | +-----------+ : : +-----------+ | | : 520 : | (CS4)|->| Transport | : : | Transport |<-|(CS4) | : 521 : | | +-----------+ : : +-----------+ | | : 522 : +------| : : |------+ : 523 : | +-----------+ : : +-----------+ | : 524 : (CS3)|->| Network | : : | Network |<-|(CS3) : 525 : | +-----------+ : : +-----------+ | : 526 : | +-----------+ : : +-----------+ | : 527 : (CS2)|->| L2 | : : | L2 |<-|(CS2) : 528 : | +-----------+ : : +-----------+ | : 529 : | +-----------+ : : +-----------+ | : 530 : (CS1)+->| L1 | : : | L1 |<-+(CS1) : 531 : +-----------+ : : +-----------+ : 532 :...........................: :...........................: 534 Figure 2: Overview of AMIKEY multi-protocol key management context 536 As in the base MIKEY specification, the security protocol can either 537 use the TEK directly, or, if supported, derive further session keys 538 from the TEK. It is however up to the targeted security protocol and 539 the associated security policy to define how the TEK is used. 541 MIKEY can be used to update TEKs and the Crypto Sessions in a current 542 Crypto Session Bundle (see [RFC3830], Section 4.5). This is done by 543 executing the transport/exchange phase once again to obtain a new TGK 544 (and consequently derive new TEKs) or to update some other specific 545 CS parameters. 547 3. AMIKEY Key Management Signaling 549 The following subsections detail the proposed additions to the MIKEY 550 specification [RFC3830] to support the AMIKEY extension. 552 The MIKEY defined key management modes consist of a single (or half) 553 round trip signaling exchange between network peers. In conjunction 554 with the peer-to-peer modes, AMIKEY incorporates support for client- 555 server infrastructures while retaining the maximum single round trip 556 key signaling exchange. 558 For AMIKEY, a client device may request a key assignment or update by 559 sending a request message (Q_MESSAGE) to a key management server 560 (KMS). The request message is protected by a pre-shared secret or a 561 public key. The server initiates the key assignment and completes 562 the exchange by sending a key Initiator message (I_MESSAGE) 563 correspondingly protected by a pre-shared secret or a public key. 564 Mutual authentication and key assignment confirmation is achieved at 565 the requesting device upon receipt of the Initiator message. This 566 signaling mode is shown in Figure 3. 568 Key Assignment Key 569 Initiator ReQuestor 570 +-----+ +------+ 571 | I | | Q | 572 +-----+ +------+ 573 Q_MESSAGE 574 <----------------------------------------- 575 I_MESSAGE 576 -----------------------------------------> 578 Figure 3: (Client) requested key assignment 580 A KMS may also autonomously initiate a key assignment or update by 581 sending a key Initiator message (I_MESSAGE) to a client, protected by 582 a pre-shared secret or a public key. As dictated by the KMS, a key 583 response message (R_MESSAGE) is returned by the key client 584 (Responder) where mutual authentication and assignment confirmation 585 is required. This key management signaling mode is shown in 586 Figure 4. 588 Key Assignment Key 589 Initiator Responder 590 +-----+ +------+ 591 | I | | R | 592 +-----+ +------+ 593 I_MESSAGE 594 -----------------------------------------> 595 [Optional] R_MESSAGE 596 <----------------------------------------- 598 Figure 4: (Server) initiated key assignment 600 As shown, the AMIKEY message flows will typically consist of a 601 request followed by a response in the form on a Requestor-Initiator 602 or Initiator-Responder exchange. It is the responsibility of the 603 Requestor or the Initiator, respectively to ensure reliability of the 604 key assignment signaling exchange. If a response is not received 605 within a timeout interval the Requestor/Initiator needs to retransmit 606 the request or abandon the connection. The timeout interval and the 607 number of retries before a connection is abandoned shall be 608 implementation defined according to the particular network 609 application. 611 3.1. Pre-shared key 613 The AMIKEY signaling flow and message information content for the 614 Pre-shared key (PSK) method is as shown in Figure 5 below, in which 615 "[]" indicates optional messages or elements: 617 Requestor 619 Q_MESSAGE = 620 [<---] HDR, T, [IDq], V 622 Initiator Responder 624 I_MESSAGE = 625 HDR, T, RAND, [IDi],[IDr], 626 {SP}, KEMAC ---> 627 R_MESSAGE = 628 [<---] HDR, T, [IDr], V 630 Figure 5: Signaling exchange and message content for the PSK method 632 The format of the AMIKEY pre-shared key Requestor message (Q_MESSAGE) 633 will follow that of the standard MIKEY Initiator and Responder 634 messages (I_MESSAGE and R_MESSAGE, respectively). Beyond the header 635 (HDR) and Timestamp (T) information elements, the message will 636 include the Identity of the Requestor IDq and the message 637 verification, V. The entire message SHALL be authenticated by V and 638 sent in cleartext. The Requestor IDq MAY be left out only when it 639 can be expected that the peer already knows the other party's ID 640 (otherwise it cannot look up the pre-shared key). For example, this 641 could be the case if the ID can be extracted from the signaling 642 protocol in which the key management message is embedded. 644 The Initiator's message securely transports one or more TGKs (carried 645 in the KEMAC) and a set of security parameters (SPs) to the Responder 646 using the pre-shared key to protect the message and its sub-payloads. 648 The Responder message MAY be sent in response to a key assignment 649 initiated by the Initiator I_MESSAGE. Since the verification message 650 V from the Responder is optional, the Initiator indicates in the HDR 651 whether it requires a verification message or not from the Responder. 652 The verification message, V, is a MAC computed over the Responder's 653 entire message, the timestamp (the same as the one that was included 654 in the Initiator's message), and the two parties identities, using 655 the authentication key. See [RFC3830] Section 5.2 for the exact 656 definition of the Verification MAC calculation and [RFC3830] Section 657 6.9 for payload definition. 659 The Initiator message SHALL indicate that the Responder message is 660 not required when a Requestor message has been used to initiate the 661 key exchange. In that case mutual authentication will be provided 662 through the Initiator message sent in response to the triggering 663 Requestor message. 665 Where the key assignment is triggered by the AMIKEY Requestor 666 message, the timestamp, T, of the Initiator message shall be the same 667 as the one that was included in the Requestor's message. The CS ID 668 map info of the Requestor message HDR will specify the requested 669 protocol key(s) to be assigned (see Section 6.1). 671 For AMIKEY the pre-shared key method is mandatory to implement. 673 3.2. Public-Key Encryption 675 For the public-key encryption method, the signaling exchange and 676 message content is similar to that of the PSK case as shown in 677 Figure 6 below: 679 Requestor 681 Q_MESSAGE = 682 [<---] HDR, T, [IDq|CERTq], SIGNq 684 Initiator Responder 686 I_MESSAGE = 687 HDR, T, RAND, [IDi|CERTi], 688 [IDr], (SP), KEMAC, 689 [CHASH], PKE, SIGNi ---> 690 R_MESSAGE = 691 [<---] HDR, T, [IDr], V 693 Figure 6: Signaling exchange and message content for the PK method 695 The AMIKEY public key Requestor message follows the standard MIKEY 696 format. Beyond the header (HDR) and Timestamp (T) information 697 elements, the message may include the Identity or Certificate of the 698 Requestor [IDq|CERTq] and a message Signature, SIGNq. The SIGNq is a 699 signature covering the entire Requestor's AMIKEY message, Q_MESSAGE, 700 using the Requestor's (private) signature key (see Section 5.2 701 [RFC3830] for the exact definition of the Signature calculation). 702 The message SHALL be sent in cleartext, authenticated by the 703 signature. 705 The Requestor IDq and certificate SHOULD be included, but the CERTq 706 MAY be left out when it can be expected that the peer can obtain the 707 certificate in some other manner from the Requestor ID. The ID may 708 be left out when it can be expected that the peer already knows the 709 other party's ID. 711 The Initiator's message securely transports one or more TGKs and a 712 set of security parameters to the Responder. This is done using an 713 envelope approach where the TGKs are encrypted (and integrity 714 protected) with keys derived from a randomly/pseudo-randomly chosen 715 "envelope key". The envelope key is sent to the Responder encrypted 716 with the public key of the Responder. 718 Where the key assignment is triggered by the Requestor message, the 719 timestamp, T, of the Initiator message shall be the same as the one 720 that was included in the Requestor's message. As for the PSK method, 721 the CS ID map info of the Requestor message HDR will specify the 722 requested protocol key(s) to be assigned (see Section 6.1). 724 The Responder message MAY be sent in response to a key assignment 725 initiated by the Initiator I_MESSAGE. The indication of the 726 requirement to send the Responder verification message V as well as 727 its calculation shall be the same as in the pre-shared key mode. The 728 timestamp in a Responder message will be the same as the one that was 729 included in the Initiator message. 731 The Initiator message SHALL indicate that the Responder message is 732 not required when a Requestor message has been used to initiate the 733 key exchange. 735 For AMIKEY the public key method is mandatory to implement. 737 3.3. [RFC3830] Diffie-Hellman Key Exchange 739 For the Diffie-Hellman key exchange method, the peer-to-peer 740 association in which both devices contribute equally to the key 741 generation will be the same as given in [RFC3830] even with a key 742 client-server network infrastructure. 744 For AMIKEY this method is optional to implement. 746 3.4. Example of AMIKEY Applied to RPL 748 The following sub-sections provide examples of how AMIKEY can be used 749 to support key management for the RPL routing protocol [RFC6550]. 751 3.4.1. AMIKEY Key Assignment for RPL Join Process 753 The process of a node joining a secured RPL instance is described in 754 Section 10.2 of the RPL specification [RFC6550]. Where the DODAG 755 operates in "authenticated mode", as indicated by the "A" bit being 756 set in the DODAG Configuration option of the DIO messages, a joining 757 node is required to access a key server to obtain the current key for 758 securing RPL messages. AMIKEY is intended to support the 759 requirements of the key management protocol that allows RPL nodes to 760 be able to obtain (and receive) the dynamic DODAG security key (see 761 Section 3.2.3 of [RFC6550]). For AMIKEY, the security of the key 762 management protocol exchanges between the nodes and the key server 763 may be based on a pre-shared key (PSK), public key (PKE) or Diffie- 764 Hellman (DH) method as described in Section 3. 766 Figure 7 illustrates how AMIKEY may be employed to obtain the DODAG 767 security key. The figure depicts how the joining node uses AMIKEY to 768 request the DODAG key when a pre-shared key is used for securing the 769 key management exchange with the key server. 771 Joining Node RPL Router Key Server 772 | | | 773 | 1. Secure DIS (KI=0) | | 774 |----------------------------->| | 775 | | | 776 | 2. Secure DIO (KI=0,"A"bit set) | 777 |<-----------------------------| | 778 | | | 779 | | 780 | 3. AMIKEY: Q_MESSAGE (HDR, T, IDq, V) | 781 |========================================================>| 782 | 4. AMIKEY: I_MESSAGE (HDR, T, RAND, IDi, {SP}, KEMAC) | 783 |<========================================================| 784 | | 785 | 786 | 5. Secure DIS (KI=n) | 787 |----------------------------->| 788 | | 789 | 6. Secure DIO (KI=n) | 790 |<-----------------------------| 791 | | 793 Figure 7: Key Assignment with AMIKEY in the RPL Join Process 795 1. A joining node broadcasts a RPL Secure DIS message to request DIO 796 information for joining the DODAG. The DIS message is secured 797 using the pre-installed key (see [RFC6550], Section 3.2.3). The 798 secure DIS message security header includes the Key Index, KI=0, 799 that references the pre-installed key used to secure the message. 801 2. An existing DODAG RPL node responds with a secure DIO message 802 that is similarly secured with the pre-installed key, even where 803 that key differs from the DODAG RPL security key being used by 804 nodes that have joined the DODAG (see [RFC6550], Section 10.2). 805 This initial DIS/DIO exchange allows the joining node to operate 806 as a leaf node and forward data traffic into the network without 807 being part of the secure routing exchange. 809 3. Based on the A-bit being set within the Secure DIO message, the 810 joining node uses its leaf node network access to initiate the 811 key request to the key server to request the current DODAG 812 security key; the joining node does this by sending an AMIKEY key 813 request (Q_MESSAGE) to the key server (see Section 3). In the 814 example in Figure 7 the Q_MESSAGE is secured based on the pre- 815 shared key maintained between the joining node and the key 816 server. The verification field (V) authenticates the message 817 sent by the requesting node (see Section 4.2.4). 819 4. The key server responds to the request by assigning the current 820 DODAG key within the I_MESSAGE (see Section 3.1). Like the 821 Q_MESSAGE, the I_MESSAGE is secured based on the pre-shared key 822 maintained between the joining node and the key server. The T 823 field included in the I_MESSAGE is the same as that sent by the 824 key requesting node in the Q_MESSAGE. This field in the form of 825 a timestamp or counter allows for replay protection (and 826 timeliness verification if network-wide time is supported in the 827 DODAG). The KEMAC information element includes the DODAG key 828 material assigned by the key server encrypted using the pre- 829 shared key maintained between the joining node and the key 830 server. 832 5. The assigned DODAG key (given by Key Index=n in the message 833 security header) is used to secure the subsequent secure DIS 834 message. 836 6. Once the secure DIS message is authenticated by the receiver a 837 secure DIO message (with KI=n) is returned. That message 838 provides current DODAG routing information and allows the joining 839 node to be a full RPL participant of the secure DODAG. 841 The particular information elements of the AMIKEY Q_MESSAGE include: 843 HDR Header (common AMIKEY header) 845 T Timestamp/counter 847 IDq ID of the requestor (joining node) 849 V Message verification 851 The particular information elements of the AMIKEY I_MESSAGE include: 853 HDR Header 855 T Timestamp/counter 857 RAND A (pseudo-)random bit-string used for generating the DODAG 858 security key (using AMIKEY, the RPL DODAG key is generated from 859 the key assigned by the key server) 861 IDi ID of the assignment initiator (key server) 863 SP Security Policy that defines the policy information of the 864 secure RPL protocol for which the key assignment is being made 866 KEMAC Key data transport payload that includes the assigned key 867 generating key from which the RPL DODAG security key is derived 869 Note: In conjunction with RPL, AMIKEY can also be applied to support 870 proactive key assignment/update by the key server using an I_MESSAGE 871 and R_MESSAGE exchange as discussed in Section 3. 873 3.4.2. AMIKEY Key Update for RPL Authenticated Mode 875 The RPL security key for a DODAG operating in authenticated mode may 876 be updated one or more times during the lifetime of the DODAG. Such 877 key updates are initiated by the key server and pushed to individual 878 RPL nodes using the AMIKEY protocol. 880 Figure 8 illustrates how AMIKEY is employed for the key update. The 881 scenario assumes a pre-shared key (PSK) for securing the key 882 management exchange between the RPL nodes and the key server. Public 883 key encryption (PKE) or Diffie-Hellman (DH) methods may also be used 884 as described in Section 3. 886 RPL Node i RPL Node j Key Server 887 | | | 888 | 1. Secure DIO | | 889 | (KI=n,"A"bit set) | | 890 |------------------------->| | 891 | | | 892 | 2. Secure DAO (KI=n) | | 893 |<-------------------------| | 894 | | | 895 | 3. Secure DAO ACK (KI=n) | | 896 |------------------------->| | 897 ~ ~ | 898 ~ ~ | 899 | | 900 | 4a. AMIKEY: I_MESSAGE (HDR,T,RAND,IDi,{SP},KEMAC) | 901 |<===========================================================| 902 | | 903 | 5a. AMIKEY: R_MESSAGE (HDR,T,IDr V) | 904 |===========================================================>| 905 | | 906 | | 4b. AMIKEY: I_MESSAGE | 907 | | (HDR,T,RAND,IDi,{SP},KEMAC) | 908 | |<================================| 909 | | 5b. AMIKEY: R_MESSAGE | 910 | | (HDR,T,IDr V) | 911 | |================================>| 912 ~ ~ 913 ~ ~ 914 | | 915 | 6. Secure DIO | 916 | (KI=n+1,"A"bit set) | 917 |------------------------->| 918 | | 919 | 7. Secure DAO (KI=n+1) | 920 |<-------------------------| 921 | | 922 | 8. Secure DAO ACK | 923 | (KI=n+1) | 924 |------------------------->| 925 | | 927 Figure 8: Key Update during RPL Operation Using AMIKEY 929 1. An operating RPL node (Node i) transmits a Secure DIO message 930 providing information on its DODAG routing connectivity. The DIO 931 message is secured using the current DODAG security key indicated 932 by the inclusion of the Key Index, KI=n, within the message 933 security header. 935 2. In response to the DIO message the RPL routing peer (Node j) 936 sends a Secure DAO message to establish/maintain its routing 937 connectivity. The DAO message is secured with the current DODAG 938 security key indicated by the inclusion of KI=n within the 939 message security header. 941 3. The RPL node receiving the DAO message may acknowledge receipt of 942 the message by sending a Secure DAO ACK message, also secured by 943 the current DODAG key. 945 4. The key server can choose at any time to update the current DODAG 946 key by making a new key assignment to each network node. The new 947 key is encrypted within the KEMAC information element of the 948 I_MESSAGE (see Section 3.1). In this example the I_MESSAGE is 949 secured based on the pre-shared key maintained between each node 950 and the key server. The T field included in the I_MESSAGE, in 951 the form of a timestamp or counter allows for replay protection 952 (and timeliness verification if network-wide time is supported). 954 5. The key assignment is acknowledged by the receiving node through 955 the sending of the R_MESSAGE (see Section 3). The requirement 956 for the sending of the R_MESSAGE is specified through the setting 957 of the V-bit flag in the I_MESSAGE Header (HDR). For replay 958 protection and timeliness verification on the part of the key 959 server, the T field included in the R_MESSAGE, is copied and 960 repeated from the I_MESSAGE. The verification field (V) 961 authenticates the message sent by the responding node using the 962 node-key server pre-shared secret. 964 6. The updated DODAG key, indicated by the Key Index=n+1 in the 965 message security header, is used to secure the subsequent 966 transmitted Secure DIO messages. 968 7. Following the key update the Secure DAO messages also use the 969 newly assigned key (indicated by KI=n+1 in the message security 970 header). 972 8. Any Secure DAO ACK messages are similarly protected using the 973 newly assigned key. 975 The particular information elements of the AMIKEY I_MESSAGE include: 977 HDR Header (common AMIKEY header) 979 T Timestamp/counter 981 RAND A (pseudo-)random bit-string used for generating the DODAG 982 security key (using AMIKEY, the RPL DODAG key is generated from 983 the key assigned by the key server). 985 IDi ID of the assignment initiator (key server) 987 SP Security Policy that defines the policy information of the 988 secure RPL protocol for which the key assignment is being made 990 KEMAC Key data transport payload that includes the assigned key 991 generating key from which the RPL DODAG security key is derived 993 The particular information elements of the AMIKEY R_MESSAGE include: 995 HDR Header 997 T Timestamp/counter 999 IDr ID of the responder (RPL node) 1001 V Message verification 1003 Note: In an ad hoc network there is the potential for nodes that have 1004 received a DODAG key update to initiate routing exchanges with nodes 1005 that have not yet received the update. This situation will be 1006 detected by the mis-match between the node's maintained DODAG key 1007 index and that of its corresponding peer. Where a received RPL 1008 message is secured by a key different from that maintained by the 1009 recipient node it will not be possible to verify the authenticity or 1010 validity of the message. To avoid potential denial of service 1011 attacks from forged or purported Secure RPL messages, a RPL node 1012 should silently discard such messages if it has not received an 1013 updated key. One consequence is the potential for broken RPL 1014 associations when the key update is not sufficiently synchronized 1015 across the DODAG. A key activation time can be used to limit the 1016 potential for such routing disruptions during the key update. The 1017 Key Activation time in the form of a UTC clock time or future count 1018 can be specified through the AMIKEY Key Validity information element 1019 (see [RFC3830] Key data sub-payload, Section 6.13). 1021 A node recovering from reset and receiving Secure DIO messages with a 1022 Key Index different from the one currently maintained can revert its 1023 status to a non-routing (leaf) node. The node can then initiate an 1024 AMIKEY key request to the key server to obtain the current DODAG key. 1026 4. [RFC3830] Selected Key Management Functions 1028 For AMIKEY all the key derivation functionality defined in MIKEY 1029 shall be based on a new default Pseudo-Random Function (PRF) given by 1030 the AES-based, AES-CMAC algorithm as specified in [RFC4493]. 1032 4.1. [RFC3830] Key Calculation 1034 4.1.1. [RFC3830] Assumptions 1036 For AMIKEY cs_id is defined so that session represents a protocol 1037 layer, logical device interface, or communications association. The 1038 cs-id values shall be as defined in this specification (see 1039 Section 6.1.2) and may be public or private/vendor-specific. 1041 4.1.2. Default PRF Description 1043 For AMIKEY the default pseudo random function shall be AES-CMAC 1044 [RFC4493]. Note: AES-CMAC aligns with HMAC-SHA1 and HMAC-MD5 as 1045 PRFs. 1047 4.1.3. [RFC3830] Generating Keys from TGK 1049 For AMIKEY the cs-id values shall be as defined in this specification 1050 (see Section 6.1.2). 1052 4.1.4. [RFC3830] Generating Keys for MIKEY Messages from an Envelope/ 1053 Pre-shared Key 1055 Change from default PRF to the default AMIKEY PRF given in 1056 Section 4.1.2 of this specification. 1058 Note: For AMIKEY, the Authentication key constant SHALL be used for 1059 generating the single TEK in the case of authenticated encryption 1060 algorithms (such as AES-CCM). 1062 4.2. [RFC3830] Pre-defined Transforms and Timestamp Formats 1064 4.2.1. Hash Functions 1066 For AMIKEY the default hash function shall be AES-CMAC [RFC4493]. 1068 4.2.2. Pseudo-Random Number Generator 1070 For AMIKEY it shall be MANDATORY to implement the new default AES- 1071 CMAC PRF specified in [RFC4493] (See Section 4.1.2 of this 1072 specification). 1074 4.2.3. [RFC3830] Key Data Transport Encryption 1076 As in MIKEY the default and mandatory-to-implement key transport 1077 encryption shall be AES in Counter mode using a 128-bit key (derived 1078 as defined in Section 4.1.4 above). The applied Counter shall be the 1079 IV defined in [RFC3830], Section 4.2.3. 1081 4.2.4. [RFC3830] MAC Verification Message Function 1083 For AMIKEY AES-CCM-64 shall be the defined default for key message 1084 authentication. The Counter used shall be the IV defined in 1085 [RFC3830], Section 4.2.3. 1087 4.3. [RFC3830] Certificates, Policies and Authorization 1089 4.4. [RFC3830] Retrieving the Data SA 1091 For AMIKEY the retrieval of a Data SA will depend on the security 1092 protocol. The support for different security protocols shall be 1093 explicitly identified through the use of public CS ID values (see 1094 Section 6.1.2 of this specification). 1096 5. [RFC3830] Behavior and Message Handling 1098 5.1. [RFC3830] General 1100 5.2. [RFC3830] Creating a message 1102 For AMIKEY where the key exchange is triggered by a Requestor, the 1103 messages from the Requestor MUST use a unique timestamp. The 1104 Initiator does not create a new timestamp but uses the timestamp used 1105 by the Requestor. 1107 When the key exchange is not triggered by a Requestor, the messages 1108 from the Initiator MUST use a unique timestamp. The Responder does 1109 not create a new timestamp, but uses the timestamp used by the 1110 Initiator. 1112 6. [RFC3830] Payload Encoding 1114 The generic LLN security protocol parameters may be transported 1115 between peers as part of a key establishment or re-keying exchange. 1116 Based on IANA registration, MIKEY currently only defines two payloads 1117 for transporting the security policy information (see Section 6.10 of 1118 [RFC3830] and [RFC4442]). This section describes the extension of 1119 MIKEY to allow the transport of Generic LLN security policy 1120 information and associated key(s) as well as applicable PRF used for 1121 key derivation. 1123 This section describes, in detail, the payload for support of the 1124 Generic LLN security protocol(s) specified by the Adapted MIKEY 1125 protocol. As in RFC3830, for all encoding, network byte order is 1126 always used, and the sign ~ indicates a variable length field. 1128 6.1. [RFC3830] Common Header Payload (HDR) 1130 The Common Header payload MUST always be present as the first payload 1131 in each message. The Common Header includes a general description of 1132 the exchange message. 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 ! version ! data type ! next payload !V! PRF func ! 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 ! CSB ID ! 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 ! #CS ! CS ID map type! CS ID map info ~ 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Figure 9: Common Header [RFC3830] 1146 o version (8 bits): the version number of MIKEY. 1148 o version = 0x01 refers to MIKEY as defined and maintained in 1149 [RFC3830]. 1151 o version = 0x03 (to be assigned by IANA) shall be used to refer to 1152 AMIKEY as defined and maintained in this document. 1154 o data type (8 bits): describes the type of message (e.g., public- 1155 key transport message, verification message, error message). See 1156 latest IANA registered values. For AMIKEY new data type values 1157 are used to specify the additional PSK and PK method Requestor 1158 messages (to be assigned by IANA). 1160 +-------------+-------+---------------------------------------------+ 1161 | Data Type | Value | Comment | 1162 +-------------+-------+---------------------------------------------+ 1163 | PSK Request | i | Requestor's pre-shared key message (AMIKEY) | 1164 | PK Request | j | Requestor's public key message (AMIKEY) | 1165 +-------------+-------+---------------------------------------------+ 1167 Table 6.1.a 1169 o next payload (8 bits): identifies the payload that is added after 1170 this payload. See latest IANA registered values. 1172 For AMIKEY a new next payload value is assigned to carry the Key 1173 Index parameter (see also Section 6.16). 1175 +----------+-------+------------------------------------------------+ 1176 | Next | Value | Section | 1177 | Payload | | | 1178 +----------+-------+------------------------------------------------+ 1179 | Last | 0 | - | 1180 | payload | | | 1181 | ... | | | 1182 | Key | n | Section 6.16 as given by the AMIKEY | 1183 | Index | | specification (value to be assigned by IANA). | 1184 | Key | m | Section 6.17 as given by the AMIKEY | 1185 | Source | | specification (value to be assigned by IANA) | 1186 | ID | | | 1187 +----------+-------+------------------------------------------------+ 1189 Table 6.1.b 1191 o V (1 bit): flag to indicate whether a verification message is 1192 expected or not (this only has meaning when it is set by the 1193 Initiator). 1195 o PRF func (7 bits): indicates the PRF function that has been/will 1196 be used for key derivation; for AMIKEY a new value, 2, has been 1197 specified to indicate the PRF that must be supported for LLNs. 1199 +-----------+-------+-----------------------------------------------+ 1200 | PRF | Value | Comments | 1201 | Function | | | 1202 +-----------+-------+-----------------------------------------------+ 1203 | AES-CMAC | 2 | As specified in [RFC4493] and that shall be | 1204 | | | mandatory for AMIKEY | 1205 +-----------+-------+-----------------------------------------------+ 1207 Table 6.1.c 1209 (AMIKEY value to be assigned by IANA) 1211 o CSB ID (32 bits): identifies the CSB (generated as specified in 1212 [RFC3830]); for AMIKEY this field is used as a message reference 1213 identifier to allow for duplicate detection where message 1214 exchanges occur over an unreliable transport network. 1216 o #CS (8 bits): indicates the number of Crypto Sessions that will be 1217 handled within the CBS; for AMIKEY this field indicates the number 1218 of protocol layers, logical device interfaces, or other 1219 communications associations that are being configured or managed 1220 within the current key management message exchange. 1222 o CS ID map type (8 bits): specifies the method of uniquely mapping. 1223 Crypto Sessions to the security protocol sessions; for AMIKEY a 1224 new value, 3, has been specified to indicate the Generic-LLN map 1225 type that must be supported for LLNs. 1227 +----------------+-------+------------------------------------------+ 1228 | CS ID Map Type | Value | Comments | 1229 +----------------+-------+------------------------------------------+ 1230 | Generic_LLN-ID | 3 | As specified in this document and as | 1231 | | | mandatory for AMIKEY | 1232 +----------------+-------+------------------------------------------+ 1234 Table 6.1.d 1236 (AMIKEY value to be assigned by IANA) 1238 o CS ID map info (variable length): identifies the crypto session(s) 1239 for which the SA should be created. For AMIKEY the GENERIC_LLN 1240 map type (defined in Section 6.1.2 below) is used to specify the 1241 security association for the individual protocol layers, logical 1242 device interfaces, or other communications associations for which 1243 key management is being provided. 1245 6.1.1. [RFC3830] SRTP ID 1247 6.1.2. The Generic_LLN-ID Map Type 1249 For the Generic_LLN map type, the CS ID map info consists of #CS (see 1250 Section 6.1) number of blocks or segments, where each segment maps 1251 policies (and a key) to a specific protocol layer, logical device 1252 interface or other communications association security protocol. 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 ! CS ID ! #P ! Ps (OPTIONAL) ~ 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 Figure 10: Generic_LLN-ID Map Type 1262 o CS ID (8 bits): specifies the CS ID used to identify a given 1263 security protocol; for AMIKEY, when used in conjunction with the 1264 Generic-LLN map type, values 0-127 shall be reserved for 1265 assignment (by IANA) to specific protocol layer, logical device 1266 interface, or other communications association security protocols 1267 while values 128-255 shall be Reserved for Private Use. 1269 Note: A combination of public and private CS IDs can be specified 1270 within a given CSB when combined key management is being applied. 1272 The following values are currently specified in this document (for 1273 example, with values to be assigned by IANA): 1275 +---------------------------+---------+--------------------------+ 1276 | CS ID | Value | Comments | 1277 +---------------------------+---------+--------------------------+ 1278 | Reserved | 0 | | 1279 | Generic PHY Layer | 1 | | 1280 | Generic Link Layer | 2 | | 1281 | Generic Network Layer | 3 | | 1282 | Generic Transport Layer | 4 | | 1283 | Generic Application Layer | 7 | | 1284 | RPL Protocol | 20 | | 1285 | ... | | | 1286 | Reserved values | 128-255 | Reserved for private use | 1287 +---------------------------+---------+--------------------------+ 1289 Table 6.1.e 1291 o #P (8 bits): indicates the number of security policies provided 1292 for the crypto session (given by the CS ID) for which key 1293 management is being provided. In response messages, #P SHALL 1294 always be exactly 1. So if #P = 0 in an initial message, a 1295 security profile MUST be provided in the response message. If #P 1296 > 0, one of the suggested policies SHOULD be chosen in the 1297 response message. If needed, the suggested policies MAY be 1298 changed. 1300 o Ps (variable length): lists the policies for the crypto session 1301 for which key management is being provided. It SHALL contain 1302 exactly #P policies, each having the specified Prot type (see 1303 Section 6.10. 1305 0 1 2 3 1306 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 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 ! Policy_no_i ! Policy_no_n ! ... ! Policy_no_#P ! 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 Figure 11: Policies 1313 o Policy_no_i (8 bits): a policy_no that corresponds to the 1314 policy_no of a SP payload. In response messages, the policy_no 1315 may refer to a SP payload in the initial message. The policy 1316 numbers should be listed in increasing order. 1318 6.2. [RFC3830] Key Data Transport Payload (KEMAC) 1320 This section shall apply entirely as specified for MIKEY in [RFC3830] 1321 with the addition of the specific message authentication code 1322 algorithms given below for AMIKEY. 1324 o MAC alg (8 bits): specifies the authentication algorithm used. 1326 +------------------+-------+----------------------------+-----------+ 1327 | MAC alg | Value | Comments | Length | 1328 | | | | (bits) | 1329 +------------------+-------+----------------------------+-----------+ 1330 | NULL | 0 | restricted usage | 0 | 1331 | | | [RFC3830], Section 4.2.4 | | 1332 | HMAC-SHA-1-160 | 1 | Mandatory, [RFC3830], | 160 | 1333 | | | Section 4.2.4 | | 1334 | HMAC-SHA-256-256 | 2 | Mandatory, [RFC3830], | 256 | 1335 | | | Section 4.2.4 | | 1336 | AES-CBC-MAC-32 | 3 | Mandatory for AMIKEY, see | 32 | 1337 | | | Section 4.2.4 | | 1338 | AES-CBC-MAC-64 | 4 | Mandatory for AMIKEY, see | 64 | 1339 | | | Section 4.2.4 | | 1340 | AES-CBC-MAC-128 | 5 | Mandatory for AMIKEY, see | 128 | 1341 | | | Section 4.2.4 | | 1342 +------------------+-------+----------------------------+-----------+ 1344 Table 6.2.b 1346 (Values for AMIKEY to be assigned by IANA) 1348 o MAC (variable length): the message authentication code of the 1349 entire message. 1351 For AMIKEY the use of AES-CBC-MAC-n may be applied in conjunction 1352 with the AES-CM encryption as given by the Encr alg field. This 1353 authenticated encryption shall be applied using an AES-CCM-n 1354 implementation. 1356 6.3. [RFC3830] Envelope Data Payload (PKE) 1358 6.4. [RFC3830] DH Data Payload (DH) 1360 6.5. [RFC3830] Signature Payload (SIGN) 1362 6.6. [RFC3830] Timestamp Payload (T) 1364 6.7. ID Payload (ID) 1366 For AMIKEY the range of ID types shall be extended to allow for an 1367 expanded array of communications protocol entities that may be key 1368 management participants. The IDs are carried within the key 1369 management message ID payload field with the TLV format as specified 1370 in [RFC3830], Section 6.7. 1372 +--------------------+-------+-------------------------+ 1373 | ID Type | Value | Comments | 1374 +--------------------+-------+-------------------------+ 1375 | IPv6 Address | 4 | As specified for AMIKEY | 1376 | Device MAC Address | 5 | As specified for AMIKEY | 1377 | Other (TBD) | n | As specified for AMIKEY | 1378 +--------------------+-------+-------------------------+ 1380 Table 6.7.a 1382 The IPv6 Address ID type is used to allow an IPv6 Address to be 1383 referenced as the unique entity identifier of the key management 1384 correspondents. To directly reference the IPv6 Address of the 1385 exchanged packets, the ID len value will be set to zero and no ID 1386 data included in the value field (see [RFC3830]). 1388 The Device MAC Address is used to allow an IEEE 48-bit MAC address to 1389 be referenced as the unique entity identifier for correspondents in a 1390 key management exchange. To directly reference the MAC Address of 1391 the exchanged packets, where the IPv6 address has been derived from 1392 the device MAC address in conformance with [RFC4291] the ID len value 1393 will be set to zero and no ID data included in the value field (see 1395 [RFC3830]). 1397 Note: The ID payload may be used by a supported security protocol as 1398 implicit Key Source Identifier (see Section 6.17) for referencing key 1399 origination. 1401 6.8. [RFC3830] Cert Hash Payload (CHASH) 1403 6.9. [RFC3830] Ver msg payload (V) 1405 6.10. Security Policy (SP) Payload 1407 The Security Policy payload defines a set of policies that apply to a 1408 specific security protocol. 1410 For AMIKEY the definition is based on the same security policy 1411 payload definition in [RFC3830], Section 6.10, with a new security 1412 protocol (Generic-LLN) as defined below. 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 ! Next payload ! Policy no ! Prot type ! Policy param ~ 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 ~ length (cont) ! Policy param ~ 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 o Next payload (8 bits): Identifies the payload that is added after 1423 this payload. See Section 6.1 of [RFC3830] for more details. 1425 o Policy no (8 bits): Each security policy payload must be given a 1426 distinct number for the current MIKEY session by the local peer. 1427 This number is used to map a cryptographic session to a specific 1428 policy (see also Section 6.1.1 of [RFC3830]). 1430 o Prot type (8 bits): This value defines the security protocol; For 1431 AMIKEY an additional value shall be assigned as given below. 1433 +-------------+-------+-------------------------+ 1434 | Prot Type | Value | Comments | 1435 +-------------+-------+-------------------------+ 1436 | Generic_LLN | 3 | As specified for AMIKEY | 1437 +-------------+-------+-------------------------+ 1439 Table 6.10 1441 o Policy param length (16 bits): This field defines the total length 1442 of the policy parameters for the selected security protocol. 1444 o Policy param (variable length): This field defines the policy for 1445 the specific security protocol. The Policy param part is built up 1446 by a set of Type/Length/Value (TLV) payloads. For each security 1447 protocol, a set of possible type/value pairs can be negotiated as 1448 defined. 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 ! Type ! Length ! Value ~ 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 12: Policy Parameter 1458 o Type (8 bits): Specifies the type of the parameter. 1460 o Length (8 bits): Specifies the length of the Value field (in 1461 bytes). 1463 o Value (variable length): Specifies the value of the parameter. 1465 6.10.1. [RFC3830] SRTP Policy 1467 6.10.2. AMIKEY Generic_LLN Policy 1469 This policy specifies the parameters for the Generic_LLN (G_LLN) 1470 protocol for which key management is being provided. The types/ 1471 values that can be negotiated are defined by the following table for 1472 the known, assigned CS ID values. For Vendor-specific, private CS ID 1473 values the applicable policy specification for a given crypto session 1474 will be left to the communicating parties. 1476 +------+---------------------------+------------------------+ 1477 | Type | Meaning | Possible Values | 1478 +------+---------------------------+------------------------+ 1479 | 0 | Encryption algorithm | See below | 1480 | 1 | Encryption key length | Depends on cipher used | 1481 | 2 | Authentication algorithm | See below | 1482 | 3 | Authentication key length | Depends on MAC used | 1483 | 4 | Generic LLN PRF | See below | 1484 | 5 | Encryption off/on | 0 if off, 1 if on | 1485 +------+---------------------------+------------------------+ 1487 Table 6.10.2.a 1489 For the Encryption algorithm, a one byte length is sufficient. For 1490 AMIKEY the currently defined possible Values are: 1492 +----------------+-------+ 1493 | G_LLN encr alg | Value | 1494 +----------------+-------+ 1495 | NULL | 0 | 1496 | AES-CM-128 | 1 | 1497 +----------------+-------+ 1499 Table 6.10.2.b 1501 For the Authentication algorithm, a one byte length is sufficient. 1502 For AMIKEY the currently defined possible Values are: 1504 +-----------------+-------+-------------------------------------+ 1505 | G_LLN auth alg | Value | Comments | 1506 +-----------------+-------+-------------------------------------+ 1507 | NULL | 0 | Not recommended for operational use | 1508 | AES-CBC-MAC-32 | 1 | | 1509 | AES-CBC-MAC-64 | 2 | | 1510 | AES-CBC-MAC-128 | 3 | | 1511 | RSA-SHA-256 Sig | 4 | | 1512 +-----------------+-------+-------------------------------------+ 1514 Table 6.10.2.c 1516 Note: Since authentication is mandatory for operational protocol 1517 security, where Encryption is set "on" by the Generic_LLN policy, 1518 authenticated encryption, AES-CCM-n, with the MAC size given by the 1519 selected authentication algorithm, or AES-CM with authentication 1520 given by the identified Signature algorithm, shall be applied. 1522 For the Generic_LLN pseudo-random function, a one byte length is also 1523 sufficient. For AMIKEY the currently defined possible Values are: 1525 +-----------------+-------+ 1526 | Generic_LLN PRF | Value | 1527 +-----------------+-------+ 1528 | AES-CMAC | 0 | 1529 +-----------------+-------+ 1531 Table 6.10.2.d 1533 6.11. [RFC3830] RAND Payload (RAND) 1535 6.12. [RFC3830] Error Payload (ERR) 1537 6.13. [RFC3830] Key Data Sub-Payload 1539 For AMIKEY, the key validity (KV) period for a TGK/TEK shall be 1540 specified using the KV Interval type indicating a potential key start 1541 and expiration time (see Section 6.14). 1543 6.14. [RFC3830] Key Validity Data 1545 For AMIKEY the Key Validity Data element shall be used to specify the 1546 activation time and validity period of an assigned TGK. 1548 For AMIKEY, the key validity (KV) period for a TGK/TEK shall be 1549 specified using the KV Interval type (see [RFC3830] Section 6.13). 1551 The corresponding Valid From (VF) and Valid To (VT) information 1552 elements that define the applicable key lifetime may be specified 1553 using the Timestamp Counter type to specify time in seconds from the 1554 time given by included key message timestamp (T). A VF Length of 1555 zero (indicating Counter value of 0) specifies an immediate key 1556 activation time. A VT Counter value of all 1s indicates infinite key 1557 validity or no expiration time. 1559 6.15. [RFC3830] General Extension Payload 1561 6.16. Key Index Payload 1563 For AMIKEY the Key Index (KI) payload is used to specify the value of 1564 the key index associated with a given TGK. 1566 0 1 2 3 1567 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 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 ! Next Payload ! KI len ! KI value (variable) ~ 1570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 Figure 13: Key Index 1574 o Next payload (8 bits): identifies the payload that is added after 1575 this payload. See Section 6.1 [RFC3830] for values. 1577 o KI len (8 bits): indicates the length of the key source identifier 1578 field. 1580 o KI value (variable length): indicates the value of the key index 1581 to be assigned to any CS TEK generated from the transported TGK. 1583 6.17. Key Source Identifier Payload 1585 For AMIKEY, where an explicit reference is required, the Key Source 1586 Identifier payload is used to provide a logical reference to the 1587 entity associated with the origination of a given TGK. The 1588 specification of the Key Source Identifier (KSI) shall be given by 1589 the supported security protocol (for example, the secured RPL routing 1590 protocol [RFC6550] specifies the use of an 8-byte KSI). 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 ! Next Payload ! KSI len ! KSI value (variable) ~ 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 Figure 14: Key Source Identifier 1600 o Next payload (8 bits): identifies the payload that is added after 1601 this payload. See Section 6.1 [RFC3830] for values. 1603 o KSI len (8 bits): indicates the length of the key source 1604 identifier field. 1606 o KSI value (variable length): specifies the logical identifier 1607 assigned to the Source or Originator of a given TGK. 1609 7. [RFC3830] Transport Protocols 1611 As in [RFC3830], AMIKEY may be integrated within session 1612 establishment or other system signaling protocols or may be directly 1613 transported over UDP or TCP. Where AMIKEY messages are integrated 1614 into other LLN-related signaling protocols its transport shall be 1615 defined as part of those protocols. 1617 8. Security Considerations 1619 A primary motivation for this RFC is the security that comes from a 1620 re-use of the key management methods and framework developed for 1621 MIKEY. The extensive deployment and on-going development provides 1622 the benefit of much wider vetting and validation essential to 1623 assuring greater security. 1625 9. [RFC3830] Groups 1627 10. Additional Specification Considerations 1629 Work had been previously initiated in developing support for an ECC- 1630 based asymmetric key management method ([I-D.ietf-msec-mikey-ecc], 1631 expired). In the context of LLNs application and subject to IPR 1632 considerations, related AMIKEY requirements may be developed. 1634 11. IANA Considerations 1636 This document defines several new name spaces associated with the 1637 AMIKEY payloads. This section summarizes the name spaces for which 1638 IANA is requested to manage the allocation of values. IANA is 1639 requested to record the pre-defined values defined in the given 1640 sections for each name space. IANA is also requested to manage the 1641 definition of additional values in the future. Unless explicitly 1642 stated otherwise, values in the range 0-240 for each name space 1643 SHOULD be approved by the process of IETF consensus and values in the 1644 range 241-255 are reserved for Private Use, according to [RFC5226]. 1646 The name spaces for the new fields identified in this document are 1647 requested to be managed by IANA (in bracket is the reference to the 1648 table with the initially registered values): 1650 o Common Header payload (6.1.) 1651 * Version 1653 o Data type (6.1.a) 1655 * AMIKEY PSK Request msg 1657 * AMIKEY PK Request msg 1659 o Next payload (6.1.b) 1661 * Key index 1663 * Key source identifier 1665 o Prf func (6.1.c) 1667 * AES-CMAC 1669 o CS ID map type (6.1.d) 1671 * Generic_LLN-ID 1673 o MAC alg (6.2.b) 1675 * AES-CBC-MAC-32 1677 * AES-CBC-MAC-64 1679 * AES-CBC-MAC-128 1681 o ID payload (6.7.a) 1683 * IPv6 Address 1685 * Device MAC Address 1687 o Proto type (6.10) 1689 * Generic_LLN 1691 o Generic_LLN policy (6.10.2) 1693 * Policy parameters (6.10.2.a) 1695 * G_LLN encr alg (6.10.2.b) 1697 * G_LLN auth alg (6.10.2.c) 1698 * G_LLN prf (6.10.2.d) 1700 12. Acknowledgments 1702 The authors would like to acknowledge the review and comments from 1703 Rene Struik and Stephen Farrell. 1705 13. References 1707 13.1. Normative References 1709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1710 Requirement Levels", BCP 14, RFC 2119, March 1997. 1712 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1713 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1714 August 2004. 1716 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1717 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1718 May 2008. 1720 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1721 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1722 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1723 Lossy Networks", RFC 6550, March 2012. 1725 13.2. Informative References 1727 [I-D.ietf-msec-mikey-ecc] 1728 Milne, A., "ECC Algorithms for MIKEY", 1729 draft-ietf-msec-mikey-ecc-03 (work in progress), 1730 June 2007. 1732 [I-D.ietf-roll-security-framework] 1733 Tsao, T., Alexander, R., Dohler, M., Daza, V., and A. 1734 Lozano, "A Security Framework for Routing over Low Power 1735 and Lossy Networks", draft-ietf-roll-security-framework-07 1736 (work in progress), January 2012. 1738 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1739 in Session Description Protocol (SDP)", RFC 3605, 1740 October 2003. 1742 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1743 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1744 RFC 3711, March 2004. 1746 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1747 Key Management", BCP 107, RFC 4107, June 2005. 1749 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1750 Architecture", RFC 4291, February 2006. 1752 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed 1753 Efficient Stream Loss-Tolerant Authentication (TESLA)", 1754 RFC 4442, March 2006. 1756 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 1757 AES-CMAC Algorithm", RFC 4493, June 2006. 1759 [RFC4563] Carrara, E., Lehtovirta, V., and K. Norrman, "The Key ID 1760 Information Type for the General Extension Payload in 1761 Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. 1763 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1764 Description Protocol", RFC 4566, July 2006. 1766 [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for 1767 Multimedia Internet KEYing (MIKEY)", RFC 4650, 1768 September 2006. 1770 [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- 1771 RSA-R: An Additional Mode of Key Distribution in 1772 Multimedia Internet KEYing (MIKEY)", RFC 4738, 1773 November 2006. 1775 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1776 Various Multimedia Internet KEYing (MIKEY) Modes and 1777 Extensions", RFC 5197, June 2008. 1779 [RFC5410] Jerichow, A. and L. Piron, "Multimedia Internet KEYing 1780 (MIKEY) General Extension Payload for Open Mobile Alliance 1781 BCAST 1.0", RFC 5410, January 2009. 1783 [RFC6043] Mattsson, J. and T. Tian, "MIKEY-TICKET: Ticket-Based 1784 Modes of Key Distribution in Multimedia Internet KEYing 1785 (MIKEY)", RFC 6043, March 2011. 1787 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1788 Authenticated Key Exchange (IBAKE) Mode of Key 1789 Distribution in Multimedia Internet KEYing (MIKEY)", 1790 RFC 6267, June 2011. 1792 Authors' Addresses 1794 Roger K. Alexander 1795 Cooper Power Systems 1796 20201 Century Blvd. Suite 250 1797 Germantown, Maryland 20874 1798 USA 1800 Email: roger.alexander@cooperindustries.com 1802 Tzeta Tsao 1803 Cooper Power Systems 1804 20201 Century Blvd. Suite 250 1805 Germantown, Maryland 20874 1806 USA 1808 Email: tzeta.tsao@cooperindustries.com