David McGrew | 8 Feb 2010 22:01
Picon
Favicon

Re: comments and questions on draft-krawczyk-hkdf and related work

Hi Hugo,

I never heard back from you on my security questions about HKDF.  I'm  
resending the original email from last year, with the questions that  
Pasi answered stripped out.

On Oct 20, 2009, at 2:43 PM, David McGrew wrote:

> Hi Hugo and Pasi,
>
> I have some comments and questions on draft-krawczyk-hkdf-00 and "On
> Extract-then-Expand Key Derivation Functions and an HMAC-based KDF".
> First, thanks for taking on this work; it makes strong contributions
> in an important area.
>
> The most important question is: what is the precise security statement
> for HKDF?  What assumptions does one need to make about the hash
> function used in HKDF in order that the security analysis applies?
> The paper says that "it is shown in [23] (see Section 8) that using
> HMAC with a truncated output as an extractor allows to prove security
> under considerably weaker assumptions on the underlying hash
> function."  However, both of the Lemmas in that paper (and the
> implication in Section 8) make random oracle assumptions.
>
> A recommended instantiation of HKDF from the paper uses HMAC-SHA-512
> (with output truncated to 256 bits) in the extract stage and
> HMAC-SHA-256 in the expand stage.  I understand from [23] that "if we
> are interested in an output of L close-to-uniform bits then the key to
> the underlying compression function needs to be sufficiently larger
> than L," which motivates the use of SHA-512 in the extraction stage.
(Continue reading)

Hugo Krawczyk | 9 Feb 2010 21:21
Picon

Re: comments and questions on draft-krawczyk-hkdf and related work

On Mon, Feb 8, 2010 at 4:01 PM, David McGrew <mcgrew <at> cisco.com> wrote:
> Hi Hugo,
>
> I never heard back from you on my security questions about HKDF.  I'm
> resending the original email from last year, with the questions that Pasi
> answered stripped out.
>

David, I am sorry for not having answered these (very good) questions at the
time.  I lost them among many other messages on the subject.

I am preparing a revision of the paper that will be much more detailed on the
formal side than the one I posted in my website. The latter had a focus on
explaining the rationale for the construction in general and informal terms.

In the meantime let me give you specific answers to you questions below.

> On Oct 20, 2009, at 2:43 PM, David McGrew wrote:
>
>> Hi Hugo and Pasi,
>>
>> I have some comments and questions on draft-krawczyk-hkdf-00 and "On
>> Extract-then-Expand Key Derivation Functions and an HMAC-based KDF".
>> First, thanks for taking on this work; it makes strong contributions
>> in an important area.
>>
>> The most important question is: what is the precise security statement
>> for HKDF?  What assumptions does one need to make about the hash
>> function used in HKDF in order that the security analysis applies?
>> The paper says that "it is shown in [23] (see Section 8) that using
(Continue reading)

David McGrew | 28 Feb 2010 00:23
Picon
Favicon

draft-irtf-cfrg-kdf-uses-00

Hello,

this new draft investigates key derivation functions and their uses.    
Please send your comments to cfrg <at> irtf.org.  KDFs are an important  
topic because of HKDF and because of other standards work (including  
NIST's proposed transitions in SP 800-131).

regards,

David

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: February 26, 2010 11:32:50 PM PST
> To: bew <at> cisco.com
> Cc: mcgrew <at> cisco.com
> Subject: New Version Notification for draft-irtf-cfrg-kdf-uses-00
>
>
> A new version of I-D, draft-irtf-cfrg-kdf-uses-00.txt has been  
> successfuly submitted by Brian Weis and posted to the IETF repository.
>
> Filename:	 draft-irtf-cfrg-kdf-uses
> Revision:	 00
> Title:		 Key Derivation Functions and their Uses
> Creation_date:	 2010-02-26
> WG ID:		 Independent Submission
> Number_of_pages: 17
>
(Continue reading)

Picon

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

I see value in adding a simpler-than-EAP method, and support this effort. But overall it's an extremely
difficult task because of IPR.

I personally would hate to see a patent-encumbered solution - and that would disqualify EKE and PAK
outright (both held by Alcatel-Lucent, AFAIK). SRP would be the only acceptable (from IPR point of view)
candidate that I'm aware of. I've been told that EKE patent is written so broadly that it could cover SRP as
well - somebody more knowledgeable should comment on this.

Tnx!

Regards,
Uri

----- Original Message -----
From: cfrg-bounces <at> irtf.org <cfrg-bounces <at> irtf.org>
To: Hannes Tschofenig <Hannes.Tschofenig <at> gmx.net>
Cc: IPsecme WG <ipsec <at> ietf.org>; cfrg <at> irtf.org <cfrg <at> irtf.org>
Sent: Tue Mar 02 12:51:29 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

At 7:22 PM +0200 3/2/10, Hannes Tschofenig wrote:
>The challenge I have in understanding the motivation for this work is impacted by ...
>
>1) EAP is not only meant to be used with backend infrastructure.
>2) EAP is an authentication framework and EAP methods exist that support strong-password based authentication.
>3) EAP is implemented by folks in IKEv2 already.
>
>To me it seems that there is the chance to re-use existing mechanisms and to even re-use existing code.

