idnits 2.17.1 draft-clancy-emu-aaapay-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (May 10, 2010) is 5072 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: 1 error (**), 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: November 11, 2010 BWS 6 G. Zorn 7 Network Zen 8 K. Hoeper 9 Motorola, Inc. 10 May 10, 2010 12 EAP Method Support for Transporting AAA Payloads 13 draft-clancy-emu-aaapay-04.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 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 11, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview and Requirements . . . . . . . . . . . . . . . . . . 4 74 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Bindings Requirements for EAP Methods . . . . . . . . . . . . 6 78 6. Bindings for Existing EAP Methods . . . . . . . . . . . . . . 7 79 6.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . 7 80 6.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 7 81 6.3. Password Authenticated Exchange (PAX) . . . . . . . . . . 7 82 6.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 8 83 6.5. Flexible Authentication via Secure Tunneling (FAST) . . . 8 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 95 1. Introduction 97 This document defines a payload which can be securely transported by 98 an Extensible Authentication Method (EAP) method [RFC3748] that 99 carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. 100 While it may seem strange for EAP to encapsulate Authorization, 101 Authentication, and Accounting (AAA) messages, since AAA typically 102 encapsulates EAP, the security properties are different. In 103 particular, AAA data transported by EAP between the client and server 104 will be protected by an end-to-end security relationship. This 105 provides a secure channel for doing things like channel bindings 106 [RFC5056]. 108 2. Terminology 110 In this document, several words are used to signify the requirements 111 of the specification. These words are often capitalized. The key 112 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 113 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 114 are to be interpreted as described in [RFC2119]. 116 3. Overview and Requirements 118 Many EAP [RFC3748] methods have extensible properties that allow you 119 to embed arbitrary data within a secure channel. This channel is 120 secured using keys derived during the EAP authentication. These 121 channels vary in the properties that they provide, typically either 122 providing integrity protection or both confidentiality and integrity 123 protection. 125 In this document we define a payload format for encapsulating 126 Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], 127 RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing 128 EAP methods that would allow them to transport this data. One 129 specific application of this is to support EAP channel bindings 130 [RFC5056][I-D.ietf-emu-chbind]. 132 The main goal is to provide the peer and server to exchange AAA 133 messages protected by an end-to-end security association. As such, 134 any EAP method transporting the AAA payloads defined in this document 135 MUST support integrity protection. To accomplish this, a method 136 supporting AAA payloads MUST perform mutual authentication and derive 137 session keys (i.e. MSK, etc), and during this derivation process 138 MUST derive a unique, cryptographically independent, fresh key for 139 protecting AAA payloads. Protocols SHOULD also support 140 confidentiality in addition to integrity protection. Confidentiality 141 is important for identity protection, as a variety of identities can 142 be passed over this channel. 144 4. AAA Payload Format 146 This section describes the formatting for the AAA Payloads. Each 147 payload consists of the following fields: 149 o Version, 1 octet 150 o Flags, 1 octet 151 o length(Session-ID), 2 octets 152 o Session-ID [RFC5247], arbitrary length 153 o One or more Diameter AVPs [RFC3588], arbitrary length 155 The version field is 1 octet. This documents defines version 0x01. 157 The flags field is 1 octet, and is the logical AND of the following 158 applicable values: 160 o 0x01: Validation Failed 161 o 0x02: Validation Inconclusive 162 o 0x04: Validation Successful 164 The validation flag fields are used by the EAP server to convey the 165 success of the consistency check to the EAP peer. These flags SHOULD 166 NOT be used in messages from the peer to server. 168 The Session-ID field is arbitrary length and is proceeded by its 169 2-octet length specified in network-byte order. 171 Following the Session-ID is an arbitrary number of Diameter AVPs. 172 AVPs already contain a length field internally, so they can be parsed 173 without additional information. 175 The payload can be graphically depicted as: 177 --- bit offset ---> 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Version=0x01 | Flags | length(Session-ID) | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 ... Session-ID ... 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 ... Diameter AVP 1 ... 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 ... ... 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 ... Diameter AVP N ... 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1 200 5. Bindings Requirements for EAP Methods 202 This section describes a set of general requirements for EAP methods 203 implementing the protected exchange of arbitrary data using the 204 techniques described in this draft. 206 An EAP method requiring the protected exchange of payloads during its 207 execution in order to enable certain features MUST: 209 o support at least one secure cryptographic algorithm that can be 210 used for integrity protection, such as an HMAC; 211 o derive a session key that can be used in the integrity protection 212 algorithm, as soon as fresh EAP session keys are available; and 213 o define a container enabling the exchange of arbitrary payloads; 214 and 215 o provide an integrity-protected channel for at least 3 protocols 216 flows (i.e. 1.5 roundtrips) in which containers with payloads can 217 be securely exchanged 219 Optionally an EAP method MAY also support an encryption algorithm 220 that is used with a freshly derived encryption key to provide 221 confidentiality of all data that is exchanged in the protected 222 channel. 224 Only existing EAP methods already satisfying these requirements can 225 support features that require the protected exchange of AAA payloads. 227 New EAP methods SHOULD be designed to meet all requirements. 229 For features demanding the protected exchange of potentially large 230 chunks of information, the support of fragmentation is RECOMMENDED. 232 6. Bindings for Existing EAP Methods 234 This section describes how binding tokens can be included in some 235 existing EAP methods that already meet the requirements for secure 236 transport of arbitrary data as specified in Section 5. 238 6.1. Generalized Pre-Shared Key (GPSK) 240 EAP-GPSK [RFC5433] defines protected data payloads. The protected 241 channel is available in three of its protocol flows, namely 242 EAP-GPSK-2, EAP-GPSK-3, and EAP-GPSK-4, and provides integrity- 243 protection. If a ciphersuite with encryption is selected (e.g. 244 Ciphersuite 1 in [RFC5433]) the channel also provides 245 confidentiality. 247 Use by GPSK simply requires instantiation of a new protected data 248 specifier (PData/Specifier): 250 o 0x0000002 (IANA-TBD): AAA Payload 252 6.2. Pre-Shared Key (PSK) 254 EAP-PSK [RFC4764] defines a protected channel. In its standard mode, 255 EAP-PSK provides a protected channel for payloads in two of its 256 flows, namely EAP-PSK-2 and EAP-PSK-3. Features requiring additional 257 flows can be supported in EAP-PSK extended authentication mode. The 258 protected channel is integrity-protected and encrypted. 260 Use by PSK simply requires instantiation of a new EXT_Type value: 262 o 0x01 (IANA-TBD): AAA Payload 264 6.3. Password Authenticated Exchange (PAX) 266 EAP-PAX [RFC4746] provides an authenticated data exchange (ADE) in 267 three of its protocol flows (EAP-PAX-2, EAP-PAX-3, and EAP-PAX-4). 268 The channel provides integrity-protection but no encryption. Channel 269 binding is explicitly supported in EAP-PAX, in which case the ADE 270 flag needs to be set, and the ADE TYPE needs to be set to 0x02 for 271 client channel binding data and to 0x03 for server channel binding 272 data. 274 Additional features could be supported by instantiation of a new ADE 275 type: 277 o 0x04 (IANA-TBD): AAA Payload 279 6.4. Tunneled Transport Layer Security (TTLS) 281 EAP-TTLS [RFC5281] uses Diameter Attribute-Value-Pairs (AVPs) for its 282 messaging. As such it natively supports transporting AAA payloads. 283 Once the TLS tunnel is established, a variable number of flows can be 284 exchanged in the second phase, e.g. to exchange payloads in an 285 integrity-protected and encrypted channel. No protocol changes are 286 necessary. 288 6.5. Flexible Authentication via Secure Tunneling (FAST) 290 EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. 291 Once the TLS tunnel is established a variable number of flows can be 292 exchanged in the second phase, e.g. to exchange payloads in an 293 integrity-protected and encrypted channel. To embed binding tokens, 294 a new TLV must be defined: 296 o 0x15 (IANA-TBD): AAA Payload 298 7. Security Considerations 300 Section 3 documented a variety of requirements for EAP methods to 301 transport these AAA payloads. They MUST support identity protection 302 of arbitrary payloads, and SHOULD support confidentiality. Each 303 method's security considerations section would detail how they 304 achieve those requirements. 306 The payload includes the EAP Session-ID field. This is to prevent 307 replay attacks. In particular, depending on how an EAP method 308 implements their secured channel, it may or may not be 309 cryptographically bound to the rest of the session. By explicitly 310 including the EAP Session-ID, we prevent replay attacks. 311 Implementations MUST verify the consistency of the Session-ID 312 received in the AAA payloads. 314 Certainly there are a whole host of issues surrounding the security 315 of what may be contained within the AAA payload format. If the 316 information being transported requires confidentiality, then the 317 method SHOULD support that. Otherwise sensitive data could be 318 disclosed. 320 8. IANA Considerations 322 We require registry from a variety of IANA repositories. 324 From "EAP-GPSK PData/Specifier": 326 o 0x0000002 (IANA-TBD): AAA Payload 328 From "EAP EXT_Type Numbers": 330 o 0x01 (IANA-TBD): AAA Payload 332 From "EAP-PAX ADE Type Namespace": 334 o 0x04 (IANA-TBD): AAA Payload 336 From "EAP-FAST TLV Types": 338 o 0x15 (IANA-TBD): AAA Payload 340 9. References 342 9.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 348 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 350 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 351 Levkowetz, "Extensible Authentication Protocol (EAP)", 352 RFC 3748, June 2004. 354 9.2. Informative References 356 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 357 "Remote Authentication Dial In User Service (RADIUS)", 358 RFC 2865, June 2000. 360 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 361 Pre-Shared Key Extensible Authentication Protocol (EAP) 362 Method", RFC 4764, January 2007. 364 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 365 "Diameter Network Access Server Application", RFC 4005, 366 August 2005. 368 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 369 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 370 November 2006. 372 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 373 Flexible Authentication via Secure Tunneling Extensible 374 Authentication Protocol Method (EAP-FAST)", RFC 4851, 375 May 2007. 377 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 378 Channels", RFC 5056, November 2007. 380 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 381 Protocol Tunneled Transport Layer Security Authenticated 382 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 384 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 385 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 386 RFC 5433, February 2009. 388 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 389 Authentication Protocol (EAP) Key Management Framework", 390 RFC 5247, August 2008. 392 [I-D.ietf-emu-chbind] 393 Clancy, T. and K. Hoeper, "Channel Binding Support for EAP 394 Methods", draft-ietf-emu-chbind-04 (work in progress), 395 October 2009. 397 Authors' Addresses 399 T. Charles Clancy 400 Laboratory for Telecommunications Sciences 401 US Department of Defense 402 College Park, MD 403 USA 405 Email: clancy@LTSnet.net 406 Avi Lior (editor) 407 Bridgewater Systems Corporation 408 303 Terry Fox Drive 409 Suite 500 410 Ottawa, Ontario K2K 3J1 411 Canada 413 Phone: +1 (613) 591-6655 414 Email: avi@bridgewatersystems.com 415 URI: http://www.bridgewatersystems.com/ 417 Glen Zorn 418 Network Zen 419 1310 East Thomas Street 420 Seattle, Washington 98102 421 US 423 Phone: +1 (206) 377-9035 424 Email: gwz@net-zen.net 426 Katrin Hoeper 427 Motorola, Inc. 428 1301 E. Algonquin Road 429 Schaumburg, Illinois 60196 430 USA 432 Email: khoeper@motorola.com