idnits 2.17.00 (12 Aug 2021) /tmp/idnits53419/draft-padmakumar-ikev2-redirect-and-auth-offload-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: IKEv2 Session Resumption assumes that the client always resumes into the same gateway that generated the ticket. IKE_AUTH exchange that follows the IKE_SESSION_RESUME exchange does not use any authentication mechanisms like pre-shared key or certificates. That means the ID values sent in the IKE_AUTH exchange can not be re-authenticated and MUST be identical to the values included in the ticket. But Authentication Offload mechanism explained in this memo allows servers to compute a pre-shared key dynamically based on the information provided by the client during IKE_AUTH exchange. Clients learn the same pre-shared key from the trust anchors during IKE_AUTH exchange. That means the IKE_AUTH exchange that follows the IKE_SESSION_RESUME exchange can independently verify the identities of both parties based on a common pre-shared key computed dynamically. This method is utilized in this memo and proxy session resumption is made possible with an IDr which is different from the one mentioned in the ticket. Access tokens computed are linked to IDi values and MUST not be changed. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: PROXY_TICKET is an IKEv2 ticket [IKEv2RESUMPTION] negotiated between client and trust anchor. IKEv2 Auth offload mechanism explained in this memo allows proxy session resumption with an IDr which is different from the one mentioned in the IKEv2 ticket. Clients can include N(PROXY_TICKET_SUPPORTED) along with N(REDIRECT_SUPPORTED) and N(GATE_PASS_SUPPORTED) in the IKE_SA_INIT exchange to inform proxy support for IKEv2 Session Resumption [IKEv2RESUMPTION] capability to the servers or trust anchors. Server redirects clients to trust anchors for authentication and proxy session negotiations. Trust anchor redirects clients back to server after successful authentication and proxy session negotiations. Trust anchors MUST not use Ticket by reference [IKEv2RESUMPTION] for passing Tickets to clients, instead, it MUST use Ticket by value [IKEv2RESUMPTION] method. If proxy session resumption is supported trust anchor MUST encrypt and integrity protect the Ticket using the GP_SECRET associated with the GATE_PASS. Client MUST include N(GATE_PASS) along with N(TICKET_OPAQUE) [IKEv2RESUMPTION] payload in the IKE_SESSION_RESUME exchange [IKEv2RESUMPTION] to indicate that the resumed session is a proxy session and the identities (old IDi of client and new IDr of server) are authenticated separately using GATE_PASS in the IKE_AUTH exchange. Server MUST not accept the Tickets with different IDr if N(GATE_PASS) is not included. If N(GATE_PASS) is included in the IKE_SESSION_RESUME exchange then the IDr contained in the Ticket MUST be the same as Trust Anchor ID contained in the GATE_PASS, otherwise this MUST be considered as normal IKE_SESSION_RESUME exchange and IDr MUST be the same as that of the responder (server). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Client can resume a proxy session with server if it holds a valid PROXY_TICKET, GATE_PASS and ACCESS_TOKEN and in such cases client MUST include N(GATE_PASS) in the IKE_SESSION_RESUME exchange to indicate that the resumed session is a proxy session and the identities (old IDi of client and new IDr of server) are authenticated separately using GATE_PASS in the IKE_AUTH exchange. Client and Server MUST use GATE_PASS based IKE_AUTH exchange (Section 14) to resume the proxy session. Server MUST not accept the Tickets with different IDr if N(GATE_PASS) is not included. Server MUST not accept the N(GATE_PASS) if Trust_Anchor_IP contained in N(REDIRECTED_FROM,Trust_Anchor_IP)is different from Trust Anchor IP contained in N(GATE_PASS). If N(GATE_PASS) is included in the IKE_SESSION_RESUME exchange then the IDr contained in the Ticket MUST be the same as Trust Anchor ID contained in the GATE_PASS otherwise this MUST be considered as normal IKE_SESSION_RESUME exchange and IDr MUST be the same as that of the responder (server) and both parties MUST use the IKE_AUTH Exchange mentioned in section 4.3.3 of IKEv2 Session Resumption [IKEv2RESUMPTION]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The responder MAY include N(AUTH_LIFETIME) [RFC4478] in the Auth reply. Such cases client MUST not include N(GATE_PASS) in the INIT exchange when it restarts INIT exchange. Instead it MAY include N(GATE_PASS_SUPPORTED) if it wants to continue using this mechanism. -- The document date (December 21, 2009) is 4534 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: 'CERTREQ' is mentioned on line 504, but not defined == Unused Reference: 'RFC2629' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC4718' is defined on line 774, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2REDIRECT' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEv2RESUMPTION' ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Experimental RFC: RFC 4478 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group AV. Padmakumar 3 Internet-Draft M. Bafna 4 Intended status: Standards Track P. Sethi 5 Expires: June 24, 2010 Cisco 6 December 21, 2009 8 IKEv2 Redirect based Authentication Offload and Proxy Session Resumption 9 draft-padmakumar-ikev2-redirect-and-auth-offload-02 11 Abstract 13 IKEv2 supports multiple authentication mechanisms like public key 14 signatures, shared secrets and EAP. EAP based authentication 15 requires server to maintain information about the client until EAP 16 completes. Public key based authentication mechanisms are highly 17 computational intensive and demands server CPU resources. 19 Redirect Mechanism for IKEv2 proposes a mechanism for IKEv2 that 20 enables a VPN gateway to redirect the VPN client to another VPN 21 gateway, for example, based on the load condition. 23 IKEv2 Session Resumption proposes an extension to IKEv2 that allows a 24 client to re-establish an IKE SA with a gateway in a highly efficient 25 manner, utilizing a previously established IKE SA. 27 Redirect mechanism can also be used to redirect a client to another 28 router (trust anchor) to do mutual authentication and an optional 29 proxy session negotiation on behalf of the server. This redirection 30 happens during the IKE_SA_INIT and server does not maintain any 31 information about the redirected client. After mutual authentication 32 and optional proxy session negotiation trust anchor redirects the 33 client back to the server with an Access Token which can be used as a 34 dynamic pre-shared key between the server and client for password 35 based IKE_AUTH exchange. Mechanism described here allows servers to 36 compute the same pre-shared key dynamically, without contacting trust 37 anchors, based on the information provided by the client during 38 IKE_AUTH exchange. Access Token based authentication permits IDr of 39 the responder to be different from that specified in Ticket and 40 permits client to reuse the proxy session (negotiated between client 41 and trust anchor) between client and server. 43 Such a mechanism is useful especially for low power devices like 44 handsets. For example, a mobile node can redirect a correspondent 45 node to its home agent. Home agent can form a proxy session with 46 correspondent node and then redirect it back to mobile node. 48 Status of this Memo 49 This Internet-Draft is submitted to IETF in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF), its areas, and its working groups. Note that 54 other groups may also distribute working documents as Internet- 55 Drafts. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 The list of current Internet-Drafts can be accessed at 63 http://www.ietf.org/ietf/1id-abstracts.txt. 65 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 This Internet-Draft will expire on June 24, 2010. 70 Copyright Notice 72 Copyright (c) 2009 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 88 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 3. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 4. GP_SECRET_INDEX . . . . . . . . . . . . . . . . . . . . . . . 6 91 5. GP_KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 92 6. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 93 7. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . . . . 7 94 8. PROXY_TICKET . . . . . . . . . . . . . . . . . . . . . . . . . 8 95 9. GP_SECRET and GATE_PASS Distribution to Trust Anchor . . . . . 8 96 10. IKEv2 First Init exchange with Server and Server 97 Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 9 98 11. IKEv2 Second Redirection by the Trust Anchor during 99 IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . . . . . 10 100 12. IKEv2 Proxy Session Resumption Exchange with Server with 101 N(GATE_PASS) . . . . . . . . . . . . . . . . . . . . . . . . . 11 102 13. IKEv2 Second Init exchange with Server with N(GATE_PASS) . . . 12 103 14. IKEv2 Auth exchange with Server with N(GATE_PASS) . . . . . . 12 104 15. IKEv2 Auth Offload and Proxy Session Resumption Messages . . . 13 105 15.1. GATE_PASS_SUPPORTED . . . . . . . . . . . . . . . . . . . 13 106 15.2. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . 14 107 15.3. PROXY_TICKET_SUPPORTED . . . . . . . . . . . . . . . . . 15 108 15.4. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . 15 109 15.5. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . 16 110 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 111 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 112 18. Security Considerations . . . . . . . . . . . . . . . . . . . 17 113 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 114 19.1. Normative References . . . . . . . . . . . . . . . . . . 17 115 19.2. Informative References . . . . . . . . . . . . . . . . . 18 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 118 1. Introduction 120 IKEv2 [RFC4306] supports multiple authentication mechanisms like 121 public key signatures, shared secrets and EAP. EAP based 122 authentication requires server to maintain information about the 123 client until EAP completes. Public key based authentication 124 mechanisms are highly computational intensive and demands server CPU 125 resources. 127 Redirect Mechanism for IKEv2 [IKEv2REDIRECT]proposes a mechanism for 128 IKEv2 that enables a VPN gateway to redirect the VPN client to 129 another VPN gateway, for example, based on the load condition. 130 Redirect can be done during the IKE_SA_INIT, IKE_AUTH exchange or in 131 the middle of a session. 133 IKEv2 Session Resumption [IKEv2RESUMPTION] proposes an extension to 134 IKEv2 that allows a client to re-establish an IKE SA with a gateway 135 in a highly efficient manner, utilizing a previously established IKE 136 SA. 138 Redirect mechanism can be used to redirect a client to another router 139 (trust anchor) to do mutual authentication and an optional proxy 140 session negotiation on behalf of the server. This redirection 141 happens during the IKE_SA_INIT and server does not maintain any 142 information about the redirected client. After mutual authentication 143 and optional proxy session negotiation trust anchor redirects the 144 client back to the server with an Access Token which can be used as a 145 dynamic pre-shared key between the server and client for password 146 based IKE_AUTH exchange. Mechanism described here allows servers to 147 compute the same pre-shared key dynamically, without contacting trust 148 anchors, based on the information provided by the client during 149 IKE_AUTH exchange. 151 IKEv2 Session Resumption assumes that the client always resumes into 152 the same gateway that generated the ticket. IKE_AUTH exchange that 153 follows the IKE_SESSION_RESUME exchange does not use any 154 authentication mechanisms like pre-shared key or certificates. That 155 means the ID values sent in the IKE_AUTH exchange can not be re- 156 authenticated and MUST be identical to the values included in the 157 ticket. But Authentication Offload mechanism explained in this memo 158 allows servers to compute a pre-shared key dynamically based on the 159 information provided by the client during IKE_AUTH exchange. Clients 160 learn the same pre-shared key from the trust anchors during IKE_AUTH 161 exchange. That means the IKE_AUTH exchange that follows the 162 IKE_SESSION_RESUME exchange can independently verify the identities 163 of both parties based on a common pre-shared key computed 164 dynamically. This method is utilized in this memo and proxy session 165 resumption is made possible with an IDr which is different from the 166 one mentioned in the ticket. Access tokens computed are linked to 167 IDi values and MUST not be changed. 169 Trust anchor MUST choose the same cryptographic suit from client's 170 offer which the server would have chosen if the client had contacted 171 server directly. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 o Trust Anchor : A router (or set of dedicated routers) that can act 180 as a proxy for a server to do mutual authentication and proxy 181 session negotiation on behalf of the server. 182 o GP_SECRET : Gate Pass Secret (GP_SECRET) is a random number 183 generated by server. Server shares GP_SECRET with all trust 184 anchors in a secure way. 185 o GP_SECRET_INDEX : Server maintains a history of GP_SECRET and each 186 GP_SECRET is uniquely identified by the GP_SECRET_INDEX 187 o GP_KEY : Gate Pass Key (GP_KEY) is a set of secret keys, updated 188 periodically and identified by an Index. GP_KEY is used to 189 generate and verify GATE_PASS. 190 o GATE_PASS : Identifies the transitive trust channel (server to 191 trust anchor). 192 o ACCESS_TOKEN : Passwords generated by trust anchors to be used 193 between server and clients. Servers and anchor routers compute 194 tokens independently but based on a common information known only 195 to them. 196 o PROXY_TICKET : An IKEv2 ticket [IKEv2RESUMPTION] is a data 197 structure that contains all the necessary information that allows 198 an IKEv2 responder to re-establish an IKEv2 security association. 199 PROXY_TICKET is an IKEv2 ticket negotiated between client and 200 trust anchor. IKEv2 Auth offload mechanism explained in this memo 201 allows proxy session resumption with an IDr which is different 202 from the one mentioned in the IKEv2 ticket. 204 3. GP_SECRET 206 Gate Pass Secret (GP_SECRET) is a random number generated by server. 207 Server shares GP_SECRET with trust anchor in a secure way 208 (distribution mechanism is explained in Section 9 ). Length of 209 GP_SECRET is decided by the encryption algorithm negotiated between 210 server and trust anchor in the context of IKE_SA. 212 4. GP_SECRET_INDEX 214 Gate Pass Secret index(GP_SECRET_INDEX) identifies the GP_SECRET. 215 Server maintains a history of GP_SECRET and each GP_SECRET is 216 uniquely identified by the GP_SECRET_INDEX 218 5. GP_KEY 220 GP_KEY is a set of authentication and encryption keys, updated 221 periodically and identified by an Index. GP_KEY has the following 222 structure. 224 GP_KEY = { 226 GP_KEY.ek 228 GP_KEY.ak 230 GP_KEY.index 232 } 234 This specification does not define the size of these fields and is 235 left up to the server to choose based on the algorithms it use. 237 GP_KEY.index is carried in a GATE_PASS(Section 6). 239 GP_KEY.ek key is used to encrypt the {trust anchor, server specific 240 informations } fields of the GATE_PASS. 242 GP_KEY.ak key is used to sign the encrypted part in the GATE_PASS. 244 When server receives an AUTH message authenticated by IKEv2 trust 245 anchor method, server verifies the Signature on the GATE_PASS using 246 the GP_KEY.ak. If this check fails, server MUST drop the AUTH 247 message and MAY send AUTHENTICATION_FAILED message. 249 6. GATE_PASS 251 An IKEv2 GATE_PASS is a data structure generated by the server and 252 contains all the necessary information that allows server to 253 recompute ACCESS_TOKEN based on the client's IDi. Server encrypt and 254 integrity protect GATE_PASS using GP_KEY and distributes to trust 255 anchors using N(GATE_PASS) notify payload. Clients receive the same 256 GATE_PASS from the trust anchors and include it in IKE_SA_INIT or 257 KE_SESSION_RESUME exchange when it restarts its IKE exchange with the 258 server. Server computes GATE_PASS using following mechanism. 260 GATE_PASS = Signature | GP_KEY.Index | Secret 262 Length of each field is not defined by this specification and can be 263 defined by the server depending on the algorithms it uses for 264 computing these. Secret and Signature can be computed using 265 following mechanism. 267 Secret = encrypt(GP_KEY.ek, {Trust Anchor IP | Trust Anchor ID | 268 GP_SECRET_INDEX | server specific informations }) 270 Signature = prf(GP_KEY.ak | GP_KEY.Index | Secret) 272 Where encrypt() and prf() are the encryption and pseudo random number 273 generator algorithms that the server wants to use. 275 Trust anchor sends GATE_PASS to client using N(GATE_PASS) notify 276 payload along with the N(REDIRECT) [IKEv2REDIRECT], 277 N(ACCESS_TOKEN)(Section 7) and optional N(TICKET_OPAQUE) 278 [IKEv2RESUMPTION] payloads. 280 7. ACCESS_TOKEN 282 Client MUST use ACCESS_TOKEN as the pre-shared key for password based 283 authentication between server and client if client includes 284 N(GATE_PASS) in the IKE_AUTH exchange. AUTH is computed using the 285 same mechanism specified in Section 2.15 of IKEv2 RFC [RFC4306] using 286 pre-shared keys. Server computes the same ACCESS_TOKEN using 287 client's identity, GATE_PASS and GP_SECRET. 289 ACCESS_TOKEN = prf(encrypt(GP_SECRET, GATE_PASS | Client's Identity)) 291 Where prf() and encrypt() are the pseudo random number generator 292 algorithm and encryption algorithm negotiated between server and 293 trust anchor during IKE_SA. It MUST be picked from the same IKE 294 channel through which the server has distributed GP_SECRET and 295 GATE_PASS to Trust Anchor. 297 Client's Identity is the identity specified by IDi payload during 298 IKE_AUTH exchange. 300 Trust anchor sends ACCESS_TOKEN to client using N(ACCESS_TOKEN) 301 payload along with N(GATE_PASS) and N(REDIRECT) payloads to redirect 302 it back to the server. 304 N(REDIRECT) is defined in [IKEv2REDIRECT]. 306 N(ACCESS_TOKEN) payloads can be included only after successful 307 verification of client's identity. 309 8. PROXY_TICKET 311 PROXY_TICKET is an IKEv2 ticket [IKEv2RESUMPTION] negotiated between 312 client and trust anchor. IKEv2 Auth offload mechanism explained in 313 this memo allows proxy session resumption with an IDr which is 314 different from the one mentioned in the IKEv2 ticket. Clients can 315 include N(PROXY_TICKET_SUPPORTED) along with N(REDIRECT_SUPPORTED) 316 and N(GATE_PASS_SUPPORTED) in the IKE_SA_INIT exchange to inform 317 proxy support for IKEv2 Session Resumption [IKEv2RESUMPTION] 318 capability to the servers or trust anchors. Server redirects clients 319 to trust anchors for authentication and proxy session negotiations. 320 Trust anchor redirects clients back to server after successful 321 authentication and proxy session negotiations. Trust anchors MUST 322 not use Ticket by reference [IKEv2RESUMPTION] for passing Tickets to 323 clients, instead, it MUST use Ticket by value [IKEv2RESUMPTION] 324 method. If proxy session resumption is supported trust anchor MUST 325 encrypt and integrity protect the Ticket using the GP_SECRET 326 associated with the GATE_PASS. Client MUST include N(GATE_PASS) 327 along with N(TICKET_OPAQUE) [IKEv2RESUMPTION] payload in the 328 IKE_SESSION_RESUME exchange [IKEv2RESUMPTION] to indicate that the 329 resumed session is a proxy session and the identities (old IDi of 330 client and new IDr of server) are authenticated separately using 331 GATE_PASS in the IKE_AUTH exchange. Server MUST not accept the 332 Tickets with different IDr if N(GATE_PASS) is not included. If 333 N(GATE_PASS) is included in the IKE_SESSION_RESUME exchange then the 334 IDr contained in the Ticket MUST be the same as Trust Anchor ID 335 contained in the GATE_PASS, otherwise this MUST be considered as 336 normal IKE_SESSION_RESUME exchange and IDr MUST be the same as that 337 of the responder (server). 339 9. GP_SECRET and GATE_PASS Distribution to Trust Anchor 341 Server MAY periodically update GP_KEY and GP_SECRET and each time it 342 updates it MUST recompute and redistributes the associated GATE_PASS 343 and GP_SECRET to all trust anchors (if they support this feature, 344 indicated by N(GATE_PASS_SUPPORTED) in the INIT exchange). This way 345 servers can restrict the life time of tokens issued to clients. 346 Server MAY maintain a history of GP_KEYs and GP_SECRETs for a 347 duration decided by server's policy to support clients who bring old 348 GATE_PASS but still valid based on GP_KEY history. 350 Server uses an INFORMATIONAL exchange to distribute GATE_PASS and 351 GP_SECRET. Server and trust anchor need not retain the IKE SAs but 352 in such cases they MUST remember the prf and encryption algorithms 353 negotiated. 355 Initiator (Server) Responder (Trust Anchor) 356 ------------------ ------------------------ 358 HDR, SK {N(GATE_PASS), 359 N(GP_SECRET) 360 } --> 362 <-- HDR, SK {} 364 Server distribution of GATE_PASS and GP_SECRET to Trust Anchor 366 The INFORMATIONAL message exchange described above is protected by 367 the existing IKEv2 SA between the server and trust anchor. Server 368 MUST maintain mappings between GATE_PASS, GP_SECRET and GP_KEY for 369 the items present in its history. Trust anchor need not maintain any 370 such history and keep only the latest GATE_PASS and GP_SECRET. 372 10. IKEv2 First Init exchange with Server and Server Redirection 374 Apart from the items specified in section 3 of [IKEv2REDIRECT] this 375 exchange includes N(GATE_PASS_SUPPORTED) and 376 N(PROXY_TICKET_SUPPORTED) payloads. 378 Initiator(client) Responder (Server) 379 ----------------- ------------------ 381 (IP_I:500 -> Initial_IP_R:500) 382 HDR(A,0), SAi1, KEi, Ni, --> 383 N(REDIRECT_SUPPORTED), 384 N(GATE_PASS_SUPPORTED), 385 N(PROXY_TICKET_SUPPORTED) 387 (Initial_IP_R:500 -> IP_I:500) 388 <-- HDR(A,0), N(REDIRECT, 389 Trust_Anchor_ID, 390 Ni_data), 391 N(GATE_PASS_SUPPORTED), 392 N(PROXY_TICKET_SUPPORTED) 394 IKEv2 First Init exchange with Server and Server Redirection 396 Subsequently client initiates a new IKE_SA_INIT exchange with the 397 trust anchor listed in the REDIRECT payload. 399 Client MUST include N(GATE_PASS_SUPPORTED)and 400 N(PROXY_TICKET_SUPPORTED) payloads in this exchange if both the 401 client and server (as indicated in the earlier redirect from server) 402 support this feature. 404 Initiator (client) Responder (Trust Anchor) 405 ------------------ ------------------------ 407 (IP_I:500 -> IP_R:500) 408 HDR(A,0), SAi1, KEi, Ni, --> 409 N(REDIRECTED_FROM, Initial_IP_R), 410 N(GATE_PASS_SUPPORTED), 411 N(PROXY_TICKET_SUPPORTED) 413 (IP_R:500 -> IP_I:500) 414 <-- HDR(A,B), SAr1, KEr, Nr, 415 [CERTREQ], 416 N(GATE_PASS_SUPPORTED), 417 N(PROXY_TICKET_SUPPORTED) 419 IKEv2 Init exchange with Trust Anchor 421 11. IKEv2 Second Redirection by the Trust Anchor during IKE_AUTH 422 Exchange 424 Clients and trust anchors have to adhere to the rules specified in 425 Section 6 of [IKEv2REDIRECT]. 427 Additionally, trust anchor MAY include N(GATE_PASS), N(ACCESS_TOKEN) 428 and N(TICKET_OPAQUE) payloads along with N(REDIRECT, Initial_IP_R)in 429 the IKE_AUTH if client specified these capabilities in the INIT 430 exchange. In such cases trust anchor MUST use the same IP of 431 Initial_IP_R received from N(REDIRECTED_FROM, Initial_IP_R) to 432 redirect it back to the same server. 434 N(ACCESS_TOKEN) payloads MUST be included only after verifying 435 client's identity. 437 If trust anchor decides to include N(TICKET_OPAQUE) along with 438 N(REDIRECT, Initial_IP_R) in the IKE_AUTH exchange it MUST also 439 include N(GATE_PASS)and N(ACCESS_TOKEN) in the exchange. 441 If trust anchor had redirected the client with N(TICKET_OPAQUE) 442 payload, client MUST use IKEv2 Session Resumption Exchange 443 (Section 12) to resume the proxy session (established between client 444 and trust anchor) with the server, otherwise client MUST proceed with 445 IKE_SA_INIT exchange (Section 13) and SHOULD include N(GATE_PASS) 446 payload in the exchange to prevent it from getting redirected again. 448 Initiator (client) Responder (Trust Anchor) 449 ------------------ ------------------------ 451 (IP_I:500 -> IP_R:500) 452 HDR(A,B), SK {IDi, [CERT,] 453 [CERTREQ,] 454 [IDr,]AUTH, SAi2, TSi, TSr 455 [,N(TICKET_REQUEST)]} --> 457 (IP_R:500 -> IP_I:500) 458 <-- HDR(A,B), SK {IDr, [CERT,] AUTH, 459 N(REDIRECT, Initial_IP_R), 460 N(GATE_PASS), N(ACCESS_TOKEN) 461 [,N(TICKET_OPAQUE)])} 463 IKEv2 Auth exchange with Trust Anchor 465 12. IKEv2 Proxy Session Resumption Exchange with Server with 466 N(GATE_PASS) 468 Client can resume a proxy session with server if it holds a valid 469 PROXY_TICKET, GATE_PASS and ACCESS_TOKEN and in such cases client 470 MUST include N(GATE_PASS) in the IKE_SESSION_RESUME exchange to 471 indicate that the resumed session is a proxy session and the 472 identities (old IDi of client and new IDr of server) are 473 authenticated separately using GATE_PASS in the IKE_AUTH exchange. 474 Client and Server MUST use GATE_PASS based IKE_AUTH exchange 475 (Section 14) to resume the proxy session. Server MUST not accept the 476 Tickets with different IDr if N(GATE_PASS) is not included. Server 477 MUST not accept the N(GATE_PASS) if Trust_Anchor_IP contained in 478 N(REDIRECTED_FROM,Trust_Anchor_IP)is different from Trust Anchor IP 479 contained in N(GATE_PASS). If N(GATE_PASS) is included in the 480 IKE_SESSION_RESUME exchange then the IDr contained in the Ticket MUST 481 be the same as Trust Anchor ID contained in the GATE_PASS otherwise 482 this MUST be considered as normal IKE_SESSION_RESUME exchange and IDr 483 MUST be the same as that of the responder (server) and both parties 484 MUST use the IKE_AUTH Exchange mentioned in section 4.3.3 of IKEv2 485 Session Resumption [IKEv2RESUMPTION]. 487 Initiator (client) Responder (Server) 488 ------------------ ------------------ 489 HDR(A,0), [N(COOKIE),] Ni, 490 N(TICKET_OPAQUE) --> 491 N(REDIRECTED_FROM, 492 Trust_Anchor_IP), 493 N(GATE_PASS) [,N+] 495 <-- HDR(A,B),Nr [,N+] 497 IKEv2 Proxy Session Resumption Exchange with Server 499 13. IKEv2 Second Init exchange with Server with N(GATE_PASS) 501 Clients MUST includes N(GATE_PASS) payload in this exchange to 502 prevent it from getting redirected again. 504 In such cases server MAY not include [CERTREQ] in the INIT reply as 505 the proof is based on GATE_PASS based authentication. 507 Initiator (client) Responder (Server) 508 ------------------ ------------------ 509 (IP_I:500 -> IP_R:500) 510 HDR(A,0), SAi1, KEi, Ni, --> 511 N(REDIRECTED_FROM, 512 Trust_Anchor_IP), 513 N(GATE_PASS) 515 (IP_R:500 -> IP_I:500) 516 <-- HDR(A,B), SAr1, KEr, Nr, 518 IKEv2 Second INIT exchange with Server 520 14. IKEv2 Auth exchange with Server with N(GATE_PASS) 522 Client includes GATE_PASS in the AUTH exchange and compute AUTH using 523 ACCESS_TOKEN as the pre-shared key. 525 Server computes ACCESS_TOKEN based on IDi, GATE_PASS and GP_SECRET 526 the same way TRUST_ANCHOR computed it earlier. 528 ACCESS_TOKEN = prf(encrypt(GP_SECRET, GATE_PASS | Client's Identity 529 (IDi))) 531 Client MUST use the same identity that it used during its earlier 532 IKE_AUTH exchange with trust anchor. Otherwise the pre-shared key 533 computed will be different and IKE_AUTH will fail. 535 Where prf() and encrypt() are the pseudo random number generator 536 algorithm and encryption algorithm negotiated between server and 537 trust anchor during IKE_SA. It MUST be picked from the same IKE 538 channel through which the server has distributed GP_SECRET and 539 GATE_PASS to Trust Anchor. 541 If server prefers to provide AUTH based on GATE_PASS it MUST include 542 the same GATE_PASS received in the reply. 544 Initiator (client) Responder (Server) 545 ------------------ ------------------ 546 (IP_I:500 -> IP_R:500) 547 HDR(A,B), SK {IDi, 548 N(GATE_PASS) 549 [IDr,]AUTH, SAi2, 550 TSi, TSr} --> 552 (IP_R:500 -> IP_I:500) 553 <-- HDR(A,B), SK {IDr, AUTH, 554 N(GATE_PASS), 555 SAr2, TSi, TSr} 557 IKEv2 AUTH exchange with Server 559 The responder MAY include N(AUTH_LIFETIME) [RFC4478] in the Auth 560 reply. Such cases client MUST not include N(GATE_PASS) in the INIT 561 exchange when it restarts INIT exchange. Instead it MAY include 562 N(GATE_PASS_SUPPORTED) if it wants to continue using this mechanism. 564 15. IKEv2 Auth Offload and Proxy Session Resumption Messages 566 15.1. GATE_PASS_SUPPORTED 568 The GATE_PASS_SUPPORTED payload is included in the initial 569 IKE_SA_INIT request by the initiator to indicate support for the 570 IKEv2 auth offload mechanism described in this memo. 572 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Next Payload |C| RESERVED | Payload Length | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 GATE_PASS_SUPPORTED 582 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 583 the 'Notify Message Type' fields are the same as described in Section 584 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate 585 that the SPI is not present in this message. The 'Protocol ID' MUST 586 be set to 0, since the notification is not specific to a particular 587 security association. 589 The 'Payload Length' field is set to the length in octets of the 590 entire payload, including the generic payload header. The Notify 591 Message Type' field is set to indicate the GATE_PASS_SUPPORTED 592 payload. 594 15.2. GATE_PASS 596 GATE_PASS payload is included in the initial IKE_SA_AUTH reply by the 597 trust anchor to client, or the initial IKE_SA_AUTH request by the 598 client to server to carry the GATE_PASS. 600 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Next Payload |C| RESERVED | Payload Length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | | 608 ~ GATE_PASS ~ 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 GATE_PASS 614 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 615 the 'Notify Message Type' fields are the same as described in Section 616 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate 617 that the SPI is not present in this message. The 'Protocol ID' MUST 618 be set to 0, since the notification is not specific to a particular 619 security association. 621 The 'Payload Length' field is set to the length in octets of the 622 entire payload, including the generic payload header. The Notify 623 Message Type' field is set to indicate the GATE_PASS payload. 625 15.3. PROXY_TICKET_SUPPORTED 627 The PROXY_TICKET_SUPPORTED payload is included in the initial 628 IKE_SA_INIT request by the initiator to indicate support for the 629 IKEv2 proxy session resumption mechanism described in this memo. 630 Note that proxy session resumption is dependent on auth offload 631 capability and client MUST also include GATE_PASS_SUPPORTED payload 632 in the exchange. 634 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Next Payload |C| RESERVED | Payload Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 PROXY_TICKET_SUPPORTED 644 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 645 the 'Notify Message Type' fields are the same as described in Section 646 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate 647 that the SPI is not present in this message. The 'Protocol ID' MUST 648 be set to 0, since the notification is not specific to a particular 649 security association. 651 The 'Payload Length' field is set to the length in octets of the 652 entire payload, including the generic payload header. The Notify 653 Message Type' field is set to indicate the GATE_PASS_SUPPORTED 654 payload. 656 15.4. ACCESS_TOKEN 658 ACCESS_TOKEN payload is included in the initial IKE_SA_AUTH reply by 659 the trust anchor to client. 661 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Next Payload |C| RESERVED | Payload Length | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 ~ ACCESS_TOKEN ~ 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 ACCESS_TOKEN 675 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 676 the 'Notify Message Type' fields are the same as described in Section 677 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate 678 that the SPI is not present in this message. The 'Protocol ID' MUST 679 be set to 0, since the notification is not specific to a particular 680 security association. 682 The 'Payload Length' field is set to the length in octets of the 683 entire payload, including the generic payload header. The Notify 684 Message Type' field is set to indicate the ACCESS_TOKEN payload. 686 15.5. GP_SECRET 688 Server uses an INFORMATIONAL exchange to distribute GP_SECRET. 690 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Next Payload |C| RESERVED | Payload Length | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | 698 ~ GP_SECRET ~ 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 GP_SECRET 704 The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and 705 the 'Notify Message Type' fields are the same as described in Section 706 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate 707 that the SPI is not present in this message. The 'Protocol ID' MUST 708 be set to 0, since the notification is not specific to a particular 709 security association. 711 The 'Payload Length' field is set to the length in octets of the 712 entire payload, including the generic payload header. The Notify 713 Message Type' field is set to indicate the GP_SECRET payload. 715 16. Acknowledgements 717 . 719 17. IANA Considerations 721 Section 15 defines five new IKEv2 notifications whose Message Type 722 values are to be allocated from the "IKEv2 Notify Message Types - 723 Status Types" registry. 725 o GATE_PASS_SUPPORTED 727 o PROXY_TICKET_SUPPORTED 729 o GATE_PASS 731 o ACCESS_TOKEN 733 o GP_SECRET 735 18. Security Considerations 737 Servers MUST periodically update GATE_PASS. This is required to 738 prevent clients from reusing the tokens. It is a good idea to force 739 clients to reauthenticate when the GATE_PASS expires using 740 N(AUTH_LIFETIME). [RFC4478] 742 19. References 744 19.1. Normative References 746 [IKEv2REDIRECT] 747 Devarapalli, V. and K. Weniger, "Redirect Mechanism for 748 the Internet Key Exchange Protocol Version 2 (IKEv2)", 749 November 2009. 751 [IKEv2RESUMPTION] 752 Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 753 Protocol Version 2 (IKEv2) Session Resumption", December 754 2009. 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 760 RFC 4306, December 2005. 762 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 763 (IKEv2) Protocol", April 2006. 765 19.2. Informative References 767 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 768 June 1999. 770 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 771 Text on Security Considerations", BCP 72, RFC 3552, 772 July 2003. 774 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 775 Implementation Guidelines", RFC 4718, October 2006. 777 Authors' Addresses 779 Padmakumar A.V. 780 Cisco Systems, Inc. 781 O'Shaugnessy Road 782 Bangalore, Karnataka 560025 783 India 785 Phone: +91 80 4103 3184 786 Email: paav@cisco.com 787 Manikchand Bafna 788 Cisco Systems, Inc. 789 O'Shaugnessy Road 790 Bangalore, Karnataka 560025 791 India 793 Phone: +91 80 4154 1365 794 Email: manikrb@cisco.com 796 Pratima Sethi 797 Cisco Systems, Inc. 798 O'Shaugnessy Road 799 Bangalore, Karnataka 560025 800 India 802 Phone: +91 80 4154 1654 803 Email: psethi@cisco.com