One document matched: draft-josefsson-krb5starttls-bootstrap-01.txt
Differences from draft-josefsson-krb5starttls-bootstrap-00.txt
Network Working Group S. Josefsson
Internet-Draft SJD AB
Updates: 4120 (if approved) March 3, 2009
Intended status: Standards Track
Expires: September 4, 2009
Kerberos V5 Reply Keys From TLS
draft-josefsson-krb5starttls-bootstrap-01
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 4, 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.
Josefsson Expires September 4, 2009 [Page 1]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
Abstract
This document describes how the Kerberos V5 over TLS protocol
together with a users' long term shared secret can be used to 1)
allow clients to securely learn a realm's KDC X.509 certificate, 2)
distribute the X.509 trust anchors used by the KDC, and 3) make it
possible for clients to use Kerberos V5 over TLS without having to
validate the server certificates.
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 user and the
KDC by instead using TLS user authentication.
This goals are achieved by introducing two new Kerberos V5 pre-
authentication mechanisms that modify how the Kerberos V5 reply key
is derived.
Josefsson Expires September 4, 2009 [Page 2]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 4
2. TLS Exporter Function . . . . . . . . . . . . . . . . . . . . 5
3. Reply Key Strengthening . . . . . . . . . . . . . . . . . . . 6
4. Avoiding Use Of Long-Term Shared Key . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Josefsson Expires September 4, 2009 [Page 3]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
1. Introduction and Background
This document describes a Kerberos V5 [RFC4120] pre-authentication
mechanism that uses Kerberos V5 over TLS
[I-D.josefsson-kerberos5-starttls] to achieve:
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.
o The ability to use Kerberos V5 over TLS without having to validate
the server certificates.
These goals are achieved by having the client connect to a KDC, take
a note of the server's certificate, and verify them as belonging to
the KDC the user trusts by properly decrypting the Kerberos V5
response using the user's password. Only the correct KDC will be
able to generate a Kerberos V5 response using the user's password and
the secrets derived from the TLS channel.
The mechanism to achieve the above goals is for the KDC to strengthen
the Kerberos V5 reply key using keying material derived from the TLS
channel [RFC5246] using the algorithm specified in Keying Material
Exporters for Transport Layer Security (TLS)
[I-D.ietf-tls-extractor].
The document also describes a pre-authentication mechanism that can
be used to achieve:
o Allow use of Kerberos V5 without a long-term shared secret between
the user 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].
Josefsson Expires September 4, 2009 [Page 4]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
2. TLS Exporter Function
The following function Krb5KeyFromTLS is used elsewhere to derive
keys from a TLS session.
Krb5KeyFromTLS (inkey, inkey_len, tlscb, tlscb_len, length, label)
Input: inkey encryption key, an octet string
inkey_len length of encryption key,
a positive integer
tlscb channel binding data, an octet string,
tlscb_len length of channel binding data,
a positive integer
length number of bytes to derive,
a positive integer
label the TLS PRF label to use,
a IANA registered string
Output: outkey derived key, an "length"-octet string
Steps:
1. Perform the TLS Exporter step:
outkey = PRF(master_secret, label,
SecurityParameters.client_random +
SecurityParameters.server_random +
context_value_length + context_value
)[length]
The "context_value" should be the concatenation of "inkey"
followed by "tlscb".
Consequently, the length of "context_value" (which used to
derived "context_value_length") will be the sum of
"inkey_len" and "tlscb_len".
The values of "length" and "label" are as the inputs to this
function.
3. Output the derived key "outkey".
Josefsson Expires September 4, 2009 [Page 5]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
3. Reply Key Strengthening
If the client do not (yet) have trust anchors for the KDC, it should
delay verification of the server certificate.
To signal that the client wishes the KDC to strengthen the reply key
using keying material derived from the TLS session, it sends a pre-
authentication mechanism called "pa-krb5starttls-strengthen". It has
a pdata-type integer value of #TBD.
The pre-authentication structure is defined in RFC 4120 as:
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] Int32,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
The content of the padata-value should be the DER encoding of the
empty string.
When receiving the request to use the "pa-krb5starttls-strengthen"
pre-authentication message, the KDC needs to decide whether to honor
it or not. This is a policy decision that can depend on several
reasons, including the content of the request. If the KDC decides
that it does not wish to honor the "pa-krb5starttls-strengthen"
request, the KDC MUST fail the request by returning
KDC_ERR_PREAUTH_FAILED.
When the KDC decides to honor the client's request, it will process
the incoming request as usual except that the KDC-REP reply key is
post processed. The post processing uses Keying Material Exporters
for Transport Layer Security (TLS) [I-D.ietf-tls-extractor], by
invoking the Krb5KeyFromTLS function with the following inputs:
inkey: user's long term shared secret
inkey_len: length of "inkey"
tlscb: the client's TLS Finished message data,
as described in the "tls-unique" channel binding
registration.
tlscb_len: length of "tlscb".
length: same as "inkey_len"
label: "Kerberos V5 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
Josefsson Expires September 4, 2009 [Page 6]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
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 KDC server
certificate and/or trust anchors transferred during the TLS
handshake, to be used during future Kerberos V5 over TLS connections.
The client MAY skip using this protocol for future connections, and
instead rely on the standard Kerberos V5 over TLS protocol with
proper validation of server certificate.
Josefsson Expires September 4, 2009 [Page 7]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
4. Avoiding Use Of Long-Term Shared Key
The ETYPE-INFO-TLS pre-authentication type is sent by the KDC in a
KRB-ERROR indicating a requirement for additional pre-authentication
before sending a reply protected using a key derived only from the
TLS session. It is used to notify a client of which encryption type
to use for the encryption of an encrypted timestamp for the purposes
of sending a PA-ENC-TIMESTAMP pre-authentication value using an
encryption key derived from the TLS session.
ETYPE-INFO-TLS ::= SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
The client choses a supported encryption type and re-send the request
with a PA-ENC-TIMESTAMP encrypted using a key derived from the TLS
session by using Krb5KeyFromTLS with the following input:
inkey: empty string
inkey_len: 0
tlscb: the client's TLS Finished message data,
as described in the "tls-unique" channel binding
registration.
tlscb_len: length of "tlscb".
length: key length of the chosen encryption type
label: "Kerberos V5 pre-auth key"
The KDC verifies the PA-ENC-TIMESTAMP and if successful it knows it
is talking to the authenticated user and can send a response
encrypted using the same encryption type as the client selected but
with a key derived using Krb5KeyFromTLS with the same inputs except
for:
label: "Kerberos V5 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.)
Josefsson Expires September 4, 2009 [Page 8]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
5. IANA Considerations
The IANA is requested to allocate the string "kerberos V5 reply key"
in the TLS Exporter label registry.
Josefsson Expires September 4, 2009 [Page 9]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
6. Acknowledgements
Nicolas Williams mentioned the advantages in
<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>, and also
suggested the use of PA-ENC-TIMESTAMP.
Josefsson Expires September 4, 2009 [Page 10]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
7. 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 using ETYPE-INFO-TLS the long-term shared key of the user 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.
Josefsson Expires September 4, 2009 [Page 11]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
8.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.
Josefsson Expires September 4, 2009 [Page 12]
Internet-Draft Kerberos V5 Reply Keys From TLS March 2009
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 4, 2009 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-21 07:49:48 |