.. _enctypes:

Encryption types

================

Kerberos can use a variety of cipher algorithms to protect data.  A

Kerberos **encryption type** (also known as an **enctype**) is a

specific combination of a cipher algorithm with an integrity algorithm

to provide both confidentiality and integrity to data.

Enctypes in requests

--------------------

Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and

TGS-REQs.  The client uses the AS-REQ to obtain initial tickets

(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to

obtain service tickets.

The KDC uses three different keys when issuing a ticket to a client:

* The long-term key of the service: the KDC uses this to encrypt the

  actual service ticket.  The KDC only uses the first long-term key in

  the most recent kvno for this purpose.

* The session key: the KDC randomly chooses this key and places one

  copy inside the ticket and the other copy inside the encrypted part

  of the reply.

* The reply-encrypting key: the KDC uses this to encrypt the reply it

  sends to the client.  For AS replies, this is a long-term key of the

  client principal.  For TGS replies, this is either the session key of the

  authenticating ticket, or a subsession key.

Each of these keys is of a specific enctype.

Each request type allows the client to submit a list of enctypes that

it is willing to accept.  For the AS-REQ, this list affects both the

session key selection and the reply-encrypting key selection.  For the

TGS-REQ, this list only affects the session key selection.

.. _session_key_selection:

Session key selection

---------------------

The KDC chooses the session key enctype by taking the intersection of

its **permitted_enctypes** list, the list of long-term keys for the

most recent kvno of the service, and the client's requested list of

enctypes.

Starting in krb5-1.11, it is possible to set a string attribute on a

service principal to control what session key enctypes the KDC may

issue for service tickets for that principal.  See :ref:`set_string`

in :ref:`kadmin(1)` for details.

Choosing enctypes for a service

-------------------------------

Generally, a service should have a key of the strongest

enctype that both it and the KDC support.  If the KDC is running a

release earlier than krb5-1.11, it is also useful to generate an

additional key for each enctype that the service can support.  The KDC

will only use the first key in the list of long-term keys for encrypting

the service ticket, but the additional long-term keys indicate the

other enctypes that the service supports.

As noted above, starting with release krb5-1.11, there are additional

configuration settings that control session key enctype selection

independently of the set of long-term keys that the KDC has stored for

a service principal.

Configuration variables

-----------------------

The following ``[libdefaults]`` settings in :ref:`krb5.conf(5)` will

affect how enctypes are chosen.

**allow_weak_crypto**

    defaults to *false* starting with krb5-1.8.  When *false*, removes

    weak enctypes from **permitted_enctypes**,

    **default_tkt_enctypes**, and **default_tgs_enctypes**.  Do not

    set this to *true* unless the use of weak enctypes is an

    acceptable risk for your environment and the weak enctypes are

    required for backward compatibility.

**permitted_enctypes**

    controls the set of enctypes that a service will permit for

    session keys and for ticket and authenticator encryption.  The KDC

    and other programs that access the Kerberos database will ignore

    keys of non-permitted enctypes.  Starting in release 1.18, this

    setting also acts as the default for **default_tkt_enctypes** and

    **defaut_tgs_enctypes**.

**default_tkt_enctypes**

    controls the default set of enctypes that the Kerberos client

    library requests when making an AS-REQ.  Do not set this unless

    required for specific backward compatibility purposes; stale

    values of this setting can prevent clients from taking advantage

    of new stronger enctypes when the libraries are upgraded.

**default_tgs_enctypes**

    controls the default set of enctypes that the Kerberos client

    library requests when making a TGS-REQ.  Do not set this unless

    required for specific backward compatibility purposes; stale

    values of this setting can prevent clients from taking advantage

    of new stronger enctypes when the libraries are upgraded.

The following per-realm setting in :ref:`kdc.conf(5)` affects the

generation of long-term keys.

**supported_enctypes**

    controls the default set of enctype-salttype pairs that :ref:`kadmind(8)`

    will use for generating long-term keys, either randomly or from

    passwords

Enctype compatibility

---------------------

See :ref:`Encryption_types` for additional information about enctypes.

========================== ===== ======== =======

enctype                    weak? krb5     Windows

========================== ===== ======== =======

des-cbc-crc                weak  <1.18    >=2000

des-cbc-md4                weak  <1.18    ?

des-cbc-md5                weak  <1.18    >=2000

des3-cbc-sha1                    <1.18    none

arcfour-hmac                     >=1.3    >=2000

arcfour-hmac-exp           weak  >=1.3    >=2000

aes128-cts-hmac-sha1-96          >=1.3    >=Vista

aes256-cts-hmac-sha1-96          >=1.3    >=Vista

aes128-cts-hmac-sha256-128       >=1.15   none

aes256-cts-hmac-sha384-192       >=1.15   none

camellia128-cts-cmac             >=1.9    none

camellia256-cts-cmac             >=1.9    none

========================== ===== ======== =======

krb5 releases 1.8 and later disable the single-DES enctypes by

default.  Microsoft Windows releases Windows 7 and later disable

single-DES enctypes by default.

krb5 releases 1.18 and later remove single-DES and 3DES

(downstream-only patch) enctype support.  Microsoft Windows never

supported 3DES.