idnits 2.17.1 draft-clancy-emu-aaapay-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2009) is 5277 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) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-16) exists of draft-ietf-emu-chbind-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 A. Lior, Ed. 5 Expires: May 16, 2010 BWS 6 G. Zorn 7 Network Zen 8 K. Hoeper 9 Motorola, Inc. 10 November 12, 2009 12 EAP Method Support for Transporting AAA Payloads 13 draft-clancy-emu-aaapay-03.txt 15 Abstract 17 This document defines bindings for existing EAP methods to transport 18 Diameter AVPs, called "AAA payloads". The primary application is to 19 support EAP channel bindings, but this could be used for other 20 applications as well. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on May 16, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3 80 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 82 5. Bindings Requirements for EAP Methods . . . . . . . . . . . . . 5 84 6. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 6 85 6.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 6 86 6.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 6 87 6.3. Password Authenticated Exchange (PAX) . . . . . . . . . . . 6 88 6.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 7 89 6.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 7 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 101 1. Introduction 103 This document defines a payload which can be securely transported by 104 an Extensible Authentication Method (EAP) method [RFC3748] that 105 carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. 106 While it may seem strange for EAP to encapsulate Authorization, 107 Authentication, and Accounting (AAA) messages, since AAA typically 108 encapsulates EAP, the security properties are different. In 109 particular, AAA data transported by EAP between the client and server 110 will be protected by an end-to-end security relationship. This 111 provides a secure channel for doing things like channel bindings 112 [RFC5056]. 114 2. Terminology 116 In this document, several words are used to signify the requirements 117 of the specification. These words are often capitalized. The key 118 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 119 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 120 are to be interpreted as described in [RFC2119]. 122 3. Overview and Requirements 124 Many EAP [RFC3748] methods have extensible properties that allow you 125 to embed arbitrary data within a secure channel. This channel is 126 secured using keys derived during the EAP authentication. These 127 channels vary in the properties that they provide, typically either 128 providing integrity protection or both confidentiality and integrity 129 protection. 131 In this document we define a payload format for encapsulating 132 Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], 133 RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing 134 EAP methods that would allow them to transport this data. One 135 specific application of this is to support EAP channel bindings 136 [RFC5056][I-D.ietf-emu-chbind]. 138 The main goal is to provide the peer and server to exchange AAA 139 messages protected by an end-to-end security association. As such, 140 any EAP method transporting the AAA payloads defined in this document 141 MUST support integrity protection. To accomplish this, a method 142 supporting AAA payloads MUST perform mutual authentication and derive 143 session keys (i.e. MSK, etc), and during this derivation process 144 MUST derive a unique, cryptographically independent, fresh key for 145 protecting AAA payloads. Protocols SHOULD also support 146 confidentiality in addition to integrity protection. Confidentiality 147 is important for identity protection, as a variety of identities can 148 be passed over this channel. 150 4. AAA Payload Format 152 This section describes the formatting for the AAA Payloads. Each 153 payload consists of the following fields: 155 o Version, 1 octet 156 o Flags, 1 octet 157 o length(Session-ID), 2 octets 158 o Session-ID [RFC5247], arbitrary length 159 o One or more Diameter AVPs [RFC3588], arbitrary length 161 The version field is 1 octet. This documents defines version 0x01. 163 The flags field is 1 octet, and is the logical AND of the following 164 applicable values: 166 o 0x01: Validation Failed 167 o 0x02: Validation Inconclusive 168 o 0x04: Validation Successful 170 The validation flag fields are used by the EAP server to convey the 171 success of the consistency check to the EAP peer. These flags SHOULD 172 NOT be used in messages from the peer to server. 174 The Session-ID field is arbitrary length and is proceeded by its 175 2-octet length specified in network-byte order. 177 Following the Session-ID is an arbitrary number of Diameter AVPs. 178 AVPs already contain a length field internally, so they can be parsed 179 without additional information. 181 The payload can be graphically depicted as: 183 --- bit offset ---> 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Version=0x01 | Flags | length(Session-ID) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 ... Session-ID ... 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 ... Diameter AVP 1 ... 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 ... ... 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 ... Diameter AVP N ... 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 1 206 5. Bindings Requirements for EAP Methods 208 This section describes a set of general requirements for EAP methods 209 implementing the protected exchange of arbitrary data using the 210 techniques described in this draft. 212 An EAP method requiring the protected exchange of payloads during its 213 execution in order to enable certain features MUST: 215 o support at least one secure cryptographic algorithm that can be 216 used for integrity protection, such as an HMAC; 217 o derive a session key that can be used in the integrity protection 218 algorithm, as soon as fresh EAP session keys are available; and 219 o define a container enabling the exchange of arbitrary payloads; 220 and 221 o provide an integrity-protected channel for at least 3 protocols 222 flows (i.e. 1.5 roundtrips) in which containers with payloads can 223 be securely exchanged 225 Optionally an EAP method MAY also support an encryption algorithm 226 that is used with a freshly derived encryption key to provide 227 confidentiality of all data that is exchanged in the protected 228 channel. 230 Only existing EAP methods already satisfying these requirements can 231 support features that require the protected exchange of AAA payloads. 233 New EAP methods SHOULD be designed to meet all requirements. 235 For features demanding the protected exchange of potentially large 236 chunks of information, the support of fragmentation is RECOMMENDED. 238 6. Bindings for Existing EAP Methods 240 This section describes how binding tokens can be included in some 241 existing EAP methods that already meet the requirements for secure 242 transport of arbitrary data as specified in Section 5. 244 6.1. Generalized Pre-Shared Key (GPSK) 246 EAP-GPSK [RFC5433] defines protected data payloads. The protected 247 channel is available in three of its protocol flows, namely 248 EAP-GPSK-2, EAP-GPSK-3, and EAP-GPSK-4, and provides integrity- 249 protection. If a ciphersuite with encryption is selected (e.g. 250 Ciphersuite 1 in [RFC5433]) the channel also provides 251 confidentiality. 253 Use by GPSK simply requires instantiation of a new protected data 254 specifier (PData/Specifier): 256 o 0x0000002 (IANA-TBD): AAA Payload 258 6.2. Pre-Shared Key (PSK) 260 EAP-PSK [RFC4764] defines a protected channel. In its standard mode, 261 EAP-PSK provides a protected channel for payloads in two of its 262 flows, namely EAP-PSK-2 and EAP-PSK-3. Features requiring additional 263 flows can be supported in EAP-PSK extended authentication mode. The 264 protected channel is integrity-protected and encrypted. 266 Use by PSK simply requires instantiation of a new EXT_Type value: 268 o 0x01 (IANA-TBD): AAA Payload 270 6.3. Password Authenticated Exchange (PAX) 272 EAP-PAX [RFC4746] provides an authenticated data exchange (ADE) in 273 three of its protocol flows (EAP-PAX-2, EAP-PAX-3, and EAP-PAX-4). 274 The channel provides integrity-protection but no encryption. Channel 275 binding is explicitly supported in EAP-PAX, in which case the ADE 276 flag needs to be set, and the ADE TYPE needs to be set to 0x02 for 277 client channel binding data and to 0x03 for server channel binding 278 data. 280 Additional features could be supported by instantiation of a new ADE 281 type: 283 o 0x04 (IANA-TBD): AAA Payload 285 6.4. Tunneled Transport Layer Security (TTLS) 287 EAP-TTLS [RFC5281] uses Diameter Attribute-Value-Pairs (AVPs) for its 288 messaging. As such it natively supports transporting AAA payloads. 289 Once the TLS tunnel is established, a variable number of flows can be 290 exchanged in the second phase, e.g. to exchange payloads in an 291 integrity-protected and encrypted channel. No protocol changes are 292 necessary. 294 6.5. Flexible Authentication via Secure Tunneling (FAST) 296 EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. 297 Once the TLS tunnel is established a variable number of flows can be 298 exchanged in the second phase, e.g. to exchange payloads in an 299 integrity-protected and encrypted channel. To embed binding tokens, 300 a new TLV must be defined: 302 o 0x15 (IANA-TBD): AAA Payload 304 7. Security Considerations 306 Section 3 documented a variety of requirements for EAP methods to 307 transport these AAA payloads. They MUST support identity protection 308 of arbitrary payloads, and SHOULD support confidentiality. Each 309 method's security considerations section would detail how they 310 achieve those requirements. 312 The payload includes the EAP Session-ID field. This is to prevent 313 replay attacks. In particular, depending on how an EAP method 314 implements their secured channel, it may or may not be 315 cryptographically bound to the rest of the session. By explicitly 316 including the EAP Session-ID, we prevent replay attacks. 317 Implementations MUST verify the consistency of the Session-ID 318 received in the AAA payloads. 320 Certainly there are a whole host of issues surrounding the security 321 of what may be contained within the AAA payload format. If the 322 information being transported requires confidentiality, then the 323 method SHOULD support that. Otherwise sensitive data could be 324 disclosed. 326 8. IANA Considerations 328 We require registry from a variety of IANA repositories. 330 From "EAP-GPSK PData/Specifier": 332 o 0x0000002 (IANA-TBD): AAA Payload 334 From "EAP EXT_Type Numbers": 336 o 0x01 (IANA-TBD): AAA Payload 338 From "EAP-PAX ADE Type Namespace": 340 o 0x04 (IANA-TBD): AAA Payload 342 From "EAP-FAST TLV Types": 344 o 0x15 (IANA-TBD): AAA Payload 346 9. References 348 9.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 354 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 356 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 357 Levkowetz, "Extensible Authentication Protocol (EAP)", 358 RFC 3748, June 2004. 360 9.2. Informative References 362 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 363 "Remote Authentication Dial In User Service (RADIUS)", 364 RFC 2865, June 2000. 366 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 367 Pre-Shared Key Extensible Authentication Protocol (EAP) 368 Method", RFC 4764, January 2007. 370 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 371 "Diameter Network Access Server Application", RFC 4005, 372 August 2005. 374 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 375 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 376 November 2006. 378 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 379 Flexible Authentication via Secure Tunneling Extensible 380 Authentication Protocol Method (EAP-FAST)", RFC 4851, 381 May 2007. 383 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 384 Channels", RFC 5056, November 2007. 386 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 387 Protocol Tunneled Transport Layer Security Authenticated 388 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 390 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 391 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 392 RFC 5433, February 2009. 394 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 395 Authentication Protocol (EAP) Key Management Framework", 396 RFC 5247, August 2008. 398 [I-D.ietf-emu-chbind] 399 Clancy, T. and K. Hoeper, "Channel Binding Support for EAP 400 Methods", draft-ietf-emu-chbind-04 (work in progress), 401 October 2009. 403 Authors' Addresses 405 T. Charles Clancy 406 Laboratory for Telecommunications Sciences 407 US Department of Defense 408 College Park, MD 409 USA 411 Email: clancy@LTSnet.net 412 Avi Lior (editor) 413 Bridgewater Systems Corporation 414 303 Terry Fox Drive 415 Suite 500 416 Ottawa, Ontario K2K 3J1 417 Canada 419 Phone: +1 (613) 591-6655 420 Email: avi@bridgewatersystems.com 421 URI: http://www.bridgewatersystems.com/ 423 Glen Zorn 424 Network Zen 425 1310 East Thomas Street 426 Seattle, Washington 98102 427 US 429 Phone: +1 (206) 377-9035 430 Email: gwz@net-zen.net 432 Katrin Hoeper 433 Motorola, Inc. 434 1301 E. Algonquin Road 435 Schaumburg, Illinois 60196 436 USA 438 Email: khoeper@motorola.com