idnits 2.17.1 draft-josefsson-krb-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 212. ** 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 (April 23, 2006) is 6570 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) April 23, 2006 5 Expires: October 25, 2006 7 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over 8 TCP 9 draft-josefsson-krb-tcp-expansion-02 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 October 25, 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 MUST NOT close the 94 connection, and MUST 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 The behaviour when more than one non-high bit is set depends on the 102 particular extension mechanisms. If a requested extension (bit X) 103 does not specify how it interact with another requested extensions 104 (bit Y), the KDC MUST treat the request as a PROBE or unsupported 105 extension, and proceed as above. 107 Each extension MUST describe the structure of protocol data beyond 108 the length field, and the behaviour of the client and KDC. If an 109 extension mechanism reserve multiple bits, it MUST describe how they 110 interact. 112 4. Interoperability Consideration 114 Implementations with support for TCP that do not claim to conform to 115 RFC 4120 may not handle the high bit correctly. Behaviour may 116 include closing the TCP connection without any response, and logging 117 an error message in the KDC log. When this was written, this problem 118 existed in modern versions of popular implementations. 119 Implementations experiencing trouble getting the expected responses 120 from a server SHOULD assume that it does not support this extension 121 mechanism. Clients MAY remember this semi-permanently, to avoid 122 excessive logging in the server. Care should be taken to avoid 123 unexpected behaviour for the user when the KDC is eventually 124 upgraded. How to handle these backwards compatibility quirks are in 125 general left unspecified. 127 5. Security Considerations 129 Because the initial length field is not protected, it is possible for 130 an active attacker (i.e., one that is able to modify traffic between 131 the client and the KDC) to make it appear to the client that the 132 server does not support this extension mechanism. Client and KDC 133 policies can be used to reject connections that does not use any 134 expansion. 136 6. IANA Considerations 138 IANA needs to create a new registry for "Kerberos 5 TCP Extensions". 139 The initial contents of this registry should be: 141 [[RFC Editor: Replace xxxx below with the number of this RFC.]] 143 Bit # Meaning Reference 144 ----- ------- --------- 145 0..29 AVAILABLE for registration. 146 30 RESERVED. RFC XXXX 148 IANA will register values 0 to 29 after IESG Approval, as defined in 149 BCP 64 [2]. Assigning value 30 requires a Standards Action. 151 7. Acknowledgements 153 Thanks to Andrew Bartlett who pointed out that some implementations 154 (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with 155 regards to the high bit, which resulted in an Interoperability 156 Consideration. 158 Nicolas Williams and Jeffrey Hutzelman provided comments that 159 improved the document. 161 8. Normative References 163 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 164 Levels", BCP 14, RFC 2119, March 1997. 166 [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 167 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 169 [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos 170 Network Authentication Service (V5)", RFC 4120, July 2005. 172 Appendix A. Copying conditions 174 Regarding this entire document or any portion of it, the author makes 175 no guarantees and is not responsible for any damage resulting from 176 its use. The author grants irrevocable permission to anyone to use, 177 modify, and distribute it in any way that does not diminish the 178 rights of anyone else to use, modify, and distribute it, provided 179 that redistributed derivative works do not contain misleading author 180 or version information. Derivative works need not be licensed under 181 similar terms. 183 Author's Address 185 Simon Josefsson 186 SJD 188 Email: simon@josefsson.org 190 Intellectual Property Statement 192 The IETF takes no position regarding the validity or scope of any 193 Intellectual Property Rights or other rights that might be claimed to 194 pertain to the implementation or use of the technology described in 195 this document or the extent to which any license under such rights 196 might or might not be available; nor does it represent that it has 197 made any independent effort to identify any such rights. Information 198 on the procedures with respect to rights in RFC documents can be 199 found in BCP 78 and BCP 79. 201 Copies of IPR disclosures made to the IETF Secretariat and any 202 assurances of licenses to be made available, or the result of an 203 attempt made to obtain a general license or permission for the use of 204 such proprietary rights by implementers or users of this 205 specification can be obtained from the IETF on-line IPR repository at 206 http://www.ietf.org/ipr. 208 The IETF invites any interested party to bring to its attention any 209 copyrights, patents or patent applications, or other proprietary 210 rights that may cover technology that may be required to implement 211 this standard. Please address the information to the IETF at 212 ietf-ipr@ietf.org. 214 Disclaimer of Validity 216 This document and the information contained herein are provided on an 217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 224 Copyright Statement 226 Copyright (C) The Internet Society (2006). This document is subject 227 to the rights, licenses and restrictions contained in BCP 78, and 228 except as set forth therein, the authors retain all their rights. 230 Acknowledgment 232 Funding for the RFC Editor function is currently provided by the 233 Internet Society.