Pre-authentication for Kerberos services

Tailor-Made

SPAKE and Diffie-Hellmann

Simple password-based encrypted key exchange (SPAKE) [4][5] is a fairly recent pre-authentication method supported by MIT Kerberos version 1.17 or newer. It is based on an asymmetric Diffie-Hellmann key exchange [6], but unlike PKINIT, no additional infrastructure in the form of a public key infrastructure (PKI) is required.

Since MIT Kerberos version 1.14, the library has also supported "authentication indicators." You can use these to define requirements for the strength of the initial user login, if needed, before the user is ultimately given a Kerberos service ticket. Therefore, you can meet the security requirements of various systems by requiring more or less strong authentication as a function of the system. In the /var/kerberos/krb5kdc/kdc.conf KDC configuration file you simply define different labels for the pre-authentication methods:

pkinit_indicator = pkinit
spake_preauth_indicator = spake
encrypted_challenge_indicator = fast

You then apply these labels to the different service principals. For example, if you want to issue a Kerberos service ticket for an SSH bastion host on the condition that the user uses the PKINIT pre-authentication method during the initial login, you can set the label for the principal as follows:

kadmin setstr host/ssh-bastion.example.com require_auth pkinit

If you now only use a password for the initial login and then try to get a service ticket for the host with kvno, the attempt will fail:

kinit tscherf
Password for tscherf@EXAMPLE.COM
kvno host/ssh-bastion.example.com
kvno: KDC policy rejects request while getting credentials for host/ssh-bastion.example.com@EXAMPLE.COM

However, if you use PKINIT for the initial login,

kinit -X X509_user_identity='FILE:/tmp/tscherf.pem' tscherf
kvno host/ssh-bastion.example.com
host/ssh-bastion.example.com@EXAMPLE.COM: kvno = 1

you are given the desired service ticket for the SSH host.

Conclusions

Thanks to authentication indicators, Kerberos now offers granular control of the pre-authentication method a user needs to use to gain access to a particular Kerberos service. Depending on how security-critical a service is, it can make sense, for example, only to grant access if FAST or SPAKE were used for the initial login.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Password management with FreeIPA
    Passwords should be safe, but easy to remember – a contradiction that can be difficult to resolve. One remedy is a password manager that stores all passwords centrally. The open source tip this month shows a different approach: FreeIPA.
  • A REST interface for FreeIPA
    Access to the FreeIPA identity management framework is usually handled via a graphical web interface or a command-line tool, but the framework can also be queried directly via the JSON-RPC API.
  • Protect privileged accounts in AD
    Granular protection for highly privileged accounts is granted by the Protected Users group in Active Directory and Kerberos authentication policies.
  • Integrating FreeIPA with Active Directory
    Many companies use Active Directory for centrally managing existing systems, but if you mix in Linux systems, you have to take care of a few things, such as different forms of integration. We show you how to connect the FreeIPA identity management framework as an interface to an Active Directory domain.
  • Migration from LDAP to FreeIPA
    The change from centralized user authentication on a vanilla LDAP server to the FreeIPA identity management solution is easier than many admins think. Given attention to a few points, the migration takes very little time and effort.
comments powered by Disqus