idnits 2.17.1 draft-wu-dime-local-keytran-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (December 4, 2009) is 5250 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5296 (Obsoleted by RFC 6696) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track G. Zorn, Ed. 5 Expires: June 7, 2010 Network Zen 6 December 4, 2009 8 Diameter Attribute-Value Pairs for Cryptographic Key Transport 9 draft-wu-dime-local-keytran-03 11 Abstract 13 Some Authentication, Authorization, and Accounting (AAA) applications 14 require the transport of cryptographic keying material; this document 15 specifies a set of Attribute-Value Pairs (AVPs) providing native 16 Diameter support of cryptographic key delivery. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to format it 23 for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on June 7, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Technical Terms and Acronyms . . . . . . . . . . . . . . . 3 65 3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . . 4 66 3.1. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 4 68 3.1.2. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.3. Keying-Material AVP . . . . . . . . . . . . . . . . . . 5 70 3.1.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 71 4. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 6.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 6.2. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 The Diameter EAP application [RFC4072] defines the EAP-Master- 85 Session-Key and EAP-Key-Name AVPs for the purpose of transporting 86 cryptographic keying material derived during the execution of certain 87 EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one 88 instance of either of these AVPs is allowed in any Diameter message. 90 However, recent work [RFC5295] has specified methods to derive other 91 keys from the keying material created during EAP method execution 92 that may require transport in addition to the MSK. In addition, ERP 93 [RFC5296] specifies new keys that may need to be transported between 94 Diameter nodes. 96 This note specifies a set of AVPs allowing the transport of multiple 97 cryptographic keys in a single Diameter message. 99 2. Terminology 101 2.1. Standards Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2.2. Technical Terms and Acronyms 109 DER 110 Diameter EAP request [RFC4072]. 112 DEA 113 Diameter EAP Answer [RFC4072]. 115 DSRK 116 Domain-Specific Root Key [RFC5295]. 118 DSUSRK Domain-Specific Usage-Specific Root Key. This is a Usage- 119 Specific Root Key derived from a DSRK [RFC5295]. 121 EAP 122 Extensible Authentication Protocol [RFC3748]. 124 EMSK 125 Extended Master Session Key [RFC3748]. 127 ERP 128 EAP Re-authentication Protocol [RFC5296]. 130 MSK 131 Master Session Key [RFC3748]. 133 rMSK 134 reauthentication MSK [RFC5296]. This is a per-authenticator key, 135 derived from the rRK (see below). 137 rRK 138 reauthentication Root Key, derived from the EMSK or DSRK 139 [RFC5296]. 141 USRK 142 Usage-Specific Root Key [RFC5295] 144 3. Attribute-Value Pair Definitions 146 This section defines new AVPs for the transport of cryptographic keys 147 in the Diameter EAP application [RFC4072], as well as other Diameter 148 applications. 150 3.1. Key AVP 152 The Key AVP (AVP Code ) is of type Grouped [RFC3588] It contains 153 the name, type and optionally, the usable lifetime of the key, as 154 well as the keying material itself. 156 Key ::= < AVP Header: AC1 > 157 { Key-Type } 158 { Keying-Material } 159 [ Key-Lifetime ] 160 [ Key-Name ] 161 * [ AVP ] 163 3.1.1. Key-Type AVP 165 The Key-Type AVP (AVP Code ) is of type Enumerated and signifies 166 the type of the key being sent. The Key-Type AVP MAY be included in 167 a DER command as a signal that a certain type of key is required in 168 the response (e.g., to support ERP). The following values are 169 defined in this document: 171 MSK (0) 172 The EAP Master Session Key [RFC3748] 174 DSRK (1) 175 A Domain-Specific Root Key [RFC5295]. 177 USRK (2) 178 A Usage Specific Root Key [RFC5295]. 180 rRK (3) 181 A reauthentication Root Key [RFC5296]. 183 rMSK (4) 184 A reauthentication Master Session Key [RFC5296]. 186 DSUSRK (5) A Domain-Specific Usage-Specific Root Key [RFC5295]. 188 If additional values are needed, they are to be assigned by IANA 189 according to the policy stated in Section 6.2 191 3.1.2. Key-Name AVP 193 The Key-Name AVP is of type OctetString. It contains an opaque key 194 identifier. Exactly how this name is generated and used depends on 195 the key type and link layer in question, and is beyond the scope of 196 this document (see [RFC5247] and [RFC5295] for discussions of key 197 name generation in the context of EAP). 199 3.1.3. Keying-Material AVP 201 The Keying-Material AVP (AVP Code ) is of type OctetString. The 202 exact usage of this keying material depends upon several factors, 203 including the link layer in use and the type of the key; it is beyond 204 the scope of this document. 206 3.1.4. Key-Lifetime AVP 208 The Key-Lifetime AVP (AVP Code ) is of type Integer64 [RFC3588] 209 and represents the period of time (in seconds) for which the contents 210 of the Keying-Material AVP Section 3.1.3 is valid. 212 NOTE: 213 Applications using this value SHOULD consider the beginning of the 214 lifetime to be the point in time when the keying material is first 215 used. 217 4. AVP Occurrence Table 219 The following table lists the AVPs that MAY be present in the DER and 220 DEA commands [RFC4072]. 222 +---------------+ 223 | Command-Code | 224 +-+-----+-----+-+ 225 AVP Name | DER | DEA | 226 -------------------------------|-----+-----+ 227 Key | 0 | 0+ | 228 Key-Type | 0+ | 0 | 229 Key-Name | 0-1 | 0-1 | 230 +-----+-----+ 232 DER and DEA Commands AVP Table 234 5. Security Considerations 236 The security considerations applicable to the Diameter Base Protocol 237 [RFC3588] are also applicable to this document. 239 6. IANA Considerations 241 Upon publication of this memo as an RFC, IANA is requested to assign 242 values as described in the following sections. 244 6.1. AVP Codes 246 Codes must be assigned for the following AVPs using the policy 247 specified in RFC 3588, Section 11.1.1: 249 o Key (, Section 3.1) 251 o Key-Type (, Section 3.1.1) 253 o Keying-Material (, Section 3.1.3 255 o Key-Lifetime (, Section 3.1.4 257 6.2. AVP Values 259 New values may be assigned for the Key-Type AVP (Section 3.1.1) using 260 the "First Come First Served" policy [RFC5226]. 262 7. Acknowledgements 264 Thanks to Semyon Mizikovsky and Sebastien Decugis for useful 265 comments. 267 Section 3.1.2 is largely derived from Section 4.1.4 of RFC 4072 268 [RFC4072]. 270 8. References 272 8.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 278 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 280 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 281 Levkowetz, "Extensible Authentication Protocol (EAP)", 282 RFC 3748, June 2004. 284 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 285 Authentication Protocol (EAP) Application", RFC 4072, 286 August 2005. 288 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 289 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 290 May 2008. 292 8.2. Informative References 294 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 295 Authentication Protocol", RFC 5216, March 2008. 297 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 298 Authentication Protocol (EAP) Key Management Framework", 299 RFC 5247, August 2008. 301 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 302 "Specification for the Derivation of Root Keys from an 303 Extended Master Session Key (EMSK)", RFC 5295, 304 August 2008. 306 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 307 authentication Protocol (ERP)", RFC 5296, August 2008. 309 Authors' Addresses 311 Qin Wu (editor) 312 Huawei Technologies Co., Ltd. 313 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 314 Nanjing, JiangSu 210001 315 China 317 Phone: +86-25-84565892 318 Email: Sunseawq@huawei.com 320 Glen Zorn (editor) 321 Network Zen 322 1310 East Thomas Street 323 Seattle, Washington 98102 324 +1 (206) 377-9035 326 Email: gwz@net-zen.net