draft-ietf-krb-wg-tcp-expansion-00.txt   draft-ietf-krb-wg-tcp-expansion-01.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD Internet-Draft SJD
Updates: 4120 (if approved) May 10, 2006 Updates: 4120 (if approved) September 13, 2006
Expires: November 11, 2006 Intended status: Standards Track
Expires: March 17, 2007
Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
TCP TCP
draft-ietf-krb-wg-tcp-expansion-00 draft-ietf-krb-wg-tcp-expansion-01
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 35 skipping to change at page 1, line 36
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 November 11, 2006. This Internet-Draft will expire on March 17, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes an extensibility mechanism for the Kerberos This document describes an extensibility mechanism for the Kerberos
v5 protocol when used over TCP transports. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Extension Mechanism for TCP transport . . . . . . . . . . . . . 3 3. Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
4. Interoperability Consideration . . . . . . . . . . . . . . . . 4 4. Interoperability Consideration . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Copying conditions . . . . . . . . . . . . . . . . . . 5 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Introduction 1. Introduction
The Kerberos 5 [3] specification, in section 7.2.2, reserve the high The Kerberos V5 [3] specification, in section 7.2.2, reserve the high
order bit in the initial length field for TCP transport for future order bit in the initial length field for TCP transport for future
expansion. This document update [3] to describe the behaviour when expansion. This document update [3] to describe the behaviour when
that bit is set. This mechanism is intended for extensions that are that bit is set. This mechanism is intended for extensions that are
specific for the TCP transport. specific for the TCP transport.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Extension Mechanism for TCP transport 3. Extension Mechanism for TCP transport
The reserved high bit of the request length field is used to signal 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 the use of this extension mechanism. When the reserved high bit is
set, the remaining 31 bits of the initial 4 octets are interpreted as set in the length field, the remaining 31 bits of the initial 4
a bitmap. Each bit in the bitmask can be used to request a octets are interpreted as a bitmap. Each bit in the bitmask can be
particular extension. The 31 bits form the "extension bitmask". It used to request a particular extension. The 31 bits form the
is expected that other documents will describe the details associated "extension bitmask". It is expected that other documents will
with particular bits. describe the details associated with particular bits.
A 4-octet value with only the high bit set, and thus the extension 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 bitmask all zeros, is called a PROBE. A client may send a probe to
find out which extensions a KDC support. A client may also set find out which extensions a KDC support. A client may also set
particular bits in the extension bitmask directly, if it does not particular bits in the extension bitmask directly, if it does not
need to query the KDC for available extensions before deciding which need to query the KDC for available extensions before deciding which
extension to request. 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 receive 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 a RFC 4120 conforming implementation that does not
support this extension mechanism, because a KRB-ERROR is always of
non-zero size.)
If a KDC receive a PROBE, or if a KDC does not support all extensions If a KDC receive a PROBE, or if a KDC does not support all extensions
corresponding to set bits in the extension bitmask, the KDC MUST corresponding to set bits in the extension bitmask, the KDC MUST
return 4 octets with the high bit set, and with the remaining bitmask return 4 octets with the high bit set, and with the remaining bitmask
indicate which extensions it supports. The KDC SHOULD NOT close the indicate which extensions it supports. The KDC then MUST wait and
connection, and SHOULD wait for the client to then send a second the client MUST send a second 4-octet value, with the high bit set.
4-octet value, with the high bit set and the remaining bits as the If the second 4-octet value is a PROBE or an unsupported extension,
bitmask, to request a particular extension. If the second 4-octet the KDC MUST close the connection. This can be used by the client to
value is a PROBE or an unsupported extension, the KDC MUST close the shutdown a session when the KDC did not support a, by the client,
connection. This is used by the client to shutdown a session when required extension. If the second 4-octet value is a supported
the KDC did not support a, by the client, required extension. extension, the KDC MUST respond by sending a 4-octet zero value,
i.e., 0x00000000. The KDC MAY directly send additional data after
the zero value, as specified by the particular negotiated extension.
Resource avaibility considerations may influence whether, and for how The client and KDC SHOULD wait for the other side to respond
long, the KDC will wait for the client to send requests. according to this protocol, and the client and KDC SHOULD NOT close
the connection prematurely. Resource avaibility considerations may
influence whether, and for how long, the client and KDC will wait for
the other side to respond to a request.
The KDC MUST NOT support the extension mechanism if it does not
support any extensions. If no extensions are supported, the KDC MUST
return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and
MUST close the TCP stream, similar to what an implementation that
does not understand this extension mechanism would do.
The behaviour when more than one non-high bit is set depends on the The behaviour when more than one non-high bit is set depends on the
particular extension mechanisms. If a requested extension (bit X) particular extension mechanisms. If a requested extension (bit X)
does not specify how it interact with another requested extensions does not specify how it interact with another requested extensions
(bit Y), the KDC MUST treat the request as a PROBE or unsupported (bit Y), the KDC MUST treat the request as a PROBE or unsupported
extension, and proceed as above. extension, and proceed as above.
Each extension MUST describe the structure of protocol data beyond Each extension MUST describe the structure of protocol data beyond
the length field, and the behaviour of the client and KDC. If an the length field, and the behaviour of the client and KDC. In
extension mechanism reserve multiple bits, it MUST describe how they particular, the structure may be a protocol with its own message
interact. framing. If an extension mechanism reserve multiple bits, it MUST
describe how they interact.
4. Interoperability Consideration 4. Interoperability Consideration
Implementations with support for TCP that do not claim to conform to Implementations with support for TCP that do not claim to conform to
RFC 4120 may not handle the high bit correctly. Behaviour may RFC 4120 may not handle the high bit correctly. The KDC behaviour
include closing the TCP connection without any response, and logging may include closing the TCP connection without any response, and
an error message in the KDC log. When this was written, this problem logging an error message in the KDC log. When this was written, this
existed in modern versions of popular implementations. problem existed in modern versions of popular KDC implementations.
Implementations experiencing trouble getting the expected responses Implementations experiencing trouble getting the expected responses
from a server SHOULD assume that it does not support this extension from a KDC might assume that the KDC does not support this extension
mechanism. Clients MAY remember this semi-permanently, to avoid mechanism. A client might remember this semi-permanently, to avoid
excessive logging in the server. Care should be taken to avoid triggering the same problematic behaviour on the KDC every time.
unexpected behaviour for the user when the KDC is eventually Care should be taken to avoid unexpected behaviour for the user when
upgraded. Implementations MAY also provide a way to enable and the KDC is eventually upgraded. Implementations might also provide a
disable this extension on a per-realm basis. How to handle these way to enable and disable this extension on a per-realm basis. How
backwards compatibility quirks are in general left unspecified. to handle these backwards compatibility quirks are in general left
unspecified.
5. Security Considerations 5. Security Considerations
Because the initial length field is not protected, it is possible for Because the initial length field is not protected, it is possible for
an active attacker (i.e., one that is able to modify traffic between an active attacker (i.e., one that is able to modify traffic between
the client and the KDC) to make it appear to the client that the the client and the KDC) to make it appear to the client that the
server does not support this extension mechanism. Client and KDC server does not support this extension mechanism (a downgrade
policies can be used to reject connections that does not use any attack). Further, active attackers can also inferfere with the
expansion. negotiation of which extensions are supported, which may also result
in a downgrade attack. This problem can be solved by having a policy
in the clients and in the KDC to reject connections that does not
have the desired properties.
6. IANA Considerations 6. IANA Considerations
IANA needs to create a new registry for "Kerberos 5 TCP Extensions". IANA needs to create a new registry for "Kerberos TCP Extensions".
The initial contents of this registry should be: The initial contents of this registry should be:
[[RFC Editor: Replace xxxx below with the number of this RFC.]] [[RFC Editor: Replace xxxx below with the number of this RFC.]]
Bit # Meaning Reference Bit # Reference
----- ------- --------- ----- ---------
0..29 AVAILABLE for registration. 0..29 AVAILABLE for registration.
30 RESERVED. RFC XXXX 30 RESERVED. RFC XXXX
IANA will register values 0 to 29 after IESG Approval, as defined in IANA will register values 0 to 29 after IESG Approval, as defined in
BCP 64 [2]. Assigning value 30 requires a Standards Action that BCP 64 [2]. Assigning value 30 requires a Standards Action that
update or obsolete this document. update or obsolete this document.
7. Acknowledgements 7. Acknowledgements
Nicolas Williams and Jeffrey Hutzelman provided comments that
improved the protocol and document.
Thanks to Andrew Bartlett who pointed out that some implementations Thanks to Andrew Bartlett who pointed out that some implementations
(MIT Kerberos and Heimdal) did not follow RFC 4120 properly with (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
regards to the high bit, which resulted in an Interoperability regards to the high bit, which resulted in an Interoperability
Consideration. Consideration.
Nicolas Williams and Jeffrey Hutzelman provided comments that
improved the document.
8. Normative References 8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005. Network Authentication Service (V5)", RFC 4120, July 2005.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
or version information. Derivative works need not be licensed under or version information. Derivative works need not be licensed under
similar terms. similar terms.
Author's Address Author's Address
Simon Josefsson Simon Josefsson
SJD SJD
Email: simon@josefsson.org Email: simon@josefsson.org
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 7, line 29 skipping to change at page 7, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 23 change blocks. 
65 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/