draft-josefsson-kerberos5-starttls-06.txt   draft-josefsson-kerberos5-starttls-07.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Updates: 4120 (if approved) March 9, 2009 Intended status: Informational July 31, 2009
Intended status: Informational Expires: February 1, 2010
Expires: September 10, 2009
Using Kerberos V5 over the Transport Layer Security (TLS) protocol Using Kerberos V5 over the Transport Layer Security (TLS) protocol
draft-josefsson-kerberos5-starttls-06 draft-josefsson-kerberos5-starttls-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on February 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document specify how the Kerberos V5 protocol can be transported This document specify how the Kerberos V5 protocol can be transported
over the Transport Layer Security (TLS) protocol, to provide over the Transport Layer Security (TLS) protocol, to provide
additional security features. This document updates RFC 4120. additional security features.
Table of Contents Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 4 1. Introduction and Background . . . . . . . . . . . . . . . . . 4
2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6 2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8 4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 8
5. Validation of Server Certificate . . . . . . . . . . . . . . . 9 5. Server Certificates . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction and Background 1. Introduction and Background
skipping to change at page 9, line 5 skipping to change at page 9, line 5
an KDC. We define a new Proto of "tls" to indicate that the an KDC. We define a new Proto of "tls" to indicate that the
particular KDC is intended to support this STARTTLS extension. The particular KDC is intended to support this STARTTLS extension. The
Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target Service, Realm, TTL, Class, SRV, Priority, Weight, Port and Target
have the same meaning as in RFC 4120. have the same meaning as in RFC 4120.
For example: For example:
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
5. Validation of Server Certificate 5. Server Certificates
The TLS protocol can provide server authentication using, for The TLS protocol may be used in a mode that provides server
example, X.509 and OpenPGP. By validating the server certificate, authentication using, for example, X.509 and OpenPGP.
clients can be certain that it is talking to the intended KDC.
The Kerberos V5 STARTTLS protocol do not require clients to verify The Kerberos V5 STARTTLS protocol do not require clients to verify
the server certificate. The goal is that support for TLS in Kerberos the server certificate. The goal is that support for TLS in Kerberos
V5 clients should be as easy to implement and deploy as support for V5 clients should be as easy to implement and deploy as support for
UDP/TCP. Use of TLS, even without server certificate validation, UDP/TCP. Use of TLS, even without server certificate validation,
protects against some attacks that Kerberos V5 over UDP/TCP do not. protects against some attacks that Kerberos V5 over UDP/TCP do not.
Requiring server certificates to be used at all times would enable Requiring server certificates to be used at all times would enable
attacks in those situations. attacks in those situations.
Many clients does not have secure long-term storage that is required Many client environments do not have secure long-term storage, which
to validate certificates. This makes it impossible to implement is required to validate certificates. This makes it impossible to
server certificate validation in practice on a large number of use server certificate validation on a large number of client
deployed systems. systems.
When clients have the ability, they need to be able to validate the When clients have the ability, they need to be able to validate the
server certificate. For this reason, if a KDC presents a X.509 server certificate. For this reason, if a KDC presents a X.509
server certificate over TLS, it MUST contain an otherName Subject server certificate over TLS, it MUST contain an otherName Subject
Alternative Name (SAN) identified using a type-id of id-krb5starttls- Alternative Name (SAN) identified using a type-id of id-krb5starttls-
san. The intention is to bind the server certificate to the Kerberos san. The intention is to bind the server certificate to the Kerberos
realm for the purpose of using Kerberos V5 STARTTLS. The value field realm for the purpose of using Kerberos V5 STARTTLS. The value field
of the otherName should contain the realm as the "Realm" ASN.1 type. of the otherName should contain the realm as the "Realm" ASN.1 type.
id-krb5starttls-san OBJECT IDENTIFIER ::= id-krb5starttls-san OBJECT IDENTIFIER ::=
skipping to change at page 9, line 45 skipping to change at page 9, line 44
shishi(6) krb5starttls-san(1) } shishi(6) krb5starttls-san(1) }
To validate a server certificate, the client MAY use local To validate a server certificate, the client MAY use local
configuration (e.g., a list that map realm names to a copy of the configuration (e.g., a list that map realm names to a copy of the
server's certificate) and compare that with the authentication server's certificate) and compare that with the authentication
information provided from the server via TLS. For illustration, the information provided from the server via TLS. For illustration, the
server certificate could be a X.509 certificate or an OpenPGP key. server certificate could be a X.509 certificate or an OpenPGP key.
In this mode, the client need no processing related to id- In this mode, the client need no processing related to id-
krb5starttls-san. krb5starttls-san.
When the server presents a X.509 server certificate, there is an When the server presents a X.509 server certificate, clients MAY use
alternative way that clients MAY use to validate the server "Certification Path Validation" as described in [RFC5280] to validate
certificate. In this mode, the KDC server certificate is validated the KDC server certificate. In addition, unless the client can
by "Certification Path Validation" as described in [RFC5280]. In otherwise verify that the server certificate is bound to the KDC of
addition, the client MUST verify that the server certificate contains the target realm, the client MUST verify that the server certificate
the id-krb5starttls-san SAN and that the value is identical with the contains the id-krb5starttls-san SAN and that the value is identical
intended Kerberos realm. to the intended Kerberos realm.
6. IANA Considerations 6. IANA Considerations
The IANA is requested to allocate a bit in the "Kerberos TCP The IANA is requested to allocate a bit in the "Kerberos TCP
Extensions" registry for the extension described in this document, as Extensions" registry for the extension described in this document, as
per [RFC5021]. per [RFC5021].
7. Acknowledgements 7. Acknowledgements
Jeffrey Hutzelman and Sam Hartman provided comments that improved the Jeffrey Hutzelman and Sam Hartman provided comments that improved the
skipping to change at page 12, line 14 skipping to change at page 12, line 14
8. Security Considerations 8. Security Considerations
The security considerations in Kerberos V5, TLS, and the Kerberos V5 The security considerations in Kerberos V5, TLS, and the Kerberos V5
TCP extension mechanism are inherited. TCP extension mechanism are inherited.
Note that TLS does not protect against Man-In-The-Middle (MITM) Note that TLS does not protect against Man-In-The-Middle (MITM)
attacks unless clients verify the KDC's credentials (X.509 attacks unless clients verify the KDC's credentials (X.509
certificate, OpenPGP key, etc) correctly. certificate, OpenPGP key, etc) correctly.
If server authentication is used, some information about the server
(such as its name) is visible to passive attackers.
To protect against the inherent downgrade attack in the extension To protect against the inherent downgrade attack in the extension
framework, implementations SHOULD offer a policy mode that requires framework, implementations SHOULD offer a policy mode that requires
this extension to always be successfully negotiated, for a particular this extension to always be successfully negotiated, for a particular
realm, or generally. For interoperability with implementations that realm, or generally. For interoperability with implementations that
do not support this extension, the policy mode SHOULD be disabled by do not support this extension, the policy mode SHOULD be disabled by
default. default.
9. References 9. References
9.1. Normative References 9.1. Normative References
 End of changes. 10 change blocks. 
22 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/