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

[Yaron Sheffer <[e-mail]>]

Yes, PACE is a ZKPP, and the AUTH payloads depend on values that the 
attacker cannot compute (PACESharedSecret). Again, this assertion is 
based on the mathematical proof of the protocol.

We have tried for many years to educate people to use better passwords. 
This has not worked. So we'd better assume that passwords are weak by 
default, and if they're good, all the better.

Thanks,
	Yaron

On 04/14/2011 09:44 PM, Nico Williams wrote:
> On Thu, Apr 14, 2011 at 1:25 PM, Yaron Sheffer<[e-mail]>  wrote:
>> 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.
>
> But the ENONCE paired with the AUTH payloads is subject to off-line
> dictionary attacks (the attacker will have to have impersonated the
> responder in order to obtain the necessary material).
>
>> 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).
>
> It sounds like you're asserting that PACE is a ZKPP.  Is that right?
>
>> 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.
>
> You might want to clarify this in the abstract and introduction then.
> But even so, as long as the passwords are human memorable and the
> mechanism is not a ZKPP, then my other comments stand.  However, if
> this is really for machine authentication then I'll be happy with text
> exhorting admins to pick good passwords.
>
>> 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.
>
> Fair enough.