idnits 2.17.1 draft-clancy-emu-aaapay-00.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 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. 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 (February 18, 2008) is 5910 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-08 == Outdated reference: A later version (-05) exists of draft-funk-eap-ttls-v0-02 == Outdated reference: A later version (-04) exists of draft-clancy-emu-chbind-00 -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 4 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 February 18, 2008 5 Expires: August 21, 2008 7 EAP Method Support for Transporting AAA Payloads 8 draft-clancy-emu-aaapay-00 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 August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document defines bindings for existing EAP methods to transport 42 Diameter AVPs, called "AAA payloads". The primary application is to 43 support EAP channel bindings, but this could be used for other 44 applications as well. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3 54 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 5 57 5.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 5 58 5.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 5 59 5.3. Passord Authenticated Exchange (PAX) . . . . . . . . . . . 5 60 5.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 5 61 5.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 Intellectual Property and Copyright Statements . . . . . . . . . . 9 74 1. Introduction 76 This document defines a payload which can be securely transported by 77 an Extensible Authentication Method (EAP) method [RFC3748] that 78 carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. 79 While it may seem strange for EAP to encapsulate Authorization, 80 Authentication, and Accounting (AAA) messages, since AAA typically 81 encapsulates EAP, the security properties are different. In 82 particular, AAA data transported by EAP between the client and server 83 will be protected by an end-to-end security relationship. This 84 provides a secure channel for doing things like channel bindings 85 [RFC5056]. 87 2. Terminology 89 In this document, several words are used to signify the requirements 90 of the specification. These words are often capitalized. The key 91 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 92 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 93 are to be interpreted as described in [RFC2119]. 95 3. Overview and Requirements 97 Many EAP [RFC3748] methods have extensible properties that allow you 98 to embed arbitrary data within a secure channel. This channel is 99 secured using keys derived during the EAP authentication. These 100 channels vary in the properties that they provide, typically either 101 providing integrity protection or both confidentiality and integrity 102 protection. 104 In this document we define a payload format for encapsulating 105 Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], 106 RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing 107 EAP methods that would allow them to transport this data. One 108 specific application of this is to support EAP channel bindings 109 [RFC5056][I-D.clancy-emu-chbind]. 111 The main goal is to provide the peer and server to exchange AAA 112 messages protected by an end-to-end security association. As such, 113 any EAP method transporting the AAA payloads defined in this document 114 MUST support integrity protection. To accomplish this, a method 115 supporting AAA payloads MUST perform mutual authentication and derive 116 session keys (i.e. MSK, etc), and during this derivation process 117 MUST derive a unique, cryptographically independent, fresh key for 118 protecting AAA payloads. Protocols SHOULD also support 119 confidentiality in addition to integrity protection. Confidentiality 120 is important for identity protection, as a variety of identities can 121 be passed over this channel. 123 4. AAA Payload Format 125 This section describes the formatting for the AAA Payloads. Each 126 payload consists of the following fields: 128 o Version, 2 octets 129 o length(Session-ID), 2 octets 130 o Session-ID [I-D.ietf-eap-keying], arbitrary length 131 o One or more Diameter AVPs [RFC3588], arbitrary length 133 The version field is 2 octets. This documents defines version 134 0x0001. 136 The Session-ID field is arbitrary length and is proceeded by its 137 2-octet length specified in network-byte order. 139 Following the Session-ID is an arbitrary number of Diameter AVPs. 140 AVPs already contain a length field internally, so they can be parsed 141 without additional information. 143 The payload can be graphically depicted as: 145 --- bit offset ---> 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Version=0x01 | length(Session-ID) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 ... Session-ID ... 153 | | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 ... Diameter AVP 1 ... 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 ... ... 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 ... Diameter AVP N ... 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1 168 5. Bindings for Existing EAP Methods 170 This section describes how binding tokens can be included in all 171 current EAP methods that support secure transport of arbitrary data. 172 Future EAP methods SHOULD describe how they can implement binding 173 tokens. 175 5.1. Generalized Pre-Shared Key (GPSK) 177 EAP-GPSK [I-D.ietf-emu-eap-gpsk] defines protected data payloads. 178 Use by GPSK simply requires instantiation of a new protected data 179 specifier (PData/Specifier): 181 o 0x0000002 (IANA-TBD): AAA Payload 183 5.2. Pre-Shared Key (PSK) 185 EAP-PSK [RFC4764] defines a protected channel. Use by PSK simply 186 requires instantiation of a new EXT_Type value: 188 o 0x01 (IANA-TBD): AAA Payload 190 5.3. Passord Authenticated Exchange (PAX) 192 EAP-PAX [RFC4746] defines an authenticated data exchange (ADE). Use 193 by PAX simply requires instantiation of a new ADE type: 195 o 0x04 (IANA-TBD): AAA Payload 197 5.4. Tunneled Transport Layer Security (TTLS) 199 EAP-TTLS [I-D.funk-eap-ttls-v0] uses Diameter Attribute-Value-Pairs 200 (AVPs) for its messaging. As such it natively supports transporting 201 AAA payloads. No protocol changes are necessary. 203 5.5. Flexible Authentication via Secure Tunneling (FAST) 205 EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. 206 To embed binding tokens, a new TLV must be defined: 208 o 0x15 (IANA-TBD): AAA Payload 210 6. Security Considerations 212 Section 3 documented a variety of requirements for EAP methods to 213 transport these AAA payloads. They MUST support identity protection 214 of arbitrary payloads, and SHOULD support confidentiality. Each 215 method's security considerations section would detail how they 216 achieve those requirements. 218 The payload includes the EAP Session-ID field. This is to prevent 219 replay attacks. In particular, depending on how an EAP method 220 implements their secured channel, it may or may not be 221 cryptographically bound to the rest of the session. By explicitly 222 including the EAP Session-ID, we prevent replay attacks. 223 Implementations MUST verify the consistency of the Session-ID 224 received in the AAA payloads. 226 Certainly there are a whole host of issues surrounding the security 227 of what may be contained within the AAA payload format. If the 228 information being transported requires confidentiality, then the 229 method SHOULD support that. Otherwise sensitive data could be 230 disclosed. 232 7. IANA Considerations 234 We require registry from a variety of IANA repositories. 236 From "EAP-GPSK PData/Specifier": 238 o 0x0000002 (IANA-TBD): AAA Payload 240 From "EAP EXT_Type Numbers": 242 o 0x01 (IANA-TBD): AAA Payload 244 From "EAP-PAX ADE Type Namespace": 246 o 0x04 (IANA-TBD): AAA Payload 248 From "EAP-FAST TLV Types": 250 o 0x15 (IANA-TBD): AAA Payload 252 8. References 254 8.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 260 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 262 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 263 Levkowetz, "Extensible Authentication Protocol (EAP)", 264 RFC 3748, June 2004. 266 8.2. Informative References 268 [I-D.ietf-eap-keying] 269 Aboba, B., Simon, D., and P. Eronen, "Extensible 270 Authentication Protocol (EAP) Key Management Framework", 271 draft-ietf-eap-keying-22 (work in progress), 272 November 2007. 274 [I-D.ietf-emu-eap-gpsk] 275 Clancy, C. and H. Tschofenig, "EAP Generalized Pre-Shared 276 Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-08 (work in 277 progress), December 2007. 279 [I-D.funk-eap-ttls-v0] 280 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 281 Authentication Protocol Version 0 (EAP-TTLSv0)", 282 draft-funk-eap-ttls-v0-02 (work in progress), 283 November 2007. 285 [I-D.clancy-emu-chbind] 286 Clancy, T. and K. Hoeper, "Channel Binding Support for EAP 287 Methods", Internet Draft draft-clancy-emu-chbind-00, 288 February 2008. 290 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 291 "Remote Authentication Dial In User Service (RADIUS)", 292 RFC 2865, June 2000. 294 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 295 "Diameter Network Access Server Application", RFC 4005, 296 August 2005. 298 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 299 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 300 November 2006. 302 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 303 Pre-Shared Key Extensible Authentication Protocol (EAP) 304 Method", RFC 4764, January 2007. 306 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 307 Flexible Authentication via Secure Tunneling Extensible 308 Authentication Protocol Method (EAP-FAST)", RFC 4851, 309 May 2007. 311 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 312 Channels", RFC 5056, November 2007. 314 Author's Address 316 T. Charles Clancy 317 DoD Laboratory for Telecommunications Sciences 318 8080 Greenmead Drive 319 College Park, MD 20740 320 USA 322 Email: clancy@ltsnet.net 324 Full Copyright Statement 326 Copyright (C) The IETF Trust (2008). 328 This document is subject to the rights, licenses and restrictions 329 contained in BCP 78, and except as set forth therein, the authors 330 retain all their rights. 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 335 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 336 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 337 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Intellectual Property 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 364 Acknowledgment 366 Funding for the RFC Editor function is provided by the IETF 367 Administrative Support Activity (IASA).