Subject: [IPsec] Generating Keying Material for the IKE_SA (IKEv2)

From: Syed Ajim Hussain <[email-masked]>
Date: Mon, 22 Nov 2010 11:25:26 +0530

Hi All

   I have some doubt about Security of IKEv2 protocol.  In the process

   Of generating Keys, every parameter is taken from IKE_SA_INIT Messages  

   Which is un-unencrypted. 

   If attacker using some tools capturing all the IKE Packets from network,

   he can easily generates the Keys.  Although attacker can not establish a

   SA without proper configuration information, but still he can easily get 

   the Keys, and he will be able to decrypt all  the  IKE Encrypted and  

   IPSEC Encrypted packets.    

   Don't you think this is a big Security Risk? In IKEv1 Pre-shared key
auth, PSK was taken as  part of key

   Calculation with is a secret to generate Key and provides some level of
Security.  

   IKE Key generation process: 

   SKEYSEED = prf(Ni | Nr, g^ir)

   {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+

                 (SKEYSEED, Ni | Nr | SPIi | SPIr )

With Regards

Syed Ajim 

 

****************************************************************************

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

****************************************************************************

________________________________

 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, November 22, 2010 1:30 AM
To: [email-masked]
Subject: IPsec Digest, Vol 79, Issue 11

If you have received this digest without all the individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/ipsec

Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.

Send IPsec mailing list submissions to

      [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit

      https://www.ietf.org/mailman/listinfo/ipsec

or, via email, send a message with subject or body 'help' to

      [email-masked]

You can reach the person managing the list at

      [email-masked]

When replying, please edit your Subject line so it is more specific

than "Re: Contents of IPsec digest..."

Today's Topics:

   1. Re: HA protocol replay protection (Yaron Sheffer)

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

Message: 1

Date: Sun, 21 Nov 2010 00:01:47 +0200

From: Yaron Sheffer <[email-masked]>

Subject: Re: [IPsec] HA protocol replay protection

To: Pekka Riikonen <[email-masked]>

Cc: IPsecme WG <[email-masked]>, Tero Kivinen <[email-masked]>,   Raj

      Singh <[email-masked]>

Message-ID: <[email-masked]>

Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi Pekka,

the text you are quoting provides implementation guidance (probably good 

one), but does not "recommend" (in the RFC 2119 sense of the word, i.e. 

equivalent to a normative SHOULD) to do so. We should have stronger text 

if we are to avoid accidental replay.

Thanks,

      Yaron

On 11/20/2010 02:14 PM, Pekka Riikonen wrote:

> :

> : Let's take the extreme case where the cluster and the peer synchronize

> : the SA, then there is no IKE traffic, and then they synchronize the SA

> : again. If we don't do anything special, the second pair of synch

> : messages will be identical to the first, i.e. will look like a replay.

> : So we have to prevent this case. One trivial solution is to mandate one

> : liveness test (initiated by the peer) immediately after the synch.

> :

> Note that draft recommends that the sync is done only when the IKE SA is

> actually needed.  If there is not IKE traffic then the sync would have

> never been done in the first place.

> ...

>     Since there can be a large number of sessions at the standby member,

>     and sending synchronization exchanges for all of them may result in

>     overload, the standby member can choose to initiate the exchange in a

>     "lazy" fashion: only when it has to send or receive the request.  In

>     general, the standby member is free to initiate this exchange at its

>     discretion.

> ...

> I've implemented the lazy sync, it's seems the best way to do it.

>     Pekka

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

_______________________________________________

IPsec mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ipsec

End of IPsec Digest, Vol 79, Issue 11

*************************************

---

From: Syed Ajim Hussain <[email-masked]>
Date: Mon, 22 Nov 2010 12:05:19 +0530

As  per Nicolas Williams -->

The key is that eavesdroppers cannot easily compute g^ir (mod p).

The initiator computes g^ir = (g^r)^i mod p, while the responder

computes g^ir = (g^i)^r mod p.  The initiator knows i and the responder

knows r.  The attacker doesn't know i, nor r, because those are not

sent.

The attacker cannot easily compute them from g^i mod p nor g^r mod p.

Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p.

The relevant number theory topic is known as the "Computational

Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman

Problem).

Syed Ajim --> 

Attacker can know who is initiator , who is responder ,  by the First
IKE_INIT_SA Message ,  by Checking Responder Cookie Zero ,  

Initiator will send -->  g^I , in KE  payload with DH Group no. in  

                         IKE_SA_INIT  Message

Responder will send -->  g^R , in KE  payload with DH Group no.

                         IKE_SA_INIT  Message

So, in  SKEYSEED = prf(Ni | Nr, g^ir),  nothing is secret , if some attacker
can capture IKE  packets. 

So he can derive the Key also.

With Regards

Syed Ajim 

 

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, November 22, 2010 11:45 AM
To: Syed Ajim Hussain
Subject: Re: [IPsec] Generating Keying Material for the IKE_SA (IKEv2)

>    SKEYSEED = prf(Ni | Nr, g^ir)

                             ^^^^

The key is that eavesdroppers cannot easily compute g^ir (mod p).

The initiator computes g^ir = (g^r)^i mod p, while the responder

computes g^ir = (g^i)^r mod p.  The initiator knows i and the responder

knows r.  The attacker doesn't know i, nor r, because those are not

sent.

The attacker cannot easily compute them from g^i mod p nor g^r mod p.

Nor can the attacker easily compute g^ir mod p from g^i and g^r mod p.

The relevant number theory topic is known as the "Computational

Diffie-Hellman Problem" (and the related Decisional Diffie-Hellman

Problem).

Nico

--