mirror of
https://github.com/samba-team/samba.git
synced 2025-01-25 06:04:04 +03:00
7055827b8f
This makes it clearer that we always want to do heimdal changes via the lorikeet-heimdal repository. Signed-off-by: Stefan Metzmacher <metze@samba.org> Reviewed-by: Joseph Sutton <josephsutton@catalyst.net.nz> Autobuild-User(master): Joseph Sutton <jsutton@samba.org> Autobuild-Date(master): Wed Jan 19 21:41:59 UTC 2022 on sn-devel-184
447 lines
15 KiB
Plaintext
447 lines
15 KiB
Plaintext
Network Working Group S. Josefsson
|
|
Internet-Draft November 13, 2004
|
|
Expires: May 14, 2005
|
|
|
|
|
|
Using Transport Layer Security (TLS) with Kerberos 5
|
|
draft-josefsson-kerberos5-starttls-00
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is subject to all provisions
|
|
of section 3 of RFC 3667. By submitting this Internet-Draft, each
|
|
author represents that any 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 become aware will be disclosed, in accordance with
|
|
RFC 3668.
|
|
|
|
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 May 14, 2005.
|
|
|
|
Copyright Notice
|
|
|
|
Copyright (C) The Internet Society (2004).
|
|
|
|
Abstract
|
|
|
|
This document specify how the Transport Layer Security (TLS) protocol
|
|
is used in conjunction with the Kerberos 5 protocol.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 1]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
Table of Contents
|
|
|
|
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
|
|
2. Extension Mechanism for TCP/IP transport . . . . . . . . . . . 4
|
|
3. Kerberos 5 STARTTLS Extension . . . . . . . . . . . . . . . . 4
|
|
3.1 STARTTLS requested by client (extension 1) . . . . . . . . 4
|
|
3.2 STARTTLS request accepted by server (extension 2) . . . . 5
|
|
3.3 Proceeding after successful TLS negotiation . . . . . . . 5
|
|
3.4 Proceeding after failed TLS negotiation . . . . . . . . . 5
|
|
3.5 STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . 5
|
|
3.6 Initial Authentication via TLS . . . . . . . . . . . . . . 5
|
|
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
|
|
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
|
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
|
|
5.2 Informative References . . . . . . . . . . . . . . . . . . . 6
|
|
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
|
|
Intellectual Property and Copyright Statements . . . . . . . . 8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 2]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
1. Introduction and Background
|
|
|
|
This document describe how Shishi, a Kerberos 5 [1] implementation,
|
|
upgrade communication between clients and Key Distribution Centers
|
|
(KDCs) to use the Transport Layer Security (TLS) [2] protocol.
|
|
|
|
The TLS protocol offer integrity and privacy protected exchanges that
|
|
can be authentication using X.509 certificates, OpenPGP keys [6], and
|
|
user name and passwords via SRP [5].
|
|
|
|
An inconclusive list of the motivation for using TLS with Kerberos 5
|
|
is given below.
|
|
|
|
o Explicit server authentication of the KDC to the client. In
|
|
traditional Kerberos 5, authentication of the KDC is proved as a
|
|
side effect that the KDC knows your encryption key (i.e., your
|
|
password).
|
|
|
|
o Flexible authentication against KDC. Kerberos 5 assume the user
|
|
knows a key (usually in the form of a password). Sometimes
|
|
external factors make this hard to fulfill. In some situations,
|
|
users are equipped with smart cards with a RSA authentication key.
|
|
In others, users have a OpenPGP client on their desktop, with a
|
|
public OpenPGP key known to the server. In some situations, the
|
|
policy may be that password authentication may only be done
|
|
through SRP.
|
|
|
|
o Kerberos exchanges are privacy protected. Part of many Kerberos
|
|
packets are transfered without privacy protection (i.e.,
|
|
encryption). That part contains information, such as the client
|
|
principal name, the server principal name, the encryption types
|
|
supported by the client, the lifetime of tickets, etc. Revealing
|
|
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 56-bit DES
|
|
altogether, but in some environments this leads to operational
|
|
difficulties.
|
|
|
|
o The TLS protocol has been studied by many parties. In some threat
|
|
models, the designer prefer to reduce the number of protocols that
|
|
can hurt the overall system security if they are compromised.
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 3]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
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 [4].
|
|
|
|
2. Extension Mechanism for TCP/IP transport
|
|
|
|
Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
|
|
over TCP. Each request and response is prefixed by 4 octets,
|
|
encoding an integer in network byte order, that indicate the length
|
|
of the packet. The high bit of the 4 octet length field was reserved
|
|
for future expansion. Servers that do not understand how to
|
|
interpret a set high bit are required to return a KRB-ERROR with the
|
|
KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
|
|
|
|
We will use the reserved bit to provide an extension mechanism. When
|
|
the reserved high bit is set, the remaining 31 bits of the 4 octets
|
|
are treated as an extensible typed hole, and thus form a 31 bit
|
|
integer enumerating various extensions. Each of the values indicate
|
|
a specific extended operation mode, two of which are used and defined
|
|
here, and the rest are left for others to use.
|
|
|
|
If the KDC do not understand a requested extension, it MUST return a
|
|
KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
|
|
length integer, with the high bit clear, as usual) and close the TCP
|
|
stream.
|
|
|
|
The following table specify the meaning of the 31 lower bits in the 4
|
|
octet field, when the high bit is set:
|
|
|
|
0 RESERVED.
|
|
1 STARTTLS requested by client.
|
|
2 STARTTLS request accepted by server.
|
|
3...2147483647 AVAILABLE for registration (via bug-shishi@josefsson.org)
|
|
.
|
|
2147483648 RESERVED.
|
|
|
|
|
|
3. Kerberos 5 STARTTLS Extension
|
|
|
|
3.1 STARTTLS requested by client (extension 1)
|
|
|
|
When this message is sent by the client, the client is requesting the
|
|
server to start TLS negotiation on the TCP stream. The client MUST
|
|
NOT start TLS negotiation immediately. Instead, the client wait for
|
|
either a KRB-ERROR (sent normally, prefixed by a 4 octet length
|
|
integer) indicating the server do not understand the set high bit, or
|
|
4 octets which is to be interpreted as an integer in network byte
|
|
order, where the high bit is set and the remaining 31 bit are
|
|
interpreted as an integer specifying ``STARTTLS request accepted by
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 4]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
server'' (extension 2). In the first case, the client infer that the
|
|
server do not understand (or wish to support) STARTTLS, and can
|
|
re-try using normal TCP, if unprotected Kerberos 5 exchanges are
|
|
acceptable to the client policy. In the latter case, it should
|
|
invoke TLS negotiation on the stream. If any other data is received,
|
|
the client MUST close the TCP stream.
|
|
|
|
3.2 STARTTLS request accepted by server (extension 2)
|
|
|
|
This message should be sent by the server when it has received the
|
|
extension 1 message. The message is an acknowledgment of the
|
|
client's request to initiate STARTTLS on the channel. The server
|
|
MUST then invoke a TLS negotiation.
|
|
|
|
3.3 Proceeding after successful TLS negotiation
|
|
|
|
If the TLS negotiation ended successfully, possibly also considering
|
|
client or server policies, the exchange within the TLS protected
|
|
stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
|
|
is no TCP 4 octet length field before each packet. Instead each
|
|
Kerberos packet MUST be sent within one TLS record, so the
|
|
application can use the TLS record length as the Kerberos 5 packet
|
|
length.
|
|
|
|
3.4 Proceeding after failed TLS negotiation
|
|
|
|
If the TLS negotiation fails, possibly due to client or server policy
|
|
(e.g., inadequate support of encryption types in TLS, or lack of
|
|
client or server authentication) the entity that detect the failure
|
|
MUST disconnected the connection. It is expected that any error
|
|
messages that explain the error condition is transfered by TLS.
|
|
|
|
3.5 STARTTLS aware KDC Discovery
|
|
|
|
Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
|
|
SRV records [3] can be used to find the address of an KDC. To locate
|
|
a KDC that support the STARTTLS extension, we use the "_tls" domain.
|
|
For example:
|
|
|
|
_kerberos._tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
|
|
_kerberos._tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
|
|
|
|
|
|
3.6 Initial Authentication via TLS
|
|
|
|
The server MAY consider the authentication performed by the TLS
|
|
exchange as sufficient to issue Kerberos 5 tickets to the client,
|
|
without requiring, e.g., pre-authentication. However, it is not an
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 5]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
error to require or use pre-authentication as well.
|
|
|
|
The client may also indicate that it wishes to use TLS both for
|
|
authentication and data protection by using the NULL encryption type
|
|
in its request. The server can decide from its local policy whether
|
|
or not issuing tickets based solely on TLS authentication, and
|
|
whether NULL encryption within TLS, is acceptable or not.
|
|
|
|
4. Security Considerations
|
|
|
|
Because the initial token is not protected, it is possible for an
|
|
active attacker to make it appear to the client that the server do
|
|
not support this extension. It is up to client configuration to
|
|
disallow non-TLS connections, if that vulnerability is deemed
|
|
unacceptable. For interoperability, we suggest the default behaviour
|
|
should be to allow automatic fall back to TCP or UDP.
|
|
|
|
The security considerations of both TLS and Kerberos 5 are inherited.
|
|
Using TLS for authentication and/or data protection together with
|
|
Kerberos alter the authentication logic fundamentally. Thus, it may
|
|
be that even if the TLS and Kerberos 5 protocols and implementations
|
|
were secure, the combination of TLS and Kerberos 5 described here
|
|
could be insecure.
|
|
|
|
No channel bindings are provided in the Kerberos messages. It is an
|
|
open question whether, and how, this could be solved. One idea for
|
|
solving this may be to specify a new encryption algorithm in Kerberos
|
|
5 that is similar to the NULL encryption algorithm, but also include
|
|
the TLS session identifier.
|
|
|
|
5. References
|
|
|
|
5.1 Normative References
|
|
|
|
[1] Neuman, C., "The Kerberos Network Authentication Service (V5)",
|
|
draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
|
|
September 2004.
|
|
|
|
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
|
|
2246, January 1999.
|
|
|
|
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
|
|
specifying the location of services (DNS SRV)", RFC 2782,
|
|
February 2000.
|
|
|
|
5.2 Informative References
|
|
|
|
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 6]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
[5] Taylor, D., "Using SRP for TLS Authentication",
|
|
draft-ietf-tls-srp-08 (work in progress), August 2004.
|
|
|
|
[6] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
|
|
authentication", draft-ietf-tls-openpgp-keys-05 (work in
|
|
progress), April 2004.
|
|
|
|
|
|
Author's Address
|
|
|
|
Simon Josefsson
|
|
|
|
EMail: simon@josefsson.org
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 7]
|
|
|
|
Internet-Draft Using TLS with Kerberos 5 November 2004
|
|
|
|
|
|
Intellectual Property Statement
|
|
|
|
The IETF takes no position regarding the validity or scope of any
|
|
Intellectual Property Rights or other rights that might be claimed to
|
|
pertain to the implementation or use of the technology described in
|
|
this document or the extent to which any license under such rights
|
|
might or might not be available; nor does it represent that it has
|
|
made any independent effort to identify any such rights. Information
|
|
on the procedures with respect to rights in RFC documents can be
|
|
found in BCP 78 and BCP 79.
|
|
|
|
Copies of IPR disclosures made to the IETF Secretariat and any
|
|
assurances of licenses to be made available, or the result of an
|
|
attempt made to obtain a general license or permission for the use of
|
|
such proprietary rights by implementers or users of this
|
|
specification can be obtained from the IETF on-line IPR repository at
|
|
http://www.ietf.org/ipr.
|
|
|
|
The IETF invites any interested party to bring to its attention any
|
|
copyrights, patents or patent applications, or other proprietary
|
|
rights that may cover technology that may be required to implement
|
|
this standard. Please address the information to the IETF at
|
|
ietf-ipr@ietf.org.
|
|
|
|
|
|
Disclaimer of Validity
|
|
|
|
This document and the information contained herein are provided on an
|
|
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
|
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
|
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
|
|
Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (2004). This document is subject
|
|
to the rights, licenses and restrictions contained in BCP 78, and
|
|
except as set for
|
|
th therein, the authors retain all their rights.
|
|
|
|
|
|
Acknowledgment
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
Internet Society.
|
|
|
|
|
|
|
|
|
|
Josefsson Expires May 14, 2005 [Page 8] |