idnits 2.17.1 draft-zhu-kerb-enctype-nego-04.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 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 242. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. -- 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 (October 21, 2005) is 6761 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) == Unused Reference: 'RFC2743' is defined on line 175, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'X680' -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft P. Leach 4 Updates: 4120 (if approved) K. Jaganathan 5 Expires: April 24, 2006 Microsoft Corporation 6 October 21, 2005 8 Kerberos Cryptosystem Negotiation Extension 9 draft-zhu-kerb-enctype-nego-04 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 April 24, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies an extension to the Kerberos protocol where 43 the client can send a list of supported encryption types in 44 decreasing preference order, and the server then selects an 45 encryption type that is supported by both the client and the server. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 51 3. Negotiation Extension . . . . . . . . . . . . . . . . . . . . . 3 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 53 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Intellectual Property and Copyright Statements . . . . . . . . . . 7 59 1. Introduction 61 Under the current mechanism [RFC4120], the KDC must limit the ticket 62 session key encryption type (enctype) chosen for a given server to 63 one it believes is supported by both the client and the server. If 64 both the client and server understand a stronger enctype than the one 65 selected by the KDC, they can not negotiate it. As the result, the 66 protection of application traffic is often weaker than necessary when 67 the server can support different sets of enctypes depending on the 68 server application software being used. 70 This document specifies an extension to the Kerberos protocol to 71 allow clients and servers to negotiate a different and possible 72 stronger cryptosystem to be used in subsequent communication. 74 This extension utilizes an authorization data element in the 75 authenticator of the AP-REQ message [RFC4120]. The client sends the 76 list of enctypes that it supports to the server, the server then 77 informs the client its choice. The negotiated subkey is sent in the 78 AP-REP message [RFC4120]. 80 2. Conventions Used in This Document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Negotiation Extension 88 If the client prefers an enctype over that of the service ticket 89 session key, then it SHOULD send a list of enctypes in decreasing 90 preference order to the server. Based on local policy, the client 91 selects enctypes out of all the enctypes available locally to be 92 included in this list and it SHOULD NOT include enctypes that are 93 less preferable than that of the ticket session key in the service 94 ticket. In addition, the client SHOULD NOT include negative (local- 95 use) enctype numbers unless it knows a-priori that the server has 96 been configured to use the same negative enctype numbers for the same 97 enctypes. 99 The client sends the enctype list via the authorization-data of the 100 authenticator in the AP-REQ [RFC4120]. A new authorization data 101 element type AD-ETYPE-NEGOTIATION is defined. 103 AD-ETYPE-NEGOTIATION 129 105 This authorization data element itself is enclosed in the AD-IF- 106 RELEVANT container, thus a correctly implemented server that does not 107 understand this element should ignore it [RFC4120]. The value of 108 this authorization element contains the DER [X680] [X690] encoding of 109 the following ASN.1 type: 111 EtypeList ::= SEQUENCE OF Int32 112 -- Specifies the enctypes supported by the client. 113 -- This enctype list is in decreasing preference order 114 -- (favorite choice first). 115 -- Int32 is defined in [RFC4120]. 117 If the EtypeList is present and the server prefers an enctype from 118 the client's enctype list over that of the AP-REQ authenticator 119 subkey (if that is present) or the service ticket session key, the 120 server MUST create a subkey using that enctype. This negotiated 121 subkey is sent in the subkey field of AP-REP message and it is then 122 used as the protocol key or base key [RFC3961] for subsequent 123 communication. 125 If the enctype of the ticket session key is included in the enctype 126 list sent by the client, it SHOULD be the last on the list; otherwise 127 this enctype MUST NOT be negotiated if it was not included in the 128 list. 130 This negotiation extension SHOULD NOT be used when the client does 131 not expect the subkey in the AP-REP message from the server. 133 A note on key generation: The KDC has a strong Pseudo-Random Number 134 Generator (PRNG), as such the client can take advantage of the 135 randomness provided by the KDC by reusing the KDC key data when 136 generating keys. Implementations SHOULD use the service ticket 137 session key value as a source of additional entropy when generating 138 the negotiated subkey. If the AP-REQ authenticator subkey is 139 present, it MAY also be used as a source of entropy. 141 The server MAY ignore the preference order indicated by the client. 142 The policy by which the client or the server chooses an enctype 143 (i.e., how the preference order for the supported enctypes is 144 selected) is a local matter. 146 4. Security Considerations 148 The client's enctype list and the server's reply enctype are part of 149 encrypted data, thus the security considerations are the same as 150 those of the Kerberos encrypted data. 152 Both the EtypeList and the server's sub-session key are protected by 153 the session key or sub-session key used for the AP-REQ, and as a 154 result, if a key for a stronger enctype is negotiated underneath a 155 key for a weaker enctype, an attacker capable of breaking the weaker 156 enctype can also discover the key for the stronger enctype. The 157 advantage of this extension is to minimize the amount of cipher text 158 encrypted under a weak enctype to which an attacker has access. 160 5. Acknowledgments 162 The authors would like to thank the following individuals for their 163 comments and suggestions: Ken Raeburn, Luke Howard, Tom Yu, Love 164 Hornquist Astrand, Sam Hartman and Martin Rex. 166 6. IANA Considerations 168 No IANA actions are required for this document. 170 7. Normative References 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, March 1997. 175 [RFC2743] Linn, J., "Generic Security Service Application Program 176 Interface Version 2, Update 1", RFC 2743, January 2000. 178 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 179 Kerberos 5", RFC 3961, February 2005. 181 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 182 Kerberos Network Authentication Service (V5)", RFC 4120, 183 July 2005. 185 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 186 Information technology - Abstract Syntax Notation One 187 (ASN.1): Specification of basic notation. 189 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 190 Information technology - ASN.1 encoding Rules: Specification 191 of Basic Encoding Rules (BER), Canonical Encoding Rules 192 (CER) and Distinguished Encoding Rules (DER). 194 Authors' Addresses 196 Larry Zhu 197 Microsoft Corporation 198 One Microsoft Way 199 Redmond, WA 98052 200 US 202 Email: lzhu@microsoft.com 204 Paul Leach 205 Microsoft Corporation 206 One Microsoft Way 207 Redmond, WA 98052 208 US 210 Email: paulle@microsoft.com 212 Karthik Jaganathan 213 Microsoft Corporation 214 One Microsoft Way 215 Redmond, WA 98052 216 US 218 Email: karthikj@microsoft.com 220 Intellectual Property Statement 222 The IETF takes no position regarding the validity or scope of any 223 Intellectual Property Rights or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; nor does it represent that it has 227 made any independent effort to identify any such rights. Information 228 on the procedures with respect to rights in RFC documents can be 229 found in BCP 78 and BCP 79. 231 Copies of IPR disclosures made to the IETF Secretariat and any 232 assurances of licenses to be made available, or the result of an 233 attempt made to obtain a general license or permission for the use of 234 such proprietary rights by implementers or users of this 235 specification can be obtained from the IETF on-line IPR repository at 236 http://www.ietf.org/ipr. 238 The IETF invites any interested party to bring to its attention any 239 copyrights, patents or patent applications, or other proprietary 240 rights that may cover technology that may be required to implement 241 this standard. Please address the information to the IETF at 242 ietf-ipr@ietf.org. 244 Disclaimer of Validity 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 249 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 250 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 251 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Copyright Statement 256 Copyright (C) The Internet Society (2005). This document is subject 257 to the rights, licenses and restrictions contained in BCP 78, and 258 except as set forth therein, the authors retain all their rights. 260 Acknowledgment 262 Funding for the RFC Editor function is currently provided by the 263 Internet Society.