idnits 2.17.1 draft-ietf-secsh-userauth-25.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. ** 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 162 has weird spacing: '... string use...' == Line 163 has weird spacing: '... string ser...' == Line 164 has weird spacing: '... string met...' == Line 216 has weird spacing: '...me-list aut...' == Line 299 has weird spacing: '... string mes...' == (40 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 (December 9, 2004) is 7078 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 627, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-20 == Outdated reference: A later version (-25) exists of draft-ietf-secsh-connect-23 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-22 == Outdated reference: A later version (-12) exists of draft-ietf-secsh-assignednumbers-10 ** 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 (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lonvick, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Expires: June 9, 2005 December 9, 2004 6 SSH Authentication Protocol 7 draft-ietf-secsh-userauth-25.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 9, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 SSH is a protocol for secure remote login and other secure network 43 services over an insecure network. This document describes the SSH 44 authentication protocol framework and public key, password, and 45 host-based client authentication methods. Additional authentication 46 methods are described in separate documents. The SSH authentication 47 protocol runs on top of the SSH transport layer protocol and provides 48 a single authenticated tunnel for the SSH connection protocol. 50 Table of Contents 52 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Conventions Used in This Document . . . . . . . . . . . . . . 3 55 4. The Authentication Protocol Framework . . . . . . . . . . . . 4 56 5. Authentication Requests . . . . . . . . . . . . . . . . . . . 4 57 5.1 Responses to Authentication Requests . . . . . . . . . . . 5 58 5.2 The "none" Authentication Request . . . . . . . . . . . . 7 59 5.3 Completion of User Authentication . . . . . . . . . . . . 7 60 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Authentication Protocol Message Numbers . . . . . . . . . . . 8 62 7. Public Key Authentication Method: publickey . . . . . . . . . 8 63 8. Password Authentication Method: password . . . . . . . . . . . 10 64 9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 12 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 66 11. Security Considerations . . . . . . . . . . . . . . . . . . 13 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . 16 73 1. Contributors 75 The major original contributors of this set of documents have been: 76 Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 77 Communications Security Corp), and Markku-Juhani O. Saarinen 78 (University of Jyvaskyla). Darren Moffit was the original editor of 79 this set of documents and also made very substantial contributions. 81 Additional contributors to this document include [need list]. 82 Listing their names here does not mean that they endorse this 83 document, but that they have contributed to it. 85 Comments on this internet draft should be sent to the IETF SECSH 86 working group, details at: 87 http://ietf.org/html.charters/secsh-charter.html Note: This paragraph 88 will be removed before this document progresses to become an RFC. 90 2. Introduction 92 The SSH authentication protocol is a general-purpose user 93 authentication protocol. It is intended to be run over the SSH 94 transport layer protocol [SSH-TRANS]. This protocol assumes that the 95 underlying protocols provide integrity and confidentiality 96 protection. 98 This document should be read only after reading the SSH architecture 99 document [SSH-ARCH]. This document freely uses terminology and 100 notation from the architecture document without reference or further 101 explanation. 103 The 'service name' for this protocol is "ssh-userauth". 105 When this protocol starts, it receives the session identifier from 106 the lower-level protocol (this is the exchange hash H from the first 107 key exchange). The session identifier uniquely identifies this 108 session and is suitable for signing in order to prove ownership of a 109 private key. This protocol also needs to know whether the 110 lower-level protocol provides confidentiality protection. 112 3. Conventions Used in This Document 114 All documents related to the SSH protocols shall use the keywords 115 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 116 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 117 requirements. These keywords are to be interpreted as described in 118 [RFC2119]. 120 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 121 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 122 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 123 this document when used to describe namespace allocation are to be 124 interpreted as described in [RFC2434]. 126 4. The Authentication Protocol Framework 128 The server drives the authentication by telling the client which 129 authentication methods can be used to continue the exchange at any 130 given time. The client has the freedom to try the methods listed by 131 the server in any order. This gives the server complete control over 132 the authentication process if desired, but also gives enough 133 flexibility for the client to use the methods it supports or that are 134 most convenient for the user, when multiple methods are offered by 135 the server. 137 Authentication methods are identified by their name, as defined in 138 [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 139 supported. However, it MAY be sent by the client. The server MUST 140 always reject this request, unless the client is to be allowed in 141 without any authentication, in which case the server MUST accept this 142 request. The main purpose of sending this request is to get the list 143 of supported methods from the server. 145 The server SHOULD have a timeout for authentication, and disconnect 146 if the authentication has not been accepted within the timeout 147 period. The RECOMMENDED timeout period is 10 minutes. Additionally, 148 the implementation SHOULD limit the number of failed authentication 149 attempts a client may perform in a single session (the RECOMMENDED 150 limit is 20 attempts). If the threshold is exceeded, the server 151 SHOULD disconnect. 153 Additional thoughts about authentication timeouts and retries may be 154 found in [ssh-1.2.30]. 156 5. Authentication Requests 158 All authentication requests MUST use the following message format. 159 Only the first few fields are defined; the remaining fields depend on 160 the authentication method. 161 byte SSH_MSG_USERAUTH_REQUEST 162 string user name in ISO-10646 UTF-8 encoding 163 string service name in US-ASCII 164 string method name in US-ASCII 165 The rest of the packet is method-specific. 167 The 'user name' and 'service name' are repeated in every new 168 authentication attempt, and MAY change. The server implementation 169 MUST carefully check them in every message, and MUST flush any 170 accumulated authentication states if they change. If it is unable to 171 flush some authentication state, it MUST disconnect if the 'user 172 name' or 'service name' changes. 174 The 'service name' specifies the service to start after 175 authentication. There may be several different authenticated 176 services provided. If the requested service is not available, the 177 server MAY disconnect immediately or at any later time. Sending a 178 proper disconnect message is RECOMMENDED. In any case, if the 179 service does not exist, authentication MUST NOT be accepted. 181 If the requested user does not exist, the server MAY disconnect, or 182 MAY send a bogus list of acceptable authentication 'method name' 183 values, but never accept any. This makes it possible for the server 184 to avoid disclosing information on which accounts exist. In any 185 case, if the user does not exist, the authentication request MUST NOT 186 be accepted. 188 While there is usually little point for clients to send requests that 189 the server does not list as acceptable, sending such requests is not 190 an error, and the server SHOULD simply reject requests that it does 191 not recognize. 193 An authentication request MAY result in a further exchange of 194 messages. All such messages depend on the authentication 'method 195 name' used, and the client MAY at any time continue with a new 196 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 197 abandon the previous authentication attempt and continue with the new 198 one. 200 The following 'method name' values are defined. 202 public key REQUIRED 203 password OPTIONAL 204 hostbased OPTIONAL 205 none NOT RECOMMENDED 207 Additional 'method name' values may be defined as specified in 208 [SSH-ARCH] and [SSH-NUMBERS]. 210 5.1 Responses to Authentication Requests 212 If the server rejects the authentication request, it MUST respond 213 with the following: 215 byte SSH_MSG_USERAUTH_FAILURE 216 name-list authentications that can continue 217 boolean partial success 219 The 'authentications that can continue' is a comma-separated 220 name-list of authentication 'method name' values that may 221 productively continue the authentication dialog. 223 It is RECOMMENDED that servers only include those 'method name' 224 values in the name-list that are actually useful. However, it is not 225 illegal to include 'method name' values that cannot be used to 226 authenticate the user. 228 Already successfully completed authentications SHOULD NOT be included 229 in the name-list, unless they really should be performed again for 230 some reason. 232 The value of 'partial success' MUST be TRUE if the authentication 233 request to which this is a response was successful. It MUST be FALSE 234 if the request was not successfully processed. 236 When the server accepts authentication, it MUST respond with the 237 following: 239 byte SSH_MSG_USERAUTH_SUCCESS 241 Note that this is not sent after each step in a multi-method 242 authentication sequence, but only when the authentication is 243 complete. 245 The client MAY send several authentication requests without waiting 246 for responses from previous requests. The server MUST process each 247 request completely and acknowledge any failed requests with a 248 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 250 A request that results in further exchange of messages will be 251 aborted by a second request. It is not possible to send a second 252 request without waiting for a response from the server, if the first 253 request will result in further exchange of messages. No 254 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 256 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 257 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 258 requests received after that SHOULD be silently ignored. 260 Any non-authentication messages sent by the client after the request 261 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 262 to the service being run on top of this protocol. Such messages can 263 be identified by their message numbers (see Section 6). 265 5.2 The "none" Authentication Request 267 A client may request a list of authentication 'method name' values 268 that may continue by using the "none" authentication 'method name'. 270 If no authentication at all is needed for the user, the server MUST 271 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 272 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 273 authentication 'method name' values that can continue. 275 This 'method name' MUST NOT be listed as supported by the server. 277 5.3 Completion of User Authentication 279 Authentication is complete when the server has responded with 280 SSH_MSG_USERAUTH_SUCCESS. All authentication related messages 281 received after sending this message SHOULD be silently ignored. 283 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 284 requested service. 286 5.4 Banner Message 288 In some jurisdictions, sending a warning message before 289 authentication may be relevant for getting legal protection. Many 290 UNIX machines, for example, normally display text from '/etc/issue', 291 or use "tcp wrappers" or similar software to display a banner before 292 issuing a login prompt. 294 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 295 before authentication is successful. This message contains text to 296 be displayed to the client user before authentication is attempted. 297 The format is as follows: 298 byte SSH_MSG_USERAUTH_BANNER 299 string message in ISO-10646 UTF-8 encoding 300 string language tag as defined in [RFC3066] 302 The client SHOULD by default display the message on the screen. 303 However, since the message is likely to be sent for every login 304 attempt, and since some client software will need to open a separate 305 window for this warning, the client software may allow the user to 306 explicitly disable the display of banners from the server. The 307 message may consist of multiple lines. 309 If the 'message' string is displayed, control character filtering 310 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 311 terminal control characters. 313 6. Authentication Protocol Message Numbers 315 All message numbers used by this authentication protocol are in the 316 range from 50 to 79, which is part of the range reserved for 317 protocols running on top of the SSH transport layer protocol. 319 Message numbers of 80 and higher are reserved for protocols running 320 after this authentication protocol, so receiving one of them before 321 authentication is complete is an error, to which the server MUST 322 respond by disconnecting, preferably with a proper disconnect message 323 sent to ease troubleshooting. 325 After successful authentication, such messages are passed to the 326 higher-level service. 328 These are the general authentication message codes: 330 SSH_MSG_USERAUTH_REQUEST 50 331 SSH_MSG_USERAUTH_FAILURE 51 332 SSH_MSG_USERAUTH_SUCCESS 52 333 SSH_MSG_USERAUTH_BANNER 53 335 In addition to the above, there is a range of message numbers 336 (60..79) reserved for method-specific messages. These messages are 337 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 338 messages). Different authentication methods reuse the same message 339 numbers. 341 7. Public Key Authentication Method: publickey 343 The only REQUIRED authentication 'method name' is public key 344 authentication. All implementations MUST support this method; 345 however, not all users need to have public keys, and most local 346 policies are not likely to require public key authentication for all 347 users in the near future. 349 With this method, the possession of a private key serves as 350 authentication. This method works by sending a 'signature' created 351 with a private key of the user. The server MUST check that the key 352 is a valid authenticator for the user, and MUST check that the 353 'signature' is valid. If both hold, the authentication request MUST 354 be accepted; otherwise it MUST be rejected. (Note that the server 355 MAY require additional authentications after successful 356 authentication.) 358 Private keys are often stored in an encrypted form at the client 359 host, and the user must supply a passphrase before the signature can 360 be generated. Even if they are not, the signing operation involves 361 some expensive computation. To avoid unnecessary processing and user 362 interaction, the following message is provided for querying whether 363 authentication using the key would be acceptable. 364 byte SSH_MSG_USERAUTH_REQUEST 365 string user name in ISO-10646 UTF-8 encoding 366 string service name in US-ASCII 367 string "publickey" 368 boolean FALSE 369 string public key algorithm name 370 string public key blob 372 Public key algorithms are defined in the transport layer 373 specification [SSH-TRANS]. The 'public key blob' may contain 374 certificates. 376 Any public key algorithm may be offered for use in authentication. 377 In particular, the list is not constrained by what was negotiated 378 during key exchange. If the server does not support some algorithm, 379 it MUST simply reject the request. 381 The server MUST respond to this message with either 382 SSH_MSG_USERAUTH_FAILURE or with the following: 384 byte SSH_MSG_USERAUTH_PK_OK 385 string public key algorithm name from the request 386 string public key blob from the request 388 To perform actual authentication, the client MAY then send a 389 signature generated using the private key. The client MAY send the 390 signature directly without first verifying whether the key is 391 acceptable. The signature is sent using the following packet: 393 byte SSH_MSG_USERAUTH_REQUEST 394 string user name 395 string service 396 string "publickey" 397 boolean TRUE 398 string public key algorithm name 399 string public key to be used for authentication 400 string signature 402 The value of 'signature' is a signature by the corresponding private 403 key over the following data, in the following order: 405 string session identifier 406 byte SSH_MSG_USERAUTH_REQUEST 407 string user name 408 string service 409 string "publickey" 410 boolean TRUE 411 string public key algorithm name 412 string public key to be used for authentication 414 When the server receives this message, it MUST check whether the 415 supplied key is acceptable for authentication, and if so, it MUST 416 check whether the signature is correct. 418 If both checks succeed, this method is successful. Note that the 419 server may require additional authentications. The server MUST 420 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 421 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 422 authentications are needed). 424 The following method-specific message numbers are used by the 425 publickey authentication method. 427 SSH_MSG_USERAUTH_PK_OK 60 429 8. Password Authentication Method: password 431 Password authentication uses the following packets. Note that a 432 server MAY request the user to change the password. All 433 implementations SHOULD support password authentication. 435 byte SSH_MSG_USERAUTH_REQUEST 436 string user name 437 string service 438 string "password" 439 boolean FALSE 440 string plaintext password in ISO-10646 UTF-8 encoding 442 Note that the 'plaintext password' value is encoded in ISO-10646 443 UTF-8. It is up to the server how it interprets the password and 444 validates it against the password database. However, if the client 445 reads the password in some other encoding (e.g., ISO 8859-1 - ISO 446 Latin1), it MUST convert the password to ISO-10646 UTF-8 before 447 transmitting, and the server MUST convert the password to the 448 encoding used on that system for passwords. 450 From an internationalization standpoint, it is desired that if a user 451 enters their password the authentication process will work regardless 452 of what OS and client software they are using. Doing so requires 453 normalization. Systems supporting non-ASCII passwords SHOULD always 454 normalize passwords and usernames whenever they are added to the 455 database, or compared (with or without hashing) to existing entries 456 in the database. SSH implementations that both store the passwords 457 and compare them SHOULD use [I-D.ietf-sasl-saslprep] for 458 normalization. 460 Note that even though the cleartext password is transmitted in the 461 packet, the entire packet is encrypted by the transport layer. Both 462 the server and the client should check whether the underlying 463 transport layer provides confidentiality (i.e., if encryption is 464 being used). If no confidentiality is provided ("none" cipher), 465 password authentication SHOULD be disabled. If there is no 466 confidentiality or no MAC, password change SHOULD be disabled. 468 Normally, the server responds to this message with success or 469 failure. However, if the password has expired the server SHOULD 470 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 471 In any case the server MUST NOT allow an expired password to be used 472 for authentication. 473 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 474 string prompt in ISO-10646 UTF-8 encoding 475 string language tag as defined in [RFC3066] 477 In this case, the client MAY continue with a different authentication 478 method, or request a new password from the user and retry password 479 authentication using the following message. The client MAY also send 480 this message instead of the normal password authentication request 481 without the server asking for it. 483 byte SSH_MSG_USERAUTH_REQUEST 484 string user name 485 string service 486 string "password" 487 boolean TRUE 488 string plaintext old password in ISO-10646 UTF-8 encoding 489 string plaintext new password in ISO-10646 UTF-8 encoding 491 The server must reply to request message with 492 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 493 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 494 follows: 496 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 497 authentication has been successfully completed. 499 SSH_MSG_USERAUTH_FAILURE with partial success The password has 500 been changed, but more authentications are needed. 502 SSH_MSG_USERAUTH_FAILURE without partial success The password has 503 not been changed. Either password changing was not supported, or 504 the old password was bad. Note that if the server has already 505 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 506 changing the password. 508 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 509 the new password was not acceptable (e.g., too easy to guess). 511 The following method-specific message numbers are used by the 512 password authentication method. 514 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 516 9. Host-Based Authentication: hostbased 518 Some sites wish to allow authentication based on the host where the 519 user is coming from, and the user name on the remote host. While 520 this form of authentication is not suitable for high-security sites, 521 it can be very convenient in many environments. This form of 522 authentication is OPTIONAL. When used, special care SHOULD be taken 523 to prevent a regular user from obtaining the private host key. 525 The client requests this form of authentication by sending the 526 following message. It is similar to the UNIX "rhosts" and 527 "hosts.equiv" styles of authentication, except that the identity of 528 the client host is checked more rigorously. 530 This method works by having the client send a signature created with 531 the private key of the client host, which the server checks with that 532 host's public key. Once the client host's identity is established, 533 authorization (but no further authentication) is performed based on 534 the user names on the server and the client, and the client host 535 name. 537 byte SSH_MSG_USERAUTH_REQUEST 538 string user name 539 string service 540 string "hostbased" 541 string public key algorithm for host key 542 string public host key and certificates for client host 543 string client host name expressed as the FQDN in US-ASCII 544 string user name on the client host in ISO-10646 UTF-8 encoding 545 string signature 547 Public key algorithm names for use in 'public key algorithm for host 548 key' are defined in the transport layer specification. The 'public 549 host key and certificates for client host' may include certificates. 551 The value of 'signature' is a signature with the private host key of 552 the following data, in this order: 554 string session identifier 555 byte SSH_MSG_USERAUTH_REQUEST 556 string user name 557 string service 558 string "hostbased" 559 string public key algorithm for host key 560 string public host key and certificates for client host 561 string client host name expressed as the FQDN in US-ASCII 562 string user name on the client host in ISO-10646 UTF-8 encoding 564 The server MUST verify that the host key actually belongs to the 565 client host named in the message, that the given user on that host is 566 allowed to log in, and that the 'signature' value is a valid 567 signature on the appropriate value by the given host key. The server 568 MAY ignore the client user name, if it wants to authenticate only the 569 client host. 571 It is RECOMMENDED that whenever possible, the server perform 572 additional checks to verify that the network address obtained from 573 the (untrusted) network matches the given client host name. This 574 makes exploiting compromised host keys more difficult. Note that 575 this may require special handling for connections coming through a 576 firewall. 578 10. IANA Considerations 580 This document is part of a set. The IANA considerations for the SSH 581 protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and 582 this document, are detailed in [SSH-NUMBERS]. 584 11. Security Considerations 586 The purpose of this protocol is to perform client user 587 authentication. It assumed that this runs over a secure transport 588 layer protocol, which has already authenticated the server machine, 589 established an encrypted communications channel, and computed a 590 unique session identifier for this session. The transport layer 591 provides forward secrecy for password authentication and other 592 methods that rely on secret data. 594 Full security considerations for this protocol are provided in 595 [SSH-ARCH]. 597 12. References 599 12.1 Normative 601 [SSH-ARCH] 602 Lonvick, C., "SSH Protocol Architecture", I-D 603 draft-ietf-secsh-architecture-20.txt, December 2004. 605 [SSH-CONNECT] 606 Lonvick, C., "SSH Connection Protocol", I-D 607 draft-ietf-secsh-connect-23.txt, December 2004. 609 [SSH-TRANS] 610 Lonvick, C., "SSH Transport Layer Protocol", I-D 611 draft-ietf-secsh-transport-22.txt, December 2004. 613 [SSH-NUMBERS] 614 Lonvick, C., "SSH Protocol Assigned Numbers", I-D 615 draft-ietf-secsh-assignednumbers-10.txt, December 2004. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 621 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 622 October 1998. 624 [RFC3066] Alvestrand, H., "Tags for the Identification of 625 Languages", BCP 47, RFC 3066, January 2001. 627 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 628 10646", STD 63, RFC 3629, November 2003. 630 [I-D.ietf-sasl-saslprep] 631 Zeilenga, K., "SASLprep: Stringprep profile for user names 632 and passwords", draft-ietf-sasl-saslprep-10 (work in 633 progress), July 2004. 635 12.2 Informative 637 [ssh-1.2.30] 638 Ylonen, T., "ssh-1.2.30/RFC", File within compressed 639 tarball ftp://ftp.funet.fi/pub/unix/security/login/ssh/ 640 ssh-1.2.30.tar.gz, November 1995. 642 Author's Address 644 Chris Lonvick (editor) 645 Cisco Systems, Inc. 646 12515 Research Blvd. 647 Austin 78759 648 USA 650 EMail: clonvick@cisco.com 652 Intellectual Property Statement 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 The IETF has been notified of intellectual property rights claimed in 677 regard to some or all of the specification contained in this 678 document. For more information consult the online list of claimed 679 rights. 681 Disclaimer of Validity 683 This document and the information contained herein are provided on an 684 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 685 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 686 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 687 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 688 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 689 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 691 Copyright Statement 693 Copyright (C) The Internet Society (2004). This document is subject 694 to the rights, licenses and restrictions contained in BCP 78, and 695 except as set forth therein, the authors retain all their rights. 697 Acknowledgment 699 Funding for the RFC Editor function is currently provided by the 700 Internet Society.