Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
RFC 5021
Document | Type |
RFC - Proposed Standard
(August 2007; No errata)
Updates RFC 4120
|
|
---|---|---|---|
Author | Simon Josefsson | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5021 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Sam Hartman | ||
Send notices to | (None) |
Network Working Group S. Josefsson Request for Comments: 5021 SJD Updates: 4120 August 2007 Category: Standards Track Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an extensibility mechanism for the Kerberos V5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiate TCP-specific Kerberos extensions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 3. Extension Mechanism for TCP Transport . . . . . . . . . . . . . 2 4. Interoperability Consideration . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . . 6 Josefsson Standards Track [Page 1] RFC 5021 Kerberos V5 TCP Extension August 2007 1. Introduction The Kerberos V5 [3] specification, in section 7.2.2, reserves the high order bit in the initial length field for TCP transport for future expansion. This document updates [3] to describe the behaviour when that bit is set. This mechanism is intended for extensions that are specific for the TCP transport. 2. Conventions Used in This Document 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 [1]. 3. Extension Mechanism for TCP Transport The reserved high bit of the request length field is used to signal the use of this extension mechanism. When the reserved high bit is set in the length field, the remaining 31 bits of the initial 4 octets are interpreted as a bitmap. Each bit in the bitmask can be used to request a particular extension. The 31 bits form the "extension bitmask". It is expected that other documents will describe the details associated with particular bits. A 4-octet value with only the high bit set, and thus the extension bitmask all zeros, is called a PROBE. A client may send a probe to find out which extensions a KDC supports. A client may also set particular bits in the extension bitmask directly, if it does not need to query the KDC for available extensions before deciding which extension to request. Note that clients are not forced to use this extension mechanism, and further, clients are expected to only use it when they wish to negotiate a particular extension. The protocol is as follows. The client MUST begin by sending a 4-octet value with the high bit set. The packet is thus either a PROBE or a specific request for some extension(s). The client MUST NOT send additional data before the server has responded. If a KDC receives a request for a set of extensions that it supports, it MUST respond by sending a 4-octet zero value, i.e., 0x00000000. The KDC MAY directly send additional data after the zero value, without waiting for the client to respond, as specified by the particular negotiated extension. (Note: A 4-octet zero value can never be sent by an implementation that conforms to RFC 4120 and that does not support this extension mechanism, because a KRB-ERROR is always of non-zero size.) Josefsson Standards Track [Page 2] RFC 5021 Kerberos V5 TCP Extension August 2007 If a KDC receives a PROBE, or if a KDC does not support all extensions corresponding to set bits in the extension bitmask, the KDC MUST return 4 octets with the high bit set, and with the remaining bitmask indicating which extensions it supports. The KDC then MUST wait, and the client MUST send a second 4-octet value with the high bit set. If the second 4-octet value is a PROBE or an unsupported extension, the KDC MUST close the connection. This can be used by the client to shut down a session when the KDC did notShow full document text