Re: [IPsec] Perfect Forward secrecy
At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote: 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. 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Perfect Forward secrecy
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.
On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote:
> 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)" wrote:
>
>>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
>>
>>-Original Message-
>>From: Scott Fluhrer (sfluhrer)
>>Sent: Friday, August 26, 2011 7:27 PM
>>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
>>Cc: 'ipsec@ietf.org'
>>Subject: RE: [IPsec] DH keys calculation performance
>>
>>
>>> -Original Message-
>>> From: Naveen B N (nbn)
>>> Sent: Friday, August 26, 2011 1:37 AM
>>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav
>>> Nir'
>>> Cc: 'ipsec@ietf.org'
>>> Subject: RE: [IPsec] DH keys calculation performance
>>>
>>> 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"
>>
>>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.
>>
>>>
>>> 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'; 'timo.te...@iki.fi'
>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools-
>>> us...@lists.sourceforge.net'; 'ikev2-de...@lists.sourceforge.net';
>>> 'ipsec-tools-de...@lists.sourceforge.net'
>>> Subject: RE: [IPsec] DH keys calculation performance
>>>
>>>
>>> > -Original Message-
>>> > From: Naveen B N (nbn)
>>> > Sent: Thursday, August 25, 2011 12:34 PM
>>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
>>> > timo.te...@iki.fi
>>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools-
>>> > us...@lists.sourceforge.net; ikev2-de...@lists.sourceforge.net;
>>> ipsec-
>>> > tools-de...@lists.sourceforge.net
>>> > Subject: RE: [IPsec] DH keys calculation performance
>>> >
>>> > Hi Scott,
>>> >
>>> > Please find the queries and comments inline ..
>>> >
>>> > Scott>- Transporting keying
Re: [IPsec] Perfect Forward secrecy
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)" wrote:
>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
>
>-Original Message-
>From: Scott Fluhrer (sfluhrer)
>Sent: Friday, August 26, 2011 7:27 PM
>To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
>Cc: 'ipsec@ietf.org'
>Subject: RE: [IPsec] DH keys calculation performance
>
>
>> -Original Message-
>> From: Naveen B N (nbn)
>> Sent: Friday, August 26, 2011 1:37 AM
>> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav
>> Nir'
>> Cc: 'ipsec@ietf.org'
>> Subject: RE: [IPsec] DH keys calculation performance
>>
>> 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"
>
>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.
>
>>
>> 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'; 'timo.te...@iki.fi'
>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools-
>> us...@lists.sourceforge.net'; 'ikev2-de...@lists.sourceforge.net';
>> 'ipsec-tools-de...@lists.sourceforge.net'
>> Subject: RE: [IPsec] DH keys calculation performance
>>
>>
>> > -Original Message-
>> > From: Naveen B N (nbn)
>> > Sent: Thursday, August 25, 2011 12:34 PM
>> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
>> > timo.te...@iki.fi
>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools-
>> > us...@lists.sourceforge.net; ikev2-de...@lists.sourceforge.net;
>> ipsec-
>> > tools-de...@lists.sourceforge.net
>> > Subject: RE: [IPsec] DH keys calculation performance
>> >
>> > 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 ha
Re: [IPsec] Perfect Forward secrecy
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
-Original Message-
From: Scott Fluhrer (sfluhrer)
Sent: Friday, August 26, 2011 7:27 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
Cc: 'ipsec@ietf.org'
Subject: RE: [IPsec] DH keys calculation performance
> -Original Message-
> From: Naveen B N (nbn)
> Sent: Friday, August 26, 2011 1:37 AM
> To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav
> Nir'
> Cc: 'ipsec@ietf.org'
> Subject: RE: [IPsec] DH keys calculation performance
>
> 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"
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.
>
> 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'; 'timo.te...@iki.fi'
> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools-
> us...@lists.sourceforge.net'; 'ikev2-de...@lists.sourceforge.net';
> 'ipsec-tools-de...@lists.sourceforge.net'
> Subject: RE: [IPsec] DH keys calculation performance
>
>
> > -Original Message-
> > From: Naveen B N (nbn)
> > Sent: Thursday, August 25, 2011 12:34 PM
> > To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
> > timo.te...@iki.fi
> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools-
> > us...@lists.sourceforge.net; ikev2-de...@lists.sourceforge.net;
> ipsec-
> > tools-de...@lists.sourceforge.net
> > Subject: RE: [IPsec] DH keys calculation performance
> >
> > 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.
>
> I believe you misunderstand; we're not using the asymmetric key to
> "derive" the symmetric keys, but instead just to transport it.
