1.. _enctypes: 2 3Encryption types 4================ 5 6Kerberos can use a variety of cipher algorithms to protect data. A 7Kerberos **encryption type** (also known as an **enctype**) is a 8specific combination of a cipher algorithm with an integrity algorithm 9to provide both confidentiality and integrity to data. 10 11 12Enctypes in requests 13-------------------- 14 15Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and 16TGS-REQs. The client uses the AS-REQ to obtain initial tickets 17(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to 18obtain service tickets. 19 20The KDC uses three different keys when issuing a ticket to a client: 21 22* The long-term key of the service: the KDC uses this to encrypt the 23 actual service ticket. The KDC only uses the first long-term key in 24 the most recent kvno for this purpose. 25 26* The session key: the KDC randomly chooses this key and places one 27 copy inside the ticket and the other copy inside the encrypted part 28 of the reply. 29 30* The reply-encrypting key: the KDC uses this to encrypt the reply it 31 sends to the client. For AS replies, this is a long-term key of the 32 client principal. For TGS replies, this is either the session key of the 33 authenticating ticket, or a subsession key. 34 35Each of these keys is of a specific enctype. 36 37Each request type allows the client to submit a list of enctypes that 38it is willing to accept. For the AS-REQ, this list affects both the 39session key selection and the reply-encrypting key selection. For the 40TGS-REQ, this list only affects the session key selection. 41 42 43.. _session_key_selection: 44 45Session key selection 46--------------------- 47 48The KDC chooses the session key enctype by taking the intersection of 49its **permitted_enctypes** list, the list of long-term keys for the 50most recent kvno of the service, and the client's requested list of 51enctypes. Starting in krb5-1.21, all services are assumed to support 52aes256-cts-hmac-sha1-96; also, des3-cbc-sha1 and arcfour-hmac session 53keys will not be issued by default. 54 55Starting in krb5-1.11, it is possible to set a string attribute on a 56service principal to control what session key enctypes the KDC may 57issue for service tickets for that principal, overriding the service's 58long-term keys and the assumption of aes256-cts-hmac-sha1-96 support. 59See :ref:`set_string` in :ref:`kadmin(1)` for details. 60 61 62Choosing enctypes for a service 63------------------------------- 64 65Generally, a service should have a key of the strongest 66enctype that both it and the KDC support. If the KDC is running a 67release earlier than krb5-1.11, it is also useful to generate an 68additional key for each enctype that the service can support. The KDC 69will only use the first key in the list of long-term keys for encrypting 70the service ticket, but the additional long-term keys indicate the 71other enctypes that the service supports. 72 73As noted above, starting with release krb5-1.11, there are additional 74configuration settings that control session key enctype selection 75independently of the set of long-term keys that the KDC has stored for 76a service principal. 77 78 79Configuration variables 80----------------------- 81 82The following ``[libdefaults]`` settings in :ref:`krb5.conf(5)` will 83affect how enctypes are chosen. 84 85**allow_weak_crypto** 86 defaults to *false* starting with krb5-1.8. When *false*, removes 87 weak enctypes from **permitted_enctypes**, 88 **default_tkt_enctypes**, and **default_tgs_enctypes**. Do not 89 set this to *true* unless the use of weak enctypes is an 90 acceptable risk for your environment and the weak enctypes are 91 required for backward compatibility. 92 93**allow_des3** 94 was added in release 1.21 and defaults to *false*. Unless this 95 flag is set to *true*, the KDC will not issue tickets with 96 des3-cbc-sha1 session keys. In a future release, this flag will 97 control whether des3-cbc-sha1 is permitted in similar fashion to 98 weak enctypes. 99 100**allow_rc4** 101 was added in release 1.21 and defaults to *false*. Unless this 102 flag is set to *true*, the KDC will not issue tickets with 103 arcfour-hmac session keys. In a future release, this flag will 104 control whether arcfour-hmac is permitted in similar fashion to 105 weak enctypes. 106 107**permitted_enctypes** 108 controls the set of enctypes that a service will permit for 109 session keys and for ticket and authenticator encryption. The KDC 110 and other programs that access the Kerberos database will ignore 111 keys of non-permitted enctypes. Starting in release 1.18, this 112 setting also acts as the default for **default_tkt_enctypes** and 113 **default_tgs_enctypes**. 114 115**default_tkt_enctypes** 116 controls the default set of enctypes that the Kerberos client 117 library requests when making an AS-REQ. Do not set this unless 118 required for specific backward compatibility purposes; stale 119 values of this setting can prevent clients from taking advantage 120 of new stronger enctypes when the libraries are upgraded. 121 122**default_tgs_enctypes** 123 controls the default set of enctypes that the Kerberos client 124 library requests when making a TGS-REQ. Do not set this unless 125 required for specific backward compatibility purposes; stale 126 values of this setting can prevent clients from taking advantage 127 of new stronger enctypes when the libraries are upgraded. 128 129The following per-realm setting in :ref:`kdc.conf(5)` affects the 130generation of long-term keys. 131 132**supported_enctypes** 133 controls the default set of enctype-salttype pairs that :ref:`kadmind(8)` 134 will use for generating long-term keys, either randomly or from 135 passwords 136 137 138Enctype compatibility 139--------------------- 140 141See :ref:`Encryption_types` for additional information about enctypes. 142 143========================== ========== ======== ======= 144enctype weak? krb5 Windows 145========================== ========== ======== ======= 146des-cbc-crc weak <1.18 >=2000 147des-cbc-md4 weak <1.18 ? 148des-cbc-md5 weak <1.18 >=2000 149des3-cbc-sha1 deprecated >=1.1 none 150arcfour-hmac deprecated >=1.3 >=2000 151arcfour-hmac-exp weak >=1.3 >=2000 152aes128-cts-hmac-sha1-96 >=1.3 >=Vista 153aes256-cts-hmac-sha1-96 >=1.3 >=Vista 154aes128-cts-hmac-sha256-128 >=1.15 none 155aes256-cts-hmac-sha384-192 >=1.15 none 156camellia128-cts-cmac >=1.9 none 157camellia256-cts-cmac >=1.9 none 158========================== ========== ======== ======= 159 160krb5 releases 1.18 and later do not support single-DES. krb5 releases 1611.8 and later disable the single-DES enctypes by default. Microsoft 162Windows releases Windows 7 and later disable single-DES enctypes by 163default. 164 165krb5 releases 1.17 and later flag deprecated encryption types 166(including ``des3-cbc-sha1`` and ``arcfour-hmac``) in KDC logs and 167kadmin output. krb5 release 1.19 issues a warning during initial 168authentication if ``des3-cbc-sha1`` is used. Future releases will 169disable ``des3-cbc-sha1`` by default and eventually remove support for 170it. 171 172 173Migrating away from older encryption types 174------------------------------------------ 175 176Administrator intervention may be required to migrate a realm away 177from legacy encryption types, especially if the realm was created 178using krb5 release 1.2 or earlier. This migration should be performed 179before upgrading to krb5 versions which disable or remove support for 180legacy encryption types. 181 182If there is a **supported_enctypes** setting in :ref:`kdc.conf(5)` on 183the KDC, make sure that it does not include weak or deprecated 184encryption types. This will ensure that newly created keys do not use 185those encryption types by default. 186 187Check the ``krbtgt/REALM`` principal using the :ref:`kadmin(1)` 188**getprinc** command. If it lists a weak or deprecated encryption 189type as the first key, it must be migrated using the procedure in 190:ref:`changing_krbtgt_key`. 191 192Check the ``kadmin/history`` principal, which should have only one key 193entry. If it uses a weak or deprecated encryption type, it should be 194upgraded following the notes in :ref:`updating_history_key`. 195 196Check the other kadmin principals: kadmin/changepw, kadmin/admin, and 197any kadmin/hostname principals that may exist. These principals can 198be upgraded with **change_password -randkey** in kadmin. 199 200Check the ``K/M`` entry. If it uses a weak or deprecated encryption 201type, it should be upgraded following the procedure in 202:ref:`updating_master_key`. 203 204User and service principals using legacy encryption types can be 205enumerated with the :ref:`kdb5_util(8)` **tabdump keyinfo** command. 206 207Service principals can be migrated with a keytab rotation on the 208service host, which can be accomplished using the :ref:`k5srvutil(1)` 209**change** and **delold** commands. Allow enough time for existing 210tickets to expire between the change and delold operations. 211 212User principals with password-based keys can be migrated with a 213password change. The realm administrator can set a password 214expiration date using the :ref:`kadmin(1)` **modify_principal 215-pwexpire** command to force a password change. 216 217If a legacy encryption type has not yet been disabled by default in 218the version of krb5 running on the KDC, it can be disabled 219administratively with the **permitted_enctypes** variable. For 220example, setting **permitted_enctypes** to ``DEFAULT -des3 -rc4`` will 221cause any database keys of the triple-DES and RC4 encryption types to 222be ignored. 223