Subject: [kitten] SPAKE channel ID for second-factor

From: Greg Hudson <[email-masked]>
Date: Mon, 03 Dec 2018 13:40:35 -0500

I have been thinking recently about some security properties of SPAKE
preauth with a second factor.  SPAKE preauth leverages the first factor
(the long-term key) to establish a channel, and then includes
second-factor communication in the key confirmation and perhaps in
subsequent messages.  This design is consistent with the ancient SAM-2
preauth mechanism (although much better because it uses a PAKE), but is
different from typical modern multi-factor authentication which tends to
rely on a TLS channel (authenticated by server cert) to protect all
authentication factors.

A consequence of the SPAKE preauth design is that if an attacker knows
the first factor (say, because of password reuse), the attacker can MITM
the SPAKE exchange and relay the second-factor communication across the
KDC-to-attacker and attacker-to-client channels, to obtain a KDC
response the attacker can decrypt.

For a simple OTP second factor, I don't know if there is much to be
done.  But for a challenge-response second factor like a Fido security
token, I think we might be able to improve on the security properties by
incorporating a SPAKE channel ID into the challenge, or simply
specifying that a SPAKE channel ID is the challenge rather than having
the KDC make one up and send it to the client.

The SPAKE draft currently says nothing about a channel ID for use by
second factors.  This could be addressed in the first second factor
specification which needs a channel ID, but I think it might be valuable
to specify a channel ID in the base SPAKE draft.  I'm thinking of something
similar to the derivation of K'[n] but using "SPAKEchannel" as the
prefix and stopping at the hash output step.

(Thought experiment, independent of Kerberos: imagine you perform an
unauthenticated DH exchange, then use a channel ID derived from the DH
shared key as the challenge for a challenge-response security token.  Is
that secure against active attacks?  I believe the answer is yes; if
not, there might be something wrong in my analysis above.)

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2018 13:52:54 -0600

> response the attacker can decrypt.

Yes.  We could fix this by adding a stable public key for authenticating
the KDC/realm, which would put this on par with the TLS case.  This is
already possible by using a FAST armor ticket obtained with [anonymous]
PKINIT, though it's more costly than something more closely integrated
into the protocol.

> the KDC make one up and send it to the client.

Even for OTP, if the OTP is "key-generating", meaning that the OTP can
be used as a symmetric key and the verifier can use it as a key to
verify a ciphertext / MAC payload send by the client, then it's OK.

However, the simplest fix is to add a server PK to the protocol.
Obviously it's a bit late for _this_ protocol, as it's been deployed,
and so can only admit backwards-compatible changes.

> prefix and stopping at the hash output step.

We'd have to fit negotiation of this into the second factor type ID.

Similarly, in order to use an augment PAKE (SPAKE2+), to use alternative
PAKEs (e.g., SPEKE), and/or to augment the protocol with a server public
key, we'd have to overload the group ID.

We can do this later, and I'd rather not hold up shepherding.  We can do
this during IETF LC, or later in a follow-on RFC.

> not, there might be something wrong in my analysis above.)

This is channel binding.  Channel binding enables discovery of an MITM
if they complete the handshake, but if they drop off (resetting any
connections) then you only get a timeout/reset as evidence of the MITM,
and the MITM gets to learn whatever metadata is available early enough
(e.g., client identity).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2018 13:55:04 -0600

> key, we'd have to overload the group ID.

Speaking of which, I am a bit disappointed that there's no SPAKE2+
support...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2018 14:27:38 -0600

On Mon, Dec 03, 2018 at 03:24:31PM -0500, Simo Sorce wrote:
> On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote:
> One of the goals of the SPAKE pre-auth mechanism is to be able to use
> it on "unconfigured" clients. The requirement to trust a specific KDC
> public key would defeat the purpose, and brings us back to the
> deployment issues we have with FAST.

It wouldn't be a requirement.  And TOFU is certainly possible.

The ability to learn realm public keys / issuers for PKINIT via SPAKE2
seems... really neat!

> A form of channel binding is more desirable in this context.

Yes, but that requires changing the OTP infrastructure, does it not?
That would slow adoption a great deal.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Mon, 03 Dec 2018 15:24:31 -0500

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

---

From: Simo Sorce <[email-masked]>
Date: Mon, 03 Dec 2018 16:01:41 -0500

> The ability to learn realm public keys / issuers for PKINIT via SPAKE2

It may be neat as an optional feature, but I do not think we should add
additional PK load on this mechanism.

> That would slow adoption a great deal.

No, the channelID Greg proposed shouldn't change how the OTP part is
dealt with if I understood it correctly.

Simo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Dec 2018 15:06:14 -0600

> additional PK load on this mechanism.

If you're not using it it won't cost anything.

Anyways, I'm not proposing any changes to this protocol at this time.

> dealt with if I understood it correctly.

Well, if you did then I didn't and it needs more explaining.

Nico
--

---

From: Simo Sorce <[email-masked]>
Date: Mon, 03 Dec 2018 16:19:18 -0500

> dealt with if I understood it correctly.

Uhmm I guess you meant wrt the use of the OTP to generate a key.
Yes that would not fly.

And just binding the channel based on a DH exchange without known
public key does not help in the case of a classic OTP. It helps only in
the case of a challenge-response token.

However I do not think we need to try to make SPAKE's Second Factor
extension dependent on non MITM-ability if the first factor is known.

In a Password + [T|H|..]OTP scheme, the second factor is used to
prevent use of the first factor without access to a [physical] token
generator, so that a leaked first factor still does require a full-
blown MITM to be useful.

SPAKE is a decent compromise here and addresses the point w/o requiring
pre-configuration of the device being used with secret shared keys or
even public keys. It perform its job of strengthening the safety of the
first factor.

For threat scenarios where MITM is a serious issue people should
probably just still use FAST.

Perhaps we could add an OTP mechanism that uses KDC PKs in the second
factor handling ? Maybe encrypting the second factor in a KDC Public
Key if "extra security" is desired and configuring the client with keys
and options to enforce this extra security is an acceptable deployment
constraint.

Simo.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 4 Dec 2018 13:14:38 -0500

> response the attacker can decrypt.

Hi Greg,

My concern about the SPAKE design is that it enables the factors to be
attacked independently.  It is possible for the attacker to know that
the long-term key is correct without being forced to use the second factor.

I would really like to see our efforts be invested in a multi-factor
Kerberos (not necessarily limited to two factors) where all of the
factors must be consumed before an successful or failure can be determined.

Does MIT have any interest in working on such a pre-auth mechanism?

Thanks.

Jeffrey Altman

---

From: Simo Sorce <[email-masked]>
Date: Tue, 04 Dec 2018 13:31:37 -0500

> Does MIT have any interest in working on such a pre-auth mechanism?

If the factors are known in advance you could combined multiple of them
and use them instead of the single long term key as the spake secret.

It just makes the multiple factors non optional, so it is a harder user
experience.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 4 Dec 2018 14:36:57 -0500

> the long-term key is correct without being forced to use the second factor.

The draft talks about this in the security considerations; see the 
discussion of "indistinguishability" in the subsection on side channels. 
  The SPAKE design can support indistinguishability if the second factor 
uses only a single round trip, and if the KDC implementation is careful 
to avoid timing channels.

(Unless the authors have missed something in our analysis, and there's 
an easy way for an attacker to know whether the guessed long-term key is 
correct even under the above constraints.  But in that case you'll have 
to point out what we've missed.)

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Dec 2018 13:55:50 -0600

> the long-term key is correct without being forced to use the second factor.

If the second factor requires just one round trip, then this SPAKE PA
does not leak which of the two (or both) failed.  Second factors that
require more than one round trip can only continue when the first factor
passes, so in that case there is a leak.

> factors must be consumed before an successful or failure can be determined.

For non-key generating second factors, the only way to do this is to
exchange all the factors independently under the protection of a FAST
armor ticket.

FAST kinda provides for a second factor, but not very well.  This could
be improved, I suppose.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 4 Dec 2018 16:27:30 -0500

> It just makes the multiple factors non optional, so it is a harder user

Hi Simo,

From a practical perspective, separate Kerberos principals must be
associated with different proofs of identity in order for applications
to be able to make authorization decisions UNLESS authorization data is
assigned to the ticket by the KDC based upon the proofs.  However,
issuing tickets with varying authorization data is dangerous because of
credential caching and the impact on cross-realm ticket issuance.

Separate credentials might be required for

   john.doe@REALM	long-term key only
   john.doe/duo@REALM	long-term key plus duo
   john.doe/piv@REALM   PIV card
   john.doe/cac@REALM   CAC card

etc. One user might have two or three of the above.

Therefore, I do not consider the optional factors case to be
particularly interesting.

Thanks.

Jeffrey Altman

---

From: Simo Sorce <[email-masked]>
Date: Tue, 04 Dec 2018 18:07:07 -0500

On Tue, 2018-12-04 at 16:27 -0500, Jeffrey Altman wrote:
> assigned to the ticket by the KDC based upon the proofs.

Indeed we have the Authentication Indicator data that expresses exactly
this idea.

>   However,

This is a valid concern.

> particularly interesting.

I can see your point, thank you.

Simo.