Subject: Re: [Ietf-krb-wg] FAST: Security of replacing reply key

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Apr 2009 22:53:42 -0400

>>>>> "ghudson" == ghudson  <[email-masked]> writes:

    ghudson> client's host, which would grant access to the decrypted
    ghudson> credentials anyway, but at a minimum this relationship
    ghudson> should be made clear in the security considerations.

    ghudson> If an anonymous pkinit ticket is used to armor the
    ghudson> exchange, then I think a man in the middle might be able
    ghudson> to read the user's credentials in the AS reply without
    ghudson> knowledge of the client's long term key.  I haven't
    ghudson> thought this case through in detail, and
    ghudson> https://lists.anl.gov/pipermail/ietf-krb-wg/2009-January/007271.html
    ghudson> suggests that it might not be possible for a man in the
    ghudson> middle to make encrypted challenge succeed while still
    ghudson> being able to read the armored parts of the exchange
    ghudson> (except through a dictionary attack on the client
    ghudson> long-term key).

    ghudson> Conceivably FAST could be changed so that KrbFastResponse
    ghudson> includes a strengthening key, rather than a replacement
    ghudson> key.  In this case, a third party with knowledge of the
    ghudson> armor ticket long-term key would still be in a position
    ghudson> to perform a dictionary attack against the user's
    ghudson> password using the AS response--but such a third party
    ghudson> can already do so using the messages encrypted in the
    ghudson> challenge key.

Larry and I would like to make this change.
Specifically, I propose the reply key should be krb-fx-cf2(strengthenkey, "strengthenkey" old_reply_key, "replykey")
where strengthenkey is a new random key sent in the rep-key field of the fast response
and where old_reply_key is the reply key at the end of padata processing.

I realize this is a late change, but I think Greg makes an important
point.  We really need implementers to scream now if they do not like
this change.  It's getting very difficult to make changes of this type
because we will need to repeat testing, but in this instance, it seems
worthwhile.

I mentioned this to Greg, but I do believe that there is not a MITM
attack against anonymous pkinit with encrypted challenge even if this
change is not made.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 2 Apr 2009 12:26:35 +0530

Sam,

       KRB-FX-CF2(protocol key, protocol key, octet string,
                 octet string)  ->  (protocol key)

       PRF+(K1, pepper1) -> octet-string-1
       PRF+(K2, pepper2) -> octet-string-2
       KRB-FX-CF2(K1, K2, pepper1, pepper2) ->
              random-to-key(octet-string-1 ^ octet-string-2)

The PRF+ function would generate the bytes equivalent to the key length.

Is it safe to assume that K1 and K2 are always of same etype so that the
octet-strings generated are of same length? 

If K1 and K2 are not of same length then the octet-string1 and octet-string2
are of different length. Do we need to XOR these octet-strings only to the
minimum length (either K1 or K2 length) and not XOR the remaining length and
use it with random-to-key()?
OR do we need to pad with zero so that both octet-strings are of same length
and then XOR on them?

Thanks,
Srini

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 02 Apr 2009 07:43:33 -0400

> The PRF+ function would generate the bytes equivalent to the key length.

The PRF+ function, described in detail immediately after the text you 
quote, generates enough bits for the random-to-key operation of the output 
enctype.  Since the length is determined by the output enctype, it is 
always the same for both octet-string-1 and octet-string-2, and there is no 
length mismatch.  This is important because the random-to-key operation 
requires input of a specific size.

> octet-strings generated are of same length?

No.  In fact, the sentence immediately _above_ the text you quote makes it 
clear that K1 and K2 may have different enctypes.  Furthermore, the 
construction works even if K1, K2, and K3 are all different enctypes.

-- Jeff

---

From: <[email-masked]>
Date: Mon, 6 Apr 2009 05:10:33 -0400

Sam,

I am trying to understand the impact of the proposed change.

The OTP pre-auth ID currently replaces the reply key. 

