idnits 2.17.1 draft-dondeti-dime-erp-diameter-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. 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 Copyright Line does not match the current year -- 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 14, 2008) is 5765 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 (ref. '4') (Obsoleted by RFC 6733) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and L. Dondeti 3 Extensions (DIME) QUALCOMM, Inc. 4 Internet-Draft July 14, 2008 5 Intended status: Standards Track 6 Expires: January 15, 2009 8 Diameter Support for EAP Re-authentication Protocol 9 draft-dondeti-dime-erp-diameter-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Abstract 38 An EAP extension, called "EAP Re-authentication Protocol (ERP)", has 39 been specified that supports an EAP method-independent protocol for 40 efficient re-authentication between the peer and the server through 41 an authenticator. This document specifies Diameter support for ERP. 42 The Diameter EAP application is re-used for encapsulating the newly 43 defined EAP Initiate and EAP Finish messages specified in the ERP 44 specification. AVPs for request and delivery of Domain Specific Root 45 Keys from the AAA/EAP server to the ER server are also specified. 46 Additionally, this document also specifies Diameter processing rules 47 relevant to ERP. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 4 55 4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4 56 4.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . 4 57 5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 5 59 5.2. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 6 60 6. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 7 61 6.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 7 62 6.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . 7 64 6.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . 7 65 7. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 7 66 8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 12.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . . . 11 76 1. Introduction 78 RFC 4072 [1] specifies a Diameter application that carries EAP 79 packets between a Diameter client and the Diameter Server/EAP server. 80 [2] defines the EAP Re-authentication Protocol to allow faster re- 81 authentication of a previously authenticated peer. In ERP, a peer 82 authenticates to the network by proving possession of key material 83 derived during a previous EAP exchange. For this purpose, an 84 Extended Master Session Key (EMSK) based re-authentication key 85 hierarchy has been defined [5]. ERP may be executed between the ER 86 peer and an ER server in the peer's home domain or the local domain 87 visited by the peer. In the latter case, a Domain Specific Root Key 88 (DSRK), derived from the EMSK, is provided to the local domain ER 89 server. The peer and the local server subsequently use the re- 90 authentication key hierarchy from the DSRK to authenticate and derive 91 authenticator specific keys within that domain. To accomplish the 92 reauthentication functionality, ERP defines two new EAP codes - EAP 93 Initiate and EAP Finish. This document specifies the reuse of 94 Diameter EAP application to carry these new EAP messages. 96 The DSRK can be obtained as part of the regular EAP exchange or as 97 part of an ERP bootstrapping exchange. The local ER server 98 requesting the DSRK needs to be in the path of the EAP or ERP 99 bootstrapping exchange in order to request and obtain the DSRK. This 100 document also specifies how the DSRK is transported to the local ER 101 server using Diameter. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [3]. 109 This document uses terminology defined in [6], [5], [2], and [1]. 111 3. Assumptions 113 This document defines additional optional AVPs for usage with the 114 Diameter EAP application. Routing of these messages is therefore 115 provided via the Diameter Application Identifier (among other 116 elements), as specified by the Diameter Base protocol [4]. Based on 117 the deployment of ERP, a local Diameter server (the same entity 118 serves as a Diameter proxy during the full EAP authentication) may 119 play the role of the ER server for future re-authentication attempts. 120 As such, the local Diameter server requesting the DSRK needs to be in 121 the path of the current EAP exchange between the peer and the EAP 122 server and also along in the future. The Diameter client is 123 furthermore assumed to be able to route the re-authentication 124 messages to the ER server. 126 4. Diameter Support for ERP 128 4.1. Protocol Overview 130 Diameter may be used to transport ERP messages between the NAS 131 (authenticator) and an authentication server (ER server). 133 In ERP, the peer sends an EAP Initiate Reauth message to the ER 134 server via the authenticator. Alternatively, the NAS may send an EAP 135 Initiate Reauth-Start message to the peer to trigger the start of 136 ERP; the peer then responds with an EAP Initiate Reauth message to 137 the NAS. 139 The general guidelines for encapsulating EAP messages in Diameter 140 from RFC 4072 [1] apply to the new EAP messages defined for ERP as 141 well. The EAP Initiate Reauth message is encapsulated in an EAP- 142 Payload AVP of a Diameter EAP-Request message by the NAS and sent to 143 the Diameter server. The NAS MUST copy the contents of the value 144 field of the 'rIKName as NAI' TLV or the peer-id TLV (when the former 145 is not present) of the EAP Initiate Reauth message into a User-Name 146 AVP of the Diameter EAP-Request. 148 The ER server processes the EAP Initiate Reauth message in accordance 149 with [2], and if that is successful, it responds with an EAP Finish 150 Reauth message indicating a success ('R' flag set to 0). The 151 Diameter server MUST encapsulate the EAP Finish Reauth message with 152 the R flag set to zero in an EAP-Payload AVP attribute of a Diameter 153 EAP-Answer message. An EAP-Master-Session-Key AVP included in the 154 Diameter EAP-Answer contains the Re-authentication Master Session Key 155 (rMSK). The Diameter Result Code, if any, SHOULD be a success Result 156 Code. 158 If the processing of the EAP Initiate Reauth message resulted in a 159 failure, the Diameter server MUST encapsulate an EAP Finish Reauth 160 message indicating failure ('R' flag set to 1) in an EAP-Payload AVP 161 of a Diameter EAP-Answer message. The Diameter Result Code, if any, 162 SHOULD be a failure Result Code. Whether an EAP Finish Reauth 163 message is sent at all is specified in [2]. 165 4.2. DSRK Request and Delivery 167 A local ER server, collocated with a Diameter proxy in the peer's 168 visited domain, may request a DSRK from the EAP server, either in the 169 initial EAP exchange (implicit bootstrapping) or in an ERP 170 bootstrapping exchange (explicit bootstrapping). It does this by 171 including the EAP-DSRK-Request AVP in the Diameter EAP-Response 172 message. The EAP-DSRK-Request AVP contains the domain or server 173 identity required to derive the DSRK. 175 An EAP server MAY send the DSRK when it receives a valid Diameter 176 EAP-Request message containing an EAP-DSRK-Request AVP. An ER server 177 MUST send the DSRK (or send a failure result) when it receives a 178 valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP 179 along with a valid EAP Initiate Re-auth packet with the bootstrapping 180 flag turned on. If an EAP-DSRK-Request AVP is included in any other 181 Diameter EAP-Request message, the Diameter server MUST reply with a 182 failure result. An EAP-DSRK AVP MUST be used to send a DSRK; an EAP- 183 DSRK-Name AVP MUST be used to send the DSRK's keyname; and an EAP- 184 DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. 186 5. Command Codes 188 This document re-uses the EAP application commands [1]: 190 Command-Name Abbrev. Code Reference Application 192 Diameter-EAP-Request DER 268 RFC 4072 EAP 193 Diameter-EAP-Answer DEA 268 RFC 4072 EAP 195 Figure 1: ERP Command Codes 197 Re-Auth-Request (RAR) may trigger ERP. 199 Session-Termination-Request (STR), Session-Termination-Answer (STA), 200 Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting- 201 Request (ACR), and Accounting-Answer (ACA) commands are used together 202 with Diameter ERP, they follow the rules in the Diameter EAP 203 application [1] and the Diameter Base specification [4]. The 204 accounting commands use the Application Identifier value of 3 205 (Diameter Base Accounting); the others use 0 (Diameter Common 206 Messages). 208 5.1. Diameter-EAP-Request (DER) 210 The Diameter-EAP-Request (DER) message [1], indicated by the Command- 211 Code field set to 268 and the 'R' bit set in the Command Flags field, 212 is sent by the NAS to the Diameter server to initiate a network 213 access authentication and authorization procedure. 215 The DEA message format is the same as defined in [1] with an addition 216 of optional EAP Re-authentication Protocol (ERP) AVPs. The addition 217 of the EAP-DSRK-Request AVP to the Diameter-EAP-Request message 218 indicates that an ERP server is present and willing to participate in 219 the ERP protocol for this session. Furthermore, the EAP-DSRK-Request 220 AVP provides identity information about the domain of the ERP server. 222 ::= < Diameter Header: 268, REQ, PXY > 223 < Session-Id > 224 { Auth-Application-Id } 225 { Origin-Host } 226 { Origin-Realm } 227 { Destination-Realm } 228 { Auth-Request-Type } 230 [ EAP-DSRK-Request ] 232 [ User-Name ] 233 [ Destination-Host ] 234 ... 235 * [ AVP ] 237 5.2. Diameter-EAP-Answer (DEA) 239 The Diameter-EAP-Answer (DEA) message defined in [1], indicated by 240 the Command-Code field set to 268 and 'R' bit cleared in the Command 241 Flags field, is sent in response to the Diameter-EAP-Request message 242 (DER). 244 The DEA message format is the same as defined in [1] with an addition 245 of optional EAP Re-authentication Protocol (ERP) AVPs. The addition 246 of the EAP-DSRK, EAP-DSRK-Name and the EAP-DSRK-Lifetime AVP to the 247 Diameter-EAP-Answer message indicates that an Diameter / ER server is 248 able to provide ERP support for this session and delivers keying 249 material, lifetime and a key name. 251 ::= < Diameter Header: 268, PXY > 252 < Session-Id > 253 { Auth-Application-Id } 254 { Auth-Request-Type } 255 { Result-Code } 256 { Origin-Host } 257 { Origin-Realm } 259 [ EAP-DSRK ] 260 [ EAP-DSRK-Name ] 261 [ EAP-DSRK-Lifetime ] 263 [ User-Name ] 264 ... 265 * [ AVP ] 267 6. Attribute Value Pair Definitions 269 6.1. EAP-DSRK-Request AVP 271 The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. This 272 AVP fulfills two purposes: First, it indicates that a ER server is 273 located in the local domain that is willing to play the role of an ER 274 server for a particular session. Second, it conveys information 275 about the domain and ER server identity to the Diameter/EAP server. 277 6.2. EAP-DSRK AVP 279 The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain 280 Specific Root Key (DSRK) is carried in this payload. 282 6.3. EAP-DSRK-Name AVP 284 The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This 285 AVP contains the name of the DSRK key that is later used during the 286 re-authentication exchange to select the correct DSRK. 288 6.4. EAP-DSRK-Lifetime AVP 290 The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and 291 contains the DSRK lifetime in seconds. 293 7. AVP Occurrence Table 295 The following table lists the AVPs that may optionally be present in 296 the DER and DEA commands [1]. 298 +---------------+ 299 | Command-Code | 300 +-+-----+-----+-+ 301 Attribute Name | DER | DEA | 302 -------------------------------|-----+-----+ 303 EAP-DSRK-Request | 0-1 | 0 | 304 EAP-DSRK | 0 | 0-1 | 305 EAP-DSRK-Name | 0 | 0-1 | 306 EAP-DSRK-Lifetime | 0 | 0-1 | 307 +-----+-----+ 309 Figure 2: DER and DEA Commands AVP Table 311 When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name 312 and the EAP-DSRK-Lifetime MUST also be present. 314 8. AVP Flag Rules 316 The following table describes the Diameter AVPs, their AVP Code 317 values, types, possible flag values, and whether the AVP MAY be 318 encrypted. The Diameter base [4] specifies the AVP Flag rules for 319 AVPs in Section 4.5. 321 +---------------------+ 322 | AVP Flag Rules | 323 +----+-----+----+-----+----+ 324 AVP Section | | |SHLD|MUST | | 325 Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| 326 ------------------------------------------+----+-----+----+-----+----+ 327 EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | 328 EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | 329 EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | 330 EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | 331 ------------------------------------------+----+-----+----+-----+----+ 333 Due to space constraints, the short form DiamIdent is used to 334 represent DiameterIdentity. 336 Figure 3: AVP Flag Rules Table 338 9. Security Considerations 340 The security considerations specified in RFC 4072 [1], and RFC 3588 341 [4] are applicable to this document. 343 EAP channel bindings may be necessary to ensure that the Diameter 344 client and the server are in sync regarding the key Requesting 345 Entity's Identity. Specifically, the Requesting Entity advertises 346 its identity through the EAP lower layer, and the user or the EAP 347 peer communicates that identity to the EAP server (and the EAP server 348 communicates that identity to the Diameter server) via the EAP method 349 for user/peer to server verification of the Requesting Entity's 350 Identity. 352 10. IANA Considerations 354 This document requires IANA registration of the following new AVPs to 355 the AVP registry established by RFC 3588 [4]: 357 o EAP-DSRK-Request 359 o EAP-DSRK 361 o EAP-DSRK-Name 363 o EAP-DSRK-Lifetime 365 11. Acknowledgments 367 Vidya Narayanan reviewed a rough draft version and found some errors. 368 Many thanks for her input. 370 12. References 372 12.1. Normative References 374 [1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 375 Authentication Protocol (EAP) Application", RFC 4072, 376 August 2005. 378 [2] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 379 authentication Protocol (ERP)", draft-ietf-hokey-erx-14 (work in 380 progress), March 2008. 382 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 383 Levels", BCP 14, RFC 2119, March 1997. 385 [4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 386 "Diameter Base Protocol", RFC 3588, September 2003. 388 12.2. Informative References 390 [5] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 391 "Specification for the Derivation of Root Keys from an Extended 392 Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-07 393 (work in progress), June 2008. 395 [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 396 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 397 June 2004. 399 Author's Address 401 Lakshminath Dondeti 402 QUALCOMM, Inc. 403 5775 Morehouse Dr 404 San Diego, CA 405 USA 407 Phone: +1 858-845-1267 408 Email: ldondeti@qualcomm.com 410 Full Copyright Statement 412 Copyright (C) The IETF Trust (2008). 414 This document is subject to the rights, licenses and restrictions 415 contained in BCP 78, and except as set forth therein, the authors 416 retain all their rights. 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Intellectual Property 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org.