Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009

[Jeffrey Altman]

Ken Hornstein wrote:
> We were required to turn off 1DES a long time ago, and any exceptions
> we had to document.  

and how long did it take you to get to that point?

> We have only two documented 1DES applications:
> AFS, and some crappy local Java application that only works with 1DES

only one Java application?  you are lucky.

> (I know, I know ... newer Java implementations supposedly support more
> enctypes, but there is some reason that these applications cannot use a
> newer Java.  I don't really pretend to know what's going on there, but
> the whole thing makes me want to kick the implementer of Java-GSS in
> the balls repeatedly, along with whomever thought Java was a good idea
> for this application in the first place).

The applications are tied to class libraries and the class libraries are
bundled to Java versions.  To make matters worse, there has not been
good backward compatibility between the versions.  Especially within the
user interface components.  As a result a Java application once tested
against a certain version of Java must be treated as if it only works on
that version of Java.

C#/.NET frameworks have an equivalent problem in the Microsoft world.

> However ... we are actually the exception.  A number of DoD realms that
> I work with do not run AFS, and as a result they have zero 1DES keys.
> And they get regular audits from people who peer over their KDC databases
> LOOKING for 1DES keys, so it's not like they're going to be able to sneak
> 1DES keys in there.

I will point out that your site has been running with the 3DES Telnet
patch now for years.  This is not true for the MIT Kerberos unsupported
distribution.

> So I think a blanket statement saying it's not possible for ALL realms to
> turn off 1DES is simply untrue.

I didn't say that "no realm" could turn off 1DES.  I said that "all
realms" could not.  There are certainly realms that have no legacy
applications that could turn off 1DES.  There is absolutely benefit to
avoiding the use of 1DES keys in new realms unless someone does
something special to enable 1DES for a specific principal.

> Now certainly there are plenty of realms that still have single-DES
> applications.  But aside from AFS, I think those applications are
> a pretty small list.  The ones that come to mind are Kerberos telnet,
> that double-secret Kerberos authenticated Oracle, Java (dammit dammit DAMMIT
> WHAT THE HELL?!?!?!?), Kerberos-authenticated NFS (note: more ball-kicking
> in order here).  I'm sure there are others, but still ... I think the large
> majority of apps can work fine without single-DES.  I can imagine that
> a number of realms can work without any single-DES at all; if you allow
> AFS as the single exception, I bet the number goes way up.

The vast majority of applications still using 1DES are things which are
internally designed, statically linked to old Kerberos libraries or
dependent on old Java GSS, and for which it may even be true that source
code is no longer available.  Given the current state of the economy and
the cut backs in staff levels, it is even more likely at the current
time that re-writing these applications will not be able to take place.

I'm not arguing that it cannot be or should not be done.  1DES must be
removed.  I'm only arguing that it must be done in a manner that permits
organizations to phase in the transitions.  You can't simply remove the
ability for end users to obtain 1DES service tickets.  Many orgs simply
do not have a list that says here are all of the clients and all of the
services and what enctypes are required or compatible.  Instead, it is a
lot safer to define a policy and apply it to a subset of the principals
that are believed to be safe to restrict a little at a time.

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090130/0f21993d/attachment.bin