idnits 2.17.1 draft-tso-telnet-krb5-04.txt: ** The Abstract section seems to be numbered 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 Internet-Drafts being working documents. ** 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 6) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2000) is 8777 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 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-05) exists of draft-tso-telnet-auth-enc-04 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ts'o, Editor 2 Internet-Draft Massachusetts Institute of Technology 3 draft-tso-telnet-krb5-04.txt April 2000 5 Telnet Authentication: Kerberos Version 5 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference mate- 18 rial or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119. 30 0. Abstract 32 This document describes how Kerberos Version 5 [1] is used with the 33 telnet protocol. It describes an telnet authentication sub-option 34 to be used with the telnet authentication option [2]. This mecha- 35 nism can also used to provide keying material to provide data confi- 36 dentiality services in conjuction with the telnet encryption option 37 [3]. 39 1. Command Names and Codes 41 Authentication Types 43 KERBEROS_V5 2 45 Sub-option Commands 46 AUTH 0 47 REJECT 1 48 ACCEPT 2 49 RESPONSE 3 50 FORWARD 4 51 FORWARD_ACCEPT 5 52 FORWARD_REJECT 6 54 2. Command Meanings 56 IAC SB AUTHENTICATION IS AUTH IAC SE 59 This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the 60 remote side of the connection. The first octet of the value is KERBEROS_V5, to indicate that Version 5 62 of Kerberos is being used. The Kerberos V5 authenticator in the 63 KRB_AP_REQ message must contain a Kerberos V5 checksum of the 64 two-byte authentication type pair. This checksum must be verified 65 by the server to assure that the authentication type pair was cor- 66 rectly negotiated. The Kerberos V5 authenticator must also in- 67 clude the optional subkey field, which shall be filled in with a 68 randomly chosen key. This key shall be used for encryption pur- 69 poses if encryption is negotiated, and shall be used as the nego- 70 tiated session key (i.e., used as keyid 0) for the purposes of the 71 telnet encryption option; if the subkey is not filled in, then the 72 ticket session key will be used instead. 74 If data confidentiality services is desired the ENCRYPT_US- 75 ING_TELOPT flag must be set in the authentication-type-pair as 76 specified in [2]. 78 IAC SB AUTHENTICATION REPLY ACCEPT IAC SE 80 This command indicates that the authentication was successful. 82 If the AUTH_HOW_MUTUAL bit is set in the second octet of the au- 83 thentication-type-pair, the RESPONSE command must be sent before 84 the ACCEPT command is sent. 86 IAC SB AUTHENTICATION REPLY REJECT IAC SE 89 This command indicates that the authentication was not successful, 90 and if there is any more data in the sub-option, it is an ASCII 91 text message of the reason for the rejection. 93 IAC SB AUTHENTICATION REPLY RESPONSE 94 IAC SE 95 This command is used to perform mutual authentication. It is only 96 used when the AUTH_HOW_MUTUAL bit is set in the second octet of 97 the authentication-type-pair. After an AUTH command is verified, 98 a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP 99 message to perform the mutual authentication. 101 IAC SB AUTHENTICATION FORWARD IAC SE 104 This command is used to forward kerberos credentials for use by 105 the remote session. The credentials are passed as a Kerberos V5 106 KRB_CRED message which includes, among other things, the forwarded 107 Kerberos ticket and a session key associated with the ticket. Part 108 of the KRB_CRED message is encrypted in the key previously ex- 109 changed for the telnet session by the AUTH suboption. 111 IAC SB AUTHENTICATION FORWARD_ACCEPT IAC 112 SE 114 This command indicates that the credential forwarding was success- 115 ful. 117 IAC SB AUTHENTICATION FORWARD_REJECT IAC SE 120 This command indicates that the credential forwarding was not suc- 121 cessful, and if there is any more data in the sub-option, it is an 122 ASCII text message of the reason for the rejection. 124 3. Implementation Rules 126 If the second octet of the authentication-type-pair has the AUTH_WHO 127 bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial 128 AUTH command, and the server responds with either ACCEPT or REJECT. 129 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv- 130 er will send a RESPONSE before it sends the ACCEPT. 132 If the second octet of the authentication-type-pair has the AUTH_WHO 133 bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial 134 AUTH command, and the client responds with either ACCEPT or REJECT. 135 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 136 client will send a RESPONSE before it sends the ACCEPT. 138 The Kerberos principal used by the server will generally be of the 139 form "host/@realm". That is, the first component of the 140 Kerberos principal is "host"; the second component is the fully qual- 141 ified lower-case hostname of the server; and the realm is the Ker- 142 beros realm to which the server belongs. 144 Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP 145 messages, the KRB_CRED structure, or the optional rejection text 146 string must be doubled as specified in [4]. Otherwise the following 147 byte might be mis-interpreted as a Telnet command. 149 4. Examples 151 User "joe" may wish to log in as user "pete" on machine "foo". If 152 "pete" has set things up on "foo" to allow "joe" access to his ac- 153 count, then the client would send IAC SB AUTHENTICATION NAME "pete" 154 IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH 155 IAC SE 157 The server would then authenticate the user as "joe" from the 158 KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by 159 Kerberos, and if "pete" has allowed "joe" to use his account, the 160 server would then continue the authentication sequence by sending a 161 RESPONSE (to do mutual authentication, if it was requested) followed 162 by the ACCEPT. 164 If forwarding has been requested, the client then sends IAC SB AU- 165 THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD IAC SE. If the server succeeds in 167 reading the forwarded credentials, the server sends FORWARD_ACCEPT 168 else, a FORWARD_REJECT is sent back. 170 Client Server 171 IAC DO AUTHENTICATION 172 IAC WILL AUTHENTICATION 174 [ The server is now free to request authentication information. 175 ] 177 IAC SB AUTHENTICATION SEND 178 KERBEROS_V5 CLIENT|MUTUAL 179 KERBEROS_V5 CLIENT|ONE_WAY IAC 180 SE 182 [ The server has requested mutual Version 5 Kerberos 183 authentication. If mutual authentication is not supported, 184 then the server is willing to do one-way authentication. 186 The client will now respond with the name of the user that it 187 wants to log in as, and the Kerberos ticket. ] 189 IAC SB AUTHENTICATION NAME 190 "pete" IAC SE 191 IAC SB AUTHENTICATION IS 192 KERBEROS_V5 CLIENT|MUTUAL AUTH 193 IAC SE 195 [ Since mutual authentication is desired, the server sends across 196 a RESPONSE to prove that it really is the right server. ] 198 IAC SB AUTHENTICATION REPLY 199 KERBEROS_V5 CLIENT|MUTUAL 200 RESPONSE 201 IAC SE 203 [ The server responds with an ACCEPT command to state that the 204 authentication was successful. ] 206 IAC SB AUTHENTICATION REPLY KER- 207 BEROS_V5 CLIENT|MUTUAL ACCEPT 208 IAC SE 210 [ If so requested, the client now sends the FORWARD command to 211 forward credentials to the remote site. ] 213 IAC SB AUTHENTICATION IS KER- 214 BEROS_V5 CLIENT|MUTUAL 215 FORWARD IAC 216 SE 218 [ The server responds with a FORWARD_ACCEPT command to state that 219 the credential forwarding was successful. ] 220 IAC SB AUTHENTICATION REPLY KER- 221 BEROS_V5 CLIENT|MUTUAL FOR- 222 WARD_ACCEPT IAC SE 224 5. Security Considerations 226 The selection of the random session key in the Kerberos V5 authenti- 227 cator is critical, since this key will be used for encrypting the 228 telnet data stream if encryption is enabled. It is strongly advised 229 that the random key selection be done using cryptographic techniques 230 that involve the Kerberos ticket's session key. For example, using 231 the current time, encrypting it with the ticket session key, and then 232 correcting for key parity is a strong way to generate a subsession 233 key, since the ticket session key is assumed to be never disclosed to 234 an attacker. 236 Care should be taken before forwarding a user's Kerberos credentials 237 to the remote server. If the remote server is not trustworthy, this 238 could result in the user's credentials being compromised. Hence, the 239 user interface should not forward credentials by default; it would be 240 far safer to either require the user to explicitly request creden- 241 tials forwarding for each connection, or to have a trusted list of 242 hosts for which credentials forwarding is enabled, but to not enable 243 credentials forwarding by default for all machines. 245 6. IANA Considerations 247 The authentication type KERBEROS_V5 and its associated suboption values 248 are registered with IANA. Any suboption values used to extend 249 the protocol as described in this document must be registered 250 with IANA before use. IANA is instructed not to issue new suboption 251 values without submission of documentation of their use. 253 7. Acknowledgments 255 This document was originally written by Dave Borman of Cray Research, 256 Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- 257 tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- 258 tion Sciences Institute developed the credential forwarding support. 260 In addition, the contributions of the Telnet Working Group are also 261 gratefully acknowledged. 263 8. References 265 [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- 266 tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem- 267 ber 1993. 269 [2] Internet Engineering Task Force, "Telnet Authentication", draft- 270 tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, 271 April 2000. 273 [3] Internet Engineering Task Force, "Telnet Data Encryption Option", 274 draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux 275 Systems, April 2000. 277 [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC 278 855, STD 8, USC/Information Sciences Institute, May 1983. 280 Editor's Address 282 Theodore Ts'o 283 Massachusetts Institute of Technology 284 MIT Room E40-343 285 77 Massachusetts Avenue 286 Cambridge, MA 02139 288 Phone: (617) 253-8091 289 EMail: tytso@mit.edu 291 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 292 The Kermit Project * Columbia University 293 612 West 115th St #716 * New York, NY * 10025 294 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org