Network Working Group AV. Padmakumar
Internet-Draft M. Bafna
Intended status: Standards Track P. Sethi
Expires: June 24, 2010 Cisco
December 21, 2009
IKEv2 Redirect based Authentication Offload and Proxy Session Resumption
draft-padmakumar-ikev2-redirect-and-auth-offload-02
Abstract
IKEv2 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 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.
IKEv2 Session Resumption proposes an extension to IKEv2 that allows a
client to re-establish an IKE SA with a gateway in a highly efficient
manner, utilizing a previously established IKE SA.
Redirect mechanism can also be used to redirect a client to another
router (trust anchor) to do mutual authentication and an optional
proxy session negotiation 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
and optional proxy session negotiation trust anchor redirects 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. Access Token based authentication permits IDr of
the responder to be different from that specified in Ticket and
permits client to reuse the proxy session (negotiated between client
and trust anchor) between client and server.
Such a mechanism is useful especially for low power devices like
handsets. For example, a mobile node can redirect a correspondent
node to its home agent. Home agent can form a proxy session with
correspondent node and then redirect it back to mobile node.
Status of this Memo
Padmakumar, et al. Expires June 24, 2010 [Page 1]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
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 June 24, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Padmakumar, et al. Expires June 24, 2010 [Page 2]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. GP_SECRET_INDEX . . . . . . . . . . . . . . . . . . . . . . . 6
5. GP_KEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. PROXY_TICKET . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. GP_SECRET and GATE_PASS Distribution to Trust Anchor . . . . . 8
10. IKEv2 First Init exchange with Server and Server
Redirection . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. IKEv2 Second Redirection by the Trust Anchor during
IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . . . . . 10
12. IKEv2 Proxy Session Resumption Exchange with Server with
N(GATE_PASS) . . . . . . . . . . . . . . . . . . . . . . . . . 11
13. IKEv2 Second Init exchange with Server with N(GATE_PASS) . . . 12
14. IKEv2 Auth exchange with Server with N(GATE_PASS) . . . . . . 12
15. IKEv2 Auth Offload and Proxy Session Resumption Messages . . . 13
15.1. GATE_PASS_SUPPORTED . . . . . . . . . . . . . . . . . . . 13
15.2. GATE_PASS . . . . . . . . . . . . . . . . . . . . . . . . 14
15.3. PROXY_TICKET_SUPPORTED . . . . . . . . . . . . . . . . . 15
15.4. ACCESS_TOKEN . . . . . . . . . . . . . . . . . . . . . . 15
15.5. GP_SECRET . . . . . . . . . . . . . . . . . . . . . . . . 16
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
18. Security Considerations . . . . . . . . . . . . . . . . . . . 17
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
19.1. Normative References . . . . . . . . . . . . . . . . . . 17
19.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Padmakumar, et al. Expires June 24, 2010 [Page 3]
Internet-Draft IKEv2 Redirect and Authentication Offload December 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.
IKEv2 Session Resumption [IKEv2RESUMPTION] proposes an extension to
IKEv2 that allows a client to re-establish an IKE SA with a gateway
in a highly efficient manner, utilizing a previously established IKE
SA.
Redirect mechanism can be used to redirect a client to another router
(trust anchor) to do mutual authentication and an optional proxy
session negotiation 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
and optional proxy session negotiation trust anchor redirects 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.
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
Padmakumar, et al. Expires June 24, 2010 [Page 4]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
one mentioned in the ticket. Access tokens computed are linked to
IDi values and MUST not be changed.
Trust anchor MUST choose the same cryptographic suit from client's
offer which the server would have chosen if the client had contacted
server directly.
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 and proxy
session negotiation 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_SECRET_INDEX : Server maintains a history of GP_SECRET and each
GP_SECRET is uniquely identified by the GP_SECRET_INDEX
o GP_KEY : Gate Pass Key (GP_KEY) is a set of secret keys, updated
periodically and identified by an Index. GP_KEY is used to
generate and verify GATE_PASS.
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.
o PROXY_TICKET : An IKEv2 ticket [IKEv2RESUMPTION] is a data
structure that contains all the necessary information that allows
an IKEv2 responder to re-establish an IKEv2 security association.
PROXY_TICKET is an IKEv2 ticket 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.
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 9 ). Length of
GP_SECRET is decided by the encryption algorithm negotiated between
server and trust anchor in the context of IKE_SA.
Padmakumar, et al. Expires June 24, 2010 [Page 5]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
4. GP_SECRET_INDEX
Gate Pass Secret index(GP_SECRET_INDEX) identifies the GP_SECRET.
Server maintains a history of GP_SECRET and each GP_SECRET is
uniquely identified by the GP_SECRET_INDEX
5. GP_KEY
GP_KEY is a set of authentication and encryption keys, 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(Section 6).
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.
6. GATE_PASS
An IKEv2 GATE_PASS is a data structure generated by the server and
contains all the necessary information that allows server to
recompute ACCESS_TOKEN based on the client's IDi. Server encrypt and
integrity protect GATE_PASS using GP_KEY and distributes to trust
anchors using N(GATE_PASS) notify payload. Clients receive the same
GATE_PASS from the trust anchors and include it in IKE_SA_INIT or
KE_SESSION_RESUME exchange when it restarts its IKE exchange with the
Padmakumar, et al. Expires June 24, 2010 [Page 6]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
server. Server computes GATE_PASS using following mechanism.
GATE_PASS = Signature | GP_KEY.Index | Secret
Length of each field is 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 IP | Trust Anchor ID |
GP_SECRET_INDEX | 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) [IKEv2REDIRECT],
N(ACCESS_TOKEN)(Section 7) and optional N(TICKET_OPAQUE)
[IKEv2RESUMPTION] payloads.
7. 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
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].
Padmakumar, et al. Expires June 24, 2010 [Page 7]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
N(ACCESS_TOKEN) payloads can be included only after successful
verification of client's identity.
8. PROXY_TICKET
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).
9. GP_SECRET and GATE_PASS Distribution to Trust Anchor
Server MAY periodically update GP_KEY and GP_SECRET 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(GATE_PASS_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 and GP_SECRETs 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
Padmakumar, et al. Expires June 24, 2010 [Page 8]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
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.
10. IKEv2 First Init exchange with Server and Server Redirection
Apart from the items specified in section 3 of [IKEv2REDIRECT] this
exchange includes N(GATE_PASS_SUPPORTED) and
N(PROXY_TICKET_SUPPORTED) payloads.
Initiator(client) Responder (Server)
----------------- ------------------
(IP_I:500 -> Initial_IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECT_SUPPORTED),
N(GATE_PASS_SUPPORTED),
N(PROXY_TICKET_SUPPORTED)
(Initial_IP_R:500 -> IP_I:500)
<-- HDR(A,0), N(REDIRECT,
Trust_Anchor_ID,
Ni_data),
N(GATE_PASS_SUPPORTED),
N(PROXY_TICKET_SUPPORTED)
IKEv2 First Init exchange with Server and Server Redirection
Subsequently client initiates a new IKE_SA_INIT exchange with the
Padmakumar, et al. Expires June 24, 2010 [Page 9]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
trust anchor listed in the REDIRECT payload.
Client MUST include N(GATE_PASS_SUPPORTED)and
N(PROXY_TICKET_SUPPORTED) payloads 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(GATE_PASS_SUPPORTED),
N(PROXY_TICKET_SUPPORTED)
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,
[CERTREQ],
N(GATE_PASS_SUPPORTED),
N(PROXY_TICKET_SUPPORTED)
IKEv2 Init exchange with Trust Anchor
11. 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 MAY include N(GATE_PASS), N(ACCESS_TOKEN)
and N(TICKET_OPAQUE) payloads along with N(REDIRECT, Initial_IP_R)in
the IKE_AUTH if client specified these capabilities 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) payloads MUST be included only after verifying
client's identity.
If trust anchor decides to include N(TICKET_OPAQUE) along with
N(REDIRECT, Initial_IP_R) in the IKE_AUTH exchange it MUST also
include N(GATE_PASS)and N(ACCESS_TOKEN) in the exchange.
Padmakumar, et al. Expires June 24, 2010 [Page 10]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
If trust anchor had redirected the client with N(TICKET_OPAQUE)
payload, client MUST use IKEv2 Session Resumption Exchange
(Section 12) to resume the proxy session (established between client
and trust anchor) with the server, otherwise client MUST proceed with
IKE_SA_INIT exchange (Section 13) and SHOULD include N(GATE_PASS)
payload in the exchange to prevent it from getting redirected again.
Initiator (client) Responder (Trust Anchor)
------------------ ------------------------
(IP_I:500 -> IP_R:500)
HDR(A,B), SK {IDi, [CERT,]
[CERTREQ,]
[IDr,]AUTH, SAi2, TSi, TSr
[,N(TICKET_REQUEST)]} -->
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, Initial_IP_R),
N(GATE_PASS), N(ACCESS_TOKEN)
[,N(TICKET_OPAQUE)])}
IKEv2 Auth exchange with Trust Anchor
12. IKEv2 Proxy Session Resumption Exchange with Server with
N(GATE_PASS)
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].
Padmakumar, et al. Expires June 24, 2010 [Page 11]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
Initiator (client) Responder (Server)
------------------ ------------------
HDR(A,0), [N(COOKIE),] Ni,
N(TICKET_OPAQUE) -->
N(REDIRECTED_FROM,
Trust_Anchor_IP),
N(GATE_PASS) [,N+]
<-- HDR(A,B),Nr [,N+]
IKEv2 Proxy Session Resumption Exchange with Server
13. IKEv2 Second Init exchange with Server with N(GATE_PASS)
Clients MUST includes N(GATE_PASS) payload in this exchange to
prevent it from getting redirected again.
In such cases server MAY not include [CERTREQ] in the INIT reply as
the proof is based on GATE_PASS based authentication.
Initiator (client) Responder (Server)
------------------ ------------------
(IP_I:500 -> IP_R:500)
HDR(A,0), SAi1, KEi, Ni, -->
N(REDIRECTED_FROM,
Trust_Anchor_IP),
N(GATE_PASS)
(IP_R:500 -> IP_I:500)
<-- HDR(A,B), SAr1, KEr, Nr,
IKEv2 Second INIT exchange with Server
14. 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, GATE_PASS and GP_SECRET
the same way TRUST_ANCHOR computed it earlier.
ACCESS_TOKEN = prf(encrypt(GP_SECRET, GATE_PASS | Client's Identity
Padmakumar, et al. Expires June 24, 2010 [Page 12]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
(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.
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(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.
15. IKEv2 Auth Offload and Proxy Session Resumption Messages
15.1. GATE_PASS_SUPPORTED
The GATE_PASS_SUPPORTED payload is included in the initial
IKE_SA_INIT request by the initiator to indicate support for the
IKEv2 auth offload mechanism described in this memo.
Padmakumar, et al. Expires June 24, 2010 [Page 13]
Internet-Draft IKEv2 Redirect and Authentication Offload December 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_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
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_SUPPORTED
payload.
15.2. 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
Padmakumar, et al. Expires June 24, 2010 [Page 14]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
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 payload.
15.3. PROXY_TICKET_SUPPORTED
The PROXY_TICKET_SUPPORTED payload is included in the initial
IKE_SA_INIT request by the initiator to indicate support for the
IKEv2 proxy session resumption mechanism described in this memo.
Note that proxy session resumption is dependent on auth offload
capability and client MUST also include GATE_PASS_SUPPORTED payload
in the exchange.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PROXY_TICKET_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
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_SUPPORTED
payload.
15.4. ACCESS_TOKEN
ACCESS_TOKEN payload is included in the initial IKE_SA_AUTH reply by
the trust anchor to client.
Padmakumar, et al. Expires June 24, 2010 [Page 15]
Internet-Draft IKEv2 Redirect and Authentication Offload December 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 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.
15.5. GP_SECRET
Server uses an INFORMATIONAL exchange to distribute GP_SECRET.
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
Padmakumar, et al. Expires June 24, 2010 [Page 16]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
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.
16. Acknowledgements
.
17. IANA Considerations
Section 15 defines five new IKEv2 notifications whose Message Type
values are to be allocated from the "IKEv2 Notify Message Types -
Status Types" registry.
o GATE_PASS_SUPPORTED
o PROXY_TICKET_SUPPORTED
o GATE_PASS
o ACCESS_TOKEN
o GP_SECRET
18. 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]
19. References
19.1. Normative References
[IKEv2REDIRECT]
Devarapalli, V. and K. Weniger, "Redirect Mechanism for
Padmakumar, et al. Expires June 24, 2010 [Page 17]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
the Internet Key Exchange Protocol Version 2 (IKEv2)",
November 2009.
[IKEv2RESUMPTION]
Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", December
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.
19.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.
Authors' Addresses
Padmakumar A.V.
Cisco Systems, Inc.
O'Shaugnessy Road
Bangalore, Karnataka 560025
India
Phone: +91 80 4103 3184
Email: paav@cisco.com
Padmakumar, et al. Expires June 24, 2010 [Page 18]
Internet-Draft IKEv2 Redirect and Authentication Offload December 2009
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 June 24, 2010 [Page 19]