Enctype configuration

[Zhanna Tsitkova]

On Jul 22, 2009, at 11:20 AM, ghudson at MIT.EDU wrote:

> I'm soliciting ideas on enctype configuration changes for 1.8.  Tom
> has a skeletal early project page at:
>
>  http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements
>
> The primary deliverable here is the ability to modify the default list
> of enctypes without completely replacing it.  So the first question is
> what syntax to introduce for that.  OpenSSL has one but it's probably
> too complicated for our purposes.  Tom proposed one in the project
> page which is probably fine.
>
> A secondary deliverable is making such modifications easier.  We
> currently have four basic families of enctypes: des, des3, rc4, and
> aes.  For each family we have 1-3 entries on the default enctypes list
> and some anciliary enctypes which you wouldn't generally want to use
> (e.g. rc4-hmac-exp and des-cbc-raw).  To remove DES from today's
> default list in Tom's proposed syntax, you would have to write:
>
>  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4
How is DEFAULT defined? The list of the default enctypes may be  
different between krb releases  and be effected by the security  
advisories.
>
>
> and if you're paranoid about the non-default DES enctypes, you might
> decide to write:
>
>  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4 -des-cbc-raw -des- 
> hmac-sha1
>
> We could make this easier through some kind of globbing, or through
> syntaxes for adding or disabling enctypes based on algorithmic
> components ("exclude anything using DES", "exclude anything using
> MD5").  Alternatively, we could formally define the four enctype
> families and allow inclusion and exclusion by family.  The presence of
> undesirable enctypes like rc4-hmac-exp complicates the issue a bit; if
> an configuration option says "include the RC4 family" then we wouldn't
> want to add 40-bit RC4 to the list, but if an option says "exclude the
> RC4 family" we would definitely want to exclude it.  Of course, these
> undesirable enctypes aren't on the default list in the first place, so
> perhaps there's no real issue.
My  suggestion of using "globs" came as a desire to make admin's  
experience more transparent.
For example, admin wants only DES3 and AES crypto without MD5. So one  
indicates: +DES3 +AES -MD5.
in addition, perhaps: +rc4-hmac

> If we're going to address the secondary deliverable at all, I would
> lean towards using the families option, because it gives the
> administrator less rope than globbing or algorithmic component
> matching.
>
> Finally, there is a third, ancillary issue, which is the
> supported_enctypes variable tells kadmin what key/salt combinations to
> create keys for from a user's password.  Because the variable includes
> salt types as well as enctypes, it would be complicated to directly
> apply any new syntax to this variable.
>
> What I would like to see happen here is for us to stop supporting salt
> type configuration.  Ken suggested some time ago that we should just
> generate a random explicit salt for every new principal.  If we make
> that change, supported_enctypes can become a straight enctype list
> using the same syntax as the other three enctype variables.  For
> backward compatibility, we would have to accept and ignore :salttype
> specifiers after enctypes, of course.  It would take a little extra
> time to implement this, but it would also carry side benefits.
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev