Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08

From: Yaron Sheffer <[email-masked]>
Date: Thu, 16 Apr 2009 10:37:32 +0300

This is a 2 week working group last call for
draft-ietf-ipsecme-ikev2-redirect-08. The target status for this document is
Proposed Standard. This is the document's second last call, following
comments by a number of people and several document revisions.

Please send your comments to the ipsec list by April 30, 2009, as follow-ups
to this message.

Please clearly indicate the position of any issue in the Internet Draft, and
if possible provide alternative text. Please also indicate the nature or
severity of the error or correction, e.g. major technical, minor technical,
nit, so that we can quickly judge the extent of problems with the document.

The document can be accessed here:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-08.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Thu, 16 Apr 2009 11:14:19 +0300

I see that in section 6 the following:

   In such cases, the gateway should send the REDIRECT notification
   payload in the final IKE_AUTH response message that carries the AUTH
   payload and the traffic selectors.  The gateway MUST NOT send and the
   client MUST NOT accept a redirect in an earlier IKE_AUTH message. 

I like that, and that was my position earlier, but wasn't the conclusion at San Francisco that the REDIRECT could come in either the first AUTH response (where we know the ID the client is using, temporary or not) *OR* in the last response?

When did we decide to not allow it in the first resopnse?

Other than that, I think the document is fine and ready for publication.

Yaron Sheffer wrote:

> draft-ietf-ipsecme-ikev2-redirect-08. The target status for 
> this document is Proposed Standard. This is the document's 
> second last call, following comments by a number of people 
> and several document revisions.
> 
> Please send your comments to the ipsec list by April 30, 
> 2009, as follow-ups to this message.
> 
> Please clearly indicate the position of any issue in the 
> Internet Draft, and if possible provide alternative text. 
> Please also indicate the nature or severity of the error or 
> correction, e.g. major technical, minor technical, nit, so 
> that we can quickly judge the extent of problems with the document.
> 

Email secured by Check Point

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 16 Apr 2009 10:56:34 -0700

Hello,

> I like that, and that was my position earlier, but wasn't the conclusion at San Francisco that the REDIRECT could come in either the first AUTH response (where we know the ID the client is using, t…

The text you quote above refers to the case when the gateway decides to 
redirect based on the EAP exchange or a as a result of interaction with 
the AAA server or some external entity (when multiple auth is used). The 
redirect is done in the final IKE_AUTH message.

> When did we decide to not allow it in the first resopnse?

We allow it. The first paragraph in section 6 and the message exchange 
just below it show this.

Vijay

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Sat, 18 Apr 2009 21:16:15 +0300

Vijay Devarapalli wrote:
> > I like that, and that was my position earlier, but wasn't the conclusion at 
> > San Francisco that the REDIRECT could come in either the first AUTH 
> > response (where we know the ID the client is using, temporary or not) 
> > *OR* in the last response?
>

The first paragraph refers to the non-EAP case. The paragraph I quoted 
is the one that refers to the EAP case, and this is the case where it makes 
sense to allow the REDIRECT both in the first and last IKE_AUTH 
responses. 

The case for the last response is the one that you made: The AAA server
may tell the gateway to send the user to another gateway.

The case for the first response is a little different. The content of the IDi 
payload tells the gateway to what domain the user belongs. "Domain" 
could map to a specific AAA server, and/or to a specific gateway.

Suppose a user connects to gateway-A with the IDi payload containing
"[email-masked]".  This is enough to tell the gateway that the
user should use gateway-B instead - policy says that all companyB 
employees connect to the gateway-B. Or maybe the user is 
"[email-masked]" and all such users should connect to the gateway
in Italy.   In both cases there is no point in authenticating to the local
AAA server. The gateway knows immediately to send the user to the 
appropriate gateway.

That is why I think (and I believe that was the conclusion in SF) that
the REDIRECT may come in both the first and last responses.

Yoav

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 19 Apr 2009 20:44:55 -0700

Hi,

> the REDIRECT may come in both the first and last responses.

