RE: draft-ietf-ipsec-ikev2-06.txt

["Beadles, Mark A" <MBeadles@smartpipes.com>]

Hi all, delurking here for a moment as an implementor of a system which
computationally generates IKE PSK's.

Obviously a maximum-length cryptographically random PSK is "best" from a
total security pt of view, in opposition to human generated passwords.
This does not seem to be in question. The question is how and whether to
mandate and/or enforce this.  

One point I'd like to make is, if the protocol specifies a MUST for
this...then there would have to exist some method for determining
noncompliance with this MUST.  It is in my opinion contradictory to specify
the PSK's are defined and exchanged "out of band" and then set a MUST
requirement on that out-of-band process.  An IKE implementation itself will
operate correctly and in compliance with this specification regardless of
the means of derivation of the PSK.  A SHOULD is still a strong
recommendation.  

(Additionally, if you are going down this path, "deriving the shared secret
from a password is not secure" doesn't go far enough.  True, "user passwords
are unlikely to have sufficient randomness".  But so would using host or
peer IP address or name or system time, for example.  The point is GIGO:
insufficient entropy in, insufficient security out.)


I'd suggest amending the text so that section 2.15 contains that protocol
specification in SHOULD terms; and then including very strong best practices
recommendations in the Security Considerations section.  This will leave no
doubt as to the desirability of randomness, but will not muddy the core
protocol with things that cannot reasonably be enforced within the protocol
itself.

2.15:

   It will commonly be the case (but it is not required) that if a shared
secret
   is used for authentication that the same key is used in both directions.
[snip]  In
   the case of a pre-shared key, the AUTH value is computed as:

      AUTH = prf(Shared Secret | "Key Pad for IKEv2", <message octets>)

   where the string "Key Pad for IKEv2" is ASCII encoded and not null
   terminated. The shared secret can be variable length. The pad string
   is added so that if the shared secret is derived from a password, the
   IKE implementation need not store the password in cleartext, but
   rather can store a one way transformation of it that could not be
   used as a password equivalent for protocols other than IKEv2. [end]

5 Security Considerations:

When using pre-shared keys, a critical consideration is how to ensure the
randomness of these secrets.  The strongest practice is to ensure that any
pre-shared key contain as much randomness as the strongest key being
negotiated. Deriving a shared secret solely from a password, name, other
low-entropy source is not secure; passwords and other such sources are
subject to dictionary and social engineering attacks, among others.


+ Mark Anthony Beadles  + mbeadles@smartpipes.com +



-----Original Message-----
From: David Jablon [mailto:dpj@theworld.com] 
Sent: Wednesday, 09 April 2003 16:58
To: Paul Hoffman / VPNC; Charlie_Kaufman@notesdev.ibm.com
Cc: IPsec WG
Subject: Re: draft-ietf-ipsec-ikev2-06.txt


Paul,

I don't really want to debate the point of whether the text should *allow*
for the use of weakened Shared Secret keys.  But it seems like the
implications need to be more clearly stated, and whether an implementation
must allow for full-strength keys is not addressed in the SHOULD version.

Here's the proposed text in question:

2(b)+:
        "When pre-sharing a key for use in prf-based authentication 
        (i.e., Shared Secret") this key {SHOULD | MUST} be of the length
        of the key for the prf agreed for use by the parties, and this key
        {SHOULD NOT | MUST NOT} be derived solely from a password
        or other data that has less randomness than a truly random key
        of the appropriate length."

At 09:47 AM 4/9/03 -0700, Paul Hoffman / VPNC wrote:
>At 10:46 AM -0400 4/8/03, David Jablon wrote:
>>I too prefer "MUST", and I prefer "MUST NOT" in the addition.
>
>Could you explain the technical reason for that? If someone uses a 
>password instead of a sufficiently-random shared secret, will the PRF 
>break?

I think that's the wrong question, or at least I don't understand how
insufficiently random input can "break" a PRF.

But your first question forces me to elaborate my concern over the SHOULD
version.  Using "SHOULD", the security of an implementation may certainly be
broken.  And any relevant security proofs or arguments that assume that keys
are random will certainly not apply.

The text in draft 06 states that human-chosen password-derived keys are
insecure in this context but it doesn't fully explain why. (See proposed
change below.) Naively replacing key bytes with password bytes results in a
skewed distribution. Depending on how the password is chosen, an N-byte
password may have as little as 10% to 20% of the randomness of an N-byte
key.  Just having the high bit of each ASCII password byte set to zero
guarantees at least a 12.5% loss.

A good technical reason for saying MUST instead of SHOULD in 2(b)+ is that
SHOULD permits implementations that restrict ALL keys to insecure length
and/or insufficient randomness.

>We have no way of testing if someone has used a password vs. a shared 
>secret. ...

Now that you mention it, there are surely some easy ways to detect common
causes for insufficient randomness.  But I wasn't proposing such a
requirement.

>... If we say MUST and MUST NOT, we are saying that implementations 
>must somehow test for this. ...

No.  I don't think so.  At least I didn't intend to.
It does (and should) say something about the design of the mechanism for
shared secret key entry, and for shared key selection (if any) --- namely
that they should not force or encourage the use of weakened keys.

>... SHOULD and SHOULD NOT (with the appropriate wording about the 
>problems of passwords) seems more realistic, but if there truly is a 
>technical problem with using a password in a PRF as Hugo has described, 
>then we should know about it.

If we didn't know how passwords are different than keys,
and how our security assumptions require truly random keys, then we should
now.

A little more wordsmithing would seem to be needed to fix the technical
problem with the SHOULD version of 2(b)+. Even if weak keys are supported,
it seems good to at least require that implementations MUST *permit* the use
of full-strength keys, and { MUST | SHOULD } *encourage* the use of
full-strength keys.

Also, one sentence in draft 06 should be expanded to better distinguish the
insecure practice from various other secure ways of deriving shared secrets
from combinations of passwords and keys. Here's a suggested expansion:

        "Note that it is a common but [[ typically ]] insecure practice to
have a
        shared key derived [[ solely ]] from a user chosen password[[,
        without incorporating another source of randomness ]]."

-- David