From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 00:22:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05536 for ; Fri, 1 Mar 2002 00:21:49 -0500 (EST) Received: (qmail 9233 invoked by uid 605); 1 Mar 2002 05:21:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9226 invoked from network); 1 Mar 2002 05:21:24 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 1 Mar 2002 05:21:24 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA09297 for ; Thu, 28 Feb 2002 21:21:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id VAA20115 for ; Thu, 28 Feb 2002 21:21:25 -0800 (PST) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g215L4sv445783 for ; Thu, 28 Feb 2002 21:21:15 -0800 (PST) Message-Id: <200203010521.g215L4sv445783@jurassic.eng.sun.com> Date: Thu, 28 Feb 2002 21:19:37 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: updated transport & userauth drafts To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Knot_of_Toads_857_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list --Knot_of_Toads_857_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Q3UFZiU2X7wKPZiUBzGhcQ== The updated transport and userauth drafts have been submitted and are in the queue to comeout by March 11th. Since this is a little while away I've attached copies below. The two issues addressed are the x.509 and the stonger language on dealing with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. No changes are now possible until after the next IETF. -- Darren J Moffat --Knot_of_Toads_857_000 Content-Type: TEXT/plain; name="draft-ietf-secsh-userauth-15.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-ietf-secsh-userauth-15.txt Content-MD5: Ieb1nba3Z6RXcbftLkz4Gw== Network Working Group T. Ylonen Internet-Draft T. Kivinen Expires: August 29, 2002 SSH Communications Security Corp M. Saarinen University of Jyvaskyla T. Rinne S. Lehtinen SSH Communications Security Corp February 28, 2002 SSH Authentication Protocol draft-ietf-secsh-userauth-15.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides Ylonen, et. al. Expires August 29, 2002 [Page 1] Internet-Draft SSH Authentication Protocol February 2002 a single authenticated tunnel for the SSH connection protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Authentication Protocol Framework . . . . . . . . . . . . 3 2.1 Authentication Requests . . . . . . . . . . . . . . . . . . . 4 2.2 Responses to Authentication Requests . . . . . . . . . . . . . 4 2.3 The "none" Authentication Request . . . . . . . . . . . . . . 6 2.4 Completion of User Authentication . . . . . . . . . . . . . . 6 2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Authentication Protocol Message Numbers . . . . . . . . . . . 7 4. Public Key Authentication Method: publickey . . . . . . . . . 7 5. Password Authentication Method: password . . . . . . . . . . . 9 6. Host-Based Authentication: hostbased . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 13 9. Additional Information . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Ylonen, et. al. Expires August 29, 2002 [Page 2] Internet-Draft SSH Authentication Protocol February 2002 1. Introduction The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. This protocol assumes that the underlying protocols provide integrity and confidentiality protection. This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation. The service name for this protocol is "ssh-userauth". When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower- level protocol provides confidentiality protection. 2. The Authentication Protocol Framework The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server. Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be allowed in without any authentication, in which case the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server. The server SHOULD have a timeout for authentication, and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect. Ylonen, et. al. Expires August 29, 2002 [Page 3] Internet-Draft SSH Authentication Protocol February 2002 2.1 Authentication Requests All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding [RFC2279]) string service name (in US-ASCII) string method name (US-ASCII) The rest of the packet is method-specific. The user name and service are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to flush some authentication state, it MUST disconnect if the user or service name changes. The service name specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or at any later time. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, authentication MUST NOT be accepted. If the requested user does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentication methods, but never accept any. This makes it possible for the server to avoid disclosing information on which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted. While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize. An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. 2.2 Responses to Authentication Requests If the server rejects the authentication request, it MUST respond with the following: Ylonen, et. al. Expires August 29, 2002 [Page 4] Internet-Draft SSH Authentication Protocol February 2002 byte SSH_MSG_USERAUTH_FAILURE string authentications that can continue boolean partial success "Authentications that can continue" is a comma-separated list of authentication method names that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those methods in the list that are actually useful. However, it is not illegal to include methods that cannot be used to authenticate the user. Already successfully completed authentications SHOULD NOT be included in the list, unless they really should be performed again for some reason. "Partial success" MUST be TRUE if the authentication request to which this is a response was successful. It MUST be FALSE if the request was not successfully processed. When the server accepts authentication, it MUST respond with the following: byte SSH_MSG_USERAUTH_SUCCESS Note that this is not sent after each step in a multi-method authentication sequence, but only when the authentication is complete. The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request. A request that results in further exchange of messages will be aborted by a second request. It is not possible to send a second request without waiting for a response from the server, if the first request will result in further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section Message Numbers Ylonen, et. al. Expires August 29, 2002 [Page 5] Internet-Draft SSH Authentication Protocol February 2002 (Section 3)). 2.3 The "none" Authentication Request A client may request a list of authentication methods that may continue by using the "none" authentication method. If no authentication at all is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication methods that can continue. This method MUST NOT be listed as supported by the server. 2.4 Completion of User Authentication Authentication is complete when the server has responded with SSH_MSG_USERAUTH_SUCCESS; all authentication related messages received after sending this message SHOULD be silently ignored. After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested service. 2.5 Banner Message In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from `/etc/issue', or use "tcp wrappers" or similar software to display a banner before issuing a login prompt. The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time before authentication is successful. This message contains text to be displayed to the client user before authentication is attempted. The format is as follows: byte SSH_MSG_USERAUTH_BANNER string message (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) The client SHOULD by default display the message on the screen. However, since the message is likely to be sent for every login attempt, and since some client software will need to open a separate window for this warning, the client software may allow the user to explicitly disable the display of banners from the server. The message may consist of multiple lines. If the message string is displayed, control character filtering Ylonen, et. al. Expires August 29, 2002 [Page 6] Internet-Draft SSH Authentication Protocol February 2002 discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending terminal control characters. 3. Authentication Protocol Message Numbers All message numbers used by this authentication protocol are in the range from 50 to 79, which is part of the range reserved for protocols running on top of the SSH transport layer protocol. Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting (preferably with a proper disconnect message sent first to ease troubleshooting). After successful authentication, such messages are passed to the higher-level service. These are the general authentication message codes: #define SSH_MSG_USERAUTH_REQUEST 50 #define SSH_MSG_USERAUTH_FAILURE 51 #define SSH_MSG_USERAUTH_SUCCESS 52 #define SSH_MSG_USERAUTH_BANNER 53 In addition to the above, there is a range of message numbers (60..79) reserved for method-specific messages. These messages are only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). Different authentication methods reuse the same message numbers. 4. Public Key Authentication Method: publickey The only REQUIRED authentication method is public key authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future. With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) Private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can Ylonen, et. al. Expires August 29, 2002 [Page 7] Internet-Draft SSH Authentication Protocol February 2002 be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the key would be acceptable. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean FALSE string public key algorithm name string public key blob Public key algorithms are defined in the transport layer specification [SSH-TRANS]. The public key blob may contain certificates. Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request. The server MUST respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following: byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request To perform actual authentication, the client MAY then send a signature generated using the private key. The client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature Signature is a signature by the corresponding private key over the following data, in the following order: string session identifier byte SSH_MSG_USERAUTH_REQUEST Ylonen, et. al. Expires August 29, 2002 [Page 8] Internet-Draft SSH Authentication Protocol February 2002 string user name string service string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct. If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). The following method-specific message numbers are used by the publickey authentication method. /* Key-based */ #define SSH_MSG_USERAUTH_PK_OK 60 5. Password Authentication Method: password Password authentication uses the following packets. Note that a server MAY request the user to change the password. All implementations SHOULD support password authentication. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean FALSE string plaintext password (ISO-10646 UTF-8) Note that the password is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying Ylonen, et. al. Expires August 29, 2002 [Page 9] Internet-Draft SSH Authentication Protocol February 2002 transport layer provides confidentiality (i.e., if encryption is being used). If no confidentiality is provided (none cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled. Normally, the server responds to this message with success or failure. However, if the password has expired the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In anycase the server MUST NOT allow an expired password to be used for authentication. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt (ISO-10646 UTF-8) string language tag (as defined in [RFC1766]) In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean TRUE string plaintext old password (ISO-10646 UTF-8) string plaintext new password (ISO-10646 UTF-8) The server must reply to request message with SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows: SSH_MSG_USERAUTH_SUCCESS The password has been changed, and authentication has been successfully completed. SSH_MSG_USERAUTH_FAILURE with partial success The password has been changed, but more authentications are needed. SSH_MSG_USERAUTH_FAILURE without partial success The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password. SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because the new password was not acceptable (e.g. too easy to guess). Ylonen, et. al. Expires August 29, 2002 [Page 10] Internet-Draft SSH Authentication Protocol February 2002 The following method-specific message numbers are used by the password authentication method. #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 6. Host-Based Authentication: hostbased Some sites wish to allow authentication based on the host where the user is coming from, and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key. The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously. This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host (ISO-10646 UTF-8) string signature Public key algorithm names for use in "public key algorithm for host key" are defined in the transport layer specification. The "public host key for client host" may include certificates. Signature is a signature with the private host key of the following data, in this order: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service Ylonen, et. al. Expires August 29, 2002 [Page 11] Internet-Draft SSH Authentication Protocol February 2002 string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name (FQDN; US-ASCII) string user name on the client host(ISO-10646 UTF-8) The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the signature is a valid signature on the appropriate value by the given host key. The server MAY ignore the client user name, if it wants to authenticate only the client host. It is RECOMMENDED that whenever possible, the server perform additional checks to verify that the network address obtained from the (untrusted) network matches the given client host name. This makes exploiting compromised host keys more difficult. Note that this may require special handling for connections coming through a firewall. 7. Security Considerations The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data. The server may go into a "sleep" period after repeated unsuccessful authentications to make key search harder. If the transport layer does not provide encryption, authentication methods that rely on secret data SHOULD be disabled. If it does not provide MAC protection, requests to change authentication data (e.g. password change) SHOULD be disabled to avoid an attacker from modifying the ciphertext without being noticed, rendering the new authentication data unusable (denial of service). Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during Ylonen, et. al. Expires August 29, 2002 [Page 12] Internet-Draft SSH Authentication Protocol February 2002 user authentication phase) if high security is required. 8. Trademark Issues As of this writing, SSH Communications Security Oy claims ssh as its trademark. As with all IPR claims the IETF takes no position regarding the validity or scope of this trademark claim. 9. Additional Information The current document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html References [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- ietf-architecture-12.txt, July 2001. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-13.txt, July 2001. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- ietf-userauth-15.txt, July 2001. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-15.txt, July 2001. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Ylonen, et. al. Expires August 29, 2002 [Page 13] Internet-Draft SSH Authentication Protocol February 2002 Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: kivinen@ssh.com Markku-Juhani O. Saarinen University of Jyvaskyla Timo J. Rinne SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: tri@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen, et. al. Expires August 29, 2002 [Page 14] Internet-Draft SSH Authentication Protocol February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen, et. al. Expires August 29, 2002 [Page 15] --Knot_of_Toads_857_000 Content-Type: TEXT/plain; name="draft-ietf-secsh-transport-13.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-ietf-secsh-transport-13.txt Content-MD5: 6/yzFBJ/wSnXBg/UIeOAcg== Network Working Group T. Ylonen Internet-Draft T. Kivinen Expires: August 29, 2002 SSH Communications Security Corp M. Saarinen University of Jyvaskyla T. Rinne S. Lehtinen SSH Communications Security Corp February 28, 2002 SSH Transport Layer Protocol draft-ietf-secsh-transport-13.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong Ylonen, et. al. Expires August 29, 2002 [Page 1] Internet-Draft SSH Transport Layer Protocol February 2002 encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 3 3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 4 3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 4 3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 5 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 5 4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 6 4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 10 4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 10 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 13 5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 16 5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 17 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 17 6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 19 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 19 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 20 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 21 9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 21 9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 22 9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 22 9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 23 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 24 13. Additional Information . . . . . . . . . . . . . . . . . . . . 24 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27 Ylonen, et. al. Expires August 29, 2002 [Page 2] Internet-Draft SSH Transport Layer Protocol February 2002 1. Introduction The SSH transport layer is a secure low level transport protocol. It provides strong encryption, cryptographic host authentication, and integrity protection. Authentication in this protocol level is host-based; this protocol does not perform user authentication. A higher level protocol for user authentication can be designed on top of this protocol. The protocol has been designed to be simple, flexible, to allow parameter negotiation, and to minimize the number of round-trips. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. It is expected that in most environments, only 2 round-trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The worst case is 3 round-trips. 2. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119] The used data types and terminology are specified in the architecture document [SSH-ARCH] The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 3. Connection Setup SSH works over any 8-bit clean, binary-transparent transport. The underlying transport SHOULD protect against transmission errors as such errors cause the SSH connection to terminate. The client initiates the connection. 3.1 Use over TCP/IP When used over TCP/IP, the server normally listens for connections on port 22. This port number has been registered with the IANA, and has been officially assigned for SSH. 3.2 Protocol Version Exchange When the connection has been established, both sides MUST send an Ylonen, et. al. Expires August 29, 2002 [Page 3] Internet-Draft SSH Transport Layer Protocol February 2002 identification string of the form "SSH-protoversion-softwareversion comments", followed by carriage return and newline characters (ASCII 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. The part of the identification string preceding carriage return and newline is used in the Diffie-Hellman key exchange (see Section Section 6). The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting. Version strings MUST consist of printable US-ASCII characters, not including whitespaces or a minus sign (-). The version string is primarily used to trigger compatibility extensions and to indicate the capabilities of an implementation. The comment string should contain additional information that might be useful in solving user problems. The protocol version described in this document is 2.0. Key exchange will begin immediately after sending this identifier. All packets following the identification string SHALL use the binary packet protocol, to be described below. 3.3 Compatibility With Old SSH Versions During the transition period, it is important to be able to work in a way that is compatible with the installed SSH clients and servers that use an older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with SSH versions 1.x. 3.4 Old Client, New Server Server implementations MAY support a configurable "compatibility" flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its protocol version as "1.99". Clients using protocol 2.0 MUST be able to identify this as identical Ylonen, et. al. Expires August 29, 2002 [Page 4] Internet-Draft SSH Transport Layer Protocol February 2002 to "2.0". In this mode the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. In the compatibility mode the server SHOULD NOT send any further data after its initialization string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the version string. When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string. 3.5 New Client, Old Server Since the new client MAY immediately send additional data after its identification string (before receiving server's identification), the old protocol may already have been corrupted when the client learns that the server is old. When this happens, the client SHOULD close the connection to the server, and reconnect using the old protocol. 4. Binary Packet Protocol Each packet is in the following format: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length packet_length The length of the packet (bytes), not including MAC or the packet_length field itself. padding_length Length of padding (bytes). payload The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression MUST be "none". random padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. Ylonen, et. al. Expires August 29, 2002 [Page 5] Internet-Draft SSH Transport Layer Protocol February 2002 There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. mac Message authentication code. If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm MUST be "none". Note that length of the concatenation of packet length, padding length, payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field is also encrypted, and processing it requires special care when sending or receiving packets. The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus MAC); implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet. 4.1 Maximum Packet Length All implementations MUST be able to process packets with uncompressed payload length of 32768 bytes or less and total packet size of 35000 bytes or less (including length, padding length, payload, padding, and MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger than uncompressed size. Implementations SHOULD support longer packets, where they might be needed, e.g. if an implementation wants to send a very large number of certificates. Such packets MAY be sent if the version string indicates that the other party is able to process them. However, implementations SHOULD check that the packet length is reasonable for the implementation to avoid denial-of- service and/or buffer overflow attacks. 4.2 Compression If compression has been negotiated, the payload field (and only it) will be compressed using the negotiated algorithm. The length field and MAC will be computed from the compressed payload. Encryption will be done after compression. Compression MAY be stateful, depending on the method. Compression MUST be independent for each direction, and implementations MUST allow independently choosing the algorithm for each direction. The following compression methods are currently defined: Ylonen, et. al. Expires August 29, 2002 [Page 6] Internet-Draft SSH Transport Layer Protocol February 2002 none REQUIRED no compression zlib OPTIONAL ZLIB (LZ77) compression The "zlib" compression is described in [RFC1950] and in [RFC1951]. The compression context is initialized after each key exchange, and is passed from one packet to the next with only a partial flush being performed at the end of each packet. A partial flush means that the current compressed block is ended and all data will be output. If the current block is not a stored block, one or more empty blocks are added after the current block to ensure that there are at least 8 bits counting from the start of the end-of-block code of the current block to the end of the packet payload. Additional methods may be defined as specified in [SSH-ARCH]. 4.3 Encryption An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload and padding fields of each packet MUST be encrypted with the given algorithm. The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. All ciphers SHOULD use keys with an effective key length of 128 bits or more. The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). The following ciphers are currently defined: 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc RECOMMENDED Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc RECOMMENDED Twofish with 128-bit key aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key aes128-cbc RECOMMENDED AES with 128-bit key Ylonen, et. al. Expires August 29, 2002 [Page 7] Internet-Draft SSH Transport Layer Protocol February 2002 serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode none OPTIONAL no encryption; NOT RECOMMENDED The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [SCHNEIER] The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys [SCHNEIER]. This is a block cipher with 8 byte blocks. The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described [TWOFISH]. This is a block cipher with 16 byte blocks. The "twofish192-cbc" cipher. Same as above but with 192-bit key. The "twofish128-cbc" cipher. Same as above but with 128-bit key. The "aes256-cbc" cipher is AES (Advanced Encryption Standard), formerly Rijndael, in CBC mode. This version uses 256-bit key. The "aes192-cbc" cipher. Same as above but with 192-bit key. The "aes128-cbc" cipher. Same as above but with 128-bit key. The "serpent256-cbc" cipher in CBC mode, with 256-bit key as described in the Serpent AES submission. The "serpent192-cbc" cipher. Same as above but with 192-bit key. The "serpent128-cbc" cipher. Same as above but with 128-bit key. The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. Arcfour (and RC4) has problems with weak keys, and should be used with caution. Ylonen, et. al. Expires August 29, 2002 [Page 8] Internet-Draft SSH Transport Layer Protocol February 2002 The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. IDEA is patented by Ascom AG. The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC2144]. The "none" algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is not recommended. Some functionality (e.g. password authentication) may be disabled for security reasons if this cipher is chosen. Additional methods may be defined as specified in [SSH-ARCH]. 4.4 Data Integrity Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet. The message authentication algorithm and key are negotiated during key exchange. Initially, no MAC will be in effect, and its length MUST be zero. After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence number itself is not included in the packet sent over the wire. The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. The MAC bytes resulting from the MAC algorithm MUST be transmitted without encryption as the last part of the packet. The number of MAC bytes depends on the algorithm chosen. Ylonen, et. al. Expires August 29, 2002 [Page 9] Internet-Draft SSH Transport Layer Protocol February 2002 The following MAC algorithms are currently defined: hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length = 20) hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16) none OPTIONAL no MAC; NOT RECOMMENDED The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use only the first n bits of the resulting value. The hash algorithms are described in [SCHNEIER]. Additional methods may be defined as specified in [SSH-ARCH]. 4.5 Key Exchange Methods The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. Only one REQUIRED key exchange method has been defined: diffie-hellman-group1-sha1 REQUIRED This method is described later in this document. Additional methods may be defined as specified in [SSH-ARCH]. 4.6 Public Key Algorithms This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). There are several aspects that define a public key type: o Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. o Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. Ylonen, et. al. Expires August 29, 2002 [Page 10] Internet-Draft SSH Transport Layer Protocol February 2002 o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats. The following public key and/or certificate formats are currently defined: ssh-dss REQUIRED sign Simple DSS ssh-rsa RECOMMENDED sign Simple RSA x509v3-sign-rsa OPTIONAL sign X.509 certificates (RSA key) x509v3-sign-dss OPTIONAL sign X.509 certificates (DSS key) spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) Additional key types may be defined as specified in [SSH-ARCH]. The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. Public key / certifcate formats that do not explicitly specify a signature format identifier MUST use the public key / certificate format identifier as the signature identifier. Signatures are encoded as follows: string signature format identifier (as specified by the public key / cert format) byte[n] signature blob in format specific encoding. The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q mpint g mpint y Ylonen, et. al. Expires August 29, 2002 [Page 11] Internet-Draft SSH Transport Layer Protocol February 2002 Here the p, q, g, and y parameters form the signature key blob. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [SCHNEIER]. The resulting signature is encoded as follows: string "ssh-dss" string dss_signature_blob dss_signature_blob is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n Here the e and n parameters form the signature key blob. Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). The "spki-sign-rsa" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [RFC2693]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "spki-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. The "pgp-sign-rsa" method indicates the certificates, the public key, and the signature are in OpenPGP compatible binary format ([RFC2440]). This method indicates that the key is an RSA-key. The "pgp-sign-dss". As above, but indicates that the key is a DSS- Ylonen, et. al. Expires August 29, 2002 [Page 12] Internet-Draft SSH Transport Layer Protocol February 2002 key. 5. Key Exchange Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. Guess is considered wrong, if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 5.1). Otherwise, the guess is considered to be right and the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 5.1 Algorithm Negotiation Key exchange begins by each side sending the following packet: byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client Ylonen, et. al. Expires August 29, 2002 [Page 13] Internet-Draft SSH Transport Layer Protocol February 2002 boolean first_kex_packet_follows uint32 0 (reserved for future extension) Each of the algorithm strings MUST be a comma-separated list of algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]). Each supported (allowed) algorithm MUST be listed in order of preference. The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. cookie The cookie MUST be a random value generated by the sender. Its purpose is to make it impossible for either side to fully determine the keys and the session identifier. kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. server_host_key_algorithms List of the algorithms supported for the server host key. The server lists the algorithms for which it has host keys; the client lists the algorithms that it is willing to accept. (There MAY be multiple host keys for a host, possibly with different algorithms.) Some host keys may not support both signatures and encryption (this can be determined from the algorithm), and thus not all host keys are valid for all key exchange methods. Algorithm selection depends on whether the chosen key exchange Ylonen, et. al. Expires August 29, 2002 [Page 14] Internet-Draft SSH Transport Layer Protocol February 2002 algorithm requires a signature or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. encryption_algorithms Lists the acceptable symmetric encryption algorithms in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section Section 4.3. mac_algorithms Lists the acceptable MAC algorithms in order of preference. The chosen MAC algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The MAC algorithm names are listed in Section Figure 1. compression_algorithms Lists the acceptable compression algorithms in order of preference. The chosen compression algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The compression algorithm names are listed in Section Section 4.2. languages This is a comma-separated list of language tags in order of preference [RFC1766]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. first_kex_packet_follows Indicates whether a guessed key exchange packet follows. If a guessed packet will be sent, this MUST be TRUE. If no guessed packet will be sent, this MUST be FALSE. Ylonen, et. al. Expires August 29, 2002 [Page 15] After receiving the SSH_MSG_KEXINIT packet from the other side, each party will know whether their guess was right. If the other party's guess was wrong, and this field was TRUE, the next packet MUST be silently ignored, and both sides MUST then act as determined by the negotiated key exchange method. If the guess was right, key exchange MUST continue using the guessed packet. After the KEXINIT packet exchange, the key exchange algorithm is run. It may involve several packet exchanges, as specified by the key exchange method. 5.2 Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. Encryption keys MUST be computed as HASH of a known value and K as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) SHOULD be used for algorithms with variable-length keys. For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. If the key length in longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words: Ylonen, et. al. Expires August 29, 2002 [Page 16] Internet-Draft SSH Transport Layer Protocol February 2002 K1 = HASH(K || H || X || session_id) (X is e.g. "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH. 5.3 Taking Keys Into Use Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. When this message is received, the new keys and algorithms MUST be taken into use for receiving. This message is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The purpose of this message is to ensure that a party is able to respond with a disconnect message that the other party can understand if something goes wrong with the key exchange. Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. byte SSH_MSG_NEWKEYS 6. Diffie-Hellman Key Exchange The Diffie-Hellman key exchange provides a shared secret that can not be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. In the following description (C is the client, S is the server; p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; 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 S's KEXINIT message which have been exchanged before this part begins): 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. Ylonen, et. al. Expires August 29, 2002 [Page 17] 2. S generates a random number y (0 < y < q) 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 || 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. 3. C verifies that K_S really is the host key for S (e.g. using certificates or a local database). 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 || e || f || K), and verifies the signature s on H. 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. 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 the following: byte SSH_MSG_KEXDH_INIT mpint e The server responds with the following: byte SSH_MSG_KEXDH_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 mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret Ylonen, et. al. Expires August 29, 2002 [Page 18] Internet-Draft SSH Transport Layer Protocol February 2002 This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, "ssh-dss" specifies SHA-1 hashing; in that case, the data is first hashed with HASH to compute H, and H is then hashed with SHA-1 as part of the signing operation. 6.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and the following group: The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 129093 ). Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF. In decimal, this value is: 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194 467627007. The generator used with this prime is g = 2. The group order q is (p - 1) / 2. This group was taken from the ISAKMP/Oakley specification, and was originally generated by Richard Schroeppel at the University of Arizona. Properties of this prime are described in [Orm96]. 7. Key Re-Exchange Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when not already doing a key exchange (as described in Section Section 5.1). When this message is received, a party MUST respond with its own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT Ylonen, et. al. Expires August 29, 2002 [Page 19] Internet-Draft SSH Transport Layer Protocol February 2002 already was a reply. Either party MAY initiate the re-exchange, but roles MUST NOT be changed (i.e., the server remains the server, and the client remains the client). Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Re-exchange is processed identically to the initial key exchange, except for the session identifier that will remain unchanged. It is permissible to change some or all of the algorithms during the re-exchange. Host keys can also change. All keys and initialization vectors are recomputed after the exchange. Compression and encryption contexts are reset. It is recommended that the keys are changed after each gigabyte of transmitted data or after each hour of connection time, whichever comes sooner. However, since the re-exchange is a public key operation, it requires a fair amount of processing power and should not be performed too often. More application data may be sent after the SSH_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the SSH transport layer. 8. Service Request After the key exchange, the client requests a service. The service is identified by a name. The format of names and procedures for defining new names are defined in [SSH-ARCH]. Currently, the following names have been reserved: ssh-userauth ssh-connection Similar local naming policy is applied to the service names, as is applied to the algorithm names; a local service should use the "servicename@domain" syntax. byte SSH_MSG_SERVICE_REQUEST string service name If the server rejects the service request, it SHOULD send an Ylonen, et. al. Expires August 29, 2002 [Page 20] Internet-Draft SSH Transport Layer Protocol February 2002 appropriate SSH_MSG_DISCONNECT message and MUST disconnect. When the service starts, it may have access to the session identifier generated during the key exchange. If the server supports the service (and permits the client to use it), it MUST respond with the following: byte SSH_MSG_SERVICE_ACCEPT string service name Message numbers used by services should be in the area reserved for them (see Section 6 in [SSH-ARCH]). The transport level will continue to process its own messages. Note that after a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 9. Additional Messages Either party may send any of the following messages at any time. 9.1 Disconnection Message byte SSH_MSG_DISCONNECT uint32 reason code string description [RFC2279] string language tag [RFC1766] This message causes immediate termination of the connection. All implementations MUST be able to process this message; they SHOULD be able to send this message. The sender MUST NOT send or receive any data after this message, and the recipient MUST NOT accept any data after receiving this message. The description field gives a more specific explanation in a human- readable form. The error code gives the reason in a more machine- readable format (suitable for localization), and can have the following values: #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 #define SSH_DISCONNECT_RESERVED 4 Ylonen, et. al. Expires August 29, 2002 [Page 21] Internet-Draft SSH Transport Layer Protocol February 2002 #define SSH_DISCONNECT_MAC_ERROR 5 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 #define SSH_DISCONNECT_CONNECTION_LOST 10 #define SSH_DISCONNECT_BY_APPLICATION 11 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 If the description string is displayed, control character filtering discussed in [SSH-ARCH] should be used to avoid attacks by sending terminal control characters. 9.2 Ignored Data Message byte SSH_MSG_IGNORE string data All implementations MUST understand (and ignore) this message at any time (after receiving the protocol version). No implementation is required to send them. This message can be used as an additional protection measure against advanced traffic analysis techniques. 9.3 Debug Message byte SSH_MSG_DEBUG boolean always_display string message [RFC2279] string language tag [RFC1766] All implementations MUST understand this message, but they are allowed to ignore it. This message is used to pass the other side information that may help debugging. If always_display is TRUE, the message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless debugging information has been explicitly requested by the user. The message doesn't need to contain a newline. It is, however, allowed to consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. If the message string is displayed, terminal control character filtering discussed in [SSH-ARCH] should be used to avoid attacks by Ylonen, et. al. Expires August 29, 2002 [Page 22] Internet-Draft SSH Transport Layer Protocol February 2002 sending terminal control characters. 9.4 Reserved Messages An implementation MUST respond to all unrecognized messages with an SSH_MSG_UNIMPLEMENTED message in the order in which the messages were received. Such messages MUST be otherwise ignored. Later protocol versions may define other meanings for these message types. byte SSH_MSG_UNIMPLEMENTED uint32 packet sequence number of rejected message 10. Summary of Message Numbers The following message numbers have been defined in this protocol: #define SSH_MSG_DISCONNECT 1 #define SSH_MSG_IGNORE 2 #define SSH_MSG_UNIMPLEMENTED 3 #define SSH_MSG_DEBUG 4 #define SSH_MSG_SERVICE_REQUEST 5 #define SSH_MSG_SERVICE_ACCEPT 6 #define SSH_MSG_KEXINIT 20 #define SSH_MSG_NEWKEYS 21 /* Numbers 30-49 used for kex packets. Different kex methods may reuse message numbers in this range. */ #define SSH_MSG_KEXDH_INIT 30 #define SSH_MSG_KEXDH_REPLY 31 11. Security Considerations This protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. It is expected that this protocol will sometimes be used without insisting on reliable association between the server host key and the server host name. Such use is inherently insecure, but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, implementors of Ylonen, et. al. Expires August 29, 2002 [Page 23] Internet-Draft SSH Transport Layer Protocol February 2002 protocols running on top of this protocol should keep this possibility in mind. This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. 12. Trademark Issues As of this writing, SSH Communications Security Oy claims ssh as its trademark. As with all IPR claims the IETF takes no position regarding the validity or scope of this trademark claim. 13. Additional Information The current document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh-charter.html References [FIPS-186] Federal Information Processing Standards Publication, ., "FIPS PUB 186, Digital Signature Standard", May 1994. [Orm96] Orman, H., "The Okaley Key Determination Protcol version1, TR97-92", 1996. [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, Nov 1987. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. Ylonen, et. al. Expires August 29, 2002 [Page 24] Internet-Draft SSH Transport Layer Protocol February 2002 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", 1996. [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition", March 1999. [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft- ietf-architecture-12.txt, July 2001. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-13.txt, July 2001. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft- ietf-userauth-15.txt, July 2001. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-15.txt, July 2001. Ylonen, et. al. Expires August 29, 2002 [Page 25] Internet-Draft SSH Transport Layer Protocol February 2002 Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: kivinen@ssh.com Markku-Juhani O. Saarinen University of Jyvaskyla Timo J. Rinne SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: tri@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen, et. al. Expires August 29, 2002 [Page 26] Internet-Draft SSH Transport Layer Protocol February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen, et. al. Expires August 29, 2002 [Page 27] --Knot_of_Toads_857_000-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 15:26:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23908 for ; Fri, 1 Mar 2002 15:26:00 -0500 (EST) Received: (qmail 28837 invoked by uid 605); 1 Mar 2002 20:25:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28830 invoked from network); 1 Mar 2002 20:25:59 -0000 Received: from ce-nfs-1.cisco.com (171.68.227.69) by mail.netbsd.org with SMTP; 1 Mar 2002 20:25:59 -0000 Received: from REMAKERW2K (dhcp-171-69-103-69.cisco.com [171.69.103.69]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with SMTP id MAA02754 for ; Fri, 1 Mar 2002 12:25:58 -0800 (PST) Message-ID: <030101c1c15f$44e58170$456745ab@cisco.com> From: "Phillip Remaker" To: Subject: Extensions to SSH in order to facilitate telnet replacement. Date: Fri, 1 Mar 2002 12:25:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit In the process of trying to eliminate telnet from customer networks, I have encountered two hurdles, one major and one minor. A number of customers continue to use telnet and terminal servers to provide legacy RS-232 port access to devices such Sun servers, Cisco routers and modems. Telnet provides two useful functions through the IAC mechanism: 1) Presentation of an out of band BREAK signal (IAC 243) as in RFC854 [This is important] 2) Manipulation of RS-232 parameters (speed, parity, flowcontrol state) by IAC commands (RFC2217) [Less important] It seems like SSH would be well suited to handle these using the well designed negotiation mechanisms within the protocol, and I was wondering if anybody has already tackled this problem. If not, I welcome suggestions about the most elegant way to handle it within the spirit of the SSH protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 15:38:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24922 for ; Fri, 1 Mar 2002 15:38:40 -0500 (EST) Received: (qmail 3768 invoked by uid 605); 1 Mar 2002 20:38:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3761 invoked from network); 1 Mar 2002 20:38:40 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 1 Mar 2002 20:38:40 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23295 for ; Fri, 1 Mar 2002 13:38:39 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24639; Fri, 1 Mar 2002 15:38:37 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g21KbrUZ002919; Fri, 1 Mar 2002 15:37:53 -0500 (EST) Message-Id: <200203012037.g21KbrUZ002919@ack.east.sun.com> From: Bill Sommerfeld To: Darren Moffat cc: ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts In-Reply-To: Your message of "Thu, 28 Feb 2002 21:19:37 PST." <200203010521.g215L4sv445783@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Mar 2002 15:37:53 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > The updated transport and userauth drafts have been submitted and are in the > queue to come out by March 11th. Ouch. Because of the publication delay, and because we've been stuck in last call mode for a while, I'm going to attempt to accelerate things somewhat... A Working Group Last Call begins today and will end on 3/12/02 for the following four drafts: draft-ietf-secsh-architecture-12.txt draft-ietf-secsh-connect-15.txt draft-ietf-secsh-transport-13.txt (as mailed to ietf-secsh yesterday) draft-ietf-secsh-userauth-15.txt (as mailed to ietf-secsh yesterday) I believe that these documents likely the current consensus of the working group and should be submitted to the IESG for consideration for publication as Proposed Standards. Comments regarding the content of these documents should be sent to the working group mailing list, . If you believe a change to a document is necessary, please include revised wording along with your comment. This Last Call period extends until March 12th, 2002, or one day after the announcement of the latter two drafts, whichever comes later. (If the drafts which are eventually released differ in any substantial way from what Darren released, I will extend the last call). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 16:59:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02288 for ; Fri, 1 Mar 2002 16:59:55 -0500 (EST) Received: (qmail 21363 invoked by uid 605); 1 Mar 2002 21:59:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21354 invoked from network); 1 Mar 2002 21:59:52 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 1 Mar 2002 21:59:52 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id NAA18037; Fri, 1 Mar 2002 13:59:50 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id NAA20530; Fri, 1 Mar 2002 13:59:48 -0800 (PST) Date: Fri, 1 Mar 2002 13:59:47 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020301135946.C29118@eskimo.com> References: <200203010521.g215L4sv445783@jurassic.eng.sun.com> <200203012037.g21KbrUZ002919@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203012037.g21KbrUZ002919@ack.east.sun.com>; from sommerfeld@east.sun.com on Fri, Mar 01, 2002 at 03:37:53PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list It looks like the transport draft still does not deal with the attack I pointed out a few weeks ago. To fix this, I suggest that the following text be added to section 4.3: (begin quote) aes256-ctr OPTIONAL AES (Rijndael) in CTR mode, with 256-bit key aes192-ctr OPTIONAL AES with 192-bit key aes128-ctr RECOMMENDED AES with 128-bit key [and similarly for all other block ciphers] The "aes256-ctr" cipher is AES (Advanced Encryption Standard), formerly Rijndael, in CTR mode. This version uses 256-bit key. The "aes192-ctr" cipher. Same as above but with 192-bit key. The "aes128-ctr" cipher. Same as above but with 128-bit key. For any cipher in CTR mode, the counter used to encrypt each plaintext block MUST be the IV if no previous plaintext block exists, or C+1 mod 2^N where C is the counter used to encrypt the previous block, and N is the block size of the cipher in bits. Network order SHOULD be used to convert the counter between its octet string form and its integer form for the computation of C+1 mod 2^N. (end quote) And that the following text be added to the security discussions section: (begin quote) The protocol may be susceptible to chosen plaintext attacks if a CBC-mode cipher is used. It is RECOMMENDED that CBC-mode ciphers be avoided if the protocol is used in a way that allows an attacker to control part or all of the first N bits of the plaintext of each packet, where N is the cipher block size. (end quote) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 17:29:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03909 for ; Fri, 1 Mar 2002 17:29:00 -0500 (EST) Received: (qmail 26974 invoked by uid 605); 1 Mar 2002 22:28:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26967 invoked from network); 1 Mar 2002 22:28:58 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 1 Mar 2002 22:28:58 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21580; Fri, 1 Mar 2002 15:28:53 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17807; Fri, 1 Mar 2002 17:28:52 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g21MS8UZ004292; Fri, 1 Mar 2002 17:28:08 -0500 (EST) Message-Id: <200203012228.g21MS8UZ004292@ack.east.sun.com> From: Bill Sommerfeld To: Wei Dai cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts In-Reply-To: Your message of "Fri, 01 Mar 2002 13:59:47 PST." <20020301135946.C29118@eskimo.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Mar 2002 17:28:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I think it's too soon to make a document change because of this -- most importantly, I don't think that enough Real Cryptographers(tm) have looked at either the problem or the proposed fix to conclude that a change along the lines of your suggested fix is better than leaving the document alone. The use of ciphers in counter mode is also very new, and, as with all stream ciphers, there are some definite subtleties to their use; who's to say that crypto researchers won't find a problem with counter modes which are just as bad as the CBC problem (i.e., a purely theoretical vulnerability except in a few corner cases). new ciphers can follow later once there's clear consensus on a solution. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 19:06:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07345 for ; Fri, 1 Mar 2002 19:06:33 -0500 (EST) Received: (qmail 19071 invoked by uid 605); 2 Mar 2002 00:06:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19064 invoked from network); 2 Mar 2002 00:06:32 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 2 Mar 2002 00:06:32 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id QAA27872; Fri, 1 Mar 2002 16:06:30 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA29400; Fri, 1 Mar 2002 16:06:30 -0800 (PST) Date: Fri, 1 Mar 2002 16:06:30 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020301160629.K29118@eskimo.com> References: <20020301135946.C29118@eskimo.com> <200203012228.g21MS8UZ004292@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203012228.g21MS8UZ004292@ack.east.sun.com>; from sommerfeld@east.sun.com on Fri, Mar 01, 2002 at 05:28:08PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 01, 2002 at 05:28:08PM -0500, Bill Sommerfeld wrote: > I think it's too soon to make a document change because of this -- > most importantly, I don't think that enough Real Cryptographers(tm) > have looked at either the problem or the proposed fix to conclude that > a change along the lines of your suggested fix is better than leaving > the document alone. I agree, there needs to be more review of the problem and the proposed solution. Cryptography researchers may think the problem is too trivial and uninteresting to look on their own initiative, so I suggest that everyone who has a stake in this ask their favorite cryptographers to to take a look. > The use of ciphers in counter mode is also very new, and, as with all > stream ciphers, there are some definite subtleties to their use; who's > to say that crypto researchers won't find a problem with counter modes > which are just as bad as the CBC problem (i.e., a purely theoretical > vulnerability except in a few corner cases). I think the cryptographic research community now understand cipher modes and their security properties much better than they used to. The CBC mode problem has been known for quite a while in the research community (but apparently the knowledge has not been passed widely outside of it). CTR mode is perhaps the best understood mode because of its simplicity, and I believe it does not have any known problems when used in the way I suggest. I would say that a vulnerability is theoretical if there is no possibility that it can be exploited in the real world. That is clearly not the case here. > new ciphers can follow later once there's clear consensus on a > solution. I don't understand why we would want to standardize on a weak protocol. If there is no consensus on a solution, wouldn't it be better to wait until there is one? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 19:11:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07416 for ; Fri, 1 Mar 2002 19:11:14 -0500 (EST) Received: (qmail 21044 invoked by uid 605); 2 Mar 2002 00:11:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20957 invoked from network); 2 Mar 2002 00:11:10 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 2 Mar 2002 00:11:10 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id BAA21277; Sat, 2 Mar 2002 01:11:00 +0100 (MET) Date: Sat, 2 Mar 2002 01:11:00 +0100 From: Markus Friedl To: Wei Dai Cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020302001100.GA20447@faui02> References: <20020301135946.C29118@eskimo.com> <200203012228.g21MS8UZ004292@ack.east.sun.com> <20020301160629.K29118@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020301160629.K29118@eskimo.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 01, 2002 at 04:06:30PM -0800, Wei Dai wrote: > I don't understand why we would want to standardize on a weak protocol. If > there is no consensus on a solution, wouldn't it be better to wait until > there is one? then why use CTR and not OFB or CFB? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 19:13:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07480 for ; Fri, 1 Mar 2002 19:13:32 -0500 (EST) Received: (qmail 21506 invoked by uid 605); 2 Mar 2002 00:13:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21498 invoked from network); 2 Mar 2002 00:13:32 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 2 Mar 2002 00:13:32 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20840; Fri, 1 Mar 2002 16:13:30 -0800 (PST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02780; Fri, 1 Mar 2002 19:13:27 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g220ChUZ005328; Fri, 1 Mar 2002 19:12:43 -0500 (EST) Message-Id: <200203020012.g220ChUZ005328@ack.east.sun.com> From: Bill Sommerfeld To: Wei Dai cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts In-Reply-To: Your message of "Fri, 01 Mar 2002 16:06:30 PST." <20020301160629.K29118@eskimo.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 01 Mar 2002 19:12:43 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I don't understand why we would want to standardize on a weak protocol. If > there is no consensus on a solution, wouldn't it be better to wait until > there is one? ssh is (much) more than just the encryption; the encryption part is just one detail of the protocol, and it's a modularly replaceable part. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 19:31:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08038 for ; Fri, 1 Mar 2002 19:31:57 -0500 (EST) Received: (qmail 25150 invoked by uid 605); 2 Mar 2002 00:31:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25143 invoked from network); 2 Mar 2002 00:31:55 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 2 Mar 2002 00:31:55 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id QAA08601; Fri, 1 Mar 2002 16:31:54 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA01020; Fri, 1 Mar 2002 16:31:53 -0800 (PST) Date: Fri, 1 Mar 2002 16:31:53 -0800 From: Wei Dai To: Markus Friedl Cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020301163153.L29118@eskimo.com> References: <20020301135946.C29118@eskimo.com> <200203012228.g21MS8UZ004292@ack.east.sun.com> <20020301160629.K29118@eskimo.com> <20020302001100.GA20447@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020302001100.GA20447@faui02>; from markus@openbsd.org on Sat, Mar 02, 2002 at 01:11:00AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Mar 02, 2002 at 01:11:00AM +0100, Markus Friedl wrote: > then why use CTR and not OFB or CFB? http://saturn.tcs.hut.fi/~helger/papers/lrw00/html/ gives a good summary of the advantages of CTR. Here are the ones that apply to SSH: Software efficiency. Modern processors support some or all of the following architectural features: aggressive pipelining, multiple instruction dispatch per clock cycle, a large number of registers, and SIMD instructions. By eliminating the computational dependency between Ci and Cj, CTR-mode encryption enables effective utilization of the above features. For many ciphers, a well-optimized implementation of CTR-mode encryption on a processor such as an Pentium III, Itanium, Alpha, or a Motorola AltiVec, may be substantially faster (even more than four times [8]) than a well-optimized implementation of CBC-mode encryption. This is greater than the gain obtained from switching from the slowest to the fastest AES finalist on most platforms [7]. Hardware efficiency. Modes such as CBC encryption are limited in their hardware speed by the maximal rate at which the underlying block cipher can be computed. This is because one must complete the computation of ciphertext Ci before one can begin to compute Ci + 1. Thus the maximal throughput, in hardware, will be about the reciprocal of the latency for E. In contrast, CTR model is fully parallelizable: one can be computing blocks C1, C2,... all at the same time, limited only by the amount of hardware that one throws at the problem. This has been shown to result in 30...100 times speedups for four of the AES finalists [6]. Preprocessing. Because the cryptographic work in enciphering a message M is independent of M, preprocessing can be used, in some environments, to increase speed. That is, one can compute the pad in ``spare cycles,'' even before one knows the plaintext M. When M is known, it is XORed with the already-computed pad. The latter can be done with throughput 10-25 Gbit/s on a contemporary processor. Provable security. The above efficiency characteristics are not obtained at the expense of security. In fact, the ``standard'' cryptographic assumption about a block cipher's security--that it is a ``pseudorandom permutation'' [9,4]--is enough to prove the security of CTR-mode encryption. See [2], which shows that the concrete security bounds one gets for CTR-mode encryption, using a block cipher, are no worse than what one gets for CBC encryption. (Indeed there are approaches to get better security bounds with CTR-mode encryption than with CBC mode, though these do not directly use the block cipher E). See [4,3].) The security of CTR mode is well-analyzed and well-understood. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 19:58:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08601 for ; Fri, 1 Mar 2002 19:58:56 -0500 (EST) Received: (qmail 27806 invoked by uid 605); 2 Mar 2002 00:58:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27799 invoked from network); 2 Mar 2002 00:58:53 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 2 Mar 2002 00:58:53 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id QAA22165; Fri, 1 Mar 2002 16:58:52 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id QAA02480; Fri, 1 Mar 2002 16:58:52 -0800 (PST) Date: Fri, 1 Mar 2002 16:58:51 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020301165851.M29118@eskimo.com> References: <20020301160629.K29118@eskimo.com> <200203020012.g220ChUZ005328@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203020012.g220ChUZ005328@ack.east.sun.com>; from sommerfeld@east.sun.com on Fri, Mar 01, 2002 at 07:12:43PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 01, 2002 at 07:12:43PM -0500, Bill Sommerfeld wrote: > ssh is (much) more than just the encryption; the encryption part is > just one detail of the protocol, and it's a modularly replaceable > part. I think the encryption is much more than a detail. It's one of the two most important services that ssh provides (the other one being the authentication). Sure ssh also does shells and file transfers and so on, but everyone would still be using rcp and rsh if it weren't for the encryption and authentication that ssh provides. Even if we decide not to put in the proposed fix, we need to at least mention the attack in the security considerations section. I don't see how it could be completely ignored. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 20:07:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08777 for ; Fri, 1 Mar 2002 20:07:01 -0500 (EST) Received: (qmail 28684 invoked by uid 605); 2 Mar 2002 01:07:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28674 invoked from network); 2 Mar 2002 01:07:00 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 2 Mar 2002 01:07:00 -0000 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id C0DC767107; Fri, 1 Mar 2002 20:26:39 -0500 (EST) Date: Fri, 1 Mar 2002 20:06:30 -0500 Subject: Re: updated transport & userauth drafts Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-ssh@netbsd.org To: Wei Dai From: RJ Atkinson In-Reply-To: <20020301160629.K29118@eskimo.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, March 1, 2002, at 07:06 , Wei Dai wrote: > I don't understand why we would want to standardize > on a weak protocol. If there is no consensus on a solution, > wouldn't it be better to wait until there is one? There is clear consensus that SSHv2 in its current form requires a lot more work for an adversary than the other available alternatives. The goal here is practical risk reduction, not perfect security. So we take what is practical to get today (i.e. the current spec) and we can always update it with additional new algorithsm later (if those algorithms still look interesting after adequate Real Cryptographer(tm) peer review). Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 1 20:07:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08804 for ; Fri, 1 Mar 2002 20:07:58 -0500 (EST) Received: (qmail 29141 invoked by uid 605); 2 Mar 2002 01:07:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29134 invoked from network); 2 Mar 2002 01:07:58 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 2 Mar 2002 01:07:58 -0000 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 634F267107; Fri, 1 Mar 2002 20:28:06 -0500 (EST) Date: Fri, 1 Mar 2002 20:07:57 -0500 Subject: Re: updated transport & userauth drafts Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-ssh@netbsd.org To: Wei Dai From: RJ Atkinson In-Reply-To: <20020301163153.L29118@eskimo.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, March 1, 2002, at 07:31 , Wei Dai wrote: > The security of CTR mode is well-analyzed and well-understood. The Real Cryptographers (tm) that I talk with would strongly dispute that assertion, though (fortunately) they have better diplomatic skills than I do. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 04:07:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26365 for ; Sat, 2 Mar 2002 04:07:52 -0500 (EST) Received: (qmail 22460 invoked by uid 605); 2 Mar 2002 09:07:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22453 invoked from network); 2 Mar 2002 09:07:49 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 2 Mar 2002 09:07:49 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16h5UL-0006lG-00; Sat, 02 Mar 2002 09:07:33 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <030101c1c15f$44e58170$456745ab@cisco.com> Subject: Re: Extensions to SSH in order to facilitate telnet replacement. Message-Id: Date: Sat, 02 Mar 2002 09:07:33 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Phillip Remaker wrote: > 1) Presentation of an out of band BREAK signal (IAC 243) as in RFC854 [This > is important] > 2) Manipulation of RS-232 parameters (speed, parity, flowcontrol state) by > IAC commands (RFC2217) [Less important] > > It seems like SSH would be well suited to handle these using the well > designed negotiation mechanisms within the protocol, and I was wondering if > anybody has already tackled this problem. If not, I welcome suggestions > about the most elegant way to handle it within the spirit of the SSH > protocol. SSH_MSG_CHANNEL_REQUEST seems like an ideal mechanism for these. Just define a channel request type ("send-break@mydomain.com" or similar), and enhance your SSH2 server to accept it on a shell-session channel and do the right thing. Then all you need to do is convince client implementors to add support for it. Note that you don't need to affect the standardisation process to do this at all - you could propose your extension as an RFC so you'd have something to refer people to, but that needn't be a prerequisite for getting it implemented. Cheers, Simon -- Simon Tatham "The difference between theory and practice is that, in theory, there is no difference." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 13:01:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02959 for ; Sat, 2 Mar 2002 13:01:21 -0500 (EST) Received: (qmail 28494 invoked by uid 605); 2 Mar 2002 18:01:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28487 invoked from network); 2 Mar 2002 18:01:17 -0000 Received: from mx01.nexgo.de (151.189.8.96) by mail.netbsd.org with SMTP; 2 Mar 2002 18:01:17 -0000 Received: from localhost (dsl-213-023-060-029.arcor-ip.net [213.23.60.29]) by mx01.nexgo.de (Postfix) with ESMTP id 53A473BCBE; Sat, 2 Mar 2002 19:01:15 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 8BA42441D; Sat, 2 Mar 2002 19:01:05 +0100 (CET) Date: Sat, 2 Mar 2002 19:01:04 +0100 From: Markus Friedl To: Wei Dai Cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020302190104.A1944@folly> References: <20020301160629.K29118@eskimo.com> <200203020012.g220ChUZ005328@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200203020012.g220ChUZ005328@ack.east.sun.com>; from sommerfeld@east.sun.com on Fri, Mar 01, 2002 at 07:12:43PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 01, 2002 at 07:12:43PM -0500, Bill Sommerfeld wrote: > > I don't understand why we would want to standardize on a weak protocol. If > > there is no consensus on a solution, wouldn't it be better to wait until > > there is one? > > ssh is (much) more than just the encryption; the encryption part is > just one detail of the protocol, and it's a modularly replaceable > part. I agree with Bill: The protocol is much more than CBC-encryption, and it's so easy to switch ciphers. The group really should move on. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 13:11:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03012 for ; Sat, 2 Mar 2002 13:11:20 -0500 (EST) Received: (qmail 29460 invoked by uid 605); 2 Mar 2002 18:11:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29453 invoked from network); 2 Mar 2002 18:11:17 -0000 Received: from p72-186.acedsl.com (HELO tp.databus.com) (66.114.72.186) by mail.netbsd.org with SMTP; 2 Mar 2002 18:11:17 -0000 Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g22IBFk27310 for ietf-ssh@netbsd.org; Sat, 2 Mar 2002 13:11:15 -0500 (EST) (envelope-from barney) Date: Sat, 2 Mar 2002 13:11:15 -0500 From: Barney Wolff To: ietf-ssh@netbsd.org Subject: Re: Extensions to SSH in order to facilitate telnet replacement. Message-ID: <20020302131115.A27254@tp.databus.com> References: <030101c1c15f$44e58170$456745ab@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anakin@pobox.com on Sat, Mar 02, 2002 at 09:07:33AM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Is there a reason, aside from elegance, that simply forwarding to localhost (or lo0) port 23 over ssh is unacceptable? It has the great advantage that no client enhancement is required. On Sat, Mar 02, 2002 at 09:07:33AM +0000, Simon Tatham wrote: > Phillip Remaker wrote: > > 1) Presentation of an out of band BREAK signal (IAC 243) as in RFC854 [This > > is important] > > 2) Manipulation of RS-232 parameters (speed, parity, flowcontrol state) by > > IAC commands (RFC2217) [Less important] > > > > It seems like SSH would be well suited to handle these using the well > > designed negotiation mechanisms within the protocol, and I was wondering if > > anybody has already tackled this problem. If not, I welcome suggestions > > about the most elegant way to handle it within the spirit of the SSH > > protocol. > > SSH_MSG_CHANNEL_REQUEST seems like an ideal mechanism for these. > Just define a channel request type ("send-break@mydomain.com" or > similar), and enhance your SSH2 server to accept it on a > shell-session channel and do the right thing. Then all you need to > do is convince client implementors to add support for it. Note that > you don't need to affect the standardisation process to do this at > all - you could propose your extension as an RFC so you'd have > something to refer people to, but that needn't be a prerequisite for > getting it implemented. -- Barney Wolff "Nonetheless, ease and peace had left this people still curiously tough. They were, if it came to it, difficult to daunt or to kill; and they were, perhaps, so unwearyingly fond of good things not least because they could, when put to it, do without them, and could survive rough handling by grief, foe, or weather in a way that astonished those who did not know them well and looked no further than their bellies and their well-fed faces." J.R.R.T. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 14:51:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03989 for ; Sat, 2 Mar 2002 14:51:21 -0500 (EST) Received: (qmail 10244 invoked by uid 605); 2 Mar 2002 19:51:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10237 invoked from network); 2 Mar 2002 19:51:18 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 2 Mar 2002 19:51:18 -0000 Received: from [192.168.0.3] (HELO ENTROPY) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 501688; Sat, 02 Mar 2002 12:58:42 -0700 Message-ID: <003401c1c223$913ccf50$02318082@vandyke.connectathon.org> From: "Joseph Galbraith" To: "Markus Friedl" , "Wei Dai" Cc: "Bill Sommerfeld" , "Darren Moffat" , References: <20020301160629.K29118@eskimo.com> <200203020012.g220ChUZ005328@ack.east.sun.com> <20020302190104.A1944@folly> Subject: Re: updated transport & userauth drafts Date: Sat, 2 Mar 2002 11:50:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I agree with Bill: The protocol is much more than CBC-encryption, > and it's so easy to switch ciphers. The group really should move > on. I too agree. Ciphers are easy to add. The core drafts clearly define how to specify additional ciphers independantly, for exactly this purpose. In fact, I would say that if people feel strongly, it would not be too early to start a document describing the proposed new ciphers. Such a document would naturally proceed independantly from the core drafts. But, in the event that all the Real Cryptographers (TM) all of a sudden said "Oh my gosh! This is horrible! Don't use CBC for anything!" we would have something we'd actually been working on, and ironing out the wording, clarity, etc. And, indeed, it wouldn't be a bad idea to have some ciphers specified that didn't use CBC, even without this specific attack, on the principle that we don't want all our eggs in one basket. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 14:58:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04084 for ; Sat, 2 Mar 2002 14:58:33 -0500 (EST) Received: (qmail 11319 invoked by uid 605); 2 Mar 2002 19:58:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11308 invoked from network); 2 Mar 2002 19:58:31 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 2 Mar 2002 19:58:31 -0000 Received: from [192.168.0.3] (HELO ENTROPY) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 501696; Sat, 02 Mar 2002 13:05:55 -0700 Message-ID: <003e01c1c224$93352770$02318082@vandyke.connectathon.org> From: "Joseph Galbraith" To: "Barney Wolff" , References: <030101c1c15f$44e58170$456745ab@cisco.com> <20020302131115.A27254@tp.databus.com> Subject: Re: Extensions to SSH in order to facilitate telnet replacement. Date: Sat, 2 Mar 2002 11:58:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Well, it requires running a complicated server (telnetd) with all it's additional bugs and security vulnerabilities on your server, and requires the client to have another complicated (maybe expensive?) piece of code on his/her system. Or, imagine either your server or client are dedicated devices -- now a telnet server seems even less attractive. - Joseph > Is there a reason, aside from elegance, that simply forwarding to > localhost (or lo0) port 23 over ssh is unacceptable? It has the > great advantage that no client enhancement is required. > > On Sat, Mar 02, 2002 at 09:07:33AM +0000, Simon Tatham wrote: > > Phillip Remaker wrote: > > > 1) Presentation of an out of band BREAK signal (IAC 243) as in RFC854 [This > > > is important] > > > 2) Manipulation of RS-232 parameters (speed, parity, flowcontrol state) by > > > IAC commands (RFC2217) [Less important] > > > > > > It seems like SSH would be well suited to handle these using the well > > > designed negotiation mechanisms within the protocol, and I was wondering if > > > anybody has already tackled this problem. If not, I welcome suggestions > > > about the most elegant way to handle it within the spirit of the SSH > > > protocol. > > > > SSH_MSG_CHANNEL_REQUEST seems like an ideal mechanism for these. > > Just define a channel request type ("send-break@mydomain.com" or > > similar), and enhance your SSH2 server to accept it on a > > shell-session channel and do the right thing. Then all you need to > > do is convince client implementors to add support for it. Note that > > you don't need to affect the standardisation process to do this at > > all - you could propose your extension as an RFC so you'd have > > something to refer people to, but that needn't be a prerequisite for > > getting it implemented. > > -- > Barney Wolff > > "Nonetheless, ease and peace had left this people still curiously > tough. They were, if it came to it, difficult to daunt or to kill; > and they were, perhaps, so unwearyingly fond of good things not > least because they could, when put to it, do without them, and could > survive rough handling by grief, foe, or weather in a way that > astonished those who did not know them well and looked no further > than their bellies and their well-fed faces." J.R.R.T. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 2 15:10:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04240 for ; Sat, 2 Mar 2002 15:10:05 -0500 (EST) Received: (qmail 12165 invoked by uid 605); 2 Mar 2002 20:10:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12140 invoked from network); 2 Mar 2002 20:09:59 -0000 Received: from p72-186.acedsl.com (HELO tp.databus.com) (66.114.72.186) by mail.netbsd.org with SMTP; 2 Mar 2002 20:09:59 -0000 Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g22K9vi28685 for ietf-ssh@netbsd.org; Sat, 2 Mar 2002 15:09:57 -0500 (EST) (envelope-from barney) Date: Sat, 2 Mar 2002 15:09:57 -0500 From: Barney Wolff To: ietf-ssh@netbsd.org Subject: Re: Extensions to SSH in order to facilitate telnet replacement. Message-ID: <20020302150957.A28656@tp.databus.com> References: <030101c1c15f$44e58170$456745ab@cisco.com> <20020302131115.A27254@tp.databus.com> <003e01c1c224$93352770$02318082@vandyke.connectathon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003e01c1c224$93352770$02318082@vandyke.connectathon.org>; from galb-list@vandyke.com on Sat, Mar 02, 2002 at 11:58:07AM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list As opposed to building the telnet complexities into sshd? And of course every device for which this functionality would be desired already has the telnet server built in. Ditto telnet client, for ssh clients. Maybe I misunderstood the request, but it seemed clear to me that the only motivation was to talk to things that expected to be talking via telnet. Barney On Sat, Mar 02, 2002 at 11:58:07AM -0800, Joseph Galbraith wrote: > Well, it requires running a complicated > server (telnetd) with all it's additional > bugs and security vulnerabilities on your > server, and requires the client to have > another complicated (maybe expensive?) > piece of code on his/her system. > > Or, imagine either your server or > client are dedicated devices -- now > a telnet server seems even less > attractive. > > - Joseph > > > Is there a reason, aside from elegance, that simply forwarding to > > localhost (or lo0) port 23 over ssh is unacceptable? It has the > > great advantage that no client enhancement is required. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 3 02:08:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16786 for ; Sun, 3 Mar 2002 02:08:07 -0500 (EST) Received: (qmail 7437 invoked by uid 605); 3 Mar 2002 07:08:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7426 invoked from network); 3 Mar 2002 07:07:59 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 3 Mar 2002 07:07:59 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 493DD3BD08; Sun, 3 Mar 2002 08:07:57 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 902806C007; Sun, 3 Mar 2002 08:07:58 +0100 (MET) Date: Sun, 3 Mar 2002 08:06:26 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Bill Sommerfeld Cc: Darren Moffat , Subject: Re: updated transport & userauth drafts In-Reply-To: <200203012037.g21KbrUZ002919@ack.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 1 Mar 2002, Bill Sommerfeld wrote: > draft-ietf-secsh-transport-13.txt (as mailed to ietf-secsh yesterday) As I (and others) have noted in previous mails: In: 4.6 Public Key Algorithms ... The certificate part may have be a zero length string, but a public key is required. ... Delete this sentence, it doesn't carry any information IMHO, it's only confusing things which are otherwise mostly clear. Same paragraph: ... This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. ... Suggested rephrase: ... This is the public key that will be used for authentication. Whether it is a plain public key or certificate (or certificate chain) is implicit from the format used. A certificate chain is the binary concatenation (i.e. of byte[n] blobs) of certificates necessary for authentication as defined by the format used. ... (note: if we don't explicitly define a certificate chain here we don't know what it is, or we'll have to drag in PKCS7 or some other means of transport/definition of one, rfc2459 doesn't define this AFAIK). In the references part, [PKCS1] is missing, suggested addition: ... [PKCS1] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 1.5, November 1993. ... IMHO these changes will add/delete as much information as is needed to unambigously (hopefully...) implement this. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 5 06:32:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24373 for ; Tue, 5 Mar 2002 06:32:30 -0500 (EST) Received: (qmail 14401 invoked by uid 605); 5 Mar 2002 11:32:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14392 invoked from network); 5 Mar 2002 11:32:24 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 Mar 2002 11:32:24 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24321; Tue, 5 Mar 2002 06:32:22 -0500 (EST) Message-Id: <200203051132.GAA24321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-13.txt Date: Tue, 05 Mar 2002 06:32:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-13.txt Pages : 27 Date : 04-Mar-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-13.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141822.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 5 06:32:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24422 for ; Tue, 5 Mar 2002 06:32:44 -0500 (EST) Received: (qmail 14677 invoked by uid 605); 5 Mar 2002 11:32:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14660 invoked from network); 5 Mar 2002 11:32:34 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 Mar 2002 11:32:34 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24309; Tue, 5 Mar 2002 06:32:17 -0500 (EST) Message-Id: <200203051132.GAA24309@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-15.txt Date: Tue, 05 Mar 2002 06:32:17 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-15.txt Pages : 15 Date : 04-Mar-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host- based client authentication methods. Additional authentication methods are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-15.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304141811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141811.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 5 17:18:29 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02870 for ; Tue, 5 Mar 2002 17:18:28 -0500 (EST) Received: (qmail 12206 invoked by uid 605); 5 Mar 2002 22:18:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12198 invoked from network); 5 Mar 2002 22:18:24 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 5 Mar 2002 22:18:24 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06767; Tue, 5 Mar 2002 15:18:21 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02659; Tue, 5 Mar 2002 17:18:19 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g25MHQUZ012320; Tue, 5 Mar 2002 17:17:26 -0500 (EST) Message-Id: <200203052217.g25MHQUZ012320@ack.east.sun.com> From: Bill Sommerfeld To: "Andersson, Mats" cc: Bill Sommerfeld , Darren Moffat , ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts In-Reply-To: Your message of "Sun, 03 Mar 2002 08:06:26 +0100." Reply-to: sommerfeld@east.sun.com Date: Tue, 05 Mar 2002 17:17:26 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > IMHO these changes will add/delete as much information as is needed to > unambigously (hopefully...) implement this. So, I don't think it's necessary to make these changes at this time. The WG has opted to split out integration of certificates with ssh into a separate document. When it's ready, that draft can clarify the description of certificate handling. If anyone disagrees *strongly* with this, speak now and explain why we need more delay before advancing the core drafts to IETF-wide last call. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 6 15:36:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04068 for ; Wed, 6 Mar 2002 15:36:18 -0500 (EST) Received: (qmail 16205 invoked by uid 605); 6 Mar 2002 20:36:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16196 invoked from network); 6 Mar 2002 20:36:16 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 6 Mar 2002 20:36:16 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26975 for ; Wed, 6 Mar 2002 13:36:15 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22641 for ; Wed, 6 Mar 2002 15:36:14 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g26KZLUZ013552 for ; Wed, 6 Mar 2002 15:35:21 -0500 (EST) Message-Id: <200203062035.g26KZLUZ013552@ack.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Core draft last call update. Date: Wed, 06 Mar 2002 15:35:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list The two drafts we were waiting for have emerged from the queue (and, at least for me, were identical to the files Darren mailed to this list); I'm accordingly revising the last call notice: A Working Group Last Call began on 1 March 2002 and will end on 12 March 2002 for the following four drafts: draft-ietf-secsh-architecture-12.txt draft-ietf-secsh-connect-15.txt draft-ietf-secsh-transport-13.txt draft-ietf-secsh-userauth-15.txt I believe that these documents likely the current consensus of the working group and should be submitted to the IESG for consideration for publication as Proposed Standards. Comments regarding the content of these documents should be sent to the working group mailing list, . If you believe a change to a document is necessary, please include revised wording along with your comment. This Last Call period extends until 12 March 2002. Issues raised so far: - Wei Dai: plaintext-guess-verification attack possible against CBC based symmetric encryption modes. Proposed resolution: WG does not see this as a serious issue but will pursue other encryption modes; no document change necessary at this stage. - XXX: existing text regarding certificates needs still more wordsmithing. Proposed resolution: during the previous last call, the WG concluded that certificate handling should be be described in a separate document. When that document exists, it can supply any necessary clarifications; there's correspondingly no need to respin the core drafts at this time. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 6 15:59:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05298 for ; Wed, 6 Mar 2002 15:59:46 -0500 (EST) Received: (qmail 29205 invoked by uid 605); 6 Mar 2002 20:59:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29198 invoked from network); 6 Mar 2002 20:59:45 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 6 Mar 2002 20:59:45 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g26KulK19641 for ietf-ssh@netbsd.org; Wed, 6 Mar 2002 12:56:47 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Core draft last call update. Date: 6 Mar 2002 20:56:47 GMT Organization: University of California, Berkeley Lines: 37 Distribution: isaac Message-ID: References: <200203062035.g26KZLUZ013552@ack.east.sun.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1015448207 19418 128.32.45.153 (6 Mar 2002 20:56:47 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 6 Mar 2002 20:56:47 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Bill Sommerfeld wrote: > - Wei Dai: plaintext-guess-verification attack possible against CBC >based symmetric encryption modes. > >Proposed resolution: WG does not see this as a serious issue but will pursue >other encryption modes; no document change necessary at this stage. Hmm. I'm a little concerned about this. Here's my reaction. I looked at the packet format and it looks like there may be the opportunity to exploit this against sessions that contain at least 2^16 packets and that multiplex data from multiple sources (surprisingly common). That's not a devastating attack, but it's probably not such a good property, either. 3DES, AES, and Blowfish are supposed to be very conservative ciphers. The above flaw partially undermines this strength. If there were some attack on our block cipher requiring only 2^16 known or chosen plaintexts, we'd run screaming; are there reasons to hold our modes of operation to a lower standard? For comparison, attacks of comparable impact have led to changes in the IPSec packet format (Bellovin's cut-and-paste attacks) and might lead to changes to TLS (heavy discussions ongoing in TLS WG right now). I don't see it as an urgent "fix this today!" bug, but standards move slowly and it may make sense to get started on fixing the specification. (It's not going to get any easier with time.) Looking at this from a design perspective, the fix seems to be straightforward. AES-CTR would do fine. AES-CBC with unpredictable IV's would also be ok, so long as all implementations enforce the constraint that they won't start emitting ciphertext until they've consumed all the plaintext for this message, but I bet many implementations do not enforce this condition -- for this reason, I suggest AES-CTR. How much work would it take to fix this weakness? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 6 16:14:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06345 for ; Wed, 6 Mar 2002 16:14:34 -0500 (EST) Received: (qmail 6830 invoked by uid 605); 6 Mar 2002 21:14:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6823 invoked from network); 6 Mar 2002 21:14:33 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 6 Mar 2002 21:14:33 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06437; Wed, 6 Mar 2002 14:14:32 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05866; Wed, 6 Mar 2002 16:14:32 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g26LDcUZ013706; Wed, 6 Mar 2002 16:13:38 -0500 (EST) Message-Id: <200203062113.g26LDcUZ013706@ack.east.sun.com> From: Bill Sommerfeld To: daw@mozart.cs.berkeley.edu (David Wagner) cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Your message of "06 Mar 2002 20:56:47 GMT." Reply-to: sommerfeld@east.sun.com Date: Wed, 06 Mar 2002 16:13:38 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list David, Note that I'm not saying we don't have to fix the problem. SSH is a modular protocol, and this very CBC flaw is also present in SSL/TLS. Documents specifying additional fixed modes can be advanced quickly once we have consensus, but need not delay the core documents. We SHOULD NOT DELAY THE REST OF SSH while we discuss a solution, particularly since there appears to be some resistance to counter modes from the membership. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 10:33:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10209 for ; Fri, 8 Mar 2002 10:33:05 -0500 (EST) Received: (qmail 21360 invoked by uid 605); 8 Mar 2002 15:33:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21353 invoked from network); 8 Mar 2002 15:33:01 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 8 Mar 2002 15:33:01 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 10:33:50 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: Specifying file names in SSH File Transfer Protocol Date: Fri, 8 Mar 2002 10:33:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list http://www2.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-02.txt states that filenames use Unix syntax. This would be fine if all the computers in the world were Unix, but they are not. FTP (RFC 959) recognize that file specification syntax varied by ignoring it. I recognize that the SSH File Transfer Protocol wants to have a defined method of specifying a file so that it can do things like implement a recursive copy of a directory tree. While it is possible to use translation routines to translate between the local system's naming structure and the Unix style, the variety of implementations that already exist do not always use the same string for the same user input. This makes it harder to get the translator to work correctly all of the time. I would like to propose a more flexible method of specifying a file, that I believe will not have these problems. A file name is composed of a sequence of strings. The first string specifies the file system. The last string specifies the file name. The intermediate strings specify each element of the directory path. This will allow each system to compose the appropriate syntax by concatenating the strings with the appropriate separators. A change will also be needed to be made to each of the commands that take a file specification to note which style of file specification is to be used. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 11:45:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15226 for ; Fri, 8 Mar 2002 11:45:23 -0500 (EST) Received: (qmail 28662 invoked by uid 605); 8 Mar 2002 16:44:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28569 invoked from network); 8 Mar 2002 16:44:51 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 8 Mar 2002 16:44:51 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16jNTu-0000xL-00; Fri, 08 Mar 2002 16:44:34 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> Subject: Re: Specifying file names in SSH File Transfer Protocol Message-Id: Date: Fri, 08 Mar 2002 16:44:34 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Richard Whalen wrote: > A file name is composed of a sequence of strings. The first string > specifies the file system. The last string specifies the file name. The > intermediate strings specify each element of the directory path. This will > allow each system to compose the appropriate syntax by concatenating the > strings with the appropriate separators. It isn't entirely clear what you mean by `each system'. Do you mean that the _client_ will use its own local convention for concatenating the file name components (so that running sftp on Unix will make every remote system look like a Unix, and likewise on Windows, VMS or whatever)? Or do you mean that the server will do the concatenation (sending over a concatenated file name as well as the separated components)? Or that the server will specify how the client should do the concatenation, or what? -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 11:51:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15660 for ; Fri, 8 Mar 2002 11:51:02 -0500 (EST) Received: (qmail 3126 invoked by uid 605); 8 Mar 2002 16:51:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3116 invoked from network); 8 Mar 2002 16:50:59 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 8 Mar 2002 16:50:59 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:51:54 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA151@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Specifying file names in SSH File Transfer Protocol Date: Fri, 8 Mar 2002 11:51:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I meant each server will do the concatenation, as the server has to do the job of accessing the file. Of course the clients can also concatenate, to give the user some information about the name of the file being accessed. -----Original Message----- From: Simon Tatham [mailto:anakin@pobox.com] Sent: Friday, March 08, 2002 11:45 AM To: ietf-ssh@netbsd.org Subject: Re: Specifying file names in SSH File Transfer Protocol Richard Whalen wrote: > A file name is composed of a sequence of strings. The first string > specifies the file system. The last string specifies the file name. The > intermediate strings specify each element of the directory path. This will > allow each system to compose the appropriate syntax by concatenating the > strings with the appropriate separators. It isn't entirely clear what you mean by `each system'. Do you mean that the _client_ will use its own local convention for concatenating the file name components (so that running sftp on Unix will make every remote system look like a Unix, and likewise on Windows, VMS or whatever)? Or do you mean that the server will do the concatenation (sending over a concatenated file name as well as the separated components)? Or that the server will specify how the client should do the concatenation, or what? -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 11:59:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16544 for ; Fri, 8 Mar 2002 11:59:10 -0500 (EST) Received: (qmail 6644 invoked by uid 605); 8 Mar 2002 16:59:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6632 invoked from network); 8 Mar 2002 16:59:09 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 8 Mar 2002 16:59:09 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA22048 for ietf-ssh@netbsd.org; Fri, 8 Mar 2002 16:56:24 GMT Date: Fri, 8 Mar 2002 16:56:24 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Specifying file names in SSH File Transfer Protocol Message-ID: <20020308165624.A21606@edinburgh.cisco.com> References: <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from anakin@pobox.com on Fri, Mar 08, 2002 at 04:44:34PM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 04:44:34PM +0000, Simon Tatham wrote: > Richard Whalen wrote: > > A file name is composed of a sequence of strings. The first string > > specifies the file system. The last string specifies the file name. The > > intermediate strings specify each element of the directory path. This will > > allow each system to compose the appropriate syntax by concatenating the > > strings with the appropriate separators. > > It isn't entirely clear what you mean by `each system'. I took him as meaning the client will take the effort to translate pathnames it sends into this format. So that where it currently sends 'string pathname', that string will itself be composed of a set of strings. Therefore we have a common over the wire format for pathnames which all clients have to translate into, and all server translate from. (As I recall pathnames aren't sent from server to client, just filenames) DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:01:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16700 for ; Fri, 8 Mar 2002 12:01:19 -0500 (EST) Received: (qmail 7926 invoked by uid 605); 8 Mar 2002 17:01:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7919 invoked from network); 8 Mar 2002 17:01:14 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 8 Mar 2002 17:01:14 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KF445J5NR696VLVM@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 08 Mar 2002 10:01:05 -0700 (MST) Date: Fri, 08 Mar 2002 10:01:02 -0700 From: "Dan O'Reilly" Subject: Re: Specifying file names in SSH File Transfer Protocol In-reply-to: <20020308165624.A21606@edinburgh.cisco.com> X-Sender: oreilly@raptor.psccos.com To: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from anakin"@pobox.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 09:56 AM 3/8/2002, Derek Fawcus wrote: >On Fri, Mar 08, 2002 at 04:44:34PM +0000, Simon Tatham wrote: > > Richard Whalen wrote: > > > A file name is composed of a sequence of strings. The first string > > > specifies the file system. The last string specifies the file name. The > > > intermediate strings specify each element of the directory > path. This will > > > allow each system to compose the appropriate syntax by concatenating the > > > strings with the appropriate separators. > > > > It isn't entirely clear what you mean by `each system'. > >I took him as meaning the client will take the effort to translate >pathnames it sends into this format. So that where it currently >sends 'string pathname', that string will itself be composed of >a set of strings. > >Therefore we have a common over the wire format for pathnames which >all clients have to translate into, and all server translate from. > >(As I recall pathnames aren't sent from server to client, just filenames) Perhaps this is a job for an ASN.1 representation of a complete filename? ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:02:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16838 for ; Fri, 8 Mar 2002 12:02:41 -0500 (EST) Received: (qmail 8595 invoked by uid 605); 8 Mar 2002 17:02:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8588 invoked from network); 8 Mar 2002 17:02:39 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 8 Mar 2002 17:02:39 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA06223; Fri, 8 Mar 2002 18:02:36 +0100 (MET) Date: Fri, 8 Mar 2002 18:02:36 +0100 From: Markus Friedl To: "Dan O'Reilly" Cc: ietf-ssh@netbsd.org Subject: Re: Specifying file names in SSH File Transfer Protocol Message-ID: <20020308170235.GA4034@faui02> References: <"fromanakin"@pobox.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 10:01:02AM -0700, Dan O'Reilly wrote: > Perhaps this is a job for an ASN.1 representation of a complete filename? you really want ASN.1 in a slim protocol? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:10:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17666 for ; Fri, 8 Mar 2002 12:10:52 -0500 (EST) Received: (qmail 14240 invoked by uid 605); 8 Mar 2002 17:10:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14233 invoked from network); 8 Mar 2002 17:10:48 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 8 Mar 2002 17:10:48 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KF44HIEXTU96VLVM@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 08 Mar 2002 10:10:44 -0700 (MST) Date: Fri, 08 Mar 2002 10:10:40 -0700 From: "Dan O'Reilly" Subject: Re: Specifying file names in SSH File Transfer Protocol In-reply-to: <20020308170235.GA4034@faui02> X-Sender: oreilly@raptor.psccos.com To: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 10:02 AM 3/8/2002, Markus Friedl wrote: >On Fri, Mar 08, 2002 at 10:01:02AM -0700, Dan O'Reilly wrote: > > Perhaps this is a job for an ASN.1 representation of a complete filename? > >you really want ASN.1 in a slim protocol? Witness the last few message exchanges. To date, everything has assumed a UNIX-style filename. Demonstrably, VMS and UNIX are different, as are other potential candidates down the road. ASN.1 obviates filename and path mapping translation issues. Now, if there's a better option than ASN.1, I have no quarrel with using it. But the functionality supplied by ASN.1 handles this better than anything I can think of. I grant the point, though, that it's potentially overkill in this protocol, but you need the functionality. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:13:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17782 for ; Fri, 8 Mar 2002 12:13:37 -0500 (EST) Received: (qmail 15265 invoked by uid 605); 8 Mar 2002 17:13:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15256 invoked from network); 8 Mar 2002 17:13:33 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 8 Mar 2002 17:13:33 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA07022; Fri, 8 Mar 2002 18:13:30 +0100 (MET) Date: Fri, 8 Mar 2002 18:13:30 +0100 From: Markus Friedl To: "Dan O'Reilly" Cc: ietf-ssh@netbsd.org Subject: Re: Specifying file names in SSH File Transfer Protocol Message-ID: <20020308171330.GB4034@faui02> References: <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 10:10:40AM -0700, Dan O'Reilly wrote: > that it's potentially overkill in this protocol, but you need the > functionality. even then int32 num_components string component0 ... string componentn wrapped into a string would be simpler, and more like the rest of the protocol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:17:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18083 for ; Fri, 8 Mar 2002 12:17:49 -0500 (EST) Received: (qmail 17729 invoked by uid 605); 8 Mar 2002 17:17:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17680 invoked from network); 8 Mar 2002 17:17:31 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 8 Mar 2002 17:17:31 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KF44PU6FBQ96VLVM@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Fri, 08 Mar 2002 10:17:27 -0700 (MST) Date: Fri, 08 Mar 2002 10:17:24 -0700 From: "Dan O'Reilly" Subject: Re: Specifying file names in SSH File Transfer Protocol In-reply-to: <20020308171330.GB4034@faui02> X-Sender: oreilly@raptor.psccos.com To: Markus Friedl Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20020308101429.01c3f8a8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 10:13 AM 3/8/2002, Markus Friedl wrote: >On Fri, Mar 08, 2002 at 10:10:40AM -0700, Dan O'Reilly wrote: > > that it's potentially overkill in this protocol, but you need the > > functionality. > >even then > int32 num_components > string component0 > ... > string componentn >wrapped into a string > >would be simpler, and more like the rest of the protocol. I agree. I think that would work pretty well. Next question: is there a need for a system identifier? In our work here for VMS, we would have found it useful to know something about the other side of the transaction. Specifically, if the system is UNIX, there's exactly 1 file structure. However, on VMS, there are multiple file structures, so knowing the other side is VMS would be important. I'm not suggesting that be part of the above message, but perhaps something in the initial message exchange could incorporate that functionality. ------ +-------------------------------+---------------------------------------+ | Dan O'Reilly | | | Principal Engineer | "Why should I care about posterity? | | Process Software | What's posterity ever done for me?" | | http://www.process.com | -- Groucho Marx | +-------------------------------+---------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 12:21:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18442 for ; Fri, 8 Mar 2002 12:21:56 -0500 (EST) Received: (qmail 20570 invoked by uid 605); 8 Mar 2002 17:21:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20549 invoked from network); 8 Mar 2002 17:21:41 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 8 Mar 2002 17:21:41 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21643 for ; Fri, 8 Mar 2002 10:21:40 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA04454 for ; Fri, 8 Mar 2002 09:21:49 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.86.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g28HLdhi951761 for ; Fri, 8 Mar 2002 09:21:39 -0800 (PST) Message-Id: <200203081721.g28HLdhi951761@jurassic.eng.sun.com> Date: Fri, 8 Mar 2002 09:21:11 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Specifying file names in SSH File Transfer Protocol To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wpBCVfGIlGV70T4gqcN0ug== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list I don't really like the suggestion of breaking the path and filename up into components. This is basically what NFSv2 did, when WebNFS was added to NFSv3 (client RFC 2054 and server RFC 2055) they went to a mechanism more like what sftp has today (See section 6 in RFC 2054). If I understand what was being proposed it would also still be in a single packet rather than the multiple round trips that NFS had until multi-component lookup arrived. Exactly what problem does the current filename mechanism pose ? a) As far as the over the wire protocol is concerned ? b) For implementors of clients ? c) For implementors of servers ? d) Most importantly for users ? There are already implementations of the protocol that work between Windows and UNIX platforms and they use different separators natively. Adding the complexity of ASN.1 is going to hurt adoption of the protocol. Also remember that this stuff is already deployed and being actively used by a large number of people so making massive changes like switching to ASN.1 probably isn't a good idea. Personally I've been using WebNFS over SSH rather than sftp recently, but that isn't available to everyone (AFAIK Solaris has the only WebNFS server but there are plugins for the nfs URL in some on Solaris based web browsers. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 13:25:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22308 for ; Fri, 8 Mar 2002 13:25:20 -0500 (EST) Received: (qmail 2136 invoked by uid 605); 8 Mar 2002 18:25:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2129 invoked from network); 8 Mar 2002 18:25:17 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 8 Mar 2002 18:25:17 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA25484 for ietf-ssh@netbsd.org; Fri, 8 Mar 2002 18:22:31 GMT Date: Fri, 8 Mar 2002 18:22:31 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020308182231.A25387@edinburgh.cisco.com> References: <200203062035.g26KZLUZ013552@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200203062035.g26KZLUZ013552@ack.east.sun.com>; from sommerfeld@east.sun.com on Wed, Mar 06, 2002 at 03:35:21PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 06, 2002 at 03:35:21PM -0500, Bill Sommerfeld wrote: > > Issues raised so far: Well there is also the issue I raised on 4th Feb in Message-ID: <20020204234611.A21942@edinburgh.cisco.com> Pasted again below: I've got a slightly different issue with the userauth spec, section 3 states: Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting (preferably with a proper disconnect message sent first to ease troubleshooting). Maybe I'm missing something, but I can't see the need to disconnect in this case, as opposed to simply discarding these messages. At the moment an extra RTT is required to wait for the SSH_MSG_USERAUTH_SUCCESS, assuming that the log in method succeeds. Given that I happen to frequently log into machines over long slow (long RTT) links, it gets painful. Unless there is a valid security reason for disconnecting, I'd suggest a change to: Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so any of these messages received before authentication has completed cannot be processed; if this situation occurs the server MUST silently discard those messages. An alternative would be to generate some sort of error response to the messages. However silent discard serves the purpose of allowing one to pipeline the initial connection protocol messages after a USERAUTH_REQUEST on the assumption that it will succeed, and still automatically deal with the request failing. The failure response indicating that the subsequent higher level protocol messages have been discarded. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 13:58:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25071 for ; Fri, 8 Mar 2002 13:58:23 -0500 (EST) Received: (qmail 19091 invoked by uid 605); 8 Mar 2002 18:58:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19079 invoked from network); 8 Mar 2002 18:58:19 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 8 Mar 2002 18:58:19 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id B9D20207C1; Fri, 8 Mar 2002 13:58:15 -0500 (EST) Date: Fri, 8 Mar 2002 13:58:15 -0500 From: Niels Provos To: "Dan O'Reilly" Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: Specifying file names in SSH File Transfer Protocol Message-ID: <20020308185815.GH29428@citi.citi.umich.edu> Mail-Followup-To: Dan O'Reilly , Markus Friedl , ietf-ssh@netbsd.org References: <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> <5.1.0.14.2.20020308101429.01c3f8a8@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020308101429.01c3f8a8@raptor.psccos.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 10:17:24AM -0700, Dan O'Reilly wrote: > Next question: is there a need for a system identifier? In our work here > for VMS, we would have found it useful to know something about the other > side of the transaction. Specifically, if the system is UNIX, there's > exactly 1 file structure. However, on VMS, there are multiple file > structures, so knowing the other side is VMS would be important. I'm not > suggesting that be part of the above message, but perhaps something in the > initial message exchange could incorporate that functionality. Do not complicate things. KISS is still a good moto. ASN.1 is the biggest mess to ever have entered the IETF. I am sure that there is a canonical filename transformation from VMS to UNIX and vice versa. This is an application problem and I do not see any need to further burden the ssh protocols. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 14:07:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25781 for ; Fri, 8 Mar 2002 14:07:47 -0500 (EST) Received: (qmail 26345 invoked by uid 605); 8 Mar 2002 19:07:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26317 invoked from network); 8 Mar 2002 19:07:44 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Mar 2002 19:07:44 -0000 Received: from [192.168.0.3] (HELO bhag) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 509168; Fri, 08 Mar 2002 12:15:21 -0700 Message-ID: <000b01c1c6d4$69385370$6401a8c0@sandia01.nm.comcast.net> From: "Jeff P. Van Dyke" To: "Niels Provos" , "Dan O'Reilly" Cc: "Markus Friedl" , References: <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <63D30D6E10CFD11190A90000F805FE86040AA150@lespaul.process.com> <5.1.0.14.2.20020308100003.00b1d850@raptor.psccos.com> <5.1.0.14.2.20020308100726.00b1dc40@raptor.psccos.com> <5.1.0.14.2.20020308101429.01c3f8a8@raptor.psccos.com> <20020308185815.GH29428@citi.citi.umich.edu> Subject: Re: Specifying file names in SSH File Transfer Protocol Date: Fri, 8 Mar 2002 12:06:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > On Fri, Mar 08, 2002 at 10:17:24AM -0700, Dan O'Reilly wrote: > > Next question: is there a need for a system identifier? In our work here > > for VMS, we would have found it useful to know something about the other > > side of the transaction. Specifically, if the system is UNIX, there's > > exactly 1 file structure. However, on VMS, there are multiple file > > structures, so knowing the other side is VMS would be important. I'm not > > suggesting that be part of the above message, but perhaps something in the > > initial message exchange could incorporate that functionality. > Do not complicate things. KISS is still a good moto. ASN.1 is the > biggest mess to ever have entered the IETF. > > I am sure that there is a canonical filename transformation from VMS > to UNIX and vice versa. This is an application problem and I do not > see any need to further burden the ssh protocols. Personally, I'm not convinced changing SFTP is the right solution (it's widely deployed and very UNIX specific in many ways), but I do believe there is a need to address this problem without forcing all of the burden onto the applications. The problem goes beyond filenames. I'd like to be able to manipulate file permissions remotely. And, the current UNIX model of file permissions is too simple to map to Windows NT. Does NFSv3 or WebNFS address the file permissions problem in a better fashion than SFTP or FTP? Jeff P. Van Dyke jpv@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 14:16:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26910 for ; Fri, 8 Mar 2002 14:16:56 -0500 (EST) Received: (qmail 2100 invoked by uid 605); 8 Mar 2002 19:16:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2093 invoked from network); 8 Mar 2002 19:16:53 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 8 Mar 2002 19:16:53 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09622 for ; Fri, 8 Mar 2002 12:16:52 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.50]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA28264 for ; Fri, 8 Mar 2002 11:17:01 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.86.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g28JGphi980661 for ; Fri, 8 Mar 2002 11:16:51 -0800 (PST) Message-Id: <200203081916.g28JGphi980661@jurassic.eng.sun.com> Date: Fri, 8 Mar 2002 11:16:23 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Specifying file names in SSH File Transfer Protocol To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y6rYYJkwOd/scoJ66oyTmw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >Does NFSv3 or WebNFS address the file permissions problem in >a better fashion than SFTP or FTP? NFSv4 does. NFSv3 is basically a remove UNIX filesystem - Sun has an sideband protocol for dealing with ACLs on Solaris. WebNFS is a set of extensions to NFSv3 to make it easier to use through firewalls and to help performance over WANs. I have continued concern that we don't need to reinvent the wheel here. What is the goal of the file transfer protocol ? Is it supposed to be equivalent to what people do with FTP but over a secure link ? Or is it supposed to be a remote filesystem running over the SSH protocol ? Unless we know the answer too this we will never know if we are adding the correct features and we will never know when we have met the requirements. I really think we need to stop and thing about the problem we are trying to solve and if a solution is needed at all, is this the correct group to be solving it - especially given that the current sftp protocol doesn't really depend on anything from SSH (it can run over other transports). However having said that we have an already deployed system so I don't think the answer can easily be "do nothing", but we do need to know the problem space. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 14:58:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29978 for ; Fri, 8 Mar 2002 14:58:45 -0500 (EST) Received: (qmail 3073 invoked by uid 605); 8 Mar 2002 19:58:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3036 invoked from network); 8 Mar 2002 19:58:39 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 8 Mar 2002 19:58:39 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04772; Fri, 8 Mar 2002 12:58:38 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28434; Fri, 8 Mar 2002 14:58:37 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g28JvdUZ018322; Fri, 8 Mar 2002 14:57:39 -0500 (EST) Message-Id: <200203081957.g28JvdUZ018322@ack.east.sun.com> From: Bill Sommerfeld To: Derek Fawcus cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Your message of "Fri, 08 Mar 2002 18:22:31 GMT." <20020308182231.A25387@edinburgh.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 08 Mar 2002 14:57:39 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > Maybe I'm missing something, but I can't see the need to disconnect in this > case, as opposed to simply discarding these messages. I don't think think it's that simple. Have you actually prototyped this? Many of these message types are ones for which the client expects a response -- simply discarding such requests on the server will confuse and/or hang clients which were expecting responses. Any implementors want to comment on this in more detail? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 15:27:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01773 for ; Fri, 8 Mar 2002 15:27:18 -0500 (EST) Received: (qmail 18765 invoked by uid 605); 8 Mar 2002 20:27:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18758 invoked from network); 8 Mar 2002 20:27:15 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 8 Mar 2002 20:27:15 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id UAA00089 for ietf-ssh@netbsd.org; Fri, 8 Mar 2002 20:24:30 GMT Date: Fri, 8 Mar 2002 20:24:30 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020308202430.B28797@edinburgh.cisco.com> References: <20020308182231.A25387@edinburgh.cisco.com> <200203081957.g28JvdUZ018322@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200203081957.g28JvdUZ018322@ack.east.sun.com>; from sommerfeld@east.sun.com on Fri, Mar 08, 2002 at 02:57:39PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 02:57:39PM -0500, Bill Sommerfeld wrote: > > Maybe I'm missing something, but I can't see the need to disconnect in this > > case, as opposed to simply discarding these messages. > > I don't think think it's that simple. Have you actually prototyped > this? Not yet. I'm working on an implementation, but I've not got to the user auth part yet. My concern is pipelining messages in anticipation of success, and being able to cope with an error occuring. Looking at the packet sequences, the current restriction forces another RTT into the log in sequence. > Many of these message types are ones for which the client expects a > response -- simply discarding such requests on the server will confuse > and/or hang clients which were expecting responses. I did state in the original message that returning an error was also acceptable to me, I just didn't want them to cause the connection to be terminated if there was no security implication of doing so. I also don't think it'll cause a problem for existing clients, as they simply won't trigger this situation. > Any implementors want to comment on this in more detail? I'd not have thought there'd be any implication of existing client's, as they'd not send the message until the RTT had expired, and they'd got a response. There would be an issue for new clients connecting to existing servers, but I was going to deal with that by having a flag which would delay based upon a CLI flag, so I could connect through old servers. It would also mean that existing servers would strictly be non conforming, but that could be dealt with during upgrades. If as you state there is a problem with silent discard, I'd be happy with the following alternate text: Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so any of these messages received before authentication has completed cannot be processed; if this situation occurs the server MUST respond with an error response, and then not act upon the message. For the error response, I'd suggest that SSH_MSG_UNIMPLEMENTED would be workable. I'd rather have a generic message as a response, as this means we don't place a burden on the higher level protocols or always have a failure type of response. An alternate would be a message sent back to state that the message was explicity exgnored (as opposed to unimplemented), which would in all other regards look like an unimplemented message, i.e. byte SSH_MSG_IGNORED uint32 packet sequence number of ignored message However that would then place more restrictions upon the sender in that they'd have to check for IGNORED and UNIMPLEMENTED, and decide if they wish to allow the connection to continue. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 15:34:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02102 for ; Fri, 8 Mar 2002 15:34:05 -0500 (EST) Received: (qmail 22493 invoked by uid 605); 8 Mar 2002 20:34:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22486 invoked from network); 8 Mar 2002 20:34:03 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 8 Mar 2002 20:34:03 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14780; Fri, 8 Mar 2002 13:34:02 -0700 (MST) Received: from ack.east.sun.com (ack.East.Sun.COM [129.148.174.177]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06484; Fri, 8 Mar 2002 15:34:01 -0500 (EST) Received: from ack (localhost [127.0.0.1]) by ack.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g28KX4UZ018485; Fri, 8 Mar 2002 15:33:04 -0500 (EST) Message-Id: <200203082033.g28KX4UZ018485@ack.east.sun.com> From: Bill Sommerfeld To: Derek Fawcus cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Your message of "Fri, 08 Mar 2002 20:24:30 GMT." <20020308202430.B28797@edinburgh.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 08 Mar 2002 15:33:03 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I also don't think it'll cause a problem for existing clients, as > they simply won't trigger this situation. What this tells me is that changing this later (after the current core drafts go to proposed standard RFC and we're ready to go for draft standard) is eminently doable. I'll repeat my litany: Is this something we absolutely positively need to fix this very instant? It doesn't seem that compelling to me.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 16:44:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05952 for ; Fri, 8 Mar 2002 16:44:41 -0500 (EST) Received: (qmail 4275 invoked by uid 605); 8 Mar 2002 21:44:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4268 invoked from network); 8 Mar 2002 21:44:39 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 8 Mar 2002 21:44:39 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28819 for ; Fri, 8 Mar 2002 13:44:38 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id NAA26889 for ; Fri, 8 Mar 2002 13:44:47 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.86.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g28Libhi109267 for ; Fri, 8 Mar 2002 13:44:37 -0800 (PST) Message-Id: <200203082144.g28Libhi109267@jurassic.eng.sun.com> Date: Fri, 8 Mar 2002 13:44:10 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Core draft last call update. To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +68730ZeqM2jLtRurC74JQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >> Maybe I'm missing something, but I can't see the need to disconnect in this >> case, as opposed to simply discarding these messages. > >I don't think think it's that simple. Have you actually prototyped >this? > >Many of these message types are ones for which the client expects a >response -- simply discarding such requests on the server will confuse >and/or hang clients which were expecting responses. In addition to that what is the point of the client sending the packets if they are likely to be discarded anyway ? This makes the client more complex. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 8 17:54:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09298 for ; Fri, 8 Mar 2002 17:54:17 -0500 (EST) Received: (qmail 7578 invoked by uid 605); 8 Mar 2002 22:54:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7570 invoked from network); 8 Mar 2002 22:54:14 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 8 Mar 2002 22:54:14 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id WAA04912; Fri, 8 Mar 2002 22:51:27 GMT Date: Fri, 8 Mar 2002 22:51:27 +0000 From: Derek Fawcus To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020308225127.A4768@edinburgh.cisco.com> References: <200203082144.g28Libhi109267@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200203082144.g28Libhi109267@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Fri, Mar 08, 2002 at 01:44:10PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 08, 2002 at 01:44:10PM -0800, Darren Moffat wrote: > >> Maybe I'm missing something, but I can't see the need to disconnect in > this > >> case, as opposed to simply discarding these messages. > > > >I don't think think it's that simple. Have you actually prototyped > >this? > > > >Many of these message types are ones for which the client expects a > >response -- simply discarding such requests on the server will confuse > >and/or hang clients which were expecting responses. > > In addition to that what is the point of the client sending the packets > if they are likely to be discarded anyway ? This makes the client > more complex. But the point is that they're not likely to be discarded. Assume that your log in attempt will be sucessful, in that case you can send the next packets (those which form the upper layer exchange) without waiting for a RTT. Granted, if for some reason the log in failed, you have to cope with that failure, and that case is more complex. But it is entirely the choice of the client if it will trigger and hence have to deal with this complexity. I'm just after not precluding a client from making that choice if it can get some advantage from dealing with the extra complexity. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 9 00:33:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27312 for ; Sat, 9 Mar 2002 00:33:30 -0500 (EST) Received: (qmail 10896 invoked by uid 605); 9 Mar 2002 05:33:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10888 invoked from network); 9 Mar 2002 05:33:26 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 9 Mar 2002 05:33:26 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA18469; Fri, 8 Mar 2002 21:33:03 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA17712; Fri, 8 Mar 2002 21:32:53 -0800 (PST) Date: Fri, 8 Mar 2002 21:32:53 -0800 From: Wei Dai To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: updated transport & userauth drafts Message-ID: <20020308213253.A3374@eskimo.com> References: <20020301163153.L29118@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rja@extremenetworks.com on Fri, Mar 01, 2002 at 08:07:57PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 01, 2002 at 08:07:57PM -0500, RJ Atkinson wrote: > On Friday, March 1, 2002, at 07:31 , Wei Dai wrote: > > The security of CTR mode is well-analyzed and well-understood. > > The Real Cryptographers (tm) that I talk with would > strongly dispute that assertion, though (fortunately) > they have better diplomatic skills than I do. They would, or they do (dispute that assertion)? Would they be willing to offer this working group an explaination why? Can you tell us who these cryptographers are, or at least what their qualifications are? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 9 00:37:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27336 for ; Sat, 9 Mar 2002 00:37:51 -0500 (EST) Received: (qmail 12615 invoked by uid 605); 9 Mar 2002 05:37:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12608 invoked from network); 9 Mar 2002 05:37:49 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 9 Mar 2002 05:37:49 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA21706; Fri, 8 Mar 2002 21:37:33 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA17954; Fri, 8 Mar 2002 21:37:22 -0800 (PST) Date: Fri, 8 Mar 2002 21:37:22 -0800 From: Wei Dai To: Bill Sommerfeld Cc: David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020308213722.B3374@eskimo.com> References: <200203062113.g26LDcUZ013706@ack.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203062113.g26LDcUZ013706@ack.east.sun.com>; from sommerfeld@east.sun.com on Wed, Mar 06, 2002 at 04:13:38PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 06, 2002 at 04:13:38PM -0500, Bill Sommerfeld wrote: > We SHOULD NOT DELAY THE REST OF SSH while we discuss a solution, > particularly since there appears to be some resistance to counter > modes from the membership. Would be appropriate to either (1) put something in the security considerations section about this attack, so that implementors are warned about this problem and will know to look for a future RFC describing the solution, or (2) delay the SSH transport protocol spec and advance the rest of SSH? P.S. I'm currently on vacation and my Internet connection is spotty. Please excuse the late replys. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 9 10:26:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10679 for ; Sat, 9 Mar 2002 10:26:57 -0500 (EST) Received: (qmail 12951 invoked by uid 605); 9 Mar 2002 15:26:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12944 invoked from network); 9 Mar 2002 15:26:56 -0000 Received: from sommerfeld.ne.mediaone.net (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 9 Mar 2002 15:26:56 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 32D752709; Sat, 9 Mar 2002 10:26:56 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id A9FB22A4A; Sat, 9 Mar 2002 10:26:55 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 9A0541FE8; Sat, 9 Mar 2002 10:26:55 -0500 (EST) From: Bill Sommerfeld To: Wei Dai Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Message from Wei Dai of "Fri, 08 Mar 2002 21:37:22 PST." <20020308213722.B3374@eskimo.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Sat, 09 Mar 2002 10:26:50 -0500 Message-Id: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > Would be appropriate to either (1) put something in the security > considerations section about this attack, so that implementors are warned > about this problem and will know to look for a future RFC describing the > solution, or (2) delay the SSH transport protocol spec and advance the > rest of SSH? (2) is not useful, because you can't do SSH without all four drafts. Remember that a certain set of folks will use telnet instead simply because there's an RFC for telnet and there isn't one for SSH. (1) is a possibility but needs to be worded very carefully (to not scare telnet users away from deploying ssh). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 00:38:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21479 for ; Mon, 11 Mar 2002 00:38:55 -0500 (EST) Received: (qmail 327 invoked by uid 605); 11 Mar 2002 05:38:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 319 invoked from network); 11 Mar 2002 05:38:52 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 11 Mar 2002 05:38:52 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA01503; Sun, 10 Mar 2002 21:38:49 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA28261; Sun, 10 Mar 2002 21:38:49 -0800 (PST) Date: Sun, 10 Mar 2002 21:38:49 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020310213849.B7020@eskimo.com> References: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020309152655.A9FB22A4A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Sat, Mar 09, 2002 at 10:26:50AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Mar 09, 2002 at 10:26:50AM -0500, Bill Sommerfeld wrote: > Remember that a certain set of folks will use telnet instead simply > because there's an RFC for telnet and there isn't one for SSH. Who are these people who puts that much more value on the availability of an RFC than on security? I'm not sure we should be so concerned with them. As the working group charter states, this working group is supposed to assure that the SSH protocol provides strong security against cryptanalysis and protocol attacks. I think it does nothing to inspire confidence in potential users of the SSH protocol to have a security fix come out immediately after the core RFCs are published. To me, being able to claim that the set of core RFCs is free from known protocol weaknesses is much more valuable than having the RFCs published a few weeks earlier. Given that the problem was found in time, and that the fix is simple (I've already provided the suggested language), why not just agree to fix it now? I'm new to the IETF standardization process, but how much time could it possibly take to put in the fix? If CTR mode is too controversial (although I don't know why it would be and still haven't seen a substantial argument against it) I would be willing to compromise by using OFB or CFB mode instead. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 03:38:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01597 for ; Mon, 11 Mar 2002 03:38:47 -0500 (EST) Received: (qmail 27111 invoked by uid 605); 11 Mar 2002 08:38:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27100 invoked from network); 11 Mar 2002 08:38:31 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 11 Mar 2002 08:38:31 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id A72493BD0A; Mon, 11 Mar 2002 09:38:28 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id D39936C007; Mon, 11 Mar 2002 09:38:29 +0100 (MET) Date: Mon, 11 Mar 2002 09:37:09 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Bill Sommerfeld Cc: Derek Fawcus , Subject: Re: Core draft last call update. In-Reply-To: <200203081957.g28JvdUZ018322@ack.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 8 Mar 2002, Bill Sommerfeld wrote: > > Maybe I'm missing something, but I can't see the need to disconnect in this > > case, as opposed to simply discarding these messages. > > I don't think think it's that simple. Have you actually prototyped > this? > > Many of these message types are ones for which the client expects a > response -- simply discarding such requests on the server will confuse > and/or hang clients which were expecting responses. > > Any implementors want to comment on this in more detail? I can't see a big win in discard versus disconnect (especially since we are in last-call now, considering the earlier comments on last minute changes to the drafts...). Disconnect seems safer and easier to handle from a protocol-perspective. If you want to optimistally assume the authentication goes well and start higher-level traffic based on this assumption it is better to handle this by queueing this traffic until the authentication stage is done. There would be a marginal performance win of course, however the complexity in handling potentially discarded messages seems a high price for this. Since the whole transport setup and authentication stages are pretty slimmed down anyway, this wouldn't add much IMHO. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 04:09:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02063 for ; Mon, 11 Mar 2002 04:09:25 -0500 (EST) Received: (qmail 11556 invoked by uid 605); 11 Mar 2002 09:09:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11549 invoked from network); 11 Mar 2002 09:09:22 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 11 Mar 2002 09:09:22 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA08575; Mon, 11 Mar 2002 10:09:07 +0100 (MET) Date: Mon, 11 Mar 2002 10:09:07 +0100 From: Markus Friedl To: Wei Dai Cc: Bill Sommerfeld , Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020311090906.GA7925@faui02> References: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> <20020310213849.B7020@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020310213849.B7020@eskimo.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Mar 10, 2002 at 09:38:49PM -0800, Wei Dai wrote: > Given that the problem was found in time, and that the fix is simple (I've > already provided the suggested language), why not just agree to fix it > now? I'm new to the IETF standardization process, but how much time could > it possibly take to put in the fix? If CTR mode is too controversial > (although I don't know why it would be and still haven't seen a > substantial argument against it) I would be willing to compromise by using > OFB or CFB mode instead. Personally I think it would be better to add OFB and/or CFB modes than to scare people in the draft by saying: "we use CBC but CBC can be broken easily" (this is how people will read it). As to CTR: AFAIK in CTR mode the handling, formating of the counter needs some work before we can agree, e.g the proposal for aes128-ctr in IPsec makes size(ciphertext) != size(plaintext), so CTR should not be added now, because it will delay the process significantly. So, if we would need a spec for OFB/CFB (with cipher block-sized feedback) soon. Having a paragraph about the dangers of CBC is a bad idea unless we offer alternatives to CBC in the very same document. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 04:30:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02570 for ; Mon, 11 Mar 2002 04:30:29 -0500 (EST) Received: (qmail 23068 invoked by uid 605); 11 Mar 2002 09:30:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23061 invoked from network); 11 Mar 2002 09:30:28 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 11 Mar 2002 09:30:28 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g2B9M6824547 for ietf-ssh@netbsd.org; Mon, 11 Mar 2002 01:22:06 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Core draft last call update. Date: 11 Mar 2002 09:22:05 GMT Organization: University of California, Berkeley Lines: 21 Distribution: isaac Message-ID: References: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> <20020310213849.B7020@eskimo.com> <20020311090906.GA7925@faui02> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1015838525 24485 128.32.45.153 (11 Mar 2002 09:22:05 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Mar 2002 09:22:05 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl wrote: >As to CTR: AFAIK in CTR mode the handling, formating of the counter >needs some work before we can agree, e.g the proposal for aes128-ctr in >IPsec makes size(ciphertext) != size(plaintext), so CTR should not be >added now, because it will delay the process significantly. > >So, if we would need a spec for OFB/CFB (with cipher block-sized >feedback) soon. Hmm. I must admit I'm a little confused: what are the reasons to prefer OFB mode over CTR mode? Are there some security reasons? Is it something else? I don't see anything terribly wrong with OFB mode, but I'd like to understand why it is preferred over CTR mode. I'm also confused on why it's a problem that IPSec uses a form of CTR mode not so well suited for SSH. Or is it better not to ask? P.S. I assumed that if there is a known security weakness, it would be disclosed in the RFC, so I'm surprised that you consider it a bad thing to have a paragraph describing the weakness. Were you proposing that mention of this risk should be omitted from the RFC? That seems dangerous. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 10:55:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12451 for ; Mon, 11 Mar 2002 10:55:05 -0500 (EST) Received: (qmail 8059 invoked by uid 605); 11 Mar 2002 15:55:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8051 invoked from network); 11 Mar 2002 15:55:04 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 11 Mar 2002 15:55:04 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 511163; Mon, 11 Mar 2002 09:02:47 -0700 Message-ID: <004301c1c914$939be180$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Andersson, Mats" , "Bill Sommerfeld" Cc: "Derek Fawcus" , References: Subject: Re: Core draft last call update. Date: Mon, 11 Mar 2002 08:51:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > On Fri, 8 Mar 2002, Bill Sommerfeld wrote: > > > Maybe I'm missing something, but I can't see the need to disconnect in this > > > case, as opposed to simply discarding these messages. > > > > I don't think think it's that simple. Have you actually prototyped > > this? > > > > Many of these message types are ones for which the client expects a > > response -- simply discarding such requests on the server will confuse > > and/or hang clients which were expecting responses. > > > > Any implementors want to comment on this in more detail? > > I can't see a big win in discard versus disconnect (especially since we > are in last-call now, considering the earlier comments on last minute > changes to the drafts...). Disconnect seems safer and easier to handle > from a protocol-perspective. If you want to optimistally assume the > authentication goes well and start higher-level traffic based on this > assumption it is better to handle this by queueing this traffic until the > authentication stage is done. There would be a marginal performance win of > course, however the complexity in handling potentially discarded messages > seems a high price for this. Since the whole transport setup and > authentication stages are pretty slimmed down anyway, this wouldn't add > much IMHO. I agree with this. The current language seems safer and more likely to get us to RFC status without any egg-on-face. Complexity is the enemy. Complexity introduces bugs. If it was just complexity in the client, that the client could chose whether or not to deal with, I might be more inclined to 'not care'. But, it also introduces complexity in the server (which in my opinion is more sensitive to bugs.) And the server MUST bear that complexity. If a server implements the current language, there is very little chance of a packet for a higher level being processed before the user correctly authenticates (due to server bug.) Sure it could happen, but it isn't likely. On the other hand, it seems more likely to happen with the new complexity. Also, since we are in last call, we have very little time to analyze the implications and behaviors of the change. It doesn't seem like we stand to gain enough to take the risk. Maybe we should discuss it more for 2.1 after we've gotten 2.0 to RFC status. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 12:14:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15744 for ; Mon, 11 Mar 2002 12:14:11 -0500 (EST) Received: (qmail 26288 invoked by uid 605); 11 Mar 2002 17:14:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26271 invoked from network); 11 Mar 2002 17:14:08 -0000 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by mail.netbsd.org with SMTP; 11 Mar 2002 17:14:08 -0000 Received: from edi-view1.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BHDkd16684 for ; Mon, 11 Mar 2002 18:13:46 +0100 (MET) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA20963 for ietf-ssh@netbsd.org; Mon, 11 Mar 2002 17:14:06 GMT Date: Mon, 11 Mar 2002 17:14:05 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020311171405.D17506@edi-view1.cisco.com> References: <004301c1c914$939be180$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <004301c1c914$939be180$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Mon, Mar 11, 2002 at 08:51:15AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 11, 2002 at 08:51:15AM -0700, Joseph Galbraith wrote: > > Complexity is the enemy. Complexity introduces bugs. If it was > just complexity in the client, that the client could chose whether > or not to deal with, I might be more inclined to 'not care'. That is where I see the complexity, the server behaviour would be fixed. Instead of the current "shutdown complete SSH connection", it would be either "silent discard" or "generic error response". > But, it also introduces complexity in the server (which in my opinion > is more sensitive to bugs.) And the server MUST bear that complexity. Agreed. However my contention is that this is only client complexity, and then only if the client chooses to invoke the triggering condition. > If a server implements the current language, there is very little > chance of a packet for a higher level being processed before > the user correctly authenticates (due to server bug.) Sure it could > happen, but it isn't likely. > > On the other hand, it seems more likely to happen with the new complexity. Disagree. You're using the same flag (has authentication passed) to simply perform a different action. The packet in question has to be inspected in either case, instead of closing the connection you simply silent discard or send a generic error response. There is no additional complexity, the server behaviour would change from one fixed type of behaviour to another fixed type of behaviour. > Also, since we are in last call, we have very little time to > analyze the implications and behaviors of the change. We have as much time as we choose to take. (i.e. the other thread about CBC mode...) > It doesn't seem like we stand to gain enough to take the risk. OK. The granted, gain is quite small. It's the elimination of one RTT. The issue being that on long RTT links, we already have a multi RTT set up time. Other parts (say the key exchange) are replaceable in the base spec, and a protocol with a small number of RTs could be used. This part of the spec is fixed, and precludes any form of client optimisation. > Maybe we should discuss it more for 2.1 after we've gotten > 2.0 to RFC status. Well if the consensus is for that, I'll accept it. I threw the suggestion in 'cause it seemed a small change, with no security impact, little implementation impact, and because I couldn't see a _security_ (as opposed to an implementation) reason for the current language in the draft. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 12:14:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15756 for ; Mon, 11 Mar 2002 12:14:19 -0500 (EST) Received: (qmail 26289 invoked by uid 605); 11 Mar 2002 17:14:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26272 invoked from network); 11 Mar 2002 17:14:08 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Mar 2002 17:14:08 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 20468835BD3; Mon, 11 Mar 2002 18:14:03 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id SAA27468; Mon, 11 Mar 2002 18:14:02 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Derek Fawcus , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. References: <200203081957.g28JvdUZ018322@ack.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 11 Mar 2002 18:14:01 +0100 In-Reply-To: <200203081957.g28JvdUZ018322@ack.east.sun.com> Message-ID: Lines: 62 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > > Maybe I'm missing something, but I can't see the need to disconnect in this > > case, as opposed to simply discarding these messages. > > I don't think think it's that simple. Have you actually prototyped > this? > > Many of these message types are ones for which the client expects a > response -- simply discarding such requests on the server will confuse > and/or hang clients which were expecting responses. > > Any implementors want to comment on this in more detail? This is my analysis: Discarding packets on the server side should be easy, except that one must not discard any connection-level packets that are sent after the userauth request that succeeded. But this logic should fit well with the logic for discarding userauth messages received after the succeeding one. On the client side, one would compute the initial one or more packets one wants to send after userauthentiation, and piggyback them onto each send userauth request. After the succeeding userauth packet that succeeds, one would expect the replies to the initial packets. However, consider the client sending several userauth requests (corresponding to the user's several public keys, say), with a piggy backed SSH_MSG_CHANNEL_OPEN after each of them. In order: SSH_MSG_USERAUTH_REQUEST SSH_MSG_CHANNEL_OPEN SSH_MSG_USERAUTH_REQUEST SSH_MSG_CHANNEL_OPEN If the second and final userauth request is that which succeeds, all is well, if the above rules are applied. But if the first userauth request succeeds, the second userauth request will be discarded, but *both* SSH_MSG_CHANNEL_OPEN requests will be processed by the server, so the client gets more than it wanted. One solution to this is to require the client that wants to piggyback non-userauth messages to wait for the reply to the first userauth request before sending the second, but then we get more roundtrips. Another might be to not *discard* non-userauth messages, but queue them for later processing after a successful userauthentication. Then the client could send SSH_MSG_CHANNEL_OPEN SSH_MSG_USERAUTH_REQUEST SSH_MSG_USERAUTH_REQUEST and the server would process the channel open request exactly once, *after* user authentication. But I think this reordering trick gets a little ugly. BTW, which implementations set the first_kex_packet_follows flag in the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before trying to optimize away some more roundtrips. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 12:48:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17251 for ; Mon, 11 Mar 2002 12:48:19 -0500 (EST) Received: (qmail 13479 invoked by uid 605); 11 Mar 2002 17:47:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12416 invoked from network); 11 Mar 2002 17:46:51 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 11 Mar 2002 17:46:51 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 511483; Mon, 11 Mar 2002 10:54:27 -0700 Message-ID: <006901c1c924$2cb83580$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , =?iso-8859-1?Q?Niels_M=F6ller?= Cc: "Derek Fawcus" , References: <200203081957.g28JvdUZ018322@ack.east.sun.com> Subject: Re: Core draft last call update. Date: Mon, 11 Mar 2002 10:42:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > BTW, which implementations set the first_kex_packet_follows flag in > the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before > trying to optimize away some more roundtrips. I believe SSH Communications is the only implementation using this, but I'm not sure. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 11 16:55:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26626 for ; Mon, 11 Mar 2002 16:55:58 -0500 (EST) Received: (qmail 16487 invoked by uid 605); 11 Mar 2002 21:55:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16066 invoked from network); 11 Mar 2002 21:55:23 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Mar 2002 21:55:23 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23790 for ; Mon, 11 Mar 2002 14:55:22 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07258 for ; Mon, 11 Mar 2002 16:55:22 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2BLsIgw002569 for ; Mon, 11 Mar 2002 16:54:18 -0500 (EST) Message-Id: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: a more detailed analysis of "known IV" vulnerability. Reply-to: sommerfeld@east.sun.com Date: Mon, 11 Mar 2002 16:54:18 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [folks, please look this over and let me know if I missed anything..] Summary: For 64-bit block ciphers in CBC mode, the probability that a given ssh session key could be exposed to a known-IV chosen-plaintext CBC guessing attack is somewhere around 1 chance in 2**23 assuming the key is used for the maximum recommended 1 gigabyte of data. Given the one-hour lifetime of ssh session keys, the chance of success is also influenced by the round trip time between the attacker and the victim; the 1 chance in 2**23 above assumes a roughly 100microsecond RTT. A 10ms RTT decreases this to roughly one chance in 2**30. To put this in perspective, the chance that a similar 1 gigabyte session encrypted using CBC mode with a 64-bit block will contain a pair of duplicate ciphertext blocks (exposing the XOR of the corresponding plaintext blocks) is about one chance in 2**11. With 128-byte-block CBC mode, the attack is much more difficult; the guessing attack is possible on a session about 1 time in 2**71. Details: [Note: One thing not considered here is compression, which fits between the ssh transport and connection layers -- it may allow additional user-chosen data in the first block, but requires the attacker to have perfect or near-perfect knowledge of the previous plaintext in order to allow the state of the compressor to be tracked. I've chosen to ignore it for now.] Given the multilayered message framing in ssh v2, it appears that the earliest raw user data can appear is 14 bytes into a message; before that, an attacker can really only influence message lengths. Messages in the encrypted stream look like: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length [http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-13.txt] However, that's not all that's involved.. the typical 'payload' starts: byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data [http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-15.txt] and a "string" in ssh encoding is a is a uint32 N followed by N bytes.. [http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-12.txt] Assuming a max message length of 64k (a typical implementation limit), an attacker can, at best, influence 16 bits out of the first 64 bits of the packet by adjusting the length of the injected message. so, rolling it all together, the first 16 bytes would be: len3 len2 len1 len0 plen 0x5e chan chan chan chan sln3 sln2 sln1 sln0 dat0 dat1 len is packet length plen is padding length chan are the bytes of channel id (small integer) slen are the string length bytes dat0 and dat1 are the actual payload being sent to the channel. len3/len2 are likely to be zero; high order bits of len1 are likely to be zero (short messages); the three low order bits of len0 are all zero (since packets are always a multiple of the block size or 8 bytes, whichever's larger), though those bits effectively move to the low order bits of plen.. high order bytes of chan are very likely to be zero or at the very least fixed for a given injection point. For an 8-byte block size: Of the first 8 bytes, attacker picks at most 16 bits, and has to wait for the remaining 48 bits of the IV to line up "just so"; i.e., on average, they have a suitable IV only once every 2**48 messages. There's a keychange every gigabyte. Let's assume a minimum message size of 32 bytes (the sshv2 implementation I use seems to send slightly larger messages than that, but using power of two makes the math easier), so that's 2**25 messages per key. This means that any given ssh session will be vulnerable to the message-guessing attack roughly one chance in 2**23. For a 16-byte block size: attacker controls at most 32 independant bits (the string length and packet length are going to be interdependant), so suitable IV comes along only once in 2**96 messages. With 2**25 messages per key, this means a session will be vulnerable at most one chance in 2**71. --- Effects of the one-hour maximum session key lifetime: plaintext insertion -> victim => snoop point =======> peer ^ | +--------------------------------+ In order to effect the attack, the attacker must trick the attacked system into generating a large number of messages (in order to generate as many possible IV's as possible) but must also be able to react very quickly to inject the chosen plaintext immediately after the IV appears; this suggests that the attack will be limited by the round-trip delay around the feedback loop diagrammed above. In order to get 2**25 "usable" IV's in an hour, the victim must generate roughly 9321 packets per second, and the total delay around the feedback loop (including the processing time on the victim) must be less than 107 microseconds. Increasing the delay will reduce the chance that the session will be vulnerable. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 08:03:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20795 for ; Tue, 12 Mar 2002 08:03:02 -0500 (EST) Received: (qmail 21611 invoked by uid 605); 12 Mar 2002 13:03:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21602 invoked from network); 12 Mar 2002 13:02:59 -0000 Received: from cdc-info.cdc.informatik.tu-darmstadt.de (130.83.23.100) by mail.netbsd.org with SMTP; 12 Mar 2002 13:02:59 -0000 Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id E5B8F2C88 for ; Tue, 12 Mar 2002 14:02:57 +0100 (MET) Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g2CD2uw13426 for ietf-ssh@netbsd.org; Tue, 12 Mar 2002 14:02:56 +0100 (MET) Date: Tue, 12 Mar 2002 14:02:56 +0100 From: Bodo Moeller To: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020312140256.A13417@cdc.informatik.tu-darmstadt.de> References: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> <20020310213849.B7020@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020310213849.B7020@eskimo.com>; from weidai@eskimo.com on Sun, Mar 10, 2002 at 09:38:49PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Sun, Mar 10, 2002 at 09:38:49PM -0800, Wei Dai wrote: [...] > Given that the problem was found in time, and that the fix is simple (I've > already provided the suggested language), why not just agree to fix it > now? What about the attack described in Appendix C of , which appears to be applicable to the SSH binary packet protocol as specified in draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or counter mode is used)? -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 09:53:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23728 for ; Tue, 12 Mar 2002 09:53:03 -0500 (EST) Received: (qmail 18712 invoked by uid 605); 12 Mar 2002 14:53:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18704 invoked from network); 12 Mar 2002 14:53:01 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 12 Mar 2002 14:53:01 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 26E902709; Tue, 12 Mar 2002 09:53:01 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id C17672A4A; Tue, 12 Mar 2002 09:53:00 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 833BA1FE8; Tue, 12 Mar 2002 09:53:00 -0500 (EST) From: Bill Sommerfeld To: Bodo Moeller Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Message from Bodo Moeller of "Tue, 12 Mar 2002 14:02:56 +0100." <20020312140256.A13417@cdc.informatik.tu-darmstadt.de> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 12 Mar 2002 09:52:54 -0500 Message-Id: <20020312145300.C17672A4A@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > What about the attack described in Appendix C of > , which appears to be > applicable to the SSH binary packet protocol as specified in > draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or > counter mode is used)? This attack has greatly increased difficulty for SSH because the SSH MAC also covers the random pad at the end of the message. As a result, you can only tell if m and m' are identical if the random padding appended by the sender is identical. Quoting from the transport draft: After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The chance of this happening depends on the message length -- ssh requires at least 4 bytes of padding, and requires that messages be padded to a multiple of the block size and a multiple of 8. If the implementation inserts the minimum padding, this will be between 4 and 11 bytes (and it can always insert more). The most "interesting" case is, of course, a single byte of channel data, which will get a minimum of 9 bytes of padding. You also only get one shot at this per connection -- the peer will drop the connection and forget the session key if you get it wrong. Compression will complicate this attack as well. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 10:05:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24036 for ; Tue, 12 Mar 2002 10:05:26 -0500 (EST) Received: (qmail 25635 invoked by uid 605); 12 Mar 2002 15:05:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25628 invoked from network); 12 Mar 2002 15:05:25 -0000 Received: from cdc-info.cdc.informatik.tu-darmstadt.de (130.83.23.100) by mail.netbsd.org with SMTP; 12 Mar 2002 15:05:25 -0000 Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 1B2FA2C88; Tue, 12 Mar 2002 16:05:24 +0100 (MET) Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g2CF5Mr13908; Tue, 12 Mar 2002 16:05:22 +0100 (MET) Date: Tue, 12 Mar 2002 16:05:22 +0100 From: Bodo Moeller To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020312160522.A13869@cdc.informatik.tu-darmstadt.de> References: <20020312145300.C17672A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020312145300.C17672A4A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Tue, Mar 12, 2002 at 09:52:54AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Tue, Mar 12, 2002 at 09:52:54AM -0500, Bill Sommerfeld wrote: >> What about the attack described in Appendix C of >> , which appears to be >> applicable to the SSH binary packet protocol as specified in >> draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or >> counter mode is used)? > This attack has greatly increased difficulty for SSH because the SSH > MAC also covers the random pad at the end of the message. As a > result, you can only tell if m and m' are identical if the random > padding appended by the sender is identical. I see. Actually the current draft only says that the padding 'SHOULD' be random, not that it 'MUST' be random. Also the minimum padding length of 32 bits isn't large enough to make the attack really intractable, so the protocol should eventually be fixed. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 10:26:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24375 for ; Tue, 12 Mar 2002 10:26:43 -0500 (EST) Received: (qmail 7618 invoked by uid 605); 12 Mar 2002 15:26:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7611 invoked from network); 12 Mar 2002 15:26:41 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 12 Mar 2002 15:26:41 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 896FA2709; Tue, 12 Mar 2002 10:26:40 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 2E12D2A4A; Tue, 12 Mar 2002 10:26:40 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 1E1C51FE8; Tue, 12 Mar 2002 10:26:40 -0500 (EST) From: Bill Sommerfeld To: Bodo Moeller Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Message from Bodo Moeller of "Tue, 12 Mar 2002 14:02:56 +0100." <20020312140256.A13417@cdc.informatik.tu-darmstadt.de> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 12 Mar 2002 10:26:34 -0500 Message-Id: <20020312152640.2E12D2A4A@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > What about the attack described in Appendix C of > , which appears to be > applicable to the SSH binary packet protocol as specified in > draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or > counter mode is used)? Now that I've had some caffeine -- there's another reason why this attack can't work for SSH. The appendix C attack works only if the IV is carried with each message -- each message is independant, with no initial state other than the key. This is emphatically not the case for the ssh transport protocol in any of CBC, CFB, OFB, or counter modes. CBC, CFB: With ssh, the IV of message N comes from the last block of message N-1. If the attacker simply substitutes c1 for c1', the first block of c will be garbled due to the wrong IV. If the attacker attempts to substitute the previous cipherblock as well so that the IV's match, this will garble the previous message and cause the connection to drop before the attack can be attempted. OFB, counter mode: The attack simply can't work as described, since the keystream generated by the cipher will be completely different for c and c'; if you substitute c for c', the entire decryption will be garbled. I may be mistaken but in order for the "OTP" version of the attack described in the appendix to be possible, the system under attack would need to be committing a much greater cryptographic sin: that of allowing the reuse of a stream cipher! - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 10:51:54 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25261 for ; Tue, 12 Mar 2002 10:51:54 -0500 (EST) Received: (qmail 23975 invoked by uid 605); 12 Mar 2002 15:51:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23968 invoked from network); 12 Mar 2002 15:51:52 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Mar 2002 15:51:52 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 68F1D83602C for ; Tue, 12 Mar 2002 16:51:47 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id QAA27784; Tue, 12 Mar 2002 16:51:46 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@netbsd.org Subject: Application data during key re-exchange Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 12 Mar 2002 16:51:46 +0100 Message-ID: Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit I'm sorry if this has been discussed before, but I don't remember the outcome. Consider a key re-exchange, and for simplicity, assume we're using the diffie-hellman-group1-sha1 method. This is what happens: Client sends Server sends 1 KEXINIT KEXINIT (in arbitrary order, or simultaneously) 2 KEXDH_INIT 3 KEXDH_REPLY 4 NEWKEYS 5 NEWKEYS Can this message exchange be interleaved with other messages? More precicely, is the server allowed to send other messages between 1 and 3, or between 3 and 4? Is the client allowed to send other messages between 1 and 2, and 2 and 5? My current code allows other messages between 1 and 2/3, but not between 2/3 and 4/5. That doesn't seem quite right. The spec says: : Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. : This message is sent with the old keys and algorithms. All messages : sent after this message MUST use the new keys and algorithms. : : When this message is received, the new keys and algorithms MUST be : taken into use for receiving. : : This message is the only valid message after key exchange, in : addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE : messages. The purpose of this message is to ensure that a party is : able to respond with a disconnect message that the other party can : understand if something goes wrong with the key exchange. : Implementations MUST NOT accept any other messages after key : exchange before receiving SSH_MSG_NEWKEYS. It's not entirely clear what is meant by "after key exchange" in the final paragraph above. My interpretation is "after KEX_DHINIT" (in the stream from the client) and "after KEX_DHREPLY" (in the stream from the server). Another possible interpretation is that the only messages that can be sent between KEXINIT and NEWKEYS are key-exchange messages and DEBUG, DISCONNECT and IGNORE. Then all channels on the connection will freeze completely during the entire key exchange process, which seems undesirable, in particular with slow connections and machines. For client-initiated key exchange, it's two roundtrips. How do you handle this? Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 11:00:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25522 for ; Tue, 12 Mar 2002 11:00:42 -0500 (EST) Received: (qmail 28917 invoked by uid 605); 12 Mar 2002 16:00:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28910 invoked from network); 12 Mar 2002 16:00:41 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 12 Mar 2002 16:00:41 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 512737; Tue, 12 Mar 2002 09:08:24 -0700 Message-ID: <00bc01c1c9de$839ef540$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , =?iso-8859-1?Q?Niels_M=F6ller?= References: Subject: Re: Application data during key re-exchange Date: Tue, 12 Mar 2002 08:56:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > It's not entirely clear what is meant by "after key exchange" in the > final paragraph above. My interpretation is "after KEX_DHINIT" (in the > stream from the client) and "after KEX_DHREPLY" (in the stream from > the server). > > Another possible interpretation is that the only messages that can be > sent between KEXINIT and NEWKEYS are key-exchange messages and DEBUG, > DISCONNECT and IGNORE. Then all channels on the connection will freeze > completely during the entire key exchange process, which seems > undesirable, in particular with slow connections and machines. For > client-initiated key exchange, it's two roundtrips. > > How do you handle this? Our interpretation is between KEXINIT and NEWKEYS nothing is allowed. So after sending a KEXINIT packet, an implementation (client or server) must not send any non-key-exchange packets other than DEBUG, DISCONNECT, and IGNORE until it has sent a NEWKEYS packet. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 11:04:13 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25590 for ; Tue, 12 Mar 2002 11:04:13 -0500 (EST) Received: (qmail 1433 invoked by uid 605); 12 Mar 2002 16:04:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1426 invoked from network); 12 Mar 2002 16:04:11 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 12 Mar 2002 16:04:11 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id RAA14137; Tue, 12 Mar 2002 17:04:07 +0100 (MET) Date: Tue, 12 Mar 2002 17:04:07 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org, Niels =?iso-8859-1?Q?M=F6ller?= Subject: Re: Application data during key re-exchange Message-ID: <20020312160407.GB9767@faui02> References: <00bc01c1c9de$839ef540$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bc01c1c9de$839ef540$2800a8c0@test.vandyke.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 12, 2002 at 08:56:46AM -0700, Joseph Galbraith wrote: > Our interpretation is between KEXINIT and NEWKEYS > nothing is allowed. So after sending a KEXINIT > packet, an implementation (client or server) > must not send any non-key-exchange packets > other than DEBUG, DISCONNECT, and IGNORE until > it has sent a NEWKEYS packet. Yes, this is what OpenSSH does (or tries). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 11:04:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25603 for ; Tue, 12 Mar 2002 11:04:31 -0500 (EST) Received: (qmail 1780 invoked by uid 605); 12 Mar 2002 16:04:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1773 invoked from network); 12 Mar 2002 16:04:29 -0000 Received: from cdc-info.cdc.informatik.tu-darmstadt.de (130.83.23.100) by mail.netbsd.org with SMTP; 12 Mar 2002 16:04:29 -0000 Received: from cdc-ws13.cdc.informatik.tu-darmstadt.de (cdc-ws13 [130.83.23.73]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 92F2C2C91; Tue, 12 Mar 2002 17:04:23 +0100 (MET) Received: (from moeller@localhost) by cdc-ws13.cdc.informatik.tu-darmstadt.de (8.10.2+Sun/8.10.2) id g2CG4M214404; Tue, 12 Mar 2002 17:04:22 +0100 (MET) Date: Tue, 12 Mar 2002 17:04:22 +0100 From: Bodo Moeller To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020312170422.A14389@cdc.informatik.tu-darmstadt.de> References: <20020312152640.2E12D2A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020312152640.2E12D2A4A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Tue, Mar 12, 2002 at 10:26:34AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Tue, Mar 12, 2002 at 10:26:34AM -0500, Bill Sommerfeld wrote: >> What about the attack described in Appendix C of >> , which appears to be >> applicable to the SSH binary packet protocol as specified in >> draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or >> counter mode is used)? > The appendix C attack works only if the IV is carried with each > message -- each message is independant, with no initial state other > than the key. > > This is emphatically not the case for the ssh transport protocol in > any of CBC, CFB, OFB, or counter modes. Yes, you are right. For any given record in the stream, after processing the previous record has been completed, the mapping between ciphertexts and plaintexts is bijective. Thus it is not possible to substitute a different ciphertext corresponding to the same plaintext because there *is* no different ciphertext corresponding to the same plaintext. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 11:25:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26206 for ; Tue, 12 Mar 2002 11:25:55 -0500 (EST) Received: (qmail 13114 invoked by uid 605); 12 Mar 2002 16:25:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13107 invoked from network); 12 Mar 2002 16:25:53 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 12 Mar 2002 16:25:53 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 6E92D2709; Tue, 12 Mar 2002 11:25:53 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 479FC2A4A; Tue, 12 Mar 2002 11:25:53 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 3BB6F1FE8; Tue, 12 Mar 2002 11:25:53 -0500 (EST) From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Cc: ietf-ssh@netbsd.org Subject: Re: Application data during key re-exchange In-Reply-To: Message from nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) of "12 Mar 2002 16:51:46 +0100." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 12 Mar 2002 11:25:47 -0500 Message-Id: <20020312162553.479FC2A4A@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list I simply don't see this as a showstopper. > Then all channels on the connection will freeze > completely during the entire key exchange process, which seems > undesirable, in particular with slow connections and machines. In many cases, the same sort of "freeze" will often happen if a TCP segment is dropped (particularly when the traffic flow is character-at-a-time interactive traffic); tcp falls back to the retransmission timeout, which is typically several hundred ms. Over a high latency path, you'll probably get more than one TCP segment drop per hour. Will the end user be able to tell the difference between rekey and dropped packets? Worrying too much about slow machines is historically not a good use of people's engineering efforts. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 12:10:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27706 for ; Tue, 12 Mar 2002 12:10:47 -0500 (EST) Received: (qmail 11135 invoked by uid 605); 12 Mar 2002 17:10:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10864 invoked from network); 12 Mar 2002 17:10:20 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 12 Mar 2002 17:10:20 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g2CH1uV11552 for ietf-ssh@netbsd.org; Tue, 12 Mar 2002 09:01:56 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Core draft last call update. Date: 12 Mar 2002 17:01:56 GMT Organization: University of California, Berkeley Lines: 16 Distribution: isaac Message-ID: References: <20020312145300.C17672A4A@orchard.arlington.ma.us> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1015952516 11336 128.32.45.153 (12 Mar 2002 17:01:56 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 12 Mar 2002 17:01:56 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Bill Sommerfeld wrote: >This attack has greatly increased difficulty for SSH because the SSH >MAC also covers the random pad at the end of the message. As a >result, you can only tell if m and m' are identical if the random >padding appended by the sender is identical. Do all implementations use truly random padding? It wasn't clear to me from the draft that the randomness of the padding is security-critical, so I could easily imagine as an optimization using not-very-random randomness for the padding if I were implementing. But maybe I missed something, or maybe it was more obvious to others. Would it be prudent to make the draft say that the padding MUST use high-quality randomness, and to describe the security threat so that implementors are less likely to fall into this trap? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 13:05:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29510 for ; Tue, 12 Mar 2002 13:05:58 -0500 (EST) Received: (qmail 11777 invoked by uid 605); 12 Mar 2002 18:05:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11770 invoked from network); 12 Mar 2002 18:05:54 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 12 Mar 2002 18:05:54 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g2CHvUa12134 for ietf-ssh@netbsd.org; Tue, 12 Mar 2002 09:57:30 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Core draft last call update. Date: 12 Mar 2002 17:57:30 GMT Organization: University of California, Berkeley Lines: 6 Distribution: isaac Message-ID: References: <20020312145300.C17672A4A@orchard.arlington.ma.us> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1015955850 12065 128.32.45.153 (12 Mar 2002 17:57:30 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 12 Mar 2002 17:57:30 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list David Wagner wrote: >Do all implementations use truly random padding? [...] Please ignore my message. I overlooked some remaining messages, and thus this message is irrelevant. (Thanks to Bill Sommerfeld for gently pointing this out.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 13:38:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00657 for ; Tue, 12 Mar 2002 13:38:49 -0500 (EST) Received: (qmail 27836 invoked by uid 605); 12 Mar 2002 18:38:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27829 invoked from network); 12 Mar 2002 18:38:46 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Mar 2002 18:38:46 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 4C1D1835E98; Tue, 12 Mar 2002 19:38:45 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id TAA27893; Tue, 12 Mar 2002 19:38:44 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Markus Friedl Cc: Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: Application data during key re-exchange References: <00bc01c1c9de$839ef540$2800a8c0@test.vandyke.com> <20020312160407.GB9767@faui02> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 12 Mar 2002 19:38:43 +0100 In-Reply-To: <20020312160407.GB9767@faui02> Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > On Tue, Mar 12, 2002 at 08:56:46AM -0700, Joseph Galbraith wrote: > > Our interpretation is between KEXINIT and NEWKEYS > > nothing is allowed. So after sending a KEXINIT > > packet, an implementation (client or server) > > must not send any non-key-exchange packets > > other than DEBUG, DISCONNECT, and IGNORE until > > it has sent a NEWKEYS packet. > > Yes, this is what OpenSSH does (or tries). Ok, I guess I just have to do the same then. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 13:51:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01273 for ; Tue, 12 Mar 2002 13:51:04 -0500 (EST) Received: (qmail 4281 invoked by uid 605); 12 Mar 2002 18:50:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4235 invoked from network); 12 Mar 2002 18:50:53 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Mar 2002 18:50:53 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 286F0835BD3; Tue, 12 Mar 2002 19:50:50 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id TAA27896; Tue, 12 Mar 2002 19:50:49 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@orchard.arlington.ma.us Cc: ietf-ssh@netbsd.org Subject: Re: Application data during key re-exchange References: <20020312162553.479FC2A4A@orchard.arlington.ma.us> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 12 Mar 2002 19:50:48 +0100 In-Reply-To: <20020312162553.479FC2A4A@orchard.arlington.ma.us> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > I simply don't see this as a showstopper. The primary reason my current code behaves the way it does is that it was a lot simpler, and I didn't see any security reasons to disallow other messages during key re-exchange, not that I have experienced freezes during key re-exchange and found them unacceptable. While waiting for the remote end to do its part of the key (re)exchange, my code spends its time in its select loop. When events occur (say, the user typed some characters, or a shell died and sent SIGCHLD to the server), ssh messages are generated and they are encrypted and put into the same write queue as all other messages on that connection. To get this right, and make sure I never send any application messages during key exchange, I will have to introduce another queue where any "application" messages generated during key key-exchange are put, to be sent after the keyexchange is finished. And I must also arrange that I temporarily stop reading channel sources that can generate a lot of data, to keep the size of the new queue from growing large. Not a big deal, but it makes the code more complex. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 17:26:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10372 for ; Tue, 12 Mar 2002 17:26:37 -0500 (EST) Received: (qmail 23362 invoked by uid 605); 12 Mar 2002 22:26:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23350 invoked from network); 12 Mar 2002 22:26:32 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 12 Mar 2002 22:26:32 -0000 Received: from localhost (dsl-213-023-029-117.arcor-ip.net [213.23.29.117]) by mx04.nexgo.de (Postfix) with ESMTP id 4CE7737B06; Tue, 12 Mar 2002 23:26:31 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 839C0442B; Tue, 12 Mar 2002 23:26:09 +0100 (CET) Date: Tue, 12 Mar 2002 23:26:09 +0100 From: Markus Friedl To: Joseph Galbraith Cc: sommerfeld@east.sun.com, =?iso-8859-1?Q?Niels_M=F6ller?= , Derek Fawcus , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020312232608.D28682@folly> References: <200203081957.g28JvdUZ018322@ack.east.sun.com> <006901c1c924$2cb83580$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <006901c1c924$2cb83580$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Mon, Mar 11, 2002 at 10:42:15AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 11, 2002 at 10:42:15AM -0700, Joseph Galbraith wrote: > > BTW, which implementations set the first_kex_packet_follows flag in > > the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before > > trying to optimize away some more roundtrips. > > I believe SSH Communications is the only > implementation using this, but I'm not sure. Who understands how first_kex_packet_follows is supposed to work? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 17:31:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10484 for ; Tue, 12 Mar 2002 17:31:25 -0500 (EST) Received: (qmail 25747 invoked by uid 605); 12 Mar 2002 22:31:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25711 invoked from network); 12 Mar 2002 22:31:06 -0000 Received: from mx01.nexgo.de (151.189.8.96) by mail.netbsd.org with SMTP; 12 Mar 2002 22:31:06 -0000 Received: from localhost (dsl-213-023-029-117.arcor-ip.net [213.23.29.117]) by mx01.nexgo.de (Postfix) with ESMTP id E15C33BC7F; Tue, 12 Mar 2002 23:31:04 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 002EF442B; Tue, 12 Mar 2002 23:30:33 +0100 (CET) Date: Tue, 12 Mar 2002 23:30:31 +0100 From: Markus Friedl To: David Wagner Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020312233031.E28682@folly> References: <20020309152655.A9FB22A4A@orchard.arlington.ma.us> <20020310213849.B7020@eskimo.com> <20020311090906.GA7925@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from daw@mozart.cs.berkeley.edu on Mon, Mar 11, 2002 at 09:22:05AM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 11, 2002 at 09:22:05AM +0000, David Wagner wrote: > Markus Friedl wrote: > >As to CTR: AFAIK in CTR mode the handling, formating of the counter > >needs some work before we can agree, e.g the proposal for aes128-ctr in > >IPsec makes size(ciphertext) != size(plaintext), so CTR should not be > >added now, because it will delay the process significantly. > > > >So, if we would need a spec for OFB/CFB (with cipher block-sized > >feedback) soon. > > Hmm. I must admit I'm a little confused: what are the reasons to > prefer OFB mode over CTR mode? Are there some security reasons? Is it > something else? I don't see anything terribly wrong with OFB mode, > but I'd like to understand why it is preferred over CTR mode. my point is that for CTR there is no common format (e.g. how is the counter encoded, etc) whereas a spec for OFB mode is simpler. > P.S. I assumed that if there is a known security weakness, it would be > disclosed in the RFC, so I'm surprised that you consider it a bad thing to > have a paragraph describing the weakness. i think it's bad to have such a paragraph without offering alternative cipher modes. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 17:32:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10527 for ; Tue, 12 Mar 2002 17:32:19 -0500 (EST) Received: (qmail 27323 invoked by uid 605); 12 Mar 2002 22:32:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27316 invoked from network); 12 Mar 2002 22:32:17 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 12 Mar 2002 22:32:17 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06868 for ; Tue, 12 Mar 2002 15:32:17 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10492 for ; Tue, 12 Mar 2002 17:32:16 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2CMVBgw013324 for ; Tue, 12 Mar 2002 17:31:11 -0500 (EST) Message-Id: <200203122231.g2CMVBgw013324@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: working group last call is complete. Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Mar 2002 17:31:11 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list We've now reached the defined end of the last call period. At this point, my sense is that no respin of the documents is necessary. The next step in the process is for me to send the documents to the area director in order to initiate an IETF-wide last call. Issues raised during working group last call: - Wei Dai: There is a known-IV chosen-plaintext attack allowing plaintext-guess-verification attack possible against many protocols using CBC based symmetric encryption modes, including SSH. Proposed resolution: This is a flaw in CBC mode, not a flaw in the SSH protocol itself. Details of how ssh does message framing seem to indicate that the attack will be extremely difficult in practice. The WG will investigate other encryption modes, but no technical document change is appropriate at this stage, as the problem can be fixed by defining new symmetric encryption types, which can easily be done in a new draft. If we come to consensus on a warning or disclaimer regarding the CBC modes we can insert additional text in one of the core documents as part of the RFC editor process. - Mats Andersson: existing text regarding certificates needs still more wordsmithing. Proposed resolution: during the previous last call, the WG concluded that certificate handling should be be described in a separate document. When that document exists, it can supply any necessary clarifications; there's correspondingly no need to respin the core drafts at this time. - Derek Fawcus: suggestion to allow optimistic sending of post-userauth messages before the server accepts authentication. Proposed resolution: as this is just an optimization (reducing round trip delays at connection setup time), we can defer any work in this area. Several issues were raised but withdrawn: - Bodo Moeller: potential cipherblock subsitution attack from Hugo K. paper. Withdrawn since it doesn't actually apply to SSH because of IV chaining. - Niels Moeller: request to change handling of rekey to allow interleaving of rekey and user messages. Not showstopper for now; apparently withdrawn. This is another optimization which we can add later. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 18:56:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12623 for ; Tue, 12 Mar 2002 18:56:39 -0500 (EST) Received: (qmail 22890 invoked by uid 605); 12 Mar 2002 23:56:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22883 invoked from network); 12 Mar 2002 23:56:36 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 12 Mar 2002 23:56:36 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06059 for ; Tue, 12 Mar 2002 16:56:35 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00939 for ; Tue, 12 Mar 2002 18:56:35 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2CNtUgw014157 for ; Tue, 12 Mar 2002 18:55:30 -0500 (EST) Message-Id: <200203122355.g2CNtUgw014157@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Please review draft-ietf-secsh-agent-00.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Mar 2002 18:55:30 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I'd like the working group to review draft-ietf-secsh-agent-00.txt in detail before the next IETF meeting (next week) so we can get an idea of how much work it needs and how close it is to done. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 19:15:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12956 for ; Tue, 12 Mar 2002 19:15:11 -0500 (EST) Received: (qmail 1572 invoked by uid 605); 13 Mar 2002 00:15:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1458 invoked from network); 13 Mar 2002 00:15:07 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 13 Mar 2002 00:15:07 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 513729; Tue, 12 Mar 2002 17:22:54 -0700 Message-ID: <020601c1ca23$97b433c0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Markus Friedl" Cc: , =?iso-8859-1?Q?Niels_M=F6ller?= , "Derek Fawcus" , References: <200203081957.g28JvdUZ018322@ack.east.sun.com> <006901c1c924$2cb83580$2800a8c0@test.vandyke.com> <20020312232608.D28682@folly> Subject: Re: Core draft last call update. Date: Tue, 12 Mar 2002 17:11:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > On Mon, Mar 11, 2002 at 10:42:15AM -0700, Joseph Galbraith wrote: > > > BTW, which implementations set the first_kex_packet_follows flag in > > > the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before > > > trying to optimize away some more roundtrips. > > > > I believe SSH Communications is the only > > implementation using this, but I'm not sure. > > Who understands how first_kex_packet_follows is supposed to work? I believe that the draft is accurate now (it wasn't for a long time.) Looking at the draft now, I could wish that the description guessing and when the guess was wrong was grouped with the first_kex_packet_follows instead of up above. If the first_kex_packet_follows flag is set, and the first item on the clients list for public key or for key exchange method does not match the first item on the server list, the next packet should be discarded as invalid. If key exchange doesn't match, then it is a packet for a key exchange method that will not be run; and in theory, the hostkey/public key type could affect the first packet sent, so this makes sense. On the other hand, I'm less than 100% fond of this feature -- it seems to add quite a bit of complexity for a relatively small performance gain. But I don't want to change it now :-) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 12 19:42:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13578 for ; Tue, 12 Mar 2002 19:42:03 -0500 (EST) Received: (qmail 17539 invoked by uid 605); 13 Mar 2002 00:42:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17529 invoked from network); 13 Mar 2002 00:42:00 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 13 Mar 2002 00:42:00 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA21037 for ietf-ssh@netbsd.org; Wed, 13 Mar 2002 00:39:07 GMT Date: Wed, 13 Mar 2002 00:39:07 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Please review draft-ietf-secsh-agent-00.txt Message-ID: <20020313003907.B17072@edinburgh.cisco.com> References: <200203122355.g2CNtUgw014157@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200203122355.g2CNtUgw014157@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Tue, Mar 12, 2002 at 06:55:30PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 12, 2002 at 06:55:30PM -0500, Bill Sommerfeld wrote: > I'd like the working group to review draft-ietf-secsh-agent-00.txt in > detail before the next IETF meeting (next week) so we can get an idea > of how much work it needs and how close it is to done. Hmm. When it was sent out I thougth there had been an error. it seems a bit light on details compared to the information that was mentioned on the list in January. i.e. draft-ietf-secsh-agent-00.txt only contains any info on page 3 (out of 5), and even that seems to just be intoductory text. Are those 8 paragraphs what you want reviewed? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 01:00:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20791 for ; Wed, 13 Mar 2002 01:00:51 -0500 (EST) Received: (qmail 21420 invoked by uid 605); 13 Mar 2002 06:00:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21412 invoked from network); 13 Mar 2002 06:00:47 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 13 Mar 2002 06:00:47 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g2D5qJQ19121 for ietf-ssh@netbsd.org; Tue, 12 Mar 2002 21:52:19 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Core draft last call update. Date: 13 Mar 2002 05:52:19 GMT Organization: University of California, Berkeley Lines: 23 Distribution: isaac Message-ID: References: <20020311090906.GA7925@faui02> <20020312233031.E28682@folly> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1015998739 18930 128.32.45.153 (13 Mar 2002 05:52:19 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 13 Mar 2002 05:52:19 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl wrote: >my point is that for CTR there is no common format (e.g. >how is the counter encoded, etc) whereas a spec for OFB mode >is simpler. That's easily fixed, and I'd gladly volunteer to help. Is this really the only barrier to getting a fix in place? >On Mon, Mar 11, 2002 at 09:22:05AM +0000, David Wagner wrote: >> P.S. I assumed that if there is a known security weakness, it would be >> disclosed in the RFC, so I'm surprised that you consider it a bad thing to >> have a paragraph describing the weakness. > >i think it's bad to have such a paragraph without offering >alternative cipher modes. I admit I don't understand. I come from a philosophy that says you disclose what you know about the security properties of the protocol, both positive and negative: truth in advertising. If the decision is that fixing this weakness is too costly at present, that's one thing; avoiding all mention of it is another. What's gained by hiding the facts from implementors and readers of the RFC? Can you help me understand the rationale behind such a stance? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 02:40:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29752 for ; Wed, 13 Mar 2002 02:40:06 -0500 (EST) Received: (qmail 11247 invoked by uid 605); 13 Mar 2002 07:39:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11232 invoked from network); 13 Mar 2002 07:39:51 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 13 Mar 2002 07:39:51 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 4E2353BD08; Wed, 13 Mar 2002 08:39:49 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 26C7A6C007; Wed, 13 Mar 2002 08:39:51 +0100 (MET) Date: Wed, 13 Mar 2002 08:38:32 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Niels =?iso-8859-1?q?M=F6ller?= Cc: Subject: Re: Application data during key re-exchange In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8BIT On 12 Mar 2002, Niels Möller wrote: > Another possible interpretation is that the only messages that can be > sent between KEXINIT and NEWKEYS are key-exchange messages and DEBUG, > DISCONNECT and IGNORE. Then all channels on the connection will freeze > completely during the entire key exchange process, which seems > undesirable, in particular with slow connections and machines. For This is my interpretation. And how our implementation works (seems cleanest doesn't it?). In our case it's also the most sensible thing to do to disallow traffic from higher layers during keyexchange since we have a multi-threaded implementation which would end up more complex and with some extra unnecessary synchronization (i.e. checks for keyexchange in progress). Given that the key-reexchange comes once an hour (or after one GB data) it doesn't seem much of an issue IMHO. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 03:05:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00075 for ; Wed, 13 Mar 2002 03:05:09 -0500 (EST) Received: (qmail 28424 invoked by uid 605); 13 Mar 2002 08:05:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28417 invoked from network); 13 Mar 2002 08:05:03 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 13 Mar 2002 08:05:03 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id C14463BD08; Wed, 13 Mar 2002 09:05:01 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 4BBFB6C0D7; Wed, 13 Mar 2002 09:05:03 +0100 (MET) Date: Wed, 13 Mar 2002 09:03:43 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Markus Friedl Cc: Joseph Galbraith , , =?iso-8859-1?Q?Niels_M=F6ller?= , Derek Fawcus , Subject: Re: Core draft last call update. In-Reply-To: <20020312232608.D28682@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 12 Mar 2002, Markus Friedl wrote: > > > BTW, which implementations set the first_kex_packet_follows flag in > > > the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before > > > > I believe SSH Communications is the only > > Who understands how first_kex_packet_follows is supposed to work? I've not used it and haven't contemplated it much though my interpretation (implementation) of it is: wrongguess = " o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 5.1)." if(wronguess && first_kex_packet_follows) { } E.g. a guessing client just sends SSH_MSG_KEXDH_INIT directly after SSH_MSG_KEXINIT, if it discovers that this is wrong (according to above) it knows that it can safely just retransmit some other KEX method's init. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 03:22:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00236 for ; Wed, 13 Mar 2002 03:22:07 -0500 (EST) Received: (qmail 8767 invoked by uid 605); 13 Mar 2002 08:21:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8736 invoked from network); 13 Mar 2002 08:21:58 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 13 Mar 2002 08:21:58 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 1385A3BD08; Wed, 13 Mar 2002 09:21:57 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 3D8196C0D7; Wed, 13 Mar 2002 09:21:59 +0100 (MET) Date: Wed, 13 Mar 2002 09:20:38 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Bill Sommerfeld Cc: Subject: Re: Please review draft-ietf-secsh-agent-00.txt In-Reply-To: <200203122355.g2CNtUgw014157@thunk.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 12 Mar 2002, Bill Sommerfeld wrote: > I'd like the working group to review draft-ietf-secsh-agent-00.txt in > detail before the next IETF meeting (next week) so we can get an idea > of how much work it needs and how close it is to done. It must have been accidentally cut somewhere in the process, it doesn't seem to me to be something that can be implemented from reading the text? Or have I missed something here? Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 03:37:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00400 for ; Wed, 13 Mar 2002 03:37:50 -0500 (EST) Received: (qmail 15988 invoked by uid 605); 13 Mar 2002 08:37:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15981 invoked from network); 13 Mar 2002 08:37:48 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 13 Mar 2002 08:37:48 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA00118; Wed, 13 Mar 2002 09:37:43 +0100 (MET) Date: Wed, 13 Mar 2002 09:37:43 +0100 From: Markus Friedl To: David Wagner Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020313083742.GA29625@faui02> References: <20020311090906.GA7925@faui02> <20020312233031.E28682@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 05:52:19AM +0000, David Wagner wrote: > Markus Friedl wrote: > I admit I don't understand. I come from a philosophy that says > you disclose what you know about the security properties of the > protocol, both positive and negative: truth in advertising. If > the decision is that fixing this weakness is too costly at present, > that's one thing; avoiding all mention of it is another. What's > gained by hiding the facts from implementors and readers of the RFC? > Can you help me understand the rationale behind such a stance? Oops, this is not my intention: I think it's better to offer alternatives in the RFC. If we want to offer alternative reaching consens on OFB and CFB is faster, especially since many installations/implementations already support these. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 12:53:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12979 for ; Wed, 13 Mar 2002 12:53:48 -0500 (EST) Received: (qmail 21744 invoked by uid 605); 13 Mar 2002 17:53:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21712 invoked from network); 13 Mar 2002 17:53:29 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2002 17:53:29 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15087; Wed, 13 Mar 2002 10:53:28 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13501; Wed, 13 Mar 2002 12:53:27 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2DHqLgw021887; Wed, 13 Mar 2002 12:52:21 -0500 (EST) Message-Id: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> From: Bill Sommerfeld To: daw@mozart.cs.berkeley.edu (David Wagner) cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Your message of "13 Mar 2002 05:52:19 GMT." Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 12:52:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > >my point is that for CTR there is no common format (e.g. > >how is the counter encoded, etc) whereas a spec for OFB mode > >is simpler. > > That's easily fixed, and I'd gladly volunteer to help. Is this > really the only barrier to getting a fix in place? To quote Randy Bush: "Please Send Draft" - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 18:14:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24157 for ; Wed, 13 Mar 2002 18:14:11 -0500 (EST) Received: (qmail 21988 invoked by uid 605); 13 Mar 2002 23:14:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21981 invoked from network); 13 Mar 2002 23:14:09 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 13 Mar 2002 23:14:09 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id PAA29811; Wed, 13 Mar 2002 15:14:07 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id PAA26668; Wed, 13 Mar 2002 15:14:08 -0800 (PST) Date: Wed, 13 Mar 2002 15:14:07 -0800 From: Wei Dai To: Bill Sommerfeld Cc: David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020313151407.A25360@eskimo.com> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Wed, Mar 13, 2002 at 12:52:21PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 12:52:21PM -0500, Bill Sommerfeld wrote: > > >my point is that for CTR there is no common format (e.g. > > >how is the counter encoded, etc) whereas a spec for OFB mode > > >is simpler. > > > > That's easily fixed, and I'd gladly volunteer to help. Is this > > really the only barrier to getting a fix in place? > > To quote Randy Bush: > > "Please Send Draft" What about the proposed language I sent earlier? It already specifies everything needed for CTR mode. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 18:34:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24564 for ; Wed, 13 Mar 2002 18:34:55 -0500 (EST) Received: (qmail 1971 invoked by uid 605); 13 Mar 2002 23:34:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1915 invoked from network); 13 Mar 2002 23:34:51 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 13 Mar 2002 23:34:51 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19564; Wed, 13 Mar 2002 15:34:43 -0800 (PST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20793; Wed, 13 Mar 2002 18:34:42 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2DNXYgw026800; Wed, 13 Mar 2002 18:33:34 -0500 (EST) Message-Id: <200203132333.g2DNXYgw026800@thunk.East.Sun.COM> From: Bill Sommerfeld To: Wei Dai cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Your message of "Wed, 13 Mar 2002 15:14:07 PST." <20020313151407.A25360@eskimo.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 18:33:34 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > What about the proposed language I sent earlier? It already specifies > everything needed for CTR mode. It needs to be turned into a stand-alone internet-draft. > For any cipher in CTR mode, the counter used to encrypt each plaintext > block MUST be the IV if no previous plaintext block exists, or C+1 mod 2^N > where C is the counter used to encrypt the previous block, and N is the > block size of the cipher in bits. Network order SHOULD be used to convert > the counter between its octet string form and its integer form for the > computation of C+1 mod 2^N. so: The size of the IV is left unspecified. The text "the counter used to encrypt each plaintext block" is unspecified, and could mean any of: C[n] = ECB-Encrypt(ctr++, P[n]); C[n] = P[n] ^ ECB-Encrypt(K, ctr++); C[n] = P[n] ^ ctr++; Also left underspecified is the block size of the mode (i.e., in terms of how the transport layer pads out messages to the block size); fundamentally there's no reason why this has to be the same as the underlying cipher block size, but if they're different, you need to specify whether or not partial blocks get carried over from message to message. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 18:52:54 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24969 for ; Wed, 13 Mar 2002 18:52:54 -0500 (EST) Received: (qmail 11963 invoked by uid 605); 13 Mar 2002 23:52:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11956 invoked from network); 13 Mar 2002 23:52:50 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 13 Mar 2002 23:52:50 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09226 for ; Wed, 13 Mar 2002 16:52:50 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23538 for ; Wed, 13 Mar 2002 18:52:49 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2DNpggw026980 for ; Wed, 13 Mar 2002 18:51:42 -0500 (EST) Message-Id: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG LAST CALL: SECSH Public Key File Format Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 18:51:41 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is the start of a working group LAST CALL on: draft-ietf-secsh-publickeyfile-02.txt SECSH Public Key File Format Last Call on this document expires in three weeks, on 3 April 2002 (I'm giving it an extra week due to the upcoming IETF week). Send comments on the document to ietf-ssh@netbsd.org Discussion question for the working group: Should this be advanced as Informational or as a Standards Track document? It could go either way -- it's not a "wire protocol" per se but it does describe a blob of data which can be exchanged (out of band) between implementations. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 18:54:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25013 for ; Wed, 13 Mar 2002 18:54:22 -0500 (EST) Received: (qmail 13164 invoked by uid 605); 13 Mar 2002 23:54:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13098 invoked from network); 13 Mar 2002 23:54:09 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2002 23:54:09 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01656 for ; Wed, 13 Mar 2002 16:54:08 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23761 for ; Wed, 13 Mar 2002 18:54:08 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2DNr0gw027009 for ; Wed, 13 Mar 2002 18:53:00 -0500 (EST) Message-Id: <200203132353.g2DNr0gw027009@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG LAST CALL: Diffie-Hellman Group Exchange Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 18:53:00 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is the start of a working group LAST CALL on: draft-ietf-secsh-dh-group-exchange-02.txt Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol Last Call on this document expires in three weeks, on 3 April 2002 (I'm giving it an extra week due to the upcoming IETF week). Send comments on the document to ietf-ssh@netbsd.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 18:55:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25075 for ; Wed, 13 Mar 2002 18:55:34 -0500 (EST) Received: (qmail 15383 invoked by uid 605); 13 Mar 2002 23:55:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15365 invoked from network); 13 Mar 2002 23:55:21 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 13 Mar 2002 23:55:21 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02030 for ; Wed, 13 Mar 2002 16:55:20 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23918 for ; Wed, 13 Mar 2002 18:55:19 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2DNsCgw027032 for ; Wed, 13 Mar 2002 18:54:12 -0500 (EST) Message-Id: <200203132354.g2DNsCgw027032@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: WG LAST CALL: Generic Message Exchange Authentication for SSH Reply-to: sommerfeld@east.sun.com Date: Wed, 13 Mar 2002 18:54:12 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is the start of a working group LAST CALL on: draft-ietf-secsh-auth-kbdinteract-02.txt Generic Message Exchange Authentication For SSH Last Call on this document expires in three weeks, on 3 April 2002 (I'm giving it an extra week due to the upcoming IETF week). Send comments on the document to ietf-ssh@netbsd.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 20:43:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26899 for ; Wed, 13 Mar 2002 20:43:50 -0500 (EST) Received: (qmail 20960 invoked by uid 605); 14 Mar 2002 01:43:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20949 invoked from network); 14 Mar 2002 01:43:46 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 14 Mar 2002 01:43:46 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16713 for ; Wed, 13 Mar 2002 18:43:45 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08703 for ; Wed, 13 Mar 2002 20:43:45 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2E1gbgw028441 for ; Wed, 13 Mar 2002 20:42:37 -0500 (EST) Message-Id: <200203140142.g2E1gbgw028441@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: The rest of the drafts.. Date: Wed, 13 Mar 2002 20:42:37 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list I just issued WG last calls on three extension drafts. At this point, I think the rest of the drafts are not yet ready to last-call. Let me know if you think I got any of these wrong.. draft-ietf-secsh-gsskeyex-03.txt GSSAPI Authentication and Key Exchange for the Secure Shell Protocol status: author says "needs a few more tweaks". draft-ietf-secsh-filexfer-02.txt SSH File Transfer Protocol status: does not seem ready for prime time based on the nature of discussion on the list. draft-ietf-secsh-dns-key-format-00.txt Storing SSH Host Keys in DNS status: authors are thinking hard about the problem. please attend the siked BOF. draft-ietf-secsh-agent-00.txt SSH Agent Forwarding status: document is incomplete, and needs more "meat". - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 21:18:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27345 for ; Wed, 13 Mar 2002 21:18:38 -0500 (EST) Received: (qmail 12441 invoked by uid 605); 14 Mar 2002 02:18:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12434 invoked from network); 14 Mar 2002 02:18:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 14 Mar 2002 02:18:36 -0000 Received: from [192.168.0.3] (HELO bhag2) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 515619 for ietf-ssh@netbsd.org; Wed, 13 Mar 2002 19:26:24 -0700 Message-ID: <00b801c1cafe$ae8c78b0$0201a8c0@bhag2> From: "Jeff P. Van Dyke" To: References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> Subject: Re: WG LAST CALL: SECSH Public Key File Format Date: Wed, 13 Mar 2002 19:10:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > This is the start of a working group LAST CALL on: > > draft-ietf-secsh-publickeyfile-02.txt > SECSH Public Key File Format > > Last Call on this document expires in three weeks, on 3 April 2002 > (I'm giving it an extra week due to the upcoming IETF week). > > Send comments on the document to ietf-ssh@netbsd.org > > Discussion question for the working group: Should this be advanced as > Informational or as a Standards Track document? It could go either > way -- it's not a "wire protocol" per se but it does describe a blob > of data which can be exchanged (out of band) between implementations. Personally, I'd like to see it go "Standards Track". Jeff P. Van Dyke jpv@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 21:32:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27527 for ; Wed, 13 Mar 2002 21:32:25 -0500 (EST) Received: (qmail 25056 invoked by uid 605); 14 Mar 2002 02:32:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24999 invoked from network); 14 Mar 2002 02:32:05 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 Mar 2002 02:32:05 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id SAA07891; Wed, 13 Mar 2002 18:32:02 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id SAA09911; Wed, 13 Mar 2002 18:32:02 -0800 (PST) Date: Wed, 13 Mar 2002 18:32:02 -0800 From: Wei Dai To: Bill Sommerfeld Cc: David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020313183202.A4967@eskimo.com> References: <20020313151407.A25360@eskimo.com> <200203132333.g2DNXYgw026800@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203132333.g2DNXYgw026800@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Wed, Mar 13, 2002 at 06:33:34PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 06:33:34PM -0500, Bill Sommerfeld wrote: > It needs to be turned into a stand-alone internet-draft. Why? > > For any cipher in CTR mode, the counter used to encrypt each plaintext > > block MUST be the IV if no previous plaintext block exists, or C+1 mod 2^N > > where C is the counter used to encrypt the previous block, and N is the > > block size of the cipher in bits. Network order SHOULD be used to convert > > the counter between its octet string form and its integer form for the > > computation of C+1 mod 2^N. > > so: > > The size of the IV is left unspecified. Ok, add this sentence to the end of 5.2: For block cipher based algorithms with variable-length IVs, the IV length SHOULD be the block size of the underlying block cipher. > The text "the counter used to encrypt each plaintext block" is > unspecified, and could mean any of: > > C[n] = ECB-Encrypt(ctr++, P[n]); > C[n] = P[n] ^ ECB-Encrypt(K, ctr++); > C[n] = P[n] ^ ctr++; Ok, add this reference to the first mention of CTR: [SP800-38A] "Recommendation for Block Cipher Modes of Operation", United States of American, National Institute of Science and Technology, NIST Special Publication 800-38A 2001 Edition, December 2001. > Also left underspecified is the block size of the mode (i.e., in terms > of how the transport layer pads out messages to the block size); > fundamentally there's no reason why this has to be the same as the > underlying cipher block size, but if they're different, you need to > specify whether or not partial blocks get carried over from message to > message. Good point, change the first paragraph under "random padding", section 4: Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size. For ciphers that do not need to process data in blocks (for example stream ciphers and block ciphers in CTR mode), a block size of 8 SHOULD be used for the purpose of determining padding length. And change the phrase "initialization vectors" in second paragraph of section 4.3 to "initialization vectors and unused keystream octets". From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 22:08:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28959 for ; Wed, 13 Mar 2002 22:07:59 -0500 (EST) Received: (qmail 16876 invoked by uid 605); 14 Mar 2002 03:07:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16790 invoked from network); 14 Mar 2002 03:07:57 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 14 Mar 2002 03:07:57 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id F2D992709; Wed, 13 Mar 2002 22:07:56 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 588192A4A; Wed, 13 Mar 2002 21:54:29 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 364C31FE8; Wed, 13 Mar 2002 21:54:29 -0500 (EST) From: Bill Sommerfeld To: Wei Dai Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. In-Reply-To: Message from Wei Dai of "Wed, 13 Mar 2002 18:32:02 PST." <20020313183202.A4967@eskimo.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Wed, 13 Mar 2002 21:54:23 -0500 Message-Id: <20020314025429.588192A4A@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > > It needs to be turned into a stand-alone internet-draft. > > Why? I made a ruling as working group chair that, because (a) the problem could be fixed by a separate document introducing new ciphers, and (b) there clearly did not exist consensus on the a fix, that we should not hold up advancement of the rest of SSH while we attempted to solve the problem. You've missed the train. The core specs are now out of our hands. > block size of the cipher in bits. Network order SHOULD be used to convert s/SHOULD/MUST/. If both sides don't increment the counter in the same way, you won't interoperate. [By comparison, random padding is only a SHOULD since getting it wrong won't break interoperability (but might have subtler ramifications). RFC2119 is quite clear that implementors may ignore SHOULD but they do so only at their own peril. ] > For block cipher based algorithms with variable-length IVs, the IV length > SHOULD be the block size of the underlying block cipher. I think this misses the point. Something like: For counter mode, we use a counter equal in size to the cipher's block size. The first block-size bytes of the "initialization vector" value negotiated by the transport protocol are used to initialize the counter. would be much clearer. > Ok, add this reference to the first mention of CTR: > > [SP800-38A] "Recommendation for Block Cipher Modes of Operation", > United States of American, National Institute of Science and > Technology, NIST Special Publication 800-38A 2001 Edition, December > 2001. I still think the text is confusing and vague. The counter value is not used to encrypt the plaintext. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 23:23:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01227 for ; Wed, 13 Mar 2002 23:23:27 -0500 (EST) Received: (qmail 2281 invoked by uid 605); 14 Mar 2002 04:23:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2274 invoked from network); 14 Mar 2002 04:23:25 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 Mar 2002 04:23:25 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id UAA29528; Wed, 13 Mar 2002 20:23:23 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id UAA14313; Wed, 13 Mar 2002 20:23:22 -0800 (PST) Date: Wed, 13 Mar 2002 20:23:22 -0800 From: Wei Dai To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: a more detailed analysis of "known IV" vulnerability. Message-ID: <20020313202322.D4967@eskimo.com> References: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Mon, Mar 11, 2002 at 04:54:18PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Couple of problems in this analysis: 1. You're assuming that there is only one packet per session that the attacker wants to confirm a guess for. A more conservative figure would be 2^16 target packets per session. 2. By opening 2^24 channels, the attacker can gain control over 8 more bits of the plaintext for 8-byte block size, and 24 more bits for 16-byte block size. Together, these two changes in the analysis imply that an attacker can on average confirm guesses on two packets per session for 8-byte block size. For 16-byte block size, it's once every 2^31 sessions. On Mon, Mar 11, 2002 at 04:54:18PM -0500, Bill Sommerfeld wrote: > [folks, please look this over and let me know if I missed anything..] > > Summary: > > For 64-bit block ciphers in CBC mode, the probability that a given ssh > session key could be exposed to a known-IV chosen-plaintext CBC > guessing attack is somewhere around 1 chance in 2**23 assuming the key > is used for the maximum recommended 1 gigabyte of data. > > Given the one-hour lifetime of ssh session keys, the chance of success > is also influenced by the round trip time between the attacker and the > victim; the 1 chance in 2**23 above assumes a roughly 100microsecond > RTT. A 10ms RTT decreases this to roughly one chance in 2**30. > > To put this in perspective, the chance that a similar 1 gigabyte > session encrypted using CBC mode with a 64-bit block will contain a > pair of duplicate ciphertext blocks (exposing the XOR of the > corresponding plaintext blocks) is about one chance in 2**11. > > With 128-byte-block CBC mode, the attack is much more difficult; the > guessing attack is possible on a session about 1 time in 2**71. > > Details: > > [Note: One thing not considered here is compression, which fits > between the ssh transport and connection layers -- it may allow > additional user-chosen data in the first block, but requires the > attacker to have perfect or near-perfect knowledge of the previous > plaintext in order to allow the state of the compressor to be tracked. > I've chosen to ignore it for now.] > > Given the multilayered message framing in ssh v2, it appears that the > earliest raw user data can appear is 14 bytes into a message; before > that, an attacker can really only influence message lengths. > > Messages in the encrypted stream look like: > > uint32 packet_length > byte padding_length > byte[n1] payload; n1 = packet_length - padding_length - 1 > byte[n2] random padding; n2 = padding_length > byte[m] mac (message authentication code); m = mac_length > > [http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-13.txt] > > However, that's not all that's involved.. the typical 'payload' starts: > > byte SSH_MSG_CHANNEL_DATA > uint32 recipient channel > string data > [http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-15.txt] > > and a "string" in ssh encoding is a is a uint32 N followed by N > bytes.. > [http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-12.txt] > > Assuming a max message length of 64k (a typical implementation limit), > an attacker can, at best, influence 16 bits out of the first 64 bits > of the packet by adjusting the length of the injected message. > > so, rolling it all together, the first 16 bytes would be: > > len3 len2 len1 len0 plen 0x5e chan chan > chan chan sln3 sln2 sln1 sln0 dat0 dat1 > > len is packet length > plen is padding length > chan are the bytes of channel id (small integer) > slen are the string length bytes > dat0 and dat1 are the actual payload being sent to the channel. > > len3/len2 are likely to be zero; high order bits of len1 are likely to > be zero (short messages); the three low order bits of len0 are all > zero (since packets are always a multiple of the block size or 8 > bytes, whichever's larger), though those bits effectively move to the > low order bits of plen.. > > high order bytes of chan are very likely to be zero or at the very > least fixed for a given injection point. > > For an 8-byte block size: > > Of the first 8 bytes, attacker picks at most 16 bits, and has to wait > for the remaining 48 bits of the IV to line up "just so"; i.e., on > average, they have a suitable IV only once every 2**48 messages. > > There's a keychange every gigabyte. Let's assume a minimum message > size of 32 bytes (the sshv2 implementation I use seems to send > slightly larger messages than that, but using power of two makes the > math easier), so that's 2**25 messages per key. > > This means that any given ssh session will be vulnerable to the > message-guessing attack roughly one chance in 2**23. > > For a 16-byte block size: > > attacker controls at most 32 independant bits (the string length and > packet length are going to be interdependant), so suitable IV comes > along only once in 2**96 messages. > > With 2**25 messages per key, this means a session will be vulnerable > at most one chance in 2**71. > > --- > > Effects of the one-hour maximum session key lifetime: > > plaintext insertion -> victim => snoop point =======> peer > ^ | > +--------------------------------+ > > In order to effect the attack, the attacker must trick the attacked > system into generating a large number of messages (in order to > generate as many possible IV's as possible) but must also be able to > react very quickly to inject the chosen plaintext immediately after > the IV appears; this suggests that the attack will be limited by the > round-trip delay around the feedback loop diagrammed above. > > In order to get 2**25 "usable" IV's in an hour, the victim must > generate roughly 9321 packets per second, and the total delay around > the feedback loop (including the processing time on the victim) must > be less than 107 microseconds. > > Increasing the delay will reduce the chance that the session will be > vulnerable. > > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 13 23:28:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01259 for ; Wed, 13 Mar 2002 23:28:44 -0500 (EST) Received: (qmail 4407 invoked by uid 605); 14 Mar 2002 04:28:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4400 invoked from network); 14 Mar 2002 04:28:43 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 14 Mar 2002 04:28:43 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id EAA02925 for ietf-ssh@netbsd.org; Thu, 14 Mar 2002 04:25:50 GMT Date: Thu, 14 Mar 2002 04:25:50 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: WG LAST CALL: SECSH Public Key File Format Message-ID: <20020314042549.C2441@edinburgh.cisco.com> References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200203132351.g2DNpggw026980@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Wed, Mar 13, 2002 at 06:51:41PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 06:51:41PM -0500, Bill Sommerfeld wrote: > This is the start of a working group LAST CALL on: > > draft-ietf-secsh-publickeyfile-02.txt > SECSH Public Key File Format > > Last Call on this document expires in three weeks, on 3 April 2002 > (I'm giving it an extra week due to the upcoming IETF week). > > Send comments on the document to ietf-ssh@netbsd.org > > Discussion question for the working group: Should this be advanced as > Informational or as a Standards Track document? It could go either > way -- it's not a "wire protocol" per se but it does describe a blob > of data which can be exchanged (out of band) between implementations. I'd say Informational. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 00:20:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02192 for ; Thu, 14 Mar 2002 00:20:58 -0500 (EST) Received: (qmail 1489 invoked by uid 605); 14 Mar 2002 05:20:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1481 invoked from network); 14 Mar 2002 05:20:54 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 14 Mar 2002 05:20:54 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA26362; Wed, 13 Mar 2002 21:20:52 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA16302; Wed, 13 Mar 2002 21:20:52 -0800 (PST) Date: Wed, 13 Mar 2002 21:20:51 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020313212051.E4967@eskimo.com> References: <20020314025429.588192A4A@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020314025429.588192A4A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Wed, Mar 13, 2002 at 09:54:23PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 09:54:23PM -0500, Bill Sommerfeld wrote: > I made a ruling as working group chair that, because (a) the problem > could be fixed by a separate document introducing new ciphers, and (b) > there clearly did not exist consensus on the a fix, that we should not > hold up advancement of the rest of SSH while we attempted to solve the > problem. > > You've missed the train. The core specs are now out of our hands. I don't agree with the proposed resolution to the issue I raised. Should I contact the Area Director now or wait for the general Last-Call? > > block size of the cipher in bits. Network order SHOULD be used to convert > > s/SHOULD/MUST/. If both sides don't increment the counter in the same > way, you won't interoperate. I wrote SHOULD in case people want to define their own CTR ciphers and use little endian counters. BTW, what about these two "SHOULD"s in 4.3: The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. If one side doesn't follow these shoulds, it would be an interoperability problem, as well as a security problem. > > For block cipher based algorithms with variable-length IVs, the IV length > > SHOULD be the block size of the underlying block cipher. > > I think this misses the point. Something like: > > For counter mode, we use a counter equal in size to the cipher's > block size. The first block-size bytes of the "initialization > vector" value negotiated by the transport protocol are used to > initialize the counter. > > would be much clearer. > > > Ok, add this reference to the first mention of CTR: > > > > [SP800-38A] "Recommendation for Block Cipher Modes of Operation", > > United States of American, National Institute of Science and > > Technology, NIST Special Publication 800-38A 2001 Edition, December > > 2001. > > I still think the text is confusing and vague. The counter value is > not used to encrypt the plaintext. My assumption is that the implementor already knows what CTR mode is, and we only need to specify the options (i.e. full-size IVs, big-endian counter) that SSH uses. For comparison, there is no explanation of how CBC mode works in the current draft, or even a specific reference for it. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 01:10:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02940 for ; Thu, 14 Mar 2002 01:10:23 -0500 (EST) Received: (qmail 25089 invoked by uid 605); 14 Mar 2002 06:10:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25082 invoked from network); 14 Mar 2002 06:10:20 -0000 Received: from pianosa.catch22.org (64.81.48.19) by mail.netbsd.org with SMTP; 14 Mar 2002 06:10:20 -0000 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 71D4D360; Wed, 13 Mar 2002 22:10:19 -0800 (PST) Date: Wed, 13 Mar 2002 22:10:19 -0800 From: David Terrell To: ietf-ssh@netbsd.org Subject: Re: WG LAST CALL: SECSH Public Key File Format Message-ID: <20020313221019.A7404@pianosa.catch22.org> Reply-To: David Terrell References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> <20020314042549.C2441@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020314042549.C2441@edinburgh.cisco.com>; from dfawcus@cisco.com on Thu, Mar 14, 2002 at 04:25:50AM +0000 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 9:52PM up 27 days, 6 hrs, 44 users, load averages: 0.39, 0.43, 0.40 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 14, 2002 at 04:25:50AM +0000, Derek Fawcus wrote: > On Wed, Mar 13, 2002 at 06:51:41PM -0500, Bill Sommerfeld wrote: > > This is the start of a working group LAST CALL on: > > > > draft-ietf-secsh-publickeyfile-02.txt > > SECSH Public Key File Format > > > > Last Call on this document expires in three weeks, on 3 April 2002 > > (I'm giving it an extra week due to the upcoming IETF week). > > > > Send comments on the document to ietf-ssh@netbsd.org > > > > Discussion question for the working group: Should this be advanced as > > Informational or as a Standards Track document? It could go either > > way -- it's not a "wire protocol" per se but it does describe a blob > > of data which can be exchanged (out of band) between implementations. > > I'd say Informational. I'd lean that way as well. How many file formats are documented as parts of the standards track? Even HTML is only done by the W3C, not the IETF. The only example I know of is the DNS zone file format in 1034/5 and various updates, and recent traffic on namedroppers has expressed regret over that decision. -- David Terrell | "If I had a nickel for every time I've seen a Usenet poster Nebcorp PM | slip in an ostensibly casual reference to how much smarter dbt@meat.net | he/she is than everyone else... why, I'd be able to throw a wwn.nebcorp.com |party for all my Mensa buddies!" -- Miguel Cruz From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 03:36:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12596 for ; Thu, 14 Mar 2002 03:36:44 -0500 (EST) Received: (qmail 4229 invoked by uid 605); 14 Mar 2002 08:36:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4222 invoked from network); 14 Mar 2002 08:36:41 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2002 08:36:41 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA09235; Thu, 14 Mar 2002 09:36:28 +0100 (MET) Date: Thu, 14 Mar 2002 09:36:28 +0100 From: Markus Friedl To: Wei Dai Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020314083628.GB8790@faui02> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020313151407.A25360@eskimo.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 13, 2002 at 03:14:07PM -0800, Wei Dai wrote: > What about the proposed language I sent earlier? It already specifies > everything needed for CTR mode. I don't see a need to rush and consider CTR only, when CFB/OFB is less controversal and already supported by existing implementations. What am I missing? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 04:08:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12917 for ; Thu, 14 Mar 2002 04:08:34 -0500 (EST) Received: (qmail 20897 invoked by uid 605); 14 Mar 2002 09:08:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20890 invoked from network); 14 Mar 2002 09:08:32 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 14 Mar 2002 09:08:32 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA10361; Thu, 14 Mar 2002 10:08:31 +0100 (MET) Date: Thu, 14 Mar 2002 10:08:31 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Cc: Wei Dai , Bill Sommerfeld , David Wagner Subject: Re: Core draft last call update. Message-ID: <20020314090831.GA10042@faui02> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> <20020314083628.GB8790@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314083628.GB8790@faui02> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 14, 2002 at 09:36:28AM +0100, Markus Friedl wrote: > when CFB/OFB is > less controversal and already supported by existing implementations. Additional ciphers The following additional ciphers are defined in output feedback (OFB) mode: 3des-ofb RECOMMENDED three-key 3DES in OFB mode blowfish-ofb RECOMMENDED Blowfish in OFB mode aes256-ofb OPTIONAL AES (Rijndael) in OFB mode, with 256-bit key aes192-ofb OPTIONAL AES with 192-bit key aes128-ofb RECOMMENDED AES with 128-bit key cast128-ofb OPTIONAL CAST-128 in OFB mode These ciphers are block ciphers use the same key setup, block size and IVs as their CBC counterparts, see [SSH-TRANS] for more information. (The IV must be changed if the same encryption key is reused.) The OFB mode is used with full feedback [HANDBOOK-APPLIED-CRYPTO, ISO10116]: "3des-ofb", "blowfish-ofb" and "cast128-ofb" use 64 bit feedback in OFB mode. "aes256-ofb", "aes192-ofb" and "aes128-ofb" use 128 bit feedback in OFB mode. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 05:04:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13936 for ; Thu, 14 Mar 2002 05:04:44 -0500 (EST) Received: (qmail 14530 invoked by uid 605); 14 Mar 2002 10:04:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14523 invoked from network); 14 Mar 2002 10:04:43 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2002 10:04:43 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 0A36982FEFA; Thu, 14 Mar 2002 11:04:42 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id LAA28507; Thu, 14 Mar 2002 11:04:41 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Derek Fawcus Cc: ietf-ssh@netbsd.org Subject: Re: WG LAST CALL: SECSH Public Key File Format References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> <20020314042549.C2441@edinburgh.cisco.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 14 Mar 2002 11:04:40 +0100 In-Reply-To: <20020314042549.C2441@edinburgh.cisco.com> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Derek Fawcus writes: > > Discussion question for the working group: Should this be advanced as > > Informational or as a Standards Track document? It could go either > > way -- it's not a "wire protocol" per se but it does describe a blob > > of data which can be exchanged (out of band) between implementations. > > I'd say Informational. Me two. Actually, I'll most likely prefer *not* using this format, but to stay with the keyformats defined by SPKI. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 05:42:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14514 for ; Thu, 14 Mar 2002 05:42:26 -0500 (EST) Received: (qmail 976 invoked by uid 605); 14 Mar 2002 10:42:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 967 invoked from network); 14 Mar 2002 10:42:24 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2002 10:42:24 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id CA9D3835E1C; Thu, 14 Mar 2002 11:42:22 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id LAA28513; Thu, 14 Mar 2002 11:42:22 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Subject: Re: WG LAST CALL: SECSH Public Key File Format References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 14 Mar 2002 11:42:21 +0100 In-Reply-To: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> Message-ID: Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > This is the start of a working group LAST CALL on: > > draft-ietf-secsh-publickeyfile-02.txt > SECSH Public Key File Format > > Last Call on this document expires in three weeks, on 3 April 2002 > (I'm giving it an extra week due to the upcoming IETF week). I don't quite like the new rules for continuation lines and separation between headers and body. I'd prefer using the good old method used for other header-body type messages, like mail and http. I.e.: The (possibly) empty header part is separated from the body by an empty line. Continuation lines are non-empty, and start with a sequence of whitespace characters. Then standard routines for dealing with header and body can be reused. Some examples of the format I'd prefer are below. Regards, /Niels ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459 6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6 NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459 6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6 NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459 6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6 NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 05:58:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14678 for ; Thu, 14 Mar 2002 05:58:58 -0500 (EST) Received: (qmail 13167 invoked by uid 605); 14 Mar 2002 10:58:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13159 invoked from network); 14 Mar 2002 10:58:57 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 14 Mar 2002 10:58:57 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 710F3835DCE; Thu, 14 Mar 2002 11:58:56 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id LAA28517; Thu, 14 Mar 2002 11:58:55 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: a more detailed analysis of "known IV" vulnerability. References: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> <20020313202322.D4967@eskimo.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 14 Mar 2002 11:58:55 +0100 In-Reply-To: <20020313202322.D4967@eskimo.com> Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > 2. By opening 2^24 channels, the attacker can gain control over 8 more > bits of the plaintext for 8-byte block size, and 24 more bits for 16-byte > block size. Do implementations allow that? My implementation has an arbitrary limit of 2^17 channels per connection. (And channel numbers are allocated sequentially). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 18:37:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04532 for ; Thu, 14 Mar 2002 18:37:31 -0500 (EST) Received: (qmail 3741 invoked by uid 605); 14 Mar 2002 23:37:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3705 invoked from network); 14 Mar 2002 23:37:28 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 14 Mar 2002 23:37:28 -0000 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 0E7BE67103; Thu, 14 Mar 2002 18:58:48 -0500 (EST) Date: Thu, 14 Mar 2002 18:36:21 -0500 Subject: Re: Core draft last call update. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-ssh@netbsd.org To: Wei Dai From: RJ Atkinson In-Reply-To: <20020313212051.E4967@eskimo.com> Message-Id: <4A708F4E-37A4-11D6-BDCA-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, March 14, 2002, at 12:20 , Wei Dai wrote: > On Wed, Mar 13, 2002 at 09:54:23PM -0500, Bill Sommerfeld wrote: >> I made a ruling as working group chair that, because (a) the problem >> could be fixed by a separate document introducing new ciphers, and (b) >> there clearly did not exist consensus on the a fix, that we should not >> hold up advancement of the rest of SSH while we attempted to solve the >> problem. >> >> You've missed the train. The core specs are now out of our hands. > > I don't agree with the proposed resolution to the issue I raised. Should > I contact the Area Director now or wait for the general Last-Call? Wei, If your goal is really to improve the deployed security of the Internet, then you ought to just create the standalone I-D and let the core drafts go without trying to de-rail the train. Bottom line is some crypto is a higher work function for an adversary than no crypto (telnet and plain-text). Crypto can always be improved. Trying to optimise IPsec (repeatedly; along many dimensions) is one of several reasons it was so badly delayed. Also, for my part, I don't (yet) have a comfort level with your proposal. IMHO, Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 21:12:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08255 for ; Thu, 14 Mar 2002 21:12:19 -0500 (EST) Received: (qmail 28403 invoked by uid 605); 15 Mar 2002 02:12:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28396 invoked from network); 15 Mar 2002 02:12:15 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 15 Mar 2002 02:12:15 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id SAA29681; Thu, 14 Mar 2002 18:12:07 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id SAA22731; Thu, 14 Mar 2002 18:12:05 -0800 (PST) Date: Thu, 14 Mar 2002 18:12:05 -0800 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: a more detailed analysis of "known IV" vulnerability. Message-ID: <20020314181205.A21862@eskimo.com> References: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> <20020313202322.D4967@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Thu, Mar 14, 2002 at 11:58:55AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Thu, Mar 14, 2002 at 11:58:55AM +0100, Niels Möller wrote: > Wei Dai writes: > > 2. By opening 2^24 channels, the attacker can gain control over 8 more > > bits of the plaintext for 8-byte block size, and 24 more bits for 16-byte > > block size. > > Do implementations allow that? My implementation has an arbitrary > limit of 2^17 channels per connection. (And channel numbers are > allocated sequentially). The attacker does not need to keep all of the channels open. He can open and close 2^24 channels to iterate through the channel numbers, and just keep 2^8 channels, each with a different id mod 2^16, open for the attack. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 14 23:01:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11976 for ; Thu, 14 Mar 2002 23:01:01 -0500 (EST) Received: (qmail 18218 invoked by uid 605); 15 Mar 2002 04:01:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18210 invoked from network); 15 Mar 2002 04:00:58 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 15 Mar 2002 04:00:58 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id UAA06032; Thu, 14 Mar 2002 20:00:54 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id UAA27785; Thu, 14 Mar 2002 20:00:54 -0800 (PST) Date: Thu, 14 Mar 2002 20:00:54 -0800 From: Wei Dai To: Markus Friedl Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020314200053.B21862@eskimo.com> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> <20020314083628.GB8790@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020314083628.GB8790@faui02>; from markus@openbsd.org on Thu, Mar 14, 2002 at 09:36:28AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 14, 2002 at 09:36:28AM +0100, Markus Friedl wrote: > I don't see a need to rush and consider CTR only, when CFB/OFB is > less controversal and already supported by existing implementations. I was not aware that existing implementations already support CFB/OFB. Apparently this is the case for OpenSSH, but it's not documented anywhere. OpenSSH also seems to support ECB mode, which does not make any sense to me. BTW, OpenSSH appears to use unregistered reserved names for these ciphers, which violates section 5 of the architecture spec. The way OpenSSH implements OFB (assuming it's accurately documented by the draft spec you sent in a later post) is different from how I would have done it. I would pad each packet to a multiple of 8 instead of the block size, but never mind. As I mentioned earlier, in the interest of time I'm willing to compromise and use OFB instead of CTR if we can get it into the core spec. If we have to do an additional RFC we might as well go for CTR since that is technically superior. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 00:35:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA13620 for ; Fri, 15 Mar 2002 00:35:16 -0500 (EST) Received: (qmail 3924 invoked by uid 605); 15 Mar 2002 05:35:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3917 invoked from network); 15 Mar 2002 05:35:13 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 15 Mar 2002 05:35:13 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id 72EFA207C3; Fri, 15 Mar 2002 00:34:59 -0500 (EST) Date: Fri, 15 Mar 2002 00:34:58 -0500 From: Niels Provos To: Wei Dai Cc: Markus Friedl , Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020315053458.GE1473@citi.citi.umich.edu> Mail-Followup-To: Wei Dai , Markus Friedl , Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> <20020314083628.GB8790@faui02> <20020314200053.B21862@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314200053.B21862@eskimo.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 14, 2002 at 08:00:54PM -0800, Wei Dai wrote: > I was not aware that existing implementations already support CFB/OFB. > Apparently this is the case for OpenSSH, but it's not documented anywhere. > OpenSSH also seems to support ECB mode, which does not make any sense to > me. BTW, OpenSSH appears to use unregistered reserved names for these > ciphers, which violates section 5 of the architecture spec. You have me confused. What are you talking about? Did you look at the source code, cipher.c contains the supported ciphers, including their names as announced during kex init: { "3des-cbc", SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc }, { "blowfish-cbc", SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc }, { "cast128-cbc", SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc }, { "arcfour", SSH_CIPHER_SSH2, 8, 16, EVP_rc4 }, { "aes128-cbc", SSH_CIPHER_SSH2, 16, 16, evp_rijndael }, { "aes192-cbc", SSH_CIPHER_SSH2, 16, 24, evp_rijndael }, { "aes256-cbc", SSH_CIPHER_SSH2, 16, 32, evp_rijndael }, I do not think that any of these ciphers violate any section of any spec produced by this working group. Specficially: The following ciphers are currently defined: 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc RECOMMENDED Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc RECOMMENDED Twofish with 128-bit key aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key aes128-cbc RECOMMENDED AES with 128-bit key Y serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode cast128-cbc OPTIONAL CAST-128 in CBC mode Please, explain yourself. I believe the biggest concern is a further delay of the drafts which already have been delayed for several years. None of the attacks that have been discussed here seem relevant enough to warrant delaying the drafts for another year. We can always define more ciphers and modes once the main drafts have been published. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 03:57:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23843 for ; Fri, 15 Mar 2002 03:57:54 -0500 (EST) Received: (qmail 23957 invoked by uid 605); 15 Mar 2002 08:57:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23950 invoked from network); 15 Mar 2002 08:57:51 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Mar 2002 08:57:51 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA18464; Fri, 15 Mar 2002 09:57:36 +0100 (MET) Date: Fri, 15 Mar 2002 09:57:36 +0100 From: Markus Friedl To: Wei Dai Cc: Bill Sommerfeld , David Wagner , ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020315085735.GA18324@faui02> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> <20020314083628.GB8790@faui02> <20020314200053.B21862@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020314200053.B21862@eskimo.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 14, 2002 at 08:00:54PM -0800, Wei Dai wrote: > I was not aware that existing implementations already support CFB/OFB. > Apparently this is the case for OpenSSH, but it's not documented anywhere. > OpenSSH also seems to support ECB mode, which does not make any sense to > me. BTW, OpenSSH appears to use unregistered reserved names for these > ciphers, which violates section 5 of the architecture spec. What versions of OpenSSH are you talking about? About released versions? Or about software that never left my laptop? Well, who cares, I'm getting used to OpenSSH-FUD... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 04:18:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24225 for ; Fri, 15 Mar 2002 04:18:27 -0500 (EST) Received: (qmail 2114 invoked by uid 605); 15 Mar 2002 09:18:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2106 invoked from network); 15 Mar 2002 09:18:24 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 15 Mar 2002 09:18:24 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id g2F9INT15732 for ; Fri, 15 Mar 2002 11:18:23 +0200 (EET) Received: (qmail 15839 invoked from network); 15 Mar 2002 09:18:22 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 15 Mar 2002 09:18:22 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.11.6/8.9.3) id g2FAKKf21820; Fri, 15 Mar 2002 12:20:20 +0200 X-Authentication-Warning: johto.hel.fi.ssh.com: sjl set sender to sjl@ssh.com using -f To: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. References: <20020315085735.GA18324@faui02> From: sjl@ssh.com (Sami J. Lehtinen) User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Canyonlands) Date: 15 Mar 2002 12:20:19 +0200 In-Reply-To: <20020315085735.GA18324@faui02> Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list markus@openbsd.org (Markus Friedl) writes: > On Thu, Mar 14, 2002 at 08:00:54PM -0800, Wei Dai wrote: > > I was not aware that existing implementations already support CFB/OFB. > > Apparently this is the case for OpenSSH, but it's not documented anywhere. > > OpenSSH also seems to support ECB mode, which does not make any sense to > > me. BTW, OpenSSH appears to use unregistered reserved names for these > > ciphers, which violates section 5 of the architecture spec. > > What versions of OpenSSH are you talking about? > > About released versions? Or about software that never left my laptop? > > Well, who cares, I'm getting used to OpenSSH-FUD... I think he is referring to our ssh, which has those modes for some ciphers (they come with the crypto lib, specified as in IPSEC etc). Sorry about that. Anyway, I believe the core documents don't need this, as a draft for additional modes is simple enough to do (as you demonstrated). Cheers, -- sjl@ssh.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 05:50:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25930 for ; Fri, 15 Mar 2002 05:50:06 -0500 (EST) Received: (qmail 14412 invoked by uid 605); 15 Mar 2002 10:50:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14304 invoked from network); 15 Mar 2002 10:50:01 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Mar 2002 10:50:01 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id E8B5C835A44; Fri, 15 Mar 2002 11:49:58 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id LAA28838; Fri, 15 Mar 2002 11:49:58 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: a more detailed analysis of "known IV" vulnerability. References: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> <20020313202322.D4967@eskimo.com> <20020314181205.A21862@eskimo.com> From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 15 Mar 2002 11:49:57 +0100 In-Reply-To: <20020314181205.A21862@eskimo.com> Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > On Thu, Mar 14, 2002 at 11:58:55AM +0100, Niels Möller wrote: > > Do implementations allow that? My implementation has an arbitrary > > limit of 2^17 channels per connection. (And channel numbers are > > allocated sequentially). > > The attacker does not need to keep all of the channels open. He can open > and close 2^24 channels to iterate through the channel numbers, and just > keep 2^8 channels, each with a different id mod 2^16, open for the attack. That depends on how channel numbers are allocated. I think a typical implementation uses a linear channel table indexed by its local channel numbers, and it will not allocate large local channel numbers as long as small numbers are available (as that would imply growing the tables). E.g., my implementation will never allocate a channel number larger than 2^17, and it always allocates the smallest available number. ("sequentially" above was perhaps not the right word, sorry about that). But an implementation has control only over its *local* numbers, the numbers it transmits over the wire are chosen by the remote peer. If the attacker has control over the peer, he gets full control over the channel numbers I send. I don't know how likely that is; if the attacker has control over the software at the remote peer, we may well have bigger problems. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 10:46:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01989 for ; Fri, 15 Mar 2002 10:46:38 -0500 (EST) Received: (qmail 19106 invoked by uid 605); 15 Mar 2002 15:45:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19085 invoked from network); 15 Mar 2002 15:45:05 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 15 Mar 2002 15:45:05 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 517599; Fri, 15 Mar 2002 08:52:56 -0700 Message-ID: <003201c1cc38$70d5f6f0$4d00a8c0@CHAOS> From: "Joseph Galbraith" To: , =?iso-8859-1?Q?Niels_M=F6ller?= Cc: References: <200203132351.g2DNpggw026980@thunk.East.Sun.COM> Subject: Re: WG LAST CALL: SECSH Public Key File Format Date: Fri, 15 Mar 2002 08:45:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Bill Sommerfeld writes: > > > This is the start of a working group LAST CALL on: > > > > draft-ietf-secsh-publickeyfile-02.txt > > SECSH Public Key File Format > > > > Last Call on this document expires in three weeks, on 3 April 2002 > > (I'm giving it an extra week due to the upcoming IETF week). > > I don't quite like the new rules for continuation lines and separation > between headers and body. I'd prefer using the good old method used > for other header-body type messages, like mail and http. I.e.: > > The (possibly) empty header part is separated from the body by an > empty line. Continuation lines are non-empty, and start with a > sequence of whitespace characters. > > Then standard routines for dealing with header and body can be reused. > Some examples of the format I'd prefer are below. The draft documents existing practice, (except where it was necessary to deviate for interoperability -- for example, requiring that any newline convention be allowed.) I suppose this would argue for informational. On the other hand, since there is no other mechanism for a client to give the server it's public keys, if an implementation can't at least convert this format to its prefered format, it won't interoperate with any clients except its own (for public key authentication.) In order for public key authentication to interoperate, there must be a way to exchange public keys between the client and the server. This draft provides a standard that can be used for that exchange. This would argue for "Standards Track" - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 17:06:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11813 for ; Fri, 15 Mar 2002 17:06:32 -0500 (EST) Received: (qmail 18083 invoked by uid 605); 15 Mar 2002 22:06:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18076 invoked from network); 15 Mar 2002 22:06:28 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 15 Mar 2002 22:06:28 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10751 for ; Fri, 15 Mar 2002 15:06:25 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25393 for ; Fri, 15 Mar 2002 17:06:24 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2FM5Egw026639 for ; Fri, 15 Mar 2002 17:05:14 -0500 (EST) Message-Id: <200203152205.g2FM5Egw026639@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: send me agenda items for Monday's meeting.. Reply-to: sommerfeld@east.sun.com Date: Fri, 15 Mar 2002 17:05:14 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, while the core drafts are done, we still have plenty to talk about: - An appropriate disclaimer about the CBC bug - The extension drafts currently in last-call. - The extension drafts not yet ready for last call. - Input for new draft(s) on crypto modes - Other SSH extensions? - Revising milestones yet again. If there's something else you want on the agenda, let me know.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 15 21:24:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15785 for ; Fri, 15 Mar 2002 21:24:45 -0500 (EST) Received: (qmail 29566 invoked by uid 605); 16 Mar 2002 02:24:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29559 invoked from network); 16 Mar 2002 02:24:38 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 16 Mar 2002 02:24:38 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id SAA27409; Fri, 15 Mar 2002 18:24:36 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id SAA07391; Fri, 15 Mar 2002 18:24:35 -0800 (PST) Date: Fri, 15 Mar 2002 18:24:35 -0800 From: Wei Dai To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Core draft last call update. Message-ID: <20020315182435.B5533@eskimo.com> References: <200203131752.g2DHqLgw021887@thunk.East.Sun.COM> <20020313151407.A25360@eskimo.com> <20020314083628.GB8790@faui02> <20020314200053.B21862@eskimo.com> <20020315085735.GA18324@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020315085735.GA18324@faui02>; from markus@openbsd.org on Fri, Mar 15, 2002 at 09:57:36AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 15, 2002 at 09:57:36AM +0100, Markus Friedl wrote: > On Thu, Mar 14, 2002 at 08:00:54PM -0800, Wei Dai wrote: > > I was not aware that existing implementations already support CFB/OFB. > > Apparently this is the case for OpenSSH, but it's not documented anywhere. > > OpenSSH also seems to support ECB mode, which does not make any sense to > > me. BTW, OpenSSH appears to use unregistered reserved names for these > > ciphers, which violates section 5 of the architecture spec. > > What versions of OpenSSH are you talking about? My apologies, what I said above applies to the SSH implementation from SSH Communications Security, not OpenSSH. > About released versions? Or about software that never left my laptop? I guess that mean you've implemented OFB mode ciphers for OpenSSH but have not released it yet? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 16 01:45:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21309 for ; Sat, 16 Mar 2002 01:45:02 -0500 (EST) Received: (qmail 27141 invoked by uid 605); 16 Mar 2002 06:45:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27131 invoked from network); 16 Mar 2002 06:45:00 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 16 Mar 2002 06:45:00 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id BAAFE3BD08; Sat, 16 Mar 2002 07:44:54 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 2D3136C007; Sat, 16 Mar 2002 07:44:56 +0100 (MET) Date: Sat, 16 Mar 2002 07:43:13 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Bill Sommerfeld Cc: Subject: Re: send me agenda items for Monday's meeting.. In-Reply-To: <200203152205.g2FM5Egw026639@thunk.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 15 Mar 2002, Bill Sommerfeld wrote: > If there's something else you want on the agenda, let me know.. Perhaps the proposed new draft that goes into detail with x509 PKI authentication (of both servers and users). I am not attending the meeting but am interested in helping out writing the draft. Especially if we get consensus in the earlier discussions of formats et.c. implementations wouldn't be too hard to do, we've got the code in place, OpenSSH have OpenSSL and SSH Inc allready have an implementation AFAIK, I don't know the status with Vandyke? (interoperable implementations in existance would of course help the discussion about how it should be specified :-). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 16 01:47:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21330 for ; Sat, 16 Mar 2002 01:47:16 -0500 (EST) Received: (qmail 28142 invoked by uid 605); 16 Mar 2002 06:47:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28135 invoked from network); 16 Mar 2002 06:47:14 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 16 Mar 2002 06:47:14 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 7B5DB3BD08; Sat, 16 Mar 2002 07:47:13 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id A69E26C007; Sat, 16 Mar 2002 07:47:14 +0100 (MET) Date: Sat, 16 Mar 2002 07:45:32 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Wei Dai Cc: Markus Friedl , Subject: Re: Core draft last call update. In-Reply-To: <20020315182435.B5533@eskimo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 15 Mar 2002, Wei Dai wrote: > My apologies, what I said above applies to the SSH implementation from > SSH Communications Security, not OpenSSH. > > > About released versions? Or about software that never left my laptop? > > I guess that mean you've implemented OFB mode ciphers for OpenSSH but > have not released it yet? We've also got OFB mode in place (tested with SSH Inc. server). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 16 02:22:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29711 for ; Sat, 16 Mar 2002 02:22:27 -0500 (EST) Received: (qmail 13134 invoked by uid 605); 16 Mar 2002 07:22:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13125 invoked from network); 16 Mar 2002 07:22:23 -0000 Received: from abraham.cs.berkeley.edu (HELO mx2.cypherpunks.ca) (128.32.247.199) by mail.netbsd.org with SMTP; 16 Mar 2002 07:22:23 -0000 X-Envelope-To: ietf-ssh@netbsd.org Received: (from news@localhost) by mx2.cypherpunks.ca (8.11.0/8.11.0) id g2G7DtN28216 for ietf-ssh@netbsd.org; Fri, 15 Mar 2002 23:13:55 -0800 To: ietf-ssh@netbsd.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: a more detailed analysis of "known IV" vulnerability. Date: 16 Mar 2002 07:13:55 GMT Organization: University of California, Berkeley Lines: 27 Distribution: isaac Message-ID: References: <200203112154.g2BLsIgw002569@thunk.East.Sun.COM> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1016262835 28039 128.32.45.153 (16 Mar 2002 07:13:55 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 16 Mar 2002 07:13:55 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@netbsd.org Precedence: list Bill Sommerfeld wrote: >[folks, please look this over and let me know if I missed anything..] Ahh. Thanks for the detailed analysis. I must admit I'm not 100% convinced by your numbers, though they seemed like a good start. It looked to me like a better estimate is that around four blocks of plaintext might leak in an average 1 GB session, assuming circumstances most favorable to the attacker. However, that's still not so bad. If all those assumptions on the upper layers hold, then the leakage is still not very severe, I guess. (Of course, we're relying heavily on these assumptions about the upper layers, so it is crucial that the upper layers not be re-designed -- e.g., by allowing provisions for fragmentation in the upper layers.) Bottom line: the exposure is quite limited, and I think it's reasonable to conclude that this attack will not be easiest way to break SSH sessions. If this is the best attack on SSH, that's a pretty good place to be at. So I think I agree with the decision to defer these changes in order to encourage SSH deployment as soon as possible. I withdraw any objections I may have had. Thanks for the explanations. I believe this rationale should be carefully explained in the SSH RFC. Otherwise, some readers might get the wrong impression. Also, it will help inform those who might re-use the SSH encoding transform without also maintaining the upper layers that they are in a danger zone. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 16 13:51:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07785 for ; Sat, 16 Mar 2002 13:51:39 -0500 (EST) Received: (qmail 23737 invoked by uid 605); 16 Mar 2002 18:51:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23728 invoked from network); 16 Mar 2002 18:51:37 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 16 Mar 2002 18:51:37 -0000 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 558AF67109; Sat, 16 Mar 2002 14:13:26 -0500 (EST) Date: Sat, 16 Mar 2002 13:51:09 -0500 Subject: Re: a more detailed analysis of "known IV" vulnerability. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-ssh@netbsd.org To: daw@mozart.cs.berkeley.edu (David Wagner) From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Saturday, March 16, 2002, at 07:13 , David Wagner wrote: > I think it's reasonable to conclude that this attack will not > be easiest way to break SSH sessions. This has been my conclusion as well, based largely on Ross Anderson's paper on how crypto is typically broken. > I believe this rationale should be carefully explained in the SSH RFC. > Otherwise, some readers might get the wrong impression. Also, it will > help inform those who might re-use the SSH encoding transform without > also maintaining the upper layers that they are in a danger zone. I'm not sure whether the detailed analysis really belongs in the core SSH RFCs. Documenting in some RFC, possibly a parallel RFC with Informational status, seems eminently reasonable. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 17 05:28:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29810 for ; Sun, 17 Mar 2002 05:28:08 -0500 (EST) Received: (qmail 1386 invoked by uid 605); 17 Mar 2002 10:27:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1379 invoked from network); 17 Mar 2002 10:27:47 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 17 Mar 2002 10:27:47 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 4A20FE939; Sun, 17 Mar 2002 21:35:49 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id g2HARQ112499; Sun, 17 Mar 2002 21:27:27 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Sun, 17 Mar 2002 21:27:24 +1100 (EST) From: Damien Miller To: RJ Atkinson Cc: David Wagner , "ietf-ssh@netbsd.org" Subject: Re: a more detailed analysis of "known IV" vulnerability. In-Reply-To: Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, 16 Mar 2002, RJ Atkinson wrote: > > I believe this rationale should be carefully explained in the SSH RFC. > > Otherwise, some readers might get the wrong impression. Also, it will > > help inform those who might re-use the SSH encoding transform without > > also maintaining the upper layers that they are in a danger zone. > > I'm not sure whether the detailed analysis really belongs in the > core SSH RFCs. Documenting in some RFC, possibly a parallel RFC > with Informational status, seems eminently reasonable. Can we put some text in the "security considerations" referring someone to a published document without delaying the drafts? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 17 14:39:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08990 for ; Sun, 17 Mar 2002 14:39:42 -0500 (EST) Received: (qmail 26405 invoked by uid 605); 17 Mar 2002 19:39:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26398 invoked from network); 17 Mar 2002 19:39:38 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Mar 2002 19:39:38 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11946; Sun, 17 Mar 2002 12:39:37 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19058; Sun, 17 Mar 2002 14:39:36 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2HJcMgw014682; Sun, 17 Mar 2002 14:38:22 -0500 (EST) Message-Id: <200203171938.g2HJcMgw014682@thunk.East.Sun.COM> From: Bill Sommerfeld To: RJ Atkinson cc: daw@mozart.cs.berkeley.edu (David Wagner), ietf-ssh@netbsd.org Subject: Re: a more detailed analysis of "known IV" vulnerability. In-Reply-To: Your message of "Sat, 16 Mar 2002 13:51:09 EST." Reply-to: sommerfeld@east.sun.com Date: Sun, 17 Mar 2002 14:38:21 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I'm not sure whether the detailed analysis really belongs in the > core SSH RFCs. Documenting in some RFC, possibly a parallel RFC > with Informational status, seems eminently reasonable. [wg chair hat off] agreed. I think it's best to split detailed analysis of this form into a separate document. An analysis of this form, while important, will dilute the specification and make it harder for an implementor to find the actual "meat" of the protocol. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 18 10:22:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07138 for ; Mon, 18 Mar 2002 10:21:59 -0500 (EST) Received: (qmail 2276 invoked by uid 605); 18 Mar 2002 15:21:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2269 invoked from network); 18 Mar 2002 15:21:57 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 18 Mar 2002 15:21:57 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22193 for ; Mon, 18 Mar 2002 08:21:56 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09011 for ; Mon, 18 Mar 2002 10:21:55 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2IFKegw022259 for ; Mon, 18 Mar 2002 10:20:40 -0500 (EST) Message-Id: <200203181520.g2IFKegw022259@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: potential disclaimer for the transport draft. Reply-to: sommerfeld@east.sun.com Date: Mon, 18 Mar 2002 10:20:40 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [wg chair hat off] I took the liberty of drafting a possible disclaimer for the CBC attack. Please send substantive comments regarding this text to this list. - Bill NOTE: Nearly all ciphers specified in this document are used in cipher block chaining (CBC) mode. It's been known for some time that CBC modes will reveal information about the plaintext if two ciphertext blocks encrypted under the same key are equal; this is one of the reasons this document strongly recommends rekeying at least once per gigabyte of data, to reduce the chance that a "birthday paradox" collision will appear. Recent research has uncovered a new attack on CBC mode which, under certain conditions, allows a chosen plaintext attacker aware of the IV for a forthcoming message to have some chance to artificially induce a system into generating ciphertext collisions, allowing the attacker's guesses at likely prior plaintexts to be confirmed. Any protocol which uses CBC in a way which allows advance knowledge of a message's IV (e.g., by using the last block of the preceding message as the IV) might be vulnerable to this attack. Preliminary analysis of this attack as applied to the SSH protocol suggests that the protocol is actually fairly resistant to this attack; while estimates vary, it appears that, on average, an attacker would have to inject tens or hundreds of millions of chosen plaintexts to confirm guesses on the value of a few unknown plaintexts. While this attack involves less work than a brute-force attack on the underlying cipher (and is thus a matter of some concern), it is also likely to be significantly more difficult than attacks on other parts of a system using the SSH protocol, and so is unlikely to be an immediate risk to real-world systems. Due to this document's recommendation that rekeying occur once an hour, an attacker also has a limited amount of time to complete any particular attack. Nevertheless, work is underway to specify, in a separate document or documents, additional cipher modes for the SSH protocol to address this vulnerability. Implementors should be prepared to add new algorithms to their implementations as this work progresses. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 18 20:54:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28885 for ; Mon, 18 Mar 2002 20:54:48 -0500 (EST) Received: (qmail 13480 invoked by uid 605); 19 Mar 2002 01:54:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13473 invoked from network); 19 Mar 2002 01:54:46 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 19 Mar 2002 01:54:46 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id RAA04233; Mon, 18 Mar 2002 17:54:43 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id RAA20283; Mon, 18 Mar 2002 17:54:43 -0800 (PST) Date: Mon, 18 Mar 2002 17:54:43 -0800 From: Wei Dai To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. Message-ID: <20020318175443.A17144@eskimo.com> References: <200203181520.g2IFKegw022259@thunk.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203181520.g2IFKegw022259@thunk.East.Sun.COM>; from sommerfeld@east.sun.com on Mon, Mar 18, 2002 at 10:20:40AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Mar 18, 2002 at 10:20:40AM -0500, Bill Sommerfeld wrote: > Preliminary analysis of this attack as applied to the SSH protocol > suggests that the protocol is actually fairly resistant to this > attack; while estimates vary, it appears that, on average, an attacker > would have to inject tens or hundreds of millions of chosen plaintexts > to confirm guesses on the value of a few unknown plaintexts. I think this paragraph is not accurate. Specificly, the protocol itself is not resistant, rather it's the current implementations that are somewhat resistant, and the attacker does not have to inject tens of millions of chosen plaintexts, he just needs to cause tens of millions of packets to be sent, and do one chosen plaintext at the right moment. > While this attack involves less work than a brute-force attack on the > underlying cipher (and is thus a matter of some concern), it is also > likely to be significantly more difficult than attacks on other parts > of a system using the SSH protocol, and so is unlikely to be an > immediate risk to real-world systems. I don't think it's the case that the attack is unlikely to be an immediate risk to real-world systems. On any particular system, it's probably not the biggest hole, but it quite likely is the biggest hole on *some* real-world systems. > Due to this document's > recommendation that rekeying occur once an hour, an attacker also has > a limited amount of time to complete any particular attack. I suggest rewording this section of the warning as follows: Preliminary analysis of this attack as applied to the SSH protocol suggests that current implementations of the protocol contain a number of limitations which have the side effect of hindering the attack. As a result the attacker must at least cause tens of millions of packets to be sent over the same connection and encrypted with the same key before the attack has a reasonable chance of success. Due to this document's recommendation that rekeying occur once an hour, an attacker also has a limited amount of time to complete any particular attack. While this attack involves less work than a brute-force attack on the underlying cipher (and is thus a matter of some concern), it is also likely to be significantly more difficult than attacks on other parts of a system using the SSH protocol. --- Also, I think we need to say something to the effect that once the new modes are defined, CBC ciphers should be considered deprecated and no longer REQUIRED or RECOMMENDED, so that future users are not confronted with the choice of CBC mode. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 19 09:22:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22557 for ; Tue, 19 Mar 2002 09:22:34 -0500 (EST) Received: (qmail 29019 invoked by uid 605); 19 Mar 2002 14:22:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29012 invoked from network); 19 Mar 2002 14:22:32 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 19 Mar 2002 14:22:32 -0000 Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id A1EA02709; Tue, 19 Mar 2002 09:22:30 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id g2JEGjV00336; Tue, 19 Mar 2002 09:16:45 -0500 (EST) Message-Id: <200203191416.g2JEGjV00336@syn.hamachi.org> From: Bill Sommerfeld To: Wei Dai Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. In-Reply-To: Message from Wei Dai of "Mon, 18 Mar 2002 17:54:43 PST." <20020318175443.A17144@eskimo.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 19 Mar 2002 09:16:44 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I think this paragraph is not accurate. Specificly, the protocol itself is > not resistant, rather it's the current implementations that are somewhat > resistant I'm rephrasing to: Preliminary analysis of this attack as applied to the SSH protocol suggests that the protocol as implemented today is actually fairly resistant to this attack... > the attacker does not have to inject tens of millions of > chosen plaintexts, he just needs to cause tens of millions of packets to > be sent, and do one chosen plaintext at the right moment. I'll rephrase to: .. on average, an attacker would need tens or hundreds of millions of opportunities to inject chosen plaintexts to be encrypted with a known IV to confirm guesses on the value of a few unknown plaintexts. > On any particular system, it's probably not the biggest hole, but it > quite likely is the biggest hole on *some* real-world systems. I think you severely underestimate how many latent undiscovered security holes are out there at the moment.. I don't think we have *any* reason to believe that. > Also, I think we need to say something to the effect that once the > new modes are defined, CBC ciphers should be considered deprecated > and no longer REQUIRED or RECOMMENDED, so that future users are not > confronted with the choice of CBC mode. It's premature to overconstrain the possible solutions. We haven't decided on the fix. If we choose to fix the problem by introducing new ciphers, the document which specifies them can deprecate the old ciphers. We could investigate new ciphers, determine we can't agree on the right ones, and fall back to fixing the problem some other way (i.e., start each block of ciphertext with an SSH_MSG_IGNORE). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 13:41:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09681 for ; Wed, 20 Mar 2002 13:41:45 -0500 (EST) Received: (qmail 4890 invoked by uid 605); 20 Mar 2002 18:41:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4883 invoked from network); 20 Mar 2002 18:41:36 -0000 Received: from sommerfeld.ne.client2.attbi.com (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 20 Mar 2002 18:41:36 -0000 Received: from syn.hamachi.org (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 77BB72709 for ; Wed, 20 Mar 2002 13:41:34 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id g2KIVuq01270 for ; Wed, 20 Mar 2002 13:31:56 -0500 (EST) Message-Id: <200203201831.g2KIVuq01270@syn.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Even more ways to fix the cbc-mode attack Date: Wed, 20 Mar 2002 13:31:56 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Since TLS has the same CBC attack problem, I attended that WG... Eric Rescorla mentioned a few ideas which had been kicked around on TLS for fixing the problem. In addition to the ones that have been mentioned already either on the list or in Monday's meeting, there are: - stream-like modes (CTR, OFB) - explicit IV Eric also mentioned two other ideas which allow the continued use of CBC mode: - use an implicit pseudorandom IV (i.e., both sides run counter mode or what have you with a different key just to generate the IV) - move the MAC to the start of the packet and (somehow) use that as the IV. There didn't seem to be consensus in that group on the right answer, either... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 14:54:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12260 for ; Wed, 20 Mar 2002 14:54:24 -0500 (EST) Received: (qmail 17967 invoked by uid 605); 20 Mar 2002 19:54:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17954 invoked from network); 20 Mar 2002 19:54:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 20 Mar 2002 19:54:19 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14921; Wed, 20 Mar 2002 12:54:18 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA08388; Wed, 20 Mar 2002 11:54:40 -0800 (PST) Received: from jurassic (jurassic [129.146.81.36]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJsBXO175772; Wed, 20 Mar 2002 11:54:11 -0800 (PST) Date: Wed, 20 Mar 2002 11:54:11 -0800 (PST) From: Darren J Moffat To: Bill Sommerfeld cc: ietf-ssh@netbsd.org Subject: Re: Even more ways to fix the cbc-mode attack In-Reply-To: <200203201831.g2KIVuq01270@syn.hamachi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 20 Mar 2002, Bill Sommerfeld wrote: > There didn't seem to be consensus in that group on the right answer, > either... Just to add to this, CTR mode didn't go down with much favour in the TLS working group either. There was support from the ADs that an IETF wide solution if it was possible, was very desirable. It does seem that TLS is less vulnerable in the ways that it is currently used than the ways we know that the SSH protocol is currently used. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 17:26:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17517 for ; Wed, 20 Mar 2002 17:26:38 -0500 (EST) Received: (qmail 19657 invoked by uid 605); 20 Mar 2002 22:26:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19650 invoked from network); 20 Mar 2002 22:26:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Mar 2002 22:26:36 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 523945 for ietf-ssh@netbsd.org; Wed, 20 Mar 2002 15:26:35 -0700 Message-ID: <005c01c1d05d$b7ff43a0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: SFTP owner, group and mode flags... Date: Wed, 20 Mar 2002 15:22:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit The current specification of SFTP passes owner and group information as UID and GID, and specifies file permissions as a UINT bit mask. This has several problems: 1. A UINT32 is not sufficient to represent UID and GID on Windows NT systems. 2. There is no mechanism for translating between the UID/GID and a human readable form (the owner name or group name.) 3. The permission mask is unable to represent the more sophisticated security information used under VMS, Windows NT and some Unix variants -- ACLs. I would propose the following: * Where we currently pass UID and GID as integers, pass them as strings of the form user@dns (see NFS: RFC3010, Section 5.6.) * In order to reduce overhead of readdir and stat operations, which will increase with the above, we add a parameter to the opendir and stat protocols to allow the client to specify what attributes it is interested in. This also allows the client to optimize stat and readdir operations. The client can avoid asking for information it isn't interested in, and minimize the work requested of the server and the amount of data transfered over the wire. * Also, now that the user / group information is available in a human readable format, the long name is entirely redundant, and expensive (more than twice as long as the rest of the stat data put together.) I propose that we remove it, and the associated temptation for applications to parse it as Unix ls output. * Change the mode field to a type field, which indicates the type of the file, and make it a byte field. * Use the ACL specification from NFS (RFC3010, Section 5.9) Unix style permission masks can be easily represented as an ACL using the special "who" values specified in 5.9.4. * We allow a server to advertise what attributes it can provide and what attributes it can provide efficiently, but require servers to tolerantly ignore requests for attributes it can't provide and require that clients be prepared to not receive attributes that the server has advertised. For example, under NT, we would advertise that we can provide User, Group and ACL information, but that they are expensive. However, if the file-system supporting a file requested by the client is FAT, then we won't be able to provide that information. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 17:27:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17539 for ; Wed, 20 Mar 2002 17:27:24 -0500 (EST) Received: (qmail 20343 invoked by uid 605); 20 Mar 2002 22:27:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20333 invoked from network); 20 Mar 2002 22:27:21 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Mar 2002 22:27:21 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 523950 for ietf-ssh@netbsd.org; Wed, 20 Mar 2002 15:27:19 -0700 Message-ID: <005f01c1d05d$d2343fa0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Internationaliztion: UTF-8 for file names Date: Wed, 20 Mar 2002 15:23:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit As currently specified, I do not believe SFTP meets the requirements of "IETF Policy on Character Sets and Languages" [RFC2277]. Last time this issue was raised, it stalled out on issues of normalization. I've now read the NFS specification on the matter [RFC3010, section 11.] NFS elected to not deal with the normalization. I would say that this would be a great deal better than what we have now (which is non-interoperability for filenames that are not 7-bit US-ASCII). I would also say that if it was good enough for NFS, it is probably good enough for SFTP. I would propose that we reference the RFC3010, section 11 and specify UTF-8 for filenames. On particularly compelling argument (at least to me) specified in RFC3010 is that a universal character set is required because various path components may be specified in different character-sets. So, for example, trying to negotiate the char-set in use during protocol startup or even on a per path basis, is insufficient. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 17:27:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17568 for ; Wed, 20 Mar 2002 17:27:36 -0500 (EST) Received: (qmail 20535 invoked by uid 605); 20 Mar 2002 22:27:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20442 invoked from network); 20 Mar 2002 22:27:25 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Mar 2002 22:27:25 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 523951 for ietf-ssh@netbsd.org; Wed, 20 Mar 2002 15:27:23 -0700 Message-ID: <006301c1d05d$d47c5ae0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Justification of SFTP Date: Wed, 20 Mar 2002 15:23:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On my way back from Minneapolis, I reviewed the NFS draft, something I'd been intending to do for a while. As I did so, I had some thoughts both on why we want to do SFTP and what our objectives are. First off the objectives: 1. Customers want a secure file sharing application. 2. Customers don't want to run another service on their servers. They want the file sharing capability built into SSH. 3. SFTP is a light-weight file sharing / transfer protocol. 4. SFTP takes advantage of existing SSH standards / code to keep specification small (i.e., we don't need to specify anything about authentication, privacy, or integrity, as these are provided by SSH.) 3. SFTP is easy to implement based on SSH (i.e., uses the same packetizing, data types, etc., so that it fits well into a SSH implementation.) 4. SFTP should borrow from NFS or other protocols when appropriate to reduce the amount of work we have to do in solving problems and doing specifications. There are several major reasons that I think the SFTP work needs to move forward: 1. Ease of implementation in SSH. The structure and philosophy of the SFTP design integrates well into an SSH implementation. Using FTP or NFS (or some variant there of) on top of in conjunction with SSH does not have this property. 2. Simplicity. NFS at least is a 212 page draft. (I'm not sure about FTP.) SFTP on the other hand, weighs in at a stunning 20 pages. I suspect by the time we complete SFTP it may have grown somewhat -- I'd be surprised if we exceed 50 pages though. 3. Doesn't require a 'separate' piece of software, that is maintained separately. From the customers standpoint, I believe this is the most significant. 4. Integrates well with existing SSH applications. Because SFTP is integrated with the SSH protocol, it is easier to do things like run both file transfer and shell over the same connection, or, have a command in the shell trigger the SFTP upload or download. I believe this kind of thing would be harder and more awkward to achieve using another protocol bolted on top of SSH. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 19:28:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20118 for ; Wed, 20 Mar 2002 19:28:30 -0500 (EST) Received: (qmail 3668 invoked by uid 605); 21 Mar 2002 00:27:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3661 invoked from network); 21 Mar 2002 00:27:48 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 21 Mar 2002 00:27:48 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id 5B3DF16C7C; Thu, 21 Mar 2002 11:27:46 +1100 (EST) Date: Thu, 21 Mar 2002 11:36:10 +1100 (EST) From: Damien Miller X-X-Sender: djm@xenon.mel.ibs.com.au To: Joseph Galbraith Cc: "ietf-ssh@netbsd.org" Subject: Re: SFTP owner, group and mode flags... In-Reply-To: <005c01c1d05d$b7ff43a0$4d00a8c0@galb.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 20 Mar 2002, Joseph Galbraith wrote: > * Where we currently pass UID and GID as > integers, pass them as strings of the > form user@dns (see NFS: RFC3010, Section 5.6.) Agreed. > * In order to reduce overhead of readdir and > stat operations, which will increase with > the above, we add a parameter to the opendir > and stat protocols to allow the client to > specify what attributes it is interested in. I don't know whether this is necessary. If the longname is eliminated, then I don't think the replies will be very large. > This also allows the client to optimize stat > and readdir operations. The client can avoid > asking for information it isn't interested in, > and minimize the work requested of the server > and the amount of data transfered over the wire. > > * Also, now that the user / group information > is available in a human readable format, the > long name is entirely redundant, and expensive > (more than twice as long as the rest of the stat > data put together.) > > I propose that we remove it, and the associated > temptation for applications to parse it as > Unix ls output. Agreed. > * Change the mode field to a type field, which indicates > the type of the file, and make it a byte field. Can you be more specific? > * Use the ACL specification from NFS (RFC3010, Section 5.9) > Unix style permission masks can be easily represented as > an ACL using the special "who" values specified in > 5.9.4. Again, this add complexity for the simple case. Why not encode extended ACLs as a seperate attribute? > * We allow a server to advertise what attributes > it can provide and what attributes it can provide > efficiently, but require servers to tolerantly > ignore requests for attributes it can't provide > and require that clients be prepared to not receive > attributes that the server has advertised. > > For example, under NT, we would advertise that we > can provide User, Group and ACL information, but > that they are expensive. What do you mean by expensive? I am a little ambivalent against advertising capabilities, especially ones relating to whether certain operations are "expensive" for the host OS. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 20 23:24:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25380 for ; Wed, 20 Mar 2002 23:24:12 -0500 (EST) Received: (qmail 5070 invoked by uid 605); 21 Mar 2002 04:24:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5063 invoked from network); 21 Mar 2002 04:24:10 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 21 Mar 2002 04:24:10 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id UAA15718; Wed, 20 Mar 2002 20:24:08 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id UAA15079; Wed, 20 Mar 2002 20:24:08 -0800 (PST) Date: Wed, 20 Mar 2002 20:24:07 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. Message-ID: <20020320202406.B14107@eskimo.com> References: <200203191416.g2JEGjV00336@syn.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200203191416.g2JEGjV00336@syn.hamachi.org>; from sommerfeld@orchard.arlington.ma.us on Tue, Mar 19, 2002 at 09:16:44AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 19, 2002 at 09:16:44AM -0500, Bill Sommerfeld wrote: > > On any particular system, it's probably not the biggest hole, but it > > quite likely is the biggest hole on *some* real-world systems. > > I think you severely underestimate how many latent undiscovered > security holes are out there at the moment.. I don't think we have > *any* reason to believe that. Ok, let me rephrase that: it quite likely is the biggest *known* hole on some real-world systems. The point remains that we can't be confident that it's not a threat to any real world system. > We haven't decided on the fix. If we choose to fix the problem by > introducing new ciphers, the document which specifies them can > deprecate the old ciphers. We could investigate new ciphers, > determine we can't agree on the right ones, and fall back to fixing > the problem some other way (i.e., start each block of ciphertext with > an SSH_MSG_IGNORE). Regarding the parenthetical suggestion, I thought each SSH packet can contain only one message. Is that incorrect? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 00:33:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26911 for ; Thu, 21 Mar 2002 00:33:15 -0500 (EST) Received: (qmail 9623 invoked by uid 605); 21 Mar 2002 05:33:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9615 invoked from network); 21 Mar 2002 05:33:11 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 21 Mar 2002 05:33:11 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id VAA12242; Wed, 20 Mar 2002 21:33:10 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id VAA17762; Wed, 20 Mar 2002 21:33:10 -0800 (PST) Date: Wed, 20 Mar 2002 21:33:09 -0800 From: Wei Dai To: Bill Sommerfeld Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. Message-ID: <20020320213309.C14107@eskimo.com> References: <200203191416.g2JEGjV00336@syn.hamachi.org> <20020320202406.B14107@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020320202406.B14107@eskimo.com>; from weidai@eskimo.com on Wed, Mar 20, 2002 at 08:24:07PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Mar 20, 2002 at 08:24:07PM -0800, Wei Dai wrote: > > We haven't decided on the fix. If we choose to fix the problem by > > introducing new ciphers, the document which specifies them can > > deprecate the old ciphers. We could investigate new ciphers, > > determine we can't agree on the right ones, and fall back to fixing > > the problem some other way (i.e., start each block of ciphertext with > > an SSH_MSG_IGNORE). > > Regarding the parenthetical suggestion, I thought each SSH packet can > contain only one message. Is that incorrect? I would still appreciate an answer to my question, but I now see that the proposed fix works in either case. The sender could send two packets for every normal message, the first one containing an SSH_MSG_IGNORE, and the second one containing the actual message. Following a suggestion David Hopwood posted to IETF-TLS, it seems a good idea to implement this workaround for CBC mode in any case, so that at least one direction of the connection is protected against the predictable-IV attack even if the other side has not implemented the final fix. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 07:11:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09341 for ; Thu, 21 Mar 2002 07:11:50 -0500 (EST) Received: (qmail 18753 invoked by uid 605); 21 Mar 2002 12:11:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18746 invoked from network); 21 Mar 2002 12:11:46 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 21 Mar 2002 12:11:46 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id ACBE28360BC; Thu, 21 Mar 2002 13:11:44 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id NAA24250; Thu, 21 Mar 2002 13:11:44 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: Bill Sommerfeld , Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. References: <200203191416.g2JEGjV00336@syn.hamachi.org> <20020320202406.B14107@eskimo.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 21 Mar 2002 13:11:43 +0100 In-Reply-To: <20020320202406.B14107@eskimo.com> Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > Regarding the parenthetical suggestion, I thought each SSH packet can > contain only one message. Is that incorrect? That's right, but if the implementation does some buffering, i.e. assembles a sequence on n packets P_1, P_2, ... P_n before the first packet (in encrypted form) is sent across the network, then I beleive packets P_2 ... P_n are not susceptible to the known iv attacks: Their contents is fixed before the attacker learns their iv:s. So if you make sure that each such sequence of packets starts with an SSH_MSG_IGNORE packet P_0, no other packets have their iv:s known in advance. This solution is impractical in my implementation, as I buffer the data to be written later, after encryption, so I hope we can find other solutions. Adding SSH_MSG_IGNORE at the end of the sequence is easier, and I'm considering doing that, to make traffic analysis harder. (And furthermore, the sequence of packets above need not correspond at all to actual ip-packets: ssh-packet boundaries and ip-packet boundaries are independent. For instance, one could arrange that every ip-packet that is transmitted starts and ends with a partial SSH_MSG_IGNORE packet, and as the length fields are encrypted. That would make it hard for an attacker to even see the ssh-packet boundaries). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 07:41:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09571 for ; Thu, 21 Mar 2002 07:41:42 -0500 (EST) Received: (qmail 5476 invoked by uid 605); 21 Mar 2002 12:41:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5403 invoked from network); 21 Mar 2002 12:41:39 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 21 Mar 2002 12:41:39 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id BB4298361C0; Thu, 21 Mar 2002 13:41:38 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id NAA24254; Thu, 21 Mar 2002 13:41:38 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Joseph Galbraith" Cc: Subject: Re: Internationaliztion: UTF-8 for file names References: <005f01c1d05d$d2343fa0$4d00a8c0@galb.vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 21 Mar 2002 13:41:37 +0100 In-Reply-To: <005f01c1d05d$d2343fa0$4d00a8c0@galb.vandyke.com> Message-ID: Lines: 57 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Joseph Galbraith" writes: > I've now read the NFS specification on the matter > [RFC3010, section 11.] NFS elected to not deal > with the normalization. I don't think that's correct. NFSv4 doesn't require normalization on the wire, but it *does* say that implementations must deal properly with normalization. Quote of the end of section 11 (my enphasis): The NFS version 4 protocol does not mandate the use of a particular normalization form at this time. A later revision of this specification may specify a particular normalization form. Therefore, the server and client can expect that they may receive unnormalized characters within protocol requests and responses. If the operating environment requires normalization, then the implementation *MUST NORMALIZE* the various UTF-8 encoded strings within the protocol before presenting the information to an application (at the client) or local file system (at the server). I admit the text is a little vague, but my interpretation is that if the operating system's open() function deals properly with unicode equivalence and do the right thing (unlikely on a unix system, don't know about windows), then the nfs implementation can pass filenames directly to open without normalizing then. However, if the open function distinguishes between various equivalent forms of filenames (i.e. not implementing unicode equivalence in the way that is *required* for unicode conformance), then the NFS code must perform normalization to the form the rest of the system uses. I'd prefer always sending normalized data on the wire, but it is acceptable with unnormalized data as long as implementations are *required* to do the right thing. > So, for example, trying to negotiate the > char-set in use during protocol startup or > even on a per path basis, is insufficient. I don't understand why you can't negotiate characterset using some extension at the initial sftp handshake. I understand that there are some problems with what rfc 3010 calls "local character sets", but I see no problem with an extension that you use at startup that says "let's use the universal utf8 characterset/encoding". I also find the discussion in RFC3010 a little strange. If one ever uses different character sets for different components of a path name, one should expect some problems. I agree totally with that. But that isn't a problem with sftp or nfs: you'll get about the same problems if everything is on a single local filesystem. So I'll put those problems in in the "broken local configuration" category. I think the best way forward with utf8 support is that someone who wants it writes up draft specifying an extension for enabling utf8 file names (or an extension for negotiating arbitrary character sets), and then we can iron out the details in the wg. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 09:08:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10919 for ; Thu, 21 Mar 2002 09:08:01 -0500 (EST) Received: (qmail 14666 invoked by uid 605); 21 Mar 2002 14:07:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14658 invoked from network); 21 Mar 2002 14:07:57 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 21 Mar 2002 14:07:57 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02439; Thu, 21 Mar 2002 07:07:50 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25262; Thu, 21 Mar 2002 09:07:49 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2LE6Tgw020932; Thu, 21 Mar 2002 09:06:29 -0500 (EST) Message-Id: <200203211406.g2LE6Tgw020932@thunk.East.Sun.COM> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) cc: Wei Dai , ietf-ssh@netbsd.org Subject: Re: potential disclaimer for the transport draft. In-Reply-To: Your message of "21 Mar 2002 13:11:43 +0100." Reply-to: sommerfeld@east.sun.com Date: Thu, 21 Mar 2002 09:06:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > That's right, but if the implementation does some buffering, i.e. > assembles a sequence on n packets > > P_1, P_2, ... P_n > > before the first packet (in encrypted form) is sent across the > network, then I beleive packets P_2 ... P_n are not susceptible to the > known iv attacks: Their contents is fixed before the attacker learns > their iv:s. For what it's worth, this matches my analysis. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:02:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12802 for ; Thu, 21 Mar 2002 10:02:10 -0500 (EST) Received: (qmail 8851 invoked by uid 605); 21 Mar 2002 15:02:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8844 invoked from network); 21 Mar 2002 15:02:08 -0000 Received: from thufir.bluecom.no (217.118.32.12) by mail.netbsd.org with SMTP; 21 Mar 2002 15:02:08 -0000 Received: from delhi (a217-118-46-124.bluecom.no [217.118.46.124]) by thufir.bluecom.no (8.11.5/8.11.5) with SMTP id g2LF26315972 for ; Thu, 21 Mar 2002 16:02:07 +0100 Message-ID: <00cd01c1d0e9$32503840$7c2e76d9@delhi> From: "Benjamin Bruheim" To: Subject: SSH2 Encrypted Private Key Date: Thu, 21 Mar 2002 16:00:20 +0100 Organization: In/Out Bergen MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA12802 Hello, I'm currently doing an implementation of ssh; I haven't got far, because I'm wondering, where can I find info on the format of SSH2 Encrypted Private Keys? The public key has its own proposal though. I may implement the RSA-keys (who look almost the same :) ), but I can't find any formal format-descriptions. // Benjamin Bruheim From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:06:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12937 for ; Thu, 21 Mar 2002 10:06:08 -0500 (EST) Received: (qmail 10530 invoked by uid 605); 21 Mar 2002 15:06:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10522 invoked from network); 21 Mar 2002 15:06:07 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 21 Mar 2002 15:06:07 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA02580; Thu, 21 Mar 2002 16:06:03 +0100 (MET) Date: Thu, 21 Mar 2002 16:06:03 +0100 From: Markus Friedl To: Benjamin Bruheim Cc: ietf-ssh@netbsd.org Subject: Re: SSH2 Encrypted Private Key Message-ID: <20020321150603.GA2502@faui02> References: <00cd01c1d0e9$32503840$7c2e76d9@delhi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00cd01c1d0e9$32503840$7c2e76d9@delhi> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 21, 2002 at 04:00:20PM +0100, Benjamin Bruheim wrote: > I'm currently doing an implementation of ssh; I haven't got far, because I'm wondering, where can I find info on the format of SSH2 Encrypted Private Keys? The public key has its own proposal though. I may implement the RSA-keys (who look almost the same :) ), but I can't find any formal format-descriptions. there is no common format for private keys. (and you don't need it if you wnat to implement ssh2). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:15:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13190 for ; Thu, 21 Mar 2002 10:15:19 -0500 (EST) Received: (qmail 15359 invoked by uid 605); 21 Mar 2002 15:15:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15352 invoked from network); 21 Mar 2002 15:15:17 -0000 Received: from thufir.bluecom.no (217.118.32.12) by mail.netbsd.org with SMTP; 21 Mar 2002 15:15:17 -0000 Received: from delhi (a217-118-46-124.bluecom.no [217.118.46.124]) by thufir.bluecom.no (8.11.5/8.11.5) with SMTP id g2LFF1321574; Thu, 21 Mar 2002 16:15:04 +0100 Message-ID: <013b01c1d0eb$03e006f0$7c2e76d9@delhi> From: "Benjamin Bruheim" To: "Markus Friedl" Cc: References: <00cd01c1d0e9$32503840$7c2e76d9@delhi> <20020321150603.GA2502@faui02> Subject: Re: SSH2 Encrypted Private Key Date: Thu, 21 Mar 2002 16:13:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA13190 > there is no common format for private keys. > (and you don't need it if you wnat to implement ssh2). Well, this is a problem when creating a personal key, and you want to keep the key across several applications. As far as I can see, ssh.com's private ssh2-key is propriatary. OpenSSH's keys is just poorly documented (and I guess its only available in sourcecodes), or badly referenced. And, I will regret it if I invent my own format. :P // Benjamin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:17:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13304 for ; Thu, 21 Mar 2002 10:17:01 -0500 (EST) Received: (qmail 16566 invoked by uid 605); 21 Mar 2002 15:16:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16460 invoked from network); 21 Mar 2002 15:16:42 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 21 Mar 2002 15:16:42 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id QAA03434; Thu, 21 Mar 2002 16:16:39 +0100 (MET) Date: Thu, 21 Mar 2002 16:16:39 +0100 From: Markus Friedl To: Benjamin Bruheim Cc: ietf-ssh@netbsd.org Subject: Re: SSH2 Encrypted Private Key Message-ID: <20020321151639.GB2502@faui02> References: <00cd01c1d0e9$32503840$7c2e76d9@delhi> <20020321150603.GA2502@faui02> <013b01c1d0eb$03e006f0$7c2e76d9@delhi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013b01c1d0eb$03e006f0$7c2e76d9@delhi> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list OpenSSH uses a PEM format as provided by OpenSSL, e.g. $ openssl genrsa -out bla 1024 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:39:09 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14037 for ; Thu, 21 Mar 2002 10:39:08 -0500 (EST) Received: (qmail 27948 invoked by uid 605); 21 Mar 2002 15:39:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27941 invoked from network); 21 Mar 2002 15:39:06 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 21 Mar 2002 15:39:06 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 524729; Thu, 21 Mar 2002 08:39:08 -0700 Message-ID: <003701c1d0ed$f56b21b0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA1DB@lespaul.process.com> Subject: Re: SFTP owner, group and mode flags... Date: Thu, 21 Mar 2002 08:34:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > The proposals for changes to the method in which user & group information > and ACLs sound good. I agree with the general idea of using mechanisms that > have been developed in existing RFCs. > > >* Change the mode field to a type field, which indicates > > the type of the file, and make it a byte field. > > I don't understand what you are talking about here. The only place that I > could find the word "mode" used in the document was in the mention that > files are always opened in binary mode. (Which I think is an error.) Sorry, I should have been more explicit here. What I'm saying is that currently there are two pieces of information in permissions field: * The type of file (directory, normal, special, etc.) * And the access rights for the owner, the group, and everyone. I was proposing that we split this. We still need a type field. This information could be encoded as a BYTE, with enumerations defined in the draft. The access rights information would be encoded as an ACL. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 10:59:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14576 for ; Thu, 21 Mar 2002 10:59:07 -0500 (EST) Received: (qmail 6434 invoked by uid 605); 21 Mar 2002 15:59:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6426 invoked from network); 21 Mar 2002 15:59:04 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 21 Mar 2002 15:59:04 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 524826; Thu, 21 Mar 2002 08:59:06 -0700 Message-ID: <005601c1d0f0$bf75ee70$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: References: <005f01c1d05d$d2343fa0$4d00a8c0@galb.vandyke.com> Subject: Re: Internationaliztion: UTF-8 for file names Date: Thu, 21 Mar 2002 08:54:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I also find the discussion in RFC3010 a little strange. If one ever > uses different character sets for different components of a path name, > one should expect some problems. I agree totally with that. But that > isn't a problem with sftp or nfs: you'll get about the same problems > if everything is on a single local filesystem. So I'll put those > problems in in the "broken local configuration" category. That depends on the operating system. NT is perfectly capable of supporting this, and having it work localy. I name a directory using cyrillic, and put files named in Japenese inside of it. Not a problem. That's because NT uses a unicode to store file names. (Now, I admit, this won't work if you are using the FAT file system, but that's a different story, but it is possible for this to work perfectly using NTFS.) My guess is that there are other filesystems out there that use unicode for file names. BeOS's filesystem did, if I remember correctly. > I think the best way forward with utf8 support is that someone who > wants it writes up draft specifying an extension for enabling utf8 > file names (or an extension for negotiating arbitrary character sets), > and then we can iron out the details in the wg. Well, we could go that route, however, in that case, when UTF-8 is not in use, we must specify what charset is in use, according to my reading of RFC2277 3.1. Also, my reading of RFC2277 3.1 leads me to believe that not using UTF-8 is at least discouraged for new protocols. I really think just specifying filenames as being encoded in UTF-8 is the best solution. UTF-8 is already used throughout the other pieces of SSH; it complies with RFC2277, and it allows systems that can support multiple char-sets to work. It also doesn't require us to register with IANA charset specifications, or try to use some existing specification (which unless it's Code Page information is hard for me -- and I really don't want anyone in the world to even think about code pages unless they MUST :-) Not to mention that code pages are poorly specificied and non-standard. We might be able to go with some other solution and still be in compliance with RFC2277 as long as UTF-8 could be negotiated, but that just complicates things because then we have to deal with a client and server that can't come to an agreement on what charset to use. I really think my users would be happiest if this stuff just worked, which is possible with UTF-8 required, but seems unlikely otherwise. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 11:24:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15691 for ; Thu, 21 Mar 2002 11:24:33 -0500 (EST) Received: (qmail 17620 invoked by uid 605); 21 Mar 2002 16:24:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17611 invoked from network); 21 Mar 2002 16:24:31 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 21 Mar 2002 16:24:31 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 524893; Thu, 21 Mar 2002 09:24:33 -0700 Message-ID: <005b01c1d0f4$4d967c30$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Damien Miller" Cc: References: Subject: Re: SFTP owner, group and mode flags... Date: Thu, 21 Mar 2002 09:20:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > * In order to reduce overhead of readdir and > > stat operations, which will increase with > > the above, we add a parameter to the opendir > > and stat protocols to allow the client to > > specify what attributes it is interested in. > > I don't know whether this is necessary. If the longname is eliminated, > then I don't think the replies will be very large. Sorry, I should have tied this better with the last point (which I've moved below): > > * We allow a server to advertise what attributes > > it can provide and what attributes it can provide > > efficiently, but require servers to tolerantly > > ignore requests for attributes it can't provide > > and require that clients be prepared to not receive > > attributes that the server has advertised. > > > > For example, under NT, we would advertise that we > > can provide User, Group and ACL information, but > > that they are expensive. > > What do you mean by expensive? I am a little ambivalent against > advertising capabilities, especially ones relating to whether certain > operations are "expensive" for the host OS. Here's what I'm thinking. It is expensive for me to get user, group and security information. I.e., returning user, group and security information slows a directory listing down by more than an order of magnitude. So, right now, since I have no clue whether the client really wants the information, I never return it. If, on the other hand, I could both tell the client that it was relatively expensive to ask for that information, and know that the client really wanted to use the data, I could return the information. The client could make an informed decesion about whether it wanted the security information or not, knowing that it is expensive for my server to acquire that information. And my server would know that the client really intended to do something with the information if it asked for it. Even if we didn't allow the server to advertise, it would still be useful to know what the client wanted. > > * Change the mode field to a type field, which indicates > > the type of the file, and make it a byte field. > > Can you be more specific? Sorry, I've had a couple of questions on this; I definitely wasn't clear (and may have used the wrong term, too.) There are two peices of information encoded into the permissions field of that sftp attribute structure. * The file type * The access control information (permissions) I was proposing that we seperate out the file type into a BYTE field, and do away with the permissions field in favor of ACLs. However, I don't feel strongly about doing away with the permissions field. In fact, after thinking about it, I realized that it might not be so easy to encode things like the sticky bit in an ACL, so there may be good reason not to. But, I do feel strongly about splitting the two pieces of information into seperate fields. In particular, my NT server can't send valid information for the permissions field, but can send valid type information. So right now, it lies about the permissions. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 11:58:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17342 for ; Thu, 21 Mar 2002 11:58:31 -0500 (EST) Received: (qmail 5970 invoked by uid 605); 21 Mar 2002 16:58:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5963 invoked from network); 21 Mar 2002 16:58:30 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 21 Mar 2002 16:58:30 -0000 Received: from mosquito.inet.org (ssh.extremenetworks.com [10.0.1.139]) by gnat.inet.org (Postfix) with ESMTP id E80AF67103; Thu, 21 Mar 2002 12:21:02 -0500 (EST) Date: Thu, 21 Mar 2002 11:58:02 -0500 Subject: Re: potential disclaimer for the transport draft. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ietf-ssh@netbsd.org To: Wei Dai From: RJ Atkinson In-Reply-To: <20020320202406.B14107@eskimo.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, March 20, 2002, at 11:24 , Wei Dai wrote: > On Tue, Mar 19, 2002 at 09:16:44AM -0500, Bill Sommerfeld wrote: >>> On any particular system, it's probably not the biggest hole, but it >>> quite likely is the biggest hole on *some* real-world systems. >> >> I think you severely underestimate how many latent undiscovered >> security holes are out there at the moment.. I don't think we have >> *any* reason to believe that. > > Ok, let me rephrase that: it quite likely is the biggest *known* hole on > some real-world systems. I actually think that your revised claim is extremely unlikely to be the case. In particular, "known" and "widely known" aren't the same. Also, several of us are not convinced your issue is a "big known hole", though I think everyone considers it a serious issue. > The point remains that we can't be confident that it's not > a threat to any real world system. No one has said made the claim that you knock down. This thread is about risk management, not whether we think the current SSH spec is perfectly secure. Delaying the spec over this level of nit is not a responsible posture for the WG, IMHO, given that we can change the attacker's work function from [wiretap cleartext passwords] to [computationally expensive cryptographic attack] by moving forward as-is today. I fully support Bill's proposed language and shipping the documents as Proposed Standard as soon as possible. Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 21 12:06:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17769 for ; Thu, 21 Mar 2002 12:06:58 -0500 (EST) Received: (qmail 11129 invoked by uid 605); 21 Mar 2002 17:06:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11122 invoked from network); 21 Mar 2002 17:06:54 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 21 Mar 2002 17:06:54 -0000 Received: from [192.168.0.3] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 524972 for ietf-ssh@netbsd.org; Thu, 21 Mar 2002 10:06:56 -0700 Message-ID: <001101c1d0fa$3976c150$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: References: Subject: Re: potential disclaimer for the transport draft. Date: Thu, 21 Mar 2002 10:02:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I fully support Bill's proposed language and shipping the documents > as Proposed Standard as soon as possible. Ditto. Lets ship 'em. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:22:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20670 for ; Fri, 22 Mar 2002 08:22:04 -0500 (EST) Received: (qmail 28945 invoked by uid 605); 22 Mar 2002 13:15:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28938 invoked from network); 22 Mar 2002 13:15:23 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 13:15:23 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA27197 for ; Fri, 22 Mar 2002 14:16:08 +0100 From: "denis bider" To: Subject: RE: closing a channel Date: Fri, 22 Mar 2002 14:16:39 +0100 Message-ID: <000901c1d1a3$cd869bf0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020322130538.GA769@faui02> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Much like a black man is still a man, and a brown > > cow is still a cow, I would think that extended > > data is still data - especially since data and > > extended data consume the same window. > > it could be some kind of out-of-band thing. I find it difficult to imagine how it could be out of band if it consumes the same window. > are WINDOW adjust messages allowed after EOF? Good point. I would vote no, because they don't make any sense after EOF. But I think this should be specified more clearly in the draft. Anyone? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:29:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20814 for ; Fri, 22 Mar 2002 08:29:34 -0500 (EST) Received: (qmail 7070 invoked by uid 605); 22 Mar 2002 12:25:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7063 invoked from network); 22 Mar 2002 12:25:30 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Mar 2002 12:25:30 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA29845 for ietf-ssh@netbsd.org; Fri, 22 Mar 2002 13:25:28 +0100 (MET) Date: Fri, 22 Mar 2002 13:25:28 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: closing a channel Message-ID: <20020322122528.GA29756@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, is it allowed to send an EXTENDED data message after sending an EOF message? Is extended data considered channel data? The draft says: 3.3 Closing a Channel When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:31:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20879 for ; Fri, 22 Mar 2002 08:31:02 -0500 (EST) Received: (qmail 22257 invoked by uid 605); 22 Mar 2002 13:03:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22250 invoked from network); 22 Mar 2002 13:03:42 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 13:03:42 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA27149 for ; Fri, 22 Mar 2002 14:04:23 +0100 From: "denis bider" To: Subject: RE: closing a channel Date: Fri, 22 Mar 2002 14:04:53 +0100 Message-ID: <000701c1d1a2$296b2780$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020322122528.GA29756@faui02> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Hi, is it allowed to send an EXTENDED data > message after sending an EOF message? > Is extended data considered channel data? Much like a black man is still a man, and a brown cow is still a cow, I would think that extended data is still data - especially since data and extended data consume the same window. This should be no issue. However, I think the draft should be more clear about how EOF relates to channel requests. It doesn't say anything about whether requests and responses can be sent after EOF has been sent. In the current implementations, there probably isn't a channel request that it would make sense sending after EOF has been sent. But in general, there might be applications where this could be reasonable, e.g. if the channel request results in only a request response and doesn't cause any data to be sent in either direction. Does the draft allow channel requests and responses to be sent after EOF or not? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:32:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20915 for ; Fri, 22 Mar 2002 08:32:23 -0500 (EST) Received: (qmail 23272 invoked by uid 605); 22 Mar 2002 13:05:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23259 invoked from network); 22 Mar 2002 13:05:44 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Mar 2002 13:05:44 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id OAA01171; Fri, 22 Mar 2002 14:05:38 +0100 (MET) Date: Fri, 22 Mar 2002 14:05:38 +0100 From: Markus Friedl To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020322130538.GA769@faui02> References: <20020322122528.GA29756@faui02> <000701c1d1a2$296b2780$0201010a@intergalactic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c1d1a2$296b2780$0201010a@intergalactic> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 02:04:53PM +0100, denis bider wrote: > > Hi, is it allowed to send an EXTENDED data > > message after sending an EOF message? > > Is extended data considered channel data? > > Much like a black man is still a man, and a brown cow is still a cow, I > would think that extended data is still data - especially since data and > extended data consume the same window. This should be no issue. it could be some kind of out-of-band thing. are WINDOW adjust messages allowed after EOF? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:38:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21047 for ; Fri, 22 Mar 2002 08:38:14 -0500 (EST) Received: (qmail 12626 invoked by uid 605); 22 Mar 2002 13:38:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12618 invoked from network); 22 Mar 2002 13:38:12 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Mar 2002 13:38:12 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id OAA02860; Fri, 22 Mar 2002 14:38:05 +0100 (MET) Date: Fri, 22 Mar 2002 14:38:05 +0100 From: Markus Friedl To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020322133804.GA2135@faui02> References: <20020322130538.GA769@faui02> <000901c1d1a3$cd869bf0$0201010a@intergalactic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000901c1d1a3$cd869bf0$0201010a@intergalactic> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 02:16:39PM +0100, denis bider wrote: > > > Much like a black man is still a man, and a brown > > > cow is still a cow, I would think that extended > > > data is still data - especially since data and > > > extended data consume the same window. > > > > it could be some kind of out-of-band thing. > > I find it difficult to imagine how it could be out of band if it consumes > the same window. hm, I still cannot find where the draft says that it's a protocol violation, EOF is just a hint. You're just not allowed to send data after CLOSE... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:53:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21297 for ; Fri, 22 Mar 2002 08:53:00 -0500 (EST) Received: (qmail 19114 invoked by uid 605); 22 Mar 2002 13:52:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19107 invoked from network); 22 Mar 2002 13:52:57 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 13:52:56 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id OAA27283; Fri, 22 Mar 2002 14:53:29 +0100 From: "denis bider" To: "'Markus Friedl'" , Subject: RE: closing a channel Date: Fri, 22 Mar 2002 14:53:59 +0100 Message-ID: <000b01c1d1a9$05245570$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020322133804.GA2135@faui02> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > hm, I still cannot find where the draft says that > it's a protocol violation, EOF is just a hint. > You're just not allowed to send data after CLOSE... Where does the draft say that EOF is just a 'hint'? What it says is this: When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. I.e.: it says that you _should_ send EOF when you will no longer send more data. What it _doesn't_ say is that you "may" send more data after you have sent EOF. I think the draft's implication here is that it would be unacceptable to send more data after you have sent EOF. I find your interpretation rather strange. I do agree, however, that the draft should be clarified with regard to this. I didn't think it was ambiguous, but seeing that someone like you can interpret that section so differently from myself, it clearly requires clarification. Just one sentence is not enough. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 08:55:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21382 for ; Fri, 22 Mar 2002 08:55:24 -0500 (EST) Received: (qmail 21696 invoked by uid 605); 22 Mar 2002 13:55:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21624 invoked from network); 22 Mar 2002 13:55:11 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Mar 2002 13:55:11 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 2F5A682F488; Fri, 22 Mar 2002 14:55:10 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id OAA24591; Fri, 22 Mar 2002 14:55:09 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Joseph Galbraith" Cc: Subject: Re: Internationaliztion: UTF-8 for file names References: <005f01c1d05d$d2343fa0$4d00a8c0@galb.vandyke.com> <005601c1d0f0$bf75ee70$4d00a8c0@galb.vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 22 Mar 2002 14:55:08 +0100 In-Reply-To: <005601c1d0f0$bf75ee70$4d00a8c0@galb.vandyke.com> Message-ID: Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Joseph Galbraith" writes: > I name a directory using cyrillic, and put files named > in Japenese inside of it. Not a problem. That's because > NT uses a unicode to store file names. Then I'd say you're not using different character sets, all parts of the filename is stored as unicode in the filesystem. There's a system wide policy that filenames are always stored in unicode. In this case (now I'm talking about a generic OS with unicode filenames and locales; I don't know if and how windows locales work in detail), if I use a locale that says that I only understand filenames in latin-x, filenames I create will be converted from latin x to unicode before they reach the real filesystem. When I access the filesystem, names that are representable in latin-x get converted before I see them, and if I want to access files using japanese filenames, I'll simply lose in one way or the other. I claim this problem is *irrelevant* for NFS and sftp: It's good enough if things that *work* using a local filesystem works over the network. For configurations that cause trouble even on a local filesystem, it's fine if we don't get it right either (although we should fail as gracefully as possible). > My guess is that there are other filesystems > out there that use unicode for file names. > BeOS's filesystem did, if I remember correctly. Unix filesystems (or any eight-bit clean filesystem) support unicode, the only thing you need to do is to create a system wide policy that says that all filenames should use utf-8 using some particular normalization form, in particular normalization is needed for the "/" character. > Well, we could go that route, however, in that case, > when UTF-8 is not in use, we must specify what charset > is in use, according to my reading of RFC2277 3.1. I'll not argue about IETF policies, as I'm not familiar enough with them. > I really think just specifying filenames as being encoded > in UTF-8 is the best solution. UTF-8 is already used > throughout the other pieces of SSH; it complies with RFC2277, > and it allows systems that can support multiple char-sets to > work. That is acceptable to me IF and ONLY IF the spec says which party is responsible for implementing the unicode equivalence requirements. (I don't recall off hand what the other ssh specs says about normalization of passwords and usernames, but they are also *badly* broken if they neglect the normalization issues). > I really think my users would be happiest if this stuff just > worked, which is possible with UTF-8 required, but seems > unlikely otherwise. As I said above, I can accept utf-8 on the wire, iff the normalization stuff is addressed properly. But you should be aware that it does *not* magically solve all character set problems problems. For instance, consider a unix system where one user uses latin-1 for his filenames, and another user uses utf-8. The server can't know this, perhaps there's a system wide policy that utf-8 should be used, and the latin-1 user ignores it. Then he will not be able to access his files over sftp (and he actually has a *better* chance with the current sftp protocol: sftp will work perfectly as long as he uses it between similar systems). Don't get me wrong, I'm not saying that handling this situation right should be a requirement for sftp (it's similar to the situation described in my first paragraphs that I argue we need not solve), I'm just giving an example of a real problem that isn't solved by adopting utf8 on the wire. utf-8 is a more or less universal character set. It is not a magic wand. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 09:00:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21566 for ; Fri, 22 Mar 2002 09:00:32 -0500 (EST) Received: (qmail 24441 invoked by uid 605); 22 Mar 2002 14:00:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24432 invoked from network); 22 Mar 2002 14:00:23 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Mar 2002 14:00:23 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id PAA03651; Fri, 22 Mar 2002 15:00:09 +0100 (MET) Date: Fri, 22 Mar 2002 15:00:09 +0100 From: Markus Friedl To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020322140009.GA3431@faui02> References: <20020322133804.GA2135@faui02> <000b01c1d1a9$05245570$0201010a@intergalactic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c1d1a9$05245570$0201010a@intergalactic> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 02:53:59PM +0100, denis bider wrote: > I think the draft's implication here is that it would be > unacceptable to send more data after you have sent EOF. Well, I agree, that not more CHANNEL_DATA should be sent after CHANNEL_EOF, but to me CHANNEL_EXTENDED_DATA is a different channel w/o explicit EOF. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 09:05:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21692 for ; Fri, 22 Mar 2002 09:05:11 -0500 (EST) Received: (qmail 26298 invoked by uid 605); 22 Mar 2002 14:05:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26185 invoked from network); 22 Mar 2002 14:05:07 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Mar 2002 14:05:07 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id PAA03819; Fri, 22 Mar 2002 15:05:05 +0100 (MET) Date: Fri, 22 Mar 2002 15:05:05 +0100 From: Markus Friedl To: denis bider Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020322140504.GA3793@faui02> References: <20020322133804.GA2135@faui02> <000b01c1d1a9$05245570$0201010a@intergalactic> <20020322140009.GA3431@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020322140009.GA3431@faui02> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 03:00:09PM +0100, Markus Friedl wrote: > On Fri, Mar 22, 2002 at 02:53:59PM +0100, denis bider wrote: > > I think the draft's implication here is that it would be > > unacceptable to send more data after you have sent EOF. > > Well, I agree, that not more CHANNEL_DATA should be sent > after CHANNEL_EOF, but to me CHANNEL_EXTENDED_DATA is > a different channel w/o explicit EOF. a different data stream w/o explicit EOF, but I'm probably wrong :) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 09:27:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22330 for ; Fri, 22 Mar 2002 09:27:33 -0500 (EST) Received: (qmail 7260 invoked by uid 605); 22 Mar 2002 14:27:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7253 invoked from network); 22 Mar 2002 14:27:31 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 14:27:31 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id PAA27371 for ; Fri, 22 Mar 2002 15:28:15 +0100 From: "denis bider" To: Subject: Draft authors' comments on EOF? (Was: RE: closing a channel) Date: Fri, 22 Mar 2002 15:28:45 +0100 Message-ID: <000e01c1d1ad$e0bbb570$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020322140504.GA3793@faui02> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Ylonen, Kivinen, Saarinen, Rinne, Lehtinen - you are the authors of the SSH Connection Protocol draft. What do you think? Will you augment the draft with a more concise specification of what EOF means and what it doesn't? Especially with regard to the following: - Is EOF just a hint or not? (I hope it's not.) - Does it apply to extended data or not? (I hope it does.) - How does it relate to channel requests and responses? What about window adjustment messages? Are any of these allowed to be sent after EOF? Thanks, denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 13:41:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28397 for ; Fri, 22 Mar 2002 13:41:22 -0500 (EST) Received: (qmail 22622 invoked by uid 605); 22 Mar 2002 18:41:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22543 invoked from network); 22 Mar 2002 18:41:17 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Mar 2002 18:41:17 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 61CF583613A; Fri, 22 Mar 2002 19:41:16 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id TAA24638; Fri, 22 Mar 2002 19:41:16 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 22 Mar 2002 19:41:14 +0100 In-Reply-To: <20020322122528.GA29756@faui02> Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > Hi, is it allowed to send an EXTENDED data message > after sending an EOF message? Is extended data > considered channel data? I'd say extended data count as data. Sending EOF means that you won't send either ordinary data or extended data anymore. (On the server side, I have a counter on the session channel. When I get EOF on the process' stdout or stderr, I decrement the counter. When it reaches zero, I send EOF on the channel). My reasons for this: Ordinary data and extended data are treated as a single stream for flow control. It would be odd to treat them differently with respect to EOF only. Allowing extended data after EOF means that there's no way to indicate EOF on the extended data channel; the other end can never know that it shouldn't expect more data. That's bad. Consider a client that wants to wait until the server will send no more data of any kind, and then send some final CHANNEL_REQUESTs before closing the channel. It might be desirable to have a wider separation between stdout and stderr data than is provided by the extended data hack. But if we want that, the Right Way is create a separate channel for stderr, with independent flow control and working EOF indication. One should invent a message byte CHANNEL_OPEN string "session-stderr" uint32 channel ; The session we want to attach this channel to or something like that. My answers to some of the other questions raised in this thread: Can one send CHANNEL_REQUEST after EOF? I'd say yes. In particular, the order in which my server sends CHANNEL_EOF and CHANNEL_REQUEST "exit-status" depends on the the relative timing of i/o and the SIGCHLD signal, and is esssentially random. Can one send WINDOW_ADJUST after EOF? This is an ill-posed question. The EOF message I send and the WINDOW_ADJUST messages I send affects different directions of the channel, and they are therefore independent. I can send EOF as soon as the channel is created, and then go on sending lots of WINDOW_ADJUST messages while I download a GB or two of data. Can I send WINDOW_ADJUST after I *received* EOF? Yes, the other end can't know the exact sequence of events anyway. And turning it around, what should I do if I *receive* WINDOW_ADJUST after I *sent* EOF? I'd say such messages should be silently ignored; the other end may well have sent the WINDOW_ADJUST before seeing my EOF. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 14:50:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00053 for ; Fri, 22 Mar 2002 14:50:20 -0500 (EST) Received: (qmail 25529 invoked by uid 605); 22 Mar 2002 19:50:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25521 invoked from network); 22 Mar 2002 19:50:16 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 22 Mar 2002 19:50:16 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id g2MJnuT16464 for ; Fri, 22 Mar 2002 21:49:56 +0200 (EET) Received: (qmail 26422 invoked from network); 22 Mar 2002 19:49:56 -0000 Received: from unknown (HELO loisteputkivalaisin.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Mar 2002 19:49:56 -0000 Received: (from tri@localhost) by loisteputkivalaisin.hel.fi.ssh.com (8.9.3/8.9.3) id XAA29871; Fri, 22 Mar 2002 23:52:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15515.42903.505928.201192@loisteputkivalaisin.hel.fi.ssh.com> Date: Fri, 22 Mar 2002 23:52:23 +0200 From: Timo J Rinne To: "denis bider" Cc: Subject: Re: Draft authors' comments on EOF? (Was: RE: closing a channel) In-Reply-To: <000e01c1d1ad$e0bbb570$0201010a@intergalactic> References: <20020322140504.GA3793@faui02> <000e01c1d1ad$e0bbb570$0201010a@intergalactic> Reply-to: tri@ssh.com Organization: SSH Communications Security, Espoo, Finland X-Face: 7N&%4=;/9+e`m7vVp3kmZ^FZ~;TBHua/@dBeFi*{xAoyz+8feePXCUmOK[GaY*0[QU`{lo *D3.D?xc>nBKUHDdXo)*OiG-MGf-a2dCZ5{yYMZV9:+H1h:%g$']XOPwUx{<5fH@l?+U8B Cr!lG(V:g=`_gdg86&u$/ez/jG_H3uU8!TB&ZuEz-BKqfBL3HGS@oA#,GsugP3o3.ckI- Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit denis bider writes: > Ylonen, Kivinen, Saarinen, Rinne, Lehtinen - you are the authors of the SSH > Connection Protocol draft. What do you think? Will you augment the draft > with a more concise specification of what EOF means and what it doesn't? > > Especially with regard to the following: > > - Is EOF just a hint or not? (I hope it's not.) No. It does have very clear semantics. > - Does it apply to extended data or not? (I hope it does.) Yes. No more data to the channel after EOF. At least that was the idea when I was more involved with the drafts. And extended data is data too in this respect. > - How does it relate to channel requests and responses? What about window > adjustment messages? Are any of these allowed to be sent after EOF? Nope, if they refer to the closed channel. //Rinne From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 15:06:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00503 for ; Fri, 22 Mar 2002 15:06:09 -0500 (EST) Received: (qmail 4542 invoked by uid 605); 22 Mar 2002 20:06:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4535 invoked from network); 22 Mar 2002 20:06:06 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 20:06:06 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id VAA28001 for ; Fri, 22 Mar 2002 21:06:50 +0100 From: "denis bider" To: Subject: RE: Draft authors' comments on EOF? (Was: RE: closing a channel) Date: Fri, 22 Mar 2002 21:07:20 +0100 Message-ID: <001901c1d1dd$2ce49500$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <15515.42903.505928.201192@loisteputkivalaisin.hel.fi.ssh.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > - How does it relate to channel requests and > > responses? What about window adjustment messages? > > Are any of these allowed to be sent after EOF? > > Nope, if they refer to the closed channel. But "after EOF" does not imply that EOF has been sent in both directions. Presumably, the situation would be that one side has sent EOF, while the other side continues to stream data. In this situation, is the side that has already sent EOF allowed to send a channel request or a response to the other side's request, or not? I would say yes, it ought to be allowed. But I think this is something that should be clearly stated in the specification, not something we should be wondering about right now. I think the specification must be amended to clarify this. I imagine that is the whole point of having the specification in the first place. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 16:30:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02169 for ; Fri, 22 Mar 2002 16:30:56 -0500 (EST) Received: (qmail 22661 invoked by uid 605); 22 Mar 2002 21:30:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22654 invoked from network); 22 Mar 2002 21:30:54 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Mar 2002 21:30:54 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id B2CF983617F; Fri, 22 Mar 2002 22:30:53 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id WAA24672; Fri, 22 Mar 2002 22:30:53 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 22 Mar 2002 22:30:52 +0100 In-Reply-To: Message-ID: Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit I wrote: > Can one send CHANNEL_REQUEST after EOF? I'd say yes. In particular, > the order in which my server sends CHANNEL_EOF and CHANNEL_REQUEST > "exit-status" depends on the the relative timing of i/o and the > SIGCHLD signal, and is esssentially random. Let me provide an admittedly contrived, but I hope still illustrative, example. Say we have a unix environment, and the server receives a CHANNEL_REQUEST "exec" request on a session channel with the following command line: "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17" The server forks and execs (assuming the user's login shell is /bin/sh) the subprocess /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17" What my server will send to the client in this situation is CHANNEL_DATA "foo\n" # The data the process sent to its stdout CHANNEL_EOF # The process closed its stdout and stderr ... delay of about 30 seconds ... CHANNEL_REQUEST "exit-status" 17 CHANNEL_CLOSE I believe this is a reasonable use of the protocol, and it obviously sends a CHANNEL_REQUEST long after the CHANNEL_EOF. What are the alternatives? * One could delay the CHANNEL_EOF until after the CHANNEL_REQUEST message. I think that's bad, there's no reson not to tell the client right away that it will get no more data on the channel. * One could wait just a short while for the process to die, and if it doesn't die, just send CHANNEL_EOF and CHANNEL_CLOSE anyway. The client won't get any exit-status. This is ugly: For a start, what's a reasonable "short while"? It happens in practice that the server detects EOF before it gets to handle the SIGCHLD signal process death. I don't want a race-condition to determine whether or not the client gets any exit-status message (I've had such race conditions in the past, I hope I have fixed them by now). * Brutally kill the process after we detect EOF, so we don't need to wait to send exit-status/exit-signal, or send a lying exit-status message. I don't like any of these alternatives *at all*, and I believe the behaviour described above, with CHANNEL_REQUEST "exit-status" sent a while after CHANNEL_EOF, is the best and most natural way to report the sequence of events to the client. Please don't ban it. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 17:34:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03268 for ; Fri, 22 Mar 2002 17:34:18 -0500 (EST) Received: (qmail 29099 invoked by uid 605); 22 Mar 2002 22:34:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29070 invoked from network); 22 Mar 2002 22:34:10 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 22 Mar 2002 22:34:10 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id XAA28282; Fri, 22 Mar 2002 23:34:52 +0100 From: "denis bider" To: "=?iso-8859-1?Q?'Niels_M=F6ller'?=" , Subject: RE: closing a channel Date: Fri, 22 Mar 2002 23:35:21 +0100 Message-ID: <001e01c1d1f1$da864280$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > CHANNEL_DATA "foo\n" > CHANNEL_EOF > ... delay of about 30 seconds ... > CHANNEL_REQUEST "exit-status" 17 > CHANNEL_CLOSE This looks very reasonable. Does your server behave the same if the client sends EOF immediately after issuing the exec request? That's what my clients do - when issuing an exec request, they let the server know immediately that they're not going to send any data. I find it problematic that the specification doesn't say who is supposed to close the session channel. Can the client rely on the server closing the channel after the child process exits? If not, can the client rely on the server sending an 'exit-status' message? Since the draft's wording about 'exit-status' is that its use is only "recommended", and since the draft doesn't say anything about the server closing the channel when the child process terminates, my implementation currently assumes that it cannot rely on any of that. So, preferring to be safe than sorry, it automatically closes the channel after EOF has been both sent and received. But if I knew that I can rely on the server to send 'exit-status' or to close the channel upon child process termination, I would prefer not to rush with my own CHANNEL_CLOSE so that I can possibly catch the program's exit code. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 22 22:45:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08343 for ; Fri, 22 Mar 2002 22:45:02 -0500 (EST) Received: (qmail 4727 invoked by uid 605); 23 Mar 2002 03:45:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4714 invoked from network); 23 Mar 2002 03:44:59 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 23 Mar 2002 03:44:59 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id TAA23257; Fri, 22 Mar 2002 19:44:57 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id TAA04227; Fri, 22 Mar 2002 19:44:57 -0800 (PST) Date: Fri, 22 Mar 2002 19:44:57 -0800 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020322194456.E17748@eskimo.com> References: <20020322122528.GA29756@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Fri, Mar 22, 2002 at 10:30:52PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Möller wrote: > * One could delay the CHANNEL_EOF until after the CHANNEL_REQUEST > message. I think that's bad, there's no reson not to tell the client > right away that it will get no more data on the channel. What's the purpose of CHANNEL_EOF, anyway? I thought it was used to tell the other side that no more data will be sent so that the other side can feel free to close the channel whenever it finishes sending its data. If you're going to send more information (e.g., the exit code) in the form of a CHANNEL_REQUEST after sending CHANNEL_EOF, then how does the other side know when it's safe to close the channel without losing information? On Fri, Mar 22, 2002 at 11:35:21PM +0100, denis bider wrote: > But if I knew that I can rely on the server to send 'exit-status' or to > close the channel upon child process termination, I would prefer not to rush > with my own CHANNEL_CLOSE so that I can possibly catch the program's exit > code. That's fine in the case of a shell command, but what about other types of channels where the concept of child process termination doesn't apply? My interpretation is that no channel data or requests should be sent after CHANNEL_EOF, but SSH_MSG_CHANNEL_SUCCESS and SSH_MSG_CHANNEL_FAILURE are allowed. I prefer this interpretation because it allows a simple rule for deciding when to initiate CHANNEL_CLOSE for all types of channels that ensures channels don't stay open after they're no longer useful. The rule is to do it as soon as both of the following two conditions are met: 1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data or requests to send) 2. CHANNEL_EOF has been received from the other side, or this side cannot process any more incoming channel data or requests. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 23 02:40:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18823 for ; Sat, 23 Mar 2002 02:40:00 -0500 (EST) Received: (qmail 12961 invoked by uid 605); 23 Mar 2002 07:39:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12953 invoked from network); 23 Mar 2002 07:39:58 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 23 Mar 2002 07:39:58 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id AA0358360C0; Sat, 23 Mar 2002 08:39:52 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id IAA24769; Sat, 23 Mar 2002 08:39:52 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider" Cc: Subject: Re: closing a channel References: <001e01c1d1f1$da864280$0201010a@intergalactic> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 23 Mar 2002 08:39:51 +0100 In-Reply-To: <001e01c1d1f1$da864280$0201010a@intergalactic> Message-ID: Lines: 92 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "denis bider" writes: > This looks very reasonable. Does your server behave the same if the client > sends EOF immediately after issuing the exec request? That's what my clients > do - when issuing an exec request, they let the server know immediately that > they're not going to send any data. The client's EOF request doesn't matter here, the server will close the channel as soon as the all of three events EOF on process stdout, EOF on process stderr, death of process, have occured. Earlier versions waited for the client to send EOF, but not all clients do that. It makes some sense to wait for the client's EOF, but for that to work we need the client to respont to exit-status with EOF, and exit-status isn't mandatory, so that gets pretty fragile. So I changed that behaviour a while ago after discussion on this list. > But if I knew that I can rely on the server to send 'exit-status' or to > close the channel upon child process termination, I would prefer not to rush > with my own CHANNEL_CLOSE so that I can possibly catch the program's exit > code. I think the best you can do is to rely on the server to send CHANNEL_CLOSE when the remote process is gone. I include the description on channel close from lsh/doc/NOTES below. Regards, /Niels EOF ON CHANNELS A typical channel (i.e. all channels created in the current implementation) are, at each end, connected to one or more fd:s for reading and writing. When the source fd(:s), i.e. the fd:s that we are reading, have no more data available, a CHANNEL_EOF message should be sent. As there may be several such fd:s, we use a counter SOURCES in the channel struct to keep track of the number of active source fd:s. When an fd is closed, the counter is decremented, and when it reaches zero, the CHANNEL_EOF message is sent. The decrementing of the counter is done by the close-callback for the fd, not by the read handler, as this is the easiest way to ensure that it is called exactly once whenever a fd dies. However, the sending of the CHANNEL_EOF message is done by the read handlers do_channel_write() and do_channel_write_extended(). This is because otherwise, eof on bidirectional fd:s migth be delayed until it is closed also for writing. There are more unsolved issues with bidirectional fd:s though, in particular tcp connections where one direction is closed (with shutdown()) long before the other. CLOSING CHANNELS The right conditions for closing a channel, and in particular a session, are even more subtle. The basic rules are: 1. When SSH_MSG_CHANNEL_CLOSE is both sent and received, the channel is killed. This is unconditionally required by the spec. 2. When SSH_MSG_CHANNEL_EOF is both sent and received, SSH_MSG_CHANNEL_CLOSE is sent. This is a rule with a few exceptions, controlled by the CHANNEL_CLOSE_AT_EOF flag, see below. These two rules are sufficient for most channel types. When looking at the channel close logic for session channels, one has to consider these three events that may occur in arbitrary order: * The client sends SSH_MSG_CHANNEL_EOF on the channel. * The server sends SSH_MSG_CHANNEL_EOF on the channel (this happens when there are no more processes which have the files the server has opened for stdout or stderr open). * The child process created by the server dies. An exit-status or exit-signal message is sent to the client. Previous versions of lshd handled these conditions as follows: It closed the channel according to rule (2) above, no exceptions. This causes other clients to hang, because they never send any SSH_MSG_CHANNEL_EOF. Using lsh did work right, only because it responded to the exit-status message with a SSH_MSG_CHANNEL_EOF. But the server can't rely on clients sending SSH_MSG_CHANNEL_EOF. Instead, it must treat process death in much the same way as reception of SSH_MSG_CHANNEL_EOF. The channel is closed once the server has both encountered EOF on the process' stdout and stderr (resulting in a SSH_MSG_CHANNEL_EOF), and sent an exit-status or exit-signal message. As a further complication, rule (2) must be relaxed, because otherwise the channel may get closed before the exit-status message is sent. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 23 02:58:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18937 for ; Sat, 23 Mar 2002 02:58:21 -0500 (EST) Received: (qmail 20319 invoked by uid 605); 23 Mar 2002 07:58:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20312 invoked from network); 23 Mar 2002 07:58:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 23 Mar 2002 07:58:16 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id B29308360E0; Sat, 23 Mar 2002 08:58:14 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id IAA24772; Sat, 23 Mar 2002 08:58:14 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> <20020322194456.E17748@eskimo.com> From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 23 Mar 2002 08:58:13 +0100 In-Reply-To: <20020322194456.E17748@eskimo.com> Message-ID: Lines: 74 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > What's the purpose of CHANNEL_EOF, anyway? I thought it was used to tell > the other side that no more data will be sent so that the other side can > feel free to close the channel whenever it finishes sending its > data. To me, a channel can be viewed as three parts: two dataflows, one for each directions, and sometimes auxillary communication like CHANNEL_REQUEST. If the parties are A and B, the dataflow from A to B are controlled by the CHANNEL_DATA, CHANNEL_EXTENDED_DATA and CHANNEL_EOF sent by A, and the WINDOW_ADJUST messages sent by B. I think it's best to treat this dataflow independently from the dataflow in the other direction, and from the auxillary communication. Theyäre three orthogonal components of the channel. > If you're going to send more information (e.g., the exit code) in > the form of a CHANNEL_REQUEST after sending CHANNEL_EOF, then how > does the other side know when it's safe to close the channel without > losing information? It's hard to know that for sure. As I said in my other message, initiating close when EOF have been both sent and received is the right thing to do for most channels, but it doesn't quite work for sessions. When I do ssh host cat foo I want the channel to be closed and the local ssh process to exit when all data has been sent by the server, and the remote process has died. I think it would be annoying if the above command would keep the channel open for ever just because the client never sends EOF. If the server waits for EOF, users would have to type ssh host cat foo That's fine in the case of a shell command, but what about other types of > channels where the concept of child process termination doesn't apply? For other channels, the "close whenever you have both sent and received EOF"-rule works fine. > 1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data > or requests to send) > 2. CHANNEL_EOF has been received from the other side, or this side cannot > process any more incoming channel data or requests. Consider the ssh host cat foo case. I'm afraid your simple rules are not sufficient (and I have actually implemented them). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 23 03:31:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19225 for ; Sat, 23 Mar 2002 03:31:04 -0500 (EST) Received: (qmail 3691 invoked by uid 605); 23 Mar 2002 08:31:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3684 invoked from network); 23 Mar 2002 08:31:02 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 23 Mar 2002 08:31:02 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA14213; Sat, 23 Mar 2002 09:30:59 +0100 (MET) Date: Sat, 23 Mar 2002 09:30:59 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020323083059.GB14015@faui02> References: <20020322122528.GA29756@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Mller wrote: > /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17" the reason for linking CHANNEL_EOF to CHANNEL_DATA only was: /bin/sh -c "echo foo; exec >/dev/null; sleep 30; exec 2>/dev/null; sleep 30; exit 17" so the EOF messages triggers a close(stdout) in the client without waiting 30 more seconds. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 23 03:38:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19297 for ; Sat, 23 Mar 2002 03:38:12 -0500 (EST) Received: (qmail 6338 invoked by uid 605); 23 Mar 2002 08:38:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6325 invoked from network); 23 Mar 2002 08:38:07 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 23 Mar 2002 08:38:07 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA14378; Sat, 23 Mar 2002 09:38:05 +0100 (MET) Date: Sat, 23 Mar 2002 09:38:05 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020323083805.GC14015@faui02> References: <20020322122528.GA29756@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 22, 2002 at 07:41:14PM +0100, Niels Mller wrote: > Ordinary data and extended data are treated as a single stream for > flow control. It would be odd to treat them differently with respect > to EOF only. Yes, I see this. My reason for linking EOF to the CHANNEL_DATA is that i wanted to signal the EOF for the logins stdout immediately to the client, so I can close(stdout). > It might be desirable to have a wider separation between stdout and > stderr data than is provided by the extended data hack. Yes, that would help. > Can one send CHANNEL_REQUEST after EOF? I'd say yes. In particular, > the order in which my server sends CHANNEL_EOF and CHANNEL_REQUEST > "exit-status" depends on the the relative timing of i/o and the > SIGCHLD signal, and is esssentially random. Yes, of course. You can send CHANNEL_REQUEST always, until you send a CHANNEL_CLOSE message. > Can one send WINDOW_ADJUST after EOF? This is an ill-posed question. I think EOF and WINDOW_ADJUST are unrelated. Even receiving a WINDOW_ADJUST after an EOF makes sense, because the peer could have sent the WINDOW_ADJUST before he receives the EOF. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 23 12:12:44 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23292 for ; Sat, 23 Mar 2002 12:12:43 -0500 (EST) Received: (qmail 25405 invoked by uid 605); 23 Mar 2002 17:12:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25398 invoked from network); 23 Mar 2002 17:12:42 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 23 Mar 2002 17:12:42 -0000 Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id JAA17570; Sat, 23 Mar 2002 09:12:36 -0800 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id JAA10670; Sat, 23 Mar 2002 09:12:35 -0800 (PST) Date: Sat, 23 Mar 2002 09:12:34 -0800 From: Wei Dai To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020323091234.A8278@eskimo.com> References: <20020322122528.GA29756@faui02> <20020322194456.E17748@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: ; from nisse@lysator.liu.se on Sat, Mar 23, 2002 at 08:58:13AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Sat, Mar 23, 2002 at 08:58:13AM +0100, Niels Möller wrote: > > 1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data > > or requests to send) > > 2. CHANNEL_EOF has been received from the other side, or this side cannot > > process any more incoming channel data or requests. > > Consider the > > ssh host cat foo > > case. I'm afraid your simple rules are not sufficient (and I have > actually implemented them). Maybe you didn't notice that condition 2 has two parts. If the child process (cat in this case) terminates, then this side cannot process any more incoming channel data or requests, so condition 2 is satisfied. But I can see why you want to make CHANNEL_EOF independent from CHANNEL_REQUEST, and also why Markus wants to make CHANNEL_EOF independent from both CHANNEL_EXTENDED_DATA and CHANNEL_REQUEST. What do you think about this proposal: link CHANNEL_EOF to all of CHANNEL_DATA, CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST, and create two new channel message types: CHANNEL_DATA_END, linked only to CHANNEL_DATA, and CHANNEL_EXTENDED_DATA_END, linked only to CHANNEL_EXTENDED_DATA. CHANNEL_EXTENDED_DATA_END would look like this: byte SSH_MSG_CHANNEL_EXTENDED_DATA_END uint32 recipient_channel uint32 data_type_code so there would be one CHANNEL_EXTENDED_DATA_END for each type of extended data. Then, CHANNEL_EOF would be used to determine when to close the channel, and CHANNEL_DATA_END and CHANNEL_EXTENDED_DATA_END would be used to tell the other side to close the corresponding fds. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 03:50:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11751 for ; Sun, 24 Mar 2002 03:50:11 -0500 (EST) Received: (qmail 757 invoked by uid 605); 24 Mar 2002 08:50:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 746 invoked from network); 24 Mar 2002 08:50:06 -0000 Received: from out001slb.verizon.net (HELO out001.verizon.net) (206.46.170.13) by mail.netbsd.org with SMTP; 24 Mar 2002 08:50:06 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.150.85]) by out001.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020324085002.LIUT6775.out001.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Sun, 24 Mar 2002 02:50:02 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Sun, 24 Mar 2002 03:50:09 -0500 Date: Sun, 24 Mar 2002 03:50:09 -0500 From: nico To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org Subject: Re: Even more ways to fix the cbc-mode attack Message-ID: <20020324035009.A2700@NICO> References: <200203201831.g2KIVuq01270@syn.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200203201831.g2KIVuq01270@syn.hamachi.org>; from sommerfeld@netbsd.org on Wed, Mar 20, 2002 at 01:31:56PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Modern Kerberos crypto uses confounders instead of IVs. Nico On Wed, Mar 20, 2002 at 01:31:56PM -0500, Bill Sommerfeld wrote: > Since TLS has the same CBC attack problem, I attended that WG... > > Eric Rescorla mentioned a few ideas which had been kicked around on > TLS for fixing the problem. > > In addition to the ones that have been mentioned already either on the > list or in Monday's meeting, there are: > > - stream-like modes (CTR, OFB) > - explicit IV > > Eric also mentioned two other ideas which allow the continued use of > CBC mode: > > - use an implicit pseudorandom IV (i.e., both sides run counter mode > or what have you with a different key just to generate the IV) > > - move the MAC to the start of the packet and (somehow) use that as > the IV. > > There didn't seem to be consensus in that group on the right answer, > either... > > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 04:20:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11963 for ; Sun, 24 Mar 2002 04:20:25 -0500 (EST) Received: (qmail 14523 invoked by uid 605); 24 Mar 2002 09:20:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14516 invoked from network); 24 Mar 2002 09:20:25 -0000 Received: from out006pub.verizon.net (HELO out006.verizon.net) (206.46.170.106) by mail.netbsd.org with SMTP; 24 Mar 2002 09:20:25 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.150.85]) by out006.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020324091922.LHMO27046.out006.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Sun, 24 Mar 2002 03:19:22 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Sun, 24 Mar 2002 04:20:28 -0500 Date: Sun, 24 Mar 2002 04:20:28 -0500 From: nico To: Bill Sommerfeld Cc: Wei Dai , ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020324042028.A544@NICO> References: <20020206134116.A24813@eskimo.com> <200202081950.g18JoTKx007574@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202081950.g18JoTKx007574@thunk.east.sun.com>; from sommerfeld@east.sun.com on Fri, Feb 08, 2002 at 02:50:29PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Feb 08, 2002 at 02:50:29PM -0500, Bill Sommerfeld wrote: > > Padding > Arbitrary-length padding, such that the total length of > (packet_length || padding_length || payload || padding) is a > multiple of the cipher block size or 8, whichever is larger. > There MUST be at least four bytes of padding. The padding SHOULD > consist of random bytes. The maximum amount of padding is 255 > bytes. > > With the 4-byte minimum, the random padding puts a floor on the > difficulty of guessing the previous block (no better than one chance > in 2**32). An implementation could render the attack entirely > meaningless by always sending a full cipherblock of padding... This would pretty much be the equivalent of starting encrypted messages with confounders. The "modern" Kerberos crypto spec relies on confounders instead of explicit IVs (which are worse than implicit IVs). So why not? Alternatively a new global request could be spec'ed to negotiate the use of confounders instead of implicit IVs. > - Bill > Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 04:45:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12074 for ; Sun, 24 Mar 2002 04:45:33 -0500 (EST) Received: (qmail 24456 invoked by uid 605); 24 Mar 2002 09:45:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24449 invoked from network); 24 Mar 2002 09:45:31 -0000 Received: from mx01.nexgo.de (151.189.8.96) by mail.netbsd.org with SMTP; 24 Mar 2002 09:45:31 -0000 Received: from localhost (dsl-213-023-062-184.arcor-ip.net [213.23.62.184]) by mx01.nexgo.de (Postfix) with ESMTP id 9B24B3BC64; Sun, 24 Mar 2002 10:45:29 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 350004439; Sun, 24 Mar 2002 10:44:56 +0100 (CET) Date: Sun, 24 Mar 2002 10:44:56 +0100 From: Markus Friedl To: Wei Dai Cc: Niels =?iso-8859-1?Q?M=F6ller?= , ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020324094456.GA20760@folly> References: <20020322122528.GA29756@faui02> <20020322194456.E17748@eskimo.com> <20020323091234.A8278@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20020323091234.A8278@eskimo.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Sat, Mar 23, 2002 at 09:12:34AM -0800, Wei Dai wrote: > On Sat, Mar 23, 2002 at 08:58:13AM +0100, Niels Möller wrote: > > > 1. CHANNEL_EOF has been sent by this side (i.e. this side has no more data > > > or requests to send) > > > 2. CHANNEL_EOF has been received from the other side, or this side cannot > > > process any more incoming channel data or requests. > > > > Consider the > > > > ssh host cat foo > > > > case. I'm afraid your simple rules are not sufficient (and I have > > actually implemented them). > > Maybe you didn't notice that condition 2 has two parts. If the child > process (cat in this case) terminates, then this side cannot process any > more incoming channel data or requests, so condition 2 is satisfied. i don't think so. incoming requests are handled by sshd, so they could still be satisfied, e.g. a possible request asking: "what's the exit status of 'cat'" From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 11:03:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14956 for ; Sun, 24 Mar 2002 11:03:05 -0500 (EST) Received: (qmail 27849 invoked by uid 605); 24 Mar 2002 16:03:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27842 invoked from network); 24 Mar 2002 16:03:04 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 24 Mar 2002 16:03:04 -0000 Received: from localhost (dsl-213-023-028-073.arcor-ip.net [213.23.28.73]) by mx04.nexgo.de (Postfix) with ESMTP id 1249737C41; Sun, 24 Mar 2002 17:03:03 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 2D1124439; Sun, 24 Mar 2002 17:02:30 +0100 (CET) Date: Sun, 24 Mar 2002 17:02:30 +0100 From: Markus Friedl To: nico Cc: Bill Sommerfeld , Wei Dai , ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020324160230.GB25162@folly> References: <20020206134116.A24813@eskimo.com> <200202081950.g18JoTKx007574@thunk.east.sun.com> <20020324042028.A544@NICO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020324042028.A544@NICO> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Mar 24, 2002 at 04:20:28AM -0500, nico wrote: > Alternatively a new global request could be spec'ed to negotiate the use > of confounders instead of implicit IVs. you cannot use SSH_MSG_GLOBAL_REQUEST, it's part of the connection protocol, a different layer. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 15:30:47 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17403 for ; Sun, 24 Mar 2002 15:30:47 -0500 (EST) Received: (qmail 28107 invoked by uid 605); 24 Mar 2002 20:30:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28054 invoked from network); 24 Mar 2002 20:30:39 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Mar 2002 20:30:39 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 65F868360B9; Sun, 24 Mar 2002 21:30:38 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id VAA25085; Sun, 24 Mar 2002 21:30:38 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> <20020323083059.GB14015@faui02> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 24 Mar 2002 21:30:36 +0100 In-Reply-To: <20020323083059.GB14015@faui02> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Mller wrote: > > /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17" > > the reason for linking CHANNEL_EOF to CHANNEL_DATA only was: > > /bin/sh -c "echo foo; exec >/dev/null; sleep 30; exec 2>/dev/null; sleep 30; exit 17" > > so the EOF messages triggers a close(stdout) in the client > without waiting 30 more seconds. I see. I don't think it's a very strong argument, though. If you interchange stdout and stderr, /bin/sh -c "echo foo; exec 2>/dev/null; sleep 30; exec >/dev/null; sleep 30; exit 17" you don't get the client to close stderr immediately when the remote process closes it's stderr. I'd prefer that sending neither DATA nor EXTENDED_DATA be allowed after you've sent EOF. It's still fine to send EOF immediately when you detect EOF on the process' stdout, but if you do that, you should also stop reading stderr, or discard any data you get from it. Don't send it to the client. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 15:47:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18107 for ; Sun, 24 Mar 2002 15:47:56 -0500 (EST) Received: (qmail 8433 invoked by uid 605); 24 Mar 2002 20:47:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8342 invoked from network); 24 Mar 2002 20:47:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Mar 2002 20:47:45 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id 4F6AC836090; Sun, 24 Mar 2002 21:47:43 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id VAA25088; Sun, 24 Mar 2002 21:47:42 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Wei Dai Cc: Markus Friedl , ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> <20020322194456.E17748@eskimo.com> <20020323091234.A8278@eskimo.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 24 Mar 2002 21:47:41 +0100 In-Reply-To: <20020323091234.A8278@eskimo.com> Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Wei Dai writes: > What do you think about this proposal: link CHANNEL_EOF to all of > CHANNEL_DATA, CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST, and create two > new channel message types: CHANNEL_DATA_END, linked only to CHANNEL_DATA, > and CHANNEL_EXTENDED_DATA_END, linked only to CHANNEL_EXTENDED_DATA. > CHANNEL_EXTENDED_DATA_END would look like this: I don't like it. It's too much extra complexity for a small very gain. It's the kind of improvement that identifies a design by a committee... For most channels, sending EOF when you don't want to send any kind of data, and CLOSE when you want the channel to go away, are exactly the two messages you need. Then enters the EXTENDED_DATA hack, which so far is used *exclusivelt* for session channels, and which has the minor bug that it doesn't quite separate the stdout and stderr flow (as what should have been two independent flows share both EOF notifications and the flow-control related messages). The situation could be improved, but then the right way is *not* to introduce more variants of the EOF message to clean up after the EXTENDED_DATA hack, but to introduce a new CHANNEL_OPEN or CHANNEL_REQUEST messages that attaches a separate stderr channel to a session. And the bottom line is that I think EXTENDED_DATA, while not perfect, is still pretty good, good enough that we shouldn't bend the rest of the protocol to "fix" it. And I encourage anybody that is annoyed by the limitations of EXTANDED_DATA to experiment with things like CHANNEL_OPEN "stderr-for-session" session without changing our now almost standard core protocols. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 16:01:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18265 for ; Sun, 24 Mar 2002 16:01:52 -0500 (EST) Received: (qmail 14854 invoked by uid 605); 24 Mar 2002 21:01:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14582 invoked from network); 24 Mar 2002 21:01:41 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 24 Mar 2002 21:01:41 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id WAA01541 for ; Sun, 24 Mar 2002 22:02:30 +0100 From: "denis bider" To: Subject: RE: closing a channel Date: Sun, 24 Mar 2002 22:02:54 +0100 Message-ID: <000701c1d377$45665d70$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Strongly agreed. > I'd prefer that sending neither DATA nor EXTENDED_DATA > be allowed after you've sent EOF. > > It's still fine to send EOF immediately when you detect > EOF on the process' stdout, but if you do that, you > should also stop reading stderr, or discard any data > you get from it. Don't send it to the client. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 16:13:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18367 for ; Sun, 24 Mar 2002 16:13:04 -0500 (EST) Received: (qmail 22508 invoked by uid 605); 24 Mar 2002 21:13:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22501 invoked from network); 24 Mar 2002 21:13:03 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 24 Mar 2002 21:13:03 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id WAA01552 for ; Sun, 24 Mar 2002 22:13:48 +0100 From: "denis bider" To: Subject: RE: closing a channel Date: Sun, 24 Mar 2002 22:14:13 +0100 Message-ID: <000801c1d378$d9b83970$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > What do you think about this proposal: > > link CHANNEL_EOF to all of CHANNEL_DATA, > > CHANNEL_EXTENDED_DATA, and CHANNEL_REQUEST, > > and create two new channel message types: > > CHANNEL_DATA_END, linked only to CHANNEL_DATA, > > I don't like it. It's too much extra complexity > for a small very gain. It's the kind of improvement > that identifies a design by a committee... Strongly agreed. At this point of the protocol's evolution, drastic solutions like introducing new message types would be counter-productive. All that is required is a clear definition of what exactly CHANNEL_EOF means. This definition should be compatible with most existing SSH2 implementations. (Except obviously broken ones.) > Then enters the EXTENDED_DATA hack, I'm not bothered by EXTENDED_DATA being a hack. It is what it is, it works how it works, that's fine with me. Now that the cat is out of the bag, and 50% of the world's secure shell servers already support SSH2, we won't get rid of EXTENDED_DATA by redesigning the protocol. If we try to do so, we'll just have to support the new system as well as the existing one. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 24 16:40:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18713 for ; Sun, 24 Mar 2002 16:40:25 -0500 (EST) Received: (qmail 7527 invoked by uid 605); 24 Mar 2002 21:40:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7520 invoked from network); 24 Mar 2002 21:40:23 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 24 Mar 2002 21:40:23 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id WAA01618 for ; Sun, 24 Mar 2002 22:41:10 +0100 From: "denis bider" To: Subject: proposal for EOF clarification Date: Sun, 24 Mar 2002 22:41:35 +0100 Message-ID: <000901c1d37c$ac8494e0$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I propose that the following text in the SSH Connection Protocol draft... When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_EOF uint32 recipient_channel No explicit response is sent to this message; however, the application may send EOF to whatever is at the other end of the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. This message does not consume window space and can be sent even if no window space is available. ... be replaced with: When a party will no longer send more data to a channel, it SHOULD send SSH_MSG_CHANNEL_EOF. byte SSH_MSG_CHANNEL_EOF uint32 recipient_channel No explicit response is sent to this message; however, the application may send EOF to whatever is at the other end of the channel. This message does not consume window space and can be sent even if no window space is available. After a party sends SSH_MSG_CHANNEL_EOF, it MUST NOT send any more data or extended data to the channel. Note that the channel remains open after this message, and more data may still be sent in the other direction. Also, after sending SSH_MSG_CHANNEL_EOF, a party may still send channel requests, as well as responses to channel requests issued by the opposite party. A channel need not be closed even after both parties have sent EOF to the channel. Although any of the parties may close the channel at any time, including after EOF has been both sent and received, the parties may continue to exchange data using channel requests regardless of what EOF messages have been sent. For example, the server may send an "exit-status" channel request on a session channel after EOF has already been sent by both parties. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 03:40:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05435 for ; Mon, 25 Mar 2002 03:40:00 -0500 (EST) Received: (qmail 27691 invoked by uid 605); 25 Mar 2002 08:39:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27655 invoked from network); 25 Mar 2002 08:39:54 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 25 Mar 2002 08:39:54 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA26797; Mon, 25 Mar 2002 09:39:51 +0100 (MET) Date: Mon, 25 Mar 2002 09:39:51 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020325083951.GA26655@faui02> References: <20020322122528.GA29756@faui02> <20020323083059.GB14015@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Mar 24, 2002 at 09:30:36PM +0100, Niels Mller wrote: > Markus Friedl writes: > > > On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Mller wrote: > > > /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17" > > > > the reason for linking CHANNEL_EOF to CHANNEL_DATA only was: > > > > /bin/sh -c "echo foo; exec >/dev/null; sleep 30; exec 2>/dev/null; sleep 30; exit 17" > > > > so the EOF messages triggers a close(stdout) in the client > > without waiting 30 more seconds. > > I see. I don't think it's a very strong argument, though. Sure, but applications using ssh might behave different if the EOF is delayed (e.g. stderr is not closed at all) and not send an EOF in the other direction. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 07:35:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07612 for ; Mon, 25 Mar 2002 07:35:42 -0500 (EST) Received: (qmail 15980 invoked by uid 605); 25 Mar 2002 12:35:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15973 invoked from network); 25 Mar 2002 12:35:39 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 25 Mar 2002 12:35:39 -0000 Received: from fafner.lysator.liu.se (fafner.lysator.liu.se [130.236.254.31]) by mail.lysator.liu.se (Postfix) with ESMTP id AA176836037; Mon, 25 Mar 2002 13:35:38 +0100 (MET) Received: (from nisse@localhost) by fafner.lysator.liu.se (8.9.3/8.8.7) id NAA25260; Mon, 25 Mar 2002 13:35:38 +0100 (MET) X-Authentication-Warning: fafner.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel References: <20020322122528.GA29756@faui02> <20020323083059.GB14015@faui02> <20020325083951.GA26655@faui02> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 25 Mar 2002 13:35:37 +0100 In-Reply-To: <20020325083951.GA26655@faui02> Message-ID: Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Markus Friedl writes: > Sure, but applications using ssh might behave different if the EOF > is delayed (e.g. stderr is not closed at all) and not send an > EOF in the other direction. Can you say some more about the problems you see? I don't see that the opensshd behaviour solves real problems. As for EOF sent by the client, my experience is that one can't rely on clients sending EOF (on a session) as the result of the server sending EOF. Clients typically send EOF when they get EOF on stdin, and often not at all (e.g. with "ssh host cat foo" command, a typical client never sends any EOF, no matter what combination of EOF, "exit-status" or CLOSE that the server sends. (Older versions of lsh did send EOF as a response to "exit-status", but that's the only case I'm aware of. It turned out to not be very useful, as no other clients seemed to do that)). I think the current opensshd behaviour of sending EXTENDED_DATA after EOF is simply a minor bug that should be fixed sooner or later. Do you have a good reason for keeping that behaviour? The below is an excerpt from a log in an lsh bug report, where the user connected to an opensshd server with the command $ lsh openserver "echo hej 1>&2" > lsh: Registering local channel 0. > lsh: Taking channel 0 in use, (local 0). > lsh: client.c: Receiving exit-status 0 on channel 0 > lsh: Receiving EOF on channel 0 (local 0) > lsh: Extended data on closed or non-existant channel 0 > lsh: Receiving CLOSE on channel 0 (local 0) (The warning message above is not entire accurate in this case, what it means is simply that lsh received extended data after eof. The channel does exist and it isn't closed). Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 07:47:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07728 for ; Mon, 25 Mar 2002 07:47:14 -0500 (EST) Received: (qmail 22461 invoked by uid 605); 25 Mar 2002 12:47:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22450 invoked from network); 25 Mar 2002 12:47:12 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 25 Mar 2002 12:47:12 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA13438; Mon, 25 Mar 2002 13:47:09 +0100 (MET) Date: Mon, 25 Mar 2002 13:47:08 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: ietf-ssh@netbsd.org Subject: Re: closing a channel Message-ID: <20020325124708.GA13278@faui02> References: <20020322122528.GA29756@faui02> <20020323083059.GB14015@faui02> <20020325083951.GA26655@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Mon, Mar 25, 2002 at 01:35:37PM +0100, Niels Möller wrote: > I think the current opensshd behaviour of sending EXTENDED_DATA after > EOF is simply a minor bug that should be fixed sooner or later. Do you > have a good reason for keeping that behaviour? I never intended to keep the behaviour. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 10:25:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14220 for ; Mon, 25 Mar 2002 10:25:10 -0500 (EST) Received: (qmail 12556 invoked by uid 605); 25 Mar 2002 15:25:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12549 invoked from network); 25 Mar 2002 15:25:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Mar 2002 15:25:09 -0000 Received: from [127.0.0.1] (HELO joseph) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 528457; Mon, 25 Mar 2002 08:25:12 -0700 Message-ID: <002a01c1d411$4880fcf0$140210ac@joseph> From: "Joseph Galbraith" To: "denis bider" , References: <000901c1d37c$ac8494e0$0201010a@intergalactic> Subject: Re: proposal for EOF clarification Date: Mon, 25 Mar 2002 08:25:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > When a party will no longer send more data to a channel, it SHOULD > send SSH_MSG_CHANNEL_EOF. > > byte SSH_MSG_CHANNEL_EOF > uint32 recipient_channel > > No explicit response is sent to this message; however, the > application may send EOF to whatever is at the other end of the > channel. This message does not consume window space and can be > sent even if no window space is available. > > After a party sends SSH_MSG_CHANNEL_EOF, it MUST NOT send any more > data or extended data to the channel. Note that the channel > remains open after this message, and more data may still be sent in > the other direction. Also, after sending SSH_MSG_CHANNEL_EOF, a > party may still send channel requests, as well as responses to > channel requests issued by the opposite party. > > A channel need not be closed even after both parties have sent > EOF to the channel. Although any of the parties may close the > channel at any time, including after EOF has been both sent and > received, the parties may continue to exchange data using channel > requests regardless of what EOF messages have been sent. For > example, the server may send an "exit-status" channel request on > a session channel after EOF has already been sent by both parties. This text looks good to me, and I agree with it. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 14:21:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27575 for ; Mon, 25 Mar 2002 14:21:39 -0500 (EST) Received: (qmail 25808 invoked by uid 605); 25 Mar 2002 19:21:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25801 invoked from network); 25 Mar 2002 19:21:36 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 25 Mar 2002 19:21:36 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21730 for ; Mon, 25 Mar 2002 12:21:36 -0700 (MST) Received: from thunk.East.Sun.COM (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11788 for ; Mon, 25 Mar 2002 14:21:35 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.East.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id g2PJK8gw000852 for ; Mon, 25 Mar 2002 14:20:08 -0500 (EST) Message-Id: <200203251920.g2PJK8gw000852@thunk.East.Sun.COM> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Re: closing a channel Reply-to: sommerfeld@east.sun.com Date: Mon, 25 Mar 2002 14:20:08 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is your (grumpy) working group chair speaking. So, like, guys, we had this last call which ended about two weeks ago. We've already handed off the core protocol documents to the next stage in the process. Denis Bider's proposed change looks nice, but it missed the deadline, and, as I read it, it just makes minor clarifications to the wording. This is *not* a showstopper; we can wait for later to fix it (when the documents come around again for Draft Standard status). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 14:43:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29024 for ; Mon, 25 Mar 2002 14:43:02 -0500 (EST) Received: (qmail 11075 invoked by uid 605); 25 Mar 2002 19:42:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11068 invoked from network); 25 Mar 2002 19:42:57 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 25 Mar 2002 19:42:57 -0000 Received: from intergalactic (intergalactic [10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id UAA04584 for ; Mon, 25 Mar 2002 20:43:48 +0100 From: "denis bider" To: Subject: RE: closing a channel Date: Mon, 25 Mar 2002 20:44:09 +0100 Message-ID: <002e01c1d435$6f58a480$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200203251920.g2PJK8gw000852@thunk.East.Sun.COM> Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Denis Bider's proposed change looks nice, > but it missed the deadline, and, as I read > it, it just makes minor clarifications to > the wording. This is *not* a showstopper; > we can wait for later to fix it (when the > documents come around again for Draft > Standard status). I think that's OK, we just have to remember to fix the document at that point. As long as we have some consensus on what exactly EOF is supposed to mean, and as long as the clarification is going to get in eventually, all is well. Thanks for your note. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 16:39:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04664 for ; Mon, 25 Mar 2002 16:39:13 -0500 (EST) Received: (qmail 15076 invoked by uid 605); 25 Mar 2002 21:39:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15065 invoked from network); 25 Mar 2002 21:39:10 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 25 Mar 2002 21:39:10 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07009; Mon, 25 Mar 2002 14:39:06 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15377; Mon, 25 Mar 2002 16:39:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2PLbbss004163; Mon, 25 Mar 2002 16:37:37 -0500 (EST) Message-Id: <200203252137.g2PLbbss004163@thunk.east.sun.com> From: Bill Sommerfeld To: "denis bider" cc: ietf-ssh@netbsd.org Subject: Re: closing a channel In-Reply-To: Your message of "Mon, 25 Mar 2002 20:44:09 +0100." <002e01c1d435$6f58a480$0201010a@intergalactic> Reply-to: sommerfeld@east.sun.com Date: Mon, 25 Mar 2002 16:37:37 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I think that's OK, we just have to remember to fix the document at that > point. As long as we have some consensus on what exactly EOF is supposed to > mean, and as long as the clarification is going to get in eventually, all is > well. I've started a list of "nits for next time". Your suggested text is part of the first entry. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Mar 25 23:25:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15275 for ; Mon, 25 Mar 2002 23:25:02 -0500 (EST) Received: (qmail 27125 invoked by uid 605); 26 Mar 2002 04:25:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27118 invoked from network); 26 Mar 2002 04:25:01 -0000 Received: from out019pub.verizon.net (HELO out019.verizon.net) (206.46.170.98) by mail.netbsd.org with SMTP; 26 Mar 2002 04:25:01 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.148.49]) by out019.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020326042459.XHQP13286.out019.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Mon, 25 Mar 2002 22:24:59 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Mon, 25 Mar 2002 23:24:59 -0500 Date: Mon, 25 Mar 2002 23:24:59 -0500 From: nico To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: an attack against SSH2 protocol Message-ID: <20020325232415.A2448@NICO> References: <20020206134116.A24813@eskimo.com> <200202081950.g18JoTKx007574@thunk.east.sun.com> <20020324042028.A544@NICO> <20020324160230.GB25162@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020324160230.GB25162@folly>; from markus@openbsd.org on Sun, Mar 24, 2002 at 05:02:30PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, Mar 24, 2002 at 05:02:30PM +0100, Markus Friedl wrote: > On Sun, Mar 24, 2002 at 04:20:28AM -0500, nico wrote: > > Alternatively a new global request could be spec'ed to negotiate the use > > of confounders instead of implicit IVs. > > you cannot use SSH_MSG_GLOBAL_REQUEST, it's part of > the connection protocol, a different layer. Yes, you're right, that would be a violation of the layer abstraction. Fine, so come up with new enctypes matching the existing CBC enctypes but whose semantics will be "same as previous version, but with this enctype all messages must start with a confounder". Also, I find it weird that the draft uses "SHOULD" wrt treating the last cipher block of a message as the IV for the next message. I can't see how two implementations can operate if one does and the other does not treat the last block of each encrypted message as the IV for the next. Of course, that must be a SHOULD because this implicit IV rule might not apply to some enctypes, but then, that should be specified per-enctype, and, for the ones that use implicit IVs it should be a MUST. I.e., this part of the connection protocol draft probably needs revision. Cheers, Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 26 07:23:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00144 for ; Tue, 26 Mar 2002 07:23:05 -0500 (EST) Received: (qmail 21875 invoked by uid 605); 26 Mar 2002 12:22:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21835 invoked from network); 26 Mar 2002 12:22:46 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 26 Mar 2002 12:22:46 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00095; Tue, 26 Mar 2002 07:22:27 -0500 (EST) Message-Id: <200203261222.HAA00095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-14.txt Date: Tue, 26 Mar 2002 07:22:26 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-14.txt Pages : 28 Date : 25-Mar-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020325160007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020325160007.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Mar 26 23:12:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07044 for ; Tue, 26 Mar 2002 23:12:02 -0500 (EST) Received: (qmail 18790 invoked by uid 605); 27 Mar 2002 04:12:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18783 invoked from network); 27 Mar 2002 04:12:00 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 27 Mar 2002 04:12:00 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00900 for ; Tue, 26 Mar 2002 20:11:59 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28040 for ; Tue, 26 Mar 2002 23:11:59 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2R4ASss019841 for ; Tue, 26 Mar 2002 23:10:28 -0500 (EST) Message-Id: <200203270410.g2R4ASss019841@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: minutes from Secure Shell [secsh] meeting at 53rd IETF Reply-to: sommerfeld@east.sun.com Date: Tue, 26 Mar 2002 23:10:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Meeting notes for IETG Secsh WG meeting, Minneapolis 53rd IETF, 3/18/02. [notes taken by Ken Hornstein, lightly edited by Bill Sommerfeld] Bill Sommerfeld (WG chair) opened the meeting with traditional agenda bashing. First up was comments about the CBC mode vulernability Wei Dai pointed out; the consensus was that this will NOT hold up the core drafts, and a disclaimer will be added (plus additional modes will be defined in a seperate document). Bill also pointed out that upon checking the listed milestones, all of them have been completed! Darren M gave a report about ssh testing at Connectathon (six different vendors, three implementations). Some interoperability problems were discovered, which turned out to be a problem with draft ambiguity. The hope was to have a more formal plan for doing SSH testing at the next Connectathon, including Kerberos/GSS interop testing (a lot of interest was expressed by Kerberos folks at Connectathon). Note from WG Chair: I am grumpy that this has taken this long! But it is his belief that the documents are ready, they survived WG last call, and a IETF-wide last call should be forthcoming. 3 drafts still in WG last call; please send comments to the list (not much discussion except on the public key file format). A few comments were brought up about making the document standards-track versus informational; the draft author said, "Either way is fine", jhutz Hutzlman said, "Standard would be better for interopability", jis said, "Standard is fine, but there might be some pushback". keyboard-interactive - seems to be done, and it interoperates with other implementations (same for d-h group exchange). 4 drafts are remaining that are NOT ready for last-call. GSSAPI - jhutz says, "Not ready yet" (there was discussion on the list, comments sent in need to be incorporated, will send out a new document next week). agent-forwarding - insufficient detail to implemnt. joeg says, "A starting point would be great, at least how OpenSSH does it". Consensus was to incorporate text describing OpenSSH agent forwarding into document. file transfer - NO consenus, as every so often someone suggests major redesign. host keys in DNS - moved to the SIKED BOF on Tuesday. CBC Attack: - Duplicate cipherblock leak the XOR of the plaintext - A chosen-plaintext attacker can force collision (by injection the XOR of the old plaintext and the old IV) - The protocol is resistant (because of multiple levels of framing) but not immune. Fixes to attack (note that it's not a ssh-specific attack): - A fixed CBC mode which includes a nonce. - Counter mode - OFB mode. _Rough_ consensus is to not hold current documents for the fix -- instead, do new document defining new encryption mode(s) (but no consensus on which mode to use). jhutz pointed out that CTR is rather new and we don't have a lot of experience with it; it was also pointed out that putting all of our eggs in one basket might be considered bad. Bill asked if anyone read his proposed disclaimer to the transport draft; all comments were "looks good"; jis said that document could be rev'd without doing a WG last call. Modulo any list comments, consensus was to do that. [this has happened]. Future draft ideas: - Legacy/historic identifiers (des-cbc); volunteer for that draft, but no draft has yet appeared. - X.509 / PKIX. Why not a GSS mechanism that knows how to do X.509? jhutz points out that people are actually using simon's patches with non-Kerberos 5 mechanisms; future discussion is necessary. - Round-trip count reduction. There was some interest in this when it was brought up before. - Deprecate implementation-name-based-workaround - do we want to officially deprecate these hacks once the drafts reach draft standard? It was brought up that customers still have non-compliant servers; Bill said that maybe put the RFC number in the version string or some other mechanism for knowing if a implementation is RFC-compliant. - Server key fingerprints: trivial draft mailed to list, not published. - Please send drafts for these: - Port forwarding of arbitrary port - UDP forwarding (Comment from WG chair: "Much pain, little gain") - line mode - Console server options (send BREAK, RS232 parameter settings) . Curent milestones: All done! New milestones? Apr 02: gssapi draft ready for last-call Apr 02: Publish draft on new modes May 02: Agent draft ready for last call May 02: Publish draft on X.509/PKIX (or maybe just use GSSAPI) May 02: publish draft on console server extensions. Dec 02: File transfer draft ready for last call. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 07:15:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23969 for ; Wed, 27 Mar 2002 07:15:58 -0500 (EST) Received: (qmail 22301 invoked by uid 605); 27 Mar 2002 12:15:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22292 invoked from network); 27 Mar 2002 12:15:50 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Mar 2002 12:15:50 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23923; Wed, 27 Mar 2002 07:15:48 -0500 (EST) Message-Id: <200203271215.HAA23923@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-14.txt Date: Wed, 27 Mar 2002 07:15:47 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-14.txt Pages : 28 Date : 25-Mar-02 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020325160007.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020325160007.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 14:35:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18303 for ; Wed, 27 Mar 2002 14:35:44 -0500 (EST) Received: (qmail 4841 invoked by uid 605); 27 Mar 2002 19:35:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4528 invoked from network); 27 Mar 2002 19:35:00 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 27 Mar 2002 19:35:00 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:09 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: SFTP File open modes Date: Wed, 27 Mar 2002 14:36:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The current specification of SFTP states that files are always opened in "binary" mode - no translations between different character sets and newline encodings. It is well known that different systems use different methods of encoding text files. If SFTP desires to be able to provide a secure way of interchanging files between systems, then it must specify a method in which text files can be exchanged in a uniform manner. To address this problem, I propose the following: add the flag SSH_FXF_ASCII to the SSH_FXP_OPEN message. When this flag is set, the file will be transferred in system independent ASCII text format, if appropriate. The system independent format is defined as characters separated by a newline character to specify end of line. The system that is storing the file may make any changes necessary to store the text in a manner that is compatible with standard methods for that system. When a file is transferred in ASCII mode, the total number of bytes transferred may be different from the size provided by the SSH_FXP_xSTAT function. Ideally, the number of bytes transmitted should never be greater. A request to open a file in ASCII format that can not be opened in ASCII format (and should probably be transferred in binary format) will return a failure status of FX_OP_UNSUPPORTED. It may be desirable to include information in the response to a xSTAT function and READDIR stating whether or not a file is candidate to be opened in ASCII format. This could be indicated in the file type information, in a manner similar to the way that a directory file is indicated. ---------------------- Richard Whalen Process Software 508-879-6994 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 15:26:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20892 for ; Wed, 27 Mar 2002 15:26:24 -0500 (EST) Received: (qmail 4234 invoked by uid 605); 27 Mar 2002 20:26:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4186 invoked from network); 27 Mar 2002 20:26:16 -0000 Received: from kathmandu.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 27 Mar 2002 20:26:16 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29657 for ; Wed, 27 Mar 2002 13:26:15 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14591 for ; Wed, 27 Mar 2002 15:26:15 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2RKOhss027441 for ; Wed, 27 Mar 2002 15:24:43 -0500 (EST) Message-Id: <200203272024.g2RKOhss027441@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: comment on draft-ietf-secsh-publickeyfile-02 Reply-to: sommerfeld@east.sun.com Date: Wed, 27 Mar 2002 15:24:43 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list 1) nit: document title should be either: "SSH public key file format" or "Secure Shell public key file format" since "secsh" is just the WG identifier, not the protocol name. 2) "SECSH" should be replaced by SSH or Secure Shell in the body of the draft. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 16:15:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23806 for ; Wed, 27 Mar 2002 16:15:14 -0500 (EST) Received: (qmail 26314 invoked by uid 605); 27 Mar 2002 21:15:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26307 invoked from network); 27 Mar 2002 21:15:09 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 27 Mar 2002 21:15:09 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23791; Wed, 27 Mar 2002 16:14:50 -0500 (EST) Message-Id: <200203272114.QAA23791@ietf.org> To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: The IESG SUBJECT: Last Call: SSH Protocol Architecture to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 27 Mar 2002 16:14:50 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list The IESG has received a request from the Secure Shell Working Group to consider publication of the following as Proposed Standards: o SSH Protocol Architecture o SSH Connection Protocol o SSH Transport Layer Protocol o SSH Authentication Protocol The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 10, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-12.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-15.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-14.txt http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-15.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 17:02:54 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26720 for ; Wed, 27 Mar 2002 17:02:53 -0500 (EST) Received: (qmail 19786 invoked by uid 605); 27 Mar 2002 22:02:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19776 invoked from network); 27 Mar 2002 22:02:49 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 27 Mar 2002 22:02:49 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16qLV2-0003xo-00; Wed, 27 Mar 2002 22:02:32 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com> Subject: Re: SFTP File open modes Message-Id: Date: Wed, 27 Mar 2002 22:02:32 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Richard Whalen wrote: > add the flag SSH_FXF_ASCII to the SSH_FXP_OPEN message. > When this flag is set, the file will be transferred in system independent > ASCII text format, if appropriate. > The system independent format is defined as characters separated by a > newline character to specify end of line. The system that is storing the > file may make any changes necessary to store the text in a manner that is > compatible with standard methods for that system. When a file is > transferred in ASCII mode, the total number of bytes transferred may be > different from the size provided by the SSH_FXP_xSTAT function. Ideally, > the number of bytes transmitted should never be greater. This seems fine to me as far as it goes, but how do you split the file into multiple FXP_READs when there's no persistent file pointer and each FXP_READ must specify a precise file offset where the previous one left off? -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Mar 27 17:07:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26844 for ; Wed, 27 Mar 2002 17:07:24 -0500 (EST) Received: (qmail 21606 invoked by uid 605); 27 Mar 2002 22:07:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21525 invoked from network); 27 Mar 2002 22:07:21 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 27 Mar 2002 22:07:21 -0000 Received: from localhost (dsl-213-023-029-187.arcor-ip.net [213.23.29.187]) by mx04.nexgo.de (Postfix) with ESMTP id A727637B03 for ; Wed, 27 Mar 2002 23:07:18 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 88CBC45EF; Wed, 27 Mar 2002 23:07:11 +0100 (CET) Date: Wed, 27 Mar 2002 23:07:11 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: Re: minutes from Secure Shell [secsh] meeting at 53rd IETF Message-ID: <20020327220710.GA17831@folly> References: <200203270410.g2R4ASss019841@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203270410.g2R4ASss019841@thunk.east.sun.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Mar 26, 2002 at 11:10:28PM -0500, Bill Sommerfeld wrote: > - Server key fingerprints: trivial draft mailed to list, not published. something like this: INTERNET-DRAFT Markus Friedl draft-friedl-secsh-fingerprint-00.txt The OpenBSD Project Expires in six months March 2001 SSH Fingerprint Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. Introduction The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This document formally describes the simple key fingerprint format. Fingerprint Format The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC-1321]. The input to the algorithm is the public key blob as described in [SSH-TRANS]. The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "4b:69:6c:72:6f:79:20:77:61:73:20:68:65:72:65:21" References [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet Draft, draft-secsh-transport-14.txt [RFC-1321] R. Rivest: "The MD5 Message-Digest Algorithm", April 1992. [RFC-2026] S. Bradner: "The Internet Standards Process -- Revision 3", October 1996. Author's Address: Markus Friedl markus@openbsd.org Munich, Germany From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 09:35:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27419 for ; Thu, 28 Mar 2002 09:35:01 -0500 (EST) Received: (qmail 16445 invoked by uid 605); 28 Mar 2002 14:35:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16435 invoked from network); 28 Mar 2002 14:34:59 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 28 Mar 2002 14:34:59 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:36:09 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA229@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Thu, 28 Mar 2002 09:36:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list A server implementation that implements the ASCII read option will need to maintain an internal persistent file pointer. When a file is opened in ASCII mode all access must be sequential and the offset in the READ & WRITE operations must be ignored. -----Original Message----- From: Simon Tatham [mailto:anakin@pobox.com] Sent: Wednesday, March 27, 2002 5:03 PM To: ietf-ssh@netbsd.org Subject: Re: SFTP File open modes Richard Whalen wrote: > add the flag SSH_FXF_ASCII to the SSH_FXP_OPEN message. > When this flag is set, the file will be transferred in system independent > ASCII text format, if appropriate. > The system independent format is defined as characters separated by a > newline character to specify end of line. The system that is storing the > file may make any changes necessary to store the text in a manner that is > compatible with standard methods for that system. When a file is > transferred in ASCII mode, the total number of bytes transferred may be > different from the size provided by the SSH_FXP_xSTAT function. Ideally, > the number of bytes transmitted should never be greater. This seems fine to me as far as it goes, but how do you split the file into multiple FXP_READs when there's no persistent file pointer and each FXP_READ must specify a precise file offset where the previous one left off? -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 10:47:06 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01262 for ; Thu, 28 Mar 2002 10:47:06 -0500 (EST) Received: (qmail 28508 invoked by uid 605); 28 Mar 2002 15:47:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28501 invoked from network); 28 Mar 2002 15:47:04 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 28 Mar 2002 15:47:04 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16qc7D-0006Wv-00; Thu, 28 Mar 2002 15:47:03 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA229@lespaul.process.com> Subject: Re: SFTP File open modes Message-Id: Date: Thu, 28 Mar 2002 15:47:03 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Richard Whalen wrote: > A server implementation that implements the ASCII read option will > need to maintain an internal persistent file pointer. When a file is > opened in ASCII mode all access must be sequential and the offset in > the READ & WRITE operations must be ignored. So you're ruling out the possibility of, for example, two interleaved sets of read requests both reading the file from the beginning? Or a set of requests reading from beginning to end, with an extra request in the middle that takes another quick look at the very start of the file? The semantics you're describing here are a lot more restrictive even than mandates for text files; in , you may not be allowed to know what a file-position variable actually looks like, but you're at least allowed to read up to a certain point in the file, save the file position, then return to the same position later and continue reading from there. Also, you've just broken the stateless nature of SFTP. (Well, not _completely_ stateless, since the existence or non-existence of a file handle is state, but the absence of a concept of current working directory and the absence of file pointers strongly suggest that the designers had statelessness in mind as a desirable property.) Do you think SFTP should never have attempted to be stateless? Or that loss of statelessness is a small price to pay for ASCII file transfer, and it's not even worth trying to work out whether we can have both? Do you know _why_ SFTP is largely stateless? (I don't, and for precisely that reason I'd want to avoid breaking its statelessness in case there was a really good reason for it I hadn't thought of.) I think this is a low-quality solution and if I had a vote to cast I'd vote against it. An example of an alternative solution that doesn't suffer from these problems would be to define new message types FXP_TEXT_READ and FXP_TEXT_WRITE. These hypothetical messages would work just like FXP_READ and FXP_WRITE, but instead of a numeric file offset they would take an opaque `file position' type. You'd have some standard means of constructing a `file position' type corresponding to the very start of a file, and you'd be entitled to re-use a given file position as many times as you liked once you'd received it from an FXP_TEXT_READ or FXP_TEXT_WRITE call. (These operations would have to return the file position after the read/write _as well_ as returning the number of bytes read/written and the data.) This solution doesn't destroy any statelessness properties of SFTP, and permits (AFAICS) all the sequences of operations permitted by on text files. (Both these solutions assume that it's easy to define a wire format for textual data. I'm not sure what such a thing might be. UTF-8 with \n line endings, perhaps? Or something negotiated between client and server?) Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the terminally confused is only apparent to the latter." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 11:34:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03826 for ; Thu, 28 Mar 2002 11:34:10 -0500 (EST) Received: (qmail 22006 invoked by uid 605); 28 Mar 2002 16:34:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21999 invoked from network); 28 Mar 2002 16:34:09 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 28 Mar 2002 16:34:09 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 11:35:19 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA22F@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Thu, 28 Mar 2002 11:35:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Simon Tatham [mailto:anakin@pobox.com] > Sent: Thursday, March 28, 2002 10:47 AM > To: ietf-ssh@netbsd.org > Subject: Re: SFTP File open modes > > > Richard Whalen wrote: > > A server implementation that implements the ASCII read option will > > need to maintain an internal persistent file pointer. When a file is > > opened in ASCII mode all access must be sequential and the offset in > > the READ & WRITE operations must be ignored. > > So you're ruling out the possibility of, for example, two > interleaved sets of read requests both reading the file from the > beginning? Or a set of requests reading from beginning to end, with > an extra request in the middle that takes another quick look at the > very start of the file? > You'll have to clarify your question, as you didn't specify whether the streams are from a single open request or from two open requests. Read requests from multiple open requests could proceed in parallel. > > Also, you've just broken the stateless nature of SFTP. (Well, not > _completely_ stateless, since the existence or non-existence of a > file handle is state, but the absence of a concept of current > working directory and the absence of file pointers strongly suggest > that the designers had statelessness in mind as a desirable > property.) Do you think SFTP should never have attempted to be > stateless? Or that loss of statelessness is a small price to pay for > ASCII file transfer, and it's not even worth trying to work out > whether we can have both? Do you know _why_ SFTP is largely > stateless? (I don't, and for precisely that reason I'd want to avoid > breaking its statelessness in case there was a really good reason > for it I hadn't thought of.) No, I don't know the reason why SFTP is largely stateless; it is not explained in the specification. My guess is that the authors were familiar with NFS (which is stateless), and created operations that are similar to that. The current specification does have the ability to provide general file access, but is missing a method of transferring (text) files between different systems. I don't really think that there are any benefits to SFTP being a stateless protocol. Since it runs over a reliable transport requests don't get lost, and hence, do not have to be repeated (part of the reason that NFS is stateless). Memory and computes are cheap these days, so keeping state around is not a problem. I'm not saying that stateless protocols are bad, just that they are not necessarily better than stateful protocols. The absence of the concept of a current working directory in SFTP would really be beneficial if there had not been an attempt to define what a file path looked like. It would allow the server to do the appropriate things to combine two parts of a file path and return something that could still be in a system independent format. > An example of an alternative solution that doesn't suffer from these > problems would be to define new message types FXP_TEXT_READ and > FXP_TEXT_WRITE. These hypothetical messages would work just like > FXP_READ and FXP_WRITE, but instead of a numeric file offset they > would take an opaque `file position' type. You'd have some standard > means of constructing a `file position' type corresponding to the > very start of a file, and you'd be entitled to re-use a given file > position as many times as you liked once you'd received it from an > FXP_TEXT_READ or FXP_TEXT_WRITE call. (These operations would have > to return the file position after the read/write _as well_ as > returning the number of bytes read/written and the data.) > The operations that you propose are a viable alternative. > > (Both these solutions assume that it's easy to define a wire format > for textual data. I'm not sure what such a thing might be. UTF-8 > with \n line endings, perhaps? Or something negotiated between > client and server?) > A wire format for textual data was defined as far back as RFC 959 (FTP) (and probably further). Yes, text has been expanded these days to allow a wider character set, and some considerations for this should be made. But the bulk of the textual data sent these days is done with a character set that uses an 8 bit unit. My employer's customers expect SFTP to provide functionality similar to what is provided by FTP, with the added security of encryption and improved authentication methods. The protocol that is currently defined is not capable of providing that functionality. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 12:21:39 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06820 for ; Thu, 28 Mar 2002 12:21:38 -0500 (EST) Received: (qmail 22037 invoked by uid 605); 28 Mar 2002 17:21:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22030 invoked from network); 28 Mar 2002 17:21:36 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 28 Mar 2002 17:21:36 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA06698 for ietf-ssh@netbsd.org; Thu, 28 Mar 2002 17:21:35 GMT Date: Thu, 28 Mar 2002 17:21:34 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: SFTP File open modes Message-ID: <20020328172134.A2712@edinburgh.cisco.com> References: <63D30D6E10CFD11190A90000F805FE86040AA22F@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA22F@lespaul.process.com>; from Whalenr@process.com on Thu, Mar 28, 2002 at 11:35:17AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 28, 2002 at 11:35:17AM -0500, Richard Whalen wrote: > > A wire format for textual data was defined as far back as RFC 959 (FTP) (and > probably further). Yes, text has been expanded these days to allow a wider > character set, and some considerations for this should be made. But the > bulk of the textual data sent these days is done with a character set that > uses an 8 bit unit. > > My employer's customers expect SFTP to provide functionality similar to what > is provided by FTP, with the added security of encryption and improved > authentication methods. The protocol that is currently defined is not > capable of providing that functionality. Rather than turn SFTP into a version of FTP, I'd suggest that a way be documented to run FTP over SSH. i.e. a SSH session connection would serve as the FTP control connection (port 21?), and additional SSH connections would be opened for each FTP file transfer connection (port 20?). This would then just seem to just involve a few hacks to an FTP client and server in order to run them over SSH. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 12:32:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07228 for ; Thu, 28 Mar 2002 12:32:49 -0500 (EST) Received: (qmail 28643 invoked by uid 605); 28 Mar 2002 17:32:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28636 invoked from network); 28 Mar 2002 17:32:46 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 28 Mar 2002 17:32:46 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA07271 for ietf-ssh@netbsd.org; Thu, 28 Mar 2002 17:32:44 GMT Date: Thu, 28 Mar 2002 17:32:44 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: SFTP File open modes Message-ID: <20020328173244.A7055@edinburgh.cisco.com> References: <63D30D6E10CFD11190A90000F805FE86040AA22F@lespaul.process.com> <20020328172134.A2712@edinburgh.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020328172134.A2712@edinburgh.cisco.com>; from dfawcus@cisco.com on Thu, Mar 28, 2002 at 05:21:34PM +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Mar 28, 2002 at 05:21:34PM +0000, Derek Fawcus wrote: > > Rather than turn SFTP into a version of FTP, I'd suggest that a way be > documented to run FTP over SSH. > > i.e. a SSH session connection would serve as the FTP control connection > (port 21?), and additional SSH connections would be opened for each > FTP file transfer connection (port 20?). Or even easier - just use the SSH tcp port forwarding facility. Plumb the client and server into this and you have it all with minimal changes. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 12:34:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07300 for ; Thu, 28 Mar 2002 12:34:31 -0500 (EST) Received: (qmail 29648 invoked by uid 605); 28 Mar 2002 17:34:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29641 invoked from network); 28 Mar 2002 17:34:29 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 28 Mar 2002 17:34:29 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 12:35:39 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA231@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Thu, 28 Mar 2002 12:35:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Derek Fawcus [mailto:dfawcus@cisco.com] > Sent: Thursday, March 28, 2002 12:22 PM > To: ietf-ssh@netbsd.org > Subject: Re: SFTP File open modes > > > On Thu, Mar 28, 2002 at 11:35:17AM -0500, Richard Whalen wrote: > > > > A wire format for textual data was defined as far back as > RFC 959 (FTP) (and > > probably further). Yes, text has been expanded these days > to allow a wider > > character set, and some considerations for this should be > made. But the > > bulk of the textual data sent these days is done with a > character set that > > uses an 8 bit unit. > > > > My employer's customers expect SFTP to provide > functionality similar to what > > is provided by FTP, with the added security of encryption > and improved > > authentication methods. The protocol that is currently > defined is not > > capable of providing that functionality. > > Rather than turn SFTP into a version of FTP, I'd suggest > that a way be > documented to run FTP over SSH. > > i.e. a SSH session connection would serve as the FTP control > connection > (port 21?), and additional SSH connections would be opened for each > FTP file transfer connection (port 20?). > > This would then just seem to just involve a few hacks to an FTP client > and server in order to run them over SSH. > > DF > F-Secure's implementation of SSH includes an optional filter module for port forwarding of FTP and HTTP, which I have not experimented with. Yes, port 21 is FTP's command channel, but 20 is seldom used as the data channel these days, and the module has code in there to intercept the information about what the data port should be and to substitute another, (I assume encrypted)port. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Mar 28 13:07:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08634 for ; Thu, 28 Mar 2002 13:07:29 -0500 (EST) Received: (qmail 17325 invoked by uid 605); 28 Mar 2002 18:07:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17318 invoked from network); 28 Mar 2002 18:07:25 -0000 Received: from nuinfo.northwestern.edu (129.105.212.72) by mail.netbsd.org with SMTP; 28 Mar 2002 18:07:25 -0000 Received: (from lunde@localhost) by nuinfo.northwestern.edu (8.8.8/8.8.8) id MAA16104; Thu, 28 Mar 2002 12:07:24 -0600 (CST) Message-Id: <200203281807.MAA16104@nuinfo.northwestern.edu> Subject: Re: SFTP File open modes To: ietf-ssh@netbsd.org Date: Thu, 28 Mar 2002 12:07:23 CST In-Reply-To: <20020328173244.A7055@edinburgh.cisco.com>; from "Derek Fawcus" at Mar 28, 2002 5:32 pm From: Albert-Lunde@northwestern.edu (Albert Lunde) Reply-To: Albert-Lunde@northwestern.edu (Albert Lunde) X-Mailer: Elm [revision: 212.5] Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Thu, Mar 28, 2002 at 05:21:34PM +0000, Derek Fawcus wrote: > > Rather than turn SFTP into a version of FTP, I'd suggest that a way be > > documented to run FTP over SSH. > > i.e. a SSH session connection would serve as the FTP control connection > > (port 21?), and additional SSH connections would be opened for each > > FTP file transfer connection (port 20?). > Or even easier - just use the SSH tcp port forwarding facility. Plumb the > client and server into this and you have it all with minimal changes. My understanding is that SSH port forwarding works only with the control connection with the FTP protocol as it stands. Both existing server code (wu-ftpd) and the FTP protocol are a rat's nest of historical legacies which we would be better off not inflicting on the next generation of software. (Speaking as a very minor beta tester of wu-ftpd.) If people want a text-mode file transfer, they'd be better off fitting it into the archtecture of ssh/sftp and paying attention to i18n issues. -- Albert Lunde Albert-Lunde@northwestern.edu (new address) Albert-Lunde@nwu.edu (old address) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 05:19:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07820 for ; Fri, 29 Mar 2002 05:19:38 -0500 (EST) Received: (qmail 3836 invoked by uid 605); 29 Mar 2002 10:19:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3829 invoked from network); 29 Mar 2002 10:19:33 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 29 Mar 2002 10:19:33 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 20683E8EA; Fri, 29 Mar 2002 21:27:52 +1100 (EST) Received: from localhost (djm@localhost) by mothra.mindrot.org (8.11.6/8.11.6) with ESMTP id g2TAJTF02358; Fri, 29 Mar 2002 21:19:30 +1100 X-Authentication-Warning: mothra.mindrot.org: djm owned process doing -bs Date: Fri, 29 Mar 2002 21:19:27 +1100 (EST) From: Damien Miller To: Derek Fawcus Cc: "ietf-ssh@netbsd.org" Subject: Re: SFTP File open modes In-Reply-To: <20020328172134.A2712@edinburgh.cisco.com> Message-ID: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 28 Mar 2002, Derek Fawcus wrote: > On Thu, Mar 28, 2002 at 11:35:17AM -0500, Richard Whalen wrote: > > > > A wire format for textual data was defined as far back as RFC 959 > > (FTP) (and probably further). Yes, text has been expanded these > > days to allow a wider character set, and some considerations for > > this should be made. But the bulk of the textual data sent these > > days is done with a character set that uses an 8 bit unit. > > > > My employer's customers expect SFTP to provide functionality > > similar to what is provided by FTP, with the added security of > > encryption and improved authentication methods. The protocol > > that is currently defined is not capable of providing that > > functionality. > > Rather than turn SFTP into a version of FTP, I'd suggest that a way > be documented to run FTP over SSH. I agree: filexfer should not know or care about ASCII files. FTP is a deployed standard which could meet the need with a few tweaks. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 07:03:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09328 for ; Fri, 29 Mar 2002 07:03:34 -0500 (EST) Received: (qmail 28071 invoked by uid 605); 29 Mar 2002 12:03:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28064 invoked from network); 29 Mar 2002 12:03:31 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 29 Mar 2002 12:03:31 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09266; Fri, 29 Mar 2002 07:03:18 -0500 (EST) Message-Id: <200203291203.HAA09266@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-fingerprint-00.txt Date: Fri, 29 Mar 2002 07:03:17 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Fingerprint Format Author(s) : M. Friedl Filename : draft-ietf-secsh-fingerprint-00.txt Pages : 2 Date : 28-Mar-02 This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-fingerprint-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-fingerprint-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-fingerprint-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020328141442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-fingerprint-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-fingerprint-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020328141442.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 08:49:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13139 for ; Fri, 29 Mar 2002 08:49:04 -0500 (EST) Received: (qmail 11226 invoked by uid 605); 29 Mar 2002 13:49:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11212 invoked from network); 29 Mar 2002 13:48:55 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 29 Mar 2002 13:48:55 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 08:50:06 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA236@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: Additional thoughts on text transfers Date: Fri, 29 Mar 2002 08:50:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Since modern day files may be encoded in a variety of textual formats the client and server need to come to an agreement on a format when exchanging text files. To provide a mechanism in which methods acceptable to both the client and server can be negotiated, I suggest the following extension data be defined for the SSH_FXP_INIT and SSH_FXP_VERSION packets extension_name TEXT-TRANSFERS extension_data (e.g. ASCII, ISO-LATIN-1, UNICODE, EBCDIC) The INIT packet may contain the list of formats that it would like to support. The VERSON packet contains the list of formats that server can support that are in the list that the client asked for. If none are presented, then ISO-LATIN-1 is assumed. Add an extended file attribute with the name (type) TEXT and the data consisting of a comma separated string in which the first element is the format that the file is currently stored in, and the following elements are formats that the file can be translated to by the OPEN/READ/WRITE functions. To the OPEN packet add an extended attribute of TEXT that specifies the text format desired for opening the file. If the file can not be opened in the requested format, the unsupported status is returned. Add FXP_TEXT_READ (as Simon Tatham suggested) that specifies the file handle, an opaque file position, and the maximum number of 8 bit bytes that should be returned in the FXP_TEXT_DATA function. The file position is a 32 bit integer with the value 0 (zero) defined to be the start of the file. All other values are considered to be opaque and manipulation of them by the client may cause an error or unpredictable results. Multiple reads with the same file position value will return the same data, as long as the file has not been modified by an I/O stream. While not all characters in all sets will be specified in an 8 bit byte, it places an upper bound on the amount of buffers that should be committed. The FXP_TEXT_DATA returns the file handle, the opaque file position for the start of the next read, an integer that specifies the number of lines of text, and a string for each line of text. By specifying separate strings for each line of text the client does not need to scan the data to insert the appropriate line separating sequence for a file stored on its system. It also provides a method for an implementation to store data with line separators even if it can not interpret the data provided that the file attributes can be properly set to note the type of data stored in the file. The FXP_TEXT_WRITE packet contains the file handle, an opaque file position, the number of lines of text present, and a string for each line of text. Again, this allows the system storing the data to store it in an appropriate manner without scanning. If the file position has the value zero, then the beginning of the file is being specified, all other values can not be interpreted. The FXP_STATUS response to the FXP_TEXT_WRITE would need to carry an new value for the file position that is the next available position to write when the file is being accessed sequentially. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:00:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13879 for ; Fri, 29 Mar 2002 09:00:58 -0500 (EST) Received: (qmail 16492 invoked by uid 605); 29 Mar 2002 14:00:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16375 invoked from network); 29 Mar 2002 13:59:57 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 29 Mar 2002 13:59:57 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id 839DA207C1; Fri, 29 Mar 2002 08:59:53 -0500 (EST) Date: Fri, 29 Mar 2002 08:59:53 -0500 From: Niels Provos To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020329135953.GZ20547@citi.citi.umich.edu> Mail-Followup-To: Richard Whalen , "'ietf-ssh@netbsd.org'" References: <63D30D6E10CFD11190A90000F805FE86040AA236@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA236@lespaul.process.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > Since modern day files may be encoded in a variety of textual formats the > client and server need to come to an agreement on a format when exchanging > text files. I disagree. You are adding complexity without any significant gain. I never had any problems transfering text files as binary files between different operating systems. Most applications are aware of the different encodings anyway. For the rare case that they are not, you can always convert to your format manually. I see absolutely no need to burden sftp with this issue. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:33:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15758 for ; Fri, 29 Mar 2002 09:33:03 -0500 (EST) Received: (qmail 3722 invoked by uid 605); 29 Mar 2002 14:33:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3715 invoked from network); 29 Mar 2002 14:33:02 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 29 Mar 2002 14:33:02 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 09:34:13 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA237@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Fri, 29 Mar 2002 09:34:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Niels Provos [mailto:provos@citi.umich.edu] > Sent: Friday, March 29, 2002 9:00 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > > Since modern day files may be encoded in a variety of > textual formats the > > client and server need to come to an agreement on a format > when exchanging > > text files. > I disagree. You are adding complexity without any significant gain. > I never had any problems transfering text files as binary files > between different operating systems. Most applications are aware of > the different encodings anyway. For the rare case that they are not, > you can always convert to your format manually. > > I see absolutely no need to burden sftp with this issue. > > Niels. > And what kinds of systems have you exchanged text files with? Ever try VMS? The majority of text files on VMS systems are stored as variable length record files with implied line separators. In most files there is a 2 byte record length between each record, that does not provide carriage control. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:36:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15921 for ; Fri, 29 Mar 2002 09:36:58 -0500 (EST) Received: (qmail 5427 invoked by uid 605); 29 Mar 2002 14:36:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5420 invoked from network); 29 Mar 2002 14:36:57 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 29 Mar 2002 14:36:57 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 09:38:08 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA238@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: SFTP File open modes Date: Fri, 29 Mar 2002 09:38:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Derek Fawcus [mailto:dfawcus@cisco.com] > Sent: Thursday, March 28, 2002 12:33 PM > To: ietf-ssh@netbsd.org > Subject: Re: SFTP File open modes > > > On Thu, Mar 28, 2002 at 05:21:34PM +0000, Derek Fawcus wrote: > > > > Rather than turn SFTP into a version of FTP, I'd suggest > that a way be > > documented to run FTP over SSH. > > > > i.e. a SSH session connection would serve as the FTP > control connection > > (port 21?), and additional SSH connections would be opened for each > > FTP file transfer connection (port 20?). > > Or even easier - just use the SSH tcp port forwarding > facility. Plumb the > client and server into this and you have it all with minimal changes. > > DF > A big problem with port forwarding is that you have to set up a forwarding for each system that you want to talk to. Yes, they could probably be set up dynamically, but then you have to educate the users how to do that. Most users do ok at exchanging files, but if you ask them to set up forwarding, you are getting too technical for them. Don't think of what's easy for you to do - think of what would be easy for the least technical member of your family to do. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:40:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16039 for ; Fri, 29 Mar 2002 09:40:07 -0500 (EST) Received: (qmail 7131 invoked by uid 605); 29 Mar 2002 14:40:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7124 invoked from network); 29 Mar 2002 14:40:05 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 29 Mar 2002 14:40:05 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id E3DFC207C1; Fri, 29 Mar 2002 09:39:59 -0500 (EST) Date: Fri, 29 Mar 2002 09:39:59 -0500 From: Niels Provos To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020329143959.GD20547@citi.citi.umich.edu> Mail-Followup-To: Richard Whalen , "'ietf-ssh@netbsd.org'" References: <63D30D6E10CFD11190A90000F805FE86040AA237@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA237@lespaul.process.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 09:34:12AM -0500, Richard Whalen wrote: > And what kinds of systems have you exchanged text files with? Ever try VMS? > The majority of text files on VMS systems are stored as variable length > record files with implied line separators. In most files there is a 2 byte > record length between each record, that does not provide carriage control. Yes, I actually helped with the system administration of a VMS cluster for a few years. There is a canonical representations of text files that your implementation may use. Also, you can always set the record length manually after you transfered your file if the application did not do it for you. I am sure that your problems can be solved without changing the wire protocol. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:41:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16142 for ; Fri, 29 Mar 2002 09:41:59 -0500 (EST) Received: (qmail 8126 invoked by uid 605); 29 Mar 2002 14:41:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8118 invoked from network); 29 Mar 2002 14:41:57 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 29 Mar 2002 14:41:57 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id A5452207C1; Fri, 29 Mar 2002 09:41:53 -0500 (EST) Date: Fri, 29 Mar 2002 09:41:53 -0500 From: Niels Provos To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: SFTP File open modes Message-ID: <20020329144153.GE20547@citi.citi.umich.edu> Mail-Followup-To: Richard Whalen , "'ietf-ssh@netbsd.org'" References: <63D30D6E10CFD11190A90000F805FE86040AA238@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA238@lespaul.process.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 09:38:07AM -0500, Richard Whalen wrote: > A big problem with port forwarding is that you have to set up a forwarding > for each system that you want to talk to. Yes, they could probably be set up > dynamically, but then you have to educate the users how to do that. Most > users do ok at exchanging files, but if you ask them to set up forwarding, > you are getting too technical for them. Don't think of what's easy for you > to do - think of what would be easy for the least technical member of your > family to do. I suggest that you try out the OpenSSH implementation of the SSH protocols. We support dynamic port forwarding. A user just configures their application to use a SOCKS proxy and the rest works automatically. It is very easy to set up for the users as many applications know about SOCKS. Regards, Niels Provos. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 09:49:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16428 for ; Fri, 29 Mar 2002 09:49:32 -0500 (EST) Received: (qmail 11108 invoked by uid 605); 29 Mar 2002 14:49:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11101 invoked from network); 29 Mar 2002 14:49:26 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 29 Mar 2002 14:49:26 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 09:50:37 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA239@lespaul.process.com> From: Richard Whalen To: "'ietf-ssh@netbsd.org'" Subject: RE: Additional thoughts on text transfers Date: Fri, 29 Mar 2002 09:50:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Niels Provos [mailto:provos@citi.umich.edu] > Sent: Friday, March 29, 2002 9:40 AM > To: Richard Whalen > Cc: 'ietf-ssh@netbsd.org' > Subject: Re: Additional thoughts on text transfers > > > On Fri, Mar 29, 2002 at 09:34:12AM -0500, Richard Whalen wrote: > > And what kinds of systems have you exchanged text files > with? Ever try VMS? > > The majority of text files on VMS systems are stored as > variable length > > record files with implied line separators. In most files > there is a 2 byte > > record length between each record, that does not provide > carriage control. > Yes, I actually helped with the system administration of a VMS cluster > for a few years. > > There is a canonical representations of text files that your > implementation may use. Also, you can always set the record length > manually after you transfered your file if the application did not do > it for you. I am sure that your problems can be solved without > changing the wire protocol. > > Niels. > There is no canonical representation for a text file specified in SFTP - that is the problem. You are suggesting that our implementation implicitly translate files stored on it to a "canonical representation", so that the files may be read on a Windows/Unix/whatever system. We have put that functionality in our implementation, but there are limitations - if it is set up to do the translation, you lose the option of not getting the translation for a file that is translatable. There would be greater utility if the method could be chosen through the protocol, rather than through setting configuration variables. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Mar 29 22:12:34 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11436 for ; Fri, 29 Mar 2002 22:12:33 -0500 (EST) Received: (qmail 16214 invoked by uid 605); 30 Mar 2002 03:12:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16207 invoked from network); 30 Mar 2002 03:12:32 -0000 Received: from out001slb.verizon.net (HELO out001.verizon.net) (206.46.170.13) by mail.netbsd.org with SMTP; 30 Mar 2002 03:12:32 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.150.8]) by out001.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020330031229.VAGS6775.out001.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Fri, 29 Mar 2002 21:12:29 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Fri, 29 Mar 2002 22:12:31 -0500 Date: Fri, 29 Mar 2002 22:12:31 -0500 From: nico To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: SFTP File open modes Message-ID: <20020329221231.A300@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com>; from Whalenr@process.com on Wed, Mar 27, 2002 at 02:36:06PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list How many well-known and often utilized ways of encoding ASCII text files are there (answer: two)? Is an ASCII mode as you suggest likely to be useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on? Perhaps it would be best to add an operation by which the client can ask the server for a given file's content type and encoding. The server's response should indicate whether it knows, whether it knows for certain and, if it knows at all, what the content type is. All encoding conversions though should be left to the client though. IMHO. Cheers, Nico On Wed, Mar 27, 2002 at 02:36:06PM -0500, Richard Whalen wrote: > The current specification of SFTP states that files are always opened in > "binary" mode - no translations between different character sets and newline > encodings. [...] > ---------------------- > Richard Whalen > Process Software > 508-879-6994 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 30 11:32:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00628 for ; Sat, 30 Mar 2002 11:32:16 -0500 (EST) Received: (qmail 8557 invoked by uid 605); 30 Mar 2002 16:32:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8550 invoked from network); 30 Mar 2002 16:32:11 -0000 Received: from lulu.it.northwestern.edu (129.105.16.54) by mail.netbsd.org with SMTP; 30 Mar 2002 16:32:11 -0000 Received: (from mailnull@localhost) by lulu.it.northwestern.edu (8.8.7/8.8.7) id KAA12314; Sat, 30 Mar 2002 10:32:09 -0600 (CST) Received: from [129.105.186.173] (legume-45-186173.nuts.nwu.edu [129.105.186.173]) by lulu.acns.nwu.edu via smap (V2.0) id xma012251; Sat, 30 Mar 02 10:31:55 -0600 Mime-Version: 1.0 X-Sender: lunde@lulu.it.northwestern.edu Message-Id: In-Reply-To: <20020329221231.A300@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com> <20020329221231.A300@NICO> Date: Sat, 30 Mar 2002 10:32:15 -0600 To: ietf-ssh@netbsd.org From: Albert Lunde Subject: Re: SFTP File open modes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: ietf-ssh-owner@netbsd.org Precedence: list >How many well-known and often utilized ways of encoding ASCII text files >are there (answer: two)? Is an ASCII mode as you suggest likely to be >useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on? > >Perhaps it would be best to add an operation by which the client can ask >the server for a given file's content type and encoding. The server's >response should indicate whether it knows, whether it knows for certain >and, if it knows at all, what the content type is. > >All encoding conversions though should be left to the client though. * First, one should distingush between a literal _ASCII_ mode, and a _text_ mode. The most specific proposal posted suggested using Latin-1 as a least-common-denominator wire encoding, with a bunch of negotiated alternatives. In this day and age, I think it would make more sense to use something like UTF-8 (further spectified to reduce ambiguties). I count at least three widely-used ways of encoding end-of-lines with characters (CR,LF, CRLF) plus fixed-length records, plus counted varable-length records: I don't know what you are thinking of in saying "two". * Text mode is a big win in the case of an OS which has files in some well-known but ideosyncratic format, because the clients don't have to say, know all the varients of EBCDIC or VMS record formats, just a single wire format. * But I think you've got a point that a server may not _know_ the encoding of files, or may not want to support the overhead of a text mode. I don't know any foolproof way to detect which files in my Mac are in Mac-extended-ASCII, which are in Latin1, and which are in Shift-JIS (because I've been running the Japaneses language kit on on of my Macs for years). The Mac type/creator scheme is more or less orthogonal to i18n issues. So this isn't something we should expect to be able to implement on every server, or for every file. -- Albert Lunde Albert-Lunde@northwestern.edu (new address) Albert-Lunde@nwu.edu (old address) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 30 11:39:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00796 for ; Sat, 30 Mar 2002 11:39:19 -0500 (EST) Received: (qmail 11239 invoked by uid 605); 30 Mar 2002 16:39:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11227 invoked from network); 30 Mar 2002 16:39:14 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 30 Mar 2002 16:39:14 -0000 Received: from localhost (dialin-145-254-234-179.arcor-ip.net [145.254.234.179]) by mx04.nexgo.de (Postfix) with ESMTP id 9423137B70; Sat, 30 Mar 2002 17:39:12 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 2C5404508; Sat, 30 Mar 2002 17:38:57 +0100 (CET) Date: Sat, 30 Mar 2002 17:38:56 +0100 From: Markus Friedl To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020330163856.GA20567@folly> References: <63D30D6E10CFD11190A90000F805FE86040AA236@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA236@lespaul.process.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 08:50:05AM -0500, Richard Whalen wrote: > Since modern day files may be encoded in a variety of textual formats the > client and server need to come to an agreement on a format when exchanging > text files. Modern day files are binary documents (pdf, doc, viruses), so no conversions is necessary. SFTP is slim and simple, you can do text conversion in you client application based on suffix-heuristics, for example. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Mar 30 11:44:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00913 for ; Sat, 30 Mar 2002 11:44:14 -0500 (EST) Received: (qmail 14219 invoked by uid 605); 30 Mar 2002 16:44:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14212 invoked from network); 30 Mar 2002 16:44:14 -0000 Received: from mx04.nexgo.de (151.189.8.80) by mail.netbsd.org with SMTP; 30 Mar 2002 16:44:14 -0000 Received: from localhost (dialin-145-254-234-179.arcor-ip.net [145.254.234.179]) by mx04.nexgo.de (Postfix) with ESMTP id 3871337B0F; Sat, 30 Mar 2002 17:44:13 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id 2095A4508; Sat, 30 Mar 2002 17:44:04 +0100 (CET) Date: Sat, 30 Mar 2002 17:44:03 +0100 From: Markus Friedl To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: SFTP File open modes Message-ID: <20020330164403.GB20567@folly> References: <63D30D6E10CFD11190A90000F805FE86040AA238@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA238@lespaul.process.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 09:38:07AM -0500, Richard Whalen wrote: > A big problem with port forwarding is that you have to set up a forwarding > for each system that you want to talk to. Yes, they could probably be set up > dynamically, Yes. > but then you have to educate the users how to do that. No. That's a client implementation issue. With OpenSSH we have an experimental SOCKS4 interface for dynamic portforwarding (see -D in ssh(1)), so this is not a protocol issue. With SSH protocol v2 you can request server-to-client or client-to-server forwardings at any time, you don't need to setup forwardings in advance. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 11:45:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25588 for ; Sun, 31 Mar 2002 11:45:53 -0500 (EST) Received: (qmail 23925 invoked by uid 605); 31 Mar 2002 16:45:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23918 invoked from network); 31 Mar 2002 16:45:51 -0000 Received: from out008pub.verizon.net (HELO out008.verizon.net) (206.46.170.108) by mail.netbsd.org with SMTP; 31 Mar 2002 16:45:51 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.146.82]) by out008.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020331164550.YBNM16955.out008.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Sun, 31 Mar 2002 10:45:50 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Sun, 31 Mar 2002 11:45:52 -0500 Date: Sun, 31 Mar 2002 11:45:51 -0500 From: nico To: Albert Lunde Cc: ietf-ssh@netbsd.org Subject: Re: SFTP File open modes Message-ID: <20020331114551.A3780@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA225@lespaul.process.com> <20020329221231.A300@NICO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Albert-Lunde@northwestern.edu on Sat, Mar 30, 2002 at 10:32:15AM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Mar 30, 2002 at 10:32:15AM -0600, Albert Lunde wrote: > * First, one should distingush between a literal _ASCII_ mode, and a > _text_ mode. > > The most specific proposal posted suggested using Latin-1 as a > least-common-denominator wire encoding, with a bunch of negotiated > alternatives. In this day and age, I think it would make more sense > to use something like UTF-8 (further spectified to reduce ambiguties). > > I count at least three widely-used ways of encoding end-of-lines with > characters (CR,LF, CRLF) plus fixed-length records, plus counted > varable-length records: I don't know what you are thinking of in > saying "two". I confess: I was thinking DOS vs. Unix (CRLF vs. LF). > * Text mode is a big win in the case of an OS which has files in some > well-known but ideosyncratic format, because the clients don't have > to say, know all the varients of EBCDIC or VMS record formats, just a > single wire format. As someone else just pointed out, nowadays text documents come in complex binary formats such as PDF and what not. I think having dos2unix and unix2dos support in the client would be nice for us *nix types. But I can do without. And certainly I don't think this belongs on the server side. > * But I think you've got a point that a server may not _know_ the > encoding of files, or may not want to support the overhead of a text > mode. > > I don't know any foolproof way to detect which files in my Mac are in > Mac-extended-ASCII, which are in Latin1, and which are in Shift-JIS > (because I've been running the Japaneses language kit on on of my > Macs for years). The Mac type/creator scheme is more or less > orthogonal to i18n issues. Heh. Good luck. > So this isn't something we should expect to be able to implement on > every server, or for every file. Or any file types at all, not in the server, or rather, not in the protocol. Having the server identify file types would facilitate client-side file type conversions - having the server do the type conversions (as proposed) complicates the protocol. Any conversions should be optional (i.e., MAY). > -- > Albert Lunde Albert-Lunde@northwestern.edu (new address) > Albert-Lunde@nwu.edu (old address) > Cheers, Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 11:50:05 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25709 for ; Sun, 31 Mar 2002 11:50:05 -0500 (EST) Received: (qmail 26204 invoked by uid 605); 31 Mar 2002 16:50:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26197 invoked from network); 31 Mar 2002 16:50:03 -0000 Received: from out012pub.verizon.net (HELO out012.verizon.net) (206.46.170.137) by mail.netbsd.org with SMTP; 31 Mar 2002 16:50:03 -0000 Received: from pool-162-84-147-41.ny5030.east.verizon.net ([162.84.146.82]) by out012.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020331165002.MEAS1346.out012.verizon.net@pool-162-84-147-41.ny5030.east.verizon.net>; Sun, 31 Mar 2002 10:50:02 -0600 Received: by pool-162-84-147-41.ny5030.east.verizon.net (sSMTP sendmail emulation); Sun, 31 Mar 2002 11:50:04 -0500 Date: Sun, 31 Mar 2002 11:50:04 -0500 From: nico To: Richard Whalen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Additional thoughts on text transfers Message-ID: <20020331115004.B3780@NICO> References: <63D30D6E10CFD11190A90000F805FE86040AA237@lespaul.process.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <63D30D6E10CFD11190A90000F805FE86040AA237@lespaul.process.com>; from Whalenr@process.com on Fri, Mar 29, 2002 at 09:34:12AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Mar 29, 2002 at 09:34:12AM -0500, Richard Whalen wrote: > And what kinds of systems have you exchanged text files with? Ever try VMS? > The majority of text files on VMS systems are stored as variable length > record files with implied line separators. In most files there is a 2 byte > record length between each record, that does not provide carriage control. Would not an extension by which the client and server can tell each other the "type" of a given file suffice? That way the conversions have to be made before/after the SFTP exchange and there is no need to burden the protocol with all the issues related to record-oriented files, seek offset issues, etc... Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 22:26:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03939 for ; Sun, 31 Mar 2002 22:26:28 -0500 (EST) Received: (qmail 9151 invoked by uid 605); 1 Apr 2002 03:26:26 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 1 Apr 2002 03:26:26 -0000 Message-ID: <20020401032626.9150.qmail@mail.netbsd.org> From: alias@netbsd.org Cc: recipient list not shown: ; Received: (qmail 9144 invoked from network); 1 Apr 2002 03:26:25 -0000 Received: from unknown (HELO webmaster) (211.192.91.195) by mail.netbsd.org with SMTP; 1 Apr 2002 03:26:25 -0000 test Sender: ietf-ssh-owner@netbsd.org Precedence: list From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 23:38:09 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06149 for ; Sun, 31 Mar 2002 23:38:09 -0500 (EST) Received: (qmail 11532 invoked by uid 605); 1 Apr 2002 04:38:08 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020401043808.11531.qmail@mail.netbsd.org> Received: (qmail 11525 invoked from network); 1 Apr 2002 04:38:06 -0000 Received: from unknown (HELO omno1060.com) (195.68.114.2) by mail.netbsd.org with SMTP; 1 Apr 2002 04:38:06 -0000 From: "ietf-ssh" Reply-To: "ietf-ssh" To: ietf-ssh@netbsd.org Date: Sat, 30 Mar 2002 23:39:20 -0500 Subject: ietf-ssh , we can assist you. X-Mailer: Microsoft Outlook Express 5.00.2919.1990 MIME-Version: 1.0 X-Precedence-Ref: 1234056789zxcvbnm Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA06149 This is great! Clean G-rated and FUN! http://www.omerset3009f.home.ro/cert.jpg From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 23:38:20 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06161 for ; Sun, 31 Mar 2002 23:38:20 -0500 (EST) Received: (qmail 11878 invoked by uid 605); 1 Apr 2002 04:38:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11871 invoked from network); 1 Apr 2002 04:38:17 -0000 Received: from tms.tm3.com (208.216.14.13) by mail.netbsd.org with SMTP; 1 Apr 2002 04:38:17 -0000 Received: by tmgnymsg1.tmol.com with Internet Mail Service (5.5.2653.19) id ; Sun, 31 Mar 2002 23:38:16 -0500 Message-ID: <1DCD8EE519B1D511B78B0002A53F8B02D97675@TMGNYMSG2> From: "Webb, Carlos" To: ietf-ssh Subject: Out of Office AutoReply: ietf-ssh , we can assist you. Date: Sun, 31 Mar 2002 23:35:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: ietf-ssh-owner@netbsd.org Precedence: list If you need an immediate response please contact: Technical Operations-NY at (212) 807-5395. Thank you, Carlos From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 23:38:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06177 for ; Sun, 31 Mar 2002 23:38:28 -0500 (EST) Received: (qmail 12395 invoked by uid 605); 1 Apr 2002 04:38:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12344 invoked from network); 1 Apr 2002 04:38:21 -0000 Received: from mail1.telekom.de (62.225.183.235) by mail.netbsd.org with SMTP; 1 Apr 2002 04:38:21 -0000 Received: from g8pbq.blf01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for ietf-ssh@netbsd.org; Mon, 1 Apr 2002 06:36:57 +0200 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Apr 2002 06:38:19 +0200 Message-Id: <1BA26ABC57F3D41191390003470C0FD902030FA0@U8PM9.blf01.telekom.de> From: "Reutter, Rene" To: ietf-ssh@netbsd.org Subject: Abwesenheitsnotiz: ietf-ssh , we can assist you. Date: Mon, 1 Apr 2002 06:38:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA06177 Sehr geehrte Damen und Herren, ich bin erst wieder am 08. April 2002 in meinem Büro in Darmstadt erreichbar. Ihre Nachricht wird nicht weitergeleitet ! In dringenden Fällen wenden Sie sich bitte an meinen Vertreter Herrn Wolfgang Pietrus, Tel.: 06151 818 6113 oder an das Sekretariat der SL Security, Tel.: 06151 818 5001 Mit freundlichem Gruß René Reutter ------------------------------------------------------ T-Systems CSM GmbH Global Computing Factory SL Security - CERT Senior IT-Architekt Hausanschrift: Pallaswiesenstrasse 180, 64293 Darmstadt Postanschrift: Postfach 10 14 54, 64214 Darmstadt Telefon: (0 61 51) 8 18-61 14 Telefax: (0 52 1) 92 10 86 08 Mobiltelefon: (01 70) 4 54 49 07 Mail: mailto:reutter@t-systems.com Zertifikat: ldap://zertifikate.telekom.de:389 Web: http://www.t-systems.de Hinweis: Diese Nachricht oder deren Anlagen können vertraulichen Inhalts, oder auf eine andere Weise schutzwürdig sein. Sollten Sie nicht der beabsichtigte Empfänger der Nachricht sein, oder diese Nachricht versehentlich erhalten haben, sind Sie nicht berechtigt, den Inhalt der Nachricht weiterzuleiten, kopieren oder den Inhalt auf eine andere Art zu verbreiten. Wenn Sie diese Nachricht versehentlich erhalten haben, benachrichtigen Sie bitte den Absender und löschen Sie die Nachricht mitsamt den Anlagen. Vielen Dank. Notice: This transmittal and or attachments may be confidential attorney-client communication or may otherwise be privileged or confidential. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Mar 31 23:38:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06189 for ; Sun, 31 Mar 2002 23:38:35 -0500 (EST) Received: (qmail 12440 invoked by uid 605); 1 Apr 2002 04:38:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12406 invoked from network); 1 Apr 2002 04:38:22 -0000 Received: from hoemail1.lucent.com (HELO hoemail1.firewall.lucent.com) (192.11.226.161) by mail.netbsd.org with SMTP; 1 Apr 2002 04:38:22 -0000 Received: from ma8117exch001p.wins.lucent.com (h152-148-40-164.lucent.com [152.148.40.164]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g314cL101288 for ; Sun, 31 Mar 2002 23:38:21 -0500 (EST) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2650.21) id <1QG2BXGA>; Sun, 31 Mar 2002 23:38:20 -0500 Message-ID: From: "Ospina, Ivan H \(Ivan\)" To: ietf-ssh Subject: Out of Office AutoReply: ietf-ssh , we can assist you. Date: Sun, 31 Mar 2002 23:38:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Sender: ietf-ssh-owner@netbsd.org Precedence: list I am on vacation until April 8. If you have any issues that require immediate attention please contact stncs at 1-866-LUCENT8 option 4 or at stncs@lucent.com.