Subject: Re: AD review for TCP extensions draft

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Mar 2007 09:07:16 -0400 (EDT)

On Wed, 21 Mar 2007, Simon Josefsson wrote:

> I agree with Sam's concern, IESG approval without approval guidelines
> is a bad idea.  We had the IANA discussion earlier, and I think the
> current text was a compromise.
>
> Given the discussions in the WG regarding whether krb5starttls should
> be adopted/published or not, I'd prefer to revisit this and make sure
> that I can use krb5starttls using this extension.  I don't care how it
> is done, but I do care strongly about being able to do krb5starttls
> even if nobody else wants to.  The only reason for me to do this
> document was to enable krb5starttls.

<hat type="chair" state="off">

I fully agree with this sentiment.  The namespace is quite small, so there
needs to be some review, but I certainly think it should be possible to
allocate a number to something that is not a standards-track document.

> >> In the security considerations section please also note that downgrade
> >> attacks can be solved by having extensions sign/MAC the set of offered
> >> extensions.
> >
> > Would someone like to propose text to this effect?
>
> I added a final sentence to the security consideration.  How about
> this?
>
>       <t>Because the initial length field is not protected, it is
> 	possible for an active attacker (i.e., one that is able to
> 	modify traffic between the client and the KDC) to make it
> 	appear to the client that the server does not support this
> 	extension mechanism (a downgrade attack).  Further, active
> 	attackers can also inferfere with the negotiation of which
> 	extensions are supported, which may also result in a downgrade
> 	attack.  This problem can be solved by having a policy in the
> 	clients and in the KDC to reject connections that does not
> 	have the desired properties.  The problem can also be
> 	mitigated by having the negotiated extension send a
> 	cryptographic checksum of the offered extensions.</t>
>
> This doesn't fully solve the problem though -- there is still a
> downgrade attack disabling the entire TCP extension mechanism.

That's OK.  If you have client policy that says you'll only talk to realm
FOO's KDC over TLS, and you don't get a TLS connection, you lose.  It
doesn't matter _why_ you didn't get a TLS connection, or in exactly what
way the negotiation failed, except for error reporting purposes.

-- Jeff