idnits 2.17.1 draft-ietf-krb-wg-tcp-expansion-02.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, updated by RFC 4748 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. 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 IETF Trust 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 (May 2, 2007) is 6175 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: 2 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) May 2, 2007 5 Intended status: Standards Track 6 Expires: November 3, 2007 8 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over 9 TCP 10 draft-ietf-krb-wg-tcp-expansion-02 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 November 3, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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. The problem can also be mitigated by 177 having the negotiated extension send a cryptographic checksum of the 178 offered extensions. 180 6. IANA Considerations 182 IANA needs to create a new registry for "Kerberos TCP Extensions". 183 The initial contents of this registry should be: 185 [[RFC Editor: Replace xxxx below with the number of this RFC.]] 187 Bit # Reference 188 ----- --------- 189 0..29 AVAILABLE for registration. 190 30 RESERVED. RFC XXXX 192 IANA will register values 0 to 29 after IESG Approval, as defined in 193 BCP 64 [2]. Assigning value 30 requires a Standards Action that 194 update or obsolete this document. 196 Registration policy: The IESG will act as a steward for the 197 namespace, considering whether the registration is justified given 198 the limited size of the namespace. The IESG will also confirm that 199 proposed registrations are not harmful to the Internet. 201 7. Acknowledgements 203 Nicolas Williams, Jeffrey Hutzelman, and Sam Hartman provided 204 comments that improved the protocol and document. 206 Thanks to Andrew Bartlett who pointed out that some implementations 207 (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with 208 regards to the high bit, which resulted in an Interoperability 209 Consideration. 211 8. Normative References 213 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 214 Levels", BCP 14, RFC 2119, March 1997. 216 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 217 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 219 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 220 Network Authentication Service (V5)", RFC 4120, July 2005. 222 Appendix A. Copying conditions 224 Regarding this entire document or any portion of it, the author makes 225 no guarantees and is not responsible for any damage resulting from 226 its use. The author grants irrevocable permission to anyone to use, 227 modify, and distribute it in any way that does not diminish the 228 rights of anyone else to use, modify, and distribute it, provided 229 that redistributed derivative works do not contain misleading author 230 or version information. Derivative works need not be licensed under 231 similar terms. 233 Author's Address 235 Simon Josefsson 236 SJD 238 Email: simon@josefsson.org 240 Full Copyright Statement 242 Copyright (C) The IETF Trust (2007). 244 This document is subject to the rights, licenses and restrictions 245 contained in BCP 78, and except as set forth therein, the authors 246 retain all their rights. 248 This document and the information contained herein are provided on an 249 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 250 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 251 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 252 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 253 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 254 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 256 Intellectual Property 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the procedures with respect to rights in RFC documents can be 265 found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at 278 ietf-ipr@ietf.org. 280 Acknowledgment 282 Funding for the RFC Editor function is provided by the IETF 283 Administrative Support Activity (IASA).