Hannes, it is not really appropriate to re-open closed charter issues. As you know, this was already
(Continue reading)

Dan Harkins | 2 Mar 2010 21:12

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2


  Hello,

  There are other criteria that should be evaluated in making a
decision, such as how well does the solution fits into IKE(v2) and
does it support "crypto agility".

  RFC 2409 supported negotiation of various parameters, like the group
used for the Diffie-Hellman key exchange. That was removed in RFC 4306.
All of the candidate exchanges listed in draft-sheffer-ipsecme-pake-
criteria do some sort of discrete logarithm cryptography and therefore
it would be useful to list whether the candidate algorithm can use
any of the groups either negotiated or asserted by IKE(v2).

  For instance, I do not believe EKE is suitable for any of the
groups currently in the IANA registry of groups that can be used with
IKE(v2). The MODP groups have a generator that is a quadratic residue
which enables a passive attacker to eliminate passwords from the
dictionary if they do not decrypt to a value that is, itself, a quadratic
residue and ECP groups are unsuitable because a passive attacker can
eliminate passwords from the group if they do not decrypt to a valid point
on the curve. In either case, after seeing a trivial number of exchanges
a passive attacker is able to determine the password with high probability.

  So EKE requires a hard-coded special group to be used for its discrete
logarithm operations and since negotiation has been removed in RFC 4306
it means that the ability to change the group to suit the policy or whim
of the user (what is popularly termed "crypto agility") goes away. EKE
also requires specification of the mode of encryption used which may or
may not be the same as the one negotiated or asserted in IKE(v2). It
(Continue reading)

Dan Harkins | 2 Mar 2010 23:54

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2


  Hi Paul,

On Tue, March 2, 2010 1:37 pm, Paul Hoffman wrote:
[snip]
>>  RFC 2409 supported negotiation of various parameters, like the group
>>used for the Diffie-Hellman key exchange. That was removed in RFC 4306.
>>All of the candidate exchanges listed in draft-sheffer-ipsecme-pake-
>>criteria do some sort of discrete logarithm cryptography and therefore
>>it would be useful to list whether the candidate algorithm can use
>>any of the groups either negotiated or asserted by IKE(v2).
>
> OK, but...
>
>>  For instance, I do not believe EKE is suitable for any of the
>>groups currently in the IANA registry of groups that can be used with
>>IKE(v2). The MODP groups have a generator that is a quadratic residue
>>which enables a passive attacker to eliminate passwords from the
>>dictionary if they do not decrypt to a value that is, itself, a quadratic
>>residue and ECP groups are unsuitable because a passive attacker can
>>eliminate passwords from the group if they do not decrypt to a valid
>> point
>>on the curve. In either case, after seeing a trivial number of exchanges
>>a passive attacker is able to determine the password with high
>> probability.
>
> Those two paragraphs don't line up. Why would you want to use the groups
> negotiated or demanded in the IKEv2 exchange if they allow for easier
> attacks? Wouldn't it be better to allow the PAKE to negotiate or demand
> its own, presumably better, groups?
(Continue reading)

Zooko Wilcox-O'Hearn | 3 Mar 2010 00:06
Gravatar

Re: draft-irtf-cfrg-kdf-uses-00

Folks:

Just for your information, in the Tahoe-LAFS project we've decided  
not to use HKDF after all for our key-derivation needs.

We do not need extraction, only expansion—all of the seeds (or  
"master keys") that we input to a KDF are unguessable, evenly  
distributed values of exactly the appropriate size.

Therefore, we now intend to use a KDF which we think is simple,  
widely understood, efficient, and with a nice security reduction  
argument. Our proposed KDF is: let the resulting key be the first few  
bytes of the XSalsa20 keystream keyed by the master key.

If this KDF is distinguishable from random then this immediately  
implies a significant weakness in XSalsa20 as a cipher. XSalsa20  
exhibiting such a weakness would be very surprising.

We can use test vectors from other people's XSalsa20 implementations  
to check the correctness of our KDF in our unit tests.

Currently we are working on the next problem—which is out-of-scope of  
HKDF standardization—of how to securely, efficiently, and testably  
generate an integer of the appropriate range to use as the private  
exponent in elliptic curve DSA. You can see our notes about how to do  
that here:

