"key type not supported" and XP SP2 changes ?

[Jeffrey Altman]

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.

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.

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.

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.

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

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

> 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