idnits 2.17.1 draft-clancy-emu-aaapay-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (May 3, 2009) is 5472 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 (-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 (~~), 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 5 Expires: November 4, 2009 BWS 6 G. Zorn, Ed. 7 Network Zen 8 May 3, 2009 10 EAP Method Support for Transporting AAA Payloads 11 draft-clancy-emu-aaapay-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on November 4, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines bindings for existing EAP methods to transport 60 Diameter AVPs, called "AAA payloads". The primary application is to 61 support EAP channel bindings, but this could be used for other 62 applications as well. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3 72 4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 5 75 5.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 5 76 5.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 5 77 5.3. Passord Authenticated Exchange (PAX) . . . . . . . . . . . 6 78 5.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 6 79 5.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 91 1. Introduction 93 This document defines a payload which can be securely transported by 94 an Extensible Authentication Method (EAP) method [RFC3748] that 95 carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588]. 96 While it may seem strange for EAP to encapsulate Authorization, 97 Authentication, and Accounting (AAA) messages, since AAA typically 98 encapsulates EAP, the security properties are different. In 99 particular, AAA data transported by EAP between the client and server 100 will be protected by an end-to-end security relationship. This 101 provides a secure channel for doing things like channel bindings 102 [RFC5056]. 104 2. Terminology 106 In this document, several words are used to signify the requirements 107 of the specification. These words are often capitalized. The key 108 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 109 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 110 are to be interpreted as described in [RFC2119]. 112 3. Overview and Requirements 114 Many EAP [RFC3748] methods have extensible properties that allow you 115 to embed arbitrary data within a secure channel. This channel is 116 secured using keys derived during the EAP authentication. These 117 channels vary in the properties that they provide, typically either 118 providing integrity protection or both confidentiality and integrity 119 protection. 121 In this document we define a payload format for encapsulating 122 Diameter AVPs [RFC3588], and via backwards compatability [RFC4005], 123 RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing 124 EAP methods that would allow them to transport this data. One 125 specific application of this is to support EAP channel bindings 126 [RFC5056][I-D.clancy-emu-chbind]. 128 The main goal is to provide the peer and server to exchange AAA 129 messages protected by an end-to-end security association. As such, 130 any EAP method transporting the AAA payloads defined in this document 131 MUST support integrity protection. To accomplish this, a method 132 supporting AAA payloads MUST perform mutual authentication and derive 133 session keys (i.e. MSK, etc), and during this derivation process 134 MUST derive a unique, cryptographically independent, fresh key for 135 protecting AAA payloads. Protocols SHOULD also support 136 confidentiality in addition to integrity protection. Confidentiality 137 is important for identity protection, as a variety of identities can 138 be passed over this channel. 140 4. AAA Payload Format 142 This section describes the formatting for the AAA Payloads. Each 143 payload consists of the following fields: 145 o Version, 1 octet 146 o Flags, 1 octet 147 o length(Session-ID), 2 octets 148 o Session-ID [I-D.ietf-eap-keying], arbitrary length 149 o One or more Diameter AVPs [RFC3588], arbitrary length 151 The version field is 1 octet. This documents defines version 0x01. 153 The flags field is 1 octet, and is the logical AND of the following 154 applicable values: 156 o 0x01: Validation Failed 157 o 0x02: Validation Inconclusive 158 o 0x04: Validation Successful 160 The validation flag fields are used by the EAP server to convey the 161 success of the consistency check to the EAP peer. These flags SHOULD 162 NOT be used in messages from the peer to server. 164 The Session-ID field is arbitrary length and is proceeded by its 165 2-octet length specified in network-byte order. 167 Following the Session-ID is an arbitrary number of Diameter AVPs. 168 AVPs already contain a length field internally, so they can be parsed 169 without additional information. 171 The payload can be graphically depicted as: 173 --- bit offset ---> 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Version=0x01 | Flags | length(Session-ID) | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | 180 ... Session-ID ... 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 ... Diameter AVP 1 ... 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ... ... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 ... Diameter AVP N ... 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1 196 5. Bindings for Existing EAP Methods 198 This section describes how binding tokens can be included in all 199 current EAP methods that support secure transport of arbitrary data. 200 Future EAP methods SHOULD describe how they can implement binding 201 tokens. 203 5.1. Generalized Pre-Shared Key (GPSK) 205 EAP-GPSK [I-D.ietf-emu-eap-gpsk] defines protected data payloads. 206 Use by GPSK simply requires instantiation of a new protected data 207 specifier (PData/Specifier): 209 o 0x0000002 (IANA-TBD): AAA Payload 211 5.2. Pre-Shared Key (PSK) 213 EAP-PSK [RFC4764] defines a protected channel. Use by PSK simply 214 requires instantiation of a new EXT_Type value: 216 o 0x01 (IANA-TBD): AAA Payload 218 5.3. Passord Authenticated Exchange (PAX) 220 EAP-PAX [RFC4746] defines an authenticated data exchange (ADE). Use 221 by PAX simply requires instantiation of a new ADE type: 223 o 0x04 (IANA-TBD): AAA Payload 225 5.4. Tunneled Transport Layer Security (TTLS) 227 EAP-TTLS [I-D.funk-eap-ttls-v0] uses Diameter Attribute-Value-Pairs 228 (AVPs) for its messaging. As such it natively supports transporting 229 AAA payloads. No protocol changes are necessary. 231 5.5. Flexible Authentication via Secure Tunneling (FAST) 233 EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging. 234 To embed binding tokens, a new TLV must be defined: 236 o 0x15 (IANA-TBD): AAA Payload 238 6. Security Considerations 240 Section 3 documented a variety of requirements for EAP methods to 241 transport these AAA payloads. They MUST support identity protection 242 of arbitrary payloads, and SHOULD support confidentiality. Each 243 method's security considerations section would detail how they 244 achieve those requirements. 246 The payload includes the EAP Session-ID field. This is to prevent 247 replay attacks. In particular, depending on how an EAP method 248 implements their secured channel, it may or may not be 249 cryptographically bound to the rest of the session. By explicitly 250 including the EAP Session-ID, we prevent replay attacks. 251 Implementations MUST verify the consistency of the Session-ID 252 received in the AAA payloads. 254 Certainly there are a whole host of issues surrounding the security 255 of what may be contained within the AAA payload format. If the 256 information being transported requires confidentiality, then the 257 method SHOULD support that. Otherwise sensitive data could be 258 disclosed. 260 7. IANA Considerations 262 We require registry from a variety of IANA repositories. 264 From "EAP-GPSK PData/Specifier": 266 o 0x0000002 (IANA-TBD): AAA Payload 268 From "EAP EXT_Type Numbers": 270 o 0x01 (IANA-TBD): AAA Payload 272 From "EAP-PAX ADE Type Namespace": 274 o 0x04 (IANA-TBD): AAA Payload 276 From "EAP-FAST TLV Types": 278 o 0x15 (IANA-TBD): AAA Payload 280 8. References 282 8.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 288 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 290 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 291 Levkowetz, "Extensible Authentication Protocol (EAP)", 292 RFC 3748, June 2004. 294 8.2. Informative References 296 [I-D.ietf-eap-keying] 297 Aboba, B., Simon, D., and P. Eronen, "Extensible 298 Authentication Protocol (EAP) Key Management Framework", 299 draft-ietf-eap-keying-22 (work in progress), 300 November 2007. 302 [I-D.ietf-emu-eap-gpsk] 303 Clancy, C. and H. Tschofenig, "EAP Generalized Pre-Shared 304 Key (EAP-GPSK) Method", draft-ietf-emu-eap-gpsk-17 (work 305 in progress), November 2008. 307 [I-D.funk-eap-ttls-v0] 308 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 309 Authentication Protocol Version 0 (EAP-TTLSv0)", 310 draft-funk-eap-ttls-v0-05 (work in progress), April 2008. 312 [I-D.clancy-emu-chbind] 313 Clancy, T. and K. Hoeper, "Channel Binding Support for EAP 314 Methods", Internet Draft draft-clancy-emu-chbind-02, 315 July 2008. 317 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 318 "Remote Authentication Dial In User Service (RADIUS)", 319 RFC 2865, June 2000. 321 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 322 "Diameter Network Access Server Application", RFC 4005, 323 August 2005. 325 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 326 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 327 November 2006. 329 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 330 Pre-Shared Key Extensible Authentication Protocol (EAP) 331 Method", RFC 4764, January 2007. 333 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 334 Flexible Authentication via Secure Tunneling Extensible 335 Authentication Protocol Method (EAP-FAST)", RFC 4851, 336 May 2007. 338 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 339 Channels", RFC 5056, November 2007. 341 Authors' Addresses 343 T. Charles Clancy 344 Laboratory for Telecommunications Sciences 345 US Department of Defense 346 College Park, MD 347 USA 349 Email: clancy@LTSnet.net 350 Avi Lior 351 Bridgewater Systems Corporation 352 303 Terry Fox Drive 353 Suite 100 354 Ottawa, Ontario K2K 3J1 355 Canada 357 Phone: +1 (613) 591-6655 358 Email: avi@bridgewatersystems.com 359 URI: http://www.bridgewatersystems.com/ 361 Glen Zorn (editor) 362 Network Zen 363 1310 East Thomas Street 364 Seattle, Washington 98102 365 US 367 Phone: +1 (206) 377-9035 368 Email: gwz@net-zen.net