Re: [kitten] SPAKE Preauth

[Nathaniel McCallum <[e-mail]>]

On Mon, 2015-05-04 at 11:54 -0400, Ken Hornstein wrote:
> > > See, I think you've got the question all wrong.  My question is 
> > > NOT,
> > > "Is OTP supposed to be the only authentication factor?", it's, 
> > > "Which
> > > protocol is it actually possible for me to deploy successfully?"
> > 
> > I believe the tension you are seeing here is the result of
> > commoditization of 2FA. Early on, 2FA systems were entirely 
> > parallel
> > authentication stacks which authenticators would need to integrate
> > with. As 2FA commoditized, we see open protocols which can be
> > integrated into existing authentication stacks.
> 
> Well ... I understand why you'd say that, but I disagree.
> 
> We use the old, old SAM protocol with what you call a pre
> -commiditized
> 2FA system today.  So I was thinking of migrating that to FAST as 
> part
> of our long-overdue Kerberos upgrade.  But I hadn't really sat down 
> and
> understood FAST (I did try to start reading the RFC several times, 
> but
> man, it's pretty dense ... I mean, yeah, I understand it's a protocol
> document so that's just a necessity, but if you want a broad overview
> it's a tough read).  So now you spelled out, "Hey, you need ANOTHER 
> key
> to create the FAST channel" ... and that's really a non-starter for
> our environment, because those keys don't exist for our users that
> most need 2FA (and see previous discussion about the problems of 
> requiring
> anonymous pkinit).
> 
> > However, after 2FA commoditized the question becomes how can I 
> > augment
> > my existing authentication stack (1FA Kerberos) with a 2FA method.
> > This is what SPAKE Preauth provides.
> 
> Well ... again, I don't think that's really the "true" question that
> gets asked.  I mean, the people who are pushing the use of 2FA are
> generally not qualified to talk about Kerberos at a protocol level.
> Really, the question is, "Are you using 2FA with Kerberos?".  Well,
> actually, I doubt that the word "Kerberos" appears anywhere.  It's 
> more
> like there's a STIG or checklist somewhere that says, "2FA is 
> required",
> or maybe, "2FA is required when passwords are used".  As long as we
> can legitimately assert that 2FA is in use, that's really all we care
> about at a fundamental level; if it's "2FA + Kerberos password", 
> that is
> totally fine (that's what we have today).  Yes, I _personally_ care 
> that
> the crypto is the best that we can possibly do, but having something
> that is deployable is more important.
> 
> > Now, I think your questions here raise an interesting point: can 
> > and
> > should we require some standardization to use the 2FA feature of 
> > SPAKE
> > preauth? I think the answer is no. And I've come to think that the
> > SPAKESecondFactor type field should really be OBJECT IDENTIFIER.
> 
> I do not quite understand your point ... are you saying that your I-D
> should completely specify how all 2FA systems work with SPAKE?  And
> personally I'd vote to keeping SPAKESecondFactor an Int32 rather than
> an OID.

No. I'm saying a vendor can define their own 2FA and assign it an
enterprise OID number and use it out of the box. No standardization
required.

Then we would create some IETF OIDs for open protocols (such as OATH
and U2F).

Nathaniel