From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jun 12 08:42: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 IAA25581 for ; Wed, 12 Jun 2002 08:42:22 -0400 (EDT) Received: (qmail 25640 invoked by uid 605); 12 Jun 2002 12:42:53 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020612124253.25639.qmail@mail.netbsd.org> Received: (qmail 25620 invoked from network); 12 Jun 2002 12:42:44 -0000 Received: from cmr-u-3077.mc.onolab.com (HELO hiperdescuento.com) (62.42.252.6) by mail.netbsd.org with SMTP; 12 Jun 2002 12:42:44 -0000 From: "Sergio de latin mega" To: sergio@hiperdescuento.com Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 12 Jun 2002 14:40:13 +0200 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Estimado amigo: Aprovecho la presente para saludarte e invitarte a que visites el nuevo diseño y presentación de nuestro centro comercial http://www.hiperdescuento.com lo que esperamos nos consolide aún más lideres en el comercio electrónico de habla hispana. Así mismo, quiero hacerte participe, por si es de tu interés, de un nuevo desarrollo tecnológico ( el asesor de compra on-line) que rompe una de las grandes lacras del comercio electrónico por Internet: La soledad del cliente ante una web y la falta de control que sobre el posible cliente tiene el comercio on-line. A fin de mejorar, entre todos, el desarrollo del comercio electrónico, te comunicamos que desde nuestra compañía estamos cediendo gratuitamente este instrumento de mejora en la gestión de la venta on line a todos nuestros clientes, asociados y amigos. Dándote las gracias por anticipado, te indico que si es de tu interés el incorporar este moderno proceso de gestión online para multiplicar las ventas de tu web, no dudes en solicitarnos información sin compromiso. En espera de tus noticias recibe un cordial saludo de JESÚS MARTÍNEZ Dtor. www.hiperdescuento.com si no deseas recibir mas email de este tipo entra en http://www.hiperdescuento.com/borrame/ e indica tu email alli. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jun 18 21:56: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 VAA11250 for ; Tue, 18 Jun 2002 21:56:31 -0400 (EDT) Received: (qmail 1359 invoked by uid 605); 19 Jun 2002 01:57:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1352 invoked from network); 19 Jun 2002 01:57:04 -0000 Received: from skuld.ucsd.edu (132.239.51.19) by mail.netbsd.org with SMTP; 19 Jun 2002 01:57:04 -0000 Received: from bintijua.ucsd.edu (bintijua.ucsd.edu [132.239.55.103]) by skuld.ucsd.edu (8.11.6/8.11.6) with ESMTP id g5J1vKq01032; Tue, 18 Jun 2002 18:57:20 -0700 (PDT) Received: from bintijua.ucsd.edu (localhost [127.0.0.1]) by bintijua.ucsd.edu (8.11.6/8.11.6) with ESMTP id g5J1uux12005; Tue, 18 Jun 2002 18:56:57 -0700 (PDT) Message-Id: <200206190156.g5J1uux12005@bintijua.ucsd.edu> From: "Tadayoshi Kohno" Reply-To: tkohno@cs.ucsd.edu cc: tkohno@cs.ucsd.edu To: ietf-ssh@netbsd.org Subject: Paper on SSH Date: Tue, 18 Jun 2002 18:56:56 -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list As Wei Dai recently pointed out, the current SSH protocol is insecure (because of problems with way CBC mode is used). In the paper http://eprint.iacr.org/2002/078/ Mihir Bellare, Chanathip Namprempre, and I show how to provably fix the SSH protocol. We have placed a summary of our recommendations at http://www-cse.ucsd.edu/users/tkohno/papers/SSH/sshadvice.html We hope that our provable security results will be of use to the IETF SSH Working Group. Yoshi From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jun 19 13:07: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 NAA27284 for ; Wed, 19 Jun 2002 13:07:42 -0400 (EDT) Received: (qmail 6487 invoked by uid 605); 19 Jun 2002 17:08:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6480 invoked from network); 19 Jun 2002 17:08:13 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 19 Jun 2002 17:08:13 -0000 Received: from jurassic.eng.sun.com ([129.146.81.36]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14839; Wed, 19 Jun 2002 11:08:12 -0600 (MDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.4+Sun/8.12.4) with SMTP id g5JH8CPC210788; Wed, 19 Jun 2002 10:08:12 -0700 (PDT) Message-Id: <200206191708.g5JH8CPC210788@jurassic.eng.sun.com> Date: Wed, 19 Jun 2002 10:08:09 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: draft-ietf-secsh-assignednumbers-00.txt To: internet-drafts@ietf.org Cc: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Brace_of_Ducks_885_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_11 SunOS 5.10 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list --Brace_of_Ducks_885_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: oQOCaWRI5LIgGWKq9yud3A== The attached document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. -- Darren J Moffat --Brace_of_Ducks_885_000 Content-Type: TEXT/plain; name="draft-ietf-secsh-assignednumbers-00.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-ietf-secsh-assignednumbers-00.txt Content-MD5: siMe3IELiU9p5PIQX41VTw== Network Working Group S. Lehtinen Internet-Draft SSH Communications Security Corp Expires: October 30, 2002 D. Moffat Sun Microsystems May 2002 SSH Protocol Assigned Numbers draft-ietf-secsh-assignednumbers-00.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 October 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH- CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. Lehtinen & Moffat Expires October 30, 2002 [Page 1] Internet-Draft SSH Protocol Assigned Numbers May 2002 Table of Contents 1. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Disconnect Codes . . . . . . . . . . . . . . . . . . . . . . 4 2. Service Names . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Authentication Method Names . . . . . . . . . . . . . . . . 5 2.2 Connection Protocol Assigned Names . . . . . . . . . . . . . 6 2.2.1 Connection Protocol Channel Types . . . . . . . . . . . . . 6 2.2.2 Connection Protocol Global Request Names . . . . . . . . . . 6 2.2.3 Connection Protocol Channel Request Names . . . . . . . . . 6 3. Key Exchange Method Names . . . . . . . . . . . . . . . . . 7 4. Assigned Algorithm Names . . . . . . . . . . . . . . . . . . 7 4.1 Encryption Algorithm Names . . . . . . . . . . . . . . . . . 7 4.2 MAC Algorithm Names . . . . . . . . . . . . . . . . . . . . 8 4.3 Public Key Algorithm Names . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 Lehtinen & Moffat Expires October 30, 2002 [Page 2] Internet-Draft SSH Protocol Assigned Numbers May 2002 1. Message Numbers The Message Number is an 8-bit value, which describes the payload of a packet. Protocol packets have message numbers in the range 1 to 255. These numbers have been allocated as follows in [SSH-ARCH]: Transport layer protocol: 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, etc.) 20 to 29 Algorithm negotiation 30 to 49 Key exchange method specific (numbers can be reused for different authentication methods) User authentication protocol: 50 to 59 User authentication generic 60 to 79 User authentication method specific (numbers can be reused for different authentication methods) Connection protocol: 80 to 89 Connection protocol generic 90 to 127 Channel related messages Reserved for client protocols: 128 to 191 Reserved Local extensions: 192 to 255 Local extensions Requests for assignments of new message numbers must be accompanied by an RFC which describes the new packet type. If the RFC is not on the standards-track (i.e. it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the message number is assigned. Message ID Value Reference ----------- ----- --------- SSH_MSG_DISCONNECT 1 [SSH-TRANS] SSH_MSG_IGNORE 2 [SSH-TRANS] SSH_MSG_UNIMPLEMENTED 3 [SSH-TRANS] SSH_MSG_DEBUG 4 [SSH-TRANS] SSH_MSG_SERVICE_REQUEST 5 [SSH-TRANS] Lehtinen & Moffat Expires October 30, 2002 [Page 3] Internet-Draft SSH Protocol Assigned Numbers May 2002 SSH_MSG_SERVICE_ACCEPT 6 [SSH-TRANS] SSH_MSG_KEXINIT 20 [SSH-TRANS] SSH_MSG_NEWKEYS 21 [SSH-TRANS] SSH_MSG_KEXDH_INIT 30 [SSH-TRANS] SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS] SSH_MSG_USERAUTH_REQUEST 50 [SSH-USERAUTH] SSH_MSG_USERAUTH_FAILURE 51 [SSH-USERAUTH] SSH_MSG_USERAUTH_SUCCESS 52 [SSH-USERAUTH] SSH_MSG_USERAUTH_BANNER 53 [SSH-USERAUTH] SSH_MSG_USERAUTH_PK_OK 60 [SSH-USERAUTH] SSH_MSG_GLOBAL_REQUEST 80 [SSH-CONNECT] SSH_MSG_REQUEST_SUCCESS 81 [SSH-CONNECT] SSH_MSG_REQUEST_FAILURE 82 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN 90 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_CONFIRMATION 91 [SSH-CONNECT] SSH_MSG_CHANNEL_OPEN_FAILURE 92 [SSH-CONNECT] SSH_MSG_CHANNEL_WINDOW_ADJUST 93 [SSH-CONNECT] SSH_MSG_CHANNEL_DATA 94 [SSH-CONNECT] SSH_MSG_CHANNEL_EXTENDED_DATA 95 [SSH-CONNECT] SSH_MSG_CHANNEL_EOF 96 [SSH-CONNECT] SSH_MSG_CHANNEL_CLOSE 97 [SSH-CONNECT] SSH_MSG_CHANNEL_REQUEST 98 [SSH-CONNECT] SSH_MSG_CHANNEL_SUCCESS 99 [SSH-CONNECT] SSH_MSG_CHANNEL_FAILURE 100 [SSH-CONNECT] 1.1 Disconnect Codes The Disconnect code is an 8-bit value, which describes the disconnect reason. Requests for assignments of new disconnect codes must be accompanied by an RFC which describes the new disconnect reason code. Disconnect code Value Reference ---------------- ----- --------- SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_ERROR 2 [SSH-TRANS] SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 [SSH-TRANS] SSH_DISCONNECT_RESERVED 4 [SSH-TRANS] SSH_DISCONNECT_MAC_ERROR 5 [SSH-TRANS] SSH_DISCONNECT_COMPRESSION_ERROR 6 [SSH-TRANS] SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 [SSH-TRANS] SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 [SSH-TRANS] SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 [SSH-TRANS] SSH_DISCONNECT_CONNECTION_LOST 10 [SSH-TRANS] SSH_DISCONNECT_BY_APPLICATION 11 [SSH-TRANS] SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 [SSH-TRANS] SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 [SSH-TRANS] Lehtinen & Moffat Expires October 30, 2002 [Page 4] Internet-Draft SSH Protocol Assigned Numbers May 2002 SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 [SSH-TRANS] SSH_DISCONNECT_ILLEGAL_USER_NAME 15 [SSH-TRANS] 2. Service Names The Service Name is used to describe a protocol layer. These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new service names must be accompanied by an RFC which describes the interpretation for the service name. If the RFC is not on the standards-track (i.e. it is an informational or experimental RFC), it must be explicitly reviewed and approved by the IESG before the RFC is published and the service name is assigned. Service name Reference ------------- --------- ssh-userauth [SSH-USERAUTH] ssh-connection [SSH-CONNECT] 2.1 Authentication Method Names The Authentication Method Name is used to describe an authentication method for the "ssh-userauth" service [SSH-USERAUTH]. These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new authentication method names must be accompanied by an RFC which describes the interpretation for the authentication method. Method name Reference ------------ --------- publickey [SSH-USERAUTH, Section 4] password [SSH-USERAUTH, Section 5] hostbased [SSH-USERAUTH, Section 6] none [SSH-USERAUTH, Section 2.3] Lehtinen & Moffat Expires October 30, 2002 [Page 5] Internet-Draft SSH Protocol Assigned Numbers May 2002 2.2 Connection Protocol Assigned Names The following request and type names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignments of new assigned names must be accompanied by an RFC which describes the interpretation for the type or request. 2.2.1 Connection Protocol Channel Types Channel type Reference ------------ --------- session [SSH-CONNECT, Section 4.1] x11 [SSH-CONNECT, Section 4.3.2] forwarded-tcpip [SSH-CONNECT, Section 5.2] direct-tcpip [SSH-CONNECT, Section 5.2] 2.2.2 Connection Protocol Global Request Names Request type Reference ------------ --------- tcpip-forward [SSH-CONNECT, Section 5.1] cancel-tcpip-forward [SSH-CONNECT, Section 5.1] 2.2.3 Connection Protocol Channel Request Names Request type Reference ------------ --------- pty-req [SSH-CONNECT, Section 4.2] x11-req [SSH-CONNECT, Section 4.3.1] env [SSH-CONNECT, Section 4.4] shell [SSH-CONNECT, Section 4.5] exec [SSH-CONNECT, Section 4.5] subsystem [SSH-CONNECT, Section 4.5] window-change [SSH-CONNECT, Section 4.7] xon-xoff [SSH-CONNECT, Section 4.8] signal [SSH-CONNECT, Section 4.9] exit-status [SSH-CONNECT, Section 4.10] exit-signal [SSH-CONNECT, Section 4.10] Lehtinen & Moffat Expires October 30, 2002 [Page 6] Internet-Draft SSH Protocol Assigned Numbers May 2002 3. Key Exchange Method Names The Key Exchange Method Name describes a key-exchange method for the protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new key-exchange method names must be accompanied by a reference to a standards-track or Informational RFC which describes this method. Method name Reference ------------ --------- diffie-hellman-group1-sha1 [SSH-TRANS, Section 4.5] 4. Assigned Algorithm Names The following identifiers (names) MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. Requests for assignment of new algorithm names must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes the algorithm. 4.1 Encryption Algorithm Names Cipher name Reference ------------ --------- 3des-cbc [SSH-TRANS, Section 4.3] blowfish-cbc [SSH-TRANS, Section 4.3] twofish256-cbc [SSH-TRANS, Section 4.3] twofish-cbc [SSH-TRANS, Section 4.3] twofish192-cbc [SSH-TRANS, Section 4.3] twofish128-cbc [SSH-TRANS, Section 4.3] aes256-cbc [SSH-TRANS, Section 4.3] aes192-cbc [SSH-TRANS, Section 4.3] aes128-cbc [SSH-TRANS, Section 4.3] serpent256-cbc [SSH-TRANS, Section 4.3] serpent192-cbc [SSH-TRANS, Section 4.3] serpent128-cbc [SSH-TRANS, Section 4.3] arcfour [SSH-TRANS, Section 4.3] idea-cbc [SSH-TRANS, Section 4.3] cast128-cbc [SSH-TRANS, Section 4.3] none [SSH-TRANS, Section 4.3] Lehtinen & Moffat Expires October 30, 2002 [Page 7] Internet-Draft SSH Protocol Assigned Numbers May 2002 4.2 MAC Algorithm Names MAC name Reference --------- --------- hmac-sha1 [SSH-TRANS, Section 4.4] hmac-sha1-96 [SSH-TRANS, Section 4.4] hmac-md5 [SSH-TRANS, Section 4.4] hmac-md5-96 [SSH-TRANS, Section 4.4] none [SSH-TRANS, Section 4.4] 4.3 Public Key Algorithm Names Algorithm name Reference --------------- --------- ssh-dss [SSH-TRANS, Section 4.6] ssh-rsa [SSH-TRANS, Section 4.6] x509v3-sign-rsa [SSH-TRANS, Section 4.6] x509v3-sign-dss [SSH-TRANS, Section 4.6] spki-sign-rsa [SSH-TRANS, Section 4.6] spki-sign-dss [SSH-TRANS, Section 4.6] pgp-sign-rsa [SSH-TRANS, Section 4.6] pgp-sign-dss [SSH-TRANS, Section 4.6] References [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-14.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. Lehtinen & Moffat Expires October 30, 2002 [Page 8] Internet-Draft SSH Protocol Assigned Numbers May 2002 Authors' Addresses Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Darren J Moffat Sun Microsystems 901 San Antonio Road Palo Alto 94303 USA EMail: Darren.Moffat@Sun.COM Lehtinen & Moffat Expires October 30, 2002 [Page 9] Internet-Draft SSH Protocol Assigned Numbers May 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. Lehtinen & Moffat Expires October 30, 2002 [Page 10] --Brace_of_Ducks_885_000-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jun 21 07:38: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 HAA08372 for ; Fri, 21 Jun 2002 07:38:38 -0400 (EDT) Received: (qmail 17551 invoked by uid 605); 21 Jun 2002 11:38:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16809 invoked from network); 21 Jun 2002 11:38:26 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 21 Jun 2002 11:38:26 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08198; Fri, 21 Jun 2002 07:37:28 -0400 (EDT) Message-Id: <200206211137.HAA08198@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-assignednumbers-00.txt Date: Fri, 21 Jun 2002 07:37:26 -0400 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 Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-00.txt Pages : 10 Date : 20-Jun-02 This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH- CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-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-assignednumbers-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-assignednumbers-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: <20020620141804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020620141804.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jun 26 07:42: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 HAA13053 for ; Wed, 26 Jun 2002 07:42:33 -0400 (EDT) Received: (qmail 11365 invoked by uid 605); 26 Jun 2002 11:43:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11358 invoked from network); 26 Jun 2002 11:43:08 -0000 Received: from arwen.bravenet.com (66.180.230.22) by mail.netbsd.org with SMTP; 26 Jun 2002 11:43:08 -0000 Received: from rosa.sf.bravenet.com (rosa.sf.bravenet.com [172.16.0.64]) by arwen.bravenet.com (Postfix) with ESMTP id E12D07184 for ; Wed, 26 Jun 2002 04:43:02 -0700 (PDT) Received: by rosa.sf.bravenet.com (Postfix, from userid 500) id D11091B5AB; Wed, 26 Jun 2002 04:43:02 -0700 (PDT) To: ietf-ssh@netbsd.org Subject: Confirm your subscription Received: from [212.122.226.59] by bravenet.com with HTTP; Wed, 26 Jun 2002 04:43:02 -0700 From: teefalist@yahoo.co.uk X-Usernum: 1938370831 X-IPAddy: 212.122.226.59 Message-Id: <20020626114302.D11091B5AB@rosa.sf.bravenet.com> Date: Wed, 26 Jun 2002 04:43:02 -0700 (PDT) Sender: ietf-ssh-owner@netbsd.org Precedence: list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mailing List Subscription Confirmation *** Confirmation required *** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You have been invited to join our mailing list. This list has a double optin feature so you must go to the URL listed below to finish joining this list. This is a safeguard for you. PLEASE CLICK THE LINK BELOW TO CONFIRM YOUR SUBSCRIPTION: http://pub23.bravenet.com/elist/add.php?usernum=1938370831&id=4281091 IF YOU DO NOT WISH TO SUBSCRIBE DO NOT CLICK THE LINK: If this message was sent in error, please disregard it and no further email will be sent to you on this subject. ----------------------------------------------------------------------- Bravenet.com ~ free webtools for webmasters ~ http://www.bravenet.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jun 26 07:59: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 HAA13802 for ; Wed, 26 Jun 2002 07:59:09 -0400 (EDT) Received: (qmail 21624 invoked by uid 605); 26 Jun 2002 11:59:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21617 invoked from network); 26 Jun 2002 11:59:49 -0000 Received: from arwen.bravenet.com (66.180.230.22) by mail.netbsd.org with SMTP; 26 Jun 2002 11:59:49 -0000 Received: from otho.sf.bravenet.com (otho.sf.bravenet.com [172.16.0.61]) by arwen.bravenet.com (Postfix) with ESMTP id 48C126C6E for ; Wed, 26 Jun 2002 04:59:49 -0700 (PDT) Received: by otho.sf.bravenet.com (Postfix, from userid 500) id 423571B589; Wed, 26 Jun 2002 04:59:49 -0700 (PDT) To: ietf-ssh@netbsd.org Subject: Welcome Received: from [214.3.17.38] by bravenet.com with HTTP; Wed, 26 Jun 2002 04:59:49 -0700 From: teefalist@yahoo.co.uk X-Usernum: 1938370831 X-IPAddy: 214.3.17.38 Message-Id: <20020626115949.423571B589@otho.sf.bravenet.com> Date: Wed, 26 Jun 2002 04:59:49 -0700 (PDT) Sender: ietf-ssh-owner@netbsd.org Precedence: list You have successfully been added to our contest we hope you will be a winner http://teefacash.8m.com ----------------------------------------------------------------------- Get Your Site Blasted with Quality Traffic! Click Now! http://linktrack.bravenet.com/o.php?id=405 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 27 01:28: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 BAA23632 for ; Thu, 27 Jun 2002 01:28:55 -0400 (EDT) Received: (qmail 14542 invoked by uid 605); 27 Jun 2002 05:29:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14535 invoked from network); 27 Jun 2002 05:29:34 -0000 Received: from mx1.eskimo.com (204.122.16.48) by mail.netbsd.org with SMTP; 27 Jun 2002 05:29:34 -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 WAA22528 for ; Wed, 26 Jun 2002 22:29:32 -0700 Received: (from weidai@localhost) by eskimo.com (8.9.1a/8.9.1) id WAA13542 for ietf-ssh@netbsd.org; Wed, 26 Jun 2002 22:29:32 -0700 (PDT) Date: Wed, 26 Jun 2002 22:29:31 -0700 From: Wei Dai To: ietf-ssh@netbsd.org Subject: protocol support for privilege seperation Message-ID: <20020626222931.E4905@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list It's a good idea for an SSH server to drop down to normal user privileges after authentication is complete, and only make requests to a privileged monitor for things like key re-exchanges. Unfortunately, without changes to the SSH protocol as currently defined, there seems to be no way to do this without allowing the non-privileged process to perform man-in-the-middle attacks if it was compromised. The attack is as follows. Assume an attacker is able to corrupt a non-privileged SSH process and cause it to execute arbitrary code. He impersonates the server at the TCP/IP layer and waits for someone to log in. When a connection comes in, he starts a key re-exchange as the couterparty to the SSH process that he controls, using the SSH_MSG_KEXINIT packet he received from the remote party and forwarding responses back and forth until the key exchange is complete. At this point, even if the Diffie-Hellman key generation and agreement were done in the privileged monitor, the monitor must either pass the shared secret back to the non-privileged process, or act as an encryption/MAC oracle for it. Either way, the attacker can now send arbitrary messages to the remote party that it will think came from the server. The problems seems to be that the privileged monitor has no way to tell whether a SSH_MSG_KEXINIT packet is for the initial key exchange, or for a re-exchange. I propose making use of the reserved field of SSH_MSG_KEXINIT, something like: byte SSH_MSG_KEXINIT ... boolean first_kex_packet_follows boolean is_initial_exchange byte[3] 0 (reserved) The privileged monitor would refuse to sign any exchange hash where is_initial_exchange is true if it's not an initial exchange. I think that would allow implementors to take full advantage of privilege seperation and avoid this attack. If current implementations are programmed to ignore the reserved field (rather than treat a non-zero value as an error), this should cause no compatibility problems. Specificly, an old client that does not make use of is_initial_exchange would be vulnerable to this attack, but it would still work. Comments? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jun 27 17:38: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 RAA17810 for ; Thu, 27 Jun 2002 17:38:46 -0400 (EDT) Received: (qmail 11422 invoked by uid 605); 27 Jun 2002 21:39:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11415 invoked from network); 27 Jun 2002 21:39:23 -0000 Received: from citi.umich.edu (141.211.133.111) by mail.netbsd.org with SMTP; 27 Jun 2002 21:39:23 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id 2F931207C7; Thu, 27 Jun 2002 17:39:22 -0400 (EDT) Date: Thu, 27 Jun 2002 17:39:22 -0400 From: Niels Provos To: Wei Dai Cc: ietf-ssh@netbsd.org Subject: Re: protocol support for privilege seperation Message-ID: <20020627213921.GX15772@citi.citi.umich.edu> Mail-Followup-To: Wei Dai , ietf-ssh@netbsd.org References: <20020626222931.E4905@eskimo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020626222931.E4905@eskimo.com> User-Agent: Mutt/1.3.27i Sender: ietf-ssh-owner@netbsd.org Precedence: list that is a known problem. but for the same reason, if the non-privilege separated process gets compromised, it can do a man-in-the-middle with ifself. or just read the key file and use if from a different hosts. this increases security, it is not perfection. On Wed, Jun 26, 2002 at 10:29:31PM -0700, Wei Dai wrote: > It's a good idea for an SSH server to drop down to normal user privileges > after authentication is complete, and only make requests to a privileged > monitor for things like key re-exchanges. Unfortunately, without changes > to the SSH protocol as currently defined, there seems to be no way to do > this without allowing the non-privileged process to perform > man-in-the-middle attacks if it was compromised. > > The attack is as follows. Assume an attacker is able to corrupt a > non-privileged SSH process and cause it to execute arbitrary code. He > impersonates the server at the TCP/IP layer and waits for someone to log > in. When a connection comes in, he starts a key re-exchange as the > couterparty to the SSH process that he controls, using the SSH_MSG_KEXINIT > packet he received from the remote party and forwarding responses back and > forth until the key exchange is complete. At this point, even if the > Diffie-Hellman key generation and agreement were done in the privileged > monitor, the monitor must either pass the shared secret back to the > non-privileged process, or act as an encryption/MAC oracle for it. Either > way, the attacker can now send arbitrary messages to the remote party that > it will think came from the server. > > The problems seems to be that the privileged monitor has no way to tell > whether a SSH_MSG_KEXINIT packet is for the initial key exchange, or for a > re-exchange. I propose making use of the reserved field of > SSH_MSG_KEXINIT, something like: > > byte SSH_MSG_KEXINIT > ... > boolean first_kex_packet_follows > boolean is_initial_exchange > byte[3] 0 (reserved) > > The privileged monitor would refuse to sign any exchange hash where > is_initial_exchange is true if it's not an initial exchange. I think that > would allow implementors to take full advantage of privilege seperation > and avoid this attack. If current implementations are programmed to ignore > the reserved field (rather than treat a non-zero value as an error), this > should cause no compatibility problems. Specificly, an old client that > does not make use of is_initial_exchange would be vulnerable to this > attack, but it would still work. > > Comments?