idnits 2.17.1 draft-ietf-dime-local-keytran-00.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/) 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 (January 8, 2010) is 5220 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: July 12, 2010 Network Zen 6 January 8, 2010 8 Diameter Attribute-Value Pairs for Cryptographic Key Transport 9 draft-ietf-dime-local-keytran-00 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. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 12, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Technical Terms and Acronyms . . . . . . . . . . . . . . . 3 62 3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . . 4 63 3.1. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.2. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.3. Keying-Material AVP . . . . . . . . . . . . . . . . . . 5 67 3.1.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 68 4. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 6 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 71 6.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6.2. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The Diameter EAP application [RFC4072] defines the EAP-Master- 82 Session-Key and EAP-Key-Name AVPs for the purpose of transporting 83 cryptographic keying material derived during the execution of certain 84 EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one 85 instance of either of these AVPs is allowed in any Diameter message. 87 However, recent work [RFC5295] has specified methods to derive other 88 keys from the keying material created during EAP method execution 89 that may require transport in addition to the MSK. In addition, ERP 90 [RFC5296] specifies new keys that may need to be transported between 91 Diameter nodes. 93 This note specifies a set of AVPs allowing the transport of multiple 94 cryptographic keys in a single Diameter message. 96 2. Terminology 98 2.1. Standards Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2.2. Technical Terms and Acronyms 106 DER 107 Diameter EAP request [RFC4072]. 109 DEA 110 Diameter EAP Answer [RFC4072]. 112 DSRK 113 Domain-Specific Root Key [RFC5295]. 115 DSUSRK 116 Domain-Specific Usage-Specific Root Key. This is a Usage-Specific 117 Root Key derived from a DSRK [RFC5295]. 119 EAP 120 Extensible Authentication Protocol [RFC3748]. 122 EMSK 123 Extended Master Session Key [RFC3748]. 125 ERP 126 EAP Re-authentication Protocol [RFC5296]. 128 MSK 129 Master Session Key [RFC3748]. 131 rMSK 132 reauthentication MSK [RFC5296]. This is a per-authenticator key, 133 derived from the rRK (see below). 135 rRK 136 reauthentication Root Key, derived from the EMSK or DSRK 137 [RFC5296]. 139 USRK 140 Usage-Specific Root Key [RFC5295] 142 3. Attribute-Value Pair Definitions 144 This section defines new AVPs for the transport of cryptographic keys 145 in the Diameter EAP application [RFC4072], as well as other Diameter 146 applications. 148 3.1. Key AVP 150 The Key AVP (AVP Code ) is of type Grouped [RFC3588] It contains 151 the name, type and optionally, the usable lifetime of the key, as 152 well as the keying material itself. 154 Key ::= < AVP Header: AC1 > 155 < Key-Type > 156 { Keying-Material } 157 [ Key-Lifetime ] 158 [ Key-Name ] 159 * [ AVP ] 161 3.1.1. Key-Type AVP 163 The Key-Type AVP (AVP Code ) is of type Enumerated and signifies 164 the type of the key being sent. The Key-Type AVP MAY be included in 165 a DER command as a signal that a certain type of key is required in 166 the response (e.g., to support ERP). The following values are 167 defined in this document: 169 MSK (0) 170 The EAP Master Session Key [RFC3748] 172 DSRK (1) 173 A Domain-Specific Root Key [RFC5295]. 175 USRK (2) 176 A Usage Specific Root Key [RFC5295]. 178 rRK (3) 179 A reauthentication Root Key [RFC5296]. 181 rMSK (4) 182 A reauthentication Master Session Key [RFC5296]. 184 DSUSRK (5) A Domain-Specific Usage-Specific Root Key [RFC5295]. 186 If additional values are needed, they are to be assigned by IANA 187 according to the policy stated in Section 6.2 189 3.1.2. Key-Name AVP 191 The Key-Name AVP is of type OctetString. It contains an opaque key 192 identifier. Exactly how this name is generated and used depends on 193 the key type and link layer in question, and is beyond the scope of 194 this document (see [RFC5247] and [RFC5295] for discussions of key 195 name generation in the context of EAP). 197 3.1.3. Keying-Material AVP 199 The Keying-Material AVP (AVP Code ) is of type OctetString. The 200 exact usage of this keying material depends upon several factors, 201 including the link layer in use and the type of the key; it is beyond 202 the scope of this document. 204 3.1.4. Key-Lifetime AVP 206 The Key-Lifetime AVP (AVP Code ) is of type Integer64 [RFC3588] 207 and represents the period of time (in seconds) for which the contents 208 of the Keying-Material AVP Section 3.1.3 is valid. 210 NOTE: 211 Applications using this value SHOULD consider the beginning of the 212 lifetime to be the point in time when the keying material is first 213 used. 215 4. AVP Occurrence Table 217 The following table lists the AVPs that MAY be present in the DER and 218 DEA commands [RFC4072]. 220 +---------------+ 221 | Command-Code | 222 +-+-----+-----+-+ 223 AVP Name | DER | DEA | 224 -------------------------------|-----+-----+ 225 Key | 0 | 0+ | 226 Key-Type | 0+ | 0 | 227 Key-Name | 0-1 | 0-1 | 228 +-----+-----+ 230 DER and DEA Commands AVP Table 232 5. Security Considerations 234 The security considerations applicable to the Diameter Base Protocol 235 [RFC3588] are also applicable to this document. 237 6. IANA Considerations 239 Upon publication of this memo as an RFC, IANA is requested to assign 240 values as described in the following sections. 242 6.1. AVP Codes 244 Codes must be assigned for the following AVPs using the policy 245 specified in RFC 3588, Section 11.1.1: 247 o Key (, Section 3.1) 249 o Key-Type (, Section 3.1.1) 251 o Keying-Material (, Section 3.1.3 253 o Key-Lifetime (, Section 3.1.4 255 6.2. AVP Values 257 New values may be assigned for the Key-Type AVP (Section 3.1.1) using 258 the "First Come First Served" policy [RFC5226]. 260 7. Acknowledgements 262 Thanks to Semyon Mizikovsky and Sebastien Decugis for useful 263 comments. 265 8. References 267 8.1. Normative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, March 1997. 272 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 273 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 275 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 276 Levkowetz, "Extensible Authentication Protocol (EAP)", 277 RFC 3748, June 2004. 279 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 280 Authentication Protocol (EAP) Application", RFC 4072, 281 August 2005. 283 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 284 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 285 May 2008. 287 8.2. Informative References 289 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 290 Authentication Protocol", RFC 5216, March 2008. 292 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 293 Authentication Protocol (EAP) Key Management Framework", 294 RFC 5247, August 2008. 296 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 297 "Specification for the Derivation of Root Keys from an 298 Extended Master Session Key (EMSK)", RFC 5295, 299 August 2008. 301 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 302 authentication Protocol (ERP)", RFC 5296, August 2008. 304 Authors' Addresses 306 Qin Wu (editor) 307 Huawei Technologies Co., Ltd. 308 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 309 Nanjing, JiangSu 210001 310 China 312 Phone: +86-25-84565892 313 Email: Sunseawq@huawei.com 315 Glen Zorn (editor) 316 Network Zen 317 1463 East Republican Street 318 #358 319 Seattle, Washington 98112 320 USA 322 Email: gwz@net-zen.net