Difference between revisions of "Projects/Disable DES"
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | {{project- |
+ | {{project-rel|1.8}} |
| − | This project will disable the single-DES encryption algorithms by default. A future (post-1.7) release will remove the code that supports single-DES. |
||
| ⚫ | |||
| + | The single-DES cipher is now widely recognized as being weak. (See RFC 4772 among others.) A future (post-1.7) release will remove the code that supports single-DES enctypes. To prepare for this future change, methods of disabling the use of single-DES enctypes must be available before then, in addition to other transition strategies. Mailing list discussion implies that using a single switch is to coarse for orderly transition, but there also should not be too many new knobs. Implementation timeline is the krb5-1.7 release. |
||
| − | In the future, in a separate project, in order to make this more future-proof, the configuration of enctypes will be enhanced to allow for inclusions and exclusions, e.g. |
||
| + | Transition strategies include |
||
| + | * Configuration option to completely disable the use of single-DES enctypes. This is a rather large hammer. |
||
| + | * Make kadmind default to not creating long-term keys with single-DES enctypes. |
||
| + | * KDC will move single-DES enctypes listed in a request to the end of the list. If a client requests any enctype that is stronger than single-DES, it will be considered before any single-DES enctypes for the purposes of session key selection and reply encryption. |
||
| + | * Provide a facility for listing enctype preferences in the KDB without providing a key. This will allow the use of an enctype for session keys but not expose a long-term key to attack. |
||
| − | <pre> |
||
| + | === Configuration to disable weak crypto === |
||
| − | permitted_enctypes = DEFAULT +des-cbc-crc |
||
| − | </pre> |
||
| − | or |
||
| ⚫ | The '''allow_weak_crypto''' libdefault boolean (which aligns with Heimdal) will control whether "weak" crypto is allowed. The crypto library will gain an internal API, krb5_c_weak_enctype(), which will indicate whether a given enctype is "weak". The krb5_keytypes structure will have a flags word that will contain a bit indicating whether a given enctype is weak. |
||
| − | <pre> |
||
| − | permitted_enctypes = DEFAULT -arcfour-hmac |
||
| − | </pre> |
||
| − | where <code>DEFAULT</code> designates the default set of enctypes. |
||
| + | A future project, [[Projects/Enctype_config_enhancements|enctype config enhancements]], will make it possible to implement this sort of enctype policy in a more generalized way. |
||
| + | === De-prioritize single-DES in session key selection === |
||
| + | |||
| + | Lowering the priority of single-DES in session key selection has few side effects. If a client requests both DES and stronger enctypes, it supports the stronger enctypes. |
||
| + | |||
| + | === Default to not creating weak keys === |
||
| + | |||
| + | Changing the kadmind defaults to stop creating single-DES keys could cause problems for users who are still using old software not capable of stronger ciphers. Changing the default for new service keys is more tractable. (A service is unlikely to use software of mixed capabilities.) |
||
| + | |||
| + | Separate supported_enctypes lists for services and clients are possible, but it is not clear that this additional complexity is desired. |
||
| + | |||
| + | === Pure enctype preferences in KDB === |
||
| + | |||
| + | Key lists in the KDB serve a dual purpose. They provide multiple keys for the purpose of supporting users who may use multiple versions of client software with differing enctype capabilities. They also indicate what session key enctypes are acceptable. Key data entries for a principal in the KDB could use zero-length keys to represent pure enctype preferences. Alternatively, a separate session key enctype preference list could exist on a per-principal basis. |
||
==Review== |
==Review== |
||
Latest revision as of 12:27, 12 October 2010
The single-DES cipher is now widely recognized as being weak. (See RFC 4772 among others.) A future (post-1.7) release will remove the code that supports single-DES enctypes. To prepare for this future change, methods of disabling the use of single-DES enctypes must be available before then, in addition to other transition strategies. Mailing list discussion implies that using a single switch is to coarse for orderly transition, but there also should not be too many new knobs. Implementation timeline is the krb5-1.7 release.
Transition strategies include
- Configuration option to completely disable the use of single-DES enctypes. This is a rather large hammer.
- Make kadmind default to not creating long-term keys with single-DES enctypes.
- KDC will move single-DES enctypes listed in a request to the end of the list. If a client requests any enctype that is stronger than single-DES, it will be considered before any single-DES enctypes for the purposes of session key selection and reply encryption.
- Provide a facility for listing enctype preferences in the KDB without providing a key. This will allow the use of an enctype for session keys but not expose a long-term key to attack.
Contents
Configuration to disable weak crypto
The allow_weak_crypto libdefault boolean (which aligns with Heimdal) will control whether "weak" crypto is allowed. The crypto library will gain an internal API, krb5_c_weak_enctype(), which will indicate whether a given enctype is "weak". The krb5_keytypes structure will have a flags word that will contain a bit indicating whether a given enctype is weak.
A future project, enctype config enhancements, will make it possible to implement this sort of enctype policy in a more generalized way.
De-prioritize single-DES in session key selection
Lowering the priority of single-DES in session key selection has few side effects. If a client requests both DES and stronger enctypes, it supports the stronger enctypes.
Default to not creating weak keys
Changing the kadmind defaults to stop creating single-DES keys could cause problems for users who are still using old software not capable of stronger ciphers. Changing the default for new service keys is more tractable. (A service is unlikely to use software of mixed capabilities.)
Separate supported_enctypes lists for services and clients are possible, but it is not clear that this additional complexity is desired.
Pure enctype preferences in KDB
Key lists in the KDB serve a dual purpose. They provide multiple keys for the purpose of supporting users who may use multiple versions of client software with differing enctype capabilities. They also indicate what session key enctypes are acceptable. Key data entries for a principal in the KDB could use zero-length keys to represent pure enctype preferences. Alternatively, a separate session key enctype preference list could exist on a per-principal basis.
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 discussion. Use standard talk page conventions. In particular, sign comments with
- --~~~~
and indent replies.
Members of Krbcore raising Blocking objections should preface their comment with {{project-block}}. The member who raised the objection should remove this markup when their objection is handled.
