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

From: [email-masked]
Date: Fri, 1 Aug 2008 07:01:09 -0400

Sam,

I am trying to make sure that I undertand how the issues you describe
below impact OTP pre-auth.  From what you say, it seems as if there are
two problems:

1.  The replace-reply-key facility can only be used in conjunction with
the client-authentication facility

2. Anonymous PKINIT allows the MITM to choose the same Armor Key as the
client and KDC.

In the current OTP ID, the client generates an OTP value and uses it
along with the armor key to generate the reply key, the KDC generates
the same OTP value and armor key and uses them to generate the same
reply key.  There is client authentication and the reply key is not sent
to the client and so it does not seem as if the first issue is a
problem.  (I suppose it is more of a generate-reply-key than a
replace-reply-key.)

However, there are attacks if the armor key can be discovered by a MITM
since it would greatly weaken the reply key generation and in certain
modes, would allow the MITM to discover the OTP value.

--Gareth

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Aug 2008 09:35:01 -0400

>>>>> "gareth" == gareth richards <[email-masked]> writes:

    gareth> Sam, I am trying to make sure that I undertand how the
    gareth> issues you describe below impact OTP pre-auth.  From what
    gareth> you say, it seems as if there are two problems:

    gareth> 1.  The replace-reply-key facility can only be used in
    gareth> conjunction with the client-authentication facility

    gareth> 2. Anonymous PKINIT allows the MITM to choose the same
    gareth> Armor Key as the client and KDC.

    gareth> In the current OTP ID, the client generates an OTP value
    gareth> and uses it along with the armor key to generate the reply
    gareth> key, the KDC generates the same OTP value and armor key
    gareth> and uses them to generate the same reply key.  There is
    gareth> client authentication and the reply key is not sent to the
    gareth> client and so it does not seem as if the first issue is a
    gareth> problem.  (

That's my understanding.  Larry and I discussed OTP and our initial
conclusion was that if we fix the armor key generation, your draft is
fine.

    gareth> However, there are attacks if the armor key can be
    gareth> discovered by a MITM since it would greatly weaken the
    gareth> reply key generation and in certain modes, would allow the
    gareth> MITM to discover the OTP value.

Right.  I think one of the significant security consideration issues
with the OTP draft is to what extent using OTP in cases where you
cannot authenticate the KDC makes sense.  The anonymous PKINIT mode
where the KDC certificate is not validated inherently is vulnerable to
a MITM attack.  I am not sure I'd say never use OTP in such a
situation, but I'd certainly say that you should carefully think about the security implications.

---

From: [email-masked]
Date: Mon, 11 Aug 2008 04:42:33 -0400

> Right.  I think one of the significant security consideration 
> issues with the OTP draft is to what extent using OTP in 
> cases where you cannot authenticate the KDC makes sense.  The 
> anonymous PKINIT mode where the KDC certificate is not 
> validated inherently is vulnerable to a MITM attack.  I am 
> not sure I'd say never use OTP in such a situation, but I'd 
> certainly say that you should carefully think about the 
> security implications.
> 
I'll add something on this issue to the security considerations.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg