idnits 2.17.1 draft-nir-ipsecme-erx-00.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 (May 1, 2011) is 4734 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-02 ** 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: November 2, 2011 Huawei 6 May 1, 2011 8 An IKEv2 Extension for Supporting ERP 9 draft-nir-ipsecme-erx-00 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 November 2, 2011. 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 4. ERX_SUPPORTED Notification 166 The Notify payload is as described in [RFC5996] 168 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 ! Next Payload !C! RESERVED ! Payload Length ! 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 ! Protocol ID ! SPI Size ! ERX Notify Message Type ! 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ! Domain Name ! 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 o Protocol ID (1 octet) MUST be 1, as this message is related to an 179 IKE SA. 180 o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 181 of [RFC5996]. 182 o ERX Notify Message Type (2 octets) - MUST be xxxxx, the value 183 assigned for ERX. TBA by IANA. 184 o Domain Name (variable) - contains the domain name or realm, as 185 these terms are used in [RFC5296bis]. 187 5. Security Considerations 189 TBA 191 6. IANA Considerations 193 IANA is requested to assign a notify message type from the status 194 types range (16418-40959) of the "IKEv2 Notify Message Types" 195 registry with name "ERX_SUPPORTED". 197 7. References 199 7.1. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 [RFC5296bis] 205 Wu, W., Cao, Z., Shi, Y., and B. He, "EAP Extensions for 206 EAP Re-authentication Protocol (ERP)", 207 draft-ietf-hokey-rfc5296bis-02 (work in progress), 208 March 2011. 210 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 211 "Internet Key Exchange Protocol: IKEv2", RFC 5996, 212 September 2010. 214 7.2. Informative References 216 [SecureBeacon] 217 Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting 218 a Trusted Network", draft-sheffer-ipsecme-secure-beacon 219 (work in progress), June 2009. 221 Authors' Addresses 223 Yoav Nir 224 Check Point Software Technologies Ltd. 225 5 Hasolelim st. 226 Tel Aviv 67897 227 Israel 229 Email: ynir@checkpoint.com 231 Q. Wu 232 Huawei Technologies Co., Ltd. 233 101 Software Avenue, Yuhua District 234 Nanjing, JiangSu 210012 235 China 237 Email: Sunseawq@huawei.com