logo_kerberos.gif

Difference between revisions of "Projects/Enctype config enhancements"

From K5Wiki
Jump to: navigation, search
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{project-early}}
+
{{project-rel|1.8}}
   
 
==Goals==
 
==Goals==
Line 7: Line 7:
 
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.
 
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.
+
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 principal renaming and principal canonicalization.
   
 
==Design==
 
==Design==
Line 44: Line 44:
 
</pre>
 
</pre>
   
3. Salt simplification
 
  +
3. supported_enctypes
   
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:
+
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. So there were will be no change to the handling of this variable.
   
# The concept of salt types will be deprecated.
 
  +
The back-burnered project [[Projects/Random_Salt_Generation]] would allow this variable to use the same syntax as the other enctype variables.
# For all new principals, a random salt will be generated and stored in the principal's DB entry (this is currently known as the 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 supported_enctypes variable 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.
 
   
 
==Implementation and Testing Notes==
 
==Implementation and Testing Notes==
   
Currently the three etype variables are processed by a static function in init_ctx.c named get_profile_etype_list. This project will probably create a subsidiary non-static function in with a name like krb5int_expand_etype_list which does the string processing part of that function. A new unit test program t_enctypes.c can use this function to exercise the code for modifying the enctype list and expanding families, and can also test that ":salttype" specifications are properly ignored.
+
Currently the three etype variables are processed by a static function in init_ctx.c named get_profile_etype_list. This project will probably create a subsidiary non-static function in with a name like krb5int_expand_etype_list which does the string processing part of that function. A new unit test program t_enctypes.c can use this function to exercise the code for modifying the enctype list and expanding families.
  +
  +
==Review==
  +
  +
This section documents the review of the project according to [[Project policy]].
  +
It is divided into multiple sections. First, approvals should be listed. To list an approval type
  +
:<nowiki>#~~~~</nowiki>
  +
on its own line.
  +
The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with <nowiki>{{project-block}}</nowiki>.
   
For enctype families, it will probably be convenient to expand the etype definitions in etypes.c with a family string for each enctype (NULL for enctypes which do not belong to a family), and add an API to get the family of an enctype.
 
  +
===Approvals===
   
To efficiently process enctype lists, it will probably be convenient to use a boolean vector with one entry per enctype. To do this we need a maximum enctype number, which will probably be a new constant in k5-int.h. If a new enctype is defined without updating this constant, it will be obvious since the new enctype won't be enabled by the processing functions.
 
  +
#[[User:TomYu|TomYu]] 08:45, 25 August 2009 (EDT)
   
Transmitting salts in AS-REQ responses is already well-tested because, since r22264, we send an explicit salt even for '''NORMAL''' salttype entries. The existing test suite should adequately test the use of '''SPECIAL''' salttypes once kadmin is changed to use them.
 
  +
===Discussion===

Latest revision as of 00:12, 16 February 2010

This project was completed in release 1.8.


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

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. So there were will be no change to the handling of this variable.

The back-burnered project Projects/Random_Salt_Generation would allow this variable to use the same syntax as the other enctype variables.

Implementation and Testing Notes

Currently the three etype variables are processed by a static function in init_ctx.c named get_profile_etype_list. This project will probably create a subsidiary non-static function in with a name like krb5int_expand_etype_list which does the string processing part of that function. A new unit test program t_enctypes.c can use this function to exercise the code for modifying the enctype list and expanding families.

Review

This section documents the review of the project according to Project policy. It is divided into multiple sections. First, approvals should be listed. To list an approval type

#~~~~

on its own line. The next section is for summarizing discussion, which should take place on krbdev@mit.edu. Provide links to the archive at http://mailman.mit.edu/pipermail/krbdev/ if appropriate. Blocking objections can be noted with {{project-block}}.

Approvals

  1. TomYu 08:45, 25 August 2009 (EDT)

Discussion