idnits 2.17.1 draft-ietf-secsh-userauth-22.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 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. ** 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 157 has weird spacing: '... string use...' == Line 158 has weird spacing: '... string ser...' == Line 159 has weird spacing: '... string met...' == Line 200 has weird spacing: '... string aut...' == Line 201 has weird spacing: '...boolean part...' == (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 (October 24, 2004) is 7095 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) -- No information found for draft-ietf-architecture - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-ARCH' -- No information found for draft-ietf-connect - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-CONNECT' -- No information found for draft-ietf-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' -- No information found for draft-ietf-assignednumbers - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-NUMBERS' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3066 (Obsoleted by RFC 4646, RFC 4647) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 16 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: April 24, 2005 October 24, 2004 6 SSH Authentication Protocol 7 draft-ietf-secsh-userauth-22.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 April 24, 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 . . . . . . . . . . . . 6 59 5.3 Completion of User Authentication . . . . . . . . . . . . 6 60 5.4 Banner Message . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Authentication Protocol Message Numbers . . . . . . . . . . . 7 62 7. Public Key Authentication Method: publickey . . . . . . . . . 8 63 8. Password Authentication Method: password . . . . . . . . . . . 10 64 9. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 66 11. Security Considerations . . . . . . . . . . . . . . . . . . 13 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 12.1 Normative . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 12.2 Informative . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 71 Intellectual Property and Copyright Statements . . . . . . . . 15 73 1. Contributors 75 The major original contributors of this document were: Tatu Ylonen, 76 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 document 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 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 115 and "MAY" that appear in this document are to be interpreted as 116 described in [RFC2119] 118 The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 119 FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 120 APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 121 this document when used to describe namespace allocation are to be 122 interpreted as described in [RFC2434]. 124 4. The Authentication Protocol Framework 126 The server drives the authentication by telling the client which 127 authentication methods can be used to continue the exchange at any 128 given time. The client has the freedom to try the methods listed by 129 the server in any order. This gives the server complete control over 130 the authentication process if desired, but also gives enough 131 flexibility for the client to use the methods it supports or that are 132 most convenient for the user, when multiple methods are offered by 133 the server. 135 Authentication methods are identified by their name, as defined in 136 [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as 137 supported. However, it MAY be sent by the client. The server MUST 138 always reject this request, unless the client is to be allowed in 139 without any authentication, in which case the server MUST accept this 140 request. The main purpose of sending this request is to get the list 141 of supported methods from the server. 143 The server SHOULD have a timeout for authentication, and disconnect 144 if the authentication has not been accepted within the timeout 145 period. The RECOMMENDED timeout period is 10 minutes. Additionally, 146 the implementation SHOULD limit the number of failed authentication 147 attempts a client may perform in a single session (the RECOMMENDED 148 limit is 20 attempts). If the threshold is exceeded, the server 149 SHOULD disconnect. 151 5. Authentication Requests 153 All authentication requests MUST use the following message format. 154 Only the first few fields are defined; the remaining fields depend on 155 the authentication method. 156 byte SSH_MSG_USERAUTH_REQUEST 157 string user name in ISO-10646 UTF-8 encoding [RFC3629] 158 string service name in US-ASCII 159 string method name in US-ASCII 160 The rest of the packet is method-specific. 162 The 'user name' and 'service name' are repeated in every new 163 authentication attempt, and MAY change. The server implementation 164 MUST carefully check them in every message, and MUST flush any 165 accumulated authentication states if they change. If it is unable to 166 flush some authentication state, it MUST disconnect if the 'user 167 name' or 'service name' changes. 169 The 'service name' specifies the service to start after 170 authentication. There may be several different authenticated 171 services provided. If the requested service is not available, the 172 server MAY disconnect immediately or at any later time. Sending a 173 proper disconnect message is RECOMMENDED. In any case, if the 174 service does not exist, authentication MUST NOT be accepted. 176 If the requested user does not exist, the server MAY disconnect, or 177 MAY send a bogus list of acceptable authentication methods, but never 178 accept any. This makes it possible for the server to avoid 179 disclosing information on which accounts exist. In any case, if the 180 user does not exist, the authentication request MUST NOT be accepted. 182 While there is usually little point for clients to send requests that 183 the server does not list as acceptable, sending such requests is not 184 an error, and the server SHOULD simply reject requests that it does 185 not recognize. 187 An authentication request MAY result in a further exchange of 188 messages. All such messages depend on the authentication method 189 used, and the client MAY at any time continue with a new 190 SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST 191 abandon the previous authentication attempt and continue with the new 192 one. 194 5.1 Responses to Authentication Requests 196 If the server rejects the authentication request, it MUST respond 197 with the following: 199 byte SSH_MSG_USERAUTH_FAILURE 200 string authentications that can continue 201 boolean partial success 203 The 'authentications that can continue' string is a comma-separated 204 list of authentication method names that may productively continue 205 the authentication dialog. 207 It is RECOMMENDED that servers only include those methods in the list 208 that are actually useful. However, it is not illegal to include 209 methods that cannot be used to authenticate the user. 211 Already successfully completed authentications SHOULD NOT be included 212 in the list, unless they really should be performed again for some 213 reason. 215 The value of 'partial success' MUST be TRUE if the authentication 216 request to which this is a response was successful. It MUST be FALSE 217 if the request was not successfully processed. 219 When the server accepts authentication, it MUST respond with the 220 following: 222 byte SSH_MSG_USERAUTH_SUCCESS 224 Note that this is not sent after each step in a multi-method 225 authentication sequence, but only when the authentication is 226 complete. 228 The client MAY send several authentication requests without waiting 229 for responses from previous requests. The server MUST process each 230 request completely and acknowledge any failed requests with a 231 SSH_MSG_USERAUTH_FAILURE message before processing the next request. 233 A request that results in further exchange of messages will be 234 aborted by a second request. It is not possible to send a second 235 request without waiting for a response from the server, if the first 236 request will result in further exchange of messages. No 237 SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. 239 SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When 240 SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication 241 requests received after that SHOULD be silently ignored. 243 Any non-authentication messages sent by the client after the request 244 that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed 245 to the service being run on top of this protocol. Such messages can 246 be identified by their message numbers (see Section 6). 248 5.2 The "none" Authentication Request 250 A client may request a list of authentication methods that may 251 continue by using the "none" authentication method. 253 If no authentication at all is needed for the user, the server MUST 254 return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return 255 SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of 256 authentication methods that can continue. 258 This method MUST NOT be listed as supported by the server. 260 5.3 Completion of User Authentication 262 Authentication is complete when the server has responded with 263 SSH_MSG_USERAUTH_SUCCESS. All authentication related messages 264 received after sending this message SHOULD be silently ignored. 266 After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the 267 requested service. 269 5.4 Banner Message 271 In some jurisdictions, sending a warning message before 272 authentication may be relevant for getting legal protection. Many 273 UNIX machines, for example, normally display text from '/etc/issue', 274 or use "tcp wrappers" or similar software to display a banner before 275 issuing a login prompt. 277 The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time 278 before authentication is successful. This message contains text to 279 be displayed to the client user before authentication is attempted. 280 The format is as follows: 281 byte SSH_MSG_USERAUTH_BANNER 282 string message in ISO-10646 UTF-8 encoding 283 string language tag as defined in [RFC3066] 285 The client SHOULD by default display the message on the screen. 286 However, since the message is likely to be sent for every login 287 attempt, and since some client software will need to open a separate 288 window for this warning, the client software may allow the user to 289 explicitly disable the display of banners from the server. The 290 message may consist of multiple lines. 292 If the message string is displayed, control character filtering 293 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending 294 terminal control characters. 296 6. Authentication Protocol Message Numbers 298 All message numbers used by this authentication protocol are in the 299 range from 50 to 79, which is part of the range reserved for 300 protocols running on top of the SSH transport layer protocol. 302 Message numbers of 80 and higher are reserved for protocols running 303 after this authentication protocol, so receiving one of them before 304 authentication is complete is an error, to which the server MUST 305 respond by disconnecting, preferably with a proper disconnect message 306 sent to ease troubleshooting. 308 After successful authentication, such messages are passed to the 309 higher-level service. 311 These are the general authentication message codes: 313 SSH_MSG_USERAUTH_REQUEST 50 314 SSH_MSG_USERAUTH_FAILURE 51 315 SSH_MSG_USERAUTH_SUCCESS 52 316 SSH_MSG_USERAUTH_BANNER 53 318 In addition to the above, there is a range of message numbers 319 (60..79) reserved for method-specific messages. These messages are 320 only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST 321 messages). Different authentication methods reuse the same message 322 numbers. 324 7. Public Key Authentication Method: publickey 326 The only REQUIRED authentication method is public key authentication. 327 All implementations MUST support this method; however, not all users 328 need to have public keys, and most local policies are not likely to 329 require public key authentication for all users in the near future. 331 With this method, the possession of a private key serves as 332 authentication. This method works by sending a signature created 333 with a private key of the user. The server MUST check that the key 334 is a valid authenticator for the user, and MUST check that the 335 signature is valid. If both hold, the authentication request MUST be 336 accepted; otherwise it MUST be rejected. (Note that the server MAY 337 require additional authentications after successful authentication.) 339 Private keys are often stored in an encrypted form at the client 340 host, and the user must supply a passphrase before the signature can 341 be generated. Even if they are not, the signing operation involves 342 some expensive computation. To avoid unnecessary processing and user 343 interaction, the following message is provided for querying whether 344 authentication using the key would be acceptable. 346 byte SSH_MSG_USERAUTH_REQUEST 347 string user name 348 string service 349 string "publickey" 350 boolean FALSE 351 string public key algorithm name 352 string public key blob 354 Public key algorithms are defined in the transport layer 355 specification [SSH-TRANS]. The public key blob may contain 356 certificates. 358 Any public key algorithm may be offered for use in authentication. 359 In particular, the list is not constrained by what was negotiated 360 during key exchange. If the server does not support some algorithm, 361 it MUST simply reject the request. 363 The server MUST respond to this message with either 364 SSH_MSG_USERAUTH_FAILURE or with the following: 366 byte SSH_MSG_USERAUTH_PK_OK 367 string public key algorithm name from the request 368 string public key blob from the request 370 To perform actual authentication, the client MAY then send a 371 signature generated using the private key. The client MAY send the 372 signature directly without first verifying whether the key is 373 acceptable. The signature is sent using the following packet: 375 byte SSH_MSG_USERAUTH_REQUEST 376 string user name 377 string service 378 string "publickey" 379 boolean TRUE 380 string public key algorithm name 381 string public key to be used for authentication 382 string signature 384 The value of 'signature' is a signature by the corresponding private 385 key over the following data, in the following order: 387 string session identifier 388 byte SSH_MSG_USERAUTH_REQUEST 389 string user name 390 string service 391 string "publickey" 392 boolean TRUE 393 string public key algorithm name 394 string public key to be used for authentication 396 When the server receives this message, it MUST check whether the 397 supplied key is acceptable for authentication, and if so, it MUST 398 check whether the signature is correct. 400 If both checks succeed, this method is successful. Note that the 401 server may require additional authentications. The server MUST 402 respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are 403 needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more 404 authentications are needed). 406 The following method-specific message numbers are used by the 407 publickey authentication method. 409 SSH_MSG_USERAUTH_PK_OK 60 411 8. Password Authentication Method: password 413 Password authentication uses the following packets. Note that a 414 server MAY request the user to change the password. All 415 implementations SHOULD support password authentication. 417 byte SSH_MSG_USERAUTH_REQUEST 418 string user name 419 string service 420 string "password" 421 boolean FALSE 422 string plaintext password in ISO-10646 UTF-8 encoding 424 Note that the 'plaintext password' value is encoded in ISO-10646 425 UTF-8. It is up to the server how it interprets the password and 426 validates it against the password database. However, if the client 427 reads the password in some other encoding (e.g., ISO 8859-1 - ISO 428 Latin1), it MUST convert the password to ISO-10646 UTF-8 before 429 transmitting, and the server MUST convert the password to the 430 encoding used on that system for passwords. 432 Note that even though the cleartext password is transmitted in the 433 packet, the entire packet is encrypted by the transport layer. Both 434 the server and the client should check whether the underlying 435 transport layer provides confidentiality (i.e., if encryption is 436 being used). If no confidentiality is provided (none cipher), 437 password authentication SHOULD be disabled. If there is no 438 confidentiality or no MAC, password change SHOULD be disabled. 440 Normally, the server responds to this message with success or 441 failure. However, if the password has expired the server SHOULD 442 indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. 443 In any case the server MUST NOT allow an expired password to be used 444 for authentication. 445 byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 446 string prompt in ISO-10646 UTF-8 encoding 447 string language tag as defined in [RFC3066] 449 In this case, the client MAY continue with a different authentication 450 method, or request a new password from the user and retry password 451 authentication using the following message. The client MAY also send 452 this message instead of the normal password authentication request 453 without the server asking for it. 455 byte SSH_MSG_USERAUTH_REQUEST 456 string user name 457 string service 458 string "password" 459 boolean TRUE 460 string plaintext old password in ISO-10646 UTF-8 encoding 461 string plaintext new password in ISO-10646 UTF-8 encoding 463 The server must reply to request message with 464 SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another 465 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as 466 follows: 468 SSH_MSG_USERAUTH_SUCCESS The password has been changed, and 469 authentication has been successfully completed. 471 SSH_MSG_USERAUTH_FAILURE with partial success The password has 472 been changed, but more authentications are needed. 474 SSH_MSG_USERAUTH_FAILURE without partial success The password has 475 not been changed. Either password changing was not supported, or 476 the old password was bad. Note that if the server has already 477 sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports 478 changing the password. 480 SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because 481 the new password was not acceptable (e.g. too easy to guess). 483 The following method-specific message numbers are used by the 484 password authentication method. 486 SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 488 9. Host-Based Authentication: hostbased 490 Some sites wish to allow authentication based on the host where the 491 user is coming from, and the user name on the remote host. While 492 this form of authentication is not suitable for high-security sites, 493 it can be very convenient in many environments. This form of 494 authentication is OPTIONAL. When used, special care SHOULD be taken 495 to prevent a regular user from obtaining the private host key. 497 The client requests this form of authentication by sending the 498 following message. It is similar to the UNIX "rhosts" and 499 "hosts.equiv" styles of authentication, except that the identity of 500 the client host is checked more rigorously. 502 This method works by having the client send a signature created with 503 the private key of the client host, which the server checks with that 504 host's public key. Once the client host's identity is established, 505 authorization (but no further authentication) is performed based on 506 the user names on the server and the client, and the client host 507 name. 509 byte SSH_MSG_USERAUTH_REQUEST 510 string user name 511 string service 512 string "hostbased" 513 string public key algorithm for host key 514 string public host key and certificates for client host 515 string client host name expressed as the FQDN in US-ASCII 516 string user name on the client host in ISO-10646 UTF-8 encoding 517 string signature 519 Public key algorithm names for use in "public key algorithm for host 520 key" are defined in the transport layer specification. The "public 521 host key for client host" may include certificates. 523 Signature is a signature with the private host key of the following 524 data, in this order: 526 string session identifier 527 byte SSH_MSG_USERAUTH_REQUEST 528 string user name 529 string service 530 string "hostbased" 531 string public key algorithm for host key 532 string public host key and certificates for client host 533 string client host name expressed as the FQDN in US-ASCII 534 string user name on the client host in ISO-10646 UTF-8 encoding 536 The server MUST verify that the host key actually belongs to the 537 client host named in the message, that the given user on that host is 538 allowed to log in, and that the signature is a valid signature on the 539 appropriate value by the given host key. The server MAY ignore the 540 client user name, if it wants to authenticate only the client host. 542 It is RECOMMENDED that whenever possible, the server perform 543 additional checks to verify that the network address obtained from 544 the (untrusted) network matches the given client host name. This 545 makes exploiting compromised host keys more difficult. Note that 546 this may require special handling for connections coming through a 547 firewall. 549 10. IANA Considerations 551 This document is part of a set. The IANA considerations for the SSH 552 protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and 553 this document, are detailed in [SSH-NUMBERS]. 555 11. Security Considerations 557 The purpose of this protocol is to perform client user 558 authentication. It assumed that this runs over a secure transport 559 layer protocol, which has already authenticated the server machine, 560 established an encrypted communications channel, and computed a 561 unique session identifier for this session. The transport layer 562 provides forward secrecy for password authentication and other 563 methods that rely on secret data. 565 Full security considerations for this protocol are provided in 566 [SSH-ARCH]. 568 12. References 570 12.1 Normative 572 [SSH-ARCH] 573 Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", 574 I-D draft-ietf-architecture-17.txt, October 2004. 576 [SSH-CONNECT] 577 Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D 578 draft-ietf-connect-20.txt, October 2004. 580 [SSH-TRANS] 581 Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", 582 I-D draft-ietf-transport-19.txt, October 2004. 584 [SSH-NUMBERS] 585 Ylonen, T. and C. Lonvick, "SSH Protocol Assigned 586 Numbers", I-D draft-ietf-assignednumbers-07.txt, October 587 2004. 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 593 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 594 October 1998. 596 12.2 Informative 598 [RFC3066] Alvestrand, H., "Tags for the Identification of 599 Languages", BCP 47, RFC 3066, January 2001. 601 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 602 10646", STD 63, RFC 3629, November 2003. 604 Author's Address 606 Chris Lonvick (editor) 607 Cisco Systems, Inc 608 12515 Research Blvd. 609 Austin 78759 610 USA 612 EMail: clonvick@cisco.com 614 Intellectual Property Statement 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 The IETF has been notified of intellectual property rights claimed in 639 regard to some or all of the specification contained in this 640 document. For more information consult the online list of claimed 641 rights. 643 Disclaimer of Validity 645 This document and the information contained herein are provided on an 646 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 647 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 648 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 649 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 650 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 651 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 653 Copyright Statement 655 Copyright (C) The Internet Society (2004). This document is subject 656 to the rights, licenses and restrictions contained in BCP 78, and 657 except as set forth therein, the authors retain all their rights. 659 Acknowledgment 661 Funding for the RFC Editor function is currently provided by the 662 Internet Society.