logo_kerberos.gif

Difference between revisions of "Projects/Enctype config enhancements"

From K5Wiki
Jump to: navigation, search
(New page: {{project-early}} Provide a means of specifying inclusions and exclusions in the configuration variables that are lists of enctypes. At present, the only way to specify a non-default enct...)
 
Line 1: Line 1:
 
{{project-early}}
 
{{project-early}}
Provide a means of specifying inclusions and exclusions in the configuration variables that are lists of enctypes. At present, the only way to specify a non-default enctype list is to explicitly list every enctype. This means that a configuration file with such an explicit list will inherently become out of date when future software releases update the default enctype lists.
 
   
One example is
 
  +
==Goals==
  +
 
At present, the only way to specify a non-default enctype list is to explicitly list every enctype. This means that a configuration file with such an explicit list will inherently become out of date when future software releases update the default enctype lists.
  +
  +
The goal of this project is to improve the administrator experience in specifying enctypes. A primary goal is to make it possible to modify the default list of enctypes without replacing it. A secondary goal is to make enctype specifications easier and clearer.
  +
  +
As a side benefit of the design, there will be a simplification of salt handling in the KDC, which will eventually have positive ramifications for principle renaming and principal canonicalization.
  +
  +
==Design==
  +
  +
1. Modifying the default enctype list
  +
  +
The following syntaxes will be added for the three enctype variables '''default_tgs_enctypes''', '''default_tgt_enctypes''', and '''permitted_enctypes'''.
  +
  +
* The word '''DEFAULT''' will expand to the default list of enctypes for that variable.
  +
* The specifier -''enctype'' will remove ''enctype'' from the list of enctypes expanded so far.
  +
* The specifier +''enctype'' will expand to ''enctype'' -- the + is a no-op for clarity purposes.
  +
  +
Examples of enctype specifications using these syntaxes are:
   
 
<pre>
 
<pre>
 
permitted_enctypes = DEFAULT +des-cbc-crc
 
permitted_enctypes = DEFAULT +des-cbc-crc
  +
default_tgs_enctypes = DEFAULT -arcfour-hmac
 
</pre>
 
</pre>
   
or
 
  +
2. Enctype families
  +
  +
The following non-overlapping enctype families will be defined:
  +
  +
* des: des-cbc-crc des-cbc-md4 des-cbc-md5
  +
* des3: des3-cbc-sha1
  +
* rc4: rc4-hmac-md5
  +
* aes: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
  +
  +
In general, families are named after ciphers (or in the case of AES, the pair of ciphers AES-128 and AES-256), and include all enctypes from the krb5 default permitted enctypes list which make use of that cipher. "Unreasonable" enctypes such as exportable RC4 and raw-mode DES are not included in families.
  +
  +
In an enctype list, a cipher family will be expanded to the corresponding list of enctypes, and -''family'' will remove all enctypes from ''family'' from the list of enctypes expanded so far. Examples could include:
  +
 
<pre>
 
<pre>
permitted_enctypes = DEFAULT -arcfour-hmac
+
permitted_enctypes = DEFAULT -des
  +
default_tgs_enctypes = DEFAULT -aes aes256-cts
 
</pre>
 
</pre>
   
where <code>DEFAULT</code> designates the default set of enctypes.
 
  +
3. Salt simplification
  +
  +
There is a fourth enctype variable, '''supported_enctypes''', which contains a list of ''enctype'':''salttype'' specifications. The salt types make it awkward to apply the above syntax extensions to this variable. To simplify this situation:
  +
  +
# The concept of salt types will be deprecated.
  +
# For all new principals, a random salt will be generated and stored with the principal (salt type '''SPECIAL'''). Existing KDC code will transmit the explicit salt to the client when responding to AS-REQs.
  +
# For compatibility, enctype list parsing will accept and discard ":salttype" specifications after enctypes.
   
The OpenSSL cipher list format could be one option, but it is probably too complicated for this purpose.
 
  +
supported_enctypes can then use the same syntax as the other three enctype variables. This simplification has some ancillary benefits for principal renaming and principal canonicalization, although those benefits cannot be immediately realized in the code base because of existing DB entries using non-'''SPECIAL''' salt types.

Revision as of 13:03, 23 July 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


Goals

At present, the only way to specify a non-default enctype list is to explicitly list every enctype. This means that a configuration file with such an explicit list will inherently become out of date when future software releases update the default enctype lists.

The goal of this project is to improve the administrator experience in specifying enctypes. A primary goal is to make it possible to modify the default list of enctypes without replacing it. A secondary goal is to make enctype specifications easier and clearer.

As a side benefit of the design, there will be a simplification of salt handling in the KDC, which will eventually have positive ramifications for principle renaming and principal canonicalization.

Design

1. Modifying the default enctype list

The following syntaxes will be added for the three enctype variables default_tgs_enctypes, default_tgt_enctypes, and permitted_enctypes.

  • The word DEFAULT will expand to the default list of enctypes for that variable.
  • The specifier -enctype will remove enctype from the list of enctypes expanded so far.
  • The specifier +enctype will expand to enctype -- the + is a no-op for clarity purposes.

Examples of enctype specifications using these syntaxes are:

permitted_enctypes = DEFAULT +des-cbc-crc
default_tgs_enctypes = DEFAULT -arcfour-hmac

2. Enctype families

The following non-overlapping enctype families will be defined:

  • des: des-cbc-crc des-cbc-md4 des-cbc-md5
  • des3: des3-cbc-sha1
  • rc4: rc4-hmac-md5
  • aes: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

In general, families are named after ciphers (or in the case of AES, the pair of ciphers AES-128 and AES-256), and include all enctypes from the krb5 default permitted enctypes list which make use of that cipher. "Unreasonable" enctypes such as exportable RC4 and raw-mode DES are not included in families.

In an enctype list, a cipher family will be expanded to the corresponding list of enctypes, and -family will remove all enctypes from family from the list of enctypes expanded so far. Examples could include:

permitted_enctypes = DEFAULT -des
default_tgs_enctypes = DEFAULT -aes aes256-cts

3. Salt simplification

There is a fourth enctype variable, supported_enctypes, which contains a list of enctype:salttype specifications. The salt types make it awkward to apply the above syntax extensions to this variable. To simplify this situation:

  1. The concept of salt types will be deprecated.
  2. For all new principals, a random salt will be generated and stored with the principal (salt type SPECIAL). Existing KDC code will transmit the explicit salt to the client when responding to AS-REQs.
  3. For compatibility, enctype list parsing will accept and discard ":salttype" specifications after enctypes.

supported_enctypes can then use the same syntax as the other three enctype variables. This simplification has some ancillary benefits for principal renaming and principal canonicalization, although those benefits cannot be immediately realized in the code base because of existing DB entries using non-SPECIAL salt types.