Antwort: Re: Encryption types [Virus checked]

[Jeffrey Altman]

denis.havlik at t-mobile.at wrote:

>>Make sure that the service principals in the KDC do not contain
>>any enctypes other than DES-CBC-CRC or DES-CBC-MD5.  Java cannot
>>handle them.
> 
> 
> Don't understand this. Aren't client programs supposed to choose the 
> encryption types they do understand out of the types that are offered by 
> KDC, and negotiate the strongest encryption supported by both KDC and the 
> client program?
> 
> Is this a bug in java, or have I misunderstood the way kerberos auth. 
> works?

There are three entities involved in Kerberos authentication:
* the end user A
* the KDC
* the service B

"A" knows what enctypes it understands but has no clue what
enctypes "B" understands.  It is up to the KDC to know what
enctypes "B" understands.  How does the KDC know which enctypes
"B" supports?  The answer it "it looks at the list of keys
it has for "B" in its database.

Now if the service is implemented in Java, there is only
support for the DES enctypes.  If you generate keys for
"B" using RC4, 3DES, or AES you are going to be in trouble.
The KDC will attempt to use the strongest possible enctype
which will naturally be one that the Java service will not
understand.

-----------

On the end user side you may find yourself with a different
incompatibility.  Let's say that you are using a JAAS class
to obtain the end user TGT from an existing credential cache
which is populated at login using MIT Kerberos 1.3.x.  The
MIT Kerberos kinit is going to obtain a TGT using the strongest
possible enctype for which there is a key in the KDC database.
There is a very strong chance that the credential cache will
not contain a TGT which the Java library will be capable of
processing due to the Java Kerberos library's support only
for the DES enctypes.