1Network Working Group T. Ts'o, Editor 2Internet-Draft Massachusetts Institute of Technology 3draft-tso-telnet-krb5-04.txt April 2000 4 5 Telnet Authentication: Kerberos Version 5 6 7Status of this Memo 8 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. 14 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." 19 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 22 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 25 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. 29 300. Abstract 31 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]. 38 391. Command Names and Codes 40 41 Authentication Types 42 43 KERBEROS_V5 2 44 45 Sub-option Commands 46 47 Expires Sept 2000 [Page 1] 48 49Internet-Draft Kerberos Version 5 for Telnet April 2000 50 51 AUTH 0 52 REJECT 1 53 ACCEPT 2 54 RESPONSE 3 55 FORWARD 4 56 FORWARD_ACCEPT 5 57 FORWARD_REJECT 6 58 592. Command Meanings 60 61 IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 62 KRB_AP_REQ message> IAC SE 63 64 This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the 65 remote side of the connection. The first octet of the <authenti- 66 cation-type-pair> value is KERBEROS_V5, to indicate that Version 5 67 of Kerberos is being used. The Kerberos V5 authenticator in the 68 KRB_AP_REQ message must contain a Kerberos V5 checksum of the 69 two-byte authentication type pair. This checksum must be verified 70 by the server to assure that the authentication type pair was cor- 71 rectly negotiated. The Kerberos V5 authenticator must also in- 72 clude the optional subkey field, which shall be filled in with a 73 randomly chosen key. This key shall be used for encryption pur- 74 poses if encryption is negotiated, and shall be used as the nego- 75 tiated session key (i.e., used as keyid 0) for the purposes of the 76 telnet encryption option; if the subkey is not filled in, then the 77 ticket session key will be used instead. 78 79 If data confidentiality services is desired the ENCRYPT_US- 80 ING_TELOPT flag must be set in the authentication-type-pair as 81 specified in [2]. 82 83 IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE 84 85 This command indicates that the authentication was successful. 86 87 If the AUTH_HOW_MUTUAL bit is set in the second octet of the au- 88 thentication-type-pair, the RESPONSE command must be sent before 89 the ACCEPT command is sent. 90 91 IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- 92 tional reason for rejection> IAC SE 93 94 This command indicates that the authentication was not successful, 95 and if there is any more data in the sub-option, it is an ASCII 96 text message of the reason for the rejection. 97 98 IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE 99 <KRB_AP_REP message> IAC SE 100 101 Expires Sept 2000 [Page 2] 102 103Internet-Draft Kerberos Version 5 for Telnet April 2000 104 105 This command is used to perform mutual authentication. It is only 106 used when the AUTH_HOW_MUTUAL bit is set in the second octet of 107 the authentication-type-pair. After an AUTH command is verified, 108 a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP 109 message to perform the mutual authentication. 110 111 IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED 112 message> IAC SE 113 114 This command is used to forward kerberos credentials for use by 115 the remote session. The credentials are passed as a Kerberos V5 116 KRB_CRED message which includes, among other things, the forwarded 117 Kerberos ticket and a session key associated with the ticket. Part 118 of the KRB_CRED message is encrypted in the key previously ex- 119 changed for the telnet session by the AUTH suboption. 120 121 IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC 122 SE 123 124 This command indicates that the credential forwarding was success- 125 ful. 126 127 IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op- 128 tional reason for rejection> IAC SE 129 130 This command indicates that the credential forwarding was not suc- 131 cessful, and if there is any more data in the sub-option, it is an 132 ASCII text message of the reason for the rejection. 133 1343. Implementation Rules 135 136 If the second octet of the authentication-type-pair has the AUTH_WHO 137 bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial 138 AUTH command, and the server responds with either ACCEPT or REJECT. 139 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv- 140 er will send a RESPONSE before it sends the ACCEPT. 141 142 If the second octet of the authentication-type-pair has the AUTH_WHO 143 bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial 144 AUTH command, and the client responds with either ACCEPT or REJECT. 145 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 146 client will send a RESPONSE before it sends the ACCEPT. 147 148 The Kerberos principal used by the server will generally be of the 149 form "host/<hostname>@realm". That is, the first component of the 150 Kerberos principal is "host"; the second component is the fully qual- 151 ified lower-case hostname of the server; and the realm is the Ker- 152 beros realm to which the server belongs. 153 154 Expires Sept 2000 [Page 3] 155 156Internet-Draft Kerberos Version 5 for Telnet April 2000 157 158 Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP 159 messages, the KRB_CRED structure, or the optional rejection text 160 string must be doubled as specified in [4]. Otherwise the following 161 byte might be mis-interpreted as a Telnet command. 162 1634. Examples 164 165 User "joe" may wish to log in as user "pete" on machine "foo". If 166 "pete" has set things up on "foo" to allow "joe" access to his ac- 167 count, then the client would send IAC SB AUTHENTICATION NAME "pete" 168 IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> 169 IAC SE 170 171 The server would then authenticate the user as "joe" from the 172 KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by 173 Kerberos, and if "pete" has allowed "joe" to use his account, the 174 server would then continue the authentication sequence by sending a 175 RESPONSE (to do mutual authentication, if it was requested) followed 176 by the ACCEPT. 177 178 If forwarding has been requested, the client then sends IAC SB AU- 179 THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure 180 with credentials to be forwarded> IAC SE. If the server succeeds in 181 reading the forwarded credentials, the server sends FORWARD_ACCEPT 182 else, a FORWARD_REJECT is sent back. 183 184 Client Server 185 IAC DO AUTHENTICATION 186 IAC WILL AUTHENTICATION 187 188 [ The server is now free to request authentication information. 189 ] 190 191 IAC SB AUTHENTICATION SEND 192 KERBEROS_V5 CLIENT|MUTUAL 193 KERBEROS_V5 CLIENT|ONE_WAY IAC 194 SE 195 196 [ The server has requested mutual Version 5 Kerberos 197 authentication. If mutual authentication is not supported, 198 then the server is willing to do one-way authentication. 199 200 The client will now respond with the name of the user that it 201 wants to log in as, and the Kerberos ticket. ] 202 203 IAC SB AUTHENTICATION NAME 204 "pete" IAC SE 205 IAC SB AUTHENTICATION IS 206 KERBEROS_V5 CLIENT|MUTUAL AUTH 207 <KRB_AP_REQ message> IAC SE 208 209 Expires Sept 2000 [Page 4] 210 211Internet-Draft Kerberos Version 5 for Telnet April 2000 212 213 [ Since mutual authentication is desired, the server sends across 214 a RESPONSE to prove that it really is the right server. ] 215 216 IAC SB AUTHENTICATION REPLY 217 KERBEROS_V5 CLIENT|MUTUAL 218 RESPONSE <KRB_AP_REP message> 219 IAC SE 220 221 [ The server responds with an ACCEPT command to state that the 222 authentication was successful. ] 223 224 IAC SB AUTHENTICATION REPLY KER- 225 BEROS_V5 CLIENT|MUTUAL ACCEPT 226 IAC SE 227 228 [ If so requested, the client now sends the FORWARD command to 229 forward credentials to the remote site. ] 230 231 IAC SB AUTHENTICATION IS KER- 232 BEROS_V5 CLIENT|MUTUAL 233 FORWARD <KRB_CRED message> IAC 234 SE 235 236 [ The server responds with a FORWARD_ACCEPT command to state that 237 the credential forwarding was successful. ] 238 239 Expires Sept 2000 [Page 5] 240 241Internet-Draft Kerberos Version 5 for Telnet April 2000 242 243 IAC SB AUTHENTICATION REPLY KER- 244 BEROS_V5 CLIENT|MUTUAL FOR- 245 WARD_ACCEPT IAC SE 246 2475. Security Considerations 248 249 The selection of the random session key in the Kerberos V5 authenti- 250 cator is critical, since this key will be used for encrypting the 251 telnet data stream if encryption is enabled. It is strongly advised 252 that the random key selection be done using cryptographic techniques 253 that involve the Kerberos ticket's session key. For example, using 254 the current time, encrypting it with the ticket session key, and then 255 correcting for key parity is a strong way to generate a subsession 256 key, since the ticket session key is assumed to be never disclosed to 257 an attacker. 258 259 Care should be taken before forwarding a user's Kerberos credentials 260 to the remote server. If the remote server is not trustworthy, this 261 could result in the user's credentials being compromised. Hence, the 262 user interface should not forward credentials by default; it would be 263 far safer to either require the user to explicitly request creden- 264 tials forwarding for each connection, or to have a trusted list of 265 hosts for which credentials forwarding is enabled, but to not enable 266 credentials forwarding by default for all machines. 267 2686. IANA Considerations 269 270 The authentication type KERBEROS_V5 and its associated suboption values 271 are registered with IANA. Any suboption values used to extend 272 the protocol as described in this document must be registered 273 with IANA before use. IANA is instructed not to issue new suboption 274 values without submission of documentation of their use. 275 2767. Acknowledgments 277 278 This document was originally written by Dave Borman of Cray Research, 279 Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- 280 tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- 281 tion Sciences Institute developed the credential forwarding support. 282 283 In addition, the contributions of the Telnet Working Group are also 284 gratefully acknowledged. 285 2868. References 287 288 [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- 289 tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem- 290 ber 1993. 291 292 [2] Internet Engineering Task Force, "Telnet Authentication", draft- 293 tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, 294 April 2000. 295 296 [3] Internet Engineering Task Force, "Telnet Data Encryption Option", 297 draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux 298 Systems, April 2000. 299 300 [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC 301 302 Expires Sept 2000 [Page 6] 303 304Internet-Draft Kerberos Version 5 for Telnet April 2000 305 306 855, STD 8, USC/Information Sciences Institute, May 1983. 307 308Editor's Address 309 310 Theodore Ts'o 311 Massachusetts Institute of Technology 312 MIT Room E40-343 313 77 Massachusetts Avenue 314 Cambridge, MA 02139 315 316 Phone: (617) 253-8091 317 EMail: tytso@mit.edu 318 319 Expires Sept 2000 [Page 7] 320 321 322 Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 323 The Kermit Project * Columbia University 324 612 West 115th St #716 * New York, NY * 10025 325 http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org 326 327 328