idnits 2.17.1 draft-clancy-emu-aaapay-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 368. 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 31, 2008) is 5747 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) == Outdated reference: A later version (-17) exists of draft-ietf-emu-eap-gpsk-11 == Outdated reference: A later version (-04) exists of draft-clancy-emu-chbind-02 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Clancy 3 Internet-Draft LTS 4 Intended status: Standards Track July 31, 2008 5 Expires: February 1, 2009 7 EAP Method Support for Transporting AAA Payloads 8 draft-clancy-emu-aaapay-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 1, 2009. 35 Abstract 37 This document defines bindings for existing EAP methods to transport 38 Diameter AVPs, called "AAA payloads". The primary application is to 39 support EAP channel bindings, but this could be used for other 40 applications as well. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3 50 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 5 53 5.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 5 54 5.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 5 55 5.3. Passord Authenticated Exchange (PAX) . . . . . . . . . . . 6 56 5.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 6 57 5.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 9 70 1. Introduction 72 This document defines a payload which can be securely transported by 73 an Extensible Authentication Method (EAP) method [RFC3748] that 74 carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. 75 While it may seem strange for EAP to encapsulate Authorization, 76 Authentication, and Accounting (AAA) messages, since AAA typically 77 encapsulates EAP, the security properties are different. In 78 particular, AAA data transported by EAP between the client and server 79 will be protected by an end-to-end security relationship. This 80 provides a secure channel for doing things like channel bindings 81 [RFC5056]. 83 2. Terminology 85 In this document, several words are used to signify the requirements 86 of the specification. These words are often capitalized. The key 87 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 88 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 89 are to be interpreted as described in [RFC2119]. 91 3. Overview and Requirements 93 Many EAP [RFC3748] methods have extensible properties that allow you 94 to embed arbitrary data within a secure channel. This channel is 95 secured using keys derived during the EAP authentication. These 96 channels vary in the properties that they provide, typically either 97 providing integrity protection or both confidentiality and integrity 98 protection. 100 In this document we define a payload format for encapsulating 101 Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], 102 RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing 103 EAP methods that would allow them to transport this data. One 104 specific application of this is to support EAP channel bindings 105 [RFC5056][I-D.clancy-emu-chbind]. 107 The main goal is to provide the peer and server to exchange AAA 108 messages protected by an end-to-end security association. As such, 109 any EAP method transporting the AAA payloads defined in this document 110 MUST support integrity protection. To accomplish this, a method 111 supporting AAA payloads MUST perform mutual authentication and derive 112 session keys (i.e. MSK, etc), and during this derivation process 113 MUST derive a unique, cryptographically independent, fresh key for 114 protecting AAA payloads. Protocols SHOULD also support 115 confidentiality in addition to integrity protection. Confidentiality 116 is important for identity protection, as a variety of identities can 117 be passed over this channel. 119 4. AAA Payload Format 121 This section describes the formatting for the AAA Payloads. Each 122 payload consists of the following fields: 124 o Version, 1 octet 125 o Flags, 1 octet 126 o length(Session-ID), 2 octets 127 o Session-ID [I-D.ietf-eap-keying], arbitrary length 128 o One or more Diameter AVPs [RFC3588], arbitrary length 130 The version field is 1 octet. This documents defines version 0x01. 132 The flags field is 1 octet, and is the logical AND of the following 133 applicable values: 135 o 0x01: Validation Failed 136 o 0x02: Validation Inconclusive 137 o 0x04: Validation Successful 139 The validation flag fields are used by the EAP server to convey the 140 success of the consistency check to the EAP peer. These flags SHOULD 141 NOT be used in messages from the peer to server. 143 The Session-ID field is arbitrary length and is proceeded by its 144 2-octet length specified in network-byte order. 146 Following the Session-ID is an arbitrary number of Diameter AVPs. 147 AVPs already contain a length field internally, so they can be parsed 148 without additional information. 150 The payload can be graphically depicted as: 152 --- bit offset ---> 153 0 1 2 3 154 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Version=0x01 | Flags | length(Session-ID) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 ... Session-ID ... 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ... Diameter AVP 1 ... 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ... ... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 ... Diameter AVP N ... 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1 175 5. Bindings for Existing EAP Methods 177 This section describes how binding tokens can be included in all 178 current EAP methods that support secure transport of arbitrary data. 179 Future EAP methods SHOULD describe how they can implement binding 180 tokens. 182 5.1. Generalized Pre-Shared Key (GPSK) 184 EAP-GPSK [I-D.ietf-emu-eap-gpsk] defines protected data payloads. 185 Use by GPSK simply requires instantiation of a new protected data 186 specifier (PData/Specifier): 188 o 0x0000002 (IANA-TBD): AAA Payload 190 5.2. Pre-Shared Key (PSK) 192 EAP-PSK [RFC4764] defines a protected channel. Use by PSK simply 193 requires instantiation of a new EXT_Type value: 195 o 0x01 (IANA-TBD): AAA Payload 197 5.3. Passord Authenticated Exchange (PAX) 199 EAP-PAX [RFC4746] defines an authenticated data exchange (ADE). Use 200 by PAX simply requires instantiation of a new ADE type: 202 o 0x04 (IANA-TBD): AAA Payload 204 5.4. Tunneled Transport Layer Security (TTLS) 206 EAP-TTLS [I-D.funk-eap-ttls-v0] uses Diameter Attribute-Value-Pairs 207 (AVPs) for its messaging. As such it natively supports transporting 208 AAA payloads. No protocol changes are necessary. 210 5.5. Flexible Authentication via Secure Tunneling (FAST) 212 EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. 213 To embed binding tokens, a new TLV must be defined: 215 o 0x15 (IANA-TBD): AAA Payload 217 6. Security Considerations 219 Section 3 documented a variety of requirements for EAP methods to 220 transport these AAA payloads. They MUST support identity protection 221 of arbitrary payloads, and SHOULD support confidentiality. Each 222 method's security considerations section would detail how they 223 achieve those requirements. 225 The payload includes the EAP Session-ID field. This is to prevent 226 replay attacks. In particular, depending on how an EAP method 227 implements their secured channel, it may or may not be 228 cryptographically bound to the rest of the session. By explicitly 229 including the EAP Session-ID, we prevent replay attacks. 230 Implementations MUST verify the consistency of the Session-ID 231 received in the AAA payloads. 233 Certainly there are a whole host of issues surrounding the security 234 of what may be contained within the AAA payload format. If the 235 information being transported requires confidentiality, then the 236 method SHOULD support that. Otherwise sensitive data could be 237 disclosed. 239 7. IANA Considerations 241 We require registry from a variety of IANA repositories. 243 From "EAP-GPSK PData/Specifier": 245 o 0x0000002 (IANA-TBD): AAA Payload 247 From "EAP EXT_Type Numbers": 249 o 0x01 (IANA-TBD): AAA Payload 251 From "EAP-PAX ADE Type Namespace": 253 o 0x04 (IANA-TBD): AAA Payload 255 From "EAP-FAST TLV Types": 257 o 0x15 (IANA-TBD): AAA Payload 259 8. References 261 8.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, March 1997. 266 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 267 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 269 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 270 Levkowetz, "Extensible Authentication Protocol (EAP)", 271 RFC 3748, June 2004. 273 8.2. Informative References 275 [I-D.ietf-eap-keying] 276 Aboba, B., Simon, D., and P. Eronen, "Extensible 277 Authentication Protocol (EAP) Key Management Framework", 278 draft-ietf-eap-keying-22 (work in progress), 279 November 2007. 281 [I-D.ietf-emu-eap-gpsk] 282 Clancy, C. and H. Tschofenig, "EAP Generalized Pre-Shared 283 Key (EAP-GPSK) Method", draft-ietf-emu-eap-gpsk-11 (work 284 in progress), July 2008. 286 [I-D.funk-eap-ttls-v0] 287 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 288 Authentication Protocol Version 0 (EAP-TTLSv0)", 289 draft-funk-eap-ttls-v0-05 (work in progress), April 2008. 291 [I-D.clancy-emu-chbind] 292 Clancy, T. and K. Hoeper, "Channel Binding Support for EAP 293 Methods", Internet Draft draft-clancy-emu-chbind-02, 294 July 2008. 296 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 297 "Remote Authentication Dial In User Service (RADIUS)", 298 RFC 2865, June 2000. 300 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 301 "Diameter Network Access Server Application", RFC 4005, 302 August 2005. 304 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 305 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 306 November 2006. 308 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 309 Pre-Shared Key Extensible Authentication Protocol (EAP) 310 Method", RFC 4764, January 2007. 312 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 313 Flexible Authentication via Secure Tunneling Extensible 314 Authentication Protocol Method (EAP-FAST)", RFC 4851, 315 May 2007. 317 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 318 Channels", RFC 5056, November 2007. 320 Author's Address 322 T. Charles Clancy 323 Laboratory for Telecommunications Sciences 324 US Department of Defense 325 College Park, MD 326 USA 328 Email: clancy@LTSnet.net 330 Full Copyright Statement 332 Copyright (C) The IETF Trust (2008). 334 This document is subject to the rights, licenses and restrictions 335 contained in BCP 78, and except as set forth therein, the authors 336 retain all their rights. 338 This document and the information contained herein are provided on an 339 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 340 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 341 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 342 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 343 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 346 Intellectual Property 348 The IETF takes no position regarding the validity or scope of any 349 Intellectual Property Rights or other rights that might be claimed to 350 pertain to the implementation or use of the technology described in 351 this document or the extent to which any license under such rights 352 might or might not be available; nor does it represent that it has 353 made any independent effort to identify any such rights. Information 354 on the procedures with respect to rights in RFC documents can be 355 found in BCP 78 and BCP 79. 357 Copies of IPR disclosures made to the IETF Secretariat and any 358 assurances of licenses to be made available, or the result of an 359 attempt made to obtain a general license or permission for the use of 360 such proprietary rights by implementers or users of this 361 specification can be obtained from the IETF on-line IPR repository at 362 http://www.ietf.org/ipr. 364 The IETF invites any interested party to bring to its attention any 365 copyrights, patents or patent applications, or other proprietary 366 rights that may cover technology that may be required to implement 367 this standard. Please address the information to the IETF at 368 ietf-ipr@ietf.org.