Re: [secdir] secdir review of draft-kuegler-ipsecme-pace-ikev2

[Nico Williams <[e-mail]>]

On Thu, Apr 14, 2011 at 12:47 PM, Dan Harkins <[e-mail]> wrote:
> On Thu, April 14, 2011 10:25 am, Nico Williams wrote:
>> In RFC5056 terms, your "unauthenticated Diffie-Hellman" exchange is a
>> "channel".
>>
>> There seems to be a terminology disconnect.  As a result of this
>> disconnect you and others are discarding the work of others (e.g.,
>> SCRAM in this case) without understanding it in the first place.
>
>  I don't think there's a terminology disconnect. Yes, it's a "channel",
> but the important thing is it's not a "secure channel", which is what
> you said above.

I'm distinguishing secure from authenticated.  If the channel can
provide confidentiality and integrity protection then it's secure.  If
it's authenticated that's even better.

>  SCRAM is not resistant to off-line dictionary attack, PACE is. So
> the work of others has not just been ignorantly discarded, it is just
> not appropriate to use in this particular case.

I don't see how the ENONCE in PACE is resistant to off-line dictionary
attacks.  What am I missing?

I stand by my assertion that SCRAM with channel binding to the KE
exchange, and protected by that KE exchange, is protected against
passive attacks, and if the channel is authenticated, then it's also
protected against active attacks.  (Note that I never proposed SCRAM
w/o CB, nor would I have.)

If I'm right that ENONCE is resistant to off-line dictionary attacks
then I stand by my assertion that SCRAM (with CB) is at least as
secure as PACE, and arguably more so.

>  What is needed here is to parlay a low-entropy password into a
> secure secret without anything else. There is no way to "authenticate
> the responder with PKIK" (as you implied in another email) because
> there is nothing else that could be used in accordance with any PKIK RFC.
> Using SCRAM here would be more secure than the broken PSK mode of IKE(v2)
> today but would not be resistant to off-line dictionary attack.

I understand that PKIX credentials will not always be available for
either, much less both of the peers (if they are available for both
then the only thing the password adds is an additional authentication
factor, and is probably an undesirable complication).  However, I
expect that a certificate will often be available for "servers".  As
for SCRAM, again, _with_ CB it's no weaker than PACE.

>  Don't think of this as a username/password protocol. There is no
> real "user". There is just a password and the two side have to prove
> to each other they know it without leaking any information about it
> to each other or an adversary. SCRAM isn't the right tool for this job.

If there's no user and the password is randomly generated then I have
no concerns whatever.

However, everything in the I-D leads me to believe that the password
is intended to be memorable to human users.  For example, why bother
with stringprep if the password is intended to be a randomly generated
string?  Why bother with Unicode at all in that case?  Moreover, the
introduction specifically refers to weak shared secrets, which leads
me to believe that PACE is specifically intended for user
authentication.

So which is it?  Is PACE just an improved PSK mechanism?  Or is PACE a
password-based mechanism as we normally think of them (i.e., for human
users)?

Nico
--