[OpenAFS-devel] configurable cryptosystem support

[Marcus Watts]

Jeffrey Hutzelman <jhutz@cmu.edu> had replied:
...
> > RFC 3961 defines a "pseudo-random" function for each crypto
> > system.  I would dearly love to use that in rxk5 - but I don't know of
> > any public implementation, entry points, or test vectors.
> 
> Indeed, there don't seem to be any.  So, help us to correct that 
> deficiency.  I'm sure there are implementors who would be happy to help 
> produce test vectors.

Right, and I'm certainly interested in pursuing this.
Once I get spare time.  Or at least less overly committed time.
One of the choices I made with openafs+rxk5 was to forego pursuing
this in the interests of actually getting something out the door.

> 
> > RFC 3961 contains a set of 'assigned numbers' for crypto systems,
> > but specifically omits any mention of which ones might be "required".
> 
> Right.  RFC3961 is a toolkit; it is up to the application using it to tell 
> you which tools are required.  In the case of Kerberos, this is specified 
> in section 8.1 of RFC4120, which requires AES256-CTS-HMAC-SHA1-96 and the 
> corresponding cksumtype HMAC-SHA1-96-AES256.  It also recommends support of 
> DES-CBC-MD5 and DES3-CBC-SHA1-KD, and their corresponding cksumtypes 
> DES-MD5 and HMAC-SHA1-DES3-KD.

Right.  That's a different list than previous standards, isn't yet
widely implemented by windows, and doesn't mention rc4 which is
important for talking to current versions of windows.  In any event the
next iteration of the standard will presumably deprecate des.  By
default k5ssl will support a superset of that list; the configure
option allows people to configure non-standard subsets, including in
particular removing des.

> 
> 
> BTW, I do wish you would configure in terms of the standard enctypes, 
> rather than configuring the underlying algorithms.

That creates a whole bunch of problems.  Like, what do you mean
"standard" enctypes?  What about "non-standard" enctypes?  Also, how do
you name standard enctypes?  Nearly all of them have at least 3 and often
more naming variations, including case, _ vs. -, ENCTYPE_, ETYPE_, or no prefix,
rc4 vs. arcfour, sometimes heimdal vs mit, etc.  The number at least is
more dependable, mainly because that's the only part the standard
actually governs.

The checksum types are in even worse disarray.  One of the more
horrendous problems I had with rxk5 was in selecting the appropriate
checksum type to go with a given keytype.  (This was to do
"rxk5_auth" -- integrity checking without privacy).  The obvious
MIT choice, krb5_c_keyed_checksum_types(), doesn't exist in heimdal.
Things went downhill from there.  The most useful checksum
typed turned out to be CKSUMTYPE_HMAC_SHA1_DES3, because
it's universally implemented and doesn't actually use des3
so doesn't care what key type.

The most useful distinction I would have gained with finer grain configuration
is the ability to separately enable 17 and 18.  Almost all other
choices I might have mader are either irrelevant or worse.  Out of etypes
4 5 6 7 16, only 16 is useful for des3.  Out of 1 2 3 8, 1 and 3
are clearly necessary, 2 is silly but harmless, 8 is interesting but
doesn't exist in heimdal, and all of these are basically insecure on
account of limited keysize.  jaltman was asking that 1 2 3 8 be disabled
wholesale at least by default in openafs.  Out of 23 24, jaltman already
made the case for just not bothering with 24.

> 
> -- Jeff
> 

				-Marcus