idnits 2.17.1 draft-ietf-krb-wg-info-ascii-gen-string-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 187 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 32 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 39: '... implementations SHOULD NOT deploy Ker...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 13, 2001) is 8199 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Jeffrey Altman 2 Columbia University 3 November 13, 2001 4 Expires: May 13, 2002 6 Informational: Kerberos GeneralString to be Interpreted as ASCII Only 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. It is filed as 30 draft-ietf-kerberos-info-ascii-gen-string-00.txt, and expires on 31 May 13, 2001. Please send comments to the Kerberos Working Group 32 mailing list. 34 Abstract: 36 To ensure future interoperability between existing deployments 37 of Kerberos 5 (RFC 1510) and future standards efforts the 38 Kerberos Working Group strongly recommends that users of Kerberos 5 39 implementations SHOULD NOT deploy Kerberos principal or service 40 names that utilize characters not included in the 94 printable 41 characters specified in the International Reference Version of 42 ISO-646/ECMA-6 (aka U.S. ASCII). 44 Background: 46 The original specification of the Kerberos protocol in RFC 1510 uses 47 GeneralString in numerous places for human-readable string data. 48 Historical implementations of Kerberos cannot utilize the full power 49 of GeneralString. This ASN.1 type requires the use of designation 50 and invocation escape sequences as specified in ISO-2022/ECMA-35 to 51 switch character sets, and the default character set that is designated 52 for G0 is the ISO-646/ECMA-6 International Reference Version (IRV) (aka 53 U.S. ASCII), which mostly works. 55 ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) and 56 two Control-function code elements (C0..C1). DER prohibits the 57 invocation of character sets into any but the G0 and C0 sets. 58 Unfortunately, this seems to have the side effect of prohibiting the 59 use of ISO-8859 (ISO Latin) character-sets or any other character-sets 60 that utilize a 96-character set, since it is prohibited by ISO-2022/ 61 ECMA-35 to invoke them into the G0 code element. 63 In practice, many implementations treat GeneralStrings as if they were 64 8-bit strings of whichever character set the implementation 65 defaults to, without regard for correct usage of character-set 66 designation escape sequences. The default character set is often 67 determined by the current user's operating system dependent locale. 68 At least one major implementation places unescaped UTF-8 encoded 69 Unicode characters in the GeneralString. This failure to adhere to 70 the GeneralString specifications results in interoperability issues 71 when conflicting character encodings are utilized by the Kerberos 72 clients, services, and KDC. 74 This unfortunate situation is the result of improper documentation 75 of the restrictions of the ASN.1 GeneralString type in prior 76 Kerberos specifications. 78 Transitioning to the use of UTF-8: 80 For various reasons, a transition to the use of UTF-8 encoding is 81 desirable. First, there is a mandate from the IESG to support 82 international character sets generally, and UTF-8 specifically. 83 Also, the fact that there are existing installations violating the 84 ISO-646/ECMA-6 restrictions and accepting the resulting pain indicates 85 that there is a clear need to support alternate character sets in 86 princpal names and passwords. As I8N support is deployed in DNS 87 there will be a need to represent Unicode service names. 89 At the same time, backward compatibility with the existing installed 90 base is crucial. Few site administrators have the luxury of declaring a 91 flash cut-over of all users, applications, servers, etc to an incompatible 92 protocol -- many have non-local users over whom they have little or no 93 control. To this end, it is important for new implementations to be able 94 to tell whether a particular non-US-ASCII string was encoded as UTF-8 by a 95 new implementation, or as something else by an old implementation. In the 96 latter case, it is of course impossible to know what the "something else" 97 is without being told in advance. 99 There have been three proposals for how the fields currently encoded 100 as GeneralStrings should be interpreted in order to accomplish such 101 a transition: 103 (1) Lie. Start using UTF-8, but continue to encode all of these 104 fields as GeneralStrings. To my knowledge, this is what Microsoft 105 is doing today. This approach is attractive because it requires 106 no changes to the message format specification and provides 100% 107 compatibility with deployments that adhere to the ISO-646/ECMA-6 108 standards. However, it has several key problems. First, it does 109 not allow a new implementation to tell whether a particular string 110 was encoded as UTF-8 by a post-RFC-1510 implementation or as some 111 8-bit local character set by an older implementation. Second, 112 there are potential problems with encoding arbitrary 8-bit strings, 113 particularly for those who are using off-the-shelf ASN.1 compilers. 114 Finally, violating the ASN.1 specification in this manner would be 115 unpopular with the ITU which is a serious issue. 117 (2) Don't lie. Start using UTF-8 encoded in GeneralStrings with 118 ISO-2022/ECMA-35 compatible escape sequences. While this has the 119 appearance of following the ASN.1 specification for GeneralString, 120 it has the problem that UTF-8 cannot be legally encoded due to the 121 restriction that only G0 compatible character-set can be specified. 122 This creates problems for implementors using off-the-shelf ASN.1 123 compilers as well as political issues with the ITU. 125 (3) Don't use GeneralString. In all the places where we currently 126 use GeneralString, begin using a new "KerberosString" type instead. 127 This type would be defined as an ASN.1 choice, with GeneralString 128 and some form of UTF-8 strings as alternatives. The selection of 129 which alternative to use would be based on whether one was talking 130 to an old implementation or a new one. This approach does involve 131 changing the message format _specifications_, but as long as the 132 GeneralString choice is used, the actual ASN.1 DER encoding does 133 not change. There is a transition issue in that replacing a type 134 with a choice containing that type is not always a legitimate thing 135 to do, but as long as DER are used (which is always the case in 136 Kerberos 5), it does work correctly. 138 The new KerberosString could be implemented as one of: 140 KerberosString ::= CHOICE { 141 general GeneralString (VisibleString), 142 utf8 UTF8String 143 } 145 or as 147 KerberosString ::= CHOICE { 148 general GeneralString (VisibleString), 149 ... 150 } 152 In both cases, most (if not all) occurrences of GeneralString 153 would be replaced with the new KerberosString. 155 It is the belief of the Kerberos Working group that regardless of the 156 final decision that is reached on how to transition to the use of UTF-8 157 those implementors and deployments which have restricted their use of 158 character-sets to the ISO-646/ECMA-6 IRV will have significantly fewer 159 difficulties making the transition. This is because the IRV is a proper 160 subset of the UTF-8 encoding. 162 Security Considerations: 164 Interoperability conflicts can result in denial of service for clients 165 that utilize character-sets in Kerberos strings other than those stored 166 in the KDC database. 168 References: 170 RFC-1510 The Kerberos Network Authentication Service (V5) 171 ISO-646/ECMA-6 7-bit Coded Character Set 172 ISO-1022/ECMA-35 Character Code Structure and Extension Techniques 173 ISO-4873/ECMA-43 8-bit Coded Character Set Structure and Rules 174 RFC-2279 UTF-8, a transformation format of ISO-10646 176 Acknowledgements: 178 This document while edited by Jeffrey Altman 179 (Columbia University) was directly derived from e-mail discussions 180 with Jeffrey T. Hutzelman (CMU) and Tom Yu 181 (MIT).