[kitten] SPAKE channel ID for second-factor

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] SPAKE channel ID for second-factor

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Dec 03, 2018 at 01:40:35PM -0500, Greg Hudson wrote:

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

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.

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

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.

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

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.

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Dec 03, 2018 at 01:52:54PM -0600, Nico Williams wrote:
> 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.

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

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
In reply to this post by Nico Williams
On Mon, 2018-12-03 at 13:52 -0600, Nico Williams wrote:
>
> 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.

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.

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

Simo.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
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:
> > 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.
>
> 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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote:

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

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

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

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

Simo.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Mon, Dec 03, 2018 at 04:01:41PM -0500, Simo Sorce wrote:

> On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote:
> > 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:
> > > > 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.
> > >
> > > 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!
>
> It may be neat as an optional feature, but I do not think we should add
> 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.

> > > 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.
>
> No, the channelID Greg proposed shouldn't change how the OTP part is
> dealt with if I understood it correctly.

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

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
In reply to this post by Simo Sorce-3
On Mon, 2018-12-03 at 16:01 -0500, Simo Sorce wrote:

> On Mon, 2018-12-03 at 14:27 -0600, Nico Williams wrote:
> > 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:
> > > > 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.
> > >
> > > 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!
>
> It may be neat as an optional feature, but I do not think we should add
> additional PK load on this mechanism.
>
> > > 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.
>
> No, the channelID Greg proposed shouldn't change how the OTP part is
> 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.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
In reply to this post by Greg Hudson
On 12/3/2018 1:40 PM, Greg Hudson wrote:

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



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
On Tue, 2018-12-04 at 13:14 -0500, Jeffrey Altman wrote:

> On 12/3/2018 1:40 PM, Greg Hudson wrote:
> > 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.
>
> 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?

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.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
In reply to this post by Jeffrey Altman-2
On 12/04/2018 01:14 PM, Jeffrey Altman wrote:
> 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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Jeffrey Altman-2
On Tue, Dec 04, 2018 at 01:14:38PM -0500, Jeffrey Altman wrote:
> 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.

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.

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
In reply to this post by Simo Sorce-3
On 12/4/2018 1:31 PM, Simo Sorce wrote:
> 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.

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





_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
On Tue, 2018-12-04 at 16:27 -0500, Jeffrey Altman wrote:

> On 12/4/2018 1:31 PM, Simo Sorce wrote:
> > 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.
>
> 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.

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

>   However,
> issuing tickets with varying authorization data is dangerous because of
> credential caching and the impact on cross-realm ticket issuance.

This is a valid concern.

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

I can see your point, thank you.

Simo.

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


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten