[OpenAFS-devel] Kerberos V, KeyFile questions

[Douglas E. Engert]

Sean O'Malley wrote:
> 
> I am attempting to convert our afs test cell to auth off of kerberos V
> MIT instead of kaserver.
> 
> My question revolves around the KeyFile. It LOOKS like I need the salted
> passphrase for the KeyFile in order to do migrate the current users.
> Is this correct? and if so, is there a program to crack this password?

Not sure what you are asking. The KeyFile has the DES keys and kvnos that
are used by AFS to encrypt tokens. Normally there is only one key in the file.

I don't believe this has anything to do with how entries are stored in the KAS.
but it does have to do with how the tokens generated by the KAS are encrypted.

> 
> I am NOT sure what the encryption is for the KeyFile I will end up using
> but it was created like in circa 92 and I am not sure anyone knows it.

The KeyFile is not encrypted. The DES keys in the file may have been generated
randomly or from a password using a string-to-key function. 

Not that you can have multiple keys in the KeyFile, and they could be shared
with multiple authentication systems. Say for example that you still have the
key used with KAS, and it has a kvno of 1. You can add a key to the KeyFile
that was generated on the K5 KDC or the Windows AD acting as a KDC.

One way to do this is to use the "bos_util adddes" routine. 
Here you give it a password. But the Windows AD (via the ktpass routine)
is using the V5 string-to-key function whereas the bos_util is using the
V4 string to key. But you can still us it, as K5 string-to-key concatenates
the password, the realm and principal strings to generate a key.    

So lets say you use the Windows 2003 AD ktpass with a password:

   ktpass -princ afs/my.afs.cell@WIN.AD.DOMAIN -mapuser svcAFS -pass qwertyui -kvno 5

Then you could use:

   bos_util adddess 5

when prompted for the password use:

   qwertyuiWIN.AD.DOMAINafsmy.afs.cell
 
The kvno is tricky with Windows, as Windows 2000 will use either 0, or 1,
where as 2003 will do the correct thing and use what you tell it. 
 
So in our KeyFile we actually have a 0, 1, and 5 entry which all have the
same key. We also have some others which where used by DCE, KAS and the 
modified krb524d.

> 
> The last question is do the newer AFS clients support Kerberos V natively
> or is that still on the "todo" list?   

This is still not a full K5 support. The keys used must still be DES,
and the AFS code has the minimal set of routines to support decoding
a K5 ticket.

The ktc_setToken is passed a DES session key, and the token, which   
includes an encrypted part using one of the keys in the KeyFile. It is 
also passed a kvno that matches the key in the KeyFile, The ktc_setToken
passes this to the cachemanager.  

To get the session key, kvno and encryptd part of a ticket on the
client still requires some Kerberos libs from some Kerberos vendor,
be it MIT, Heimdal, or Microsoft. This is usually done with a ak5log,
or afslogin program which gets linked with AFS and calls the ktc_setToken.  

1.2.9 I believe could handle a Kerberos v5 token. But it had to be small,
and it had to use dec-cbc-crc. 

The Windows client 1.3.64 along with the MIT KfW has native support.  

> 
> I am assuming I have to run krb524 and use the older encryption methods
> for the stored hashes (which are incompatible with like Windows.)

1.3.64 will correct this, and support des-cbc-md5 and larger tickets.
This is needed on the client and server side. 

> We still need IV compatibility until the migration to V is complete which
> will take at least a year. I would like to dump kerberos IV support
> altogether. I am just wondering about the feasibility of the plan.
> 
> Sean
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444