http://allmydata.org/trac/pycryptopp/ticket/2#comment:13

Thank you very much to everyone, especially Dave McGrew and Hugo  
(Continue reading)

Dan Harkins | 3 Mar 2010 01:48

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2


  Hi David,

On Tue, March 2, 2010 3:49 pm, Black_David <at> emc.com wrote:
[snip]
>
> OTOH, I think you've oversimplified here ...
>
>>   The candidate exchanges all rely on the "hard problem" of doing a
>> discrete logarithm in one of the defined groups. It's the same "hard
>> problem" that makes the Diffie-Hellman portion of IKE secure. If the
>> group negotiated or demanded in IKE allows for an "easier attack" then
>> it shouldn't be used in the IKE exchange to do the Diffie-Hellman.
>
> If I follow your logic, I think you're arguing that because the existing
> groups allow easier attacks on password authentication (e.g., based on
> checks on what a guessed password decrypts to) then they allow easier
> attacks on IKE with existing authentication, *hence* those groups are
> unacceptable to use with IKE.  I think the *hence* is off the mark due to
> the much larger candidate search space when other techniques (e.g.,
> certificate-based) are used to authenticate.

  That wasn't what I was arguing. I think all the candidate exchanges
are based on the computational Diffie-Hellman assumption. And the
work factor to attack them on that front should be the same as the
work factor to attack a standard Diffie-Hellman key exchange. Or am
I missing something?

  I don't think any of the currently-defined groups are unacceptable
to use with IKE. But hypothetically, if there was some group defined
(Continue reading)

Picon

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

You're good!  :-)

On the vendor side - perhaps EKE patent concern was the cause (you implement/sell free SRP and get slapped
with EKE licensing)? And the users found alternative solutions in the meanwhile?

Do you think weak passwords are too dangerous overall (many other ways of attacking them outside of direct
protocol attempts that we try to defend against), and so we shouldn't entertain them at all?

Tnx!
Regards,
Uri

----- Original Message -----
From: pgut001 <pgut001 <at> wintermute02.cs.auckland.ac.nz>
To: smb <at> cs.columbia.edu <smb <at> cs.columbia.edu>; Blumenthal, Uri - 0662 - MITLL
Cc: cfrg <at> irtf.org <cfrg <at> irtf.org>; Hannes.Tschofenig <at> gmx.net <Hannes.Tschofenig <at> gmx.net>;
ipsec <at> ietf.org <ipsec <at> ietf.org>; paul.hoffman <at> vpnc.org <paul.hoffman <at> vpnc.org>
Sent: Tue Mar 02 19:41:43 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

"Steven M. Bellovin" <smb <at> cs.columbia.edu> writes:

>Note that the EKE patent expires in October 2011.  (At least I think it does;
>it was filed in October 1991.)  Depending on when you expect implementations
>to appear-- and given how long it takes to produce standards-track documents
>in the IETF -- it might not be a problem.

Given that SRP implementations have been available and more or less freely 
usable for quite some time and TLS-PSK is completely unencumbered anyway, I 
think the real issue won't be "when will implementations appear" but "why 
(Continue reading)

Picon

Re: [IPsec] Beginning discussion on secure password-only authentication for IKEv2

A reasonable question is - do all the proposed "EKE variations" have the same requirement (and the same
weakness)? Or only the original EKE does?

Regards,
Uri

----- Original Message -----
From: cfrg-bounces <at> irtf.org <cfrg-bounces <at> irtf.org>
To: Dan Harkins <dharkins <at> lounge.org>
Cc: ipsec <at> ietf.org <ipsec <at> ietf.org>; cfrg <at> irtf.org <cfrg <at> irtf.org>; Black_David <at> emc.com
<Black_David <at> emc.com>; paul.hoffman <at> vpnc.org <paul.hoffman <at> vpnc.org>
Sent: Tue Mar 02 19:58:35 2010
Subject: Re: [Cfrg] [IPsec] Beginning discussion on secure password-only authentication for IKEv2

On Tue, 2 Mar 2010 16:48:07 -0800 (PST)
"Dan Harkins" <dharkins <at> lounge.org> wrote:

> 
>   Hi David,
> 
> 
> On Tue, March 2, 2010 3:49 pm, Black_David <at> emc.com wrote:
> [snip]
> >
> > OTOH, I think you've oversimplified here ...
> >
> >>   The candidate exchanges all rely on the "hard problem" of doing a
> >> discrete logarithm in one of the defined groups. It's the same
> >> "hard problem" that makes the Diffie-Hellman portion of IKE
> >> secure. If the group negotiated or demanded in IKE allows for an
(Continue reading)


Gmane