From owner-ietf-ssh@clinet.fi Fri Nov 3 10:23:22 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09726 for ; Fri, 3 Nov 2000 10:23:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA21596 for ietf-ssh-outgoing; Fri, 3 Nov 2000 15:08:30 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA21584 for ; Fri, 3 Nov 2000 15:08:27 +0200 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 639 for ; Fri, 3 Nov 2000 06:10:44 -0700 Message-ID: <005101c04597$856968f0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: Subject: secsh for San Diego IETF meeting? Date: Fri, 3 Nov 2000 06:11:01 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit I see a draft agenda for the December IETF meeting in San Diego is out. http://www.ietf.org/meetings/agenda.html I don't see a secsh session scheduled yet. What do we need to do to get one on the schedule? Thanks. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Nov 3 11:30:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28042 for ; Fri, 3 Nov 2000 11:30:52 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA01590 for ietf-ssh-outgoing; Fri, 3 Nov 2000 16:14:04 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA01583 for ; Fri, 3 Nov 2000 16:14:02 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00752 for ; Fri, 3 Nov 2000 06:13:59 -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,v1.7) with ESMTP id JAA08125; Fri, 3 Nov 2000 09:13:58 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eA3EDKa143392; Fri, 3 Nov 2000 09:13:20 -0500 (EST) Message-Id: <200011031413.eA3EDKa143392@thunk.east.sun.com> From: Bill Sommerfeld To: "Jeff P. Van Dyke" cc: ietf-ssh@clinet.fi Subject: Re: secsh for San Diego IETF meeting? In-reply-to: Your message of "Fri, 03 Nov 2000 06:11:01 MST." <005101c04597$856968f0$0201a8c0@vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 03 Nov 2000 09:13:20 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk I'm currently on the road; I'll be sending in a schedule request to the secretariat on Monday. BTW, they'll want a list of other working groups to avoid conflicts with; if any of the implementors or document editors out there have suggestions of ones to avoid, let me know.. - Bill From owner-ietf-ssh@clinet.fi Tue Nov 7 08:10:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28457 for ; Tue, 7 Nov 2000 08:10:58 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA09731 for ietf-ssh-outgoing; Tue, 7 Nov 2000 13:04:55 +0200 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA09710 for ; Tue, 7 Nov 2000 13:04:41 +0200 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06229; Tue, 7 Nov 2000 06:04:33 -0500 (EST) Message-Id: <200011071104.GAA06229@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@clinet.fi From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-01.txt Date: Tue, 07 Nov 2000 06:04:32 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk --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 : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-01.txt Pages : 8 Date : 06-Nov-00 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the underlying authentication mechanism(s) used by the SSH server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.txt 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-auth-kbdinteract-01.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-auth-kbdinteract-01.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: <20001106120255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001106120255.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ssh@clinet.fi Thu Nov 9 08:05:35 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15960 for ; Thu, 9 Nov 2000 08:05:34 -0500 (EST) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA27602 for ietf-ssh-outgoing; Thu, 9 Nov 2000 12:52:30 +0200 Message-Id: <200011091052.MAA27602@mail.clinet.fi> Received: from TmpStr (dial-196-D02.FRA1.equant.net [57.66.132.196]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id MAA27578 for ; Thu, 9 Nov 2000 12:52:27 +0200 To: ietf-ssh@clinet.fi Subject: OFFER Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Date: Thu, 9 Nov 2000 13:52:28 +0300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to base64 by mail.clinet.fi id MAA27602 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA15960 Ïðåäëàãàåì âèçîâóþ ïîääåðæêó äëÿ Øâåéöàðèè - USD 60,-- íà ñðîê äî 14 äíåé äëÿ ïðîæèâàþùèõ â ÐÔ - ïðè íàëè÷èè àâèàáèëåòà è ñòðàõîâêè. Âîçìîæíà òàêæå ïîääåðæêà äëÿ äâóõðàçîâûõ âèç,áðîíèðîâàíèå è ïðîïëàòà îòåëåé. e-mail: schweiz@libel.org Åñëè Âû, íå æåëàåòå ïîëó÷àòü â äàëüíåéøåì íèêàêèõ ñîîáùåíèé, òî ïðèøëèòå ñâîé e-mail àäðåñ, íàçâàíèå ôèðìû, ðîä äåÿòåëüíîñòè è ìû èñêëþ÷èì Âàñ èç ñïèñêà ðàññûëêè. Ïðèíîñèì ñâîè èçâèíåíèÿ, åñëè äàííàÿ èíôîðìàöèÿ Âàñ íå èíòåðåñóåò. ðÒÅÄÌÁÇÁÅÍ ×ÉÚÏ×ÕÀ ÐÏÄÄÅÒÖËÕ ÄÌÑ û×ÅÊÃÁÒÉÉ - USD 60,-- ÎÁ ÓÒÏË ÄÏ 14 ÄÎÅÊ ÄÌÑ ÐÒÏÖÉ×ÁÀÝÉÈ × òæ - ÐÒÉ ÎÁÌÉÞÉÉ Á×ÉÁÂÉÌÅÔÁ É ÓÔÒÁÈÏ×ËÉ. ÷ÏÚÍÏÖÎÁ ÔÁËÖÅ ÐÏÄÄÅÒÖËÁ ÄÌÑ Ä×ÕÈÒÁÚÏ×ÙÈ ×ÉÚ, ÂÒÏÎÉÒÏ×ÁÎÉÅ É ÐÒÏÐÌÁÔÁ ÏÔÅÌÅÊ. e-mail: schweiz@libel.org åÓÌÉ ÷Ù ÎÅ ÖÅÌÁÅÔÅ ÐÏÌÕÞÁÔØ × ÄÁÌØÎÅÊÛÅÍ ÎÉËÁËÉÈ ÓÏÏÂÝÅÎÉÊ, ÔÏ ÐÒÉÛÌÉÔÅ Ó×ÏÊ e-mail ÁÄÒÅÓ, ÎÁÚ×ÁÎÉÅ ÆÉÒÍÙ, ÒÏÄ ÄÅÑÔÅÌØÎÏÓÔÉ É ÍÙ ÉÓËÌÀÞÉÍ ÷ÁÓ ÉÚ ÓÐÉÓËÁ ÒÁÓÓÙÌËÉ. ðÒÉÎÏÓÉÍ Ó×ÏÉ ÉÚ×ÉÎÅÎÉÑ, ÅÓÌÉ ÄÁÎÎÁÑ ÉÎÆÏÒÍÁÃÉÑ ÷ÁÓ ÎÅ ÉÎÔÅÒÅÓÕÅÔ. ¿àÕÔÛÐÓÐÕÜ ÒØ×ÞÒãî ßÞÔÔÕàÖÚã ÔÛï ÈÒÕÙæÐàØØ - USD 60,-- ÝÐ áàÞÚ ÔÞ 14 ÔÝÕÙ ÔÛï ßÞáâÞïÝÝÞ ßàÞÖØÒÐîéØå Ò ÀÄ - ßàØ ÝÐÛØçØØ ÐÒØÐÑØÛÕâÐ Ø áâàÐåÞÒÚØ. ²Þ×ÜÞÖÝÐ âÐÚÖÕ ßÞÔÔÕàÖÚÐ ÔÛï ÔÒãåàÐ×ÞÒëå ÒØ×, ÑàÞÝØàÞÒÐÝØÕ Ø ßàÞßÛÐâÐ ÞâÕÛÕÙ. e-mail: schweiz@libel.org µáÛØ ²ë, ÝÕ ÖÕÛÐÕâÕ ßÞÛãçÐâì Ò ÔÐÛìÝÕÙèÕÜ ÝØÚÐÚØå áÞÞÑéÕÝØÙ, âÞ ßàØèÛØâÕ áÒÞÙ e-mail ÐÔàÕá, ÝÐ×ÒÐÝØÕ äØàÜë, àÞÔ ÔÕïâÕÛìÝÞáâØ Ø Üë ØáÚÛîçØÜ ²Ðá Ø× áßØáÚÐ àÐááëÛÚØ. ¿àØÝÞáØÜ áÒÞØ Ø×ÒØÝÕÝØï, ÕáÛØ ÔÐÝÝÐï ØÝäÞàÜÐæØï ²Ðá ÝÕØÝâÕàÕáãÕâ. From owner-ietf-ssh@clinet.fi Thu Nov 16 21:35:47 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03658 for ; Thu, 16 Nov 2000 21:35:46 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA28098 for ietf-ssh-outgoing; Fri, 17 Nov 2000 02:30:37 +0200 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA28095 for ; Fri, 17 Nov 2000 02:30:35 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16051; Thu, 16 Nov 2000 16:30:29 -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,v1.7) with ESMTP id TAA03580; Thu, 16 Nov 2000 19:29:59 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAH0TJa226052; Thu, 16 Nov 2000 19:29:19 -0500 (EST) Message-Id: <200011170029.eAH0TJa226052@thunk.east.sun.com> From: Bill Sommerfeld To: Sami Lehtinen Cc: ietf-ssh@clinet.fi Subject: Re: New drafts (TODO) In-reply-to: Your message of "Thu, 16 Nov 2000 09:22:47 +0200." <14867.35655.867142.388764@asgard.tky.hut.fi> Reply-to: sommerfeld@east.sun.com Date: Thu, 16 Nov 2000 19:29:18 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > Should concatenated string encoding specify length of each string? > (transport, section 6) > - [chair couldn't find context; will take to list] Ok, I found the context: Date: Mon, 24 Aug 1998 09:28:38 +0000 From: Sigurdur Asgeirsson 3. Sections 4 and 6 of the Authentication Protocol document both contain the following paragraph: -- Signature is a signature with the private host key of the following data, in this order: o session identifier, and o packet payload without the signature. -- Is the signature performed over the raw data of the session identifier and the packet payload or are the two perhaps supposed to be converted into strings (length prepended) before signing, like in section 6 of the Transport Layer document (Diffie-Hellman Key Exchange)? It appears that this was revised subsequent to this message but the text is still somewhat vague; userauth-07 says (identical text in sections 4 and 6): Signature is a signature with the private host key of the following data, in this order: o session identifier (encoded as string), and o packet payload without the signature. This could be expressed a bit less ambiguously as something like: Signature is a signature with the ... key over the following message: string session identifier 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 > DH parameter selection clarification > - [chair couldn't find context; will take to list] The context for this issue appears to be: Date: Thu, 25 Feb 1999 09:28:01 +0000 From: Sigurdur Asgeirsson 2. Section 5.2, "Output from Key Exchange" contains the following text: "The key exchange produces two values: a shared secret K, and an exchange hash H." Section 6, "Diffie-Hellman Key Exchange" then goes to great lengths to specify excactly how the exchange hash "H" is computed, but fails to specify the format of "K", which is used in key derivation. I suggest that section 6 specify that the binary format of K, the shared secret, be mpint (as in the ssh reference implementation). It appears that transport-07 still leaves this unspecified. - Bill From owner-ietf-ssh@clinet.fi Fri Nov 17 11:20:02 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12979 for ; Fri, 17 Nov 2000 11:20:01 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA22986 for ietf-ssh-outgoing; Fri, 17 Nov 2000 16:14:15 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA22978 for ; Fri, 17 Nov 2000 16:14:13 +0200 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 581 for ; Fri, 17 Nov 2000 07:17:03 -0700 Message-ID: <003401c050a1$1cb785c0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: Subject: Secure Shell Public Key Channel Date: Fri, 17 Nov 2000 07:14:54 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit An individual draft for Secure Shell Public Key Channel has been submitted. The draft is available from: http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-channel-00.txt Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a channel that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The public key channel provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with a mandatory command. --- On a several occasions, there has been some interest in trying to standardize the file format of SSH public keys. At this time, I believe this draft provides a better and more comprehensive solution to the problem that users are having managing SSH public keys. We are very interested in receiving feedback on this draft. If time permits and there is sufficient interest, we hope there will be an opportunity to discuss this draft at the upcoming meeting in San Diego. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Nov 17 11:20:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13150 for ; Fri, 17 Nov 2000 11:20:27 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA22985 for ietf-ssh-outgoing; Fri, 17 Nov 2000 16:14:15 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA22977 for ; Fri, 17 Nov 2000 16:14:13 +0200 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 581 for ; Fri, 17 Nov 2000 07:17:05 -0700 Message-ID: <003501c050a1$1dd59ff0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: Subject: SSH GSS-API Authentication Method Date: Fri, 17 Nov 2000 07:16:35 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit An individual draft for SSH GSS-API Authentication Method has been submitted. The draft is available from: http://www.ietf.org/internet-drafts/draft-galb-secsh-gssapi-00.txt Abstract SECSH is a protocol for secure remote login and other secure network services over an insecure network. GSSAPI is a general-purpose user authentication method based on RFC 2743. This document describes a method for encoding GSSAPI onto the model described in the SECSH authentication protocol framework [SSH-AUTH]. --- We are very interested in receiving feedback on this draft. If time permits and there is sufficient interest, we hope there will be an opportunity to discuss this draft at the upcoming meeting in San Diego. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Nov 17 20:58:21 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16528 for ; Fri, 17 Nov 2000 20:58:21 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA06301 for ietf-ssh-outgoing; Sat, 18 Nov 2000 02:28:36 +0200 Received: from www.arion.ch (www.arion.ch [193.189.196.58]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id CAA06291 for ; Sat, 18 Nov 2000 02:28:33 +0200 Message-ID: <001301c050f4$b62e3de0$382043c2@user> From: "OW" To: ietf-ssh@clinet.fi Subject: =?koi8-r?B?7sHExcDT2CwgzdkgzsUgz9vJwszJ09gsIM7B0NLB18nXINzUzyDQyQ==?= =?koi8-r?B?09jNzyDJzcXOzs8g98HNIQ==?= Date: Sat, 18 Nov 2000 03:15:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to base64 by mail.clinet.fi id CAA06301 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA16528 åÓÌÉ ÷ÁÓ îå ÉÎÔÅÒÅÓÕÅÔ ÚÄÏÒÏ×ÁÑ, ÓÞÁÓÔÌÉ×ÁÑ ÖÉÚÎØ × ÜËÏÌÏÇÉÞÅÓËÉ ÞÉÓÔÏÍ ÍÅÓÔÅ, ÅÓÌÉ ÷ÁÓ îå ÒÁÄÕÅÔ ÏÂÝÅÎÉÅ Ó ÐÒÉÒÏÄÏÊ É Ô×ÏÒÅÎÉÑÍÉ ÞÅÌÏ×ÅÞÅÓËÏÇÏ ÄÕÈÁ, ÅÓÌÉ ÷ÁÍ ÎÅ ÉÎÔÅÒÅÓÎÙ ÚÁÇÁÄËÉ ÐÒÏÛÌÏÇÏ É ÂÕÄÕÝÅÇÏ, ÜÔÏ ÓÏÏÂÝÅÎÉÅ ÐÏÐÁÌÏ Ë ÷ÁÍ ÐÏ ÏÛÉÂËÅ. åÓÌÉ × éÎÔÅÒÎÅÔÅ ÷ÁÓ ÉÎÔÅÒÅÓÕÅÔ ÔÏÌØËÏ "ÓÅËÓ, ÁÎÅËÄÏÔÙ É ÈÁÌÑ×Á", ÓÏÔÒÉÔÅ ÜÔÏ ÐÉÓØÍÏ ÎÅ ÞÉÔÁÑ É, ÐÏÖÁÌÕÊÓÔÁ, ÉÚ×ÉÎÉÔÅ ÚÁ ÂÅÓÐÏËÏÊÓÔ×Ï. åÓÌÉ ÷Ù ×ÓÅ-ÔÁËÉ ÞÉÔÁÅÔÅ ÄÁÌØÛÅ, ×ÏÚÍÏÖÎÏ, ÷Ù ÚÁÈÏÔÉÔÅ ÏÚÎÁËÏÍÉÔØÓÑ Ó ÎÅÄÁ×ÎÏ ÏÔËÒÙ×ÛÉÍÓÑ ÐÏÒÔÁÌÏÍ www.ovum.ru. Ovum.ru - ÐÏÒÔÁÌ ÜËÏÌÏÇÉÞÎÏÇÏ ÏÂÒÁÚÁ ÖÉÚÎÉ, Ó×ÑÚÁÎÎÏÇÏ Ó ÄÕÈÏ×ÎÙÍ ÒÏÓÔÏÍ, ÐÏÚÎÁÎÉÅÍ ÓÅÂÑ, ÏÓÏÚÎÁÎÉÅÍ Ó×ÏÅÊ Ó×ÑÚÉ Ó ÐÒÉÒÏÄÏÊ É ÓÏ ×ÓÅÍ ÍÉÒÏÍ, Ó ÃÅÎÎÏÓÔÑÍÉ ÓÅÍØÉ É ÜËÏÌÏÇÉÉ. úÁÈÏÄÉÔÅ ÎÁ www.ovum.ru - ÍÏÖÅÔ ÂÙÔØ, ÜÔÏ ÉÍÅÎÎÏ ÔÏ, ÞÔÏ ÷ÁÍ ÎÕÖÎÏ ÓÅÊÞÁÓ. íÏÖÅÔ ÂÙÔØ - ÜÔÏ ÓÕÄØÂÁ? From owner-ietf-ssh@clinet.fi Mon Nov 20 15:05:42 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06614 for ; Mon, 20 Nov 2000 15:05:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA22653 for ietf-ssh-outgoing; Mon, 20 Nov 2000 19:45:37 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA22650 for ; Mon, 20 Nov 2000 19:45:35 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 057C02407DC9; Mon, 20 Nov 2000 18:45:35 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA09014; Mon, 20 Nov 2000 18:45:34 +0100 (MET) To: sommerfeld@east.sun.com Cc: Sami Lehtinen , ietf-ssh@clinet.fi Subject: Re: New drafts (TODO) References: <200011170029.eAH0TJa226052@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 20 Nov 2000 18:45:34 +0100 In-Reply-To: Bill Sommerfeld's message of "Thu, 16 Nov 2000 19:29:18 -0500" Message-ID: Lines: 78 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Bill Sommerfeld writes: > Ok, I found the context: > > Date: Mon, 24 Aug 1998 09:28:38 +0000 > From: Sigurdur Asgeirsson > > 3. Sections 4 and 6 of the Authentication Protocol document both contain > the following paragraph: > -- > Signature is a signature with the private host key of the following > data, in this order: > o session identifier, and > o packet payload without the signature. > -- > Is the signature performed over the raw data of the session identifier > and the packet payload or are the two perhaps supposed to be converted > into strings (length prepended) before signing, like in section 6 of the > Transport Layer document (Diffie-Hellman Key Exchange)? ... > This could be expressed a bit less ambiguously as something like: > > Signature is a signature with the ... key over the following message: > > string session identifier > 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 I believe this is the right encoding. However, it would be nice to also let the spec spell out that it *is* just the session id (as a string) prepended to the packet payload (without signature). > > DH parameter selection clarification > > - [chair couldn't find context; will take to list] > > The context for this issue appears to be: > > Date: Thu, 25 Feb 1999 09:28:01 +0000 > From: Sigurdur Asgeirsson > > 2. Section 5.2, "Output from Key Exchange" contains the following > text: > > "The key exchange produces two values: a shared secret K, and an > exchange hash H." > > Section 6, "Diffie-Hellman Key Exchange" then goes to great lengths to > specify excactly how the exchange hash "H" is computed, but fails to > specify the format of "K", which is used in key derivation. > I suggest that section 6 specify that the binary format of K, the > shared secret, be mpint (as in the ssh reference implementation). For some key exchange methods (e.g. most DH variants), K is naturally an integer, and it makes sense to encode it as an integer. However, for other methods (e.g. methods that obtain K by hashing some data), it is more natural to think about K as a string. So I think it is best to leave the specification of the format of K to the definition of each keyexchange method. As the only difference between the string and the mpint encoding is whether or not leading zero octets are stripped (or sometimes added), all that means in practice is that some keyexchange methods will provide a K that is a fix length string (e.g. a 20 octet sha1 hash value), while other methods will provide a variable length octet string that is canonicalized accordning to the rules for encoding ssh mpints. I agree that the definition of diffie-hellman keyexchange should say that K is an mpint. /Niels From owner-ietf-ssh@clinet.fi Mon Nov 20 17:33:55 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01303 for ; Mon, 20 Nov 2000 17:33:54 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA04779 for ietf-ssh-outgoing; Mon, 20 Nov 2000 22:43:06 +0200 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA04775 for ; Mon, 20 Nov 2000 22:43:05 +0200 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id WAA10686 for ; Mon, 20 Nov 2000 22:43:05 +0200 (EET) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id WAA00390 for ietf-ssh@clinet.fi; Mon, 20 Nov 2000 22:43:05 +0200 (EET) Received: by NOTVRA91.VTL.VIDEOTRON.COM(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256989.0074E0C9 ; Tue, 31 Oct 2000 16:16:37 -0500 X-Lotus-FromDomain: VRA From: =?iso-8859-1?Q?=22Andr=E9_Champagne=22?= To: ietf-ssh@clinet.fi Message-ID: <85256989.0074DFF0.00@NOTVRA91.VTL.VIDEOTRON.COM> Date: Tue, 31 Oct 2000 16:16:33 -0500 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ssh@clinet.fi Precedence: bulk unsubscribe From owner-ietf-ssh@clinet.fi Tue Nov 21 01:06:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12333 for ; Tue, 21 Nov 2000 01:06:06 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA02130 for ietf-ssh-outgoing; Tue, 21 Nov 2000 06:12:19 +0200 Received: from syrinx.oankali.net (syrinx.oankali.net [206.243.169.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA02122 for ; Tue, 21 Nov 2000 06:12:18 +0200 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id XAA19288; Mon, 20 Nov 2000 23:12:13 -0500 Date: Mon, 20 Nov 2000 23:12:13 -0500 (EST) From: "Richard E. Silverman" X-Sender: res@syrinx.oankali.net Reply-To: "Richard E. Silverman" To: SECSH Discussion List cc: "Jeff P. Van Dyke" , Joseph Galbraith Subject: Re: Secure Shell Public Key Channel In-Reply-To: <003401c050a1$1cb785c0$0201a8c0@vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Jeff and Joseph, I have read the public-key channel draft you posted, and have a few comments. 1) The proposal strikes me as a good idea. I wonder if it shouldn't be generalized, though. You're introducing an abstraction allowing clients to control authentication and authorization (AA) properties for the remote account. SSH is extensible, and already supports a number of AA mechanisms besides public-key. Each one has a similar problem: the authorization data is represented in some ad-hoc way that may change from one server OS or sshd implementation to another (e.g. a Kerberos-5 principal being listed in ~/.k5login). We could instead have an "AA channel", with requests parameterized by the authentication type we want to manipulate -- each authentication type would have its own space of operations, such as the add/remove/list you propose for public keys. This then be easily extensible to other authentication methods should that prove useful, but would not significantly complicate the protocol or implementation, I think. 2) The Secure Shell Public Key Channel has been designed to run on top of the SECSH transport layer [SSH-TRANS] and user authentication protocols [SSH-AUTH]... I think the wording here should be changed. There is a similar comment in the SSH-CONN draft, and it is confusing. Neither SSH-CONN nor your proposed protocol runs "on top of" SSH-AUTH -- they both run directly on top of SSH-TRANS. Rather, there is an expectation that before allowing a client to request either of these services, the server will have authenticated the client. This may mean that they will run *after* a successful run of the SSH-AUTH protocol -- but that is sequencing, not protocol layering. Furthermore, it is not required. A special-purpose SSH server might allow anyone to engage in SSH-CONN immediately after setting up an SSH-TRANS connection, providing some restricted, anonymous service to anyone who knocks. Or, an implementation might authenticate the client via some other means outside the SSH protocol, and then proceed directly with SSH-CONN. I think allowing for these scenarios is part of the point of defining SSH-AUTH separately in the first place. I suggest something like this: The Secure Shell Public Key Channel has been designed to run on top of the SECSH transport layer [SSH-TRANS]. It is expected that the server will require client authentication before allowing the client to use the public-key channel, and that this will normally happen via a preceding use of the SECSH user authentication protocol [SSH-AUTH] on the same SSH-TRANS connection. 3) I think the feature of adding a forced command for a key should also be generalized. Existing SSH servers have many authorization options that users can associate with the public keys for an account -- e.g. the "from", "no-pty", "command", etc. options in the authorized_keys file. A forced command is just one of these. Instead of a special-purpose "publickey-command" request, how about "set attribute" instead, taking these arguments: authentication-type authentication-token attribute-name attribute-value A publickey-command request would then look like this: set-attribute("publickey",,"command","/bin/ls") But now the same framework could equally well support something like this: set-attribute("kerberos-5","res@REALM","from","10.1.2.3") We would then need requests to list the attributes supported by the server, delete attributes, and list attribute/value pairs currently associated with a given (method,token) pair. -- Richard Silverman slade@shore.net From owner-ietf-ssh@clinet.fi Tue Nov 21 07:15:52 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13368 for ; Tue, 21 Nov 2000 07:15:51 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA04846 for ietf-ssh-outgoing; Tue, 21 Nov 2000 12:20:14 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA04842 for ; Tue, 21 Nov 2000 12:20:13 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 70F3A3BE08; Tue, 21 Nov 2000 11:20:13 +0100 (MET) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id 301D231772; Tue, 21 Nov 2000 11:20:06 +0100 (MET) Date: Tue, 21 Nov 2000 11:20:03 +0100 (MET) From: Martin Forssen Subject: Re: Secure Shell Public Key Channel To: slade@shore.net Cc: ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001121102006.301D231772@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk > The Secure Shell Public Key Channel has been designed to run on > top of the SECSH transport layer [SSH-TRANS] and user authentication > protocols [SSH-AUTH]... Shouldn't this be defined as a subsystem instead of as a new channel type? A new channel type sounds a bit too low level for me and a subsystem would make it much easier to write clean implementations. /MaF From owner-ietf-ssh@clinet.fi Tue Nov 21 09:36:27 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09828 for ; Tue, 21 Nov 2000 09:36:08 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA06833 for ietf-ssh-outgoing; Tue, 21 Nov 2000 14:32:11 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA06808 for ; Tue, 21 Nov 2000 14:32:06 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7295324027EC; Tue, 21 Nov 2000 13:32:04 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA17902; Tue, 21 Nov 2000 13:32:04 +0100 (MET) To: Martin Forssen Cc: slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel References: <20001121102006.301D231772@pelee.firedoor.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 21 Nov 2000 13:32:03 +0100 In-Reply-To: Martin Forssen's message of "Tue, 21 Nov 2000 11:20:03 +0100 (MET)" Message-ID: Lines: 26 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Martin Forssen writes: > Shouldn't this be defined as a subsystem instead of as a new channel > type? A new channel type sounds a bit too low level for me and a > subsystem would make it much easier to write clean implementations. The choice of making a particular feature a subsystem or a channel type is a trade-off. A subsystem may be cleaner (unless there's bulk data transfer involved, in which case one may have to reimplement the flow-controlled channel mechanism is), but I believe new channel types are more flexible from a user perspective. It's nice to be able use a single ssh connection for all operations. For instance, look at file transfer. With new channel types for up- and download of files, it would be possible to write an ssh client where you type some command character, get into file transfer mode, start a few transfers in the background, and then return to your interactive shell or whatever the connection was used for earlier. You can't do that as conveniently with a subsystem like sftp; in particular not if you're using some userauth mechanism that requires you to type some password or passphrase for each new connection. Does anybody have any guidelines for the choice between channels and subsystems? /Niels From owner-ietf-ssh@clinet.fi Tue Nov 21 09:50:51 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12372 for ; Tue, 21 Nov 2000 09:50:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA14970 for ietf-ssh-outgoing; Tue, 21 Nov 2000 15:04:35 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA14937 for ; Tue, 21 Nov 2000 15:04:26 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id 04D2E3BD46; Tue, 21 Nov 2000 14:04:25 +0100 (MET) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id 4476231772; Tue, 21 Nov 2000 14:04:17 +0100 (MET) Date: Tue, 21 Nov 2000 14:04:15 +0100 (MET) From: Martin Forssen Subject: Re: Secure Shell Public Key Channel To: nisse@lysator.liu.se Cc: slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Message-Id: <20001121130417.4476231772@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id PAA14970 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA12372 On 21 Nov, Niels Möller wrote: > Martin Forssen writes: >> Shouldn't this be defined as a subsystem instead of as a new channel >> type? A new channel type sounds a bit too low level for me and a >> subsystem would make it much easier to write clean implementations. > > The choice of making a particular feature a subsystem or a channel > type is a trade-off. A subsystem may be cleaner (unless there's bulk > data transfer involved, in which case one may have to reimplement the > flow-controlled channel mechanism is), but I believe new channel types > are more flexible from a user perspective. It's nice to be able use a > single ssh connection for all operations. This is not a valid argument. Subsystems are defined as a subtype of the session channel type and nothing prevents you from using as many simultaneous sessions as you want in a single connection. Any eventual limitations lies entirely in the client. > For instance, look at file transfer. With new channel types for up- > and download of files, it would be possible to write an ssh client > where you type some command character, get into file transfer mode, > start a few transfers in the background, and then return to your > interactive shell or whatever the connection was used for earlier. You > can't do that as conveniently with a subsystem like sftp; in > particular not if you're using some userauth mechanism that requires > you to type some password or passphrase for each new connection. But you can start multiple session channels within one ssh connection. From the connection draft section 4. " 4. Interactive Sessions A session is a remote execution of a program. The program may be a shell, an application, a system command, or some built-in subsystem. It may or may not have a tty, and may or may not involve X11 forwarding. Multiple sessions can be active simultaneously." Specially note the last sentence. The Appgate client can for example open a number of separate terminal windows (i.e. shell command channels) simultaneously all sharing one single ssh connection. The F-secure Mac client can also have multiple shell windows active simultaneously. /MaF From owner-ietf-ssh@clinet.fi Tue Nov 21 10:09:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16720 for ; Tue, 21 Nov 2000 10:09:52 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA19050 for ietf-ssh-outgoing; Tue, 21 Nov 2000 15:20:52 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA19040 for ; Tue, 21 Nov 2000 15:20:51 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 95F19240A00B; Tue, 21 Nov 2000 14:20:49 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA29276; Tue, 21 Nov 2000 14:20:49 +0100 (MET) To: Martin Forssen Cc: slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel References: <20001121130417.4476231772@pelee.firedoor.se> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 21 Nov 2000 14:20:49 +0100 In-Reply-To: Martin Forssen's message of "Tue, 21 Nov 2000 14:04:15 +0100 (MET)" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Martin Forssen writes: > This is not a valid argument. Subsystems are defined as a subtype of the > session channel type and nothing prevents you from using as many > simultaneous sessions as you want in a single connection. Any eventual > limitations lies entirely in the client. You're absolutely right. I was confusing "subsystems" with "services". Sorry about that. /Niels From owner-ietf-ssh@clinet.fi Tue Nov 21 11:59:29 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11624 for ; Tue, 21 Nov 2000 11:59:28 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA09932 for ietf-ssh-outgoing; Tue, 21 Nov 2000 17:08:02 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA09928 for ; Tue, 21 Nov 2000 17:08:00 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 5CE0D2407DEE; Tue, 21 Nov 2000 16:07:59 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA24385; Tue, 21 Nov 2000 16:07:59 +0100 (MET) To: Mats Andersson Cc: Martin Forssen , slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 21 Nov 2000 16:07:58 +0100 In-Reply-To: Mats Andersson's message of "Tue, 21 Nov 2000 15:56:33 +0100 (MET)" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Mats Andersson writes: > This is only if the client can't handle multiple sessions, remember it's > still within the same ssh connection, i.e. it's not a problem with the > protocol (if you don't mean to define session == connection?). I was confused (as MaF already pointed out). So please forget that. > On another note, there is also of course the possibility to instead have a > special authentication type which handles the initial deployment and other > handling of authorized keys (not sure why this would be better or worse > though :-). As the transport level and the key exchange are the most security critical parts of the protocol, I think it is better not to add any feature there unless it is really necessary. I.e. mess with the transport and keyechange *only* if the feature can't be implemented in any other way. /Niels From owner-ietf-ssh@clinet.fi Tue Nov 21 12:01:14 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12001 for ; Tue, 21 Nov 2000 12:01:14 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA07005 for ietf-ssh-outgoing; Tue, 21 Nov 2000 16:55:03 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA07002 for ; Tue, 21 Nov 2000 16:55:02 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id 2FC421FF01; Tue, 21 Nov 2000 15:56:33 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 2886C1F101; Tue, 21 Nov 2000 15:56:33 +0100 (MET) Date: Tue, 21 Nov 2000 15:56:33 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Martin Forssen , slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id QAA07003 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id QAA07005 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12001 On 21 Nov 2000, Niels Möller wrote: > > subsystem would make it much easier to write clean implementations. > > flow-controlled channel mechanism is), but I believe new channel types > are more flexible from a user perspective. It's nice to be able use a > single ssh connection for all operations. This is only if the client can't handle multiple sessions, remember it's still within the same ssh connection, i.e. it's not a problem with the protocol (if you don't mean to define session == connection?). > start a few transfers in the background, and then return to your > interactive shell or whatever the connection was used for earlier. You > can't do that as conveniently with a subsystem like sftp; in > particular not if you're using some userauth mechanism that requires > you to type some password or passphrase for each new connection. see above On another note, there is also of course the possibility to instead have a special authentication type which handles the initial deployment and other handling of authorized keys (not sure why this would be better or worse though :-). Cheers, /Mats From owner-ietf-ssh@clinet.fi Tue Nov 21 12:29:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16651 for ; Tue, 21 Nov 2000 12:29:42 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA13863 for ietf-ssh-outgoing; Tue, 21 Nov 2000 17:37:00 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA13860 for ; Tue, 21 Nov 2000 17:36:59 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id D84471FF01; Tue, 21 Nov 2000 16:38:30 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id D10A41F101; Tue, 21 Nov 2000 16:38:30 +0100 (MET) Date: Tue, 21 Nov 2000 16:38:30 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: Martin Forssen , slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id RAA13861 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id RAA13863 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16651 On 21 Nov 2000, Niels Möller wrote: > I was confused (as MaF already pointed out). So please forget that. Sorry, I wrote it before seeing his post. > > special authentication type which handles the initial deployment and > other > handling of authorized keys (not sure why this would be better > or worse > though :-). > > As the transport level and the key exchange are the most security > critical parts of the protocol, I think it is better not to add any > feature there unless it is really necessary. I.e. mess with the > transport and keyechange *only* if the feature can't be implemented in > any other way. As I wrote, define a new authentication method. I don't see how this would be bad? (or have anything to do with transport/KEX?) As I see it, this is really a form of user authentication (e.g. first authenticated with an OTP and then have the ability to deploy a key, and/or edit/view authorized keys if necessary). IMHO it is thus more logical to have this implemented as an authentication method. Or as MAF points out subsystem for that matter since the edit/view functionality of course seems more like an application feature rather than an authentication method :-). Cheers, /Mats From owner-ietf-ssh@clinet.fi Tue Nov 21 13:38:47 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02176 for ; Tue, 21 Nov 2000 13:38:46 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA22898 for ietf-ssh-outgoing; Tue, 21 Nov 2000 18:53:35 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA22890 for ; Tue, 21 Nov 2000 18:53:35 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id SAA17803; Tue, 21 Nov 2000 18:54:09 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.43185.230705.650810@asgard.tky.hut.fi> Date: Tue, 21 Nov 2000 18:54:09 +0200 (EET) To: Martin Forssen Cc: nisse@lysator.liu.se, slade@shore.net, ietf-ssh@clinet.fi, jpv@vandyke.com, galb@vandyke.com Subject: Re: Secure Shell Public Key Channel In-Reply-To: <20001121130417.4476231772@pelee.firedoor.se> References: <20001121130417.4476231772@pelee.firedoor.se> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Martin Forssen, on November 21. 2000, wrote: : The Appgate client can for example open a number of separate terminal : windows (i.e. shell command channels) simultaneously all sharing one : single ssh connection. The F-secure Mac client can also have multiple : shell windows active simultaneously. ... and our Windows client does this too. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Tue Nov 21 16:26:23 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04800 for ; Tue, 21 Nov 2000 16:26:23 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id TAA19649 for ietf-ssh-outgoing; Tue, 21 Nov 2000 19:33:09 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id TAA19416 for ; Tue, 21 Nov 2000 19:32:58 +0200 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 240; Tue, 21 Nov 2000 10:35:57 -0700 Message-ID: <004401c053e0$fdf75b40$1000a8c0@viper> From: "Jeff P. Van Dyke" To: "Martin Forssen" , Cc: , References: <20001121102006.301D231772@pelee.firedoor.se> Subject: Re: Secure Shell Public Key Channel Date: Tue, 21 Nov 2000 10:31:45 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > > The Secure Shell Public Key Channel has been designed to run on > > top of the SECSH transport layer [SSH-TRANS] and user authentication > > protocols [SSH-AUTH]... > > Shouldn't this be defined as a subsystem instead of as a new channel > type? A new channel type sounds a bit too low level for me and a > subsystem would make it much easier to write clean implementations. Can you elaborate on this? Why do you think it is too low level? Why do you think making it a subsystem would make it much easier to write a clean implementation? In our implementation, making it a channel or subsystem doesn't make much difference. We've been considering a number of extensions to SECSH. And for most of these, we've been leaning towards using channels because of the flow control. I'd be very interested in hearing from others about the pros and cons of extending SECSH by adding new channels versus extending SECSH by adding new subsystems. The only subsystem that I know of that is widely available is sftp, and with our implementation we could have just as easily implemented a file transfer protocol as a channel. With the public key channel as specified, I don't believe flow control would be a problem. Therefore, if the consensus is that it should be a subsystem, we would be willing to rewrite the draft to reflect this. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Tue Nov 21 18:34:10 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25076 for ; Tue, 21 Nov 2000 18:34:09 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA14386 for ietf-ssh-outgoing; Tue, 21 Nov 2000 23:41:06 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA14380 for ; Tue, 21 Nov 2000 23:41:05 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 7F7B5240A008; Tue, 21 Nov 2000 22:41:04 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA01615; Tue, 21 Nov 2000 22:41:04 +0100 (MET) To: "Jeff P. Van Dyke" Cc: "Martin Forssen" , , , Subject: Re: Secure Shell Public Key Channel References: <20001121102006.301D231772@pelee.firedoor.se> <004401c053e0$fdf75b40$1000a8c0@viper> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 21 Nov 2000 22:41:03 +0100 In-Reply-To: "Jeff P. Van Dyke"'s message of "Tue, 21 Nov 2000 10:31:45 -0700" Message-ID: Lines: 80 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Jeff P. Van Dyke" writes: > > > The Secure Shell Public Key Channel has been designed to run on > > > top of the SECSH transport layer [SSH-TRANS] and user authentication > > > protocols [SSH-AUTH]... > > > > Shouldn't this be defined as a subsystem instead of as a new channel > > type? A new channel type sounds a bit too low level for me and a > > subsystem would make it much easier to write clean implementations. > > Can you elaborate on this? Why do you think it is too low level? > > Why do you think making it a subsystem would make it much easier > to write a clean implementation? After a quick look at the draft, I think I agree with MaF. It seems a little against the spirit of the channel mechanism to attach meaning to the boundaries between successive data packets, and it seems to be a little at odds with its flow control. For instance, I would expect that for _any_ channel, it would be legal for an implementation to give the sending party a window size of just 1 octet, receive a SSH_MSG_CHANNEL_DATA packet with 1 octet of data, send a SSH_MSG_WINDOW_ADJUST message increasing the window size with 1 octet, and so on. That wouldn't work with the proposed protocol. Hmm. On second thought, for this problem it doesn't really matter if it is a subsystem or not. The problem is the use of SSH_MSG_CHANNEL_DATA and the atomicity requirements. An alternative might be to package the requests as SSH_MSG_CHANNEL_REQUEST. One possible exception is the list request, where it would make sense to use some kind of flow control, but I still think it would be inappropriate to specify where the SSH_MSG_CHANNEL_DATA boundaries should fall in the data stream. > In our implementation, making it a channel or subsystem doesn't > make much difference. How do you deal with the case that you have a transmission window-size that is non-zero, but smaller than the next data packet you want to send? > We've been considering a number of extensions to SECSH. And for > most of these, we've been leaning towards using channels because > of the flow control. Are you saying that subsystems doesn't use flow-control? The spec isn't very clear on what a "subsystem" is allowed to do, but from my reading it appears that "subsystem" is just like "exec", with a different interpretation of the command-line/subsystem name. It would be nice if a subsystem could somehow grab few more message types, something like like byte SSH_MSG_CHANNEL_SUBSYSTEM_REQUEST uint32 recipient channel string subtype (meaning depending on the subsystem) ... subsystem and subtype dependant data byte SSH_MSG_CHANNEL_SUBSYSTEM_REPLY uint32 recipient channel string subtype (meaning depending on the subsystem) ... subsystem and subtype dependent data (The primary difference from SSH_MSG_CHANNEL_REQUEST is that the subsystem can stuff more data into the reply). > The only subsystem that I know of that is widely available is > sftp, and with our implementation we could have just as easily > implemented a file transfer protocol as a channel. Are there any official specs for sftp yet? Regards, /Niels PS. Sorry if I'm getting a little incoherent here. I haven't read the specs for any subsystem, even less implemented one. So I don't really know how they are expected to work. From owner-ietf-ssh@clinet.fi Tue Nov 21 21:13:40 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16322 for ; Tue, 21 Nov 2000 21:13:39 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id CAA26003 for ietf-ssh-outgoing; Wed, 22 Nov 2000 02:34:32 +0200 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id CAA26000 for ; Wed, 22 Nov 2000 02:34:32 +0200 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id CAA18067; Wed, 22 Nov 2000 02:35:11 +0200 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-ID: <14875.5310.979106.617561@asgard.tky.hut.fi> Date: Wed, 22 Nov 2000 02:35:10 +0200 (EET) To: nisse@lysator.liu.se (Niels Möller) Cc: Subject: Re: Secure Shell Public Key Channel In-Reply-To: References: <20001121102006.301D231772@pelee.firedoor.se> <004401c053e0$fdf75b40$1000a8c0@viper> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id CAA26003 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA16322 Niels Möller, on November 21. 2000, wrote: : Are there any official specs for sftp yet? No, and will not be before or during the San Diego IETF (we (Tatu and I) missed the deadline for the submission of new drafts). I will, however, be putting it out by other means for the joy of the working group, in the near future (unless somebody objects to this). I submitted the core drafts late yesterday evening EET (that's about 5 hours ago), and judging from the automatic reply I received, it may take a while for them to be published. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Wed Nov 22 05:43:50 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17341 for ; Wed, 22 Nov 2000 05:43:50 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id KAA14897 for ietf-ssh-outgoing; Wed, 22 Nov 2000 10:51:20 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id KAA14891 for ; Wed, 22 Nov 2000 10:51:19 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id 07C2A1FF01; Wed, 22 Nov 2000 09:52:51 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 0127D1F101 for ; Wed, 22 Nov 2000 09:52:50 +0100 (MET) Date: Wed, 22 Nov 2000 09:52:50 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: ietf-ssh@clinet.fi Subject: X11 channels In-Reply-To: <14875.5310.979106.617561@asgard.tky.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Question: If I have two different sessions where I would like to forward X11 channels to two different local displays, how would I do that given the protocol doesn't give any hints on which session a certain x11 SSH_MSG_CHANNEL_OPEN belongs to. The only way I can think of is to delay the actual connect to the local display until the bogus cookie is received and can be mapped to a specific session (and hence display). This is kind of pathological (and I guess that nobody does this) but I'm just curious. Cheers, /Mats From owner-ietf-ssh@clinet.fi Wed Nov 22 07:47:27 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05084 for ; Wed, 22 Nov 2000 07:47:26 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA13126 for ietf-ssh-outgoing; Wed, 22 Nov 2000 12:35:14 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA13121 for ; Wed, 22 Nov 2000 12:35:13 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id EFA6E3BD46; Wed, 22 Nov 2000 11:35:12 +0100 (MET) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id 7F31B31773; Wed, 22 Nov 2000 11:35:08 +0100 (MET) Date: Wed, 22 Nov 2000 11:35:05 +0100 (MET) From: Martin Forssen Subject: Re: Secure Shell Public Key Channel To: jpv@vandyke.com Cc: ietf-ssh@clinet.fi In-Reply-To: <004401c053e0$fdf75b40$1000a8c0@viper> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001122103508.7F31B31773@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 21 Nov, Jeff P. Van Dyke wrote: >> > The Secure Shell Public Key Channel has been designed to run on >> > top of the SECSH transport layer [SSH-TRANS] and user authentication >> > protocols [SSH-AUTH]... >> >> Shouldn't this be defined as a subsystem instead of as a new channel >> type? A new channel type sounds a bit too low level for me and a >> subsystem would make it much easier to write clean implementations. > > Can you elaborate on this? Why do you think it is too low level? > > Why do you think making it a subsystem would make it much easier > to write a clean implementation? Both the ssh2-servers which I have examined more closely implements subsytems as external processes which means you can add a new subsystemwithout any modifications to the ssh server code at all. In contrast new channel types needs numerous modifications to the server-code. My feelings when reading the draft (and Tatu kind of confirmed this in his post) is that subsystems are meant to be higher upp in the protocol stack and handle application-level stuff. ANd I see publickey management as definitely an application-level issue. > We've been considering a number of extensions to SECSH. And for > most of these, we've been leaning towards using channels because > of the flow control. I'd be very interested in hearing from > others about the pros and cons of extending SECSH by adding > new channels versus extending SECSH by adding new subsystems. As others have already stated, flow-control is not an issue since it applies to subsystems as well (they are after all built on top of channels). /MaF From owner-ietf-ssh@clinet.fi Wed Nov 22 11:00:33 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16604 for ; Wed, 22 Nov 2000 11:00:32 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA32352 for ietf-ssh-outgoing; Wed, 22 Nov 2000 16:07:57 +0200 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA32332 for ; Wed, 22 Nov 2000 16:07:54 +0200 Received: from viper2 ([192.168.0.38]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 608; Wed, 22 Nov 2000 07:10:56 -0700 Message-ID: <002f01c0548e$16717f40$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: "Martin Forssen" Cc: References: <20001122103508.7F31B31773@pelee.firedoor.se> Subject: Re: Secure Shell Public Key Channel Date: Wed, 22 Nov 2000 07:11:08 -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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit On November 22, Martin Forssen wrote: > > On 21 Nov, Jeff P. Van Dyke wrote: > > We've been considering a number of extensions to SECSH. And for > > most of these, we've been leaning towards using channels because > > of the flow control. I'd be very interested in hearing from > > others about the pros and cons of extending SECSH by adding > > new channels versus extending SECSH by adding new subsystems. > > As others have already stated, flow-control is not an issue since it > applies to subsystems as well (they are after all built on top of > channels). A channel can control the flow by sending (or not sending) window size adjustments. From draft-ietf-secsh-connect-07.txt: 3.2. Data Transfer The window size specifies how many bytes the other party can send before it must wait for the window to be adjusted. Both parties use the following message to adjust the window. byte SSH_MSG_CHANNEL_WINDOW_ADJUST uint32 recipient channel uint32 bytes to add How does a subsystem do this? As I understand subsystems, the session channel has flow control, but there is wall between the session channel and the subsystem. Therefore, the subsystem protocol must re-implement a flow control mechanism. Imagine a subsystem that uses one thread to read and one thread to write to the SSH2 server via a pipe (assuming the subsystem is an external process). In this case, the reader and the writer may need to coordinate to make sure the reader doesn't get too far ahead of the writer. Now consider a channel that uses one thread to read and one thread to write. Since the writer would be responsible for sending window adjustments, the reader can't get too far ahead of the writer. In a multi-threaded implementation, this simplifies things. I think in many cases, the flow control mechanism required in the subsystem would be "easy" to implement. My point is that if you use a channel, you don't have to implement it. With the public key channel as specified, I don't believe flow control would be a problem. And therefore, there is no real obstacle to making it a subsystem. > Both the ssh2-servers which I have examined more closely implements > subsytems as external processes which means you can add a new > subsystem without any modifications to the ssh server code at all. In > contrast new channel types needs numerous modifications to the > server-code. Since we'd like to see servers implement the public key channel/subsystem, I think your observation about existing implementations may be a compelling reason to rewrite the draft as a subsystem. By doing so, it wouldn't even be necessary for the server vendor to implement it - a 3rd party could implement the public key subsystem. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Wed Nov 22 11:09:03 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17808 for ; Wed, 22 Nov 2000 11:09:03 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA28567 for ietf-ssh-outgoing; Wed, 22 Nov 2000 15:51:46 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA28550 for ; Wed, 22 Nov 2000 15:51:41 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 818A02401F6C; Wed, 22 Nov 2000 14:51:40 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA03407; Wed, 22 Nov 2000 14:51:39 +0100 (MET) To: Mats Andersson Cc: ietf-ssh@clinet.fi Subject: Re: X11 channels References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 22 Nov 2000 14:51:39 +0100 In-Reply-To: Mats Andersson's message of "Wed, 22 Nov 2000 09:52:50 +0100 (MET)" Message-ID: Lines: 55 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Mats Andersson writes: > If I have two different sessions where I would like to forward X11 > channels to two different local displays, how would I do that given the > protocol doesn't give any hints on which session a certain x11 > SSH_MSG_CHANNEL_OPEN belongs to. I don't think that is pathological at all. > The only way I can think of is to delay the actual connect to the local > display until the bogus cookie is received and can be mapped to a specific > session (and hence display). There's also the X display number, which seems more appropriate for identifying different x displays. It is sent with the SSH_MSG_CHANNEL_REQUEST thet requests forwarding. Both the display number and the cookie will be sent in the first X request as each X channel is opened, if I recall the X protocol correctly. The client will typically replace the cookie before sending the initial X request to the real X-server. It could look at the display number as well, even if it seems ugly to delay the open (it's nicer to open the connection immediately on SSH_MSG_CHANNEL_OPEN, in order to give the peer a correct SSH_MSG_CHANNEL_OPEN_CONFIRMATION or SSH_MSG_CHANNEL_OPEN_FAILURE. A simple change would be to include the display number in the SSH_MSG_CHANNEL_OPEN message, like byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender channel uint32 initial window size uint32 maximum packet size string originator address (e.g. "192.168.7.38") uint32 originator port uint32 display number Is this a reasonable change? Making implementations backwards compatible should be straight-forward (look at the length of the packet; if the display number is missing, fail unless exactly one display number have been sent earlier with "x11-req"). As an alternative to sending the display number (which won't necessarily match the display number used by any real x server anyway), one could send the channel number of the corresponding session. Another question: Say the server sets up an AF_UNIX socket for communicationg with its proxying X server. What should the fields "originator address" and "originator port" contain? I believe using an AF_UNIX socket with paranoid permissions is preferable to using an ordinary tcp socket and MIT_MAGIC_COOKIE-style authentication. /Niels From owner-ietf-ssh@clinet.fi Wed Nov 22 12:16:31 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00286 for ; Wed, 22 Nov 2000 12:16:30 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA12022 for ietf-ssh-outgoing; Wed, 22 Nov 2000 17:09:48 +0200 Received: from nic.appgate.com (nic.appgate.com [193.12.107.226]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA12017 for ; Wed, 22 Nov 2000 17:09:48 +0200 Received: from pelee.firedoor.se (pelee.firedoor.se [172.23.2.10]) by nic.appgate.com (Postfix) with ESMTP id EA3973BE08; Wed, 22 Nov 2000 16:09:47 +0100 (MET) Received: from appgate.com (maunaloa.firedoor.se [172.23.2.56]) by pelee.firedoor.se (Postfix) with ESMTP id B076831772; Wed, 22 Nov 2000 16:09:43 +0100 (MET) Date: Wed, 22 Nov 2000 16:09:41 +0100 (MET) From: Martin Forssen Subject: Re: Secure Shell Public Key Channel To: jpv@vandyke.com Cc: ietf-ssh@clinet.fi In-Reply-To: <002f01c0548e$16717f40$0201a8c0@vandyke.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20001122150943.B076831772@pelee.firedoor.se> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 22 Nov, Jeff P. Van Dyke wrote: > As I understand subsystems, the session channel has flow control, > but there is wall between the session channel and the subsystem. > Therefore, the subsystem protocol must re-implement a flow > control mechanism. The idea is that the subsystem should not do any flow control by itself. That is a transport issue and therefore automatically handled by the lower layers (i.e. the underlying stream channel). The subsystem will just see two pipes, one to read from and one to write from. And that is all there is to it. /MaF From owner-ietf-ssh@clinet.fi Thu Nov 23 16:50:36 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13464 for ; Thu, 23 Nov 2000 16:50:35 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id VAA24973 for ietf-ssh-outgoing; Thu, 23 Nov 2000 21:54:50 +0200 Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id VAA24966 for ; Thu, 23 Nov 2000 21:54:48 +0200 Received: from sandelman.ottawa.on.ca (localhost [127.0.0.1]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id PAA18045 for ; Thu, 23 Nov 2000 15:15:38 -0500 (EST) Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id eANBkVC00597 for ; Thu, 23 Nov 2000 06:46:31 -0500 (EST) Message-Id: <200011231146.eANBkVC00597@sandelman.ottawa.on.ca> To: ietf-ssh@clinet.fi Subject: Re: X11 channels In-reply-to: Your message of "Wed, 22 Nov 2000 09:52:50 +0100." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 Nov 2000 06:46:31 -0500 From: Michael Richardson Sender: owner-ietf-ssh@clinet.fi Precedence: bulk >>>>> "Mats" == Mats Andersson writes: Mats> This is kind of pathological (and I guess that nobody does this) but I'm Mats> just curious. I have often used Xnest so that various applications that break with certain window managers can be run with the window manager they prefer. Being able to forward a connection to my Xnest would be nice. So I don't think this is that pathological. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[ ] mcr@solidum.com www.solidum.com the little fishy gone?|PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-ietf-ssh@clinet.fi Fri Nov 24 05:54:53 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19186 for ; Fri, 24 Nov 2000 05:54:52 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA29623 for ietf-ssh-outgoing; Fri, 24 Nov 2000 11:14:07 +0200 Received: from mail.mindbright.se (IDENT:postfix@mindterm.appgate.com [193.12.107.237]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA29616 for ; Fri, 24 Nov 2000 11:14:06 +0200 Received: by mail.mindbright.se (Postfix, from userid 1001) id C6FED1FF01; Fri, 24 Nov 2000 10:15:38 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 7846C1F101; Fri, 24 Nov 2000 10:15:38 +0100 (MET) Date: Fri, 24 Nov 2000 10:15:38 +0100 (MET) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@clinet.fi Subject: Re: X11 channels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.clinet.fi id LAA29617 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by mail.clinet.fi id LAA29623 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA19186 Hi, On 22 Nov 2000, Niels Möller wrote: > There's also the X display number, which seems more appropriate for > identifying different x displays. It is sent with the > SSH_MSG_CHANNEL_REQUEST thet requests forwarding. Both the display > number and the cookie will be sent in the first X request as each X > channel is opened, if I recall the X protocol correctly. Well, the draft says it's the "screen number" actually, the X server has several displays which each one can have several screens. What it (the draft) fails to describe is exactly what the "screen number" means here. The draft also ommits describing how the returned SSH_MSG_CHANNEL_OPEN should be mapped back to a specific request which was my question/problem (which your suggestion would of course solve IFF the "screen number" in the request is defined to be the local display to connect back to, which is fine by me). This would also solve the problem when one session requests a x11 channel with "single connection" set to true, and another requests an x11 channel where it's set to false. All this is of course not very well defined how the server should handle either... However, as I said, this can of course be handled with just setting different cookies to different requests and we will know how to map them back (but will have to delay the actual local connect until we get the cookie). But I guess a small change in the protocol would be preferable here. > As an alternative to sending the display number (which won't > necessarily match the display number used by any real x server > anyway), one could send the channel number of the corresponding > session. Sounds better to me, mapping it to the channel seems cleaner to me. Suggestion for the draft: Introduce a last field in the SSH_MSG_CHANNEL_OPEN type "x11" in which the client channel number that was the origin of the request is put by the server. Define ALL the fields in the SSH_MSG_CHANNEL_REQUEST (type "x11") aswell as the fields in the SSH_MSG_CHANNEL_OPEN (type "x11") (sections 4.3.1 and 4.3.2 of the connection draft). Also define the "screen number" (or change to "display number"?) how it's used on server, and on client. Cheers, /Mats From owner-ietf-ssh@clinet.fi Fri Nov 24 11:29:01 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22551 for ; Fri, 24 Nov 2000 11:29:00 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id QAA11189 for ietf-ssh-outgoing; Fri, 24 Nov 2000 16:53:29 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id QAA11162 for ; Fri, 24 Nov 2000 16:53:21 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4367124027E5; Fri, 24 Nov 2000 15:53:10 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA01205; Fri, 24 Nov 2000 15:53:09 +0100 (MET) To: Mats Andersson Cc: ietf-ssh@clinet.fi Subject: Re: X11 channels References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 24 Nov 2000 15:53:04 +0100 In-Reply-To: Mats Andersson's message of "Fri, 24 Nov 2000 10:15:38 +0100 (MET)" Message-ID: Lines: 66 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Mats Andersson writes: > Well, the draft says it's the "screen number" actually, the X server has > several displays which each one can have several screens. What it (the > draft) fails to describe is exactly what the "screen number" means here. Hmm, you're right, we need one identifier to identify the X-server (display) to connect to, and another one for the screen number. The screen number must be sent in the "x11-req" SSH_MSG_CHANNEL_REQUEST, in order for the peer to set the final component of $DISPLAY properly, but should not otherwise matter much to the client. Remote processes should be free to use a different screen number when actually connecting to the X server (unless the client explicitly wants to forbid that), while they must not be able to connect to any other display than that being forwarded. > Introduce a last field in the SSH_MSG_CHANNEL_OPEN type "x11" in which the > client channel number that was the origin of the request is put by the > server. Define ALL the fields in the SSH_MSG_CHANNEL_REQUEST (type "x11") > aswell as the fields in the SSH_MSG_CHANNEL_OPEN (type "x11") (sections > 4.3.1 and 4.3.2 of the connection draft). Also define the "screen number" > (or change to "display number"?) how it's used on server, and on client. I think it's unnecessary to include the channel number, it's better to use a display-id that is mapped to an x-server by the client. So I'd propose the following: : byte SSH_MSG_CHANNEL_REQUEST : uint32 recipient channel : string "x11-req" : boolean want reply : boolean single connection : string x11 authentication protocol : string x11 authentication cookie : uint32 x11 screen number : uint32 display-id : : The display id is used by the originator of this message to identify : a (usually local) X display. It may use several id:s for the same X : display, in order to enforce the single-connection property when : requesting X forwarding for several concurrent sessions. and : byte SSH_MSG_CHANNEL_OPEN : string "x11" : uint32 sender channel : uint32 initial window size : uint32 maximum packet size : string originator address (e.g. "192.168.7.38") : uint32 originator port : uint32 display-id : : The display-id MUST be the same as in the corresponding "x11-req" : message. An alternative would be to use a string for the display-id (that way, a client could put its value of $(DISPLAY) there. But I think a numeric id is slightly better). The handling of the display-id field, on the client side, is similar to the handling of the address-to-bind and port-number-to-bind fields in the tcpip-forwarding messages: It is first looked up in the table of requested forwardings, and if it is found, that list provides the target for the forwarded connection. /Niels From owner-ietf-ssh@clinet.fi Mon Nov 27 08:35:14 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08797 for ; Mon, 27 Nov 2000 08:35:13 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA14324 for ietf-ssh-outgoing; Mon, 27 Nov 2000 13:09:04 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA14296 for ; Mon, 27 Nov 2000 13:08:59 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 3775F2402816; Mon, 27 Nov 2000 12:08:53 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id MAA16232; Mon, 27 Nov 2000 12:08:51 +0100 (MET) To: Tatu Ylonen Cc: Mats Andersson , ietf-ssh@clinet.fi Subject: Re: X11 channels References: <200011270830.KAA01099@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 27 Nov 2000 12:08:48 +0100 In-Reply-To: Tatu Ylonen's message of "Mon, 27 Nov 2000 10:30:32 +0200 (EET)" Message-ID: Lines: 45 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > I personally think it would be a mistake to add the display-id. It > would only add complexity, with no added value. It is just an > incompatible change. I think something more is needed (although on second thought, I'm not sure if a "display-id" provides any real benefit over providing the channel number of the associated channel. If anyone is interested, I can expand on my thinking here). One may need it even if there is only a single display. For instance if you have several sessions and want to allow only one X connect from each session (hmm, I was sure there was some "only one connection" flag in the x11-req and tcpip-forward messages, but now it seems I have dreamt that up). > If the client ever needs to perform an association similar to > display-id, it can be implemented by sending a different fake > authentication cookie for each thing represented by a display-id, > and have the client scan its table for the correct fake cookie. That seems like a kludge: I want to be able to send an accurate SSH_MSG_CHANNEL_OPEN_FAILURE for attempts to connect to a display I don't want to forward. (I don't feel strongly about this, though. I'd support the change if other people agree it is useful; otherwise I'll be able to hand out different cookies, or one-time cookies, or something like that). > Remember that you also need to connect to unix domain sockets. That reminds me of my previous question: What is the originator address and originator port supposed to contain if the X client connected via a unix domain socket? byte SSH_MSG_CHANNEL_OPEN string "x11" uint32 sender channel uint32 initial window size uint32 maximum packet size string originator address (e.g. "192.168.7.38") uint32 originator port /Niels From owner-ietf-ssh@clinet.fi Wed Nov 29 12:11:44 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15034 for ; Wed, 29 Nov 2000 12:11:41 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA24655 for ietf-ssh-outgoing; Wed, 29 Nov 2000 17:05:20 +0200 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA24643 for ; Wed, 29 Nov 2000 17:05:18 +0200 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4BEA0240821B; Wed, 29 Nov 2000 16:05:12 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA29300; Wed, 29 Nov 2000 16:05:11 +0100 (MET) To: Tatu Ylonen Cc: Mats Andersson , ietf-ssh@clinet.fi Subject: Re: X11 channels References: <200011270830.KAA01099@torni.hel.fi.ssh.com> <200011290813.KAA17106@torni.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII From: nisse@lysator.liu.se (Niels Möller) Date: 29 Nov 2000 16:05:11 +0100 In-Reply-To: Tatu Ylonen's message of "Wed, 29 Nov 2000 10:13:13 +0200 (EET)" Message-ID: Lines: 28 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tatu Ylonen writes: > If the display is not shared between sessions, then you can already > implement "one connection only" in either the server or the client. > (In server you can of course always force separate displays if you are > configured for "only one connection".) My point was that implementing it in the client would be easier and cleaner if there was some id in the x11-req message that was also included in corresponding CHANNEL_OPEN messages. But perhaps that's not very important. > I don't object to specifying some special value for this case (e.g., > address "unix-domain", port ""). Hmm. Perhaps it's better to use the empty string? As I have said before, I think one will sometimes want to send dns names rather than ip-numbers, so magic strings that happen to be valid dns names are perhaps a bad idea. > From an implementation standpoint, however, there are potential > problems associated with forwarding unix-domain sockets. Would you like to share your experiences? I haven't really looked into X forwarding yet, but in general, I believe unix-sockets with paranoid permissions are more appropriate than tcp sockets. /Niels From owner-ietf-ssh@clinet.fi Wed Nov 29 17:40:49 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10098 for ; Wed, 29 Nov 2000 17:40:48 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA24611 for ietf-ssh-outgoing; Wed, 29 Nov 2000 22:46:16 +0200 Received: from citi.umich.edu (macandros.citi.umich.edu [141.211.92.141] (may be forged)) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA24599 for ; Wed, 29 Nov 2000 22:46:15 +0200 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id C44AE207C1 for ; Wed, 29 Nov 2000 15:46:13 -0500 (EST) Subject: hashes for ssh-rsa From: Niels Provos In-Reply-To: Niels M ller, 27 Nov 2000 12:08:48 +0100 To: ietf-ssh@clinet.fi Date: Wed, 29 Nov 2000 15:46:13 -0500 Message-Id: <20001129204613.C44AE207C1@citi.umich.edu> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, I have not see a draft that includes "ssh-rsa" yet. While this part is still being written, it might be worthwhile to allow other hashes besides SHA1 for for "ssh-rsa". DSS is constrained by restricting the signed data to only 160-bit. With RSA, we don't face these constraints, and SSL actually uses a concatenation of SHA1 and MD5 for the signature. It woulde be nice if SHA1+MD5 or SHA-512 would be an option for ssh-rsa. Comments? Niels. From owner-ietf-ssh@clinet.fi Thu Nov 30 17:54:04 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07097 for ; Thu, 30 Nov 2000 17:54:04 -0500 (EST) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id XAA25534 for ietf-ssh-outgoing; Thu, 30 Nov 2000 23:11:50 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id XAA25530 for ; Thu, 30 Nov 2000 23:11:48 +0200 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10445 for ; Thu, 30 Nov 2000 13:11:46 -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,v1.7) with ESMTP id QAA09196 for ; Thu, 30 Nov 2000 16:11:46 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAULB5a104779 for ; Thu, 30 Nov 2000 16:11:06 -0500 (EST) Message-Id: <200011302111.eAULB5a104779@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@clinet.fi Subject: agenda items.. Reply-to: sommerfeld@east.sun.com Date: Thu, 30 Nov 2000 16:11:05 -0500 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk We will be meeting at the San Diego IETF on Monday in the 3:30-5:30pm timeslot. I expect that we'll spend most of the time discussing the core drafts. Folks who have something they want on the agenda should send requests to me. Thanks. (I'm also going to be doing a fast review of the recently posted core secsh drafts and will then start a working group last call on the core documents.) - Bill