Re: [kitten] SPAKE Preauth

[Nathaniel McCallum <[e-mail]>]

On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote:
> On Tue, Apr 28, 2015 at 05:53:01PM -0400, Benjamin Kaduk wrote:
> > "can't tell which factor was guessed incorrectly" seems like a 
> > pretty
> > important property (I would be really excited to see a scheme with 
> > this
> > property get deployed!), but it does not seem to be mentioned in 
> > the
> > current section 1.2 text.  (It does talk about avoiding
> > ciphertexts^Wpackets which are vulnerable to offline brute-force 
> > attack,
> > but I don't see anything mentioning the online attack as well.) 
> >  Hmm, this
> > is mentioned in the security considerations, at least.  I think it 
> > should
> > be more prominent earlier in the document.
> > 
> > However, it seems like the text at the end of section 4.3 wherein 
> > "[i]f
> > validation of the second factor requires furthe round-trips, the 
> > KDC MUST
> > reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" 
> > loses
> > the indistinguishability property, as the encrypted 
> > SPAKESecondFactor
> > would not be generated if the long-term key (password) was 
> > incorrect.
> > This seems inherent to second factors which require multiple round 
> > trips
> > to validate, though, so maybe we have to make a choice of the 
> > tradeoff.
> 
> Yes.  And 4.4 makes it worse because continued 2nd factor exchanges 
> use
> EncryptedData, including from the AS to the client (which can then
> confirm that its choice of password guess was incorrect).
> 
> The fix for this is to send AS->client 2nd factor continuations in 
> the
> clear if at all possible.  Which means that in the AS->client 3rd and
> subsequent passes we need a CHOICE of OCTET STRING or EncryptedData, 
> or
> perhaps allow the use of the null enctype in the AS->client 2nd 
> factor
> EncryptedData.
> 
> The AS will know as soon as it tries to decrypt the client's 2nd 
> factor
> (whose EncryptedData functions as a proof of possession) that the 
> client
> doesn't know the password.  In this case the AS should continue and
> process _a_ 2nd factor as much as possible as if the password was 
> right.
> The AS could do this by arranging to have a special user account (so 
> as
> not to lock out the real user) for testing bogus second factors, and
> using a random or constant 2nd factor for this.

I think this is overkill. Most continuations will have already
validated some aspect of the second factor. For instance, in HOTP/TOTP
continuations are used for synchronization of the token after the
validation of the initial token code.

Nathaniel