Subject: [IPsec] IPSec implementation query.

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Thu, 18 Aug 2011 11:48:18 +0530

Hello,

	IPSec in linux kernel doesn't seem to work with packets sent
from RAW socket.
I think this is as per the design of RAW socket, that they bypass the
transport layer. But as they enter the core IP layer, and there is a
policy to protect, they should get protected. But this does not happen?
Any clues?

Also, if this is not possible, how can we use kernel IPSec to protect
RAW socket data.

Thanks,
Prashant

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Thu, 25 Aug 2011 16:18:04 +0530

Hi ,
Can we not use the existing RSA keys to get the shared secret without using the DH computation
Because of the calculation that are involved.
Let's say A wants to initiate a session with B.
Let A get the Public key of B from CA by sending a protected message using public key of CA.
Use the obtained public key for sending the shared secret to B and same from the other
End has well, this will ensure authentication and avoiding DH computation.

I feel that certificate can be used for authentication and as well has negotiated Symmetric key using the 
 Concept of Asymmetric cryptography which is one of the good features of certificate.

Why in Ikev2, certificates are just used for authentication and why they are not used for 
negotiating Symmetric key instead in place of DH computation. Is it to avoid use of Trusted CA negotiation.

Thanks and Regards
Naveen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Prashant Batra (prbatra)
Sent: Tuesday, July 26, 2011 6:33 PM
To: Yaron Sheffer; Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] DH keys calculation performance

Thanks Yoav and Yaron  for the suggestions.
Even I was thinking and tried generating and storing the key pair  well in the beginning,.  This helped to some extent.

The secret calculation is also very expensive, but this has to be done in midst of the exchange only.

Regards,
Prashant 

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 4:47 PM
To: Yoav Nir
Cc: Prashant Batra (prbatra); [email-masked]
Subject: Re: [IPsec] DH keys calculation performance

You might want to review http://tools.ietf.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces the computational costs of renewing an IKE SA when a client needs to reconnect to a gateway a second time after some failure.

Thanks,
    Yaron

On 07/26/2011 01:40 PM, Yoav Nir wrote: 

On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:

Hello,

The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange 
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?

Hi Prashant.

I know of three ways to optimize the D-H exchange.

First, note that each peer has to perform two operations: 
 1. Generate: create a random x and calculate X=2^x mod p
 2. Derive: calculate the shared secret S=Y^x mod p
The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long before the exchange. If your problem is degraded performance at some peak, you can pre-generate some values. This has a high cost in memory, but can be useful for dealing with peaks.

Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p
If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=x<=2048 and store these values. After that, both the generate and derive operations become simple multiplications of the resulting values. This has a fixed cost in memory, but can accelerate things.

Third, you may want to look at the EC groups. The EC operations require less computation.

Hope this helps

Yoav

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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 25 Aug 2011 06:27:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Naveen B N (nbn)
> Sent: Thursday, August 25, 2011 6:48 AM
> Cc: [email-masked]; Prashant Batra (prbatra)

Well, you certainly can use certificates (with public key encryption keys) to transport keying material; indeed, the ciphersuite of TLS that is in general use does exactly that.

However, it does have a few drawbacks.  Here are some of the reasons that the IKEv2 designers may have chosen not to use it:

- Transporting keying material lacks forward secrecy.  "Forward secrecy" is the property that, if some actually recovers the entire state of one (or both) of the sides, they still won't be able to decrypt a transcript of a session that had happened earlier (because the state needed to decrypt it was zeroized when the session was closed).  With key transport, it is impractical to zeroize the private key used during the exchange, and with that, the attacker can decrypt the keying material, and from there, rederive the session keys.  In contrast, with DH, as long as both sides zeroize the private exponents and shared secrets (along with the session state), the attacker does not have enough information.

- IKEv2 allows other types of authentication beyond certificates; using public key encryption as a step in generating keying material would imply that we would need a different mechanism to generate keying material for other types of authentication.  This is certainly not impossible (in fact, IKEv1 did have different mechanisms based on authentication type, although for different reasons); the IKEv2 designers decided to unify that.

> Even I was thinking and tried generating and storing the key pair  well
> in the beginning,.  This helped to some extent.
> 
> Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces
> the computational costs of renewing an IKE SA when a client needs to
> reconnect to a gateway a second time after some failure.
> 
> Thanks,
>     Yaron
> 
> The "Derive" operation has to be done during the exchange, but the
> "Generate" operation can be done long before the exchange. If your
> problem is degraded performance at some peak, you can pre-generate some
> values. This has a high cost in memory, but can be useful for dealing
> with peaks.
> 
> If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p
> for 0<=x<=2048 and store these values. After that, both the generate
> and derive operations become simple multiplications of the resulting
> values. This has a fixed cost in memory, but can accelerate things.
>

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Thu, 25 Aug 2011 22:03:48 +0530

Hi Scott,

Please find the queries and comments inline ..

Scott>- Transporting keying material lacks forward secrecy.  "Forward secrecy" is the property that, if some actually recovers the entire state of one (or both) of the sides, they still won't be able to decrypt a transcript of a session that had happened earlier (because the state needed to decrypt it was zeroized when the session was closed).  With key transport, it is impractical to zeroize the private key used during the exchange, and with that, the attacker can decrypt the keying material, and from there, rederive the session keys.  In contrast, with DH, as long as both sides zeroize the private exponents and shared secrets (along with the session state), the attacker does not have enough information.

Naveen>> TO maintain "Forward Secrecy", we have to change the keys from time to time based on the key length, which can be achieved by re-negotiating 
        new keys with the communicated Symmetric key.
	  But if you say that the first session used is to derive the private key of the peer, then Asymmetric key should never be used for deriving symmetric keys
        Or to protect data. If Certificate are still used in TLS for negotiation of Symmetric keys, this is a major issue because they are used in important places.

Naveen>>So, Certificates should only be used for authentication in a protected environment is it.
	  What could be the life time of the RSA keys then, how long will it take to derive a private key from a public key with the best available resources.
	  Then it comes down to DH method being the best secured available solution for negotiating Symmetric key on the fly, without having shared keying material with the peer.

Scott>- IKEv2 allows other types of authentication beyond certificates; using public key encryption as a step in generating keying material would imply that we would need a different mechanism to generate keying material for other types of authentication.  This is certainly not impossible (in fact, IKEv1 did have different mechanisms based on authentication type, although for different reasons); the IKEv2 designers decided to unify that.

Naveen>>May be Ikev2 designers feel that the intruder may selects a week authentication type if exposed in plan message, But I think we are authenticating the INIT_MESSAGE in IKE_AUTH
        Message, so they could have provided a authentication method in IKE_INIT message.

Thanks and Regards
Naveen

-----Original Message-----
From: Scott Fluhrer (sfluhrer) 
Sent: Thursday, August 25, 2011 6:57 PM
To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir
Cc: [email-masked]; Prashant Batra (prbatra)
Subject: RE: [IPsec] DH keys calculation performance

> Of Prashant Batra (prbatra)

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 25 Aug 2011 09:47:42 -0700

> From: Naveen B N (nbn)
> Sent: Thursday, August 25, 2011 12:34 PM
> To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
> [email-masked]
> Cc: [email-masked]'; Prashant Batra (prbatra); ipsec-tools-
> [email-masked]; [email-masked]; ipsec-
> [email-masked]
> Scott>- Transporting keying material lacks forward secrecy.  "Forward
> secrecy" is the property that, if some actually recovers the entire
> state of one (or both) of the sides, they still won't be able to
> decrypt a transcript of a session that had happened earlier (because
> the state needed to decrypt it was zeroized when the session was
> closed).  With key transport, it is impractical to zeroize the private
> key used during the exchange, and with that, the attacker can decrypt
> the keying material, and from there, rederive the session keys.  In
> contrast, with DH, as long as both sides zeroize the private exponents
> and shared secrets (along with the session state), the attacker does
> not have enough information.
> 
> Naveen>> TO maintain "Forward Secrecy", we have to change the keys from
> time to time based on the key length, which can be achieved by re-
> negotiating
> 	  But if you say that the first session used is to derive the
> private key of the peer, then Asymmetric key should never be used for
> deriving symmetric keys
>         Or to protect data. If Certificate are still used in TLS for
> negotiation of Symmetric keys, this is a major issue because they are
> used in important places.

