idnits 2.17.1 draft-nir-ipsecme-erx-03.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2012) is 4398 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) == Missing Reference: 'IDr' is mentioned on line 141, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-hokey-rfc5296bis-06 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track Q. Wu 5 Expires: October 14, 2012 Huawei 6 April 12, 2012 8 An IKEv2 Extension for Supporting ERP 9 draft-nir-ipsecme-erx-03 11 Abstract 13 This document describes an extension to the IKEv2 protocol that 14 allows an IKE Security Association (SA) to be created and 15 authenticated using the EAP Re-authentication Protocol extension as 16 described in RFC 5296bis. 18 NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with 19 the RFC number assigned to that document. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 14, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 IKEv2, as specified in section 2.16 of [RFC5996], allows 56 authentication of the initiator using an EAP method. Using EAP 57 significantly increases the count of round-trips required to 58 establish the IPsec SA, and also may require user interaction. This 59 makes it inconvenient to allow a single remote access client to 60 create multiple IPsec tunnels with multiple IPsec gateways that 61 belong to the same domain. 63 The EAP Re-authentication Protocol (ERP), as described in 64 [RFC5296bis], allows an EAP peer to authenticate to multiple 65 authenticators, while performing the full EAP method only once. 66 Subsequent authentications require fewer round-trips and no user 67 interaction. 69 Bringing these two technologies together allows a remote access IPsec 70 client to create multiple tunnels with different gateways that belong 71 to a single domain, as well as using the keys from other contexts of 72 using EAP, such as network access within the same domain, to 73 transparently connect to VPN gateways within this domain. 75 1.1. Conventions Used in This Document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Usage Scenarios 83 This work is motivated by the following several scenarios. 84 o Multiple tunnels for a single remote access VPN client. Suppose a 85 company has offices in New York City, Paris, and Shanghai. For 86 historical reasons, the email server is located in the Paris 87 office, while most of the servers hosting the company's intranet 88 are located in Shanghai, and the finance department servers are in 89 NYC. An employee using remote access VPN may need to connect to 90 servers from all three locations. While it is possible to connect 91 to a single gateway, and have that gateway route the requests to 92 the other gateways (perhaps through site-2-site VPN), this is not 93 efficient, and it is more desirable to have the client initiate 94 three different tunnels. It is, however, not desirable to have 95 the user type in a password three times. 96 o Roaming. In these days of mobile phones and tablets, users often 97 move from the wireless LAN in their office, where access may be 98 granted through 802.1x, to a cellular network where VPN is 99 necessary and back again. Both the VPN server and the 802.1x 100 access point are authenticators that connect to the same AAA 101 servers. So it makes sense to make the transition smooth, without 102 requiring user interaction. [SecureBeacon] is a now-abandoned 103 attempt to allow detecting whether the client should connect using 104 VPN or not. 106 3. Protocol Outline 108 Supporting ERX requires an EAP payload in the first IKE_AUTH request. 109 This is a deviation from the rules in RFC 5996, so support needs to 110 be indicated through a Notify payload in the IKE_SA_INIT response. 111 This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, 112 and therefore contains the domain name, as specified in section 113 5.3.1.1 of [RFC5296bis]. 115 A supporting initiator that has unexpired keys for this domain will 116 send the EAP_Initiate/Re-auth message in an EAP payload in the first 117 IKE_AUTH request. 119 The responder sends the EAP payload content to a backend AAA server, 120 and receives the rMSK and an EAP-Finish/Re-auth message. It then 121 forwards the EAP-Finish/Re-auth message to the Initiator in an EAP 122 payload within the first IKE_AUTH response. 124 The initiator then sends an additional IKE_AUTH request, that 125 includes the AUTH payload which has been calculated using the rMSK in 126 the role of the MSK as described in sections 2.15 and 2.16 of 127 [RFC5996]. The responder replies similarly, and the IKE_AUTH 128 exchange is finished. 130 The following figure is adapted from appendixes C.1 and C.3 of RFC 131 5996, with most of the optional payloads removed. Note that the 132 EAP_Initiate/Re-auth message replaces the IDi payload. 134 init request --> SA, KE, Ni, 136 init response <-- SA, KE, Nr, 137 N[ERX_SUPPORTED] 139 first request --> EAP(EAP_Initiate/Re-auth), 140 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 141 [IDr], 142 [CP(CFG_REQUEST)], 143 SA, TSi, TSr, 144 [V+][N+] 146 first response <-- IDr, [CERT+], AUTH, 147 EAP(EAP-Finish/Re-auth), 148 [V+][N+] 150 last request --> AUTH 152 last response <-- AUTH, 153 [CP(CFG_REPLY)], 154 SA, TSi, TSr, 155 [V+][N+] 157 3.1. Clarification About EAP Codes 159 Section 3.16 of [RFC5996] enumerates the EAP codes in EAP messages 160 which are carried in EAP payloads. The enumeration goes only to 4. 161 It is not clear whether that list is supposed to be exhaustive or 162 not. 164 To clarify, an implementation supporting this specification MUST 165 accept and transmit EAP messages with at least the codes for Initiate 166 and Finish (5 and 6), in addition to the four codes enumerated in RFC 167 5996. 169 3.2. User Name in the Protocol 171 The authors, as well as participants of the HOKEY and IPSECME working 172 groups believe that all use cases for this extension to IKE have a 173 single backend AAA server doing both the authentication and the re- 174 authentication. The reasoning behind this is that IKE runs over the 175 Internet, and would naturally connect to the user's home network. 177 This section addresses instances where this is not the case. 179 Section 5.3.2 of [RFC5296bis] describes the EAP-Initiate/Re-auth 180 packet, which in the case of IKEv2 is carried in the first IKE_AUTH 181 request. This packet contains the KeyName-NAI TLV. This TLV 182 contains the username used in authentication. It is relayed to the 183 AAA server in the AccessRequest message, and is returned from the AAA 184 server in the AccessAccept message. 186 The username part of the NAI within the TLV is the EMSKName encoded 187 in hexadecimal digits. The domain part is the domain name of the 188 home domain of the user. The username part is ephemeral in the sense 189 that a new one is generated for each full authentication. This 190 ephemeral value is not a good basis for making policy decisions, and 191 they are also a poor source of user identification for the purposes 192 of logging. 194 Instead, it is up to the implementation in the IPsec gateway to make 195 policy decisions based on other factors. The following list is by no 196 means exhaustive: 197 o In some cases the home domain name may be enough to make policy 198 decisions. If all users with a particular home domain get the 199 same authorization, then policy does not depend on the real user 200 name. Logging can still be done by correlating VPN gateway IKE 201 events with AAA servers access records. 202 o Sometimes users receive different authorizations based on groups 203 they belong to. The AAA server can communicate such information 204 to the VPN gateway, for example using the CLASS attribute in 205 RADIUS and DIAMETER. Logging again depends on correlation with 206 AAA servers. 207 o AAA servers may support extensions that allow them to communicate 208 with their clients (in our case - the VPN gateway) to push user 209 information. For example, a certain product integrates a RADIUS 210 server with LDAP, so a client could query the server using LDAP 211 and receive the real record for this user. Others may provide 212 this data through vendor-specific extensions to RADIUS or 213 DIAMETER. 215 In any case authorization is a major issue in deployments, if the 216 backend AAA server supporting the re-authentication is different from 217 the AAA server that had supported the original authentication. It is 218 up to the re-authenticating AAA server to provide the necessary 219 information for authorization. 221 4. ERX_SUPPORTED Notification 223 The Notify payload is as described in [RFC5996] 224 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 ! Next Payload !C! RESERVED ! Payload Length ! 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 ! Protocol ID ! SPI Size ! ERX Notify Message Type ! 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 ! Domain Name ! 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 o Protocol ID (1 octet) MUST be 1, as this message is related to an 235 IKE SA. 236 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 237 of [RFC5996]. 238 o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value 239 assigned for ERX. TBA by IANA. 240 o Domain Name (variable) - contains the domain name or realm, as 241 these terms are used in [RFC5296bis]. 243 5. Security Considerations 245 The protocol extension described in this document extends the 246 authentication from one EAP context, which may or may not be part of 247 IKEv2, to an IKEv2 context. Successful completion of the protocol 248 proves to the authenticator, which in our case is a VPN gateway, that 249 the supplicant, or VPN client, has authenticated in some other EAP 250 context. 252 The protocol supplies the authenticator with the domain name with 253 which the supplicant has authenticated, but does not supply it with a 254 specific identity. Instead, the gateway receives an EMSKName, which 255 is an ephemeral ID. 257 If the domain name is sufficient to make access control decisions, 258 this is enough. If not, then the gateway needs to find out either 259 the real name or authorization information for that particular user. 260 This may be done using the AAA protocol or by some other federation 261 protocol, which is out of scope for this specification. 263 6. IANA Considerations 265 IANA is requested to assign a notify message type from the status 266 types range (16418-40959) of the "IKEv2 Notify Message Types" 267 registry with name "ERX_SUPPORTED". 269 7. References 271 7.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC5296bis] 277 Wu, W., Cao, Z., Zorn, G., Shi, Y., and B. He, "EAP 278 Extensions for EAP Re-authentication Protocol (ERP)", 279 draft-ietf-hokey-rfc5296bis-06 (work in progress), 280 May 2011. 282 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 283 "Internet Key Exchange Protocol: IKEv2", RFC 5996, 284 September 2010. 286 7.2. Informative References 288 [SecureBeacon] 289 Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting 290 a Trusted Network", draft-sheffer-ipsecme-secure-beacon 291 (work in progress), June 2009. 293 Authors' Addresses 295 Yoav Nir 296 Check Point Software Technologies Ltd. 297 5 Hasolelim st. 298 Tel Aviv 67897 299 Israel 301 Email: ynir@checkpoint.com 303 Qin Wu 304 Huawei Technologies Co., Ltd. 305 101 Software Avenue, Yuhua District 306 Nanjing, JiangSu 210012 307 China 309 Email: sunseawq@huawei.com