idnits 2.17.1 draft-winter-abfab-eapapplicability-02.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 date (July 16, 2012) is 4274 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) -- No information found for draft-hartman-emu-mutual-crypto-bind - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 Intended status: Standards Track J. Salowey 5 Expires: January 17, 2013 Cisco 6 July 16, 2012 8 Update to the EAP Applicability Statement for ABFAB 9 draft-winter-abfab-eapapplicability-02 11 Abstract 13 This document updates the EAP applicability statement from RFC3748 to 14 reflect recent usage of the EAP protocol in application oriented use 15 cases proposed in ABFAB 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 17, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 2. Uses of EAP for Application-Layer Access . . . . . . . . . . . 3 54 3. Revised EAP applicability statement . . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 60 7.2. Informational References . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 The EAP applicability statement in [RFC3748] defines the scope of the 65 Extensible Authentication Protocol to be "for use in network access 66 authentication, where IP layer connectivity may not be available.", 67 and states that "Use of EAP for other purposes, such as bulk data 68 transport, is NOT RECOMMENDED.". 70 While some of the recommendation against usage of EAP for bulk data 71 transport is still valid, some of the other provisions in the 72 applicability statement have turned out to be too narrow. Section 2 73 describes the example where EAP is used to authenticate application 74 layer access. Section 3 provides new text to update the paragraph 75 1.3. "Applicability" in [RFC3748]. 77 1.1. Requirements Language 79 In this document, several words are used to signify the requirements 80 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 81 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 82 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 83 interpreted as described in RFC 2119. [RFC2119] 85 2. Uses of EAP for Application-Layer Access 87 Ongoing work in the IETF (abfab working group) specifies the use of 88 EAP over GSSAPI for generic application layer access. In the past, 89 using EAP in this context has met resistance due to the lack of 90 channel bindings [I-D.ietf-emu-chbind]. Without channel bindings, a 91 peer does not know what service will be provided by the 92 authenticator. In most network access use cases all access servers 93 that are served by a particular EAP server are providing the same or 94 very similar types of service. The peer does not need to 95 differentiate between different access network services supported by 96 the same EAP server. 98 However as additional services use EAP for authentication, the 99 distinction of which service is being contacted becomes more 100 important. Consider an environment with multiple printers; if a peer 101 printed a document in the wrong location then potentially sensitive 102 information might be printing in a location where the user associated 103 with the peer would be unable to retrieve it. It is also likely that 104 services might have different security properties. For example, it 105 might be more likely that a low-value service is compromised than 106 some high value service. If the high-value service could be 107 impersonated by a low-value service then the security of the overall 108 system would be limited by the security 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 For these reasons, channel binding MUST be implemented by peers, EAP 122 servers and AAA servers in environments where EAP authentication is 123 used to access application layer services. In addition, channel 124 binding MUST default to being required by peers for non-network 125 authentication. If the EAP server is aware that authentication is 126 for something other than a network service, it too MUST default to 127 requiring channel binding. Operators need to carefully consider the 128 security implications before relaxing these requirements. One 129 potentially serious attack exists when channel binding is not 130 required and EAP authentication is introduced into an existing non- 131 network service. A device can be created that impersonates a Network 132 Access Service to peers, but actually proxies the authentication to 133 the service that newly accepts EAP authentications may decrease the 134 security of this service even for users who previously used non-EAP 135 means of authentication to the service. 137 It is important for the application layer to prove possession of the 138 EAP MSK between the EAP Peer and EAP Authenticator. In addition, the 139 application should define an channel binding attributes that are 140 sufficient to validate that the application service is being 141 correctly represented to the peer. 143 3. Revised EAP applicability statement 145 The following text is added to the EAP applicability statement in 146 [RFC3748]. 148 In cases where EAP is used for application authentication, support 149 for EAP Channel Bindings is REQUIRED on the EAP Peer and EAP Server 150 to validate that the host is authorized to provide the services 151 requested. In addition, the application MUST define channel binding 152 attributes that are sufficient to validate that the application 153 service is being correctly represented to the peer. It is important 154 for the protocol carrying EAP to prove possession of the EAP MSK 155 between the EAP Peer and EAP Authenticator. 157 4. Security Considerations 159 In addition to the requirements discussed in the main sections of the 160 document applications should take into account how server 161 authentication is achieved. Some deployments may allow for weak 162 server authentication that is then validated with an additional 163 existing exchange that provides mutual authentication. In order to 164 fully mitigate the risk of NAS impersonation when these mechanisms 165 are used, it is RECOMMENDED that mutual channel bindings be used 166 enforced to bind the authentications together as described in 167 [I-D.hartman-emu-mutual-crypto-bind] 169 5. IANA Considerations 171 This document has no actions for IANA. 173 6. Acknowledgements 175 Large amounts of helpful text and insightful thoughts were 176 contributed by Sam Hartman, Painless Security. 178 7. References 180 7.1. Normative References 182 [RFC2119] Bradner, S., "Key words for use 183 in RFCs to Indicate Requirement 184 Levels", BCP 14, RFC 2119, 185 March 1997. 187 [RFC3748] Aboba, B., Blunk, L., 188 Vollbrecht, J., Carlson, J., 189 and H. Levkowetz, "Extensible 190 Authentication Protocol (EAP)", 191 RFC 3748, June 2004. 193 [I-D.ietf-emu-chbind] Hartman, S., Clancy, T., and K. 194 Hoeper, "Channel Binding 195 Support for EAP Methods", 196 draft-ietf-emu-chbind-16 (work 197 in progress), May 2012. 199 7.2. Informational References 201 [I-D.hartman-emu-mutual-crypto-bind] Hartman, S., Wasserman, M., and 202 D. Zhang, "EAP Mutual 203 Cryptographic Binding", draft- 204 hartman-emu-mutual-crypto-bind- 205 00 (work in progress), 206 March 2012. 208 Authors' Addresses 210 Stefan Winter 211 Fondation RESTENA 212 6, rue Richard Coudenhove-Kalergi 213 Luxembourg 1359 214 LUXEMBOURG 216 Phone: +352 424409 1 217 Fax: +352 422473 218 EMail: stefan.winter@restena.lu 219 URI: http://www.restena.lu. 221 Joseph Salowey 222 Cisco Systems 223 2901 3rd Ave 224 Seattle 98121 225 USA 227 EMail: jsalowey@cisco.com