Subject: Re: [kitten] SPAKE Preauth

From: Nico Williams <[email-masked]>
Date: Fri, 1 May 2015 16:15:04 -0500

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.

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 01 May 2015 17:18:58 -0400

> 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

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 May 2015 16:20:04 -0500

There should be a generic OTP 2nd factor type for user-input OTPs.

There should also be a generic OTP 2nd factor for plug-in/NFC-type OTPs.

For a generic OTP 2nd factor for user-input OTPs the 'data' in the
AS->client second pass should be a UTF8String, or just UTF-8.

It's important to define such generic OTP 2nd factors because they are
quite popular.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 May 2015 16:23:21 -0500

On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote:
> > 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.
> 

It doesn't seem like overkill to me.  Unless the property that an
attacker can't distinguish which factor was wrong is not that important.

Note that AS implementations could just always send continuations as
EncryptedData, leaking that way.  What I want is for it to be possible
to implement an AS that doesn't leak.

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 01 May 2015 17:24:04 -0400

> It's important to define such generic OTP 2nd factors because they 

I plan to create separate standards for OATH and U2F.

Nathaniel

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 01 May 2015 17:27:03 -0400

> to implement an AS that doesn't leak.

I don't think that is possible. The cost for sending data in the clear
to avoid leaking EncryptedData is the loss of integrity protection.

Nathaniel

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 May 2015 16:30:56 -0500

On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote:
> > EncryptedData, leaking that way.  What I want is for it to be
> > possible to implement an AS that doesn't leak.
> 

Any OTPs that require continuation then result in this leak.  This has
to be documented, since avoiding this leak is a core feature of this
protocol.

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 01 May 2015 17:32:34 -0400

> to be documented, since avoiding this leak is a core feature of this

Correct. Is the current warning insufficient? It is my understanding
this is spelled out in the security considerations section.

Nathaniel

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 May 2015 17:22:58 -0500

> I plan to create separate standards for OATH and U2F.

Is there any reason that a generic one couldn't be specified here?

Nico
--

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 01 May 2015 22:24:58 -0400

On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote:
> > > There should also be a generic OTP 2nd factor for plug-in/NFC
> > > -type 
> > > OTPs.
> > > 
> > > It's important to define such generic OTP 2nd factors because 
> > > they 
> > > are
> > > quite popular.
> > 

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.

Nathaniel

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 01 May 2015 22:58:04 -0400

>somewhat hard for me to quantify, but it arises from my experience

So ... I hate to ask this, but does this mean KITTEN is coming around
to officially deciding that OTP in Kerberos should _not_ use FAST?  I
will fully admit that I've been out of the Kerberos game for a while,
but seeing Nathan's description of the challenges with deploying FAST
makes me realize that I'd run into the exact same problems ... and that
makes me think that a FAST-based OTP would probably be very challenging
if you had a diverse Kerberos deployment.  And I simply wouldn't bother
deploying both FAST and SPAKE; I'd just pick one to make things easier.

--Ken

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 2 May 2015 14:15:28 -0400 (EDT)

> this is spelled out in the security considerations section.

I think I already mentioned this in my earlier comments, but I think that
mentioning more prominently in the introduction the goal of not leaking
which factor was incorrect, with the caveat about continuation messages
losing this property, would be an improvement to just mentioning it in the
security considerations.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 2 May 2015 17:59:08 -0400 (EDT)

> deploying both FAST and SPAKE; I'd just pick one to make things easier.

Essentially, the answer is different whether OTP is supposed to be the
first (and only) authentication factor, or a second factor to be used in
conjunction with a password.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 May 2015 18:08:57 -0500

> somewhat hard for me to quantify, but it arises from my experience

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

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 May 2015 18:16:04 -0500

In addition to adding some standard OTP-ish second factors, I'd like to
have a way to "augment" the PAKE with the same user password so as to
improve resistance to KDC database compromise.

For example, if we had a password->signature key algorithm then we could
have a second factor that consists of a signature of the AS' and user's
PAKE public keys (say; handwaving a bit)m and then the AS ends up
storing w (from the PAKE) and the public key for the signature.

If we salt the password differently to derive w and the siging key, then
the AS ends up storing not a password equivalent, but a password
verifier.  That makes KDB compromise somewhat less bad than today, since
attackers would have to mount off-line dictionary attacks, giving realm
operators more time to have users change their passwords.  (Service keys
remain a problem, but that can be addressed too, separately.)

But augmenting the PAKE this way means we may need to use two second
factors: one to augment the PAKE, and one that's the actual OTP-ish
second factor.  That will require some tweaking of the proposed
protocol.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 2 May 2015 18:24:36 -0500

> losing this property, would be an improvement to just mentioning it in the

Agreed, but I also wonder if there might be second factor types where
the AS->client continuations could be sent with no protection and still
be secure.  Consider an OTP resync use case where the client gets asked
to send N more OTPs.  The AS stores N (then N-1, N-2, .., N==1) in the
state cookie, while the client binds all the resync requests (and
response OTPs) into the transcript, so the AS can't be tricked into
taking more OTPs than it needs, and the resync doesn't hurst the client,
leaking nothing to the attacker.  Granted, this analysis has to be done
on a per-second factor type basis.

Perhaps we don't or shouldn't care.  But if this failure cause
indistinguishability feature is critical, then maybe we should care.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Sun, 03 May 2015 18:32:44 -0400

> that might be).  I don't see how the user-input OTP experience can get

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.

> keyboard?  an audio description of the same?), but text is quite

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

Simo.

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

---

From: Nico Williams <[email-masked]>
Date: Sun, 3 May 2015 20:04:28 -0500

> and just reference them by id internally.

Ah, I see.  OK, thanks.

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 04 May 2015 10:40:59 -0400

>conjunction with a password.

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?"

--Ken

---

From: Nathaniel McCallum <[email-masked]>
Date: Mon, 04 May 2015 11:25:50 -0400

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

Pre-commiditized 2FA is the context of RFC 6560. There is no attempt
here to use the existing 1FA infrastructure of Kerberos. RFC 6560 is
just a fancy method for passing credentials in cleartext through
Kerberos protected by FAST. The KDC then passes these credentials
directly to the parallel authentication stack. It is the HTTPS Basic
Auth of the Kerberos world.

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.

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.

Nathaniel

---

From: Greg Hudson <[email-masked]>
Date: Mon, 04 May 2015 11:31:19 -0400

> protocol is it actually possible for me to deploy successfully?"

Deployability is a big motivator for SPAKE preauth.

I wasn't involved in the early stages of FAST OTP, but I believe it was
primarily trying to solve the problem of bridging between an OTP master
authentication server and the Kerberos protocol.  In a deployment where
the KDC has no user-specific shared secrets with the client, there needs
to be some way of establishing a confidential, server-authenticated
channel from the client to the KDC, so that the client can send the
PIN+OTP value to the KDC for verification against the OTP back end.
FAST allows that channel to be created using either a host keytab or an
X.509 KDC certificate (using anonymous PKINIT).

The big challenges of deploying FAST OTP as I see it are threefold:

* It is designed to replace rather than augment Kerberos long-term keys.

* At least in MIT krb5, we haven't added enough FAST support to the
upper layers of the get-init-creds stack to make it easy to deploy.

* Unless you can assume host keytabs on all of the clients, there's no
good way around the requirement to put an X.509 certificate on the KDC
and configuring all of the clients to trust its CA.

SPAKE preauth doesn't have these problems, but it does require you to
start with traditional Kerberos back-end database containing
string2key'd user passwords.  If you don't have that, and instead have
an OTP server with PINs, then FAST OTP may still be a better answer.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 04 May 2015 11:54:32 -0400

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

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

>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

---

From: Nathaniel McCallum <[email-masked]>
Date: Mon, 04 May 2015 20:16:52 -0400

> personally I'd vote to keeping SPAKESecondFactor an Int32 rather than

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

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 05 May 2015 00:17:34 -0400

>Then we would create some IETF OIDs for open protocols (such as OATH

I'm wondering how that is better than the "normal" Kerberos scheme where
vendors can register their 2FA or whatever with IANA.

And on further thought ... I realize that I'm strongly with Nico in that
a generic OTP should be specified somewhere.  I know you mentioned U2F,
but that just seems like an additional unnecessary layer (also, the U2F
protocol seems to be web-specific, in that it mentions adding the origin
URL and TLS channel ID to the authentication flow).  Sure, if people
want to use U2F no objections here, but it just seems lousy that the
initial specification(s) don't mention a generic OTP protocol; like Nico
said, there are a ton of these devices.

--Ken

---

From: Simo Sorce <[email-masked]>
Date: Tue, 5 May 2015 13:55:38 -0400 (EDT)

----- Original Message -----
> From: "Ken Hornstein" <[email-masked]>
> To: [email-masked]
> Sent: Tuesday, May 5, 2015 12:17:34 AM
> Subject: Re: [kitten] SPAKE Preauth
> 

If by "genric" protocol you mena TOTP or HOTP tokens we'll definitely provide that.
I think Nico meant "generic" as in really "free form as long as it is a text string" type of generic which I would object too(it would require sending prompts from the KDC. See previous message about why that is not ok.

Simo.

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 May 2015 13:02:16 -0500

I meant generic as in: works with all the commonly deployed OTPs such as
HOTP, including all schemes where the user merely types in a sequence of
digits appearing in a display on a token.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 May 2015 11:30:51 -0500

> improve resistance to KDC database compromise.

As discussed off-list, Nathaniel proposes that an augmentation factor
can wrap other factors, and so can be left to later.  I'm satisfied with
that answer.

Nico
--