Subject: Re: 3DES and RFC1964

From: [email-masked]
Date: Tue, 4 Apr 2000 20:35:53 -0500

In regards to Ken Raeburn's posting of 04Apr2000 at 19:58:24, I respectfully
disagree with the proposed "due it now/fast" approach.  While I too want to see
3DES and other crypto algorithms available, in addition to DES, for the wrap()
and unwrap() calls, I don't believe the problem is so bad that we cannot fix it
in a more robust, well throught out manner.  AFAIK, DES has not been the weak
link (so far) in the vast majority of security breaches that get reported.  It's
usually poor planning, operation, human failure, et cetera.

At one point, I thought an extension to RFC 2078 (GSS-API v2) for QoP
specification would be the right approach, but I've since changed my mind.  I
think we should focus our efforts on SPNEGO and a new mechanism or mechanisms
with stronger symmetric crypto.
>
>
>> Tom Yu (MIT) asked about futures for the Kerberos GSS mechanism.  He stated
>> that Microsoft and others are interested in squeezing 3DES into RFC-1964
>> rather than doing a general cryptosystem-independent scheme, and asked the
>> attendees whether they wished to voice any objections to hacking into
>> RFC-1964 rather than pursuing a wholly new approach.
>
>Shouldn't have been "rather", but "in addition to" or "while".  The
>goal is to get 3DES available *now*, and a better
>cryptosystem-independent scheme available when we've banged out the
>details of little issues like whether ASN.1 sucks or whether 32-bit
>numbers are big enough or whether we should use already-defined
>Kerberos message structures or whether we can extend RFC1964 to be
>more cryptosystem-independent or whether we should order pizza for
>late-night meetings where go back and forth endlessly on such things
>without making any decisions.
>
>>    It was noted that
>> interoperability issues might arise if a single OID were used.  Ted Ts'o (VA
>> Linux) would like to see an analysis of what the failure cases and modes
>> would be. Tom plans to circulate a more detailed proposal to the list.
>
>IMHO the interoperability problems are similar to those that come up
>when adding new cryptosystems to Kerberos.
>
>Client side:
>
>Request from the KDC a session key from a list of cryptosystem types
>that your GSSAPI mechanism supports.  DES must be on the list, unless
>you simply don't want to talk to a non-updated service; we now add
>3DES as an option.  If you haven't upgraded your software, you'll be
>asking for DES only.
>
>MIT's 1.0 release didn't do this, in fact it lacked a lot of
>compatibility support for cryptosystem additions, in the krb5 core as
>well as GSSAPI.  The 1.1.1 release should fare much better -- it asks
>for DES only.
>
>
>Server side:
>
>Until the server-side software is updated for 3DES support, tell the
>KDC not to issue 3DES session keys for its services even if clients
>ask.  If the KDC has 3DES support, it must include somewhere, somehow,
>an indication of whether a given application server can support 3DES.
>(Worst case, a flag saying "turn 3des support off".  Best case,
>separate data for each principal.)  This is needed for a smooth
>upgrade of Kerberos, even ignoring GSSAPI issues.
>
>If a client initiates a connection using a 3DES session key, and the
>server's krb5 code supports it but the GSSAPI code does not (meaning
>IMHO that the KDC isn't configured right), context establishment will
>probably succeed, and all following messages will fail to be
>understood.  The end result of that depends entirely on how the GSSAPI
>library used and the application are written.  If they're written
>poorly, a crash or security compromise could result; that's always the
>case though.  If they're written well, they should print or log an
>error message, and fail.
>
>This could be a problem with code that negotiates for one of several
>authentication mechanisms -- the GSSAPI-KERBEROS context establishment
>will presumably be enough for both sides to agree on the use of that
>mechanism, and move on to exchanging data, but the data exchanges
>would fail because the messages couldn't be decoded.  But as I said,
>this situation is assuming a KDC that's misconfigured for that
>application server.
>
>Ken
>-++**==--++**==--++**==--++**==--++**==--++**==--++**==
>This message was posted through the Stanford campus mailing list
>server.  If you wish to unsubscribe from this mailing list, send the
>message body of "unsubscribe ietf-cat-wg" to [email-masked]

David K. Hemsath, Senior Security Architect
IBM Tivoli Security Business Unit
Building 1, Suite 270
9020 Capital of Texas Hwy N. GHCC
Austin, TX 78759  USA
e-mail: [email-masked]
Telephone: +1(512)458-4037 x5027; Fax: 2377
Cell phone/pager: +1(512)632-8567/[email-masked]

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Ken Raeburn <[email-masked]>
Date: 04 Apr 2000 23:24:04 -0400

> usually poor planning, operation, human failure, et cetera.

Let me make this perfectly clear: I don't want work on a better,
cleaner mechanism to stop.  I want it pushed ahead.  A point I tried
to make in my previous message was that these are not mutually
exclusive approaches.

I'm absolutely certain it can be done better, and I've been of that
opinion since well before MIT hired me nearly a year ago.  In fact,
I've been opposed to doing this hack in discussions on this topic in
the past, specifically because I wanted the effort to go into getting
the new mechanism done.  But progress on that front has been slow;
some proposals were put out longer ago than that.  I'm very skeptical
that it will be finished up any time soon.

I don't want to have to tell someone, "No, we won't give you 3DES
protection, because we're taking our time deciding details of a new
mechanism to deploy it, and we decided not to put in the day's effort
to add it to the old mechanism, because we don't like the old
mechanism."  At least, not to someone asking why we've added 3DES
protection to everything except the MIT krb5 administrative interface
that's based on GSSAPI, or why we recommend the GSSAPI over the krb5
interface when in our implementation it can't provide the same level
of protection.

One of the benefits of extending RFC1964 is that 95% of the work is
already done, and most of the decisions are already made; it's almost
a no-brainer.

Whether or not there's been an actual breach -- a publicly reported
one, that is -- is not the issue; it's coming within reach of large,
determined organizations now, and it'll only get easier.  IMHO that
means we need to raise the bar higher ASAP.

But yes, the fact that other attacks have been easier so far does
reduce the pressure somewhat.
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]