One document matched: draft-josefsson-krb5starttls-bootstrap-00.txt
Network Working Group S. Josefsson
Internet-Draft SJD AB
Updates: 4120 (if approved) March 2, 2009
Intended status: Standards Track
Expires: September 3, 2009
Strengthening the Kerberos V5 Reply Key using TLS
draft-josefsson-krb5starttls-bootstrap-00
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 3, 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 3, 2009 [Page 1]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
Abstract
This document describes how to strengthen the Kerberos V5 reply key
using keying material derived from TLS, by using a pre-authentication
mechanism. The goals are 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.
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Josefsson Expires September 3, 2009 [Page 2]
Internet-Draft Kerberos V5 Reply Key Strengthening 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. This is 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.
o Securely distribute the trust anchors used by the Key Distribution
Center (KDC) in a Kerberos V5 realm. This is achieved the same
way as before, but rather than remembering the server certificate,
it remembers the trust anchor.
o The ability to use Kerberos V5 over TLS without having to validate
the server certificates.
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 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 3, 2009 [Page 3]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
2. Protocol
The client and KDC MUST support Kerberos V5 over TLS
[I-D.josefsson-kerberos5-starttls]. If the client do not (yet) have
trust anchors for the KDC, it should disable 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-bootstrap". 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-bootstrap"
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-bootstrap"
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 as follows. The post processing uses Keying Material
Exporters for Transport Layer Security (TLS)
[I-D.ietf-tls-extractor]. The channel binding input "tlscb" value
MUST be the client's TLS Finished message data as described in the
"tls-unique" channel binding registration.
Josefsson Expires September 3, 2009 [Page 4]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
StrengthenKrb5ReplyKeyUsingTLS (inkey, inkey_len,
tlscb, tlscb_len)
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
Output: outkey derived key, a inlen-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".
Use the value of "inkey_len" as the value of the "length"
variable.
3. Output the derived key "outkey".
The client will strengthen the 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 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 3, 2009 [Page 5]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
3. IANA Considerations
None.
Josefsson Expires September 3, 2009 [Page 6]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
4. Acknowledgements
Nicolas Williams mentioned the advantages in
<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>.
Josefsson Expires September 3, 2009 [Page 7]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
5. 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.
Josefsson Expires September 3, 2009 [Page 8]
Internet-Draft Kerberos V5 Reply Key Strengthening March 2009
6. References
6.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.
6.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 3, 2009 [Page 9]
Internet-Draft Kerberos V5 Reply Key Strengthening 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 3, 2009 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-21 07:59:22 |