Re: [kitten] SPAKE Preauth

[Ken Hornstein <[e-mail]>]

>> 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.

--Ken