Updated Branches: refs/heads/master 5bd7629ef -> 46ea09302
http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/rfc4256.txt ---------------------------------------------------------------------- diff --git a/sshd-core/src/docs/rfc4256.txt b/sshd-core/src/docs/rfc4256.txt deleted file mode 100644 index 44f1758..0000000 --- a/sshd-core/src/docs/rfc4256.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group F. Cusack -Request for Comments: 4256 savecore.net -Category: Standards Track M. Forssen - AppGate Network Security AB - January 2006 - - - Generic Message Exchange Authentication for - the Secure Shell Protocol (SSH) - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The Secure Shell Protocol (SSH) is a protocol for secure remote login - and other secure network services over an insecure network. This - document describes a general purpose authentication method for the - SSH protocol, suitable for interactive authentications where the - authentication data should be entered via a keyboard (or equivalent - alphanumeric input device). The major goal of this method is to - allow the SSH client to support a whole class of authentication - mechanism(s) without knowing the specifics of the actual - authentication mechanism(s). - -1. Introduction - - The SSH authentication protocol [SSH-USERAUTH] is a general-purpose - user authentication protocol. It is intended to be run over the SSH - transport layer protocol [SSH-TRANS]. The authentication protocol - assumes that the underlying protocols provide integrity and - confidentiality protection. - - This document describes a general purpose authentication method for - the SSH authentication protocol. This method is suitable for - interactive authentication methods that do not need any special - software support on the client side. Instead, all authentication - data should be entered via the keyboard. The major goal of this - method is to allow the SSH client to have little or no knowledge of - - - -Cusack & Forssen Standards Track [Page 1] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - the specifics of the underlying authentication mechanism(s) used by - the SSH server. This will allow the server to arbitrarily select or - change the underlying authentication mechanism(s) without having to - update client code. - - The name for this authentication method is "keyboard-interactive". - - This document should be read only after reading the SSH architecture - document [SSH-ARCH] and the SSH authentication document - [SSH-USERAUTH]. This document freely uses terminology and notation - from both documents without reference or further explanation. - - This document also describes some of the client interaction with the - user in obtaining the authentication information. While this is - somewhat out of the scope of a protocol specification, it is - described here anyway because some aspects of the protocol are - specifically designed based on user interface issues, and omitting - this information may lead to incompatible or awkward implementations. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC-2119]. - -2. Rationale - - Currently defined authentication methods for SSH are tightly coupled - with the underlying authentication mechanism. This makes it - difficult to add new mechanisms for authentication as all clients - must be updated to support the new mechanism. With the generic - method defined here, clients will not require code changes to support - new authentication mechanisms, and if a separate authentication layer - is used, such as [PAM], then the server may not need any code changes - either. - - This presents a significant advantage to other methods, such as the - "password" method (defined in [SSH-USERAUTH]), as new (presumably - stronger) methods may be added "at will" and system security can be - transparently enhanced. - - Challenge-response and One Time Password mechanisms are also easily - supported with this authentication method. - - However, this authentication method is limited to authentication - mechanisms that do not require any special code, such as hardware - drivers or password mangling, on the client. - - - - - - -Cusack & Forssen Standards Track [Page 2] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - -3. Protocol Exchanges - - The client initiates the authentication with an - SSH_MSG_USERAUTH_REQUEST message. The server then requests - authentication information from the client with an - SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the - information from the user and then responds with an - SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send - another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the - answer from the client. - -3.1. Initial Exchange - - The authentication starts with the client sending the following - packet: - - byte SSH_MSG_USERAUTH_REQUEST - string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) - string service name (US-ASCII) - string "keyboard-interactive" (US-ASCII) - string language tag (as defined in [RFC-3066]) - string submethods (ISO-10646 UTF-8) - - The language tag is deprecated and SHOULD be the empty string. It - may be removed in a future revision of this specification. Instead, - the server SHOULD select the language to be used based on the tags - communicated during key exchange [SSH-TRANS]. - - If the language tag is not the empty string, the server SHOULD use - the specified language for any messages sent to the client as part of - this protocol. The language tag SHOULD NOT be used for language - selection for messages outside of this protocol. If the server does - not support the requested language, the language to be used is - implementation-dependent. - - The submethods field is included so the user can give a hint of which - actual methods he wants to use. It is a comma-separated list of - authentication submethods (software or hardware) that the user - prefers. If the client has knowledge of the submethods preferred by - the user, presumably through a configuration setting, it MAY use the - submethods field to pass this information to the server. Otherwise, - it MUST send the empty string. - - The actual names of the submethods is something the user and the - server need to agree upon. - - Server interpretation of the submethods field is implementation- - dependent. - - - -Cusack & Forssen Standards Track [Page 3] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - One possible implementation strategy of the submethods field on the - server is that, unless the user may use multiple different - submethods, the server ignores this field. If the user may - authenticate using one of several different submethods, the server - should treat the submethods field as a hint on which submethod the - user wants to use this time. - - Note that when this message is sent to the server, the client has not - yet prompted the user for a password, and so that information is NOT - included with this initial message (unlike the "password" method). - - The server MUST reply with an SSH_MSG_USERAUTH_SUCCESS, - SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. - - The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message - if the failure is based on the user name or service name; instead, it - SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s), which look just - like the one(s) that would have been sent in cases where - authentication should proceed, and then send the failure message - (after a suitable delay, as described below). The goal is to make it - impossible to find valid usernames by comparing the results when - authenticating as different users. - - The server MAY reply with an SSH_MSG_USERAUTH_SUCCESS message if no - authentication is required for the user in question. However, a - better approach, for reasons discussed above, might be to reply with - an SSH_MSG_USERAUTH_INFO_REQUEST message and ignore (don't validate) - the response. - -3.2. Information Requests - - Requests are generated from the server using the - SSH_MSG_USERAUTH_INFO_REQUEST message. - - The server may send as many requests as are necessary to authenticate - the client; the client MUST be prepared to handle multiple exchanges. - However, the server MUST NOT ever have more than one - SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may - not send another request before the client has answered. - - - - - - - - - - - - -Cusack & Forssen Standards Track [Page 4] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: - - byte SSH_MSG_USERAUTH_INFO_REQUEST - string name (ISO-10646 UTF-8) - string instruction (ISO-10646 UTF-8) - string language tag (as defined in [RFC-3066]) - int num-prompts - string prompt[1] (ISO-10646 UTF-8) - boolean echo[1] - ... - string prompt[num-prompts] (ISO-10646 UTF-8) - boolean echo[num-prompts] - - The language tag is deprecated and SHOULD be the empty string. It - may be removed in a future revision of this specification. Instead, - the server SHOULD select the language used based on the tags - communicated during key exchange [SSH-TRANS]. - - If the language tag is not the empty string, the server SHOULD use - the specified language for any messages sent to the client as part of - this protocol. The language tag SHOULD NOT be used for language - selection for messages outside of this protocol. If the server does - not support the requested language, the language to be used is - implementation-dependent. - - The server SHOULD take into consideration that some clients may not - be able to properly display a long name or prompt field (see next - section), and limit the lengths of those fields if possible. For - example, instead of an instruction field of "Enter Password" and a - prompt field of "Password for [email protected]: ", a better choice - might be an instruction field of "Password authentication for - [email protected]" and a prompt field of "Password: ". It is - expected that this authentication method would typically be backended - by [PAM] and so such choices would not be possible. - - The name and instruction fields MAY be empty strings; the client MUST - be prepared to handle this correctly. The prompt field(s) MUST NOT - be empty strings. - - The num-prompts field may be `0', in which case there will be no - prompt/echo fields in the message, but the client SHOULD still - display the name and instruction fields (as described below). - - - - - - - - - -Cusack & Forssen Standards Track [Page 5] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - -3.3. User Interface - - Upon receiving a request message, the client SHOULD prompt the user - as follows: - - A command line interface (CLI) client SHOULD print the name and - instruction (if non-empty), adding newlines. Then, for each prompt - in turn, the client SHOULD display the prompt and read the user - input. - - A graphical user interface (GUI) client has many choices on how to - prompt the user. One possibility is to use the name field (possibly - prefixed with the application's name) as the title of a dialog window - in which the prompt(s) are presented. In that dialog window, the - instruction field would be a text message, and the prompts would be - labels for text entry fields. All fields SHOULD be presented to the - user. For example, an implementation SHOULD NOT discard the name - field because its windows lack titles; instead, it SHOULD find - another way to display this information. If prompts are presented in - a dialog window, then the client SHOULD NOT present each prompt in a - separate window. - - All clients MUST properly handle an instruction field with embedded - newlines. They SHOULD also be able to display at least 30 characters - for the name and prompts. If the server presents names or prompts - longer than 30 characters, the client MAY truncate these fields to - the length it can display. If the client does truncate any fields, - there MUST be an obvious indication that such truncation has - occurred. The instruction field SHOULD NOT be truncated. - - Clients SHOULD use control character filtering, as discussed in - [SSH-ARCH], to avoid attacks by including terminal control characters - in the fields to be displayed. - - For each prompt, the corresponding echo field indicates whether the - user input should be echoed as characters are typed. Clients SHOULD - correctly echo/mask user input for each prompt independently of other - prompts in the request message. If a client does not honor the echo - field for whatever reason, then the client MUST err on the side of - masking input. A GUI client might like to have a checkbox toggling - echo/mask. Clients SHOULD NOT add any additional characters to the - prompt, such as ": " (colon-space); the server is responsible for - supplying all text to be displayed to the user. Clients MUST also - accept empty responses from the user and pass them on as empty - strings. - - - - - - -Cusack & Forssen Standards Track [Page 6] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - -3.4. Information Responses - - After obtaining the requested information from the user, the client - MUST respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message. - - The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as - follows: - - byte SSH_MSG_USERAUTH_INFO_RESPONSE - int num-responses - string response[1] (ISO-10646 UTF-8) - ... - string response[num-responses] (ISO-10646 UTF-8) - - Note that the responses are encoded in ISO-10646 UTF-8. It is up to - the server how it interprets the responses and validates them. - However, if the client reads the responses in some other encoding - (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 - before transmitting. - - From an internationalization standpoint, it is desired that if a user - enters responses, the authentication process will work regardless of - what OS and client software they are using. Doing so requires - normalization. Systems supporting non-ASCII passwords SHOULD always - normalize passwords and usernames whenever they are added to the - database, or compare them (with or without hashing) to existing - entries in the database. SSH implementations that both store the - passwords and compare them SHOULD use [SASLPREP] for normalization. - - If the num-responses field does not match the num-prompts field in - the request message, the server MUST send a failure message. - - In the case that the server sends a `0' num-prompts field in the - request message, the client MUST send a response message with a `0' - num-responses field to complete the exchange. - - The responses MUST be ordered as the prompts were ordered. That is, - response[n] MUST be the answer to prompt[n]. - - After receiving the response, the server MUST send either an - SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another - SSH_MSG_USERAUTH_INFO_REQUEST message. - - If the server fails to authenticate the user (through the underlying - authentication mechanism(s)), it SHOULD NOT send another request - message(s) in an attempt to obtain new authentication data; instead, - it SHOULD send a failure message. The only time the server should - send multiple request messages is if additional authentication data - - - -Cusack & Forssen Standards Track [Page 7] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - is needed (i.e., because there are multiple underlying authentication - mechanisms that must be used to authenticate the user). - - If the server intends to respond with a failure message, it MAY delay - for an implementation-dependent time before sending it to the client. - It is suspected that implementations are likely to make the time - delay configurable; a suggested default is 2 seconds. - -4. Authentication Examples - - Here are two example exchanges between a client and server. The - first is an example of challenge/response with a handheld token. - This is an authentication that is not otherwise possible with other - authentication methods. - - C: byte SSH_MSG_USERAUTH_REQUEST - C: string "user23" - C: string "ssh-userauth" - C: string "keyboard-interactive" - C: string "" - C: string "" - - S: byte SSH_MSG_USERAUTH_INFO_REQUEST - S: string "CRYPTOCard Authentication" - S: string "The challenge is '14315716'" - S: string "en-US" - S: int 1 - S: string "Response: " - S: boolean TRUE - - [Client prompts user for password] - - C: byte SSH_MSG_USERAUTH_INFO_RESPONSE - C: int 1 - C: string "6d757575" - - S: byte SSH_MSG_USERAUTH_SUCCESS - - - - - - - - - - - - - - -Cusack & Forssen Standards Track [Page 8] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - The second example is a standard password authentication; in this - case, the user's password is expired. - - C: byte SSH_MSG_USERAUTH_REQUEST - C: string "user23" - C: string "ssh-userauth" - C: string "keyboard-interactive" - C: string "en-US" - C: string "" - - S: byte SSH_MSG_USERAUTH_INFO_REQUEST - S: string "Password Authentication" - S: string "" - S: string "en-US" - S: int 1 - S: string "Password: " - S: boolean FALSE - - [Client prompts user for password] - - C: byte SSH_MSG_USERAUTH_INFO_RESPONSE - C: int 1 - C: string "password" - - S: byte SSH_MSG_USERAUTH_INFO_REQUEST - S: string "Password Expired" - S: string "Your password has expired." - S: string "en-US" - S: int 2 - S: string "Enter new password: " - S: boolean FALSE - S: string "Enter it again: " - S: boolean FALSE - - [Client prompts user for new password] - - C: byte SSH_MSG_USERAUTH_INFO_RESPONSE - C: int 2 - C: string "newpass" - C: string "newpass" - - S: byte SSH_MSG_USERAUTH_INFO_REQUEST - S: string "Password changed" - S: string "Password successfully changed for user23." - S: string "en-US" - S: int 0 - - - - - -Cusack & Forssen Standards Track [Page 9] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - [Client displays message to user] - - C: byte SSH_MSG_USERAUTH_INFO_RESPONSE - C: int 0 - - S: byte SSH_MSG_USERAUTH_SUCCESS - -5. IANA Considerations - - The userauth type "keyboard-interactive" is used for this - authentication method. - - The following method-specific constants are used with this - authentication method: - - SSH_MSG_USERAUTH_INFO_REQUEST 60 - SSH_MSG_USERAUTH_INFO_RESPONSE 61 - -6. Security Considerations - - The authentication protocol and this authentication method depend on - the security of the underlying SSH transport layer. Without the - confidentiality provided therein, any authentication data passed with - this method is subject to interception. - - The number of client-server exchanges required to complete an - authentication using this method may be variable. It is possible - that an observer may gain valuable information simply by counting - that number. For example, an observer may guess that a user's - password has expired, and with further observation may be able to - determine the password lifetime imposed by a site's password - expiration policy. - -7. References - -7.1. Normative References - - [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC-3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC-3066] Alvestrand, H., "Tags for the Identification of - Languages", BCP 47, RFC 3066, January 2001. - - - - - - -Cusack & Forssen Standards Track [Page 10] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - - [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell - (SSH) Protocol Architecture", RFC 4251, January 2006. - - [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell - (SSH) Authentication Protocol", RFC 4252, January - 2006. - - [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell - (SSH) Transport Layer Protocol", RFC 4253, January - 2006. - - [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User - Names and Passwords", RFC 4013, February 2005. - -7.2. Informative References - - [PAM] Samar, V., Schemers, R., "Unified Login With - Pluggable Authentication Modules (PAM)", OSF RFC - 86.0, October 1995. - -Authors' Addresses - - Frank Cusack - savecore.net - - EMail: [email protected] - - - Martin Forssen - AppGate Network Security AB - Otterhallegatan 2 - SE-411 18 Gothenburg - SWEDEN - - EMail: [email protected] - - - - - - - - - - - - - - - - -Cusack & Forssen Standards Track [Page 11] - -RFC 4256 SSH Generic Interactive Authentication January 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - [email protected]. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Cusack & Forssen Standards Track [Page 12] - http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/rfc4345.txt ---------------------------------------------------------------------- diff --git a/sshd-core/src/docs/rfc4345.txt b/sshd-core/src/docs/rfc4345.txt deleted file mode 100644 index 6b764a1..0000000 --- a/sshd-core/src/docs/rfc4345.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group B. Harris -Request for Comments: 4345 January 2006 -Category: Standards Track - - - Improved Arcfour Modes for - the Secure Shell (SSH) Transport Layer Protocol - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies methods of using the Arcfour cipher in the - Secure Shell (SSH) protocol that mitigate the weakness of the - cipher's key-scheduling algorithm. - -1. Introduction - - Secure Shell (SSH) [RFC4251] is a secure remote-login protocol. It - allows for the use of an extensible variety of symmetric cipher - algorithms to provide confidentiality for data in transit. One of - the algorithms specified in the base protocol is "arcfour", which - specifies the use of Arcfour (also known as RC4), a fast stream - cipher. As [RFC4253] says, though, "Arcfour (and RC4) has problems - with weak keys, and should be used with caution." These problems are - described in more detail in [MANTIN01], along with a recommendation - to discard the first 1536 bytes of keystream so as to ensure that the - cipher's internal state is thoroughly mixed. This document specifies - new cipher algorithms for SSH that follow this recommendation. - -2. Conventions Used in this Document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - -Harris Standards Track [Page 1] - -RFC 4345 Improved Arcfour Modes for SSH January 2006 - - -3. Applicability Statement - - Implementations of Arcfour are typically slightly faster and much - smaller than those of any other encryption algorithm currently - defined for SSH. This must be balanced, though, against the known - security problems with Arcfour described in Section 5. In most - cases, where speed and code size are not critical issues, the - algorithms specified by [RFC4344] should be used instead. - -4. Algorithm Definitions - - The "arcfour128" algorithm is the RC4 cipher, as described in - [SCHNEIER], using a 128-bit key. The first 1536 bytes of keystream - generated by the cipher MUST be discarded, and the first byte of the - first encrypted packet MUST be encrypted using the 1537th byte of - keystream. - - The "arcfour256" algorithm is the same, but uses a 256-bit key. - -5. Security Considerations - - The security considerations in [RFC4251] apply. - - The discarded bytes of keystream MUST be kept secret and MUST NOT be - transmitted over the network. The contents of these bytes could - reveal information about the key. - - There are two classes of attack on Arcfour described in [MIRONOV]. - Strong distinguishers distinguish an Arcfour keystream from - randomness at the start of the stream and are defended against by the - algorithm defined in this document. Weak distinguishers can operate - on any part of the keystream, and the best ones, described in [FMcG] - and [MANTIN05], can use data from multiple, different keystreams. A - consequence of this is that encrypting the same data (for instance, a - password) sufficiently many times in separate Arcfour keystreams can - be sufficient to leak information about it to an adversary. It is - thus RECOMMENDED that Arcfour (either in the form described here or - that described in [RFC4251]) not be used for high-volume password- - authenticated connections. - -6. IANA Considerations - - The IANA has assigned the Encryption Algorithm Names "arcfour128" and - "arcfour256" in accordance with [RFC4250]. - - - - - - - -Harris Standards Track [Page 2] - -RFC 4345 Improved Arcfour Modes for SSH January 2006 - - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) - Protocol Assigned Numbers", RFC 4250, January 2006. - - [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) - Protocol Architecture", RFC 4251, January 2006. - - [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) - Transport Layer Protocol", RFC 4253, January 2006 - - [RFC4344] Bellare, M., Kohno, T., and C. Namprempre, "The Secure - Shell (SSH) Transport Layer Encryption Modes", RFC 4344, - January 2006. - - [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: - protocols algorithms and source in code in C", John Wiley - and Sons, New York, NY, 1996. - -7.2. Informative References - - [FMcG] Fluhrer, S. and D. McGrew, "Statistical Analysis of the - Alleged RC4 Keystream Generator", Fast Software - Encryption: 7th International Workshop, FSE 2000, April - 2000, <http://www.mindspring.com/~dmcgrew/rc4-03.pdf>. - - [MANTIN01] Mantin, I., "Analysis of the Stream Cipher RC4", M.Sc. - Thesis, Weizmann Institute of Science, 2001, <http:// - www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Mantin1.zip>. - - [MIRONOV] Mironov, I., "(Not So) Random Shuffles of RC4", Advances - in Cryptology -- CRYPTO 2002: 22nd Annual International - Cryptology Conference, August 2002, - <http://eprint.iacr.org/2002/067.pdf>. - - [MANTIN05] Mantin, I., "Predicting and Distinguishing Attacks on RC4 - Keystream Generator", Advances in Cryptology -- EUROCRYPT - 2005: 24th Annual International Conference on the Theory - and Applications of Cryptographic Techniques, May 2005. - - - - - - - -Harris Standards Track [Page 3] - -RFC 4345 Improved Arcfour Modes for SSH January 2006 - - -Author's Address - - Ben Harris - 2a Eachard Road - CAMBRIDGE - CB3 0HY - UNITED KINGDOM - - EMail: [email protected] - -Trademark Notice - - "RC4" and "SSH" are registered trademarks in the United States. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Harris Standards Track [Page 4] - -RFC 4345 Improved Arcfour Modes for SSH January 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - [email protected]. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Harris Standards Track [Page 5] - \ No newline at end of file http://git-wip-us.apache.org/repos/asf/mina-sshd/blob/46ea0930/sshd-core/src/docs/rfc4419.txt ---------------------------------------------------------------------- diff --git a/sshd-core/src/docs/rfc4419.txt b/sshd-core/src/docs/rfc4419.txt deleted file mode 100644 index 87f9af7..0000000 --- a/sshd-core/src/docs/rfc4419.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group M. Friedl -Request for Comments: 4419 N. Provos -Category: Standards Track W. Simpson - March 2006 - - - Diffie-Hellman Group Exchange for - the Secure Shell (SSH) Transport Layer Protocol - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo describes a new key exchange method for the Secure Shell - (SSH) protocol. It allows the SSH server to propose new groups on - which to perform the Diffie-Hellman key exchange to the client. The - proposed groups need not be fixed and can change with time. - -1. Overview and Rationale - - SSH [RFC4251] is a very common protocol for secure remote login on - the Internet. Currently, SSH performs the initial key exchange using - the "diffie-hellman-group1-sha1" method [RFC4253]. This method - prescribes a fixed group on which all operations are performed. - - The Diffie-Hellman key exchange provides a shared secret that cannot - be determined by either party alone. Furthermore, the shared secret - is known only to the participant parties. In SSH, the key exchange - is signed with the host key to provide host authentication. - - The security of the Diffie-Hellman key exchange is based on the - difficulty of solving the Discrete Logarithm Problem (DLP). Since we - expect that the SSH protocol will be in use for many years in the - future, we fear that extensive precomputation and more efficient - algorithms to compute the discrete logarithm over a fixed group might - pose a security threat to the SSH protocol. - - - - - -Friedl, et al. Standards Track [Page 1] - -RFC 4419 SSH DH Group Exchange March 2006 - - - The ability to propose new groups will reduce the incentive to use - precomputation for more efficient calculation of the discrete - logarithm. The server can constantly compute new groups in the - background. - -2. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -3. Diffie-Hellman Group and Key Exchange - - The server keeps a list of safe primes and corresponding generators - that it can select from. A prime p is safe if p = 2q + 1 and q is - prime. New primes can be generated in the background. - - The generator g should be chosen such that the order of the generated - subgroup does not factor into small primes; that is, with p = 2q + 1, - the order has to be either q or p - 1. If the order is p - 1, then - the exponents generate all possible public values, evenly distributed - throughout the range of the modulus p, without cycling through a - smaller subset. Such a generator is called a "primitive root" (which - is trivial to find when p is "safe"). - - The client requests a modulus from the server indicating the - preferred size. In the following description (C is the client, S is - the server, the modulus p is a large safe prime, and g is a generator - for a subgroup of GF(p), min is the minimal size of p in bits that is - acceptable to the client, n is the size of the modulus p in bits that - the client would like to receive from the server, max is the maximal - size of p in bits that the client can accept, V_S is S's version - string, V_C is C's version string, K_S is S's public host key, I_C is - C's KEXINIT message, and I_S is S's KEXINIT message that has been - exchanged before this part begins): - - 1. C sends "min || n || max" to S, indicating the minimal acceptable - group size, the preferred size of the group, and the maximal - group size in bits the client will accept. - - 2. S finds a group that best matches the client's request, and sends - "p || g" to C. - - 3. C generates a random number x, where 1 < x < (p-1)/2. It - computes e = g^x mod p, and sends "e" to S. - - - - - - -Friedl, et al. Standards Track [Page 2] - -RFC 4419 SSH DH Group Exchange March 2006 - - - 4. S generates a random number y, where 0 < y < (p-1)/2, and - computes f = g^y mod p. S receives "e". It computes K = e^y mod - p, H = hash(V_C || V_S || I_C || I_S || K_S || min || n || max || - p || g || e || f || K) (these elements are encoded according to - their types; see below), and signature s on H with its private - host key. S sends "K_S || f || s" to C. The signing operation - may involve a second hashing operation. - - 5. C verifies that K_S really is the host key for S (e.g., using - certificates or a local database to obtain the public key). C is - also allowed to accept the key without verification; however, - doing so will render the protocol insecure against active attacks - (but may be desirable for practical reasons in the short term in - many environments). C then computes K = f^x mod p, H = hash(V_C - || V_S || I_C || I_S || K_S || min || n || max || p || g || e || - f || K), and verifies the signature s on H. - - Servers and clients SHOULD support groups with a modulus length of k - bits, where 1024 <= k <= 8192. The recommended values for min and - max are 1024 and 8192, respectively. - - Either side MUST NOT send or accept e or f values that are not in the - range [1, p-1]. If this condition is violated, the key exchange - fails. To prevent confinement attacks, they MUST accept the shared - secret K only if 1 < K < p - 1. - - The server should return the smallest group it knows that is larger - than the size the client requested. If the server does not know a - group that is larger than the client request, then it SHOULD return - the largest group it knows. In all cases, the size of the returned - group SHOULD be at least 1024 bits. - - This is implemented with the following messages. The hash algorithm - for computing the exchange hash is defined by the method name, and is - called HASH. The public key algorithm for signing is negotiated with - the KEXINIT messages. - - First, the client sends: - - byte SSH_MSG_KEY_DH_GEX_REQUEST - uint32 min, minimal size in bits of an acceptable group - uint32 n, preferred size in bits of the group the server will send - uint32 max, maximal size in bits of an acceptable group - - - - - - - - -Friedl, et al. Standards Track [Page 3] - -RFC 4419 SSH DH Group Exchange March 2006 - - - The server responds with - - byte SSH_MSG_KEX_DH_GEX_GROUP - mpint p, safe prime - mpint g, generator for subgroup in GF(p) - - The client responds with: - - byte SSH_MSG_KEX_DH_GEX_INIT - mpint e - - The server responds with: - - byte SSH_MSG_KEX_DH_GEX_REPLY - string server public host key and certificates (K_S) - mpint f - string signature of H - - The hash H is computed as the HASH hash of the concatenation of the - following: - - string V_C, the client's version string (CR and NL excluded) - string V_S, the server's version string (CR and NL excluded) - string I_C, the payload of the client's SSH_MSG_KEXINIT - string I_S, the payload of the server's SSH_MSG_KEXINIT - string K_S, the host key - uint32 min, minimal size in bits of an acceptable group - uint32 n, preferred size in bits of the group the server will send - uint32 max, maximal size in bits of an acceptable group - mpint p, safe prime - mpint g, generator for subgroup - mpint e, exchange value sent by the client - mpint f, exchange value sent by the server - mpint K, the shared secret - - This value is called the exchange hash, and it is used to - authenticate the key exchange as per [RFC4253]. - -4. Key Exchange Methods - - This document defines two new key exchange methods: - "diffie-hellman-group-exchange-sha1" and - "diffie-hellman-group-exchange-sha256". - - - - - - - - -Friedl, et al. Standards Track [Page 4] - -RFC 4419 SSH DH Group Exchange March 2006 - - -4.1. diffie-hellman-group-exchange-sha1 - - The "diffie-hellman-group-exchange-sha1" method specifies - Diffie-Hellman Group and Key Exchange with SHA-1 [FIPS-180-2] as - HASH. - -4.2. diffie-hellman-group-exchange-sha256 - - The "diffie-hellman-group-exchange-sha256" method specifies - Diffie-Hellman Group and Key Exchange with SHA-256 [FIPS-180-2] as - HASH. - - Note that the hash used in key exchange (in this case, SHA-256) must - also be used in the key derivation pseudo-random function (PRF), as - per the requirement in the "Output from Key Exchange" section in - [RFC4253]. - -5. Summary of Message Numbers - - The following message numbers have been defined in this document. - They are in a name space private to this document and not assigned by - IANA. - - #define SSH_MSG_KEX_DH_GEX_REQUEST_OLD 30 - #define SSH_MSG_KEX_DH_GEX_REQUEST 34 - #define SSH_MSG_KEX_DH_GEX_GROUP 31 - #define SSH_MSG_KEX_DH_GEX_INIT 32 - #define SSH_MSG_KEX_DH_GEX_REPLY 33 - - SSH_MSG_KEX_DH_GEX_REQUEST_OLD is used for backward compatibility. - Instead of sending "min || n || max", the client only sends "n". In - addition, the hash is calculated using only "n" instead of "min || n - || max". - - The numbers 30-49 are key exchange specific and may be redefined by - other kex methods. - -6. Implementation Notes - -6.1. Choice of Generator - - One useful technique is to select the generator, and then limit the - modulus selection sieve to primes with that generator: - - 2 when p (mod 24) = 11. - 5 when p (mod 10) = 3 or 7. - - - - - -Friedl, et al. Standards Track [Page 5] - -RFC 4419 SSH DH Group Exchange March 2006 - - - It is recommended to use 2 as generator, because it improves - efficiency in multiplication performance. It is usable even when it - is not a primitive root, as it still covers half of the space of - possible residues. - -6.2. Private Exponents - - To increase the speed of the key exchange, both client and server may - reduce the size of their private exponents. It should be at least - twice as long as the key material that is generated from the shared - secret. For more details, see the paper by van Oorschot and Wiener - [VAN-OORSCHOT]. - -7. Security Considerations - - This protocol aims to be simple and uses only well-understood - primitives. This encourages acceptance by the community and allows - for ease of implementation, which hopefully leads to a more secure - system. - - The use of multiple moduli inhibits a determined attacker from - precalculating moduli exchange values, and discourages dedication of - resources for analysis of any particular modulus. - - It is important to employ only safe primes as moduli, as they allow - us to find a generator g so that the order of the generated subgroup - does not factor into small primes, that is, with p = 2q + 1, the - order has to be either q or p - 1. If the order is p - 1, then the - exponents generate all possible public values, evenly distributed - throughout the range of the modulus p, without cycling through a - smaller subset. Van Oorshot and Wiener note that using short private - exponents with a random prime modulus p makes the computation of the - discrete logarithm easy [VAN-OORSCHOT]. However, they also state - that this problem does not apply to safe primes. - - The least significant bit of the private exponent can be recovered - when the modulus is a safe prime [MENEZES]. However, this is not a - problem if the size of the private exponent is big enough. Related - to this, Waldvogel and Massey note: When private exponents are chosen - independently and uniformly at random from {0,...,p-2}, the key - entropy is less than 2 bits away from the maximum, lg(p-1) - [WALDVOGEL]. - - The security considerations in [RFC4251] also apply to this key - exchange method. - - - - - - -Friedl, et al. Standards Track [Page 6] - -RFC 4419 SSH DH Group Exchange March 2006 - - -8. Acknowledgements - - The document is derived in part from "SSH Transport Layer Protocol" - [RFC4253] by T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, and S. - Lehtinen. - - Markku-Juhani Saarinen pointed out that the least significant bit of - the private exponent can be recovered efficiently when using safe - primes and a subgroup with an order divisible by two. - - Bodo Moeller suggested that the server send only one group, reducing - the complexity of the implementation and the amount of data that - needs to be exchanged between client and server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Friedl, et al. Standards Track [Page 7] - -RFC 4419 SSH DH Group Exchange March 2006 - - -Appendix A: Generation of Safe Primes - - The "Handbook of Applied Cryptography" [MENEZES] lists the following - algorithm to generate a k-bit safe prime p. It has been modified so - that 2 is a generator for the multiplicative group mod p. - - 1. Do the following: - - 1. Select a random (k-1)-bit prime q, so that q mod 12 = 5. - - 2. Compute p := 2q + 1, and test whether p is prime (using, - e.g., trial division and the Rabin-Miller test). - - 2. Repeat until p is prime. - - If an implementation uses the OpenSSL libraries, a group consisting - of a 1024-bit safe prime and 2 as generator can be created as - follows: - - DH *d = NULL; - d = DH_generate_parameters(1024, DH_GENERATOR_2, NULL, NULL); - BN_print_fp(stdout, d->p); - - The order of the subgroup generated by 2 is q = p - 1. - -References - -Normative References - - [FIPS-180-2] National Institute of Standards and Technology (NIST), - "Secure Hash Standard (SHS)", FIPS PUB 180-2, - August 2002. - - [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) - Protocol Architecture", RFC 4251, January 2006. - - [RFC4253] Lonvick, C., "The Secure Shell (SSH) Transport Layer - Protocol", RFC 4253, January 2006. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -Informative References - - [MENEZES] Menezes, A., van Oorschot, P., and S. Vanstone, - "Handbook of Applied Cryptography", CRC Press, p. 537, - 1996. - - - - -Friedl, et al. Standards Track [Page 8] - -RFC 4419 SSH DH Group Exchange March 2006 - - - [VAN-OORSCHOT] van Oorschot, P. and M. Wiener, "On Diffie-Hellman key - agreement with short exponents", Advances in - Cryptology -EUROCRYPT'96, LNCS 1070, - Springer-Verlag, pp. 332-343, 1996. - - [WALDVOGEL] Waldvogel, C. and J. Massey, "The probability - distribution of the Diffie-Hellman key", Proceedings - of AUSCRYPT 92, LNCS 718, Springer-Verlag, pp. - 492-504, 1993. - -Authors' Addresses - - Markus Friedl - EMail: [email protected] - - - Niels Provos - EMail: [email protected] - - - William A. Simpson - EMail: [email protected] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Friedl, et al. Standards Track [Page 9] - -RFC 4419 SSH DH Group Exchange March 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - [email protected]. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Friedl, et al. Standards Track [Page 10] -
