"key type not supported" and XP SP2 changes ?

[Tim Alsop]

Jeffrey,

We have been using DES keys with MS AD KDC's for last 4 years and now we
have discovered we can use RC4-HMAC tgt with XP SP2. Before SP2 we have
been able to use RC4 tgt with Windows 2000 workstations only. We are
therefore trying to make it work with XP SP1. 

As I mentioned before we are not requesting the tgt so we cannot ask for
a DES-CBC-CRC or DES-CBC-MD5 tgt in the request. We are simply reading
the LSA cache and the Microsoft code is requesting the tgt from AD. The
way I understand it works is that our code reads the tgt to check it is
present and valid, then we read the service ticket to see if this is
present and valid. If the MS LSA sees a request to read a ticket that is
not present it asks AD to issue the ticket rather than answering "ticket
not present". I also understand that our code is validating the ticket
by looking at the etype and this is causing the problem when it sees the
RC4 key.

In response to Sam's suggestion about mapping unsupported keytypes -
yes, this is an option for us, but we are trying to investigate all
options available and make a decision about the best way forward in
short term. It appears the main options are (in no particular order) (i)
convince customer to upgrade to SP2, (ii) add rc4 support to our code
quicker than previously planned, (iii) modify our code so it ignores the
error or maps rc4 onto null etype, (iv) use des keys for user accounts.

We are only looking for this solution for 1 client who cannot upgrade to
SP2 for other reasons. Our product is the first product that will be
using kerberos other than MS operating system use of the protocol. I
don't understand why upgrading kerberos.dll is any different to being
able to apply the part of SP2 that is needed - are you suggesting that
SP2 will break other third party products ?

Yes, we plan to open a PSS request with MS if we decide this is the best
way forward in short term.

Thanks again,

Tim.

-----Original Message-----
From: kerberos-bounces at MIT.EDU [mailto:kerberos-bounces at MIT.EDU] On
Behalf Of Jeffrey Altman
Sent: 07 September 2004 23:53
To: kerberos at MIT.EDU
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim:

You have not provided enough information to show how your code is ending
up with the RC4-HMAC session key.  The XP SP2 changes have only been
around for the last four weeks in production code.  What have you been
doing for the last four years to make your code work with Windows 2000
and XP?

If the only enctypes which are common between your libraries and the
Windows Kerberos are DES-CBC-CRC and DES-CBC-MD5, then you must request
tickets by specifying one of those enctypes at the time you request
them.  Otherwise, you are likely to end up with RC4-HMAC as the session
key type when talking to Active Directory unless the account associated
with the SPN has been configured to be DES only.

Asking your clients to install a new version of Kerberos.dll on their
systems is going to break other third party products which rely on the
Kerberos SSP functionality as determined by the operating system version
number.  For that reason I doubt that Microsoft would issue such a
change.  Of course, you could always file a PSS request if you have a
support contract.

Jeffrey Altman


Tim Alsop wrote:

> Jeffrey,
> 
> Sorry to be confusing. Our code is not requesting a tgt, but I know 
> for a fact that setting AllowTGTSessionKey to 0 on XP SP2 (the default
> setting) causes our code to work as required, but setting it to 1 
> causes it to complain with "key type not supported". My explanation I 
> have given so far has been based on my assumptions from this test - 
> maybe wrongly, but I am trying to draw a conclusion and it seems 
> likely to me that if the key is not exported we don't give an error 
> because we don't see the RC4 key. Maybe this conclusion is incorrect, 
> but it does not change the fact that if we had the support for 
> AllowTGTSessionKey on
> pre-SP2 XP systems we could provide a quick solution to the problem 
> discovered by our customer.
> 
> I realy do apprecaite your help so far with this issue. I hope my 
> explanation above helps ?
> 
> Take care,
> 
> Tim.
> 
> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On 
> Behalf Of Jeffrey Altman
> Sent: 07 September 2004 20:30
> To: kerberos at mit.edu
> Subject: Re: "key type not supported" and XP SP2 changes ?
> 
> Tim Alsop wrote:
> 
> 
>>Tim> we don't want to extract a tgt from lsa cache. This is not
>>necessary because our Kerberos library interfaces with LSA and 
>>requests a service ticket. The service ticket request is handled by MS
> 
> 
>>code and the MS Kerberos library (e.g. LSA) sends the request to MS AD
> 
> 
>>KDC. Our Kerberos library does not need any access to the Key, but 
>>since it sees the key and we have validation code to check for etypes 
>>that are supported (for other reasons) our code gives "key type not
> 
> supported"
> 
>>error.
> 
> 
> If you are not requesting the TGT then the AllowTGTSessionKey flag 
> does not come into play at all.
> 
> 
> 
>>Tim> we are not looking to use DES enc type. The expectation is that
>>Tim> RC4
>>keys can be used for TGT, but when a tgt is stored in the LSA cache we
> 
> 
>>don't see the RC4 key (e.g. AllowTGTSessionKey = 0). If we see the key
> 
> 
>>our code considers this to be an error - we are trying to avoid this 
>>but cannot on pre-SP2 versions of XP.
> 
> 
> What AllowTGTSessionKey does is allow the session key to be exported.
> If it cannot be exported the encryption type is set to 0
(ENCTYPE_NULL).
> 
> I really suggest that you fix your code.  Setting the 
> AllowTGTSessionKey value to 0 breaks KFW and it breaks Java Kerberos.
> 
> 
>>Tim> Our code has a similar cache type to hide any specifics from the
>>application. Our implementation will eventually support the RC4 etype 
>>so this will work better then, but we have an existing customer who 
>>cannot deploy SP2 for a while and are trying to see if there is a 
>>short term solution for them.
> 
> 
> Your statements are so confusing.  You have said repeatedly that the 
> reason you need to AllowTGTSessionKey flag is because you need to hide

> the RC4-HMAC enctype from your application.  But now you say the 
> customer is having problems installing XP SP2 which is where the 
> default behavior is "AllowTGTSessionKey = 0.  Which is it?
> 
> 
> 
>>Tim> If MS were able to implement the AllowTgtSessionKey that is in
> 
> SP2
> 
>>so that it can be added by hotfix to SP1 XP workstations this will
> 
> solve
> 
>>our problem.
> 
> 
> My confusion continues.  How does this solve your problem?
> Why is your application caring about the session key enctype of the 
> TGT when it is not attempting to use the TGT to obtain a service
ticket?
> 
> Jeffrey Altman
> 
> 
> 

--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos