idnits 2.17.1 draft-wu-dime-local-keytran-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4072, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4072, updated by this document, for RFC5378 checks: 2002-06-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2009) is 5407 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 (==), 5 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 Technologies Co., Ltd. 4 Updates: 4072 (if approved) G. Zorn, Ed. 5 Intended status: Standards Track Network Zen 6 Expires: January 8, 2010 July 7, 2009 8 Diameter Attribute-Value Pairs for Cryptographic Key Transport 9 draft-wu-dime-local-keytran-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 8, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Some AAA applications require the transport of cryptographic keying 48 material; this document specifies a set of Attribute-Value Pairs 49 (AVPs) providing native Diameter support of cryptographic key 50 delivery. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Technical Terms and Acronyms . . . . . . . . . . . . . . . 3 58 3. Attribute-Value Pair Definitions . . . . . . . . . . . . . . . 4 59 3.1. EAP-Key AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.1. EAP-Key-Type AVP . . . . . . . . . . . . . . . . . . . 5 61 3.1.2. EAP-Key-Name AVP . . . . . . . . . . . . . . . . . . . 5 62 3.1.3. EAP-Keying-Material AVP . . . . . . . . . . . . . . . . 5 63 3.1.4. EAP-Key-Lifetime AVP . . . . . . . . . . . . . . . . . 6 64 4. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The Diameter EAP application [RFC4072] defines the EAP-Master- 77 Session-Key and EAP-Key-Name AVPs for the purpose of transporting 78 cryptographic keying material derived during the execution of certain 79 EAP [RFC3748] methods (for example, EAP-TLS [RFC5216]). At most one 80 instance of either of these AVPs is allowed in any Diameter message. 82 However, recent work [RFC5295] has specified methods to derive other 83 keys from the keying material created during EAP method execution 84 that may require transport in addition to the MSK. In addition, ERP 85 [RFC5296] specifies new keys that may need to be transported between 86 Diameter nodes. 88 This note specifies a set of AVPs allowing the transport of multiple 89 cryptographic keys in a single Diameter message. 91 2. Terminology 93 The following terms are used in this note. 95 2.1. Standards Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2.2. Technical Terms and Acronyms 103 AAA 104 Authentication, Authorization, and Accounting (see below). 106 Accounting 107 The act of collecting information on resource usage for the 108 purpose of trend analysis, auditing, billing, or cost allocation 109 [RFC2989]. 111 Authentication 112 The act of verifying a claimed identity, in the form of a pre- 113 existing label from a mutually known name space, as the originator 114 of a message (message authentication) or as the end-point of a 115 channel (entity authentication) [RFC2989]. 117 Authorization 118 The act of determining if a particular right, such as access to 119 some resource, can be granted to the presenter of a particular 120 credential [RFC2989]. 122 DER 123 Diameter EAP request. [RFC4072] 125 DEA 126 Diameter EAP Answer. [RFC4072] 128 DSRK 129 Domain Specific Root Key [RFC5295]. 131 EAP 132 Extensible Authentication Protocol [RFC3748]. 134 EMSK 135 Extended Master Session Key [RFC3748]. 137 ERP 138 EAP Re-authentication Protocol [RFC5296]. 140 MSK 141 Master Session Key [RFC3748]. 143 rMSK 144 re-authentication MSK [RFC5296]. This is a per-authenticator key, 145 derived from the rRK. 147 rRK 148 re-authentication Root Key, derived from the EMSK or DSRK 149 [RFC5296]. 151 USRK 152 Usage Specific Root Key [RFC5295]. 154 3. Attribute-Value Pair Definitions 156 This section defines new AVPs for the transport of cryptographic keys 157 in the Diameter EAP application [RFC4072], as well as other Diameter 158 applications. 160 3.1. EAP-Key AVP 162 The EAP-Key AVP (AVP Code ) is of type Grouped [RFC3588]. It 163 contains the name, type and optionally, the usable lifetime of the 164 key, as well as the keying material itself. 166 EAP-Key ::= < AVP Header: AC1 > 167 { EAP-Key-Type } 168 { EAP-Keying-Material } 169 [ EAP-Key-Lifetime ] 170 [ EAP-Key-Name ] 171 * [ AVP ] 173 3.1.1. EAP-Key-Type AVP 175 The EAP-Key-Type AVP (AVP Code ) is of type Enumerated and 176 signifies the type of the key being sent. The EAP-Key-Type MAY be 177 included in a DER command as a signal that a certain type of key is 178 required in the response (e.g., to support ERP). The following 179 values are defined in this document: 181 MSK (0) 182 The EAP Master Session Key. [RFC3748] 184 DSRK (1) 185 A Domain Specific Root Key. [RFC5295] 187 USRK (2) 188 A Usage Specific Root Key. [RFC5295] 190 rRK (4) 191 A reauthentication Root Key. [RFC5296] 193 rMSK (5) 194 A reauthentication Master Session Key. [RFC5296] 196 If additional values are needed, they are to be assigned by IANA 197 according to the policy stated in Section 6.2. 199 3.1.2. EAP-Key-Name AVP 201 The syntax and semantics of the EAP-Key-Name AVP are specified in 202 Section 4.1.4 of RFC 4072. 204 3.1.3. EAP-Keying-Material AVP 206 The EAP-Keying-Material AVP (AVP Code ) is of type OctetString. 207 The exact usage of this keying material depends upon several factors, 208 including the link layer in use and the type of the key; it is beyond 209 the scope of this document. 211 3.1.4. EAP-Key-Lifetime AVP 213 The EAP-Key-Lifetime AVP (AVP Code ) is of type Integer64 214 [RFC3588] representing the period of time (in seconds) for which the 215 keying material is valid. 217 Note: Applications using this value SHOULD consider the beginning of 218 the lifetime to be the point in time when the keying material is 219 first used. 221 4. AVP Occurrence Table 223 The following table lists the AVPs that MAY be present in the DER and 224 DEA commands [RFC4072]. 226 +---------------+ 227 | Command-Code | 228 +-+-----+-----+-+ 229 AVP Name | DER | DEA | 230 -------------------------------|-----+-----+ 231 EAP-Key | 0 | 0+ | 232 EAP-Key-Type | 0+ | 0 | 233 EAP-Key-Name | 0-1 | 0-1 | 234 +-----+-----+ 236 DER and DEA Commands AVP Table 238 5. Security Considerations 240 The security considerations discussed in [RFC3588] are applicable to 241 this document. 243 6. IANA Considerations 245 Upon publication of this memo as an RFC, IANA is requested to assign 246 values as described in the following sections. 248 6.1. AVP Codes 250 Codes must be assigned for the following AVPs using the policy 251 specified in RFC 3588, Section 11.1.1: 253 o EAP-Key (, Section 3.1) 254 o EAP-Key-Type (, Section 3.1.1) 256 o EAP-Keying-Material (, Section 3.1.3) 258 o EAP-Key-Lifetime (, Section 3.1.4) 260 6.2. AVP Values 262 New values may be assigned for the EAP-Key-Type AVP (Section 3.1.1) 263 using the "First Come, First Served" policy [RFC5226]. 265 7. References 267 7.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 7.2. Informative References 289 [RFC2989] Aboba, B., Calhoun, P., Glass, S., Hiller, T., McCann, P., 290 Shiino, H., Zorn, G., Dommety, G., C.Perkins, B.Patil, 291 D.Mitton, S.Manning, M.Beadles, P.Walsh, X.Chen, 292 S.Sivalingham, A.Hameed, M.Munson, S.Jacobs, B.Lim, 293 B.Hirschman, R.Hsu, Y.Xu, E.Campell, S.Baba, and E.Jaques, 294 "Criteria for Evaluating AAA Protocols for Network 295 Access", RFC 2989, November 2000. 297 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 298 Authentication Protocol", RFC 5216, March 2008. 300 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 301 "Specification for the Derivation of Root Keys from an 302 Extended Master Session Key (EMSK)", RFC 5295, 303 August 2008. 305 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 306 authentication Protocol (ERP)", RFC 5296, August 2008. 308 Authors' Addresses 310 Qin Wu (editor) 311 Huawei Technologies Co., Ltd. 312 Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. 313 Nanjing, Jiangsu 21001 314 China 316 Phone: +86-25-84565892 317 Email: sunseawq@huawei.com 319 Glen Zorn (editor) 320 Network Zen 321 1310 East Thomas Street 322 #306 323 Seattle, Washington 98102 324 USA 326 Phone: +1 (206) 377-9035 327 Email: gwz@net-zen.net