One document matched: draft-josefsson-krb5starttls-bootstrap-02.txt
Differences from draft-josefsson-krb5starttls-bootstrap-01.txt
Network Working Group S. Josefsson
Internet-Draft SJD AB
Updates: 4120 (if approved) March 6, 2009
Intended status: Standards Track
Expires: September 7, 2009
Deriving Keys From TLS for Kerberos V5
draft-josefsson-krb5starttls-bootstrap-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes how clients can use the Kerberos V5 over TLS
protocol together with its long term key to 1) avoid having to
Josefsson Expires September 7, 2009 [Page 1]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
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.
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . . 3
2. The Krb5KeyFromTLS Function . . . . . . . . . . . . . . . . . . 3
3. The PA-TLS Pre-Authentication Type . . . . . . . . . . . . . . 4
4. Reply Key Strengthening . . . . . . . . . . . . . . . . . . . . 6
5. Avoiding Use Of Long-Term Shared Key . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Josefsson Expires September 7, 2009 [Page 2]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
1. Introduction and Background
This document describes a Kerberos V5 [RFC4120] pre-authentication
type that uses Kerberos V5 over TLS
[I-D.josefsson-kerberos5-starttls] to achieve:
o The ability to use Kerberos V5 over TLS without having to validate
the server certificates.
o Allow Kerberos V5 clients to securely learn a Kerberos V5 realm's
Key Distribution Center (KDC) certificates.
o 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 [RFC5246].
The document also describes a mechanism to achieve:
o 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 [I-D.josefsson-kerberos5-starttls].
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 [RFC2119].
2. The Krb5KeyFromTLS Function
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) [I-D.ietf-tls-extractor] framework and
uses functions defined in Encryption and Checksum Specifications for
Kerberos 5 [RFC3961].
Josefsson Expires September 7, 2009 [Page 3]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
Krb5KeyFromTLS (ltkey, ltkey_len,
tlscb, tlscb_len,
enctype,
label)
Input: ltkey long term key,
an octet string
ltkey_len length of long term key,
an integer larger or equal to 0
tlscb channel binding data,
an octet string
tlscb_len length of channel binding data,
a positive integer
etype number assigned for an encryption type
label the TLS PRF label to use,
a IANA registered string
Output: protkey derived protocol-key
Steps:
1. Set "length" to the key-generation seed length, K, for the
encryption type "enctype" as per RFC 3961.
2. Set "context_value" to the concatenation of "ltkey" followed
by "tlscb". Note that "ltkey" may be empty.
3. Derive the value for "context_value_length" from the sum of
"ltkey_len" and "tlscb_len".
4. Perform the TLS Exporter step:
outkey = PRF(master_secret, label,
SecurityParameters.client_random +
SecurityParameters.server_random +
context_value_length + context_value
)[length]
5. Output random-to-key(outkey). The random-to-key function is
defined in RFC 3961.
3. The PA-TLS Pre-Authentication Type
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
Josefsson Expires September 7, 2009 [Page 4]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
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.
PA-TLS ::= EncryptedData -- PA-TLS-ENC
PA-TLS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL,
only-tls [2] BOOLEAN
}
The client choses the encryption type to use. Kerberos V5 [RFC4120]
mandates support for AES256-CTS-HMAC-SHA1-96 [RFC3962]. 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:
ltkey: empty string
ltkey_len: 0
tlscb: the client's TLS Finished message data,
as described in the "tls-unique" channel binding
registration.
tlscb_len: length of "tlscb".
etype: the encryption type number chosen by the client
label: "Kerberos pre-auth key"
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
Josefsson Expires September 7, 2009 [Page 5]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
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.
PA-ETYPE-INFO-TLS ::= SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
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).
4. Reply Key Strengthening
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:
ltkey: client long term key in protocol-key format
ltkey_len: length of "ltkey"
tlscb: the client's TLS Finished message data,
as described in the "tls-unique" channel binding
registration.
tlscb_len: length of "tlscb".
etype: encryption type number of client long-term key
label: "Kerberos strengthen key"
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.
Josefsson Expires September 7, 2009 [Page 6]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
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.
5. Avoiding Use Of Long-Term Shared Key
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:
ltkey: empty string
ltkey_len: 0
tlscb: the client's TLS Finished message data,
as described in the "tls-unique" channel binding
registration.
tlscb_len: length of "tlscb".
etype: encryption type used for the PA-TLS
label: "Kerberos derive key"
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.)
6. IANA Considerations
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.
7. Acknowledgements
Nicolas Williams mentioned the advantages in
<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and suggested
Josefsson Expires September 7, 2009 [Page 7]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
the use of (what became) PA-TLS.
8. Security Considerations
The security considerations in Kerberos V5 [RFC4120], TLS [RFC5246],
Kerberos V5 TCP extension [RFC5021], and Kerberos V5 over TLS
[I-D.josefsson-kerberos5-starttls] 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.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[I-D.josefsson-kerberos5-starttls]
Josefsson, S., "Using Kerberos V5 over the Transport Layer
Security (TLS) protocol",
draft-josefsson-kerberos5-starttls-04 (work in progress),
December 2008.
[I-D.ietf-tls-extractor]
Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", draft-ietf-tls-extractor-04 (work
in progress), February 2009.
Josefsson Expires September 7, 2009 [Page 8]
Internet-Draft Deriving Keys From TLS for Kerberos V5 March 2009
9.2. Informative References
[RFC5021] Josefsson, S., "Extended Kerberos Version 5 Key
Distribution Center (KDC) Exchanges over TCP", RFC 5021,
August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Author's Address
Simon Josefsson
Simon Josefsson Datakonsult AB
Hagagatan 24
Stockholm 113 47
Sweden
Email: simon@josefsson.org
URI: http://josefsson.org/
Josefsson Expires September 7, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-21 07:50:37 |