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

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Nov 2008 23:56:11 +0100

Thanks to Jeffrey for pointing to Sam's old e-mail below.  I'm trying to
understand how it relates to the krb5starttls document.

Sam's final conclusion is:

   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.

As far as I can tell, the problem appears to affect pre-authentication
mechanisms that run under krb5starttls.  The solution is for these
pre-authentication mechanisms to use a channel bindings.

Have I gotten that right?

I added in the -03 version (submitted Dec 2007) a PA-DATA
pa-channel-binding that can carry these channel bindings.  What remains
is for future pre-authentication mechanisms to specify the channel
binding data, based on Sam's ideas below.

I'm not sure I understand the pre-auth problem space, or rather, I'm
sure I do not understand the pre-auth problem space fully, so I'm not
the best person to explain this problem to others.  But if this is a
concern that pre-auth designers should know about, it sounds like
something could be added to the security considerations of krb5starttls.
I'd appreciate text for this, or I could use Sam's e-mail below as a
starting pointer.

Thoughts?

/Simon

Sam Hartman <[email-masked]> writes:

> 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
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg