Subject: [Ipsec] Extended Authentication IKEv1 - IKEv2

From: Uma Shankar Ch <[email-masked]>
Date: Fri, 10 Sep 2004 23:02:11 +0530

Can IKEv1 be used with any mutual authentication  method using Xauth?
Am not aware of it.

In IKEv2 extended authentication happen as part of AUTH exchange before 
authenticating the
Client by the server. But, in IKEv1 it happens after establishing trusted 
authentication
channel with whatever way authentication is configured ( by pre-shared key 
or public key
certificates) by the administrator. Is it because with IKEv1, we can't use 
mutual authenticating
method?

In this context, in summary, I have the following questions

1. What is the rationale of changing the way extended authentication starts 
from v1 to v2?

Of course, there would be definitely certain advantages with this change, 
but am not able to
  understand what are those.

  (i) Is that, the repercussion of this change is the text in Security 
Considerations section
(Section 5) of the draft?

"Use of EAP authentication changes the probing possibilities somewhat.
  When EAP authentication is used, the responder proves its identity
  before the initiator does, so an initiator that knew the name of a
  valid initiator could probe the responder for both its name and
  certificates."

2.  I could not find any text relating to the change of the way extended 
authentication happen in  IKEv1 and the proposed standard in IKEv2 in 
"Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt".

3. The last minor point.

  (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which 
is obsolete and the
new one being  RFC 3748?
  (ii) In the text wherever applicable, the draft is mentioning "Extended 
Authentication ..."
it should have been "Extensible Authentication..."

Can any body clarify on this?

-Uma

www.intoto.com

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2004 21:33:37 +0300

Hi Uma,

I don't have an answer to your primary question, but:

> *"Appendix A: Summary of changes from IKEv1"* of 
> *"draft-ietf-ipsec-ikev2-15.txt"*.

Yes. I would suggest adding the following text to Appendix A:

"(NN) To support authentication through the Extensible
Authentication Protocol (EAP) [ref]."

>  (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which 

Yes, which is a problem that people have complained
about :-)

   http://www.vpnc.org/ietf-ipsec/mail-archive/msg00474.html

Please refer to RFC 3748.

(It strikes me that there's probably other things that
have not been adopted in the IKEv2 draft. For instance,
the above message complained about a typo s/NAC/NAK,
which is still wrong in -15...)

>  (ii) In the text wherever applicable, the draft is mentioning 
> "*Extended Authentication *..."
> it should have been "*Extensible Authentication*..."

Right.

--Jari

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Sep 2004 07:59:53 +0300

AFAIK the rationale is that EAP is not used between two IPSec gateways, 
but with a client connecting to a gateway (or "access concentrator").  
There are two reasons why the gateway should identify first.

1. The gateway authenticates with a certificate or shared secret.  The 
EAP methods may be less secure, so a fake gateway can either do a MITM 
attack and connect to the real gateway, or even worse, get the 
credentials and be able to connect to the real gateway later.  If you 
look at an EAP method such as GTC (gateway asks "Password?", client 
answers "12345"), you don't want your client to do GTC with a gateway 
that hasn't authenticated yet.  The certificates (and PSK) are assumed 
to be more secure, and an authentication should not give the attacker 
enough information to impersonate a gateway.

2. The gateway is assumed to be known.  Its identity (as opposed to its 
PSK or private key) are usually not secret.

On 10/09/2004, at 20:32, Uma Shankar Ch wrote:

>  In IKEv2 extended authentication happen as part of AUTH exchange 
> before authenticating the
>  Client by the server. But, in IKEv1 it happens after establishing 
> trusted authentication
>  channel with whatever way authentication is configured ( by 
> pre-shared key or public key
>  certificates) by the administrator. Is it because with IKEv1, we 
> can't use mutual authenticating
>  method?
>
>  1. What is the rationale of changing the way extended authentication 
> starts from v1 to v2?
>
>  Of course, there would be definitely certain advantages with this 
> change, but am not able to
>  2.  I could not find any text relating to the change of the way 
> extended authentication happen in  IKEv1 and the proposed standard in 
> IKEv2 in "Appendix A: Summary of changes from IKEv1" of 
> "draft-ietf-ipsec-ikev2-15.txt".
>
>  3. The last minor point.
>
>   (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 
> which is obsolete and the
>  new one being  RFC 3748?
> "Extended Authentication ..."

---

From: Uma Shankar Ch <[email-masked]>
Date: Sun, 12 Sep 2004 19:22:48 +0530

I Thank You for your response.
Still...

At 07:59 AM 9/11/04 +0300, Yoav Nir wrote:
>but with a client connecting to a gateway (or "access 
>concentrator").  There are two reasons why the gateway should identify first.
>
>1. The gateway authenticates with a certificate or shared secret.  The EAP 
>methods may be less secure, so a fake gateway can either do a MITM attack 
>and connect to the real gateway, or even worse, get the credentials and be 
>able to connect to the real gateway later.  If you look at an EAP method 
>such as GTC (gateway asks "Password?", client answers "12345"), you don't 
>want your client to do GTC with a gateway that hasn't authenticated yet.

Uma:

Absolutely, client has to do EAP with an authenticated gateway. I 
completely agree with it and that is the reason 4th message from the 
responder does give cert payload ad AUTH to prove it's authenticity.
                      <--    HDR, SK {IDr, [CERT,] AUTH,EAP }

But a genuine  Gateway should also know it's talking to a real client 
before starting EAP.
My whole question is what is the advantage in dropping the AUTH payload to 
start EAP. We can always indicate responder to start EAP with a Notify 
similar to "EAP_ONLY_AUTHENTICATION"?

1. As said by you, even I think this is important, if EAP method is less 
secure. So, here It's Important to have a authenticated channel before 
hand  for both client  and the responder gateway, as is done in V1.

2. If EAP method is more secure, in the sense that which uses mutual 
authenticating method and generates MSK can also make use of the potential 
offered by IKEv2. With this most of the DoS attacks that could 
happen  because of unprotected initial messages of Mutual authenticating 
methods, as the underlying layer gave them a secured and authenticated 
channel can be avoided.
Otherwise even these methods, though those are working with IKEv2 are still 
susceptible as they don't have authenticated channel.

Am not understanding what is the advantage we are getting by dropping the 
AUTH payload in third message?

The only thing I can see is, it's reducing  computational burden on the 
responder gateway. Is it the real Advantage?

>The certificates (and PSK) are assumed to be more secure, and an 
>authentication should not give the attacker enough information to 
>impersonate a gateway.
>

Uma:
This answered my second mail question partially -- "why responder should 
expose his identity before authenticating the client".

Then it seems --- why the security consideration section,  should still 
contain this statement. Is it because just to alert????????

-Uma

www.intoto.com

>>channel with whatever way authentication is configured ( by pre-shared 
>>key or public key
>>certificates) by the administrator. Is it because with IKEv1, we can't 
>>use mutual authenticating
>>method?
>>
>><https://www1.ietf.org/mailman/listinfo/ipsec>https://www1.ietf.org/mailman/listinfo/ipsec 
>>
></blockquote></x-html>

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Sun, 12 Sep 2004 12:31:48 -0700

Hi Uma,
    Unlike in IKEv1, in IKEv2, there is only one level of authentication. That means, in IKEv2, the nodes need to
     authenticate the peers with one type of authentication. That is major advantage I see here (with respect to
    configuration). In IKEv1, there are two authentication stages to take advantage of AAA infrastrucutre.
    One is at the IKE level and  another at AAA level.     Clients are configured with preshared/Certificate and X-AUTH credentials. 
    This was un-necessary and complex configuration. One might say that, it provides good security. In reality, it is not.
    Remote access clients normally asked to share same preshared key (for a given SGW) and AAA authentication is
    actually used to authenticate the clients. Any time, key is known to multiple people,  the security associated
    with it will be always under suspect. So, it is not really giving any advantage.

    In regards to DoS attack, Clients also need to do same level computation to move onto next stage ie EAP stage.
    But certainly, it is a problem, in case of DDOS attack ie multiple clients under coordination can swamp the
    security gateway. This is generic problem, not only associated with IKE, but with whole of Internet and
    applications.  Note that IKE provide Cookie Notify mechanism to ensure that Client does the DH computation before
    Server does.

    In my view, when a security gateway is used as remote access server, its identity is in general has to be
    made known. In IKE, at least I see protection where SG Identity is given, only upon checking the client
    Identity. I believe that we can live with this limitation.

Srini
Intoto Inc.
www.intoto.com
  ----- Original Message ----- 
  From: Uma Shankar Ch 
  To: Yoav Nir 
  Cc: [email-masked] 
  Sent: Sunday, September 12, 2004 6:52 AM
  Subject: Re: [Ipsec] Extended Authentication IKEv1 - IKEv2

    AFAIK the rationale is that EAP is not used between two IPSec gateways, but with a client connecting to a gateway (or "access concentrator").  There are two reasons why the gateway should identify first. 

    1. The gateway authenticates with a certificate or shared secret.  The EAP methods may be less secure, so a fake gateway can either do a MITM attack and connect to the real gateway, or even worse, get the credentials and be able to connect to the real gateway later.  If you look at an EAP method such as GTC (gateway asks "Password?", client answers "12345"), you don't want your client to do GTC with a gateway that hasn't authenticated yet.  

  Uma: 

  Absolutely, client has to do EAP with an authenticated gateway. I completely agree with it and that is the reason 4th message from the responder does give cert payload ad AUTH to prove it's authenticity.
                       <--    HDR, SK {IDr, [CERT,] AUTH,EAP }

  But a genuine  Gateway should also know it's talking to a real client before starting EAP.
  My whole question is what is the advantage in dropping the AUTH payload to start EAP. We can always indicate responder to start EAP with a Notify similar to "EAP_ONLY_AUTHENTICATION"?

  1. As said by you, even I think this is important, if EAP method is less secure. So, here It's Important to have a authenticated channel before hand  for both client  and the responder gateway, as is done in V1.

  2. If EAP method is more secure, in the sense that which uses mutual authenticating method and generates MSK can also make use of the potential offered by IKEv2. With this most of the DoS attacks that could happen  because of unprotected initial messages of Mutual authenticating methods, as the underlying layer gave them a secured and authenticated channel can be avoided.
  Otherwise even these methods, though those are working with IKEv2 are still susceptible as they don't have authenticated channel.

  Am not understanding what is the advantage we are getting by dropping the AUTH payload in third message?

  The only thing I can see is, it's reducing  computational burden on the responder gateway. Is it the real Advantage?

    The certificates (and PSK) are assumed to be more secure, and an authentication should not give the attacker enough information to impersonate a gateway. 

    2. The gateway is assumed to be known.  Its identity (as opposed to its PSK or private key) are usually not secret. 

  Uma: 
  This answered my second mail question partially -- "why responder should expose his identity before authenticating the client".

  Then it seems --- why the security consideration section,  should still contain this statement. Is it because just to alert????????

  -Uma

  www.intoto.com

      In IKEv2 extended authentication happen as part of AUTH exchange before authenticating the 
      Client by the server. But, in IKEv1 it happens after establishing trusted authentication 
      channel with whatever way authentication is configured ( by pre-shared key or public key 
      certificates) by the administrator. Is it because with IKEv1, we can't use mutual authenticating 
      method? 

      1. What is the rationale of changing the way extended authentication starts from v1 to v2? 

      Of course, there would be definitely certain advantages with this change, but am not able to 
       understand what are those. 

       (i) Is that, the repercussion of this change is the text in Security Considerations section 
      (Section 5) of the draft? 

      2.  I could not find any text relating to the change of the way extended authentication happen in  IKEv1 and the proposed standard in IKEv2 in "Appendix A: Summary of changes from IKEv1" of "draft-ietf-ipsec-ikev2-15.txt". 

      3. The last minor point. 

       (i) Even "draft-ietf-ipsec-ikev2-15.txt" refers [EAP] as RFC 2284 which is obsolete and the 
      new one being  RFC 3748? 
       (ii) In the text wherever applicable, the draft is mentioning "Extended Authentication ..." 
      it should have been "Extensible Authentication..." 

      -Uma 

      www.intoto.com 

------------------------------------------------------------------------------

---

From: Uma Shankar Ch <[email-masked]>
Date: Mon, 13 Sep 2004 23:22:57 +0530

Hi Srini,

I accept we might  have to live with some DDoS attacks. Thanks for the 
detailed clarification we are getting the definite advantage in terms of 
configuration. This would play very important role when it comes to 
wireless/mobile deployment scenarios.

Regards,
Uma

At 12:31 PM 9/12/04 -0700, Srinivasa Rao Addepalli wrote:
>      authenticate the peers with one type of authentication. That is 
> major advantage I see here (with respect to
>     One is at the IKE level and  another at AAA level.     Clients are 
> configured with preshared/Certificate and X-AUTH credentials.
>     This was un-necessary and complex configuration. One might say that, 
> it provides good security. In reality, it is not.
>     In regards to DoS attack, Clients also need to do same level 
> computation to move onto next stage ie EAP stage.
>     applications.  Note that IKE provide Cookie Notify mechanism to 
> ensure that Client does the DH computation before
>     Server does.
>
><http://www.intoto.com>www.intoto.com
>From: <mailto:[email-masked]>Uma Shankar Ch
>To: <mailto:[email-masked]>Yoav Nir
>Cc: <mailto:[email-masked]>[email-masked]
>>that hasn't authenticated yet.
>Uma:
>
>Otherwise even these methods, though those are working with IKEv2 are 
>still susceptible as they don't have authenticated channel.
>
>----------