idnits 2.17.1 draft-ietf-krb-wg-tcp-expansion-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 273. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2006) is 6436 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (ref. '2') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD 4 Updates: 4120 (if approved) September 13, 2006 5 Intended status: Standards Track 6 Expires: March 17, 2007 8 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over 9 TCP 10 draft-ietf-krb-wg-tcp-expansion-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 17, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document describes an extensibility mechanism for the Kerberos 44 V5 protocol when used over TCP transports. The mechanism uses the 45 reserved high-bit in the length field. It can be used to negotiate 46 TCP-specific Kerberos extensions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . . 3 52 3. Extension Mechanism for TCP transport . . . . . . . . . . . . . 3 53 4. Interoperability Consideration . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 58 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . . . 7 62 1. Introduction 64 The Kerberos V5 [3] specification, in section 7.2.2, reserve the high 65 order bit in the initial length field for TCP transport for future 66 expansion. This document update [3] to describe the behaviour when 67 that bit is set. This mechanism is intended for extensions that are 68 specific for the TCP transport. 70 2. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [1]. 76 3. Extension Mechanism for TCP transport 78 The reserved high bit of the request length field is used to signal 79 the use of this extension mechanism. When the reserved high bit is 80 set in the length field, the remaining 31 bits of the initial 4 81 octets are interpreted as a bitmap. Each bit in the bitmask can be 82 used to request a particular extension. The 31 bits form the 83 "extension bitmask". It is expected that other documents will 84 describe the details associated with particular bits. 86 A 4-octet value with only the high bit set, and thus the extension 87 bitmask all zeros, is called a PROBE. A client may send a probe to 88 find out which extensions a KDC support. A client may also set 89 particular bits in the extension bitmask directly, if it does not 90 need to query the KDC for available extensions before deciding which 91 extension to request. 93 Note that clients are not forced to use this extension mechanism, and 94 further, clients are expected to only use it when they wish to 95 negotiate a particular extension. 97 The protocol is as follows. The client MUST begin by sending a 98 4-octet value with the high bit set. The packet is thus either a 99 PROBE or a specific request for some extension(s). The client MUST 100 NOT send additional data before the server has responded. 102 If a KDC receive a request for a set of extensions that it supports, 103 it MUST respond by sending a 4-octet zero value, i.e., 0x00000000. 104 The KDC MAY directly send additional data after the zero value, 105 without waiting for the client to respond, as specified by the 106 particular negotiated extension. (Note: A 4-octet zero value can 107 never be sent by a RFC 4120 conforming implementation that does not 108 support this extension mechanism, because a KRB-ERROR is always of 109 non-zero size.) 111 If a KDC receive a PROBE, or if a KDC does not support all extensions 112 corresponding to set bits in the extension bitmask, the KDC MUST 113 return 4 octets with the high bit set, and with the remaining bitmask 114 indicate which extensions it supports. The KDC then MUST wait and 115 the client MUST send a second 4-octet value, with the high bit set. 116 If the second 4-octet value is a PROBE or an unsupported extension, 117 the KDC MUST close the connection. This can be used by the client to 118 shutdown a session when the KDC did not support a, by the client, 119 required extension. If the second 4-octet value is a supported 120 extension, the KDC MUST respond by sending a 4-octet zero value, 121 i.e., 0x00000000. The KDC MAY directly send additional data after 122 the zero value, as specified by the particular negotiated extension. 124 The client and KDC SHOULD wait for the other side to respond 125 according to this protocol, and the client and KDC SHOULD NOT close 126 the connection prematurely. Resource avaibility considerations may 127 influence whether, and for how long, the client and KDC will wait for 128 the other side to respond to a request. 130 The KDC MUST NOT support the extension mechanism if it does not 131 support any extensions. If no extensions are supported, the KDC MUST 132 return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and 133 MUST close the TCP stream, similar to what an implementation that 134 does not understand this extension mechanism would do. 136 The behaviour when more than one non-high bit is set depends on the 137 particular extension mechanisms. If a requested extension (bit X) 138 does not specify how it interact with another requested extensions 139 (bit Y), the KDC MUST treat the request as a PROBE or unsupported 140 extension, and proceed as above. 142 Each extension MUST describe the structure of protocol data beyond 143 the length field, and the behaviour of the client and KDC. In 144 particular, the structure may be a protocol with its own message 145 framing. If an extension mechanism reserve multiple bits, it MUST 146 describe how they interact. 148 4. Interoperability Consideration 150 Implementations with support for TCP that do not claim to conform to 151 RFC 4120 may not handle the high bit correctly. The KDC behaviour 152 may include closing the TCP connection without any response, and 153 logging an error message in the KDC log. When this was written, this 154 problem existed in modern versions of popular KDC implementations. 156 Implementations experiencing trouble getting the expected responses 157 from a KDC might assume that the KDC does not support this extension 158 mechanism. A client might remember this semi-permanently, to avoid 159 triggering the same problematic behaviour on the KDC every time. 160 Care should be taken to avoid unexpected behaviour for the user when 161 the KDC is eventually upgraded. Implementations might also provide a 162 way to enable and disable this extension on a per-realm basis. How 163 to handle these backwards compatibility quirks are in general left 164 unspecified. 166 5. Security Considerations 168 Because the initial length field is not protected, it is possible for 169 an active attacker (i.e., one that is able to modify traffic between 170 the client and the KDC) to make it appear to the client that the 171 server does not support this extension mechanism (a downgrade 172 attack). Further, active attackers can also inferfere with the 173 negotiation of which extensions are supported, which may also result 174 in a downgrade attack. This problem can be solved by having a policy 175 in the clients and in the KDC to reject connections that does not 176 have the desired properties. 178 6. IANA Considerations 180 IANA needs to create a new registry for "Kerberos TCP Extensions". 181 The initial contents of this registry should be: 183 [[RFC Editor: Replace xxxx below with the number of this RFC.]] 185 Bit # Reference 186 ----- --------- 187 0..29 AVAILABLE for registration. 188 30 RESERVED. RFC XXXX 190 IANA will register values 0 to 29 after IESG Approval, as defined in 191 BCP 64 [2]. Assigning value 30 requires a Standards Action that 192 update or obsolete this document. 194 7. Acknowledgements 196 Nicolas Williams and Jeffrey Hutzelman provided comments that 197 improved the protocol and document. 199 Thanks to Andrew Bartlett who pointed out that some implementations 200 (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with 201 regards to the high bit, which resulted in an Interoperability 202 Consideration. 204 8. Normative References 206 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 207 Levels", BCP 14, RFC 2119, March 1997. 209 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 210 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 212 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 213 Network Authentication Service (V5)", RFC 4120, July 2005. 215 Appendix A. Copying conditions 217 Copyright (C) 2005, 2006 Simon Josefsson 219 Regarding this entire document or any portion of it, the author makes 220 no guarantees and is not responsible for any damage resulting from 221 its use. The author grants irrevocable permission to anyone to use, 222 modify, and distribute it in any way that does not diminish the 223 rights of anyone else to use, modify, and distribute it, provided 224 that redistributed derivative works do not contain misleading author 225 or version information. Derivative works need not be licensed under 226 similar terms. 228 Author's Address 230 Simon Josefsson 231 SJD 233 Email: simon@josefsson.org 235 Full Copyright Statement 237 Copyright (C) The Internet Society (2006). 239 This document is subject to the rights, licenses and restrictions 240 contained in BCP 78, and except as set forth therein, the authors 241 retain all their rights. 243 This document and the information contained herein are provided on an 244 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 245 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 246 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 247 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 248 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 249 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 251 Intellectual Property 253 The IETF takes no position regarding the validity or scope of any 254 Intellectual Property Rights or other rights that might be claimed to 255 pertain to the implementation or use of the technology described in 256 this document or the extent to which any license under such rights 257 might or might not be available; nor does it represent that it has 258 made any independent effort to identify any such rights. Information 259 on the procedures with respect to rights in RFC documents can be 260 found in BCP 78 and BCP 79. 262 Copies of IPR disclosures made to the IETF Secretariat and any 263 assurances of licenses to be made available, or the result of an 264 attempt made to obtain a general license or permission for the use of 265 such proprietary rights by implementers or users of this 266 specification can be obtained from the IETF on-line IPR repository at 267 http://www.ietf.org/ipr. 269 The IETF invites any interested party to bring to its attention any 270 copyrights, patents or patent applications, or other proprietary 271 rights that may cover technology that may be required to implement 272 this standard. Please address the information to the IETF at 273 ietf-ipr@ietf.org. 275 Acknowledgment 277 Funding for the RFC Editor function is provided by the IETF 278 Administrative Support Activity (IASA).