Re: [IPsec] Perfect Forward secrecy

"Dan Harkins" <dharkins@lounge.org> Mon, 29 August 2011 06:29 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274E121F855B for <ipsec@ietfa.amsl.com>; Sun, 28 Aug 2011 23:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.223
X-Spam-Level:
X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfPBGI1lE-Dd for <ipsec@ietfa.amsl.com>; Sun, 28 Aug 2011 23:29:43 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A082F21F86EE for <ipsec@ietf.org>; Sun, 28 Aug 2011 23:29:43 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3FCDD1022404C; Sun, 28 Aug 2011 23:31:06 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 28 Aug 2011 23:31:06 -0700 (PDT)
Message-ID: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net>
In-Reply-To: <CA81055B.598C%ynir@checkpoint.com>
References: <CA81055B.598C%ynir@checkpoint.com>
Date: Sun, 28 Aug 2011 23:31:06 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Yoav Nir <ynir@checkpoint.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Naveen B N <nbn@cisco.com>, Rajeshwar Singh Jenwar <rsj@cisco.com>, Scott Fluhrer <sfluhrer@cisco.com>
Subject: Re: [IPsec] Perfect Forward secrecy
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 06:29:45 -0000

  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)" <nbn@cisco.com> 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.teras@iki.fi'
>>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools-
>>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net';
>>> 'ipsec-tools-devel@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.teras@iki.fi
>>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools-
>>> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net;
>>> ipsec-
>>> > tools-devel@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.
>>>
>>> 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).
>>>
>>> >
>>> > 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: ipsec@ietf.org; Prashant Batra (prbatra)
>>> > Subject: RE: [IPsec] DH keys calculation performance
>>> >
>>> >
>>> >
>>> > > -----Original Message-----
>>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On
>>> > Behalf
>>> > > Of Naveen B N (nbn)
>>> > > Sent: Thursday, August 25, 2011 6:48 AM
>>> > > To: Yaron Sheffer; Yoav Nir
>>> > > Cc: ipsec@ietf.org; Prashant Batra (prbatra)
>>> > > Subject: Re: [IPsec] DH keys calculation performance
>>> > >
>>> > > 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.
>>> >
>>> > 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
>>> > >
>>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On
>>> > Behalf
>>> > > Of Prashant Batra (prbatra)
>>> > > Sent: Tuesday, July 26, 2011 6:33 PM
>>> > > To: Yaron Sheffer; Yoav Nir
>>> > > Cc: ipsec@ietf.org
>>> > > 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:yaronf.ietf@gmail.com]
>>> > > Sent: Tuesday, July 26, 2011 4:47 PM
>>> > > To: Yoav Nir
>>> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org
>>> > > 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
>>> > > IPsec@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/ipsec
>>> > > _______________________________________________
>>> > > IPsec mailing list
>>> > > IPsec@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/ipsec
>>
>>Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>