Deriving Keys From TLS for Kerberos V5
Simon Josefsson Datakonsult AB
Hagagatan 24Stockholm113 47Swedensimon@josefsson.orghttp://josefsson.org/This document describes how clients can use the Kerberos V5
over TLS protocol together with its long term key to 1) avoid
having to validate the server certificate, 2) securely learn a
KDC's server certificate, and 3) learn the trust anchors used
by the KDC.We also describe how the Kerberos V5 over TLS protocol can be
used to 4) avoid the need for a long term shared key between
the client and the KDC by instead using TLS client
authentication.These goals are achieved by introducing a new Kerberos V5
pre-authentication type that modify how the Kerberos V5 reply
key is derived.This document describes a Kerberos
V5 pre-authentication type that
uses Kerberos
V5 over TLS to achieve:The ability to use Kerberos V5 over TLS without having to
validate the server certificates.Allow Kerberos V5 clients to securely learn a Kerberos V5
realm's Key Distribution Center (KDC) certificates.Securely distribute the trust anchors used by the Key
Distribution Center (KDC) in a Kerberos V5 realm.These goals are achieved by having the client connect to a
KDC without verifying the server certificates, take a note of
the server certificate and the certificate chain, and verify
them as belonging to the KDC the client trusts by properly
decrypting the Kerberos V5 response using the clients long
term key. Only the correct KDC will be able to generate a
Kerberos V5 response using the clients long-term key and the
secrets derived from the TLS
channel.The document also describes a mechanism to achieve:Allow use of Kerberos V5 without a long-term shared
secret between the client and the KDC.This goal is achieved by having the client authenticate
itself using TLS, and having the KDC request that the client
send a PA-ENC-TIMESTAMP pre-authentication data encrypted
using a key derived from the TLS channel. If successful, the
KDC will encrypt the response using a reply key derived only
from the TLS channel.This document requires that both the client and the KDC MUST
support Kerberos
V5 over TLS.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.The following function Krb5KeyFromTLS is used to derive keys
from a TLS session. This builds on
the Keying Material
Exporters for Transport Layer Security (TLS) framework
and uses functions defined
in Encryption and Checksum
Specifications for Kerberos 5.The PA-TLS pre-authentication type is sent by the client to a
KDC. It requests that the server uses a different Kerberos V5
reply key. If the "only-tls" flag is true, the reply key will
be derived from only the TLS session. If the "only-tls" flag
is false, the key will be derived from both the TLS session
and the the client long-term key. The exact semantic is
described in sub-sequent sections.The syntax of PA-TLS is defined as follows.The client choses the encryption type to
use. Kerberos V5 mandates
support
for AES256-CTS-HMAC-SHA1-96. If
the client do not have out of band information to use another
encryption type, clients MUST use AES256-CTS-HMAC-SHA1-96.The key used to encrypt the PA-TLS-ENC is derived using
Krb5KeyFromTLS with the following input:The server process an PA-TLS by verifying that the encryption
type is acceptable. If this fails, the server MAY respond
with a PA-ETYPE-INFO-TLS as defined below. The server proceed
and derive the keys and decrypt the PA-TLS. If this fails,
the server MUST respond with a KDC_ERR_PREAUTH_FAILED
error.When the PA-TLS is successfully decrypted, the KDC needs to
decide whether to honor the request or not. This is a policy
decision that can depend on several reasons, including the
content of the request.When the "tls-only" flag is true, the server MUST verify that
TLS has authenticated the client (e.g., by a X.509 client
certificate, OpenPGP key, or SRP password). The KDC may
perform policy checks whether a particular client should be
allowed to use this pre-authentication type.If for any reason the server decides that it does not wish to
accept the PA-TLS request, the server MUST fail the request by
returning KDC_ERR_PREAUTH_FAILED.An PA-ETYPE-INFO-TLS message is used by the KDC to demand
that a client sends a PA-TLS. The PA-ETYPE-INFO-TLS contains,
by the KDC, acceptable encryption types. The
PA-ETYPE-INFO-TLS message can be used by a KDC to require that
clients uses PA-TLS, or to require that clients send a PA-TLS
using some particular encryption types.The PA-ETYPE-INFO-TLS is used as follows. The KDC sends a
KRB-ERROR packet with the KDC_ERR_PREAUTH_REQUIRED error-code
and store a METHOD-DATA containing an PA-ETYPE-INFO-TLS in the
e-data field.The client responds by sending a PA-TLS encrypted using one
of the indicated types, or fail for policy reasons (e.g., none
of the proposed encryption types are acceptable).If the client do not have the required information needed to
verify a server certificate, it will delay verification of the
server certificate. The server MUST include a root
certificate in the TLS certificate_list.The client sends a PA-TLS type with the "tls-only" flag set
to FALSE. The server process the PA-TLS as described earlier.
On success, the server process the incoming requests as usual
except that any KDC-REP reply key is post processed using the
Krb5KeyFromTLS function with the following inputs:The client will strengthen its local KDC-REP reply key using
the same procedure. On successful decryption of the KDC-REP,
the clients is certain that it is talking to a KDC that knows
the client's shared key without any man-in-the-middle. The
client can then remember the server certificate and/or trust
anchors transferred during the TLS handshake, to be used
during future Kerberos V5 over TLS connections.If the client can securely store the information required to
validate the server in the future, the client MAY skip using
the PA-TLS for future connections, and instead rely on the
standard Kerberos V5 over TLS protocol with proper validation
of server certificate.The client can use TLS to authenticate it, and then ask the
KDC to use the TLS authentication to authenticate the Kerberos
request. The latter step is performed by sending a PA-TLS
type with "only-tls" set to TRUE.The server process the PA-TLS as described earlier. On
success, the server process the incoming Kerberos requests as
usual except that the KDC-REP reply key will be generated by
Krb5KeyFromTLS with the following inputs:The client derives the key the same way, and will be able to
decrypt the response.Note that this means the long term shared key will not be
involved in deriving the reply that protects the Kerberos V5
response.(The reason for encrypting the response is because Kerberos
V5 does not have any null encryption scheme.)The IANA is requested to allocate the strings "Kerberos
pre-auth key", "Kerberos strengthen key", and "Kerberos derive
key" in the TLS Exporter label registry.Nicolas Williams mentioned the advantages in
<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and
suggested the use of (what became) PA-TLS.The security considerations
in Kerberos V5,
TLS, Kerberos
V5 TCP extension,
and Kerberos
V5 over TLS are inherited.By request PA-TLS with only-tls set to TRUE the client's
long-term key is no longer involved in deriving the Kerberos
V5 ticket. Instead only the authentication from the TLS
channel is used. This changes the cryptographic model of
Kerberos V5 significantly, and makes it possible to operate
Kerberos V5 without even having a long term shared key for a
particular user. This changes how a Kerberos V5 security
analysis should be made, so be aware of this model change when
reading other literature.