Ok, got it. Redirect in the first IKE_AUTH response is always allowed, even
if there is an EAP exchange. I will clarify it in the next revision.

Vijay

---

From: Yoav Nir <[email-masked]>
Date: Mon, 20 Apr 2009 10:29:44 +0300

Hi

Come to think of it, I'm wondering about something else.

Let's suppose that the gateway cannot tell where the user should connect. The EAP exchange with the AAA server begins. The AAA server realizes that the user name ("jdoe") is not in its database, and the user should be redirected to gateway B.

What now?  Does it complete the exchange successfully, and redirect?  Or does it fail the exchange and redirect?

I think the obvious answer is to fail the exchange and redirect.  I think we should mandate that even with EAP failure, the client should honor the REDIRECT.

If the gateway authentication fails (the AUTH payload in the first IKE_AUTH response fails to authenticate) then I'm not sure what the right action is.  REDIRECT is accepted in an unauthenticated INITIAL exchange. Why not, then, in a failed authentication IKE_AUTH exchange?

Vijay Devarapalli wrote: 

> >>> I like that, and that was my position earlier, but wasn't the 
> >>> conclusion at San Francisco that the REDIRECT could come 
> in either 
> >>> the first AUTH response (where we know the ID the client 
> is using, 
> >>> temporary or not)
> >> The text you quote above refers to the case when the 
> gateway decides 
> >> to redirect based on the EAP exchange or a as a result of 
> interaction 
> >> with the AAA server or some external entity (when multiple auth is 
> >> used). The redirect is done in the final IKE_AUTH message.
> >> 
> >> We allow it. The first paragraph in section 6 and the message 
> >> exchange just below it show this.
> >> 
> >> Vijay
> > 
> > is the one that refers to the EAP case, and this is the 
> case where it 
> > makes sense to allow the REDIRECT both in the first and 
> last IKE_AUTH 
> > responses.
> > 
> > The case for the last response is the one that you made: The AAA 
> > server may tell the gateway to send the user to another gateway.
> > 
> > The case for the first response is a little different. The 
> content of 
> > the IDi payload tells the gateway to what domain the user 
> belongs. "Domain"
> > "[email-masked]".  This is enough to tell the gateway 
> that the user 
> > should use gateway-B instead - policy says that all 
> companyB employees 
> > connect to the gateway-B. Or maybe the user is 
> "[email-masked]" and 
> > all such users should connect to the gateway
> Ok, got it. Redirect in the first IKE_AUTH response is always 
> allowed, even if there is an EAP exchange. I will clarify it 
> in the next revision.
> 
> Vijay
> 
> > 
> > Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 20 Apr 2009 10:43:05 +0300

Below.

> -----Original Message-----
> From: Yoav Nir
> Sent: Monday, April 20, 2009 10:30
> To: Vijay Devarapalli
> Cc: Yaron Sheffer; IPsecme WG
> Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
> 
> Hi
> 
> Let's suppose that the gateway cannot tell where the user should connect.
> The EAP exchange with the AAA server begins. The AAA server realizes that
> the user name ("jdoe") is not in its database, and the user should be
> redirected to gateway B.
> 
> I think the obvious answer is to fail the exchange and redirect.  I think
> we should mandate that even with EAP failure, the client should honor the
> REDIRECT.
> 
> If the gateway authentication fails (the AUTH payload in the first
> IKE_AUTH response fails to authenticate) then I'm not sure what the right
> action is.  REDIRECT is accepted in an unauthenticated INITIAL exchange.
> Why not, then, in a failed authentication IKE_AUTH exchange?
> 
[YS] No, failing authentication is different from being unauthenticated. The
client may have a policy that says that it's willing to be redirected at
IKE_SA_INIT. But if it receives an AUTH value that is explicitly untrusted
(say, with a revoked certificate), I think it should not act on it. Even
though a malicious gateway could have responded in the first exchange etc.
etc.

Also note that it may be hard to untangle client authentication from gateway
authentication, e.g. when using symmetric password authentication such as
<self plug> EAP-EKE </self plug>.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 21 Apr 2009 13:31:32 +0300

So are we working with the assumption that the gateway (or the AAA server) can always authenticate any user that connects? 

> From: Yaron Sheffer 
> Sent: Monday, April 20, 2009 10:43 AM
> To: Yoav Nir; Vijay Devarapalli
> Cc: IPsecme WG
> > The EAP exchange with the AAA server begins. The AAA server 
> realizes 
> > that the user name ("jdoe") is not in its database, and the user 
> > should be redirected to gateway B.
> > 
> > What now?  Does it complete the exchange successfully, and 
> redirect?  
> > Or does it fail the exchange and redirect?
> > 
> > I think the obvious answer is to fail the exchange and redirect.  I 
> > think we should mandate that even with EAP failure, the 
> client should 
> > honor the REDIRECT.
> > 
> > IKE_AUTH response fails to authenticate) then I'm not sure what the 
> > right action is.  REDIRECT is accepted in an 
> unauthenticated INITIAL exchange.
> [YS] No, failing authentication is different from being 
> unauthenticated. The client may have a policy that says that 
> it's willing to be redirected at IKE_SA_INIT. But if it 
> receives an AUTH value that is explicitly untrusted (say, 
> with a revoked certificate), I think it should not act on it. 
> Even though a malicious gateway could have responded in the 
> first exchange etc.
> etc.
> 
> Also note that it may be hard to untangle client 
> authentication from gateway authentication, e.g. when using 
> symmetric password authentication such as <self plug> EAP-EKE 
> </self plug>.

---

From: <[email-masked]>
Date: Tue, 28 Apr 2009 10:10:47 +0200

<not wearing any hats>

1) The new versions since the previous WGLC introduced a number of
additional steps (e.g. nonce payload, clarifying PAD etc.) to the
redirection process, but currently these are spread over the whole
document, or in some cases, partly missing (e.g. the document never
says what the client should do with the nonce data in the REDIRECT
notification). IMHO these should be included in the overall flow in
Section 3. Proposed text:

3.  IKEv2 Initial Exchange with Redirect

   This section describes the use of Redirect mechanism during the
   IKE_SA_INIT exchange.  Gateway-initiated redirect and the use of
   redirect during IKE_AUTH exchange are explained in subsequent
   sections.

   The VPN client indicates support for the IKEv2 redirect mechanism
   and the willingness to be redirected by including a
   REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT
   request.  If the IKE_SA_INIT request did not include the
   REDIRECT_SUPPORTED notification, the responder MUST NOT use the
   redirect mechanism specified in this document.

   To redirect the IKEv2 session to another VPN gateway, the VPN
   gateway that initially received the IKE_SA_INIT request selects
   another VPN gateway (how the selection is made is beyond the scope
   of this document), and replies with an IKE_SA_INIT response
   containing a REDIRECT notification message. The notification
   includes the address of the selected VPN gateway, and the nonce
   data from the Ni payload in the IKE_SA_INIT request.

   Note that when the IKE_SA_INIT response includes the REDIRECT
   notification, the exchange does not result in the creation of an
   IKE_SA, and the responder SPI will be zero.
 
       Initiator                    Responder (initial VPN GW)
       ---------                    -------------------------

    (IP_I:500 -> Initial_IP_R:500)
    HDR(A,0), SAi1, KEi, Ni,   -->
    N(REDIRECT_SUPPORTED)

                              (Initial_IP_R:500 -> IP_I:500)
                          <-- HDR(A,0), N(REDIRECT, IP_R, nonce data)

   When the client receives the IKE_SA_INIT response, it MUST verify
   that the nonce data matches the value sent in the IKE_SA_INIT
   request. If the values do not match, the client MUST silently
   discard the response (and keep waiting for another response).  This
   prevents certain Denial-of-Service attacks on the initiator that
   could be caused by an attacker injecting IKE_SA_INIT responses with
   REDIRECT payloads.

   Next, the client initiates a new IKE_SA_INIT exchange to the
   address included in the REDIRECT payload. The VPN client includes
   the IP address of the original VPN gateway that redirected the
   client in the REDIRECTED_FROM notification. The IKEv2 exchange then
   proceeds as it would have proceeded with the original VPN gateway.

       Initiator                   Responder (Selected VPN GW)
       ---------                   ---------------------------

    (IP_I:500 -> IP_R:500)
    HDR(A,0), SAi1, KEi, Ni,   -->
    N(REDIRECTED_FROM, Initial_IP_R)

                              (IP_R:500 -> IP_I:500)
                          <-- HDR(A,B), SAr1, KEr, Nr,[CERTREQ]

    (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,
                                                 SAr2, TSi, TSr}

   In particular, the client MUST use the same Peer Authorization
   Database (PAD) and Security Policy Database (SPD) entries as it
   would have used with the original gateway. Receiving a redirect
   notification MUST NOT result in the modification of any PAD or SPD
   entries. In practise, this means the new gateway either has to
   either use the same responder identity (IDr) as the original
   gateway, or the PAD entry must use wildcards (such as
   gw*.example.com) that match multiple responder identities.

