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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Jan 2009 15:41:30 -0500

--On Thursday, December 04, 2008 11:23:15 PM -0500 Jeffrey Hutzelman 
<[email-masked]> wrote:

> --On Thursday, December 04, 2008 01:11:55 PM -0600 Nicolas Williams
> <[email-masked]> wrote:
>
>> On Thu, Dec 04, 2008 at 11:58:31AM -0500, Jeffrey Hutzelman wrote:
>>> --On Wednesday, November 19, 2008 02:03:47 AM +0100 Simon Josefsson
>>> <[email-masked]> wrote:
>>> > Nicolas Williams <[email-masked]> writes:
>>> >> 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#secti
>>> > on-3
>>>
>>> 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.
>
> 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.

I've seen no movement in the last month on this, which I believe to be the 
last outstanding issue before STARTTLS can move forward.  Can I have some 
comments/discussion on this, please?

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