I believe you misunderstand; we're not using the asymmetric key to "derive" the symmetric keys, but instead just to transport it.

Here's the scenario:
- Side A picks some keying material ("premaster secret" is TLS's terminology for it)
- Side A encrypts it with Side B's public key, and sends it to B
- Side B decrypts it with his own private key
- Both side A and side B use that keying material (and possibly other information that has been exchanged) to derive the real session keys

The problem I was discussing: what if, after the session has been shut down, the attacker recovers side B's private key?  This private key is unlikely to be zeroized along with the session (at least, with the current CA infrastructure); using this private key, the attacker could decrypt the encrypted keying material (just like B did), and rederive the session keys (again, just like B did).

> 	  What could be the life time of the RSA keys then, how long will
> it take to derive a private key from a public key with the best
> available resources.
> 	  Then it comes down to DH method being the best secured
> available solution for negotiating Symmetric key on the fly, without
> having shared keying material with the peer.
> 
> Scott>- IKEv2 allows other types of authentication beyond certificates;
> using public key encryption as a step in generating keying material
> would imply that we would need a different mechanism to generate keying
> material for other types of authentication.  This is certainly not
> impossible (in fact, IKEv1 did have different mechanisms based on
> authentication type, although for different reasons); the IKEv2
> designers decided to unify that.
> 
> Naveen>>May be Ikev2 designers feel that the intruder may selects a
> week authentication type if exposed in plan message, But I think we are
> authenticating the INIT_MESSAGE in IKE_AUTH
> > Use the obtained public key for sending the shared secret to B and
> same
> > from the other
> > I feel that certificate can be used for authentication and as well
> has
> > negotiated Symmetric key using the
> > negotiating Symmetric key instead in place of DH computation. Is it
> to
> > avoid use of Trusted CA negotiation.
> 
> Well, you certainly can use certificates (with public key encryption
> keys) to transport keying material; indeed, the ciphersuite of TLS that
> is in general use does exactly that.
> 
> However, it does have a few drawbacks.  Here are some of the reasons
> that the IKEv2 designers may have chosen not to use it:
> 
> - Transporting keying material lacks forward secrecy.  "Forward
> secrecy" is the property that, if some actually recovers the entire
> state of one (or both) of the sides, they still won't be able to
> decrypt a transcript of a session that had happened earlier (because
> the state needed to decrypt it was zeroized when the session was
> closed).  With key transport, it is impractical to zeroize the private
> key used during the exchange, and with that, the attacker can decrypt
> the keying material, and from there, rederive the session keys.  In
> contrast, with DH, as long as both sides zeroize the private exponents
> and shared secrets (along with the session state), the attacker does
> not have enough information.
> 
> - IKEv2 allows other types of authentication beyond certificates; using
> public key encryption as a step in generating keying material would
> imply that we would need a different mechanism to generate keying
> material for other types of authentication.  This is certainly not
> impossible (in fact, IKEv1 did have different mechanisms based on
> authentication type, although for different reasons); the IKEv2
> designers decided to unify that.
> 
> >
> > Thanks and Regards
> > Naveen
> >
> > The secret calculation is also very expensive, but this has to be
> done
> > in midst of the exchange only.
> >
> > Regards,
> > Prashant
> >
> >
> > Third, you may want to look at the EC groups. The EC operations
> require
> > less computation.
> >
> > Hope this helps
> >
> > Yoav
> >
> >
> >

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Fri, 26 Aug 2011 11:07:01 +0530

Hi Scott,
if we can take care of the "Forward Secrecy",
When using Asymetric keys from certificates 
To negotiate symmetric keys, then certificate 
Can be used in place of DH Computation.

"TO maintain "Forward Secrecy", we have to change the keys from
time to time based on the key length, which can be achieved by re-
negotiating"

If this is possible then I can present a draft for the same.

Thanks & Regards
Naveen

-----Original Message-----
From: Scott Fluhrer (sfluhrer) 
Sent: Thursday, August 25, 2011 10:18 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; [email-masked]'
Cc: [email-masked]'; Prashant Batra (prbatra); [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [IPsec] DH keys calculation performance

Here's the scenario:

---

From: "ramaswamy" <[email-masked]>
Date: Fri, 26 Aug 2011 11:54:56 +0530

Hello

In the common case, there is a single IKE_SA_INIT exchange and a single
IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the
first Child SA. In exceptional cases, there may be more than one of each of
these exchanges.

                In case a DoS attack is expected on IKEv2, the responder may
fight back using certain defense methods. In DoS attack where the target is
flooded with session initiation (IKE_SA_INIT) requests from a spoofed IP
address the responder may use cookie negotiation to defend oneself. This
means that the responder does not do anything until it is verified that the
initiator can receive packets at the address from which it claims to be
sending them. This procedure is called IKEv2 negotiation with cookies and is
illustrated in below figure.

IK2.JPG

In cookie negotiation messages (1) and (4) constitute IKE_SA_INIT exchange
and messages (2) and (3) constitute cookie exchange that is used to verify
the initiator. Finally, an IKE_AUTH exchange consists of messages (5) and
(6).IKEv2 DoS protection is optional and it allows the responder to respond
to message 1 with a cookie, which the initiator equally has to include in
message 3. IKEv2 cookie negotiation tries to avoid redundant processing
until the existence of the initiator can be determined.

In peer to peer network environment, any one peer can act as either
initiator or responder. In this situation, resistance against DoS attack and
identity protection of both the initiator and the responder is crucial as
anyone can be a victim of attacks.

In client server environment resistance of client against DoS attack and
protection of identity of the server is not a priority. But protecting the
identity of client and resistance against DoS attack of server is more
vital. On the other hand, in wireless network environment, where the
bandwidth of channel is less and packet loss is more, DoS attack is major
issue because probability of packet loss is more when the channel is
flooded. 

Having several advantages, ikev2 still suffers from some deficiency, such as
DoS attack, replay attack, man-in-the middle attack, when using in different
network environments and connections. One problem is regarding the way it
protects the peers form DoS attack. It has cookies mechanism to protect
against DoS attack. In this case resistance can be obtained by increasing
the number of message in the initial exchange . What is paid to get the
level of protection is increasing two messages to initial exchange. This
forces the new delay to system especially in wireless environment with high
probability of packet loss. Therefore using this method attacker can gain
the success by introducing delay to valid initiator. Therefore in this case
there is no use of cookies negotiation because host would be still under Dos
attack. Cookies negotiation to be protecting the Dos attack also falls short
in case the attack is carried out by multiple sources and each peer reply
correctly to cookie negotiation.

It is important to protect the initiator's identity in both client-server
and peer to peer environment.  In original ikev2, only the identity of
responder is protected by both active and passive attacker. It fails to
protect the initiator identity from the active attacker. One of deficiency
of ikev2, which we found in both client server and peer to peer environment,
is when the responder is invalid entity, the initiator knows about the
responder only when responder is authenticating to initiator.  In this case
the initiator is victim of replay attack and all the computation carried out
by initiator would go in vain.  This is also called as CPU based dos attack
and memory based dos attack.

Proposed new negotiations 

ik3.JPG

Before initial exchange begins initiator looks up to the pre shared secret
with the intended responder and does the hash value on first half of pre
shared secret, nonce of the initiator. Once the responder receives the
request it looks up the correspondence pre shared key in its table and it
takes the nonce form initiator request message then it does a hash value to
authenticate the initiator. After authentication of initiator the responder
calculate the hash value of its own by using first half of the preshared
key, initiator nonce and responder nonce and send the response to initiator
so that ikev2 can avoid the replay attack, because only the intended user,
who has pre shared key, can only generate hash value. After the IKE_SA_INIT
exchange that is initial  authentication is successful, both the parties
calculates the quantity called SKEYSEED from nonce, second half part  of the
pre shared key and the Diffie-Hellman shared secret established. SKEYSEED
also used to calculate the seven other keys to protect the further messages.

SKEYSEED = PRF (Ni | Nr | second half of PSK, gIR).

In case a DoS attack is expected on IKEv2, the responder may fight back
using our advanced cookie negotiation method  which ensure responder  does
no to do anything until it is verified that the initiator can receive the
packets at the address from which it is claims to be sending them. Upon
receiving cookies request message the initiator calculates hash value on
received cookie, first half of the preshared key and nonce of the initiator
to authenticate to responder. Generating the hash value of preshared key
with responder cookie ensure that only intended initiator can replay for the
cookie request. If the cookie negotiation fails, protocol will halt.

Kindly share the views on the same,

Best Regards ,

Ram

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 26 Aug 2011 06:56:50 -0700

> Sent: Friday, August 26, 2011 1:37 AM
> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav
> Nir'
> Cc: [email-masked]'

No, you'd have the change the asymmetric keys all well; with the private key, the attacker can still recover the session (symmetric) keys.

Now, it's not impossible to change the public keys; however, it does involve generating a fresh private/public key pair.  With RSA, at least, that's a lot more expensive than doing a single exchange (or, for that matter, several dozen simple exchanges), and so if the point of this is to reduce the total amount of computation, well, that rather misses the point.

> Cc: [email-masked]'; Prashant Batra (prbatra); 'ipsec-tools-
> [email-masked]'; [email-masked]';
> [email-masked]'
> I believe you misunderstand; we're not using the asymmetric key to
> "derive" the symmetric keys, but instead just to transport it.
> 
> Here's the scenario:
> - Both side A and side B use that keying material (and possibly other
> information that has been exchanged) to derive the real session keys
> 
> The problem I was discussing: what if, after the session has been shut
> down, the attacker recovers side B's private key?  This private key is
> unlikely to be zeroized along with the session (at least, with the
> current CA infrastructure); using this private key, the attacker could
> decrypt the encrypted keying material (just like B did), and rederive
> the session keys (again, just like B did).
> 
> >
> >         Message, so they could have provided a authentication method
> in
> > IKE_INIT message.
> >
> >
> > Thanks and Regards
> > Naveen
> >
> > > Can we not use the existing RSA keys to get the shared secret
> without
> > > using the DH computation
> > > Let A get the Public key of B from CA by sending a protected
> message
> > > using public key of CA.
> > >  Concept of Asymmetric cryptography which is one of the good
> features
> > > of certificate.
> > >
> > > You might want to review
> http://tools.ietf.org/html/rfc5996#section-
> > > 2.12.
> > >
> > > Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1
> mod
> > > p)) mod p

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Fri, 26 Aug 2011 11:00:33 +0530

Hi Scott,

Thanks & Regards
Naveen

-----Original Message-----
From: Scott Fluhrer (sfluhrer) 
Sent: Thursday, August 25, 2011 10:18 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'; [email-masked]'
Cc: [email-masked]'; Prashant Batra (prbatra); [email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: [IPsec] DH keys calculation performance

Here's the scenario:

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Mon, 29 Aug 2011 11:24:26 +0530

Hi Scott,
Even with the Pre-shared secret, the protocol can't keep up the property of " perfect Forward secrecy".
I have assumed the both the server and client use pre-shared secret, same below methods applies to Certificate based 
Authentication has well.
Below steps show why.

Subject: Intruder X acts has server only to get the access of auth payload.

1)A send IKE_INIT to indented server.
2) X[ intruder ] receives the INIT and process just has the protocol and replies with the generated
public value for DH. IKE_INT response is from Intruder instead of Server by creating the packet using 
a raw socket using [ IP spoofing].
3)A and X now generate the Sk key which is used to encrypt the next IKE_AUTH message.
4)A sends IKE_AUTH and intruder receives the same and he is able to decrypt the message and get access to IDR and Auth payload.
5)Intrudes gets hold of the AUTH data and work on it to derive the Pre-shared Secret { eg. Brute force}.
6) Since The Pre-shared secret is not changes the Intruder can now behave has the Initiator to server[IDR] 
And complete the Ikev2 flow. 

Kindly share your view on the above .

Thanks and Regards
Naveen

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Aug 2011 09:04:53 +0300

Hi Naveen

If you use a 128-bit or 256-bit truly random shared secret (like you
should, although probably nobody does), brute force will never work. If
you use a weaker shared secret, such as something with 20-40 bits of
entropy, then your offline dictionary attack becomes practical.

For suggested ways of counteracting this, take a look at these:
http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut
http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2
http://tools.ietf.org/html/draft-shin-augmented-pake

On 8/29/11 8:54 AM, "Naveen B N (nbn)" <[email-masked]> wrote:

>I have assumed the both the server and client use pre-shared secret, same
>below methods applies to Certificate based
>Authentication has well.
>Below steps show why.
>
>4)A sends IKE_AUTH and intruder receives the same and he is able to
>decrypt the message and get access to IDR and Auth payload.
>No, you'd have the change the asymmetric keys all well; with the private
>key, the attacker can still recover the session (symmetric) keys.
>
>Now, it's not impossible to change the public keys; however, it does
>involve generating a fresh private/public key pair.  With RSA, at least,
>that's a lot more expensive than doing a single exchange (or, for that
>matter, several dozen simple exchanges), and so if the point of this is
>to reduce the total amount of computation, well, that rather misses the
>point.
>
>>
>Scanned by Check Point Total Security Gateway.

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 28 Aug 2011 23:31:06 -0700 (PDT)

Hi Naveen,

  Yoav is right that increasing the size of the secret, and ensuring it
is uniformly random, will mitigate this sort of dictionary attack. And
the 3 drafts he mentions will basically foil it entirely.

  But the attack you mention does not affect "perfect forward secrecy".
That is the property that even with the loss of a long term credential
(like the pre-shared secret learned by dictionary attack) the adversary
is unable to determine the session key from a different run of the
protocol. This property still holds even with a successful dictionary
attack against a pre-shared key.

  regards,

  Dan.

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Mon, 29 Aug 2011 14:10:16 +0530

Hi Dan and Yoav,
Thank you and appreciate for the timely comments on my view and 
sharing the drafts for the same.

I was thinking to bring a Token concept in Ikev2 which will be 
Given by the responder, so that the session keys is bound to a 
life time and If the Key is still valid IKE_INIT can be skipped
and IKE_AUTH is directly used even in the next sessions. 

Tokens= Session key + Life time.

The above will save DH computation and key negotiation in case 
the session was aborted for some reason and if the client has 
multiple make break of sessions.

The above will save multiple times of authentication of client 
who was already authenticated.

Kindly share your views on token to be used has authenticators.

Thanks and Regards
Naveen

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, August 29, 2011 12:01 PM
To: Yoav Nir
Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar
Singh Jenwar (rsj); [email-masked]
Subject: Re: [IPsec] Perfect Forward secrecy

  Hi Naveen,

  regards,

  Dan.

On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote:
>>Even with the Pre-shared secret, the protocol can't keep up the
property
>>of " perfect Forward secrecy".
>>2) X[ intruder ] receives the INIT and process just has the protocol
and
>>replies with the generated
>>public value for DH. IKE_INT response is from Intruder instead of
Server
>>by creating the packet using
>>6) Since The Pre-shared secret is not changes the Intruder can now
behave
>>has the Initiator to server[IDR]
>>> > Naveen>>So, Certificates should only be used for authentication in
a
>>> > protected environment is it.
>>> > week authentication type if exposed in plan message, But I think
we
>>> are
>>> > > Why in Ikev2, certificates are just used for authentication and
why
>>> > > they are not used for
>>> > > Even I was thinking and tried generating and storing the key
pair
>>> >  well
>>> > > the computational costs of renewing an IKE SA when a client
needs
>>> > > The DH exchange (Calculation of Public/Private key and the
Secret)
>>> > > problem is degraded performance at some peak, you can
pre-generate
>>> > some
>>> > > If you're using a 2048-bit D-H group, you can pre-calculate 2^x
mod
>>> p

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Aug 2011 05:21:20 -0400

At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote:
>property of " perfect Forward secrecy".
>I have assumed the both the server and client use pre-shared secret, 
>same below methods applies to Certificate based
>Authentication has well.
>Below steps show why.

PFS refers to the ability of an adversary to recover the symmetric key(s)
used to encrypt traffic.  The analysis you provided does not address that
concern. IKE's use of ephemeral DH provides PFS.

Steve

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Mon, 29 Aug 2011 15:49:34 +0530

Hi Dan and Yoav Nir,

Kindly share your views on token to be used has authenticators
For multiple sessions.

Thanks and Regards
Naveen

-----Original Message-----
From: Dan Harkins [mailto:[email-masked]] 
Sent: Monday, August 29, 2011 12:01 PM
To: Yoav Nir
Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar

  Hi Naveen,

  regards,

  Dan.

property
same
and
Server
behave
a
we
why
pair
needs
Secret)
pre-generate
mod

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 29 Aug 2011 21:35:55 +0300

Hi Naveen,

please take a look at RFC 5723, which is very similar to your idea.

Thanks,
     Yaron

On 29.8.2011 13:19, Naveen B N (nbn) wrote:
>> On 8/29/11 8:54 AM, "Naveen B N (nbn)"<[email-masked]>  wrote:
>>
>>> Hi Scott,
>>>> Thanks&  Regards

---

From: "Naveen B N (nbn)" <[email-masked]>
Date: Tue, 30 Aug 2011 11:16:32 +0530

Hi Yaorn,

Pleased to know that there is an RFC which is similar to 
My idea already, but I am happy to know that I am thinking in right
direction,
thanks you for your reply.

Also please find the below idea has well.

In the years to come since there are plenty of 
IPv6 address available. An organization may have 
Multiple entry points to its network and hope 
Most of the organization want to provider Work 
>From home has well :). 

Don't you think that the gateway needs to handle all the
Authentication by itself for so many users, will it 
Not be better to offload only authentication process to 
a IKEV2 server, so that there is one dedicates server 
to perform the token based authentication.

What i really want to propose is a Ikev2 client - server 
Model, where the gateway needs to only accept a part 
Of the message has authenticator and dedicate itself 
to perform what it is really meant for.

Kindly share your views on the above.

Thanks and Regards
Naveen

-----Original Message-----
From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, August 30, 2011 12:06 AM
To: Naveen B N (nbn)
Cc: Dan Harkins; Yoav Nir; [email-masked]; Saravana Ravindran
(sarravin); Sastry SK (sassk); Scott Fluhrer (sfluhrer)
Subject: Re: [IPsec] Avoid multiple authentication's

Hi Naveen,

Thanks,
     Yaron

On 29.8.2011 13:19, Naveen B N (nbn) wrote:
>>>>> Naveen>>  TO maintain "Forward Secrecy", we have to change the
keys
>>>> from

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Aug 2011 12:11:06 +0300

ramaswamy writes:
> Before initial exchange begins initiator looks up to the pre shared
> secret with the intended responder and does the hash value on first
> half of pre shared secret, nonce of the initiator. Once the
> responder receives the request it looks up the correspondence pre
> shared key in its table and it takes the nonce form initiator
> request message then it does a hash value to authenticate the
> initiator.

This is bit like how IKEv1 did it, and it has same problem than IKEv1
had with that, meaning it does not provide ANY identity protection at
all. 

The responder needs to find the pre-shared key for the initiator based
only with the information that are in the first IKE_SA_INIT packet.
This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni
does not help at all in this process. The only information that
responder has which it can use is the source IP-address of the
IKE_SA_INIT packet.

This has the effect that the pre-shared key will be tied to the source
IP-address of the initiator, which mean every passive listener will
also see that same IP-address and will know the identity of the
initiator.

The method in IKEv2 where the PSK is not tied to the IP-address of the
initiator offers much better identity protection, as now the responder
identity is only releaved to the active attacker.
-- 
[email-masked]