Re: [kitten] SPAKE Preauth

[Simo Sorce <[e-mail]>]

On Sat, 2015-05-02 at 18:08 -0500, Nico Williams wrote:
> On Fri, May 01, 2015 at 10:24:58PM -0400, Nathaniel McCallum wrote:
> > On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote:
> > > Is there any reason that a generic one couldn't be specified here?
> > 
> > Speaking for myself, I want to create a high-quality integrated
> > experience, not a generic one. I would prefer picking one open
> > standard (such as OATH) and getting the details right. This is
> > somewhat hard for me to quantify, but it arises from my experience
> > implementing RFC 6560.
> 
> I don't buy this.  I understand and agree about how a dependency on
> _FAST_ made RFC6560 difficult to deploy, and also how RFC6560's
> incomplete/missing handling of *multiple* factors made it less useful
> than expected.  I don't think that means "generality -> bad".
> 
> Also, I don't think a generic OTP 2nd factor here would necessarily lead
> to a low-quality user experience.  For all user-input OTPs, all the user
> needs is a prompt, which can be sent in UTF-8 and already localized to
> a language of the user's preference (since the AS ought to know what
> that might be).  I don't see how the user-input OTP experience can get
> much better than that.

I think we explicitly exclude sending unauthenticated prompts from the
KDC, as it would be easy to confuse/subvert the user experience by an
attacker.

Because the prompts would have to be sent unauthenticated in the SPAKE
algorithm we'd have to define either generic, unhelpful prompts, or
define specific OTP mechanisms so that clients have prompts backed in
and just reference them by id internally.

> I suppose one could add media (a vine showing the act of pulling the OTP
> out of one's pocket or purse, reading the OTP, then entering it on a
> keyboard?  an audio description of the same?), but text is quite
> accessible.

See above, a generic OTP would have to rely on no text coming from the
KDC.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York