new_reply_key =  KRB-FX-CF2(armor_key, otp_derived_key, O3, O4) 

If I understand your proposal, then this would need to be changed to
generated new_reply_key from the old reply_key instead of the
armore_key.  But since the OTP pre-auth mechanism doesn't prompt the
user for their Kerberos password then how would it know this key?

--Gareth

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: 02 April 2009 03:54
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ietf-krb-wg] FAST: Security of replacing reply key
> 
>     ghudson> 
> https://lists.anl.gov/pipermail/ietf-krb-wg/2009-January/007271.html
> Specifically, I propose the reply key should be 
> krb-fx-cf2(strengthenkey, "strengthenkey" old_reply_key, 
> "replykey") where strengthenkey is a new random key sent in 
> the rep-key field of the fast response and where 
> old_reply_key is the reply key at the end of padata processing.
> 
> I realize this is a late change, but I think Greg makes an 
> important point.  We really need implementers to scream now 
> if they do not like this change.  It's getting very difficult 
> to make changes of this type because we will need to repeat 
> testing, but in this instance, it seems worthwhile.
> 
> 
> I mentioned this to Greg, but I do believe that there is not 
> a MITM attack against anonymous pkinit with encrypted 
> challenge even if this change is not made.

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 8 Apr 2009 12:17:30 +0530

Sam> Larry and I would like to make this change.
Sam> Specifically, I propose the reply key should be krb-fx-
Sam> cf2(strengthenkey, "strengthenkey" old_reply_key, "replykey")
Sam> where strengthenkey is a new random key sent in the rep-key field of
Sam> the fast response
Sam> and where old_reply_key is the reply key at the end of padata
Sam> processing.

Since, the rep-key field of fast response contains only the strengthenkey,
the client should derive the reply key to be used using the strengthenkey
got in fast response and the key derived from the user's password and then
he can decrypt the AS-REP using the derived key. Is this correct?

But, this would also mean opening up to dictionary attack?

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Apr 2009 03:25:25 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> Since, the rep-key field of fast response contains only
    Srinivas> the strengthenkey, the client should derive the reply
    Srinivas> key to be used using the strengthenkey got in fast
    Srinivas> response and the
correct so far

    Srinivas>  key derived from the user's password

Only if some pre-authentication mechanism or fast factor doesn't
replace or otherwise alter the reply key.

What you describe is absolutely right for encrypted challenge.
However if you used pkinit with FAST, pkinit would replace the reply
key, which depending on the KDC implementation might be strengthened.

The dictionary attack vulnerability does not change at least with
encrypted challenge.  An attacker could attack the combination of
strengthen_key+long_term_key or could attack the combination of
armor_key+long_term_key (the challenge key).  However both the
strengthen_key and armor_key are believed to be strong.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 8 Apr 2009 14:17:52 +0530

Gareth> 
Gareth> Sam,
Gareth> 
Gareth> I am trying to understand the impact of the proposed change.
Gareth> 
Gareth> The OTP pre-auth ID currently replaces the reply key.
Gareth> 
Gareth> new_reply_key =  KRB-FX-CF2(armor_key, otp_derived_key, O3, O4)
Gareth> 
Gareth> If I understand your proposal, then this would need to be changed
Gareth> to
Gareth> generated new_reply_key from the old reply_key instead of the
Gareth> armore_key.  But since the OTP pre-auth mechanism doesn't prompt
Gareth> the
Gareth> user for their Kerberos password then how would it know this key?
Gareth> 

>From Sam response to my question in another email, as the OTP pre-auth
generates the reply key using the method as above there is no need to
consider the strengthen key for OTP pre-auth.

Thanks,
Srini

---

From: Greg Hudson <[email-masked]>
Date: Wed, 08 Apr 2009 10:36:31 -0400

> user for their Kerberos password then how would it know this key?

Sam and I were only discussing FAST's mechanism-independent facility for
changing the reply key if no FAST factor changes it in some other way.
It should be fine for the OTP factor to continue replacing the reply key
in the manner it currently does.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Apr 2009 16:42:03 -0400

>>>>>   <[email-masked]> writes:

    > Sam, I am trying to understand the impact of the proposed
    > change.

    > If I understand your proposal, then this would need to be
    > changed to generated new_reply_key from the old reply_key
    > instead of the armore_key.  But since the OTP pre-auth mechanism
    > doesn't prompt the user for their Kerberos password then how
    > would it know this key?

No, I'm only talking about what is now called the rep-key field in the KrbFastResponse sequence.

That field would presumably be renamed strengthen-key.

So, here's how I'd expect that to interact with the OTP.
You would set the reply key to krb-fx-cf2(armor_key,otp_key, o3, o4)

Provided that the KDC does not set the strengthen-key, then that would remain the reply key.
A KDC MAY, although doesn't have a strong reason to, set the strengthen-key.
in which case the reply key would end up something like
krb-fx-cf2(strengthen_key, otp_reply_key,)
Where otp_reply_key is as above.
I have omitted the cf2 constants.
So, in the OTP case you could replace and then later strengthen the reply key.

There is not a security reason to do in the OTP case, although clients
need to be prepared for this.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Mon, 13 Apr 2009 10:46:31 +0530

>>>>>   Sam Hartman writes:

> need to be prepared for this.

I can understand the reason behind strengthenkey in case of FAST
encrypted-challenge.

Some cases may not always use strengthenkey and reply-key might be
sufficient e.g. OTP, pkinit. So, do you think it is better to have reply-key
and strengthenkey in KrbFastResponse (instead of just replacing reply-key
with strengthenkey field), so that it is flexible to use either
strengthenkey or reply-key?
Using both would avoid any confusion as to treat the key as reply-key or
strengthenkey. Also, there maynot be any point in deriving another key (case
of strengthenkey) if there is no need to do so.

Thanks,
Srini

---

From: Greg Hudson <[email-masked]>
Date: Mon, 13 Apr 2009 11:24:04 -0400

> sufficient e.g. OTP, pkinit.

Are you talking about a generic facility for replacing the reply key, or
a specific way of doing that (like the one in draft 10) where the KDC
simply tells the client the new reply key in the KrbFastResponse,
protected only by the armor key?

With the change Sam is proposing, it should still be fine for a
mechanism to implement the replace-reply-key facility using its own
padata and rules.  My understanding of the OTP draft is that it replaces
the reply key without using the KrbFastResponse field.

---

From: <[email-masked]>
Date: Tue, 14 Apr 2009 05:32:30 -0400

> krb-fx-cf2(strengthen_key, otp_reply_key,) Where 
> otp_reply_key is as above.
> There is not a security reason to do in the OTP case, 
> although clients need to be prepared for this.
> 
Thanks Sam, Srini and Greg for the replies, I think I've got it now. 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 14 Apr 2009 19:02:45 +0530

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 30 March 2009 22:30
To: [email-masked]
Subject: [Ietf-krb-wg] FAST: Security of replacing reply key

If a ticket-based armor is used to protect the exchange--say, using
the host key of the client machine--then anyone with knowledge of the
long-term key of the armor ticket can observe and decrypt the
exchange, read the reply key in the KrbFastResponse message, and
decrypt the returned credentials without knowledge of the user's
long-term key.  In many cases knowing the armor ticket long-term key
is synonymous with being root on the client's host, which would grant
access to the decrypted credentials anyway, but at a minimum this
relationship should be made clear in the security considerations.

[Srinivas Cheruku] Sam proposed to use strengthenkey so that the returned
ticket is secured and anyone with knowledge of just the long term key of the
armor ticket cannot be able to decrypt the AS-REP. But does this mean that
the KrbFastArmoredReq and KrbFastArmoredRep are not secure enough as a
person with knowledge of long term key of armor ticket can read them? Is
this ok?

Thanks,
Srini