Subject: [Ietf-krb-wg] FAST, Channel Binding and Replace Reply Key

From: Sam Hartman <[email-masked]>
Date: Thu, 31 Jul 2008 13:45:27 -0400

Larry and I met to discuss  FAST and security requirements.

Ultimately the attack I was describing Monday boils down to the
following.  Currently, the spec does not require that when you send a
reply key to someone, you make sure you are sending it to the party
that authenticated as the client.

In the attack I described, Eve intercepts and MITMs the connection
between Alice the client and Bob, the KDC.

Alice encrypts a proof that she is who she claims to be.  Bob receives
this proof and then sends the response to whomever he is connected to
without actually making sure those are the same parties.

So, there is a fundamental requirement for reply key replacement: you
need to make sure that you disclose the reply key to the party who has
proven they are the client.

One way to do this is to do what RFC 4556 does and combine reply key
with client authentication.

If you don't do that then you need to cryptographically bind them
together somehow.  Effectively that means you need some cryptographic
channel over which the reply key will go and you need to use channel
binding in order to bind the client authentication to that channel.

In the specific case of FAST, it means that we need to make sure that
we have some channel binding data that we can use for the channel.

The session key in a Kerberos ticket is intended to be known only by
the KDC, client and service.  It actually serves as a reasonable
confidential name for a channel; its hash would be a fine public name.
We want to do something a bit more complicated, because we also want
to make sure that if you have two authentications using the same
ticket that they get different channel names. So, the client needs to
contribute something to make the channel name fresh.  We plan to use
the armor key to separate channels. However, today the armor key is
chosen by the client in the subsession authenticator.  RFC 5056
requires that channel bindings be constructed in such a manner that a
MITM cannot force one channel to have the same channel bindings as
another.  A client-chosen key fails to meet this requirement.  So, we
propose that the armor key be the result of combining the session key
from the ticket with the subsession key defined by the client.

We also discovered a defect in anonymous PKINIT as defined in the
anonymous draft.  The client has no confidence that the session key
will be known only by the KDC and service in the anonymous PKINIT
case.  The problem is that if there is a MITM, the MITM can choose a
session key such that the session key between the MITM and the real
KDC is the same as the session key between the client and the MITM.
FAST is depending on that property for its security so it needs to be
preserved.

Once you have established this channel, you then need to perform
channel binding when client authentication is performed.  If channel
binding is not performed when client authentication happens, then
replacing the reply key is very dangerous.

One question that immediately comes to mind is to what extent does
starttls have the same issues. 

Yes.  If you want to separate replace reply key from client
authentication in a pre-authentication mechanism running under
starttls then you will need to engage channel binding.

One consequence of this is that pre-authentication mechanisms will
tend to depend more than you'd like on what channel technology is
being used.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 31 Jul 2008 11:25:32 -0700

> tend to depend more than you'd like on what channel technology is

Yuck.

Glad to see people worrying about it though.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg