GSSAPI delegation wierdness, a DOS, and channel bindings

[Sam Hartman]

>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

    Tom> I apologize for not getting to this sooner; IETF and other
    Tom> things have intervened.

And it managed to get dropped on the floor again.
*sigh*

    Tom> We still need to look over the creds-encryption problem more
    Tom> carefully, though, so we won't take that change just yet.

This does create a critical interop problem with Heimdal.  Many
applications including current ssh do not work with the Heimdal
release.  Or rather, if you have an MIT server and Heimdal clients you
run into significant problems.

It is my intent to audit the patch and apply whatever hunks Tom did
not grab while correcting the DOS issue back in August.

The client behavior will be as follows:

* For currently specified GSS crypto-systems (DES, 3DES) besides rc4,
  we will not encrypt.

* For rc4 and future crypto systems we will encrypt the credentials.

Thanks to Microsoft for indirectly realizing that we could hang this
misfeature as another side-car on crypto system negotiation.


Note that if IETF standardizes any of the current proposals for an
extensible krb-cred2 message, we will encrypt when sending that
message, as the spec is very likely to make such encryption mandatory.

It is highly unfortunate that we did not handle this patch in time for
the 1.2 series of Kerberos releases.

At least for now I propose to accept unencrypted credentials on the
server side.  In future, when there are situations where we know
accepting unencrypted credentials is never needed, we may be more
restrictive in when we accept the unencrypted credentials.