idnits 2.17.1 draft-ietf-krb-wg-tcp-expansion-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 220. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 (May 10, 2006) is 6532 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 (~~), 2 warnings (==), 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 10, 2006 5 Expires: November 11, 2006 7 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over 8 TCP 9 draft-ietf-krb-wg-tcp-expansion-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 11, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes an extensibility mechanism for the Kerberos 43 v5 protocol when used over TCP transports. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Conventions used in this document . . . . . . . . . . . . . . . 3 49 3. Extension Mechanism for TCP transport . . . . . . . . . . . . . 3 50 4. Interoperability Consideration . . . . . . . . . . . . . . . . 4 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 53 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 54 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 55 Appendix A. Copying conditions . . . . . . . . . . . . . . . . . . 5 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 The Kerberos 5 [3] specification, in section 7.2.2, reserve the high 62 order bit in the initial length field for TCP transport for future 63 expansion. This document update [3] to describe the behaviour when 64 that bit is set. This mechanism is intended for extensions that are 65 specific for the TCP transport. 67 2. Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [1]. 73 3. Extension Mechanism for TCP transport 75 The reserved high bit of the request length field is used to signal 76 the use of this extension mechanism. When the reserved high bit is 77 set, the remaining 31 bits of the initial 4 octets are interpreted as 78 a bitmap. Each bit in the bitmask can be used to request a 79 particular extension. The 31 bits form the "extension bitmask". It 80 is expected that other documents will describe the details associated 81 with particular bits. 83 A 4-octet value with only the high bit set, and thus the extension 84 bitmask all zeros, is called a PROBE. A client may send a probe to 85 find out which extensions a KDC support. A client may also set 86 particular bits in the extension bitmask directly, if it does not 87 need to query the KDC for available extensions before deciding which 88 extension to request. 90 If a KDC receive a PROBE, or if a KDC does not support all extensions 91 corresponding to set bits in the extension bitmask, the KDC MUST 92 return 4 octets with the high bit set, and with the remaining bitmask 93 indicate which extensions it supports. The KDC SHOULD NOT close the 94 connection, and SHOULD wait for the client to then send a second 95 4-octet value, with the high bit set and the remaining bits as the 96 bitmask, to request a particular extension. If the second 4-octet 97 value is a PROBE or an unsupported extension, the KDC MUST close the 98 connection. This is used by the client to shutdown a session when 99 the KDC did not support a, by the client, required extension. 101 Resource avaibility considerations may influence whether, and for how 102 long, the KDC will wait for the client to send requests. 104 The behaviour when more than one non-high bit is set depends on the 105 particular extension mechanisms. If a requested extension (bit X) 106 does not specify how it interact with another requested extensions 107 (bit Y), the KDC MUST treat the request as a PROBE or unsupported 108 extension, and proceed as above. 110 Each extension MUST describe the structure of protocol data beyond 111 the length field, and the behaviour of the client and KDC. If an 112 extension mechanism reserve multiple bits, it MUST describe how they 113 interact. 115 4. Interoperability Consideration 117 Implementations with support for TCP that do not claim to conform to 118 RFC 4120 may not handle the high bit correctly. Behaviour may 119 include closing the TCP connection without any response, and logging 120 an error message in the KDC log. When this was written, this problem 121 existed in modern versions of popular implementations. 122 Implementations experiencing trouble getting the expected responses 123 from a server SHOULD assume that it does not support this extension 124 mechanism. Clients MAY remember this semi-permanently, to avoid 125 excessive logging in the server. Care should be taken to avoid 126 unexpected behaviour for the user when the KDC is eventually 127 upgraded. Implementations MAY also provide a way to enable and 128 disable this extension on a per-realm basis. How to handle these 129 backwards compatibility quirks are in general left unspecified. 131 5. Security Considerations 133 Because the initial length field is not protected, it is possible for 134 an active attacker (i.e., one that is able to modify traffic between 135 the client and the KDC) to make it appear to the client that the 136 server does not support this extension mechanism. Client and KDC 137 policies can be used to reject connections that does not use any 138 expansion. 140 6. IANA Considerations 142 IANA needs to create a new registry for "Kerberos 5 TCP Extensions". 143 The initial contents of this registry should be: 145 [[RFC Editor: Replace xxxx below with the number of this RFC.]] 147 Bit # Meaning Reference 148 ----- ------- --------- 149 0..29 AVAILABLE for registration. 151 30 RESERVED. RFC XXXX 153 IANA will register values 0 to 29 after IESG Approval, as defined in 154 BCP 64 [2]. Assigning value 30 requires a Standards Action that 155 update or obsolete this document. 157 7. Acknowledgements 159 Thanks to Andrew Bartlett who pointed out that some implementations 160 (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with 161 regards to the high bit, which resulted in an Interoperability 162 Consideration. 164 Nicolas Williams and Jeffrey Hutzelman provided comments that 165 improved the document. 167 8. Normative References 169 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 170 Levels", BCP 14, RFC 2119, March 1997. 172 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 173 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 175 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 176 Network Authentication Service (V5)", RFC 4120, July 2005. 178 Appendix A. Copying conditions 180 Copyright (C) 2005, 2006 Simon Josefsson 182 Regarding this entire document or any portion of it, the author makes 183 no guarantees and is not responsible for any damage resulting from 184 its use. The author grants irrevocable permission to anyone to use, 185 modify, and distribute it in any way that does not diminish the 186 rights of anyone else to use, modify, and distribute it, provided 187 that redistributed derivative works do not contain misleading author 188 or version information. Derivative works need not be licensed under 189 similar terms. 191 Author's Address 193 Simon Josefsson 194 SJD 196 Email: simon@josefsson.org 198 Intellectual Property Statement 200 The IETF takes no position regarding the validity or scope of any 201 Intellectual Property Rights or other rights that might be claimed to 202 pertain to the implementation or use of the technology described in 203 this document or the extent to which any license under such rights 204 might or might not be available; nor does it represent that it has 205 made any independent effort to identify any such rights. Information 206 on the procedures with respect to rights in RFC documents can be 207 found in BCP 78 and BCP 79. 209 Copies of IPR disclosures made to the IETF Secretariat and any 210 assurances of licenses to be made available, or the result of an 211 attempt made to obtain a general license or permission for the use of 212 such proprietary rights by implementers or users of this 213 specification can be obtained from the IETF on-line IPR repository at 214 http://www.ietf.org/ipr. 216 The IETF invites any interested party to bring to its attention any 217 copyrights, patents or patent applications, or other proprietary 218 rights that may cover technology that may be required to implement 219 this standard. Please address the information to the IETF at 220 ietf-ipr@ietf.org. 222 Disclaimer of Validity 224 This document and the information contained herein are provided on an 225 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 226 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 227 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 228 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 229 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 230 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 232 Copyright Statement 234 Copyright (C) The Internet Society (2006). This document is subject 235 to the rights, licenses and restrictions contained in BCP 78, and 236 except as set forth therein, the authors retain all their rights. 238 Acknowledgment 240 Funding for the RFC Editor function is currently provided by the 241 Internet Society.