Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document

[Andy Lutomirski <[e-mail]>]

On Mon, Dec 15, 2014 at 9:34 AM, Michael Hamburg <[e-mail]> wrote:
>
>> On Dec 15, 2014, at 3:52 AM, Stephen Farrell <[e-mail]> wrote:
>>
>>
>>
>> On 15/12/14 11:16, Yoav Nir wrote:
>>> But I would really like to know who needs a PAKE right now. PAKEs
>>> require the server to store the cleartext password or a password
>>> equivalent, creating a security issue that is potentially worse than
>>> sending cleartext passwords through authenticated channels (as in
>>> form-based or basic authentication to a TLS-protected server)
>>
>
> It is definitely a disadvantage of the SPAKE2 draft as currently written that it does not support augmentation, which would allow the server to store a non-password-equivalent token.  Perhaps this part of the feedback would best be expressed as “there should be an augmented option in the draft, such as PAKE2+”?
>
>> +many - PAKEs are IMO cool but mostly-useless crypto for exactly
>> this reason (and before others disagree, yes, I know some folks
>> disagree:-) If however, CFRG folk want to work on 'em I've no
>> objection but just so you all know, there is no horde of IETFers
>> waiting with bated breath for more PAKE protocol options.
>
>> There are to be fair a quite small number of sensible people who
>> do figure there's a niche there to fill though (Dan H. for example
>> but not sure who else), so I could of course be wrong about that.
>> As I understand it, the niche Dan has in mind is for signing up
>> to get a certificate in a PKI, where the password is used to
>> authenticate the certificate request. Even in that case, I'm
>> not convinced that PAKEs add value - esp since a one (or limited)
>> time use password could be better there and requires no new
>> crypto.
>>
>
> PAKEs are definitely a niche technology, but they are occasionally useful.  For example, they would be handy to protect WiFi, and possibly to add a layer of protection to protocols like SSH and IMAP which are often accessed with a password.

IMO essentially all password-protected crypto tokens (chip-and-PIN
cards, etc) should be using PAKEs to protect the PIN.  Otherwise if
you sniff a valid transaction between the keypad and the token, you
can very easily brute-force the PIN.

Admittedly, the usual threat models probably don't distinguish such
attacks from attacks that directly compromise the keypad, but I bet
that it's easy to sniff enough of the transaction from RF leakage to
do the same thing if you can put some malicious device near the
keypad, even if you haven't compromised the keypad or token and both
have perfect internal side-channel countermeasures.

--Andy