2) As I already noted in my March 2 email, the document does not say
exactly what information outside IPsec (i.e. Mobile IPv6) is being
updated by the redirect, and the security implications if it.

Perhaps something like this, added to the end of Section 3:

   When running IKEv2 between a Mobile IPv6 Mobile Node (MN) and Home
   Agent (HA), redirecting the IKEv2 exchange to another HA is not
   enough; the Mobile IPv6 signalling also needs to be sent to the new
   HA address. The MN MAY treat the information received in the
   IKE_SA_INIT response in similar way as it would treat HA discovery
   information received from other unauthenticated (and potentially
   untrustworthy) sources (such as DNS lookups not protected with
   DNSSEC). However, if the MN has authenticated information about its
   Home Agent, it MUST NOT be updated based on the IKE_SA_INIT
   response.

   If the REDIRECT notification is received during the IKE_AUTH
   exchange (after the HA has been authenticated; see Section 6), the
   MN MAY pass the new address to Mobile IPv6 and treat it in similar
   fashion as information from the Home Agent Switch Message
   [RFC5142].

   Gateway-initiated REDIRECT notifications exchanged in INFORMATIONAL
   exchanges (see Section 5) MUST NOT result in updating any Mobile
   IPv6 state. In such cases, the Home Agent Switch Message specified
   in [RFC5142] are used instead.

(I haven't fully thought through all the details, so comments are
welcome...)

And the security considerations text needs something, too.

3) Section 6, 1st paragraph: I think this text needs to be clearer
about whether an IKE_SA is created or not (current the SHOULDs
etc. make this somewhat unclear). IMHO if the client will always just
close the IKE_SA, it doesn't make much sense to create it in the first
place? But it looks like the intent of the current text might have
been that the IKE_SA *is* created... If that's the case, then the
message diagram below this paragraph should also show the
INFORMATIONAL exchange with Delete payload.

4) Section 6, last paragraph:

> payload and the traffic selectors.  The gateway MUST NOT send and
> the client MUST NOT accept a redirect in an earlier IKE_AUTH
> message.

This is a bit confusing, since the first sentence says "should", and
in this particular case, the final IKE_AUTH response does not
actually have the traffic selectors! Also, if the intent was to allow
redirect in the 1st IKE_AUTH response, this text doesn't do it.
Perhaps something like this?

   In such cases, the gateway can include the REDIRECT notification
   either in the first IKE_AUTH response, or the last IKE_AUTH
   response. The gateway MUST NOT send, and the client MUST NOT
   accept, the REDIRECT notification in any other IKE_AUTH response.

5) Section 9, last paragraph, is a bit confusing (even if the redirect
message was always authenticated, we still wouldn't want to modify the
PAD based on it), and in the wrong place (it's important part of the
protocol, not just a security consideration). The proposed text for
Section 3 included the essential parts, I think.

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Yaron Sheffer
> Sent: 16 April, 2009 10:38
> To: IPsecme WG
> Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08
>