"key type not supported" and XP SP2 changes ?

[Tim Alsop]

Comments inline prefixed with Tim> : 

-----Original Message-----
From: Jeffrey Altman [mailto:jaltman2 at nyc.rr.com] 
Sent: 08 September 2004 09:19
To: Tim Alsop
Subject: Re: "key type not supported" and XP SP2 changes ?

Tim Alsop wrote:

> 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.

This statement is one of the most confusing.  Under what conditions will
XP not obtain an RC4-HMAC session key?  I've been using XP for a long
time now and it always uses an RC4-HMAC key unless the user account has
been marked as DES only.

Tim> Yes, it will not get an RC4 session key when the account in AD is
marked as DES only. This is the only time it will not be RC4 as far as I
am aware and this is what I was referring to. I hope this clears up any
confusion.

Let us continue ...

> 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.

This is where you are making your mistake.  The API for Requesting a
Ticket from the KDC is the KerbRetrieveTicketMessage.  If you ask it for
a service ticket of the form "krbtgt/REALM at REALM" you are asking for a
query to be sent to the KDC.  It is up to the LSA to determine if the
request is satisfied from the cache or not.  Requesting the TGT should
not in general be used to determine if the LSA is appropriately
authenticated using "Kerberos".  It does not matter if there is a TGT
there or not as Windows caches the username and password at logon.  If
there is no valid TGT, Windows will obtain one (if possible) when you
query for an arbitrary service ticket.

Tim> Ok, I am not a developer so I was not aware of this, but your
explanation makes sense. Thank you for educating me :-)

However, if you want to ensure that you obtain a TGT with a DES enctype
all you do is specify the EncryptionType of the
KERB_RETRIEVE_TKT_REQUEST to be DES_CBC_MD5 or DES_CBC_CRC and you will
get a TGT returned to you with a session key of the specified type.
Windows does not provide any API other than the
KerbRetrieveTicketMessage to obtain the body of a Kerberos ticket so I
know this is the API you must be using.

Tim> ok, as you know a gss-api application does not ask for a tgt so we
must be just asking for a service ticket (during the initiate context
request). When we ask for a service ticket the LSA will presumably
determine that a tgt already exists (with rc4 session key) and then (for
some reason) we get an error because our code does not recognise the rc4
etype.

If all you want to know is whether or not the cache contains a ticket
that is named "krbtgt/REALM at REALM" with a valid expiration time, then
you should not be using KerbRetrieveTicketMessage but instead should be
using either KerbQueryTicketCacheMessage (on Win2000) or
KerbQueryTicketCacheExMessage (on XP).  However, as I pointed out above
the failure to find a TGT in the cache is really meaningless given the
fact that the username and password for the Windows account used to
obtain the TGT are cached in the LSA.

Tim> we are not planning to change the way our code works - we just want
to understand why we get this problem with SP1 and see if there is a way
to make SP1 work same way as SP2. Clearly there are many things we can
do to our code to circumvent the Sp2 upgrade and this is being
considered as one of the options, but the preferred option is for MS to
issue a hotfix in order to allow the SP2 functionality to be available
in pre-SP2 XP workstations.

> 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.

There is no need for any of this.

Tim> So, if there is no need for (i) (ii) (iii) or (iv). What do you
suggest is the answer to our problem ?

> 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.  SP2 has broken third party products.  Third party products have
been forced to modify their use of the LSA in order to obtain the same
level of functionality.  Vendors test the OS Version and Service Pack
level to determine which set of functionality is available in each OS
release.  The XP SP2 functionality is equivalent to the 2003
functionality.  This is different from the 2000 through 2000 SP4
functionality and the XP through XP SP1 functionality.  I expect that
2000 SP5 will support a different subset and that 2003 SP1 will be
significantly changed as well.

Tim> Sounds like we will have "fun" for many years to come then :-)

> 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.

--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu