Subject: Re: [Ietf-krb-wg] start-tls status

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Dec 2008 11:58:31 -0500

--On Wednesday, November 19, 2008 02:03:47 AM +0100 Simon Josefsson 
<[email-masked]> wrote:

> Nicolas Williams <[email-masked]> writes:
>
>> On Tue, Nov 18, 2008 at 04:18:52PM -0600, Jeffrey Hutzelman wrote:
>>> While STARTTLS does need to be analyzed to determine whether the same
>>> problems described in Sam's message apply when it is used, that is not
>>> the  primary reason the document has not been published.  The document
>>> has not  been published because we've been unable to come to consensus
>>> on an  intended status.  Any other issues that have come up have
>>> generally been  resolved in a timely fashion, leaving the
>>> intended-status question as the  only blocking issue on multiple
>>> occasions.
>>
>> I've not looked at STARTTLS in a while, but I'd like to see:
>>
>> 1) channel binding from pre-auth to the TLS channel;
>
> What's missing from section 3 below?
>
> http://tools.ietf.org/html/draft-josefsson-kerberos5-starttls-03#section-3

Nico, can you answer this?
Do you believe that section 3 is complete and sufficient?

>> 2) reply keys derived from the TLS channel.
>
> I believe that is beyond the scope of krb5starttls.  However, there are
> several other document in this area, what's missing from
> draft-ietf-tls-extractor, currently in WGLC?

I think you're misinterpreting Nico's request.  He's talking specifically 
about deriving the Kerberos reply key (that is, the one used to encrypt the 
EncASRepPart).

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Dec 2008 20:07:25 +0100

> about deriving the Kerberos reply key (that is, the one used to encrypt the 

I don't follow how that would work, i.e., how to translate the request
into text in the specification.  Suggestions?

Consider if you are using leap-of-faith TLS.  Consider if you are using
TLS with no encryption.  Deriving the EncASRepPart key from the TLS
session in these situations seems like a bad idea to me.  The same
concern applies to several ways TLS can be used.

Krb5starttls offer the ability for everyone to define a PA-DATA
extension that signals that the other end should use a krb5starttls
channel to derive reply keys.  Such a specification could specify in
which situations it is useful.  That specification would be a better
place to discuss the reasons behind deriving the EncASRepPart key from
the TLS channel too.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Dec 2008 13:11:55 -0600

> Nico, can you answer this?

Sorry I'd missed that reply.

> Do you believe that section 3 is complete and sufficient?

It's not complete, and possibly unnecessary.  The issue is: we need a
way to do channel-bound PA-ENC-TIMESTAMP.  (Perhaps "need" is too
strong?)

So perhaps what Simon should do is specify that PA-ENC-TIMESTAMP works
differently over STARTTLS, or specify a variant of PA-ENC-TIMESTAMP that
does.

> about deriving the Kerberos reply key (that is, the one used to encrypt the 

Yes.  But perhaps that's completely unnecessary in the STARTTLS case and
I had just not realized it yet.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 04 Dec 2008 20:47:50 +0100

> differently over STARTTLS, or specify a variant of PA-ENC-TIMESTAMP that

Why does this needs to be in the krb5starttls document?

It seems like it belongs in a separate document, if you see a use-case
for it.  There are certainly reasonable ways to use krb5starttls without
pre-authentication.

> I had just not realized it yet.

Please propose text.  I don't see an easy way to satisfy this request
without introducing serious security problems or at least a complex
security considerations.

/Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Dec 2008 22:27:28 -0500

--On Thursday, December 04, 2008 08:07:25 PM +0100 Simon Josefsson 
<[email-masked]> wrote:

>> I think you're misinterpreting Nico's request.  He's talking
>> specifically  about deriving the Kerberos reply key (that is, the one
>> used to encrypt the  EncASRepPart).
>
> session in these situations seems like a bad idea to me.

[speaking without a hat, mostly(*)]
I think we came to the conlusion when talking about preauth in Dublin that 
_replacing_ the reply key is often a bad idea, so much so that the preauth 
framework should no longer define such an operation.  However, an operation 
that "strengthens" the reply key by somehow combining the existing key with 
some new source of keying material is often useful, and should never be 
harmful as long as the combining operation is appropriately defined.  This 
is covered in some detail in section 4.2 of the preauth document.

In the case of leap-of-faith TLS, one of the things you gain by partially 
deriving the reply key from the TLS session is that it cryptographically 
binds the TLS session to the KDC reply it carries, such that if there is a 
MITM, the real client and KDC will derive different reply keys and thus the 
operation will not work (preauth that depends on the reply key will fail, 
and unless the reply key is later replaced, a client will be unable to 
decrypt an eventual KDC-REP).

Note that in this scenario, if the reply key is strengthened by TLS rather 
than replaced, then an attacker will not be able to derive _either_ key. 
Merely replacing the reply key with one derived from TLS would in fact 
break the protocol, by allowing a MITM attacker (or anyone else) to 
impersonate a KDC or client.

> place to discuss the reasons behind deriving the EncASRepPart key from

One could certainly imagine a preauth mechanism intended to be run over TLS 
which provides the "strengthen reply key" facility as defined in the 
preauth framework document.  One could also imagine defining STARTTLS 
itself to imply use of such a mechanism, without requiring use of any 
particular padata item.  I think what Nico was originally asking for was 
something like the latter, though from his more recent messages it appears 
his thinking may have changed....

-- Jeff

(*) Particularly, my intent here is to explain and clarify.  I'm not 
advocating any particular course of action, nor suggesting that any 
particular resolution would be required for the document to advance.  The 
question does need to be resolved, but that resolution could take the form 
either of making some change, or of deciding not to make any change.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 04 Dec 2008 23:23:15 -0500

--On Thursday, December 04, 2008 01:11:55 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

> It's not complete, and possibly unnecessary.

In fact, having looked at that section myself, I believe it is rather 
underspecified.  It defines a padata type for carrying a channel binding, 
but says nothing explicit about what channel should be described, or what 
semantics should be applied.  It requires that every  TGS-REQ include 
pa-channel-binding data, but does not specify what the KDC should do with 
that data or how it should behave if the channel bindings do not match.  It 
provides no way for a client to discover whether channel bindings were 
correct.

It is possible to make seemingly reasonable guesses about much of that, 
however, doing so would likely lead one to believe that some security is 
gained by requiring clients to send pa-channel-binding with bindings to the 
TLS session and requiring KDC's to verify these bindings and return an 
error if they do not match.  That belief would be incorrect -- since 
PA-DATA is not authenticated or bound to the rest of the KDC exchange in 
any way, the channel binding data is essentially sent unprotected inside 
the very channel it describes, and there is nothing to prevent an MITM 
attacker from replacing this padata in transit with a value reflecting the 
channel he shares with the KDC.

To be effective, channel bindings must be authenticated in some fashion. 
For example, the preauth data might be signed or MAC'd in some fashion.

Alternately, one might strengthen the reply key with key material derived 
from the TLS session, as described in my last message.  However, I would 
suggest examining this approach very carefully before deciding to use it, 
as my recollection is that the TLS master secret does _not_ constitute a 
unique channel binding and so using material derived from it to strengthen 
the reply key might not provide the desired protection.  It would be 
helpful if someone who's thought about this more carefully would speak up.

-- Jeff