idnits 2.17.1 draft-ietf-secsh-auth-kbdinteract-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 105: '...ONSE message. The server MUST not send...' RFC 2119 keyword, line 122: '... server SHOULD use this language for...' RFC 2119 keyword, line 132: '... configuration setting, it MAY use the...' RFC 2119 keyword, line 134: '... MUST send the empty string....' RFC 2119 keyword, line 153: '... The server MUST reply with either a...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 115 has weird spacing: '... string user ...' == Line 116 has weird spacing: '... string servi...' == Line 118 has weird spacing: '... string langu...' == Line 119 has weird spacing: '... string subme...' == Line 179 has weird spacing: '... string name ...' == (6 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The client initiates the authentication with a SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with a SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with a SSH_MSG_USERAUTH_INFO_RESPONSE message. The server MUST not send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client. -- 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 (1 March 2001) is 8454 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) -- Looks like a reference, but probably isn't: '1' on line 244 == Unused Reference: 'RFC-2279' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'SSH-CONNECT' is defined on line 328, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 86 (ref. 'PAM') ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-06 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-08 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-08 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-08 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Forssen 3 INTERNET-DRAFT Appgate AB 4 draft-ietf-secsh-auth-kbdinteract-02.txt F. Cusack 5 Expires in six months Qwest Internet Solutions 6 1 March 2001 8 Generic Message Exchange Authentication For SSH 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 SSH is a protocol for secure remote login and other secure network 34 services over an insecure network. This document describes a general 35 purpose authentication method for the SSH protocol, suitable for 36 interactive authentications where the authentication data should be 37 entered via a keyboard. The major goal of this method is to allow 38 the SSH client to support a whole class of authentication 39 mechanism(s) without knowing the specifics of the actual 40 authentication mechanism(s). 42 1. Introduction 44 The SSH authentication protocol is a general-purpose user 45 authentication protocol. It is intended to be run over the SSH 46 transport layer protocol [SSH-TRANS]. The protocol assumes that the 47 underlying protocols provide integrity and confidentiality 48 protection. 50 This document describes a general purpose authentication method for 51 the SSH protocol. This method is suitable for interactive 52 authentication methods which does not need any special software 53 support on the client side. Instead all authentication data should be 54 entered via the keyboard. The major goal of this method is to allow 55 the SSH client to have little or no knowledge of the specifics of the 56 underlying authentication mechanism(s) used by the SSH server. This 57 will allow the server to arbitrarily select or change the underlying 58 authentication mechanism(s) without having to update client code. 60 The name for this authentication method is "keyboard-interactive". 62 This document should be read only after reading the SSH architecture 63 document [SSH-ARCH] and the SSH authentication document [SSH- 64 USERAUTH]. This document freely uses terminology and notation from 65 both documents without reference or further explanation. 67 This document also describes some of the client interaction with the 68 user in obtaining the authentication information. While this is 69 somewhat out of the scope of a protocol specification, it is still 70 described here since some aspects of the protocol are specifically 71 designed based on user interface issues, and omitting this 72 information may lead to incompatible or awkward implementations. 74 2. Rationale 76 Currently defined authentication methods for SSH are tightly coupled 77 with the underlying authentication mechanism. This makes it difficult 78 to add new mechanisms for authentication as all clients must be 79 updated to support the new mechanism. With the generic method defined 80 here, clients will not require code changes to support further new 81 authentication mechanisms, provided the mechanism fits the 82 requirements for keyboard-interactive. And if a separate 83 authentication layer is used, such as [PAM], then the server may not 84 need any code changes either. 86 This presents a significant advantage to other methods, such as the 87 "password" method (defined in [SSH-USERAUTH]), as new (presumably 88 stronger) methods may be added "at will" and system security can be 89 transparently enhanced. 91 Challenge-response and One Time Password mechanisms are also easily 92 supported with this authentication method. 94 This authentication method is however limited to authentication 95 mechanisms which do not require any special code, such as hardware 96 drivers or password mangling, on the client. 98 3. Protocol Exchanges 100 The client initiates the authentication with a 101 SSH_MSG_USERAUTH_REQUEST message. The server then requests 102 authentication information from the client with a 103 SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the 104 information from the user and then responds with a 105 SSH_MSG_USERAUTH_INFO_RESPONSE message. The server MUST not send 106 another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the 107 answer from the client. 109 3.1 Initial Exchange 111 The authentication starts with the client sending the following 112 packet: 114 byte SSH_MSG_USERAUTH_REQUEST 115 string user name (ISO-10646 UTF-8) 116 string service name (US-ASCII) 117 string "keyboard-interactive" (US-ASCII) 118 string language tag (as defined in [RFC-1766]) 119 string submethods (ISO-10646 UTF-8) 121 The language tag indicates the client's preferred language. The 122 server SHOULD use this language for all text that is to be presented 123 to the user in the subsequent exchanges. 125 If the server cannot support the requested language, the language to 126 be used is implementation-dependent. 128 The submethods field is included so the user can give a hint of which 129 actual methods he wants to use. It is a a comma-separated list of 130 authentication submethods (software or hardware) which the user 131 prefers. If the client has knowledge of the submethods preferred by 132 the user, presumably through a configuration setting, it MAY use the 133 submethods field to pass this information to the server. Otherwise it 134 MUST send the empty string. 136 The actual names of the submethods is something which the user and 137 the server needs to agree upon. 139 Server interpretation of the submethods field is implementation- 140 dependent. 142 One possible implementation strategy of the submethods field on the 143 server is that, unless the user may use multiple different 144 submethods, the server ignores this field. If the user may 145 authenticate using one of several different submethods the server 146 should treat the submethods field as a hint on which submethod the 147 user wants to use this time. 149 Note that when this message is sent to the server, the client has not 150 yet prompted the user for a password, and so that information is NOT 151 included with this initial message (unlike the "password" method). 153 The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, 154 SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. 156 The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message 157 if the failure is based on the user name or service name; instead it 158 SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just 159 like the one(s) which would have been sent in cases where 160 authentication should proceed, and then send the failure message 161 (after a suitable delay, as described below). The goal is to make it 162 impossible to find valid user names by just comparing the results 163 when authenticating as different users. 165 3.2 Information Requests 167 Requests are generated from the server using the 168 SSH_MSG_USERAUTH_INFO_REQUEST message. 170 The server may send as many requests as are necessary to authenticate 171 the client; the client MUST be prepared to handle multiple exchanges. 172 However the server MUST never have more than one 173 SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is it may not 174 send another request before the client has answered. 176 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: 178 byte SSH_MSG_USERAUTH_INFO_REQUEST 179 string name (ISO-10646 UTF-8) 180 string instruction (ISO-10646 UTF-8) 181 string language tag (as defined in [RFC-1766]) 182 int num-prompts 183 string prompt[1] (ISO-10646 UTF-8) 184 boolean echo[1] 185 ... 186 string prompt[num-prompts] (ISO-10646 UTF-8) 187 boolean echo[num-prompts] 189 The server SHOULD limit the length of the name and prompt fields to 190 30 characters. No restrictions are placed on the instruction field. 192 The name and instruction fields MAY be empty strings, the client MUST 193 be prepared to handle this correctly. 195 The num-prompts field may be `0', in which case there will be no 196 prompt/echo fields in the message, but the client MUST still display 197 the name and instruction fields (as described below). 199 3.3 User Interface 201 Upon receiving a request message, the client SHOULD prompt the user 202 as follows: 204 A command line interface (CLI) client SHOULD print the name and 205 instruction (if non-empty), adding newlines. Then for each prompt in 206 turn, the client MUST display the prompt and read the user input. 208 A graphical user interface (GUI) client SHOULD present a dialog 209 window, using the name (if non-empty) as the title of the window, the 210 instruction (if non-empty) as a text message inside the dialog, and 211 the appropriate number of entry fields with the prompts as labels. A 212 GUI client SHOULD NOT present each prompt in a separate window. 214 All clients MUST properly handle an instruction field with embedded 215 newlines. They MUST also be able to display at least 30 characters 216 for the name and prompts. If the server presents names/prompts 217 longer than 30 characters, the client MAY truncate these fields to 218 the length it can display. If the client does truncate any fields, 219 there SHOULD be an obvious indication that such truncation has 220 occurred. 222 Clients SHOULD use control character filtering as discussed in [SSH- 223 ARCH] to avoid attacks by including terminal control characters in 224 the fields to be displayed. 226 For each prompt, the corresponding echo field indicates whether or 227 not the user input should be echoed or not. Clients SHOULD correctly 228 handle echo for each prompt independently of other prompts in the 229 request message. Clients SHOULD NOT add any additional characters to 230 the prompt such as ": "; the server is responsible for supplying all 231 text to be displayed to the user. Clients MUST also accept empty 232 responses from the user and pass them on as empty strings. 234 3.4 Information Responses 236 After obtaining the requested information from the user, the client 237 MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. 239 The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as 240 follows: 242 byte SSH_MSG_USERAUTH_INFO_RESPONSE 243 int num-responses 244 string response[1] (ISO-10646 UTF-8) 245 ... 246 string response[num-responses] (ISO-10646 UTF-8) 248 Note that the responses are encoded in ISO-10646 UTF-8. It is up to 249 the server how it interprets the responses and validates them. 250 However, if the client reads the responses in some other encoding 251 (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 252 before transmitting. 254 If the num-responses field does not match the num-prompts field in 255 the request message, the server MUST send a failure message. 257 In the case that the server sends a `0' num-prompts field in the 258 request message, the client MUST send a response message with a `0' 259 num-responses field. 261 After receiving the response, the server MUST send either a 262 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 263 SSH_MSG_USERAUTH_INFO_REQUEST message. 265 If the server fails to authenticate the user (through the underlying 266 authentication mechanism(s)), it SHOULD NOT send another request 267 message(s) in an attempt to obtain new authentication data, instead 268 it SHOULD send a failure message. The only time the server should 269 send multiple request messages is if additional authentication data 270 is needed (i.e., because there are multiple underlying authentication 271 mechanisms that must be used to authenticate the user). 273 If the server intends to respond with a failure message, it MAY delay 274 for an implementation dependent time before sending to the client. 275 It is suspected that implementations are likely to make the time 276 delay a configurable, a suggested default is 2 seconds. 278 4. Authentication Example 280 Here is an example exchange between a client and server: 282 C: byte SSH_MSG_USERAUTH_REQUEST 283 C: string "user23" 284 C: string "ssh-userauth" 285 C: string "keyboard-interactive" 286 C: string "en-US" 287 C: string "" 289 S: byte SSH_MSG_USERAUTH_INFO_REQUEST 290 S: string "CryptoCARD Authentication" 291 S: string "The challenge is '14315716'" 292 S: string "en-US" 293 S: int 1 294 S: string "Response: " 295 S: boolean TRUE 297 [Client prompts user for password] 299 C: byte SSH_MSG_USERAUTH_INFO_RESPONSE 300 C: int 1 301 C: string "6d757575" 303 S: byte SSH_MSG_USERAUTH_SUCCESS 305 5. Protocol constants 307 The following method-specific constants are used with this 308 authentication method: 310 SSH_MSG_USERAUTH_INFO_REQUEST 60 311 SSH_MSG_USERAUTH_INFO_RESPONSE 61 313 6. References 315 [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable 316 Authentication Modules (PAM)", OSF RFC 86.0, October 1995 318 [RFC-1766] Alvestrand, H., "Tags for the Identification of 319 Languages", March 1995. 321 [RFC-2279] Yergeau, F., "UTF-8, a Transformation Format of Unicode 322 and ISO 10646", October 1996. 324 [SSH-ARCH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. 325 Lehtinen, "SSH Protocol Architecture", Internet Draft, draft-ietf- 326 secsh-architecture-06.txt 328 [SSH-CONNECT] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. 329 Lehtinen, "SSH Connection Protocol", Internet Draft, draft-ietf- 330 secsh-connect-08.txt 332 [SSH-TRANS] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. 333 Lehtinen, "SSH Transport Layer Protocol", Internet Draft, draft- 334 ietf-secsh-transport-08.txt 336 [SSH-USERAUTH] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. 337 Lehtinen, "SSH Authentication Protocol", Internet Draft, draft-ietf- 338 secsh-userauth-08.txt 340 7. Author's Addresses 342 Frank Cusack 343 Qwest Internet Solutions 344 1200 Harbor Blvd, 8th Fl. 345 Weehawken, NJ 07087 346 Email: fcusack@iconnet.net 348 Martin Forssen 349 Appgate AB 350 Stora Badhusgatan 18-20 351 SE-411 21 Gothenburg 352 SWEDEN 353 Email: maf@appgate.com