Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
RFC 5021

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