idnits 2.17.1 draft-ietf-abfab-eapapplicability-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3748, but the abstract doesn't seem to directly say this. It does mention RFC3748 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3748, updated by this document, for RFC5378 checks: 2003-02-10) -- 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 (August 19, 2013) is 3874 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 informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ABFAB Working Group S. Winter 3 Internet-Draft RESTENA 4 Updates: 3748 (if approved) J. Salowey 5 Intended status: Standards Track Cisco 6 Expires: February 20, 2014 August 19, 2013 8 Update to the EAP Applicability Statement for ABFAB 9 draft-ietf-abfab-eapapplicability-06 11 Abstract 13 This document updates the Extensible Authentication Protocol (EAP) 14 applicability statement from RFC3748 to reflect recent usage of the 15 EAP protocol in the Application Bridging for Federated Access Beyond 16 web (ABFAB) architecture. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 20, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Uses of EAP for Application-Layer Access . . . . . . . . . . 2 55 2.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Re-Authentication . . . . . . . . . . . . . . . . . . . . 4 57 3. Revised EAP applicability statement . . . . . . . . . . . . . 5 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 7.2. Informational References . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The EAP applicability statement in [RFC3748] defines the scope of the 68 Extensible Authentication Protocol to be "for use in network access 69 authentication, where IP layer connectivity may not be available.", 70 and states that "Use of EAP for other purposes, such as bulk data 71 transport, is NOT RECOMMENDED.". 73 While some of the recommendation against usage of EAP for bulk data 74 transport is still valid, some of the other provisions in the 75 applicability statement have turned out to be too narrow. Section 2 76 describes the example where EAP is used to authenticate application 77 layer access. Section 3 provides new text to update the paragraph 78 1.3. "Applicability" in [RFC3748]. 80 1.1. Requirements Language 82 In this document, several words are used to signify the requirements 83 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 84 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 85 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 86 interpreted as described in RFC 2119. [RFC2119] 88 2. Uses of EAP for Application-Layer Access 90 Ongoing work in the IETF specifies the use of EAP over GSSAPI for 91 generic application layer access [I-D.ietf-abfab-gss-eap]. In the 92 past, using EAP in this context has met resistance due to the lack of 93 channel bindings [RFC6677]. Without channel bindings, a peer cannot 94 verify if an authenticator is authorized to provide an advertised 95 service. 97 However as additional services use EAP for authentication, the 98 distinction of which service is being contacted becomes more 99 important. Application services might have different properties. 100 Consider an environment with multiple printers some of which provide 101 a confidential service to output documents to a controlled location. 102 If a peer sent a document to the wrong service then potentially 103 sensitive information might be printed in an uncontrolled location 104 and be disclosed. In addition, it might be more likely that a low- 105 value service is compromised than some high value service. If the 106 high-value service could be impersonated by a low-value service then 107 the security of the overall system would be limited by the security 108 of the lower value service. 110 This distinction is present in any environment where peers' security 111 depends on which service they reach. However it is particularly 112 acute in a federated environment where multiple organizations are 113 involved. It is very likely that these organizations will have 114 different security policies and practices. It is very likely that 115 the goals of these organizations will not entirely be aligned. In 116 many situations one organization could gain value by being able to 117 impersonate another. In this environment, authenticating the EAP 118 server is insufficient: the peer must also validate that the 119 contacted host is authorized to provide the requested service. 121 In environments where EAP is used for purposes other than network 122 access authentication: 124 o All EAP servers and all application access EAP peers MUST support 125 channel bindings. All network access EAP peers SHOULD support 126 channel bindings. 128 o Channel binding MUST be used for all application authentication. 129 The EAP server MUST either require that the correct EAP lower- 130 layer attribute or another attribute indicating the purpose of the 131 authentication be present in the channel binding data for 132 application authentication. 134 o Channel binding SHOULD be used for all network access 135 authentication, and when channel binding data is present, the EAP 136 server MUST require that it contain the correct EAP lower-layer 137 attribute to explicitly identify the reason for authentication. 139 o Any new usage of EAP MUST use channel bindings including the EAP 140 lower-layer attribute to prevent confusion with network access 141 usage. 143 Operators need to carefully consider the security implications before 144 relaxing these requirements. One potentially serious attack exists 145 when channel binding is not required and EAP authentication is 146 introduced into an existing service other than network access. A 147 device can be created that impersonates a Network Access Service to 148 peers, but actually proxies the authentication to the new application 149 service that accepts EAP authentications. This may decrease the 150 security of this service even for users who previously used non-EAP 151 means of authentication to the service. 153 It is REQUIRED for the application layer to prove that both the EAP 154 Peer and EAP Authenticator possess the EAP Master Session Key (MSK). 155 Failing to validate the possession of the EAP MSK can allow an 156 attacker to insert himself into the conversation and impersonate the 157 peer or authenticator. In addition, the application should define 158 channel binding attributes that are sufficient to validate that the 159 application service is being correctly represented to the peer. 161 2.1. Retransmission 163 In EAP, the authenticator is responsible for retransmission. By 164 default EAP assumes that the lower layer (the application in this 165 context) is unreliable. The authenticator can send a packet whenever 166 its retransmission timer triggers. In this mode, applications need 167 to be able to receive and process EAP messages at any time during the 168 authentication conversation. 170 Alternatively, EAP permits a lower layer to set the retransmission 171 timer to infinite. When this happens, the lower layer becomes 172 responsible for reliable delivery of EAP messages. Applications that 173 use a lock-step or client-driven authentication protocol might 174 benefit from this approach. 176 In addition to retransmission behavior applications need to deal with 177 discarded EAP messages. For example, whenever some EAP methods 178 receive erroneous input, these methods discard the input rather than 179 generating an error response. If the erroneous input was generated 180 by an attacker, legitimate input can sometimes be received after the 181 erroneous input. Applications MUST handle discarded EAP messages, 182 although the specific way in which discarded messages will be handled 183 depends on the characteristics of the application. Options include 184 failing the authentication at the application level, requesting an 185 EAP retransmit and waiting for additional EAP input. 187 Applications designers that incorporate EAP into their application 188 need to determine how retransmission and message discards are 189 handled. 191 2.2. Re-Authentication 192 EAP lower layers MAY provide a mechanism for re-authentication to 193 happen within an existing session [RFC3748]. Re-authentication 194 permits security associations to be updated without establishing a 195 new session. For network access, this can be important because 196 interrupting network access can disrupt connections and media. 198 Some applications might not need re-authentication support. For 199 example if sessions are relatively short-lived or if sessions can be 200 replaced without significant disruption, re-authentication might not 201 provide value. Protocols like Hypertext Transfer Protocol (HTTP) 202 [RFC2616] and Simple Mail Transport Protocol (SMTP) [RFC5321] are 203 examples of protocols where establishing a new connection to update 204 security associations is likely to be sufficient. 206 Re-authentication is likely to be valuable if sessions or connections 207 are long-lived or if there is a significant cost to disrupting them. 209 Another factor may make re-authentication important. Some protocols 210 only permit one party in a protocol (for example the client) to 211 establish a new connection. If another party in the protocol needs 212 the security association refreshed then re-authentication can provide 213 a mechanism to do so. 215 Application designers need to determine whether re-authentication 216 support is needed and which parties can initiate it. 218 3. Revised EAP applicability statement 220 The following text is added to the EAP applicability statement in 221 [RFC3748]. 223 In cases where EAP is used for application authentication, support 224 for EAP Channel Bindings is REQUIRED on the EAP Peer and EAP Server 225 to validate that the host is authorized to provide the services 226 requested. In addition, the application MUST define channel binding 227 attributes that are sufficient to validate that the application 228 service is being correctly represented to the peer. The protocol 229 carrying EAP MUST prove possession of the EAP MSK between the EAP 230 Peer and EAP Authenticator. In the context of EAP for application 231 access the application is providing the EAP Lower Layer. 232 Applications protocols vary so their specific behavior and transport 233 characteristics needs to be considered when determining their 234 retransmission and re-authentication behavior. Circumstances might 235 require that applications need to perform conversion of identities 236 from an application specific character set to UTF-8 or another 237 character set required by a particular EAP method. 239 4. Security Considerations 241 In addition to the requirements discussed in the main sections of the 242 document applications should take into account how server 243 authentication is achieved. Some deployments may allow for weak 244 server authentication that is then validated with an additional 245 existing exchange that provides mutual authentication. In order to 246 fully mitigate the risk of NAS impersonation when these mechanisms 247 are used, it is RECOMMENDED that mutual channel bindings be used to 248 bind the authentications together as described in 249 [I-D.ietf-emu-crypto-bind]. When doing channel binding it is 250 REQUIRED that the authenticator is not able to modify the channel 251 binding data passed between the peer to the authenticator as part of 252 the authentication process. 254 5. IANA Considerations 256 This document has no actions for IANA. 258 6. Acknowledgements 260 Large amounts of helpful text and insightful thoughts were 261 contributed by Sam Hartman, Painless Security. David Black 262 contributed to the text clarifying channel bindings usage. 264 7. References 266 7.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 272 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 273 3748, June 2004. 275 [RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding 276 Support for Extensible Authentication Protocol (EAP) 277 Methods", RFC 6677, July 2012. 279 7.2. Informational References 281 [I-D.ietf-emu-crypto-bind] 282 Hartman, S., Wasserman, M., and D. Zhang, "EAP Mutual 283 Cryptographic Binding", draft-ietf-emu-crypto-bind-04 284 (work in progress), July 2013. 286 [I-D.ietf-abfab-gss-eap] 287 Hartman, S. and J. Howlett, "A GSS-API Mechanism for the 288 Extensible Authentication Protocol", draft-ietf-abfab-gss- 289 eap-09 (work in progress), August 2012. 291 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 292 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 293 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 295 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 296 October 2008. 298 Authors' Addresses 300 Stefan Winter 301 Fondation RESTENA 302 6, rue Richard Coudenhove-Kalergi 303 Luxembourg 1359 304 LUXEMBOURG 306 Phone: +352 424409 1 307 Fax: +352 422473 308 EMail: stefan.winter@restena.lu 309 URI: http://www.restena.lu. 311 Joseph Salowey 312 Cisco Systems 313 2901 3rd Ave 314 Seattle, Washington 98121 315 USA 317 EMail: jsalowey@cisco.com