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

[Yaron Sheffer <[e-mail]>]

Hi Nico,

ENONCE in and of itself is not vulnerable to an off-line dictionary 
attack because the password encrypts a random bit string, and we take 
care that there is no stray entropy (padding, MAC) that such an attacker 
could use.

As to the bigger question of why the protocol as a whole is not 
vulnerable to the attack, you will have to follow the proof in the paper 
(or maybe just ask my coauthor).

And regarding the usage scenario: the primary scenario is password-based 
machine-to-machine authentication. Yes, sysadmins are human (in most 
cases :-) and they tend to use short passwords for machine auth, much 
more often than we would have liked.

There is a secondary use case that's the usual human-to-server auth, 
where the peers are too lazy to use EAP. I'm questioning whether this 
scenario is interesting enough to add a salted "mode" into the protocol.

Thanks,
	Yaron

On 04/14/2011 08:59 PM, Nico Williams wrote:
> 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
> --