idnits 2.17.1 draft-ietf-telnet-authentication-04.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-26) 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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == 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 a Security Considerations 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 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 223: '...entication types MUST be ordered to in...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1992) is 11608 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) -- Missing reference section? '1' on line 278 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Internet Engineering Task Force 3 Internet-Draft Telnet Working Group 4 D. Borman, Editor 5 Cray Research, Inc. 6 July 1992 8 Telnet Authentication Option 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the 1id-abstracts.txt listing contained in the 24 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 25 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 26 current status of any Internet Draft. 28 1. Command Names and Codes 30 AUTHENTICATION 37 31 IS 0 32 SEND 1 33 REPLY 2 34 NAME 3 36 Authentication Types 37 NULL 0 38 KERBEROS_V4 1 39 KERBEROS_V5 2 40 SPX 3 41 RSA 6 42 LOKI 10 44 Modifiers 45 AUTH_WHO_MASK 1 46 AUTH_CLIENT_TO_SERVER 0 47 AUTH_SERVER_TO_CLIENT 1 48 AUTH_HOW_MASK 2 49 AUTH_HOW_ONE_WAY 0 50 AUTH_HOW_MUTUAL 2 52 2. Command Meanings 54 This document makes reference to a "server" and a "client". For the 55 purposes of this document, the "server" is the side of the connection 56 that did the passive TCP open (TCP LISTEN state), and the "client" is 57 the side of the connection that did the active open. 59 IAC WILL AUTHENTICATION 61 The client side of the connection sends this command to indicate 62 that it is willing to send and receive authentication information. 64 IAC DO AUTHENTICATION 66 The servers side of the connection sends this command to indicate 67 that it is willing to send and receive authentication information. 69 IAC WONT AUTHENTICATION 71 The client side of the connection sends this command to indicate 72 that it refuses to send or receive authentication information; the 73 server side sends this command if it receives a DO AUTHENTICATION 74 command. 76 IAC DONT AUTHENTICATION 78 The server side of the connection sends this command to indicate 79 that it refuses to send or receive authentication information; the 80 client side sends this command if it receives a WILL AUTHENTICA- 81 TION command. 83 IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE 85 The sender of this command (the server) requests that the remote 86 side send authentication information for one of the authentication 87 types listed in "authentication-type-pair-list". The 88 "authentication-type-pair-list" is an ordered list of 89 "authentication-type" pairs. Only the server side (DO AUTHENTICA- 90 TION) is allowed to send this. 92 IAC SB AUTHENTICATION IS authentication-type-pair IAC SE 94 The sender of this command (the client) is sending the authentica- 95 tion information for authentication type "authentication-type- 96 pair". Only the client side (WILL AUTHENTICATION) is allowed to 97 send this. 99 IAC SB AUTHENTICATION REPLY authentication-type-pair IAC 100 SE 102 The sender of this command (the server) is sending a reply to the 103 the authentication information received in a previous IS command. 104 Only the server side (DO AUTHENTICATION) is allowed to send this. 106 IAC SB AUTHENTICATION NAME remote-user IAC SE 108 This optional command is sent to specify the account name on the 109 remote host that the user wishes to be authorized to use. Note 110 that authentication may succeed, and the authorization to use a 111 particular account may still fail. Some authentication mechanisms 112 may ignore this command. 114 The "authentication-type-pair" is two octets, the first is the au- 115 thentication type, and the second is a modifier to the type. There 116 are currently two one bit fields defined in the modifier, the 117 AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit, so there are four possi- 118 ble combinations: 120 AUTH_CLIENT_TO_SERVER 121 AUTH_HOW_ONE_WAY 123 The client will send authentication information about the local 124 user to the server. If the negotiation is successful, the 125 server will have authenticated the user on the client side of 126 the connection. 128 AUTH_SERVER_TO_CLIENT 129 AUTH_HOW_ONE_WAY 131 The server will authenticate itself to the client. If the 132 negotiation is successful, the client will know that it is con- 133 nected to the server that it wants to be connected to. 135 AUTH_CLIENT_TO_SERVER 136 AUTH_HOW_MUTUAL 138 The client will send authentication information about the local 139 user to the server, and then the server will authenticate it- 140 self to the client. If the negotiation is successful, the 141 server will have authenticated the user on the client side of 142 the connection, and the client will know that it is connected 143 to the server that it wants to be connected to. 145 AUTH_SERVER_TO_CLIENT 146 AUTH_HOW_MUTUAL 147 The server will authenticate itself to the client, and then the 148 client will authenticate itself to the server. If the negotia- 149 tion is successful, the client will know that it is connected 150 to the server that it wants to be connected to, and the server 151 will know that the client is who it claims to be. 153 3. Default Specification 155 The default specification for this option is 157 WONT AUTHENTICATION 158 DONT AUTHENTICATION 160 meaning there will not be any exchange of authentication information. 162 4. Motivation 164 One of the deficiences of the Telnet protocol is that in order to log 165 into remote systems, users have to type their passwords, which are 166 passed in clear text through the network. If the connections goes 167 through untrusted networks, there is the possibility that passwords 168 will be compromised by someone watching the packets as they go by. 170 The purpose of the AUTHENTICATION option is to provide a framework 171 for the passing of authentication information through the TELNET ses- 172 sion. This means that: 1) the users password will not be sent in 173 clear text across the network, and 2) if the front end telnet process 174 has the appropriate authentication information, it can automatically 175 send the information, and the user will not have to type any pass- 176 word. 178 It is intended that the AUTHENTICATION option be general enough that 179 it can be used to pass information for any authentication system. 181 5. Security Implications 183 The ability to negotiate a common authentication mechanism between 184 client and server is a feature of the authentication option that 185 should be used with caution. When the negotiation is performed, no 186 authentication has yet occurred. Therefore each system has no way of 187 knowing whether or not it is talking to the system it intends. An in- 188 truder could attempt to negotiate the use of an authentication system 189 which is either weak, or already compromised by the intruder. 191 6. Implementation Rules 193 WILL and DO are used only at the beginning of the connection to ob- 194 tain and grant permission for future negotiations. 196 The authentication is only negotiated in one directions; the server 197 must send the "DO", and the client must send the "WILL". This res- 198 triction is due to the nature of authentication; there are three pos- 199 sible cases; server authenticates client, client authenticates 200 server, and server and client authenticate each other. By only nego- 201 tiating the option in one direction, and then determining which of 202 the three cases is being used via the suboption, potential ambiguity 203 is removed. If the server receives a "DO", it must respond with a 204 "WONT". If the client receives a "WILL", it must respond with a 205 "DONT". 207 Once the two hosts have exchanged a DO and a WILL, the server is free 208 to request authentication information. In the request, a list of 209 supported authentication types is sent. Only the server may send re- 210 quests ("IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC 211 SE"). Only the client may transmit authentication information via 212 the "IAC SB AUTHENTICATION IS authentication-type ... IAC SE" com- 213 mand. Only the server may send replys ("IAC SB AUTHENTICATION REPLY 214 authentication-type ... IAC SE"). As many IS and REPLY suboptions 215 may be exchanged as are needed for the particular authentication 216 scheme chosen. 218 If the client does not support any of the authentication types listed 219 in the authentication-type-pair-list, a type of NULL should be used 220 to indicate this in the IS reply. Note that in this case, the server 221 may choose to close the connection. 223 The order of the authentication types MUST be ordered to indicate a 224 preference for different authentication types, the first type being 225 the most preferred, and the last type the least preferred. 227 The following is an example of use of the option: 229 Client Server 230 IAC DO AUTHENTICATION 231 IAC WILL AUTHENTICATION 232 [ The server is now free to request authentication information. 233 ] 234 IAC SB AUTHENTICATION SEND 235 KERBEROS_V4 CLIENT|MUTUAL 236 KERBEROS_V4 CLIENT|ONE_WAY IAC 237 SE 238 [ The server has requested mutual Kerberos authentication, but is 239 willing to do just one-way Kerberos authentication. The client 240 will now respond with the name of the user that it wants to log 241 in as, and the Kerberos ticket. ] 242 IAC SB AUTHENTICATION NAME "joe" 243 IAC SE 244 IAC SB AUTHENTICATION IS 245 KERBEROS_V4 CLIENT|MUTUAL AUTH 4 246 7 1 67 82 65 89 46 67 7 9 77 0 247 48 24 49 244 109 240 50 208 43 248 35 25 116 104 44 167 21 201 224 249 229 145 20 2 244 213 220 33 134 250 148 4 251 249 233 229 152 77 2 251 109 130 231 33 146 190 248 1 9 252 31 95 94 15 120 224 0 225 76 205 253 70 136 245 190 199 147 155 13 254 IAC SE 255 [ The server responds with an ACCEPT command to state that the 256 authentication was successful. ] 257 IAC SB AUTHENTICATION REPLY 258 KERBEROS_V4 CLIENT|MUTUAL ACCEPT 259 IAC SE 260 [ Next, the client sends across a CHALLENGE to verify that it is 261 really talking to the right server. ] 262 IAC SB AUTHENTICATION REPLY 263 KERBEROS_V4 CLIENT|MUTUAL 264 CHALLENGE xx xx xx xx xx xx xx 265 xx IAC SE 266 [ Lastly, the server sends across a RESPONSE to prove that it 267 really is the right server. 268 IAC SB AUTHENTICATION REPLY 269 KERBEROS_V4 CLIENT|MUTUAL 270 RESPONSE yy yy yy yy yy yy yy yy 271 IAC SE 273 It is expected that any implementation that supports the Telnet AU- 274 THENTICATION option will support all of this specification. 276 7. References 278 [1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 1060, 279 ISI, March 1990 281 Author's Address 283 David A. Borman, Editor 284 Cray Research, Inc. 285 655F Lone Oak Drive 286 Eagan, MN 55123 288 Phone: (612) 452-6650 290 Mailing List: telnet-ietf@CRAY.COM 291 EMail: dab@CRAY.COM 293 Chair's Address 294 The working group can be contacted via the current chair: 296 Steve Alexander 297 INTERACTIVE Systems Corporation 298 1901 North Naper Boulevard 299 Naperville, IL 60563-8895 301 Phone: (708) 505-9100 x256 302 EMail: stevea@isc.com