idnits 2.17.1 draft-gaonkar-radext-erp-attrs-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. 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 abstract seems to contain references ([6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 25, 2008) is 5899 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) == Unused Reference: '4' is defined on line 230, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 234, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3579 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2548 (ref. '3') == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-08 == Outdated reference: A later version (-14) exists of draft-ietf-hokey-erx-12 == Outdated reference: A later version (-07) exists of draft-ietf-hokey-emsk-hierarchy-04 == Outdated reference: A later version (-18) exists of draft-zorn-radius-keywrap-13 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Gaonkar 3 Internet-Draft Georgia Tech University 4 Intended status: Standards Track L. Dondeti 5 Expires: August 28, 2008 V. Narayanan 6 QUALCOMM, Inc. 7 G. Zorn 8 February 25, 2008 10 RADIUS Support for EAP Re-authentication Protocol 11 draft-gaonkar-radext-erp-attrs-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 RFCxxxx (draft-ietf-hokey-erx after publication) [6] specifies the 45 EAP Re-authentication Protocol (ERP). This document specifies RADIUS 46 support for ERP. The procedures in RFC3579 [1] are used for 47 encapsulating the EAP Initiate and Finish messages specified in 48 RFCxxxx (draft-ietf-hokey-erx after publication) [6]. This document 49 specifies attributes for the request and delivery of Domain Specific 50 Root Keys from the AAA/EAP server to the ER Server. Additionally, 51 this document also specifies RADIUS message processing rules relevant 52 to ERP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. RADIUS Support for ERP . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 5 61 3.3. Conflicting Messages . . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Intellectual Property and Copyright Statements . . . . . . . . . . 8 71 1. Introduction 73 RFC3579 [1] specifies EAP message encapsulation in RADIUS messages. 74 [6] defines the EAP Re-authentication Protocol to allow faster re- 75 authentication of a previously authenticated peer. In ERP, a peer 76 authenticates to the network by proving possession of key material 77 derived during a previous EAP exchange. For this purpose, ERP 78 defines two new EAP codes - EAP Initiate and EAP Finish. This 79 document specifies the encapsulation of these messages in RADIUS. In 80 addition, a Domain Specific Root Key (DSRK) may be transported from 81 the RADIUS or EAP Server to an EAP Re-authentication (ER) server in 82 the local domain for the purpose of re-authenticating the peer within 83 that domain (see Figure 2 of [6]. This document defines how the DSRK 84 is transported to the ER server using RADIUS. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [2]. 92 This document uses terminology defined in [7], [8], [6], and [1]. 94 3. RADIUS Support for ERP 96 The EAP Re-authentication Protocol, defined in [6], provides a 97 mechanism for efficient re-authentication of EAP peers that have 98 unexpired keying material from a previous EAP exchange. For this 99 purpose, an Extended Master Session Key (EMSK) based re- 100 authentication key hierarchy has been defined [8]. ERP may be 101 executed between the ER peer and an ER server in the peer's home 102 domain or the local domain visited by the peer. In the latter case, 103 a Domain Specific Root Key (DSRK), derived from the EMSK, is provided 104 to the local domain ER server. The peer and the local server 105 subsequently use the re-authentication key hierarchy from the DSRK to 106 authenticate and derive authenticator specific keys within that 107 domain. 109 The DSRK can be obtained as part of the regular EAP exchange or as 110 part of an ERP bootstrapping exchange. The local ER server 111 requesting the DSRK needs to be in the path of the EAP or ERP 112 bootstrapping exchange in order to request and obtain the DSRK. 114 3.1. Protocol Overview 116 RADIUS may be used to transport ERP messages between the NAS 117 (authenticator) and an authentication server (ER server). 119 In ERP, the peer sends an EAP Initiate Reauth message to the ER 120 server via the authenticator. Alternatively, the NAS may send an EAP 121 Initiate Reauth-Start message to the peer to trigger the start of 122 ERP; the peer then responds with an EAP Initiate Reauth message to 123 the NAS. 125 The general guidelines for encapsulating EAP messages in RADIUS from 126 RFC3579 [1] apply to the new EAP messages defined for ERP as well. 127 The EAP Initiate Reauth message is encapsulated in an EAP-Message 128 attribute of a RADIUS Access-Request message by the NAS and sent to 129 the RADIUS server. In order to permit non-EAP aware RADIUS proxies 130 to forward the Access-Request packet, the NAS MUST copy the contents 131 of the value field of the 'rIKName as NAI' TLV or the peer-id TLV 132 (when the former is not present) of the EAP Initiate Reauth message 133 into the User-Name attribute of the Access-Request. 135 The ER server processes the EAP Initiate Reauth message in accordance 136 with [6], and if that is successful, it responds with an EAP Finish 137 Reauth message indicating a success ('R' flag set to 0). The RADIUS 138 server MUST encapsulate the EAP Finish Reauth message with the R flag 139 set to zero in an EAP-Message attribute of a RADIUS Access-Accept 140 message. The Re-authentication Master Session Key (rMSK) is 141 transported along with this message to the NAS. The rMSK transport 142 follows the same procedures of MSK transport along with EAP Success 143 messages in a regular EAP exchange. The MS-MPPE-Recv-Key and MS- 144 MPPE-Send-Key attributes defined in RFC2548 [3] are used to transport 145 the rMSK from the server to the NAS as follows: 147 MS-MPPE-Recv-Key = rMSK (0, n/2-1) 149 MS-MPPE-Send-Key = rMSK (n/2, n-1) 151 where, 'n' is the total length of the rMSK in octets and the (x, y) 152 notation indicates the starting and ending octets of the key 153 material. 155 If the processing of the EAP Initiate Reauth message resulted in a 156 failure, the RADIUS server MUST encapsulate an EAP Finish Reauth 157 message indicating failure ('R' flag set to 1) in an EAP-Message 158 attribute of a RADIUS Access-Reject message. Whether the RADIUS 159 server sends an EAP Finish Reauth message is specified in [6]. 161 3.2. DSRK Request and Delivery 163 A local ER server, collocated with a RADIUS server in the peer's 164 visited domain, may request a DSRK from the EAP server, either in the 165 initial EAP exchange or in an ERP bootstrapping exchange. The key 166 request and delivery mechanism specified in [9] is used. A RADIUS 167 server acting as an ER server may include the Keying-Material 168 attribute defined in [9] in the RADIUS Access-Request message 169 containing an EAP Response packet or an EAP Initiate Reauth packet in 170 the EAP-Message attribute. The App ID field of the Keying-Material 171 attribute MUST be set to "EAP DSRK" and the Optional Data field 172 SHOULD be set to the domain or server identity required to derive the 173 DSRK. The RADIUS server requesting the DSRK needs to be in the path 174 of the corresponding EAP or ERP exchange between the peer and the EAP 175 or ER server. 177 The RADIUS server, acting as the EAP server, if it wishes to include 178 a DSRK in response to a request for it, SHOULD include the Keying- 179 Material attribute defined in [9] in the RADIUS Access-Accept message 180 (containing either an EAP Success or EAP Finish Reauth with the 'R' 181 flag set to 0). The App ID of the Keying-Material attribute MUST be 182 set to "EAP DSRK" and the Optional Data field SHOULD be set to the 183 domain or server identity used by the EAP server to derive the DSRK. 184 The encrypted DSRK itself must be included in the Data field of the 185 Keying-Material attribute in accordance with [9]. 187 3.3. Conflicting Messages 189 In addition to the rules specified in Section 2.6.3. of RFC3579 [1], 190 the following combinations SHOULD NOT be sent by a RADIUS Server: 192 Access-Accept/EAP-Message/EAP Finish Reauth with 'R' flag set to 1 194 Access-Reject/EAP-Message/EAP Finish Reauth with 'R' flag set to 0 196 Access-Reject/Keying-Material 198 Access-Challenge/EAP-Message/EAP Initiate Reauth 200 Access-Challenge/EAP-Message/EAP Finish Reauth 202 4. Security Considerations 204 The security considerations specified in RFC 3579 [1], RFC 2548 [3], 205 and [9] are applicable to this document. 207 5. IANA Considerations 209 This document requires IANA registration of the following value of 210 the App ID field for the RADIUS Keying-Material attribute: 212 2 ... EAP DSRK 214 6. Acknowledgments 216 7. References 218 7.1. Normative References 220 [1] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In 221 User Service) Support For Extensible Authentication Protocol 222 (EAP)", RFC 3579, September 2003. 224 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 225 Levels", BCP 14, RFC 2119, March 1997. 227 [3] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 228 RFC 2548, March 1999. 230 [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 231 Authentication Dial In User Service (RADIUS)", RFC 2865, 232 June 2000. 234 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 235 Considerations Section in RFCs", 236 draft-narten-iana-considerations-rfc2434bis-08 (work in 237 progress), October 2007. 239 7.2. Informative References 241 [6] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 242 authentication Protocol (ERP)", draft-ietf-hokey-erx-12 (work in 243 progress), February 2008. 245 [7] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 246 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 247 June 2004. 249 [8] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 250 "Specification for the Derivation of Root Keys from an Extended 251 Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-04 252 (work in progress), February 2008. 254 [9] Zorn, G., "RADIUS Attributes for the Delivery of Keying 255 Material", draft-zorn-radius-keywrap-13 (work in progress), 256 April 2007. 258 Authors' Addresses 260 Kedar Gaonkar 261 Georgia Tech University 263 Email: kgaonkar3@gatech.edu 265 Lakshminath Dondeti 266 QUALCOMM, Inc. 267 5775 Morehouse Dr 268 San Diego, CA 269 USA 271 Phone: +1 858-845-1267 272 Email: ldondeti@qualcomm.com 274 Vidya Narayanan 275 QUALCOMM, Inc. 276 5775 Morehouse Dr 277 San Diego, CA 278 USA 280 Phone: +1 858-845-2483 281 Email: vidyan@qualcomm.com 283 Glen Zorn 285 Email: glenzorn@comcast.net 287 Full Copyright Statement 289 Copyright (C) The IETF Trust (2008). 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 298 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 299 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 300 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org. 327 Acknowledgment 329 Funding for the RFC Editor function is provided by the IETF 330 Administrative Support Activity (IASA).