draft-josefsson-kerberos5-starttls-01.txt | draft-josefsson-kerberos5-starttls-02.txt | |||
---|---|---|---|---|
Network Working Group S. Josefsson | Network Working Group S. Josefsson | |||
Internet-Draft SJD | Internet-Draft SJD | |||
Intended status: Standards Track October 4, 2006 | Intended status: Standards Track October 21, 2006 | |||
Expires: April 7, 2007 | Expires: April 24, 2007 | |||
Using Kerberos V5 over the Transport Layer Security (TLS) protocol | Using Kerberos V5 over the Transport Layer Security (TLS) protocol | |||
draft-josefsson-kerberos5-starttls-01 | draft-josefsson-kerberos5-starttls-02 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
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 April 7, 2007. | This Internet-Draft will expire on April 24, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
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. | additional security features. | |||
skipping to change at page 3, line 17 | skipping to change at page 3, line 17 | |||
This document describe how a Kerberos V5 [2] implementation may | This document describe how a Kerberos V5 [2] implementation may | |||
upgrade communication between clients and Key Distribution Centers | upgrade communication between clients and Key Distribution Centers | |||
(KDCs) to use the Transport Layer Security (TLS) [4] protocol. | (KDCs) to use the Transport Layer Security (TLS) [4] protocol. | |||
The TLS protocol offer integrity and privacy protected exchanges that | The TLS protocol offer integrity and privacy protected exchanges that | |||
can be authentication using X.509 certificates, OpenPGP keys [7], and | can be authentication using X.509 certificates, OpenPGP keys [7], and | |||
user name and passwords via SRP [6]. | user name and passwords via SRP [6]. | |||
There are several reasons to use Kerberos V5 over TLS. | There are several reasons to use Kerberos V5 over TLS. | |||
o Prevents downgrade attacks affecting, e.g., encryption types and | ||||
pre-auth data negotiation. The encryption type field in KDC-REQ, | ||||
and the METHOD-DATA field with the requested pre-auth types from | ||||
the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent | ||||
without integrity or privacy protection in Kerberos 5. This | ||||
allows an attacker to replace the encryption type with a | ||||
compromised encryption type, e.g., 56-bit DES, or request that | ||||
clients should use a broken pre-auth type. Since clients in | ||||
general cannot know the encryption types other servers support, or | ||||
the pre-auth types servers prefer or require, it is difficult for | ||||
the client to detect if there was a man-in-the-middle or if the | ||||
remote server simply did not support a stronger encryption type or | ||||
preferred another pre-auth type. | ||||
o Kerberos exchanges are privacy protected. Part of many Kerberos | o Kerberos exchanges are privacy protected. Part of many Kerberos | |||
packets are transfered without privacy protection (i.e., | packets are transfered without privacy protection (i.e., | |||
encryption). That part contains information, such as the client | encryption). That part contains information, such as the client | |||
principal name, the server principal name, the encryption types | principal name, the server principal name, the encryption types | |||
supported by the client, the lifetime of tickets, etc. Revealing | supported by the client, the lifetime of tickets, etc. Revealing | |||
such information is, in some threat models, considered a problem. | such information is, in some threat models, considered a problem. | |||
o Prevents downgrade attacks affecting encryption types. The | ||||
encryption type of the ticket in KDC-REQ are sent in the clear in | ||||
Kerberos 5. This allows an attacker to replace the encryption | ||||
type with a compromised mechanisms, e.g., 56-bit DES. Since | ||||
clients in general cannot know the encryption types other servers | ||||
support, it is difficult for the client to detect if there was a | ||||
man-in-the-middle or if the remote server simply did not support a | ||||
stronger mechanism. Clients could chose to refuse, e.g., 56-bit | ||||
DES altogether, but in some environments this leads to operational | ||||
difficulties. | ||||
o Additional authentication against the KDC. In some situations, | o Additional authentication against the KDC. In some situations, | |||
users are equipped with smart cards with a RSA authentication key. | users are equipped with smart cards with a RSA authentication key. | |||
In others, users have a OpenPGP client on their desktop, with a | In others, users have a OpenPGP client on their desktop, with a | |||
public OpenPGP key known to the server. In some situations, the | public OpenPGP key known to the server. | |||
policy may be that password authentication may only be done | ||||
through SRP. | ||||
o The TLS protocol has been studied by many parties. In some threat | o The TLS protocol has been studied by many parties. In some threat | |||
models, the designer prefer to reduce the number of protocols that | models, the designer prefer to reduce the number of protocols that | |||
can hurt the overall system security if they are compromised. | can hurt the overall system security if they are compromised. | |||
o Explicit server authentication of the KDC to the client. In | o Explicit server authentication of the KDC to the client. In | |||
traditional Kerberos 5, authentication of the KDC is proved as a | traditional Kerberos 5, authentication of the KDC is proved as a | |||
side effect that the KDC knows your encryption key (i.e., your | side effect that the KDC knows your encryption key (i.e., your | |||
password). | password). | |||
skipping to change at page 6, line 37 | skipping to change at page 6, line 37 | |||
Certificate* | Certificate* | |||
ClientKeyExchange | ClientKeyExchange | |||
CertificateVerify* | CertificateVerify* | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
Finished --------> | Finished --------> | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
<-------- Finished | <-------- Finished | |||
[ Kerberos V5 negotiation starts ] | [ Kerberos V5 negotiation starts ] | |||
4 octet length field | ||||
Kerberos V5 AS-REQ --------> | Kerberos V5 AS-REQ --------> | |||
4 octet length field | ||||
Kerberos V5 AS-REP | Kerberos V5 AS-REP | |||
<-------- | <-------- | |||
* Indicates optional or situation-dependent messages that are not | * Indicates optional or situation-dependent messages that are not | |||
always sent. | always sent. | |||
4. STARTTLS aware KDC Discovery | 4. STARTTLS aware KDC Discovery | |||
Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System | Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System | |||
(DNS) SRV records [5] can be used to find the address of an KDC. | (DNS) SRV records [5] can be used to find the address of an KDC. | |||
End of changes. 8 change blocks. | ||||
18 lines changed or deleted | 21 lines changed or added | |||
This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |