idnits 2.17.1 draft-nir-ipsecme-erx-01.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 (July 11, 2011) is 4670 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 137, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-hokey-rfc5296bis-03 ** 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: January 12, 2012 Huawei 6 July 11, 2011 8 An IKEv2 Extension for Supporting ERP 9 draft-nir-ipsecme-erx-01 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 5296 and its bis document. 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 January 12, 2012. 35 Copyright Notice 37 Copyright (c) 2011 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 1. Introduction 52 IKEv2, as specified in [RFC5996], allows authentication of the 53 initiator using an EAP method. This is described in section 2.16. 54 Using EAP significantly increases the count of round-trips required 55 to establish the IPsec SA, and also may require user interaction. 56 This makes it inconvenient to allow a single remote access client to 57 create multiple IPsec tunnels with multiple IPsec gateways that 58 belong to the same domain. 60 The EAP Re-authentication Protocol (ERP), as descripted in 61 [RFC5296bis], allows an EAP peer to authenticate to multiple 62 authenticators, while performing the full EAP method only once. 63 Subsequent authentications require fewer round-trips and no user 64 interaction. 66 Bringing these two technologies together allows a remote access IPsec 67 client to create multiple tunnels with different gateways that belong 68 to a single domain, as well as using the keys from other contexts of 69 using EAP, such as network access within the same domain, to 70 transparently connect to VPN gateways within this domain. 72 1.1. Conventions Used in This Document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Usage Scenarios 80 Several scenarios motivated this proposal: 81 o Multiple tunnels for a single remote access VPN client. Suppose a 82 company has offices in New York City, Paris, and Shanghai. For 83 historical reasons, the email server is located in the Paris 84 office, while most of the servers hosting the company's intranet 85 are located in Shanghai, and the finance department servers are in 86 NYC. An employee using remote access VPN may need to connect to 87 servers from all three locations. While it is possible to connect 88 to a single gateway, and have that gateway route the requests to 89 the other gateways (perhaps through site-2-site VPN), this is not 90 efficient, and it is more desirable to have the client initiate 91 three different tunnels. It is, however, not desirable to have 92 the user type in a password three times. 93 o Roaming. In these days of mobile phones and tablets, users often 94 move from the wireless LAN in their office, where access may be 95 granted through 802.1x, to a cellular network where VPN is 96 necessary and back again. Both the VPN server and the 802.1x 97 access point are authenticators that connect to the same AAA 98 servers. So it makes sense to make the transition smooth, without 99 requiring user interaction. [SecureBeacon] is an attempt to allow 100 detecting whether the client should connect using VPN or not. 102 3. Protocol Outline 104 Supporting ERX requires an EAP payload in the first IKE_AUTH request. 105 This is a deviation from the rules in RFC 5996, so support needs to 106 be indicated through a Notify payload in the IKE_SA_INIT response. 107 This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, 108 and therefore contains the domain name, as specified in section 109 5.3.1.1 of [RFC5296bis]. 111 A supporting initiator that has unexpired keys for this domain will 112 send the EAP_Initiate/Re-auth message in an EAP payload in the first 113 IKE_AUTH request. 115 The responder sends the EAP payload content to a backend AAA server, 116 and receives the rMSK and an EAP-Finish/Re-auth message. If forwards 117 that to the initiator in an EAP payload within the first IKE_AUTH 118 response. 120 The initiator then sends an additional IKE_AUTH request, that 121 includes the AUTH payload which has been calculated using the rMSK in 122 the role of the MSK as described in sections 2.15 and 2.16 or 123 [RFC5996]. The responder replies similarly, and the IKE_AUTH 124 exchange is finished. 126 The following figure is adapted from appendixes C.1 and C.3 of RFC 127 5996, with most of the optional payloads removed. Note that the 128 EAP_Initiate/Re-auth message replaces the IDi payload. 130 init request --> SA, KE, Ni, 132 init response <-- SA, KE, Nr, 133 N[ERX_SUPPORTED] 135 first request --> EAP(EAP_Initiate/Re-auth), 136 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], 137 [IDr], 138 [CP(CFG_REQUEST)], 139 SA, TSi, TSr, 140 [V+][N+] 142 first response <-- IDr, [CERT+], AUTH, 143 EAP(EAP-Finish/Re-auth), 144 [V+][N+] 146 last request --> AUTH 148 last response <-- AUTH, 149 [CP(CFG_REPLY)], 150 SA, TSi, TSr, 151 [V+][N+] 153 3.1. Clarification About EAP Codes 155 Section 3.16 of [RFC5996] enumerates the EAP codes in EAP messages 156 which are carried in EAP payloads. The enumeration goes only to 4. 157 It is not clear whether that list is supposed to be exhaustive or 158 not. 160 To clarify, an implementation supporting this specification MUST 161 accept and transmit EAP messages with at least the codes for Initiate 162 and Finish (5 and 6). 164 3.2. User Name in the Protocol 166 Section 5.3.2 of [RFC5296bis] describes the EAP-Initiate/Re-auth 167 packet, which in the case of IKEv2 is carried in the first IKE_AUTH 168 request. This packet contains the KeyName-NAI TLV. This TLV 169 contains the username used in authentication. It is relayed to the 170 AAA server in the AccessRequest message, and is returned from the AAA 171 server in the AccessAccept message. 173 The username part of the NAI within the TLV is the EMSKName encoded 174 in hexadecimal digits. The domain part is the domain name of the 175 home domain of the user. The username part is ephemeral in the sense 176 that a new one is generated for each full authentication. This 177 ephemeral value is not a good basis for making policy decisions, and 178 they are also a poor source of user ID for the purposes of logging. 180 Instead, it is up to the implementation in the IPsec gateway to make 181 policy decisions based on other factors. The following list is by no 182 means exhaustive: 183 o In some cases the home domain name may be enough to make policy 184 decisions. If all users with a particular home domain get the 185 same authorization, then policy does not depend on the real user 186 name. Logging can still be done by correlating VPN gateway IKE 187 events with AAA servers access records. 188 o Sometimes users receive different authorizations based on groups 189 they belong to. The AAA server can communicate such information 190 to the VPN gateway, for example using the CLASS attribute in 191 RADIUS and DIAMETER. Logging again depends on correlation with 192 AAA servers. 193 o AAA servers may support extensions that allow them to communicate 194 with their clients (in our case - the VPN gateway) to push user 195 information. For example, a certain product integrates a RADIUS 196 server with LDAP, so a client could query the server using LDAP 197 and receive the real record for this user. Others may provide 198 this data through vendor-specific extensions to RADIUS or 199 DIAMETER. 201 In any case authorization is a major issue in deployments, if the 202 peer's home EAP server does not also perform the re-authentication. 204 4. ERX_SUPPORTED Notification 206 The Notify payload is as described in [RFC5996] 208 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 ! Next Payload !C! RESERVED ! Payload Length ! 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 ! Protocol ID ! SPI Size ! ERX Notify Message Type ! 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 ! Domain Name ! 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 o Protocol ID (1 octet) MUST be 1, as this message is related to an 219 IKE SA. 220 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 221 of [RFC5996]. 222 o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value 223 assigned for ERX. TBA by IANA. 225 o Domain Name (variable) - contains the domain name or realm, as 226 these terms are used in [RFC5296bis]. 228 5. Security Considerations 230 TBA 232 6. IANA Considerations 234 IANA is requested to assign a notify message type from the status 235 types range (16418-40959) of the "IKEv2 Notify Message Types" 236 registry with name "ERX_SUPPORTED". 238 7. References 240 7.1. Normative References 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [RFC5296bis] 246 Wu, W., Cao, Z., Shi, Y., and B. He, "EAP Extensions for 247 EAP Re-authentication Protocol (ERP)", 248 draft-ietf-hokey-rfc5296bis-03 (work in progress), 249 May 2011. 251 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 252 "Internet Key Exchange Protocol: IKEv2", RFC 5996, 253 September 2010. 255 7.2. Informative References 257 [SecureBeacon] 258 Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting 259 a Trusted Network", draft-sheffer-ipsecme-secure-beacon 260 (work in progress), June 2009. 262 Authors' Addresses 264 Yoav Nir 265 Check Point Software Technologies Ltd. 266 5 Hasolelim st. 267 Tel Aviv 67897 268 Israel 270 Email: ynir@checkpoint.com 272 Q. Wu 273 Huawei Technologies Co., Ltd. 274 101 Software Avenue, Yuhua District 275 Nanjing, JiangSu 210012 276 China 278 Email: Sunseawq@huawei.com