Network Working Group AV. Padmakumar Internet-Draft M. Bafna Intended status: Standards Track P. Sethi Expires: January 28, 2010 Cisco July 27, 2009 IKEv2 Redirect and Authentication Offload draft-padmakumar-ikev2-redirect-and-auth-offload-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract IKEv2 supports multiple authentication mechanisms like public key signatures, shared secrets and EAP. EAP based authentication Padmakumar, et al. Expires January 28, 2010 [Page 1] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 requires server to maintain information about the client until EAP completes. Public key based authentication mechanisms are highly computational intensive and demands server CPU resources. Redirect Mechanism for IKEv2 proposes a mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. Redirect mechanism can also be used to redirect a client to another router (trust anchor) to do mutual authentication on behalf of the server. This redirection happens during the IKE_SA_INIT and server does not maintain any information about the redirected client. After mutual authentication Trust anchor can redirect the client back to the server with an Access Token which can be used as a dynamic pre- shared key between the server and client for password based IKE_AUTH exchange. Mechanism described here allows servers to compute the same pre-shared key dynamically, without contacting trust anchors, based on the information provided by the client during IKE_AUTH exchange. Such a mechanism is useful especially for low power devices like handsets. For example, a mobile node can redirect such authentications to its home agent. This proposal explains a mechanism to offload such verifications to a set of less critical routers or to a service provider who offers trust as a service. Padmakumar, et al. Expires January 28, 2010 [Page 2] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. GP_KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. GP_SECRET and GATE_PASS Distribution to Trust Anchor . . . . . 7 8. IKEv2 First Init exchange with Server and Server Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. IKEv2 Second Redirection by the Trust Anchor during IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . . . . . 9 10. IKEv2 Second Init exchange with Server with N(TRUST_ANCHOR_INCLUDED) . . . . . . . . . . . . . . . . . . . 9 11. IKEv2 Auth exchange with Server with N(GATE_PASS) . . . . . . 10 12. IKEv2 Trust Anchor Messages . . . . . . . . . . . . . . . . . 11 12.1. TRUST_ANCHOR_SUPPORTED . . . . . . . . . . . . . . . . . 11 12.2. TRUST_ANCHOR_INCLUDED . . . . . . . . . . . . . . . . . . 12 12.3. GATE_PASS_REQ . . . . . . . . . . . . . . . . . . . . . . 12 12.4. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . 13 12.5. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . 14 12.6. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . 16 16.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Padmakumar, et al. Expires January 28, 2010 [Page 3] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 1. Introduction IKEv2 [RFC4306] supports multiple authentication mechanisms like public key signatures, shared secrets and EAP. EAP based authentication requires server to maintain information about the client until EAP completes. Public key based authentication mechanisms are highly computational intensive and demands server CPU resources. Redirect Mechanism for IKEv2 [IKEv2REDIRECT]proposes a mechanism for IKEv2 that enables a VPN gateway to redirect the VPN client to another VPN gateway, for example, based on the load condition. Redirect can be done during the IKE_SA_INIT, IKE_AUTH exchange or in the middle of a session. Redirect mechanism can also be used to redirect a client to another router (trust anchor) to do mutual authentication on behalf of the server. This redirection happens during IKE_SA_INIT and server does not maintain any information about the redirected client. After mutual authentication Trust anchor can redirect the client back to the server with an Access Token which can be used as a dynamic pre- shared key between the server and client for password based IKE_AUTH exchange. Mechanism described here allows servers to compute the same pre-shared key dynamically, without contacting trust anchors, based on the information provided by the client during IKE_AUTH exchange. Such a mechanism is useful especially for low power devices like handsets. For example, a mobile node can redirect such authentications to its home agent. This proposal explains a mechanism to offload such verifications to a set of less critical routers or to a service provider who offers trust as a service. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. o Trust Anchor : A router (or set of dedicated routers) that can act as a proxy for a server to do mutual authentication on behalf of the server. o GP_SECRET : Gate Pass Secret (GP_SECRET) is a random number generated by server. Server shares GP_SECRET with all trust anchors in a secure way. o GP_KEY : Gate Pass Key (GP_KEY) is a secret key pair, updated periodically and identified by an Index. GP_KEY is used to generate and verify GATE_PASS. Padmakumar, et al. Expires January 28, 2010 [Page 4] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 o GATE_PASS : Identifies the transitive trust channel (server to trust anchor). o ACCESS_TOKEN : Passwords generated by trust anchors to be used between server and clients. Servers and anchor routers compute tokens independently but based on a common information known only to them. 3. GP_SECRET Gate Pass Secret (GP_SECRET) is a random number generated by server. Server shares GP_SECRET with trust anchor in a secure way (distribution mechanism is explained in section 'GP_SECRET and GATE_PASS Distribution to Trust Anchor'). Length of GP_SECRET is decided by the encryption algorithm negotiated between server and trust anchor in the context of IKE_SA. 4. GP_KEY GP_KEY is a secret key pair, updated periodically and identified by an Index. GP_KEY has the following structure. GP_KEY = { GP_KEY.ek GP_KEY.ak GP_KEY.index } This specification does not define the size of these fields and is left up to the server to choose based on the algorithms it use. GP_KEY.index is carried in a GATE_PASS. GP_KEY.ek key is used to encrypt the {trust anchor, server specific informations } fields of the GATE_PASS. GP_KEY.ak key is used to sign the encrypted part in the GATE_PASS. When server receives an AUTH message authenticated by IKEv2 trust anchor method, server verifies the Signature on the GATE_PASS using the GP_KEY.ak. If this check fails, server MUST drop the AUTH message and MAY send AUTHENTICATION_FAILED message. Padmakumar, et al. Expires January 28, 2010 [Page 5] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 5. GATE_PASS Server generates GATE_PASS and distributes to trust anchors. Clients receive the same GATE_PASS from the trust anchors after their successful authentication with trust anchor. Clients include this GATE_PASS in the Auth exchange when it restarts its IKE exchange with the server. Server computes GATE_PASS using following mechanism. GATE_PASS = Signature | GP_KEY.Index | Secret Length of each fields are not defined by this specification and can be defined by the server depending on the algorithms it uses for computing these. Secret and Signature can be computed using following mechanism. Secret = encrypt(GP_KEY.ek, {Trust Anchor, server specific informations }) Signature = prf(GP_KEY.ak | GP_KEY.Index | Secret) Where encrypt() and prf() are the encryption and pseudo random number generator algorithms that the server wants to use. Trust anchor sends GATE_PASS to client using N(GATE_PASS) notify payload along with the N(REDIRECT) payload [IKEv2REDIRECT]. N(GATE_PASS) payload can be included only after successful verification of client's identity. 6. ACCESS_TOKEN Client MUST use ACCESS_TOKEN as the pre-shared key for password based authentication between server and client if client includes N(GATE_PASS) in the IKE_AUTH exchange. AUTH is computed using the same mechanism specified in Section 2.15 of IKEv2 RFC [RFC4306] using pre-shared keys. Server computes the same ACCESS_TOKEN using client's identity, GATE_PASS and GP_SECRET. ACCESS_TOKEN = prf(encrypt(GP_SECRET, GATE_PASS | Client's Identity)) Where prf() and encrypt() are the pseudo random number generator algorithm and encryption algorithm negotiated between server and trust anchor during IKE_SA. It MUST be picked from the same IKE channel through which the server has distributed GP_SECRET and GATE_PASS to Trust Anchor. Client's Identity is the identity specified by IDi payload during Padmakumar, et al. Expires January 28, 2010 [Page 6] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 IKE_AUTH exchange. Trust anchor sends ACCESS_TOKEN to client using N(ACCESS_TOKEN) payload along with N(GATE_PASS) and N(REDIRECT) payloads to redirect it back to the server. N(REDIRECT) is defined in [IKEv2REDIRECT]. N(ACCESS_TOKEN) and N(GATE_PASS) payloads can be included only after successful verification of client's identity. 7. GP_SECRET and GATE_PASS Distribution to Trust Anchor Server MAY periodically update GP_KEY and each time it updates it MUST recompute and redistributes the associated GATE_PASS and GP_SECRET to all trust anchors (if they support this feature, indicated by N(TRUST_ANCHOR_SUPPORTED) in the INIT exchange). This way servers can restrict the life time of tokens issued to clients. Server MAY maintain a history of GP_KEYs for a duration decided by server's policy to support clients who bring old GATE_PASS but still valid based on GP_KEY history. Server uses an INFORMATIONAL exchange to distribute GATE_PASS and GP_SECRET. Server and trust anchor need not retain the IKE SAs but in such cases they MUST remember the prf and encryption algorithms negotiated. Initiator (Server) Responder (Trust Anchor) ------------------ ------------------------ HDR, SK {N(GATE_PASS), N(GP_SECRET) } --> <-- HDR, SK {} Server distribution of GATE_PASS and GP_SECRET to Trust Anchor The INFORMATIONAL message exchange described above is protected by the existing IKEv2 SA between the server and trust anchor. Server MUST maintain mappings between GATE_PASS, GP_SECRET and GP_KEY for the items present in its history. Trust anchor need not maintain any such history and keep only the latest GATE_PASS and GP_SECRET. Padmakumar, et al. Expires January 28, 2010 [Page 7] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 8. IKEv2 First Init exchange with Server and Server Redirection Apart from the items specified in section 3 of [IKEv2REDIRECT] this exchange includes N(TRUST_ANCHOR_SUPPORTED) payload. If the server supports trust anchors it MUST include N(TRUST_ANCHOR_SUPPORTED) payload along with redirect payload in the reply. Initiator(client) Responder (Server) ----------------- ------------------ (IP_I:500 -> Initial_IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECT_SUPPORTED), N(TRUST_ANCHOR_SUPPORTED) (Initial_IP_R:500 -> IP_I:500) <-- HDR(A,0), N(REDIRECT, Trust_Anchor_ID, Ni_data), N(TRUST_ANCHOR_SUPPORTED) IKEv2 First Init exchange with Server and Server Redirection Subsequently client initiates a new IKE_SA_INIT exchange with the trust anchor listed in the REDIRECT payload. Client MUST include N(TRUST_ANCHOR_SUPPORTED) payload in this exchange if both the client and server (as indicated in the earlier redirect from server) support this feature. Initiator (client) Responder (Trust Anchor) ------------------ ------------------------ (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_FROM, Initial_IP_R), N(TRUST_ANCHOR_SUPPORTED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ], N(TRUST_ANCHOR_SUPPORTED) Padmakumar, et al. Expires January 28, 2010 [Page 8] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 IKEv2 Init exchange with Trust Anchor 9. IKEv2 Second Redirection by the Trust Anchor during IKE_AUTH Exchange Clients and trust anchors have to adhere to the rules specified in Section 6 of [IKEv2REDIRECT]. Additionally trust anchor includes N(GATE_PASS) and N(ACCESS_TOKEN) payloads along with N(REDIRECT, Initial_IP_R)in the IKE_AUTH if client specified this capability in the INIT exchange. In such cases trust anchor MUST use the same IP of Initial_IP_R received from N(REDIRECTED_FROM, Initial_IP_R) to redirect it back to the same server. N(ACCESS_TOKEN) and N(GATE_PASS) payloads MUST be included only after verifying client's identity. Initiator (client) Responder (Trust Anchor) ------------------ ------------------------ (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, [CERT,] AUTH, N(REDIRECT, Initial_IP_R), N(GATE_PASS), N(ACCESS_TOKEN))} IKEv2 Auth exchange with Trust Anchor 10. IKEv2 Second Init exchange with Server with N(TRUST_ANCHOR_INCLUDED) Clients MUST includes N(TRUST_ANCHOR_INCLUDED) payload in this exchange to prevent it from redirecting again. Server specifies N(GATE_PASS_REQ) in the reply. In such cases server MAY not include [CERTREQ] in the INIT reply as the proof is based on GATE_PASS based authentication. Padmakumar, et al. Expires January 28, 2010 [Page 9] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 Initiator (client) Responder (Server) ------------------ ------------------ (IP_I:500 -> IP_R:500) HDR(A,0), SAi1, KEi, Ni, --> N(REDIRECTED_FROM, Trust_Anchor_IP), N(TRUST_ANCHOR_INCLUDED) (IP_R:500 -> IP_I:500) <-- HDR(A,B), SAr1, KEr, Nr, N(GATE_PASS_REQ) IKEv2 Second INIT exchange with Server 11. IKEv2 Auth exchange with Server with N(GATE_PASS) Client includes GATE_PASS in the AUTH exchange and compute AUTH using ACCESS_TOKEN as the pre-shared key. Server computes ACCESS_TOKEN based on IDi and GATE_PASS using GP_SECRET the same way TRUST_ANCHOR computed it earlier. ACCESS_TOKEN = prf(encrypt(GP_SECRET, GATE_PASS | Client's Identity (IDi))) Client MUST use the same identity that it used during its earlier IKE_AUTH exchange with trust anchor. Otherwise the pre-shared key computed will be different and IKE_AUTH will fail. Where prf() and encrypt() are the pseudo random number generator algorithm and encryption algorithm negotiated between server and trust anchor during IKE_SA. It MUST be picked from the same IKE channel through which the server has distributed GP_SECRET and GATE_PASS to Trust Anchor. If server prefers to provide AUTH based on GATE_PASS it MUST include the same GATE_PASS received in the reply. Padmakumar, et al. Expires January 28, 2010 [Page 10] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 Initiator (client) Responder (Server) ------------------ ------------------ (IP_I:500 -> IP_R:500) HDR(A,B), SK {IDi, N(GATE_PASS) [IDr,]AUTH, SAi2, TSi, TSr} --> (IP_R:500 -> IP_I:500) <-- HDR(A,B), SK {IDr, AUTH, N(GATE_PASS), SAr2, TSi, TSr} IKEv2 AUTH exchange with Server The responder MAY include N(AUTH_LIFETIME) [RFC4478] in the Auth reply. Such cases client MUST not include N(TRUST_ANCHOR_INCLUDED) in the INIT exchange when it restarts INIT exchange. Instead it MAY include N(TRUST_ANCHOR_SUPPORTED) if it wants to continue using this mechanism. 12. IKEv2 Trust Anchor Messages 12.1. TRUST_ANCHOR_SUPPORTED The TRUST_ANCHOR_SUPPORTED payload is included in the initial IKE_SA_INIT request by the initiator to indicate support for the IKEv2 trust anchor mechanism described in this document. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRUST_ANCHOR_SUPPORTED The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate Padmakumar, et al. Expires January 28, 2010 [Page 11] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the TRUST_ANCHOR_SUPPORTED payload. 12.2. TRUST_ANCHOR_INCLUDED The TRUST_ANCHOR_INCLUDED payload is included in the initial IKE_SA_INIT request by the initiator to indicate support for the IKEv2 trust anchor mechanism described in this document and also to inform that it was redirected once and possess a valid GATE_PASS. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TRUST_ANCHOR_INCLUDED The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the TRUST_ANCHOR_INCLUDED payload. 12.3. GATE_PASS_REQ The GATE_PASS_REQ payload is included in the IKE_SA_INIT reply by the responder to indicate support for the IKEv2 trust anchor mechanism described in this document and also instruct initiator to include a GATE_PASS in the AUTH exchange. Padmakumar, et al. Expires January 28, 2010 [Page 12] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GATE_PASS_REQ The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the GATE_PASS_REQ payload. 12.4. GATE_PASS GATE_PASS payload is included in the initial IKE_SA_AUTH reply by the trust anchor to client, or the initial IKE_SA_AUTH request by the client to server to carry the GATE_PASS. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GATE_PASS ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GATE_PASS The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section Padmakumar, et al. Expires January 28, 2010 [Page 13] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the GATE_PASS payload. 12.5. ACCESS_TOKEN ACCESS_TOKEN payload is included in the initial IKE_SA_AUTH reply by the trust anchor to client. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ACCESS_TOKEN ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACCESS_TOKEN The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the ACCESS_TOKEN payload. 12.6. GP_SECRET Server uses an INFORMATIONAL exchange to distribute GP_SECRET. Padmakumar, et al. Expires January 28, 2010 [Page 14] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GP_SECRET ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GP_SECRET The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and the 'Notify Message Type' fields are the same as described in Section 3.10 of RFC 4306. The 'SPI Size' field MUST be set to 0 to indicate that the SPI is not present in this message. The 'Protocol ID' MUST be set to 0, since the notification is not specific to a particular security association. The 'Payload Length' field is set to the length in octets of the entire payload, including the generic payload header. The Notify Message Type' field is set to indicate the GP_SECRET payload. 13. Acknowledgements . 14. IANA Considerations This document defines six new IKEv2 Notification Message types as described in Section 'IKEv2 Trust Anchor Messages'. The six Notify Message Types must be assigned values between 16396 and 40959. o TRUST_ANCHOR_SUPPORTED o TRUST_ANCHOR_INCLUDED o GATE_PASS_REQ o GATE_PASS o ACCESS_TOKEN Padmakumar, et al. Expires January 28, 2010 [Page 15] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 o GP_SECRET 15. Security Considerations Servers MUST periodically update GATE_PASS. This is required to prevent clients from reusing the tokens. It is a good idea to force clients to reauthenticate when the GATE_PASS expires using N(AUTH_LIFETIME). [RFC4478] 16. References 16.1. Normative References [IKEv2REDIRECT] Devarapalli, V. and K. Weniger, "Redirect Mechanism for IKEv2", June 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", April 2006. 16.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006. Padmakumar, et al. Expires January 28, 2010 [Page 16] Internet-Draft IKEv2 Redirect and Authentication Offload July 2009 Authors' Addresses Padmakumar A.V. Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India Phone: +91 80 4103 3184 Email: paav@cisco.com Manikchand Bafna Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India Phone: +91 80 4154 1365 Email: manikrb@cisco.com Pratima Sethi Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India Phone: +91 80 4154 1654 Email: psethi@cisco.com Padmakumar, et al. Expires January 28, 2010 [Page 17]