Notes about Linux authentication and authorization

Kerberos (130915)

Kerberos is a nearly pure authentication system based on:

• Symmetric keys.
• Distributed operation.
• A central key repository.
• An authentication protocol and an administration protocol.
• Encryption of both protocols.
• Distinction between long term keys and temporary keys.
• A very wide variety of encryption types, options and modes of operation.

The only authorization aspect is in the administrative protocol, to delimit the authority of system administrators.

There are at least these implementations of Kerberos:

• MIT Kerberos.
• Heimdal.
• Shishi.
• AD Kerberos.

There are some disparate tables in the documentation and elsewhere on enctypes and salt types (1, 2, 3, 4) here is a merged table:

Auth hints for passwd (120812)

• MD5 password hashing is known to be easily defeatable.

Auth hints for Kerberos (130119)

• In general it is not worth enabling addresses in Kerberos tickets, as their value depends on there being no NAT, on multihomed hosts being carefully configured in DNS, and in having a fully secured forward and reverse DNS name resolution, and the latter is particularly rare.
• Proxiable tickets are essentially never used, so they probably should be disabled by default.
• In most cases forwardable tickets are not needed, and can be requested specifically with kinit -f if needed, so probably they should be disabled by default.
• Kerberos realm names are case sensitive, unlike DNS names, so there is a problem when matching DNS names with realm names. The convention is that there is a default mapping from DNS names to all upper case realm names, so the convention is to use all upper case realm names that with the same spelling as related DNS name.
  Also AFS cell names are case insentitive, and are usually written all lower case and with the same spelling as the related DNS name. There is a default mapping from all lower case cell names to all upper case realm names.
  Even if in theory there is more flexibility, complications can happen in a setup that chooses related DNS names, realm names, and cell names with the same spelling (which is highly recommended), unless by convention DNS names in configuration files are all lower case, Kerberos realm names are all upper case, and AFS cell names are all lower case.

Auth hints for MIT Kerberos (210726)

Version dependent:

• In version 1.18 (as reported) the Kerberos client library will Expand single-component hostnames in host-based principal names when DNS canonicalization is not used, adding the system's first DNS search path as a suffix.
• In version 1.14 and later specific keys can be tagged with flag e to mark them extractable without kvno increment allowing the same functionality as kadmin.local's ktadd -norandkey which has been removed.
• In version 1.11 and later des_crc_session_supported can be used to enable or disable the KDC to issue des-cbc-src sessions keys.
• In version 1.11 and later it is possible to set an attribute of a principal to the list of enctypes for the session keys to be issued by the KDC for that principal.
• In Kerberos versions before 1.10.2 (or before 1.9.4) a bug in getaddrinfo in GNU LIBC makes it impossible to effectively turns off the rdns setting, as reverse DNS lookups are done regardless. This can be a significant security risk unless reverse DNS is properly signed.
• Version 1.11 and later have the enctypes camellia128-cts-cmac and camellia256-cts-cmac which are not supported by MS-Windows. These types were added experimentally in 1.9 but they did not have official numbers yet and disabled by default.
• Version 1.8 and later disable the weak DES enctypes unless allow_weak_crypto is enabled in krb5.conf.
• Version 1.8 and later allow specifying enctypes by family (des, des3, aes, rc4).
• Version 1.3.2 and later of the GSSAPI library support the aes-cts enctypes.
• Version 1.2.1 and later support the -norandkey option to kadmin.local which allows exporting the current keytab entry without generating a new key.

Version independent:

• When extracting keytab entries using kadmin the kvno is incremented as a new key instance is created, which means that previous keytab entries need to be updated, because all keytab entries and tickets with previous kvnos are now invalid. In effect in kadmin the command ktadd is a variant of chpw -randkey.
• When changing the password on a principal a new key instance is created, and the previous one is deleted, unless -keepold is specified with cpw.
• When the KDC has to choose a key for a principal, by default it will get the key with the highest kvno and will pick the first enctype associated with the key, where first is the one listed first by getprinc, which is the enctype listed first in supported_enctypes when the key with that kvno was created.
• The salt type :normal prints as none in several messages; other types are no longer much used:

  <geekosaur> afs3 would be only used if you needed compatibility with a kaserver, and v4 only if you need compatibility with kerberos 4; there are significant security holes with both, so not at all recommended