idnits 2.17.1 draft-ietf-secsh-userauth-27.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 710. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 137 has weird spacing: '... string dat...' == Line 180 has weird spacing: '... string use...' == Line 181 has weird spacing: '... string ser...' == Line 182 has weird spacing: '... string met...' == Line 234 has weird spacing: '...me-list aut...' == (41 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 14, 2005) is 6981 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) == Unused Reference: 'RFC3629' is defined on line 646, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ylonen 2 Internet-Draft SSH Communications Security Corp 3 Expires: September 15, 2005 C. Lonvick, Ed. 4 Cisco Systems, Inc. 5 March 14, 2005 7 SSH Authentication Protocol 8 draft-ietf-secsh-userauth-27.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 15, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 SSH is a protocol for secure remote login and other secure network 44 services over an insecure network. This document describes the SSH 45 authentication protocol framework and public key, password, and 46 host-based client authentication methods. Additional authentication 47 methods are described in separate documents. The SSH authentication 48 protocol runs on top of the SSH transport layer protocol and provides 49 a single authenticated tunnel for the SSH connection protocol. 51 Table of Contents 53 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . 3 56 4. The Authentication Protocol Framework . . . . . . . . . . . 4 57 5. Authentication Requests . . . . . . . . . . . . . . . . . . 5 58 5.1 Responses to Authentication Requests . . . . . . . . . . . 6 59 5.2 The "none" Authentication Request . . . . . . . . . . . . 7 60 5.3 Completion of User Authentication . . . . . . . . . . . . 7 61 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7 62 6. Authentication Protocol Message Numbers . . . . . . . . . . 8 63 7. Public Key Authentication Method: publickey . . . . . . . . 8 64 8. Password Authentication Method: password . . . . . . . . . . 10 65 9. Host-Based Authentication: hostbased . . . . . . . . . . . . 12 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 67 11. Security Considerations . . . . . . . . . . . . . . . . . . 14 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . 14 70 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 72 A. Trademark Notice . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . 16 75 1. Contributors 77 The major original contributors of this set of documents have been: 78 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 79 Communications Security Corp), and Markku-Juhani O. Saarinen 80 (University of Jyvaskyla). Darren Moffit was the original editor of 81 this set of documents and also made very substantial contributions. 83 Many people contributed to the development of this document over the 84 years. People who should be acknowledged include Mats Andersson, Ben 85 Harris, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, 86 Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, 87 Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken 88 Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels 89 Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, 90 Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their 91 names here does not mean that they endorse this document, but that 92 they have contributed to it. 94 2. Introduction 96 The SSH authentication protocol is a general-purpose user 97 authentication protocol. It is intended to be run over the SSH 98 transport layer protocol [SSH-TRANS]. This protocol assumes that the 99 underlying protocols provide integrity and confidentiality 100 protection. 102 This document should be read only after reading the SSH architecture 103 document [SSH-ARCH]. This document freely uses terminology and 104 notation from the architecture document without reference or further 105 explanation. 107 The 'service name' for this protocol is "ssh-userauth". 109 When this protocol starts, it receives the session identifier from 110 the lower-level protocol (this is the exchange hash H from the first 111 key exchange). The session identifier uniquely identifies this 112 session and is suitable for signing in order to prove ownership of a 113 private key. This protocol also needs to know whether the 114 lower-level protocol provides confidentiality protection. 116 3. Conventions Used in This Document 118 All documents related to the SSH protocols shall use the keywords 119 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 120 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 121 requirements. These keywords are to be interpreted as described in 122 [RFC2119]. 124 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 125 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 126 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 127 this document when used to describe namespace allocation are to be 128 interpreted as described in [RFC2434]. 130 Protocol fields and possible values to fill them are defined in this 131 set of documents. Protocol fields will be defined in the message 132 definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as 133 follows. 135 byte SSH_MSG_CHANNEL_DATA 136 uint32 recipient channel 137 string data 139 Throughout these documents, when the fields are referenced, they will 140 appear within single quotes. When values to fill those fields are 141 referenced, they will appear within double quotes. Using the above 142 example, possible values for 'data' are "foo" and "bar". 144 4. The Authentication Protocol Framework 146 The server drives the authentication by telling the client which 147 authentication methods can be used to continue the exchange at any 148 given time. The client has the freedom to try the methods listed by 149 the server in any order. This gives the server complete control over 150 the authentication process if desired, but also gives enough 151 flexibility for the client to use the methods it supports or that are 152 most convenient for the user, when multiple methods are offered by 153 the server. 155 Authentication methods are identified by their name, as defined in 156 [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 157 supported. However, it MAY be sent by the client. The server MUST 158 always reject this request, unless the client is to be allowed in 159 without any authentication, in which case the server MUST accept this 160 request. The main purpose of sending this request is to get the list 161 of supported methods from the server. 163 The server SHOULD have a timeout for authentication, and disconnect 164 if the authentication has not been accepted within the timeout 165 period. The RECOMMENDED timeout period is 10 minutes. Additionally, 166 the implementation SHOULD limit the number of failed authentication 167 attempts a client may perform in a single session (the RECOMMENDED 168 limit is 20 attempts). If the threshold is exceeded, the server 169 SHOULD disconnect. 171 Additional thoughts about authentication timeouts and retries may be 172 found in [ssh-1.2.30]. 174 5. Authentication Requests 176 All authentication requests MUST use the following message format. 177 Only the first few fields are defined; the remaining fields depend on 178 the authentication method. 179 byte SSH_MSG_USERAUTH_REQUEST 180 string user name in ISO-10646 UTF-8 encoding 181 string service name in US-ASCII 182 string method name in US-ASCII 183 The rest of the packet is method-specific. 185 The 'user name' and 'service name' are repeated in every new 186 authentication attempt, and MAY change. The server implementation 187 MUST carefully check them in every message, and MUST flush any 188 accumulated authentication states if they change. If it is unable to 189 flush some authentication state, it MUST disconnect if the 'user 190 name' or 'service name' changes. 192 The 'service name' specifies the service to start after 193 authentication. There may be several different authenticated 194 services provided. If the requested service is not available, the 195 server MAY disconnect immediately or at any later time. Sending a 196 proper disconnect message is RECOMMENDED. In any case, if the 197 service does not exist, authentication MUST NOT be accepted. 199 If the requested 'user name' does not exist, the server MAY 200 disconnect, or MAY send a bogus list of acceptable authentication 201 'method name' values, but never accept any. This makes it possible 202 for the server to avoid disclosing information on which accounts 203 exist. In any case, if the 'user name' does not exist, the 204 authentication request MUST NOT be accepted. 206 While there is usually little point for clients to send requests that 207 the server does not list as acceptable, sending such requests is not 208 an error, and the server SHOULD simply reject requests that it does 209 not recognize. 211 An authentication request MAY result in a further exchange of 212 messages. All such messages depend on the authentication 'method 213 name' used, and the client MAY at any time continue with a new 214 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 215 abandon the previous authentication attempt and continue with the new 216 one. 218 The following 'method name' values are defined. 220 public key REQUIRED 221 password OPTIONAL 222 hostbased OPTIONAL 223 none NOT RECOMMENDED 225 Additional 'method name' values may be defined as specified in 226 [SSH-ARCH] and [SSH-NUMBERS]. 228 5.1 Responses to Authentication Requests 230 If the server rejects the authentication request, it MUST respond 231 with the following: 233 byte SSH_MSG_USERAUTH_FAILURE 234 name-list authentications that can continue 235 boolean partial success 237 The 'authentications that can continue' is a comma-separated 238 name-list of authentication 'method name' values that may 239 productively continue the authentication dialog. 241 It is RECOMMENDED that servers only include those 'method name' 242 values in the name-list that are actually useful. However, it is not 243 illegal to include 'method name' values that cannot be used to 244 authenticate the user. 246 Already successfully completed authentications SHOULD NOT be included 247 in the name-list, unless they really should be performed again for 248 some reason. 250 The value of 'partial success' MUST be TRUE if the authentication 251 request to which this is a response was successful. It MUST be FALSE 252 if the request was not successfully processed. 254 When the server accepts authentication, it MUST respond with the 255 following: 257 byte SSH_MSG_USERAUTH_SUCCESS 259 Note that this is not sent after each step in a multi-method 260 authentication sequence, but only when the authentication is 261 complete. 263 The client MAY send several authentication requests without waiting 264 for responses from previous requests. The server MUST process each 265 request completely and acknowledge any failed requests with a 266 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 268 A request that results in further exchange of messages will be 269 aborted by a second request. It is not possible to send a second 270 request without waiting for a response from the server, if the first 271 request will result in further exchange of messages. No 272 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 274 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 275 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 276 requests received after that SHOULD be silently ignored. 278 Any non-authentication messages sent by the client after the request 279 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 280 to the service being run on top of this protocol. Such messages can 281 be identified by their message numbers (see Section 6). 283 5.2 The "none" Authentication Request 285 A client may request a list of authentication 'method name' values 286 that may continue by using the "none" authentication 'method name'. 288 If no authentication at all is needed for the user, the server MUST 289 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 290 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 291 authentication 'method name' values that can continue. 293 This 'method name' MUST NOT be listed as supported by the server. 295 5.3 Completion of User Authentication 297 Authentication is complete when the server has responded with 298 SSH_MSG_USERAUTH_SUCCESS. All authentication related messages 299 received after sending this message SHOULD be silently ignored. 301 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 302 requested service. 304 5.4 Banner Message 306 In some jurisdictions, sending a warning message before 307 authentication may be relevant for getting legal protection. Many 308 UNIX machines, for example, normally display text from '/etc/issue', 309 or use "tcp wrappers" or similar software to display a banner before 310 issuing a login prompt. 312 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 313 after this authentication protocol starts and before authentication 314 is successful. This message contains text to be displayed to the 315 client user before authentication is attempted. The format is as 316 follows: 317 byte SSH_MSG_USERAUTH_BANNER 318 string message in ISO-10646 UTF-8 encoding 319 string language tag as defined in [RFC3066] 321 The client SHOULD by default display the 'message' on the screen. 322 However, since the 'message' is likely to be sent for every login 323 attempt, and since some client software will need to open a separate 324 window for this warning, the client software may allow the user to 325 explicitly disable the display of banners from the server. The 326 'message' may consist of multiple lines. 328 If the 'message' string is displayed, control character filtering 329 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 330 terminal control characters. 332 6. Authentication Protocol Message Numbers 334 All message numbers used by this authentication protocol are in the 335 range from 50 to 79, which is part of the range reserved for 336 protocols running on top of the SSH transport layer protocol. 338 Message numbers of 80 and higher are reserved for protocols running 339 after this authentication protocol, so receiving one of them before 340 authentication is complete is an error, to which the server MUST 341 respond by disconnecting, preferably with a proper disconnect message 342 sent to ease troubleshooting. 344 After successful authentication, such messages are passed to the 345 higher-level service. 347 These are the general authentication message codes: 349 SSH_MSG_USERAUTH_REQUEST 50 350 SSH_MSG_USERAUTH_FAILURE 51 351 SSH_MSG_USERAUTH_SUCCESS 52 352 SSH_MSG_USERAUTH_BANNER 53 354 In addition to the above, there is a range of message numbers 355 (60..79) reserved for method-specific messages. These messages are 356 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 357 messages). Different authentication methods reuse the same message 358 numbers. 360 7. Public Key Authentication Method: publickey 362 The only REQUIRED authentication 'method name' is public key 363 authentication. All implementations MUST support this method; 364 however, not all users need to have public keys, and most local 365 policies are not likely to require public key authentication for all 366 users in the near future. 368 With this method, the possession of a private key serves as 369 authentication. This method works by sending a 'signature' created 370 with a private key of the user. The server MUST check that the key 371 is a valid authenticator for the user, and MUST check that the 372 'signature' is valid. If both hold, the authentication request MUST 373 be accepted; otherwise it MUST be rejected. (Note that the server 374 MAY require additional authentications after successful 375 authentication.) 377 Private keys are often stored in an encrypted form at the client 378 host, and the user must supply a passphrase before the signature can 379 be generated. Even if they are not, the signing operation involves 380 some expensive computation. To avoid unnecessary processing and user 381 interaction, the following message is provided for querying whether 382 authentication using the key would be acceptable. 383 byte SSH_MSG_USERAUTH_REQUEST 384 string user name in ISO-10646 UTF-8 encoding 385 string service name in US-ASCII 386 string "publickey" 387 boolean FALSE 388 string public key algorithm name 389 string public key blob 391 Public key algorithms are defined in the transport layer 392 specification [SSH-TRANS]. The 'public key blob' may contain 393 certificates. 395 Any public key algorithm may be offered for use in authentication. 396 In particular, the list is not constrained by what was negotiated 397 during key exchange. If the server does not support some algorithm, 398 it MUST simply reject the request. 400 The server MUST respond to this message with either 401 SSH_MSG_USERAUTH_FAILURE or with the following: 403 byte SSH_MSG_USERAUTH_PK_OK 404 string public key algorithm name from the request 405 string public key blob from the request 407 To perform actual authentication, the client MAY then send a 408 signature generated using the private key. The client MAY send the 409 signature directly without first verifying whether the key is 410 acceptable. The signature is sent using the following packet: 412 byte SSH_MSG_USERAUTH_REQUEST 413 string user name 414 string service 415 string "publickey" 416 boolean TRUE 417 string public key algorithm name 418 string public key to be used for authentication 419 string signature 421 The value of 'signature' is a signature by the corresponding private 422 key over the following data, in the following order: 424 string session identifier 425 byte SSH_MSG_USERAUTH_REQUEST 426 string user name 427 string service 428 string "publickey" 429 boolean TRUE 430 string public key algorithm name 431 string public key to be used for authentication 433 When the server receives this message, it MUST check whether the 434 supplied key is acceptable for authentication, and if so, it MUST 435 check whether the signature is correct. 437 If both checks succeed, this method is successful. Note that the 438 server may require additional authentications. The server MUST 439 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 440 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 441 authentications are needed). 443 The following method-specific message numbers are used by the 444 publickey authentication method. 446 SSH_MSG_USERAUTH_PK_OK 60 448 8. Password Authentication Method: password 450 Password authentication uses the following packets. Note that a 451 server MAY request the user to change the password. All 452 implementations SHOULD support password authentication. 454 byte SSH_MSG_USERAUTH_REQUEST 455 string user name 456 string service 457 string "password" 458 boolean FALSE 459 string plaintext password in ISO-10646 UTF-8 encoding 461 Note that the 'plaintext password' value is encoded in ISO-10646 462 UTF-8. It is up to the server how it interprets the password and 463 validates it against the password database. However, if the client 464 reads the password in some other encoding (e.g., ISO 8859-1 - ISO 465 Latin1), it MUST convert the password to ISO-10646 UTF-8 before 466 transmitting, and the server MUST convert the password to the 467 encoding used on that system for passwords. 469 From an internationalization standpoint, it is desired that if a user 470 enters their password the authentication process will work regardless 471 of what OS and client software they are using. Doing so requires 472 normalization. Systems supporting non-ASCII passwords SHOULD always 473 normalize passwords and usernames whenever they are added to the 474 database, or compared (with or without hashing) to existing entries 475 in the database. SSH implementations that both store the passwords 476 and compare them SHOULD use [I-D.ietf-sasl-saslprep] for 477 normalization. 479 Note that even though the cleartext password is transmitted in the 480 packet, the entire packet is encrypted by the transport layer. Both 481 the server and the client should check whether the underlying 482 transport layer provides confidentiality (i.e., if encryption is 483 being used). If no confidentiality is provided ("none" cipher), 484 password authentication SHOULD be disabled. If there is no 485 confidentiality or no MAC, password change SHOULD be disabled. 487 Normally, the server responds to this message with success or 488 failure. However, if the password has expired the server SHOULD 489 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 490 In any case the server MUST NOT allow an expired password to be used 491 for authentication. 492 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 493 string prompt in ISO-10646 UTF-8 encoding 494 string language tag as defined in [RFC3066] 496 In this case, the client MAY continue with a different authentication 497 method, or request a new password from the user and retry password 498 authentication using the following message. The client MAY also send 499 this message instead of the normal password authentication request 500 without the server asking for it. 502 byte SSH_MSG_USERAUTH_REQUEST 503 string user name 504 string service 505 string "password" 506 boolean TRUE 507 string plaintext old password in ISO-10646 UTF-8 encoding 508 string plaintext new password in ISO-10646 UTF-8 encoding 510 The server must reply to each request message with 511 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 512 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 513 follows: 515 SSH_MSG_USERAUTH_SUCCESS - The password has been changed, and 516 authentication has been successfully completed. 518 SSH_MSG_USERAUTH_FAILURE with partial success - The password has 519 been changed, but more authentications are needed. 521 SSH_MSG_USERAUTH_FAILURE without partial success - The password 522 has not been changed. Either password changing was not supported, 523 or the old password was bad. Note that if the server has already 524 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 525 changing the password. 527 SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because 528 the new password was not acceptable (e.g., too easy to guess). 530 The following method-specific message numbers are used by the 531 password authentication method. 533 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 535 9. Host-Based Authentication: hostbased 537 Some sites wish to allow authentication based on the host where the 538 user is coming from, and the user name on the remote host. While 539 this form of authentication is not suitable for high-security sites, 540 it can be very convenient in many environments. This form of 541 authentication is OPTIONAL. When used, special care SHOULD be taken 542 to prevent a regular user from obtaining the private host key. 544 The client requests this form of authentication by sending the 545 following message. It is similar to the UNIX "rhosts" and 546 "hosts.equiv" styles of authentication, except that the identity of 547 the client host is checked more rigorously. 549 This method works by having the client send a signature created with 550 the private key of the client host, which the server checks with that 551 host's public key. Once the client host's identity is established, 552 authorization (but no further authentication) is performed based on 553 the user names on the server and the client, and the client host 554 name. 556 byte SSH_MSG_USERAUTH_REQUEST 557 string user name 558 string service 559 string "hostbased" 560 string public key algorithm for host key 561 string public host key and certificates for client host 562 string client host name expressed as the FQDN in US-ASCII 563 string user name on the client host in ISO-10646 UTF-8 encoding 564 string signature 566 Public key algorithm names for use in 'public key algorithm for host 567 key' are defined in the transport layer specification. The 'public 568 host key and certificates for client host' may include certificates. 570 The value of 'signature' is a signature with the private host key of 571 the following data, in this order: 573 string session identifier 574 byte SSH_MSG_USERAUTH_REQUEST 575 string user name 576 string service 577 string "hostbased" 578 string public key algorithm for host key 579 string public host key and certificates for client host 580 string client host name expressed as the FQDN in US-ASCII 581 string user name on the client host in ISO-10646 UTF-8 encoding 583 The server MUST verify that the host key actually belongs to the 584 client host named in the message, that the given user on that host is 585 allowed to log in, and that the 'signature' value is a valid 586 signature on the appropriate value by the given host key. The server 587 MAY ignore the client 'user name', if it wants to authenticate only 588 the client host. 590 It is RECOMMENDED that whenever possible, the server perform 591 additional checks to verify that the network address obtained from 592 the (untrusted) network matches the given client host name. This 593 makes exploiting compromised host keys more difficult. Note that 594 this may require special handling for connections coming through a 595 firewall. 597 10. IANA Considerations 599 This document is part of a set. The IANA considerations for the SSH 600 protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and 601 this document, are detailed in [SSH-NUMBERS]. 603 11. Security Considerations 605 The purpose of this protocol is to perform client user 606 authentication. It assumed that this runs over a secure transport 607 layer protocol, which has already authenticated the server machine, 608 established an encrypted communications channel, and computed a 609 unique session identifier for this session. The transport layer 610 provides forward secrecy for password authentication and other 611 methods that rely on secret data. 613 Full security considerations for this protocol are provided in 614 [SSH-ARCH]. 616 12. References 618 12.1 Normative 620 [SSH-ARCH] 621 Lonvick, C., "SSH Protocol Architecture", 622 I-D draft-ietf-secsh-architecture-22.txt, March 2005. 624 [SSH-CONNECT] 625 Lonvick, C., "SSH Connection Protocol", 626 I-D draft-ietf-secsh-connect-25.txt, March 2005. 628 [SSH-TRANS] 629 Lonvick, C., "SSH Transport Layer Protocol", 630 I-D draft-ietf-secsh-transport-24.txt, March 2005. 632 [SSH-NUMBERS] 633 Lonvick, C., "SSH Protocol Assigned Numbers", 634 I-D draft-ietf-secsh-assignednumbers-12.txt, March 2005. 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 640 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 641 October 1998. 643 [RFC3066] Alvestrand, H., "Tags for the Identification of 644 Languages", BCP 47, RFC 3066, January 2001. 646 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 647 10646", STD 63, RFC 3629, November 2003. 649 [I-D.ietf-sasl-saslprep] 650 Zeilenga, K., "SASLprep: Stringprep profile for user names 651 and passwords", 652 Internet-Draft draft-ietf-sasl-saslprep-10, July 2004. 654 12.2 Informative 656 [ssh-1.2.30] 657 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 658 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 659 ssh-1.2.30.tar.gz, November 1995. 661 Authors' Addresses 663 Tatu Ylonen 664 SSH Communications Security Corp 665 Fredrikinkatu 42 666 HELSINKI FIN-00100 667 Finland 669 Email: ylo@ssh.com 671 Chris Lonvick (editor) 672 Cisco Systems, Inc. 673 12515 Research Blvd. 674 Austin 78759 675 USA 677 Email: clonvick@cisco.com 679 Appendix A. Trademark Notice 681 "ssh" is a registered trademark in the United States and/or other 682 countries. 684 Note to the RFC Editor: This should be a separate section like the 685 subsequent ones, and not an appendix. This paragraph to be removed 686 before publication. 688 Intellectual Property Statement 690 The IETF takes no position regarding the validity or scope of any 691 Intellectual Property Rights or other rights that might be claimed to 692 pertain to the implementation or use of the technology described in 693 this document or the extent to which any license under such rights 694 might or might not be available; nor does it represent that it has 695 made any independent effort to identify any such rights. Information 696 on the procedures with respect to rights in RFC documents can be 697 found in BCP 78 and BCP 79. 699 Copies of IPR disclosures made to the IETF Secretariat and any 700 assurances of licenses to be made available, or the result of an 701 attempt made to obtain a general license or permission for the use of 702 such proprietary rights by implementers or users of this 703 specification can be obtained from the IETF on-line IPR repository at 704 http://www.ietf.org/ipr. 706 The IETF invites any interested party to bring to its attention any 707 copyrights, patents or patent applications, or other proprietary 708 rights that may cover technology that may be required to implement 709 this standard. Please address the information to the IETF at 710 ietf-ipr@ietf.org. 712 The IETF has been notified of intellectual property rights claimed in 713 regard to some or all of the specification contained in this 714 document. For more information consult the online list of claimed 715 rights. 717 Disclaimer of Validity 719 This document and the information contained herein are provided on an 720 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 721 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 722 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 723 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 724 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 725 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 727 Copyright Statement 729 Copyright (C) The Internet Society (2005). This document is subject 730 to the rights, licenses and restrictions contained in BCP 78, and 731 except as set forth therein, the authors retain all their rights. 733 Acknowledgment 735 Funding for the RFC Editor function is currently provided by the 736 Internet Society.