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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text