idnits 2.17.1 draft-tso-telnet-krb5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 Introduction 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (February 1998) is 9561 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) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Ts'o, Editor 3 Internet-Draft Massachusetts Institute of Technology 4 draft-tso-telnet-krb5-00.txt February 1998 6 Telnet Authentication: Kerberos Version 5 8 Status of this Memo 10 This document is an Internet-Draft. 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 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Command Names and Codes 28 Authentication Types 30 KERBEROS_V5 2 32 Sub-option Commands 34 AUTH 0 35 REJECT 1 36 ACCEPT 2 37 RESPONSE 3 38 FORWARD 4 39 FORWARD_ACCEPT 5 40 FORWARD_REJECT 6 42 2. Command Meanings 44 IAC SB AUTHENTICATION IS AUTH IAC SE 47 This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the 48 remote side of the connection. The first octet of the 49 value is KERBEROS_V5, to indicate that 50 Version 5 of Kerberos is being used. The Kerberos V5 51 authenticator in the KRB_AP_REQ message must contain a Kerberos V5 52 checksum of the two-byte authentication type pair. This checksum 53 must be verified by the server to assure that the authentication 54 type pair was correctly negotiated. The Kerberos V5 authenticator 55 must also include the optional subkey field, which shall be filled 56 in with a randomly chosen key. This key shall be used for 57 encryption purposes if encryption is negotiated, and shall be 58 assigned keyid 0 for the purposes of the telnet encryption option. 60 IAC SB AUTHENTICATION REPLY ACCEPT IAC SE 62 This command indicates that the authentication was successful. 64 If the AUTH_HOW_MUTUAL bit is set in the second octet of the 65 authentication-type-pair, the RESPONSE command must be sent before 66 the ACCEPT command is sent. 68 IAC SB AUTHENTICATION REPLY REJECT 69 IAC SE 71 This command indicates that the authentication was not successful, 72 and if there is any more data in the sub-option, it is an ASCII 73 text message of the reason for the rejection. 75 IAC SB AUTHENTICATION REPLY RESPONSE 76 IAC SE 78 This command is used to perform mutual authentication. It is only 79 used when the AUTH_HOW_MUTUAL bit is set in the second octet of 80 the authentication-type-pair. After an AUTH command is verified, 81 a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP 82 message to perform the mutual authentication. 84 IAC SB AUTHENTICATION FORWARD IAC SE 87 This command is used to forward kerberos credentials for use by 88 the remote session. The credentials are passed as a Kerberos V5 89 KRB_CRED message which includes, among other things, the forwarded 90 Kerberos ticket and a session key associated with the ticket. Part 91 of the KRB_CRED message is encrypted in the key previously 92 exchanged for the telnet session by the AUTH subobption. 94 IAC SB AUTHENTICATION FORWARD_ACCEPT IAC 95 SE 97 This command indicates that the credential forwarding was 98 successful. 100 IAC SB AUTHENTICATION FORWARD_REJECT 101 IAC SE 103 This command indicates that the credential forwarding was not 104 successful, and if there is any more data in the sub-option, it is 105 an ASCII text message of the reason for the rejection. 107 3. Implementation Rules 109 If the second octet of the authentication-type-pair has the AUTH_WHO 110 bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial 111 AUTH command, and the server responds with either ACCEPT or REJECT. 112 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 113 server will send a RESPONSE before it sends the ACCEPT. 115 If the second octet of the authentication-type-pair has the AUTH_WHO 116 bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial 117 AUTH command, and the client responds with either ACCEPT or REJECT. 118 In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the 119 client will send a RESPONSE before it sends the ACCEPT. 121 The Kerberos principal used by the server will generally be of the 122 form "host/@realm". That is, the first component of the 123 Kerberos principal is "host"; the second component is the fully 124 qualified lower-case hostname of the server; and the realm is the 125 Kerberos realm to which the server belongs. 127 Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP 128 messages, the KRB_CRED structure, or the optional rejection text 129 string must be doubled as specified in [2]. Otherwise the following 130 byte might be mis-interpreted as a Telnet command. 132 4. Examples 134 User "joe" may wish to log in as user "pete" on machine "foo". If 135 "pete" has set things up on "foo" to allow "joe" access to his 136 account, then the client would send IAC SB AUTHENTICATION NAME "pete" 137 IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH 138 IAC SE 140 The server would then authenticate the user as "joe" from the 141 KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by 142 Kerberos, and if "pete" has allowed "joe" to use his account, the 143 server would then continue the authentication sequence by sending a 144 RESPONSE (to do mutual authentication, if it was requested) followed 145 by the ACCEPT. 147 If forwarding has been requested, the client then sends IAC SB 148 AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD IAC SE. If the server 150 succeeds in reading the forwarded credentials, the server sends 151 FORWARD_ACCEPT else, a FORWARD_REJECT is sent back. 153 Client Server 154 IAC DO AUTHENTICATION 155 IAC WILL AUTHENTICATION 157 [ The server is now free to request authentication information. 158 ] 160 IAC SB AUTHENTICATION SEND 161 KERBEROS_V5 CLIENT|MUTUAL 162 KERBEROS_V5 CLIENT|ONE_WAY IAC 163 SE 165 [ The server has requested mutual Version 5 Kerberos 166 authentication. If mutual authentication is not supported, 167 then the server is willing to do one-way authentication. 169 The client will now respond with the name of the user that it 170 wants to log in as, and the Kerberos ticket. ] 172 IAC SB AUTHENTICATION NAME 173 "pete" IAC SE 174 IAC SB AUTHENTICATION IS 175 KERBEROS_V5 CLIENT|MUTUAL AUTH 176 IAC SE 178 [ Since mutual authentication is desired, the server sends across 179 a RESPONSE to prove that it really is the right server. ] 181 IAC SB AUTHENTICATION REPLY 182 KERBEROS_V5 CLIENT|MUTUAL 183 RESPONSE 184 IAC SE 186 [ The server responds with an ACCEPT command to state that the 187 authentication was successful. ] 189 IAC SB AUTHENTICATION REPLY 190 KERBEROS_V5 CLIENT|MUTUAL ACCEPT 191 IAC SE 193 [ If so requested, the client now sends the FORWARD command to 194 forward credentials to the remote site. ] 196 IAC SB AUTHENTICATION IS 197 KERBEROS_V5 CLIENT|MUTUAL 198 FORWARD IAC 199 SE 201 [ The server responds with a FORWARD_ACCEPT command to state that 202 the credential forwarding was successful. ] 203 IAC SB AUTHENTICATION REPLY 204 KERBEROS_V5 CLIENT|MUTUAL 205 FORWARD_ACCEPT IAC SE 206 5. Security Considerations 208 The selection of the random session key in the Kerberos V5 authenti- 209 cator is critical, since this key will be used for encrypting the 210 telnet data stream if encryption is enabled. It is strongly advised 211 that the random key selection be done using cryptographic techniques 212 that involve the Kerberos ticket's session key. For example, using 213 the current time, encrypting it with the ticket session key, and then 214 correcting for key parity is a strong way to generate a subsession 215 key, since the ticket session key is assumed to be never disclosed to 216 an attacker. 218 Care should be taken before forwarding a user's Kerberos credentials 219 to the remote server. If the remote server is not trustworthy, this 220 could result in the user's credentials being compromised. Hence, the 221 user interface should not forward credentials by default; it would be 222 far safer to either require the user to explicitly request creden- 223 tials forwarding for each connection, or to have a trusted list of 224 hosts for which credentials forwarding is enabled, but to not enable 225 credentials forwarding by default for all machines. 226 6. Acknowledgements 228 This document was originally written by Dave Borman of Cray Research, 229 Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- 230 tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- 231 tion Sciences Institute developed the credential forwarding support. 233 In addition, the contributions of the Telnet Working Group are also 234 gratefully acknowledged. 236 7. References 238 [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- 239 tem (V5)", RFC 1510, USC/Information Sciences Institute, Sep- 240 tember 1993. 242 [2] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC 243 855, STD 8, USC/Information Sciences Institute, May 1983. 245 Editor's Address 247 Theodore Ts'o 248 Massachusetts Institute of Technology 249 MIT Room E40-343 250 77 Massachusetts Avenue 251 Cambridge, MA 02139 252 Phone: (617) 253-8091 253 EMail: tytso@mit.edu