From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 1 18:17:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07311 for ; Wed, 1 Aug 2001 18:17:04 -0400 (EDT) Received: (qmail 29579 invoked by uid 605); 1 Aug 2001 22:11:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29569 invoked from network); 1 Aug 2001 22:11:53 -0000 Received: from faui02.informatik.uni-erlangen.de (root@131.188.30.102) by mail.netbsd.org with SMTP; 1 Aug 2001 22:11:53 -0000 Received: from folly.informatik.uni-erlangen.de (root@localhost [127.0.0.1]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id AAA05375; Thu, 2 Aug 2001 00:15:35 +0200 (MET DST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 6FDAF44A6; Thu, 2 Aug 2001 00:15:31 +0200 (CEST) Date: Thu, 2 Aug 2001 00:15:31 +0200 From: Markus Friedl To: Joseph Galbraith Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: drafts appear to have been published; please review. Message-ID: <20010802001530.A26237@folly> References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <017601c11a1d$d5578120$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017601c11a1d$d5578120$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Tue, Jul 31, 2001 at 06:06:37PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 31, 2001 at 06:06:37PM -0600, Joseph Galbraith wrote: > Hmm... the drafts appear to have changed in a way > that totally confuses my diff tool... is anyone > else having a bad time with this or is my diff > tool just complete drain bamaged? try to get wdiff from some gnu site. wdiff -p works fine for me. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:36:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28677 for ; Fri, 3 Aug 2001 16:36:18 -0400 (EDT) Received: (qmail 27437 invoked by uid 605); 3 Aug 2001 20:33:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27430 invoked from network); 3 Aug 2001 20:33:12 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:33:12 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137262 for ietf-ssh@netbsd.org; Fri, 03 Aug 2001 14:36:12 -0600 Message-ID: <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: global and channel requests -- more information on failure, more flexibility on success Date: Fri, 3 Aug 2001 14:37:46 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Regarding global and channel requests... I believe more information on failure and more flexibility on success is needed. - In the connection draft, section 2, we should change byte SSH_MSG_REQUEST_SUCCESS to byte SSH_MSG_REQUEST_SUCCESS string request-name ... request-specific data follows All current requests (unless otherwise specified) have no request specific data. If existing implementations won't safely ignore the extra packet data, we should change the packet number and deprecate the existing one. - In the connection draft, section 2, we should change byte SSH_MSG_REQUEST_FAILURE to byte SSH_MSG_REQUEST_FAILURE string request-name uint32 reason string additional text (UTF-8) string language where reason is one of ADMIN_PROHIBITED = 0 UNKNOWN_UNSUPPORTED = 1 RESOURCE_SHORTAGE = 2 GENERAL_FAILURE = 3 I think existing implementations should simply ignore the extra data. If not, we should give this code a new value, i.e., SSH_MSG_REQUEST_FAILURE2, and deprecate the old message. - If global requests are issued asynchronously (is this allowed?) are there any guarantees for order of completion? Do we need to be able to tag requests? - In the connection draft, section 3.4, we should change byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel to byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel string request-name ...request specific data If existing implementations won't safely ignore the extra packet data, we should change the packet number and deprecate the existing one. - In the connection draft, section 3.4, we should change byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel to byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel string request-name uint32 reason string addition descriptive text (UTF8) string language Again, I believe current implementations should discard the extra data at the end of the packet -- if not, we should change the message number and deprecate this existing message. - In the connection draft, section 3.4, we explicitly allow requests to be sent without waiting for completion. Are there any ordering guarantees? Do we need to tag the requests so responses can be associated with specific requests? Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:37:38 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28694 for ; Fri, 3 Aug 2001 16:37:38 -0400 (EDT) Received: (qmail 27874 invoked by uid 605); 3 Aug 2001 20:34:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27861 invoked from network); 3 Aug 2001 20:34:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:34:34 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137268 for ietf-ssh@netbsd.org; Fri, 03 Aug 2001 14:37:34 -0600 Message-ID: <00e801c11c5c$57de4d00$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: @domainname naming Date: Fri, 3 Aug 2001 14:39:07 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit In the connection draft, section 2, we should declare that global request names follow the DNS extensibility naming convention. In the connection draft, section 3.4, we should declare that channel request names follow the DNS extensibility naming convention. In the connection draft, section 4.5 we should note that subsystem names follow DNS extension convention. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:37:46 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28708 for ; Fri, 3 Aug 2001 16:37:46 -0400 (EDT) Received: (qmail 27877 invoked by uid 605); 3 Aug 2001 20:34:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27866 invoked from network); 3 Aug 2001 20:34:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:34:34 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137269 for ietf-ssh@netbsd.org; Fri, 03 Aug 2001 14:37:46 -0600 Message-ID: <00e901c11c5c$5f4ceb50$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: The "zlib bug" Date: Fri, 3 Aug 2001 14:39:20 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit In the transport draft, Section 4.2, do we need a comment about the zlib bug? (If I remember the discussion correctly, zlib as implemented in existing SSH servers isn't really zlib as defined in RFC1950 and RFC1951) Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:38:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28745 for ; Fri, 3 Aug 2001 16:38:34 -0400 (EDT) Received: (qmail 28700 invoked by uid 605); 3 Aug 2001 20:35:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28693 invoked from network); 3 Aug 2001 20:35:30 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:35:30 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137277 for ietf-ssh@netbsd.org; Fri, 03 Aug 2001 14:38:30 -0600 Message-ID: <00ea01c11c5c$797193a0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: x.509v3 publickeys and signatures Date: Fri, 3 Aug 2001 14:40:04 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit In the transport draft, Section 4.6, we specify that public keys are, in general encoded as: string certificate or public key format identifier byte[n] key/certificate data However, the sections on x.509 are less clear. And in fact, SSH Communications current x.509 implementation omits the string, including only the certificate data -- although the string is included when sending signatures. I would suggest we include the following text in section documenting "x509v3-sign-rsa": The "x509v3-sign-rsa" key format has the following specific encoding: string "x509v3-sign-rsa" byte[n] x.509v3 compatible der encoded certificate data The resulting signature is encoded as follows: string "x509v3-sign-rsa" string rsa_signature_blob Variants to this go in the other x.509 sections as appropriate. In addition, I would suggest that we note that signatures made with x509v3-sign-rsa keys MUST use the SHA-1 hash, and be done using PKCS1. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:41:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28809 for ; Fri, 3 Aug 2001 16:41:25 -0400 (EDT) Received: (qmail 29240 invoked by uid 605); 3 Aug 2001 20:38:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29233 invoked from network); 3 Aug 2001 20:38:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:38:22 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137278; Fri, 03 Aug 2001 14:41:22 -0600 Message-ID: <00f801c11c5c$dfbc19a0$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: Re: drafts appear to have been published; please review. Date: Fri, 3 Aug 2001 14:42:55 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit There are a number of places in the draft where formatting is a problem. o Indentation is often a little screwy making it seem like some things are associated or subsections when the are not. o In arch, pg. 8, section 4, the headings "boolean", "uint32", "string", etc. all look like they are associated with the section above them. o In the transport, pg 6, section 4, the documentation for packet format is messed up, both indentation and vertical white space. o In the transport draft, Section 5.1, the section labeled server_host_key_algorithms, a blank line between paragraphs would help readability. (The same applies anyplace where paragraphs are not currently separated by blank lines.) o In the connection draft table of contents, there appear to be extra characters for 4.3.1 and 4.3.2 -- unless these have meaning I'm not aware of? o In the transport draft, Section 4.2, 4.3, 4.4, and 4.5 there is a missing reference with regards to defining additional methods. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 16:47:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28901 for ; Fri, 3 Aug 2001 16:47:01 -0400 (EDT) Received: (qmail 314 invoked by uid 605); 3 Aug 2001 20:44:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 307 invoked from network); 3 Aug 2001 20:43:58 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 20:43:58 -0000 Received: from [127.0.0.1] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137288 for ietf-ssh@netbsd.org; Fri, 03 Aug 2001 14:46:58 -0600 Message-ID: <00ff01c11c5d$a8143f40$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: Other misc things in the drafts Date: Fri, 3 Aug 2001 14:48:31 -0600 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Here are a number of comments on a fresh read of the drafts, something I haven't done for a while. - In the userauth draft, Section 6, we refer to the "client username on the remote host" Since the "user name" field is the username on the remote host (from the clients point for view) I think this must really mean the "username on the client" In any case, "remote host" is vague, since we don't really know what point of view we are using, client or server. I would suggest this just become "username on the client" or perhaps "client user name" - In the connection draft, section 4.3.1, we should note that the x11 authentication cookie MUST be hexadecimal encoded. - In the connection draft, near section 4.7 should we add a "terminal-mode-change" message which could be used to notify the other side about mode changes (for example from input cooked to raw mode) This might allow optimizations for long lag time links (satellite) if the client wanted to cook lines on it's own. I would suggest byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "terminal-mode-change" boolean FALSE string encoded terminal modes string TERM environment variable value We may not want to do this -- we are trying to finish the drafts -- and it doesn't have a proven usefulness (though I've had occasion to wish I could do this as we tried to work around NT's lack of real PTYs.) - In the connection draft, section 5.1, we should specify text like this: The response to the "tcpip-forward" request will look like: byte SSH_MSG_GLOBAL_REQUEST_SUCCESS string "tcpip-forward" uint32 port that was bound on server We should also explicitly allow binding to port 0 to indicate any port. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 17:12:45 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29330 for ; Fri, 3 Aug 2001 17:12:45 -0400 (EDT) Received: (qmail 4468 invoked by uid 605); 3 Aug 2001 21:09:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4451 invoked from network); 3 Aug 2001 21:09:29 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 3 Aug 2001 21:09:29 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04626 for ; Fri, 3 Aug 2001 15:13:26 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA25165 for ; Fri, 3 Aug 2001 14:15:28 -0700 (PDT) Received: from spica1 (spica1.Eng.Sun.COM [129.146.81.114]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f73LDNb983832 for ; Fri, 3 Aug 2001 14:13:23 -0700 (PDT) Date: Fri, 3 Aug 2001 14:10:56 -0700 (PDT) From: Alok Aggarwal X-X-Sender: To: Subject: Port Forwarding Clarification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Section 5.1 of the connection protocol draft says: byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g. "0.0.0.0") uint32 port number to bind 'Address to bind' and 'port number to bind' specify the address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. When it says the address should be "0.0.0.0" if connections are allowed from anywhere, is it intended that if the client is IPv4 only then the address to bind should be "0.0.0.0"? So, if the client is dual stack or IPv6 only, then is it legal to send "::"? How do some of the implementors handle this case? Perhaps the draft needs to be explicit about specifying the 'address to bind' for IPv4 and IPv6 clients. -Alok From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Aug 3 19:24:20 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00822 for ; Fri, 3 Aug 2001 19:24:19 -0400 (EDT) Received: (qmail 18944 invoked by uid 605); 3 Aug 2001 23:21:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18937 invoked from network); 3 Aug 2001 23:21:11 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 3 Aug 2001 23:21:11 -0000 Received: from [127.0.0.1] (HELO joseph) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 137399; Fri, 03 Aug 2001 17:24:01 -0600 Message-ID: <00a601c11c74$d386dea0$140210ac@galbraiths.com> From: "Joseph Galbraith" To: "Alok Aggarwal" Cc: References: Subject: Re: The "zlib bug" Date: Fri, 3 Aug 2001 17:34:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > In the transport draft, Section 4.2, do we need a comment > > about the zlib bug? (If I remember the discussion correctly, > > zlib as implemented in existing SSH servers isn't really > > zlib as defined in RFC1950 and RFC1951) > > What zlib bug are you referring to here? Alok, Unfortunately, I'm not terribly familiar with the issues, I just remembering it being talked about. The issue was raised by Wei Dai back in January when we were aiming for last call then. > I raised an issue several months ago that I don't think ever got resolved. > The issue is how to define "partial flush" of the zlib compressed data > stream. I think the current definition is ambiguous, but I'm not sure how > to fix it. The problem is that there is a bug in the current zlib library > which requires more bits (consisting of empty blocks) to be outputed in a > flush than is necessary. If we were to define "partial flush" in the most > natural way (i.e. not taking into account this bug), someone may create an > secsh implementation that's not compatible with any secsh implementation > based on the current zlib. > > I've reported this bug to the zlib maintainers, and they've promised to > fix it in a future release. Do we want to maintain backwards compatibility > and define "partial flush" in a way that satisfies the current buggy zlib? He proposed some text for the drafts: > Here are my suggested definitions. First the non-compatible version, which > you may consider for "zlib-2". (An implementation that supports "zlib-2" > can also easily support "zlib" so it may be a good idea to have both.) > This definition has the advantage of being simpler and saving a few bytes > per packet: > > A partial flush means that the current compressed block is ended and all > data will be output. If the current block does not end on a byte boundary, > an empty block is added to fill up the last byte. He also proposed text for a compatible version, and later revised it to: > A partial flush means that the current compressed block is ended and all > data will be output. If the current block is not a stored block, one or > more empty blocks are added after the current block to ensure that there > are at least 8 bits counting from the start of the end-of-block code of > the current block to the end of the packet payload. Bill Sommerfield weighed in with: > Ok. > > [WG chair hat on] > > I'd like to treat this as two separate issues: > > 1) we don't accurately describe what's on the wire (due to the zlib > bug). > > This is serious and (IMHO) warrants a fix to the current drafts. > (noting the zlib bug). > > 2) we could do better on the compression. > > One of my alter egos is a performance tweaker, so fixing this (by > creating an alternate zlib-2 compression method) has a definite > appeal. > > At this stage in the game (for Proposed Standard), it's OK to toss in > new features without implementation experience, but I don't think we > want to delay the drafts until we get consensus on zlib-2; it might > also be wise to wait until someone plugs the new zlib release into a > secsh implementation before defining "zlib-2". > > So, what we can do is create a separate zlib-2 draft, and when that > gets suitably mature fold that into the transport draft.. > > Comments? Hopefully, that reviews all the issues sufficiently. I think the whole thread is probably available in the archives. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Aug 4 10:22:31 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26543 for ; Sat, 4 Aug 2001 10:22:30 -0400 (EDT) Received: (qmail 13732 invoked by uid 605); 4 Aug 2001 14:19:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13725 invoked from network); 4 Aug 2001 14:19:24 -0000 Received: from shearer.org (HELO calulu.shearer.org) (203.20.69.69) by mail.netbsd.org with SMTP; 4 Aug 2001 14:19:24 -0000 Received: from calulu.shearer.org ([203.20.69.69]) by calulu.shearer.org with esmtp (Exim 3.12 #1) id 15T2KL-0001vH-00 for ietf-ssh@netbsd.org; Sat, 04 Aug 2001 23:52:53 +0930 Date: Sat, 4 Aug 2001 23:52:53 +0930 (CST) From: Dan Shearer To: ietf-ssh@netbsd.org Subject: Small modification to allow application proxies Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list This proposes a modification to http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-09.txt The change affects the definition of the header exchange, and I have not found a record of it being previously discussed. My apologies if it has been. I am not a security protocols expert (far from it) just a user hacking together a solution. Section 3.2 "Protocol Version Exchange" says: When the connection has been established, both sides MUST send an identification string of the form "SSH-protoversion-softwareversion comments"... : The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC-2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP-wrappers to display an error message before disconnecting. I would like to suggest that the client be allowed to optionally send other lines of data in the same way the servers can, ie a paragraph like so: The client MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC-2279] (language is not specified). Servers MUST be able to process such lines up to a limit of 4096 8-bit characters after the newline; they MAY be silently ignored, or MAY be used to perform some pre-processing of the connection attempt. If they are if they are displayed or logged, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow application-level proxies for ssh, whereby multiple, different servers can be accessed via a single IP address by specifying an appropriate payload such as a hostname or other mapping supported by the proxy. The syntax of any payload is not specified. I have invented an arbitary 4096 character limit for safety, although I don't really know what it should be. I observe that there is no such limit in the original which says "Clients MUST be able to process such lines". I suspect this allows the possibility of a malicious server or packet insertion attack tying up an unsuspecting client, or otherwise confusing it. I have not checked to see if this issue has been discussed before on the secsh list; it probably has been, since it is rather obvious! When I first started playing with openssh I fiddled with letting the client specify version information such as a DNS name, however this isn't a good solution for many reasons. UTF-8 DNS names would break the length limit for a start. I don't see that this proposal weakens the protocol, because the sensible way to implement an application proxy is just to send on all information including the extended version string to the host the other side of the proxy as specified by the payload. Examples -------- The following examples assume a network like this: Internet ssh application proxy Internal .test network ip address 1.2.3.4 girafe (10.0.0.1) DNS A bouchon.test CNAME girafe.test They also assume a -z parameter to the ssh client which puts everything that follows -z in the extended version string. Sessions are initiated from random hosts on the Internet. ssh -z girafe.test would make a connection on port 22 to 1.2.3.4, and the proxy server would see there was a payload. Since "girafe.test" resolves on the internal network's DNS, the connection attempt is forwarded to 10.0.0.1 (if policy allows.) ssh -z bouchon.test would connect to port 22 on 1.2.3.4, and the proxy server would see that the name in the payload is its own name, and (if policy allows) this is forwarded on to the local machine just like any other connection. Either there is an ssh daemon running on a port other than 22, or the proxy server is also an ssh daemon (possibly inadvisable, depends) or the ssh daemon is running on port 22 bound to another interface on the same machine as 1.2.3.4. ssh -z zero.example would initiate a connection to the machine zero.example, which is not running an ssh proxy and would completely ignore the payload, proceeding with an ordinary connection attempt. Apart from the transmited version payload, everything in this example would proceed as if the command ssh zero.example had been used instead. Benefits -------- I see the benefits of this addition to be mainly: 1. Networks behind NAT firewalls will be able to expose internal ssh services without exposing any more IP addresses. This increases convenience for such sites, not security 2. An application proxy for ssh will become practical. This could increase security (even for sites which are not behind NAT firewalls) and it certainly allows some forms of logging and control to be centralised that would otherwise be distributed at the ssh connection endpoints inside a network 3. Potential to consolidate services, for similar reasons that web hosters like to run many virtual servers from one IP address The proxy could choose to perform transformations on the ssh stream rather than just passing it on. -- Dan Shearer Open Source Manager Mob: +61 411 49 1800 Tel: +61 8 8130 3104 dan@tellurian.com.au From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 6 11:03:43 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25028 for ; Mon, 6 Aug 2001 11:03:43 -0400 (EDT) Received: (qmail 16623 invoked by uid 605); 6 Aug 2001 15:00:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16616 invoked from network); 6 Aug 2001 15:00:33 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 6 Aug 2001 15:00:33 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f76F4cf07310 for ; Mon, 6 Aug 2001 18:04:38 +0300 (EEST) Received: (qmail 6736 invoked from network); 6 Aug 2001 15:04:38 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 6 Aug 2001 15:04:38 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id SAA13687; Mon, 6 Aug 2001 18:05:22 +0300 To: ietf-ssh@netbsd.org Subject: Re: The algorithm name "" References: From: sjl@ssh.com (Sami J. Lehtinen) Date: 06 Aug 2001 18:05:22 +0300 In-Reply-To: nisse@lysator.liu.se's message of "Wed, 25 Apr 2001 09:53:25 +0000 (UTC)" Message-ID: Lines: 57 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list nisse@lysator.liu.se (Niels Möller) writes: > I've had some reports on interoperation problems with the latest lsh > client and a server presenting itself as "SSH-1.99-2.0.13 > (non-commercial)". The server sends a USERAUTH_FAILURE message > > DEBUG: Received USERAUTH_FAILURE (size 25 = 0x19) > 00000000: 33000000137075626c69636b65792c70 3....publickey,p > 00000010: 617373776f72642c00 assword,. > > Looking at the packet, the "authentications that can continue" string > is "publickey,password,". Note the trailing comma. lsh parses this as > a list with three elements "publickey", "password", "". And it > considers empty algorithm names as a protocol error and disconnects. I'd say this is a bug in 2.0.13. > Am I being overly pedantic, or should empty algorithm names be treated > as errors? Probably should. > Another question is how to interpret the list "" (which makes sense > for instance in the languages_client_to_server list). Is that an empty > list, or a list containing a single empty string?Ruling out empty > strings resolves that ambiguity, making sure that "" can only be > interpreted as an empty list. I see it as an empty list in this context. > I'd like to edit the architecture draft as follows, > > Current text: > [SNIP] > > In this protocol, all algorithm identifiers MUST be printable US-ASCII > strings no longer than 64 characters. Names MUST be case-sensitive. > > Proposal: Replace the last paragraph with > > In this protocol, all algorithm identifiers MUST be printable > US-ASCII non-empty strings no longer than 64 characters. Names MUST > be case-sensitive. > > It may also be a good idea to specify the format for comma-separated > lists once, in the architecture document. Proposal, to be added to > section 4, "Data Type Representations Used in the SSH Protocols" in > the architecture document: Both suggestions seem fine to me. Cheers, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 6 16:48:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01482 for ; Mon, 6 Aug 2001 16:48:30 -0400 (EDT) Received: (qmail 29830 invoked by uid 605); 6 Aug 2001 20:45:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29823 invoked from network); 6 Aug 2001 20:45:21 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 6 Aug 2001 20:45:21 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18593; Mon, 6 Aug 2001 14:49:23 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14837; Mon, 6 Aug 2001 16:49:24 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f76KmmJ21623; Mon, 6 Aug 2001 16:48:48 -0400 (EDT) Message-Id: <200108062048.f76KmmJ21623@thunk.east.sun.com> From: Bill Sommerfeld To: Dan Shearer cc: ietf-ssh@netbsd.org Subject: Re: Small modification to allow application proxies In-reply-to: Your message of "Sat, 04 Aug 2001 23:52:53 +0930." Reply-to: sommerfeld@east.sun.com Date: Mon, 06 Aug 2001 16:48:48 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list It's not clear to me why it would be necessary to change servers this way; an application-layer proxy which required the client to prefix the connection with some sort of control message could strip the prefix from the stream before forwarding the rest to the eventual destination, leaving the protocol, as seen on the outside of the application proxy, unchanged. A worked example of this is, of course, the SOCKS proxying protocol.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 6 18:21:22 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03354 for ; Mon, 6 Aug 2001 18:21:22 -0400 (EDT) Received: (qmail 24772 invoked by uid 605); 6 Aug 2001 22:18:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24765 invoked from network); 6 Aug 2001 22:18:14 -0000 Received: from shearer.org (HELO calulu.shearer.org) (203.20.69.69) by mail.netbsd.org with SMTP; 6 Aug 2001 22:18:14 -0000 Received: from calulu.shearer.org ([203.20.69.69]) by calulu.shearer.org with esmtp (Exim 3.12 #1) id 15TsY7-0002Y1-00; Tue, 07 Aug 2001 07:38:35 +0930 Date: Tue, 7 Aug 2001 07:38:35 +0930 (CST) From: Dan Shearer To: Bill Sommerfeld cc: ietf-ssh@netbsd.org Subject: Re: Small modification to allow application proxies In-Reply-To: <200108062048.f76KmmJ21623@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 6 Aug 2001, Bill Sommerfeld wrote: > It's not clear to me why it would be necessary to change servers this > way; Actually it isn't, you are right. The essence of my proposal can be entirely met by modifying the client. Right now it is only the server which can send extra information after the version string. If a client wants to pass on meta-info of some sort it can't, unless it is with a limited bodge in the comment string. It would be very nice if a standard ssh client could be used from any platform to connect to such an application-layer proxy without any additional infrastructure, just as any web browser can connect to a virtual web server because the protocol passes information about which host is requested. However this would mean that if a client chose to send this information every time by default (on the off-chance that it might be an application proxy that it was connecting to) then any non-proxies would reject the connection attempt because of extraneous data. Maybe that is a good thing. I'll submit my implementation to the appropriate place and see what they say. > an application-layer proxy which required the client to prefix > the connection with some sort of control message could strip the > prefix from the stream before forwarding the rest to the eventual > destination, leaving the protocol, as seen on the outside of the > application proxy, unchanged. Thus creating a client (or a mode of a client, such as I proposed) that would only work with a proxy. That's ok I guess. -- Dan Shearer Open Source Manager Mob: +61 411 49 1800 Tel: +61 8 8130 3104 dan@tellurian.com.au From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 7 06:31:17 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29675 for ; Tue, 7 Aug 2001 06:31:16 -0400 (EDT) Received: (qmail 25180 invoked by uid 605); 7 Aug 2001 10:28:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25170 invoked from network); 7 Aug 2001 10:28:00 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 7 Aug 2001 10:28:00 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f77AW3f02302 for ; Tue, 7 Aug 2001 13:32:07 +0300 (EEST) Received: (qmail 6751 invoked from network); 7 Aug 2001 10:32:02 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 7 Aug 2001 10:32:02 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id NAA14487; Tue, 7 Aug 2001 13:32:46 +0300 From: "Sami J. Lehtinen" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="fIHgcHgV4k" Content-Transfer-Encoding: 7bit Message-ID: <15215.50126.388539.735708@johto.hel.fi.ssh.com> Date: Tue, 7 Aug 2001 13:32:46 +0300 (EEST) To: ietf-ssh@netbsd.org Subject: Bubble Babble X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: ietf-ssh-owner@netbsd.org Precedence: list --fIHgcHgV4k Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Here's the document, as requested. Keep in mind that this document will need atleast some polishing before any formal publication can be done. --fIHgcHgV4k Content-Type: text/plain Content-Description: Bubble Babble specification Content-Disposition: inline; filename="babble-rfc.txt" Content-Transfer-Encoding: 7bit authors==Huima status==Experimental title==The Bubble Babble Binary Data Encoding number==Internet Draft date==April 2000 Network Working Group Antti Huima Internet Draft SSH Communications Security draft-huima-babble-01.txt April 2000 The Bubble Babble Binary Data Encoding Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a new encoding method for binary data that is intended to be used in conjunction with fingerprints of security-critical data. 1. Introduction Hash values of certificates and public keys, known as fingerprints or thumbprints, are commonly used for verifying that a received security-critical datum has been received correctly. Fingerprints are binary data and typically encoded as series of hexadecimal digits. However, long strings hexadecimal digits are difficult for comprehend and cumbersome to translate reliably e.g. over phone. The Bubble Babble Encoding encodes arbitrary binary data into pseudowords that are more natural to humans and that can be pronounced relatively easily. The encoding consumes asymptotically the same amount of space as an encoding of the form HH HH HH HH ... where `H' is a hexadecimal digit, i.e. carries 16 bits in six characters. However, the Bubble Babble Encoding includes a checksumming method that can sometimes detect invalid encodings. The method does not increase the length of the encoded data. 2. Encoding Below, _|X|_ denotes the largest integer not greater than X. Let the data to be encoded be D[1] ... D[K] where K is the length of the data in bytes; every D[i] is an integer from 0 to 2^8 - 1. First define the checksum series C[1] ... C[_|K/2|_] where C[1] = 1 C[n] = (C[n - 1] * 5 + (D[n * 2 - 3] * 7 + D[n * 2 - 2])) mod 36 The data is then transformed into _|K/2|_ `tuples' T[1] ... T[_|K/2|_] and one `partial tuple' P so that T[i] = where a = (((D[i * 2 - 3] >> 6) & 3) + C[i]) mod 6 b = (D[i * 2 - 3] >> 2) & 15 c = (((D[i * 2 - 3]) & 3) + _|C[i] / 6|_) mod 6 d = (D[i * 2 - 2] >> 4) & 15; and e = (D[i * 2 - 3]) & 15. The partial tuple P is P = where if K is even then a = (C[i]) mod 6 b = 16 c = _|C[i] / 6|_ but if it is odd then a = (((D[K] >> 6) & 3) + C[i]) mod 6 b = (D[K] >> 2) & 15 c = (((D[K]) & 3) + _|C[i] / 6|_) mod 6 The `vowel table' V maps integers between 0 and 5 to vowels as 0 - a 1 - e 2 - i 3 - o 4 - u 5 - y and the `consonant table' C maps integers between 0 and 16 to consonants as 0 - b 1 - c 2 - d 3 - f 4 - g 5 - h 6 - k 7 - l 8 - m 9 - n 10 - p 11 - r 12 - s 13 - t 14 - v 15 - z 16 - x The encoding E(T) of a tuple T = is then the string V[a] C[b] V[c] C[d] `-' C[e] where there are five characters, and `-' is the literal hyphen. The encoding E(P) of a partial tuple P = is the three-character string V[a] C[b] V[c]. Finally, the encoding of the whole input data D is obtained as `x' E(T[1]) E(T[2]) ... E(T[_|K/2|_]) E(P) `x' where `x's are literal characters. 3. Decoding Decoding is obviously the process of encoding reversed. To check the checksums, when a tuple or partial tuple has been recovered from the encoded string, an implementation should check that ((a - C[i]) mod 6) < 4 and that ((c - C[i]) mod 6) < 4. Otherwise the encoded string is not a valid encoding of any data and should be rejected. 4. Checksum Strength Every vowel in an encoded string carries 0.58 bits redundancy; thus the length of the `checksum' in the encoding of an input string containing K bytes is 0.58 * K bits. 5. Test Vectors ASCII Input Encoding ------------------------------------------------------------------ `' (empty string) `xexax' `1234567890' `xesef-disof-gytuf-katof-movif-baxux' `Pineapple' `xigak-nyryk-humil-bosek-sonax' 6. Author's Address Antti Huima SSH Communications Security, Ltd. [XXX] 7. Full Copyright Statement Copyright (C) The Internet Society (2000). 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. --fIHgcHgV4k Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] --fIHgcHgV4k-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 7 09:23:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAB03183 for ; Tue, 7 Aug 2001 09:23:20 -0400 (EDT) Received: (qmail 14186 invoked by uid 605); 7 Aug 2001 13:20:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14179 invoked from network); 7 Aug 2001 13:20:05 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Aug 2001 13:20:05 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 139209 for ietf-ssh@netbsd.org; Tue, 07 Aug 2001 07:23:21 -0600 Message-ID: <004101c11f44$5e2b0780$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: Subject: New channel requests... Date: Tue, 7 Aug 2001 13:51:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit This isn't part of what we agreed on in the meeting, so I've done it as a separate email-- but, it makes sense to me to change the channel requests in a parallel fashion to the global requests. Also, we [Van Dyke] have wanted better failure messages for subsystem requests, so I've introduced "start-subsystem" to replace "subsystem" with better failure results provided. Again, please comment. Do people think this is a bad idea, or can we go ahead, since it is fully backward compatible? Joseph Galbraith galb-list@vandyke.com ------------ Section 3.4 3.4 Channel-Specific Requests Many channel types have extensions that are specific to that particular channel type. An example is requesting a pty (pseudo terminal) for an interactive session. All channel-specific requests use the following format. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string request type (restricted to US-ASCII) boolean want reply ... type-specific data If want reply is FALSE, no response will be sent to the request. Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS or SSH_MSG_CHANNEL_FAILURE, or request- specific continuation messages. If the request is not recognized or is not supported for the channel, SSH_MSG_CHANNEL_FAILURE is returned. This message does not consume window space and can be sent even if no window space is available. Request types are local to each channel type. byte SSH_MSG_CHANNEL_SUCCESS uint32 recipient_channel ...request specific data byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel ...request specific data These messages do not consume window space and can be sent even if no window space is available. Unless otherwise specified, a request uses the general form of these messages, with no request specific failure or success data. If the recipient doesn't recognize the request, it will send a SSH_MSG_CHANNEL_FAILURE without any request specific data. This is called the generic form. Requests that do send information during failure MUST use the following format: byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel uint32 reason string descriptive-text [UTF8] string language ... further request-specific data follows New requests SHOULD use this extended failure message in order to provide end users and server administrators with information about a failure. 3.4.1 Multiple requests and ordering The client is allowed to send further messages without waiting for the response to the request. The recipient must respond to messages in the order received so that responses can be matched to requests. 3.4.2 Compatibility with older software As with global requests, older software can send old requests without fear of receiving an extended response. New software, sending new requests to older software will receive the generic form of SSH_MSG_CHANNEL_FAILURE. If the task can be accomplished in another way, the new software can proceed to attempt that; otherwise, it knows the receiver does not support the operation being attempted. ------------ Section 3.4, part about subsystems byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "start-subsystem" boolean want reply string subsystem name This last form executes a predefined subsystem. It is expected that these will include a general file transfer mechanism, and possibly other features. Implementations may also allow configuring more such mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish from arbitrary output from shell initialization scripts etc. This spurious output from the shell may be filtered out either at the server or at the client. The server SHOULD not halt the execution of the protocol stack when starting a shell or a program. All input and output from these SHOULD be redirected to the channel or to the encrypted tunnel. It is RECOMMENDED to request and check the reply for these messages. The client SHOULD ignore these messages. The server response uses the generic form of SSH_MSG_CHANNEL_SUCCESS in the success case. In the failure case, the extended form of SSH_MSG_CHANNEL_FAILURE is used as defined in Section 3.4. There is no additional request specific data beyond the reason, description and language fields. The reason codes used are as follows: SSH_SUBSYSTEM_GENERIC 0 Generic error to be used for errors not covered by other reason codes. SSH_SUBSYSTEM_UNKNOWN 1 The subsystem name is not defined on the server. SSH_SUBSYSTEM_NOT_FOUND 2 The subsystem name is defined, but could not be started because the associated component didn't exist. SSH_SUBSYSTEM_ADMINISTRATIVELY_PROHIBITED 3 The subsystem will not be started because it the user requesting it is not permitted to do so. 3.4.1 Compatibility This request used to be "subsystem". The "subsystem" request is still supported, but implementations should move away from using it. The "subsystem" request is identical to the "start-subsystem" request, except that it uses the general form of the response messages, making it impossible to determine why the subsystem did not start, in the event of a failure. Old software receiving a "start-subsystem" request will fail it with the general response form. Newer software can then fall back on the old "subsystem" request. Old software making "subsystem" requests will receive compatible general response forms, regardless of whether a new or old implementation is the receiver. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 7 09:23:29 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03194 for ; Tue, 7 Aug 2001 09:23:29 -0400 (EDT) Received: (qmail 14383 invoked by uid 605); 7 Aug 2001 13:20:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14174 invoked from network); 7 Aug 2001 13:20:05 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Aug 2001 13:20:05 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 139207 for ietf-ssh@netbsd.org; Tue, 07 Aug 2001 07:23:20 -0600 Message-ID: <004001c11f44$5d6609d0$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: Subject: New requests to support binding port 0 Date: Tue, 7 Aug 2001 13:21:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit As promised during the meeting, here are the changes required to support binding to port 0. There are two sets of changes -- the first changes global requests in a fully backward compatible manner to make the second set of changes legal. The second set of changes define two new requests, "tcpip-bind" and "tcpip-unbind" which replace the existing "tcpip-forward" and "cancel-tcpip-forward" requests. The "tcpip-forward" and "cancel-tcpip-forward" requests are still defined, but are deprecated. I also clarified multiple requests and ordering. Please let me know if this is satisfactory, or if people what changes, or if I totally screwed up what I agreed to do :-) Joseph Galbraith galb-list@vandyke.com ------------------------------------------------------- For section 2 of the connection draft: 2. Global Requests There are several kinds of requests that affect the state of the remote end "globally", independent of any channels. An example is a request to start TCP/IP forwarding for a specific port. All such requests use the following format. byte SSH_MSG_GLOBAL_REQUEST string request name (restricted to US-ASCII) boolean want reply ... request-specific data follows The recipient will respond to this message with SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request-specific continuation messages if `want reply' is TRUE. byte SSH_MSG_REQUEST_SUCCESS ... request-specific data follows Unless otherwise specified, a request sends no additional data with it's success message. If the recipient does not recognize, it simply responds with SSH_MSG_REQUEST_FAILURE. byte SSH_MSG_REQUEST_FAILURE If the recipient recognizes the request, but can not complete the request because of local policy or because an error occurs processing the request, it responds with: byte SSH_MSG_REQUEST_FAILURE ... request-specific data follows Unless otherwise specified, a request sends no additional data with it's failure message. In this case, it is not possible to distinguish between the unrecognized request case and the failed request case. Requests that do send information during failure MUST use the following format: byte SSH_MSG_REQUEST_FAILURE uint32 reason string descriptive-text [UTF8] string language ... further request-specific data follows New requests SHOULD use this extended failure message in order to provide end users and server administrators with information about a failure. 2.1 Multiple requests and ordering Multiple requests may be sent without waiting for replies. The receiver must complete requests in the order which they are received so that responses can be matched with requests. 2.2 Compatibility with existing implementations Since all previously defined requests are defined as having no request-specific data for either success or failure messages, existing implementations can send these previously define requests without fear of receiving an extended failure or success message in response. New implementations might send a new request to an old implementation. In this case, the old implementation will not recognize the request, and will respond with the "unrecognized" form of the SSH_MSG_REQUEST_FAILURE message -- the only form of failure message previously defined. ------ New text for Section 5.1: 5.1 Requesting Port Forwarding A party need not explicitly request forwardings from its own end to the other direction. However, if it wishes that connections to a port on the other side be forwarded to the local side, it must explicitly request that the port be bound on the remote side. byte SSH_MSG_GLOBAL_REQUEST string "tcpip-bind" boolean want reply string address to bind (e.g. "0.0.0.0") uint32 port number to bind 'Address to bind' and 'port number to bind' specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. (Note that the client can still filter connections based on information passed in the open request.) The port should be 0 to bind to any available port. Implementations should only allow forwarding privileged ports if the user has been authenticated as a privileged user. Client implementations SHOULD reject these messages; they are normally only sent by the client. The server responds with either byte SSH_MSG_REQUEST_SUCCESS uint32 port that was bound or byte SSH_MSG_REQUEST_FAILURE uint32 reason string descriptive-text [UTF8] string language where reason is one of the reason codes defined below. A port forwarding can be cancelled with the following message. Note that channel open requests may be received until a reply to this message is received. byte SSH_MSG_GLOBAL_REQUEST string "tcpip-unbind" boolean want reply string address_to_bind (e.g. "127.0.0.1") uint32 port number to bind Client implementations SHOULD reject these messages; they are normally only sent by the client. The port number may not be 0. The server responds with either byte SSH_MSG_REQUEST_SUCCESS or byte SSH_MSG_REQUEST_FAILURE uint32 reason string descriptive-text [UTF8] string language Reason codes are one of the following: SSH_BIND_GENERAL_FAILURE 0 SSH_BIND_ADMINISTRATIVELY_PROHIBITED 1 SSH_BIND_PORT_IN_USE 2 SSH_BIND_INVALID_ADDRESS 3 SSH_BIND_INVALID_PORT 4 SSH_BIND_PORT_NOT_BOUND 5 5.1.1 Compatibility with previous Port Forwarding requests Previously, these requests were "tcpip-forward" and "cancel-tcpip-forward" These requests are still supported, but implementations SHOULD move away from using them. The requests are identical to the "tcpip-bind" and "tcpip-unbind" requests, except that the generic success and failure messages are sent (with no request specific data attached.) Because it is not possible to get information about what port was bound, it is also prohibited to bind to port 0 when using a "tcpip-forward" request. "tcpip-forward" and "cancel-tcpip-forward" should be considered deprecated. If a new client sends a "tcpip-bind" request to an old server, it will receive the "unrecognized- request" form of the failure message. In this case, binding to port 0 is not possible, but all other requests can still be made by falling back into a "compatibility mode" and issuing "tcpip-forward" requests instead. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 7 09:27:55 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03266 for ; Tue, 7 Aug 2001 09:27:55 -0400 (EDT) Received: (qmail 16441 invoked by uid 605); 7 Aug 2001 13:24:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16434 invoked from network); 7 Aug 2001 13:24:46 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Aug 2001 13:24:46 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 139223 for ietf-ssh@netbsd.org; Tue, 07 Aug 2001 07:28:02 -0600 Message-ID: <005c01c11f45$0588cb20$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: Subject: x.509v3 certificates... Date: Tue, 7 Aug 2001 14:29:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit **** **** I've included the algorithm string **** in key packet clarification here even though we **** forgot to talk about it in the meeting. Please, **** comment! **** **** That's the part where it says: **** string "x509v3-*" **** string x.509v3 compatible der encoded certificate data **** In the meeting we talked about x.509v3 certificates -- the problem is that when using smart cards, you don't always have control over the hash algorithm used. So, we decided to change x.509v3 certificates to use pkcs7 signatures, because otherwise, there is no way to know what hashing algorithm was used. As promised, here is the text. Please comment on the changes -- silence means everyone agrees with me, right? Thanks, Joseph Galbraith galb-list@vandyke.com --------- Transport draft, Section 4.6 (We might want to number the different sections of this, so that ssh-dss becomes 4.6.1, ssh-rsa becomes 4.6.2, and x509v3-* becomes 4.6.3) 4.6.3 x.509v3 certificates The "x509v3-*" methods indicate that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER-encoded format. The formats used in X.509v3 are described in [RFC2459]. The formats used for signatures are described in [PKCS7]. Note, that there is no such algorithm as "x509v3-*", but the * is used only in this document to denote all algorithms beginning with x509v3. There are currently two such algorithms defined: x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) The "x509v3-*" key format has the following generic encoding: string "x509v3-*" string x.509v3 compatible der encoded certificate data The resulting signature is encoded as follows: string "pkcs7" string PKCS-7 signature, DER encoded The "x509v3-sign-rsa" method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "x509v3-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 08:30:35 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11130 for ; Wed, 8 Aug 2001 08:30:35 -0400 (EDT) Received: (qmail 23014 invoked by uid 605); 8 Aug 2001 12:27:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23007 invoked from network); 8 Aug 2001 12:27:24 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Aug 2001 12:27:24 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 8BF0282F466; Wed, 8 Aug 2001 14:31:33 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA12805; Wed, 8 Aug 2001 14:31:33 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: global and channel requests -- more information on failure, more flexibility on success References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 08 Aug 2001 14:31:33 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Fri, 3 Aug 2001 14:37:46 -0600" Message-ID: Lines: 83 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > Regarding global and channel requests... I believe more > information on failure and more flexibility on success > is needed. Why? I believe global requests should always be answered in order, and channel_requests on the same channel should also be answered in order. This is analogous to the requirements for userauth-requests, which I think are spelled out more clearly in the documents. If you really want to be able to permute responses, you should add a an id to each request, but I don't think that is really needed. Adding just the request-name to the responses seems useless. > - In the connection draft, section 2, we should change > > byte SSH_MSG_REQUEST_SUCCESS > > to > > byte SSH_MSG_REQUEST_SUCCESS > string request-name > ... request-specific data follows I don't think adding the request name here is terribly useful. As for request specific data, that might be useful, but we don't need to do anything about that now. The day I invent a request where it makes sense to have additional data, I'll add it. Implementations that don't know about the new request will never see the extended response packet, because they never send the new request. > If existing implementations won't safely ignore the extra > packet data, we should change the packet number and > deprecate the existing one. Datapoint: LSH generally do *not* allow extra data on random packets, and will generally treat that as a fatal protocol error. > - In the connection draft, section 2, we should change > > byte SSH_MSG_REQUEST_FAILURE > > > to > > byte SSH_MSG_REQUEST_FAILURE > string request-name > uint32 reason > string additional text (UTF-8) > string language That makes more sense (although the request-name is still redundant, under the assumption that requests are still answered in order). > I think existing implementations should simply ignore the > extra data. If not, we should give this code a new value, > i.e., SSH_MSG_REQUEST_FAILURE2, and deprecate the old > message. You can't do that, what you can do is add new _request_ messages. > - If global requests are issued asynchronously (is this allowed?) > are there any guarantees for order of completion? Do we need > to be able to tag requests? I think the only reasonable thing is to require that responses are sent in the right order (requests on different channels can be answered in any order, though). Summary: I disagree with you're proposed changes, except for adding some more information to failure messages. Resonses should be sent in the right where "right order" is defined in my first paragraph. It's too late to replace "reply-in-order" with "add-id-to-all-requests", and I think reply-in-order is adequate. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 08:39:28 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11304 for ; Wed, 8 Aug 2001 08:39:27 -0400 (EDT) Received: (qmail 23934 invoked by uid 605); 8 Aug 2001 12:36:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23927 invoked from network); 8 Aug 2001 12:36:18 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Aug 2001 12:36:18 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 973B682F52D; Wed, 8 Aug 2001 14:40:28 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA12989; Wed, 8 Aug 2001 14:40:28 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: Other misc things in the drafts References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00ff01c11c5d$a8143f40$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 08 Aug 2001 14:40:28 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Fri, 3 Aug 2001 14:48:31 -0600" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > - In the connection draft, section 4.3.1, we should note > that the x11 authentication cookie MUST be hexadecimal > encoded. Why? Is that what people are doing (I haven't implemented x11 forwarding yet). It seems very strange to me to use a redundant but ascii-friendly encoding for things in the binary very eight-bit clean ssh protocols. > - In the connection draft, section 5.1, we should specify > text like this: > > The response to the "tcpip-forward" request will look like: > > byte SSH_MSG_GLOBAL_REQUEST_SUCCESS > string "tcpip-forward" > uint32 port that was bound on server > > We should also explicitly allow binding to port > 0 to indicate any port. I agree this is a good idea. Although I think that for backwards compatibility we should either (i) say that the port field is included *only* when binding port 0, or (ii) use a new request type /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 11:54:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15698 for ; Wed, 8 Aug 2001 11:54:24 -0400 (EDT) Received: (qmail 24599 invoked by uid 605); 8 Aug 2001 15:51:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24592 invoked from network); 8 Aug 2001 15:51:14 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Aug 2001 15:51:14 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 140461; Wed, 08 Aug 2001 09:54:34 -0600 Message-ID: <06bf01c12022$a6cf1290$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: =?iso-8859-1?Q?Niels_M=F6ller?= Cc: References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> Subject: Re: global and channel requests -- more information on failure, more flexibility on success Date: Wed, 8 Aug 2001 16:56:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Yes, I think I've been mostly talked around -- see my email "New requests to support binding port 0" for a new proposal that is completely backwards compatible -- there is no change in the response protocols for currently defined requests. But, it does make it legal for new requests to define responses that carry additional, request- specific information. (And defines a couple of new requests that use both new response and new failure protocols.) Thanks for your comments. Please read the new proposal and let me know what you think of it. - Joseph ----- Original Message ----- From: "Niels Möller" To: "Joseph Galbraith" Cc: Sent: Wednesday, August 08, 2001 1:31 PM Subject: Re: global and channel requests -- more information on failure, more flexibility on success > "Joseph Galbraith" writes: > > > Regarding global and channel requests... I believe more > > information on failure and more flexibility on success > > is needed. > > Why? I believe global requests should always be answered in order, and > channel_requests on the same channel should also be answered in order. > This is analogous to the requirements for userauth-requests, which I > think are spelled out more clearly in the documents. > > If you really want to be able to permute responses, you should add a > an id to each request, but I don't think that is really needed. Adding > just the request-name to the responses seems useless. > > > - In the connection draft, section 2, we should change > > > > byte SSH_MSG_REQUEST_SUCCESS > > > > to > > > > byte SSH_MSG_REQUEST_SUCCESS > > string request-name > > ... request-specific data follows > > I don't think adding the request name here is terribly useful. As for > request specific data, that might be useful, but we don't need to do > anything about that now. > > The day I invent a request where it makes sense to have additional > data, I'll add it. Implementations that don't know about the new > request will never see the extended response packet, because they > never send the new request. > > > If existing implementations won't safely ignore the extra > > packet data, we should change the packet number and > > deprecate the existing one. > > Datapoint: LSH generally do *not* allow extra data on random packets, > and will generally treat that as a fatal protocol error. > > > - In the connection draft, section 2, we should change > > > > byte SSH_MSG_REQUEST_FAILURE > > > > > > to > > > > byte SSH_MSG_REQUEST_FAILURE > > string request-name > > uint32 reason > > string additional text (UTF-8) > > string language > > That makes more sense (although the request-name is still redundant, > under the assumption that requests are still answered in order). > > > I think existing implementations should simply ignore the > > extra data. If not, we should give this code a new value, > > i.e., SSH_MSG_REQUEST_FAILURE2, and deprecate the old > > message. > > You can't do that, what you can do is add new _request_ messages. > > > - If global requests are issued asynchronously (is this allowed?) > > are there any guarantees for order of completion? Do we need > > to be able to tag requests? > > I think the only reasonable thing is to require that responses are > sent in the right order (requests on different channels can be > answered in any order, though). > > Summary: I disagree with you're proposed changes, except for adding > some more information to failure messages. > > Resonses should be sent in the right where "right order" is defined in > my first paragraph. > > It's too late to replace "reply-in-order" with > "add-id-to-all-requests", and I think reply-in-order is adequate. > > Regards, > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 11:56:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15770 for ; Wed, 8 Aug 2001 11:56:52 -0400 (EDT) Received: (qmail 25017 invoked by uid 605); 8 Aug 2001 15:53:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25008 invoked from network); 8 Aug 2001 15:53:43 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Aug 2001 15:53:43 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 140478 for ietf-ssh@netbsd.org; Wed, 08 Aug 2001 09:57:03 -0600 Message-ID: <06d301c12022$ff75ed60$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: Subject: Fw: Other misc things in the drafts Date: Wed, 8 Aug 2001 16:58:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Whoopss... I meant for this to do to the list as well. - Joseph ----- Original Message ----- From: "Joseph Galbraith" To: "Niels Möller" Sent: Wednesday, August 08, 2001 4:57 PM Subject: Re: Other misc things in the drafts > > > - In the connection draft, section 4.3.1, we should note > > > that the x11 authentication cookie MUST be hexadecimal > > > encoded. > > > > Why? Is that what people are doing (I haven't implemented x11 > > forwarding yet). It seems very strange to me to use a redundant but > > ascii-friendly encoding for things in the binary very eight-bit clean > > ssh protocols. > > Yes -- it is current practice. I agree it is gross -- I believe > it is done this way because the string is passed directly to > the xauth program, but I'm not sure. > > > > - In the connection draft, section 5.1, we should specify > > > text like this: > > > > > > The response to the "tcpip-forward" request will look like: > > > > > > byte SSH_MSG_GLOBAL_REQUEST_SUCCESS > > > string "tcpip-forward" > > > uint32 port that was bound on server > > > > > > We should also explicitly allow binding to port > > > 0 to indicate any port. > > > > I agree this is a good idea. Although I think that for backwards > > compatibility we should either > > > > (i) say that the port field is included *only* when binding port 0, > > or > > (ii) use a new request type > > Again, take a look at the new proposal which is fully > back-wards compatible. > > Thanks, > > Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 12:31:41 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16493 for ; Wed, 8 Aug 2001 12:31:40 -0400 (EDT) Received: (qmail 4769 invoked by uid 605); 8 Aug 2001 16:28:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4762 invoked from network); 8 Aug 2001 16:28:29 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Aug 2001 16:28:29 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 1E91782F702; Wed, 8 Aug 2001 18:32:39 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id SAA17820; Wed, 8 Aug 2001 18:32:38 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: global and channel requests -- more information on failure, more flexibility on success References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> <06bf01c12022$a6cf1290$0d8a21d9@sidewinder> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 08 Aug 2001 18:32:38 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Wed, 8 Aug 2001 16:56:12 +0100" Message-ID: Lines: 96 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > Yes, I think I've been mostly talked around -- > see my email > > "New requests to support binding port 0" > > for a new proposal that is completely backwards > compatible -- there is no change in the response > protocols for currently defined requests. I was replying to mail in order... Now I have read your more recent proposals. * Ordering for channel requests: 3.4.1 Multiple requests and ordering The client is allowed to send further messages without waiting for the response to the request. The recipient must respond to messages in the order received so that responses can be matched to requests. Requests on separate channels should be independent, with no ordering constraints. Is that obvious, or should the spec say that explicitly? * The two forms of failure messages: byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel ...request specific data and byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel uint32 reason string descriptive-text [UTF8] string language ... further request-specific data follows It seems odd to refer to the three optional fields as "request specific", when they are in fact required to be the same for all requests. These two forms seems a little awkward, but I'm not sure what is the best way to deal with it. I'm not terribly concerned about backwards compatibility here, if the new fields are really needed, I'd prefer to abandon the first shorter form completely. If you need to have an old version talking to a new server, you can still get them to interoperate by simply disabling all features that result in a SSH_MSG_CHANNEL_FAILURE, so I think it may work well to skip the backwards-compatibility complexity in this case. But perhaps I'm naive. The same reasoning applies to SSH_MSG_FAILURE. * The new tcpip-bind requests: byte SSH_MSG_GLOBAL_REQUEST string "tcpip-bind" boolean want reply string address to bind (e.g. "0.0.0.0") uint32 port number to bind 'Address to bind' and 'port number to bind' specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. I'd prefer to change the last sentence to The address should be "" if connections are allowed from anywhere. That means, listen on all interfaces, be they ipv4 or ipv6. "0.0.0.0" and "::" can also be used, but they would be needed only in special circumstances. (I'd also like to be allowed to use dns names everywhere in the protocol, but that's an extension that it's simple to make later.It might also be nice to have a defined way to say "listen on localhost only, no matter if ipv4 or ipv6 is used". Perhaps the string "localhost" could be used for that). * And finally, I feel a little uneasy about creating new request types for all this. Do we need that much backwards compatibility? As far as I see, the cases that matters at all from a backwards-compatibility point of view are (i) failure cases (see above), and (ii) binding port 0, which is something that no old client should try, and which an old server should simply refuse. So do we really need to create new request types? Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 17:40:51 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22034 for ; Wed, 8 Aug 2001 17:40:50 -0400 (EDT) Received: (qmail 29962 invoked by uid 605); 8 Aug 2001 21:37:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29955 invoked from network); 8 Aug 2001 21:37:37 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Aug 2001 21:37:37 -0000 Received: from [127.0.0.1] (HELO sidewinder) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 140991; Wed, 08 Aug 2001 15:40:58 -0600 Message-ID: <07e001c12053$0b070b70$0d8a21d9@sidewinder> From: "Joseph Galbraith" To: =?iso-8859-1?Q?Niels_M=F6ller?= , References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> <06bf01c12022$a6cf1290$0d8a21d9@sidewinder> Subject: Re: global and channel requests -- more information on failure, more flexibility on success Date: Wed, 8 Aug 2001 22:42:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2479.0006 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2479.0006 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > These two forms seems a little awkward, but I'm not sure what is the > best way to deal with it. I'm not terribly concerned about backwards > compatibility here, if the new fields are really needed, I'd prefer to > abandon the first shorter form completely. If you need to have an old > version talking to a new server, you can still get them to > interoperate by simply disabling all features that result in a > SSH_MSG_CHANNEL_FAILURE, so I think it may work well to skip the > backwards-compatibility complexity in this case. But perhaps I'm > naive. Actually, old client to new server would be the worst, because the client sends a whole bunch of requests (pty, shell, subsystem, agent, etc.) and if any of them failed, the client would notice too much data in the response and report a protocol error. Imagine an SFTP client -- you can't really disable subsystem requests, which might generate failures. I'd be willing to rework the wording a little and see if we can't get the idea expressed a little less awkwardly. For example, something along the lines of "unless otherwise specified, a request uses the basic version of the response messages. New requests SHOULD use the extended version of the failure message which is defines as follows ... " Would that make you happier? > * The new tcpip-bind requests: > > byte SSH_MSG_GLOBAL_REQUEST > string "tcpip-bind" > boolean want reply > string address to bind (e.g. "0.0.0.0") > uint32 port number to bind > > 'Address to bind' and 'port number to bind' specify the IP address > and port to which the socket to be listened is bound. The address > should be "0.0.0.0" if connections are allowed from anywhere. > > I'd prefer to change the last sentence to > > The address should be "" if connections are allowed from > anywhere. I like that -- we talked about several possiblities for this during the working group meeting, but that one wasn't mentioned -- I like it better then anything that was. What do other people think about this? > * And finally, I feel a little uneasy about creating new request types > for all this. > > Do we need that much backwards compatibility? As far as I see, the > cases that matters at all from a backwards-compatibility point of view > are (i) failure cases (see above), and (ii) binding port 0, which is > something that no old client should try, and which an old server > should simply refuse. > > So do we really need to create new request types? Well, that was what the consensus at the meeting -- I think just doing something different in the case of zero came up, and was felt to be a little ugly. I actually I think the new messages are for the best, since the old drafts didn't actually disallow binding to port 0 (even if it wasn't specifically allowed either.) SecureCRT probably doesn't check to make the port isn't zero -- and there might be other clients out there that would allow it to happen if the user requested it. Also, do old servers actually refuse, or does it succeed -- I'd bet succeed -- but I don't have easy access right now to test -- but it seems like I tested this once. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 8 17:49:25 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22171 for ; Wed, 8 Aug 2001 17:49:25 -0400 (EDT) Received: (qmail 2973 invoked by uid 605); 8 Aug 2001 21:46:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2966 invoked from network); 8 Aug 2001 21:46:15 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 8 Aug 2001 21:46:15 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11480; Wed, 8 Aug 2001 15:50:14 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.36]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA01867; Wed, 8 Aug 2001 14:52:18 -0700 (PDT) Received: from spica1 (spica1.Eng.Sun.COM [129.146.81.114]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78LnoB343675; Wed, 8 Aug 2001 14:49:50 -0700 (PDT) Date: Wed, 8 Aug 2001 14:47:21 -0700 (PDT) From: Alok Aggarwal X-X-Sender: To: Joseph Galbraith cc: =?iso-8859-1?Q?Niels_M=F6ller?= , Subject: Re: global and channel requests -- more information on failure, more flexibility on success In-Reply-To: <07e001c12053$0b070b70$0d8a21d9@sidewinder> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > > * The new tcpip-bind requests: > > > > byte SSH_MSG_GLOBAL_REQUEST > > string "tcpip-bind" > > boolean want reply > > string address to bind (e.g. "0.0.0.0") > > uint32 port number to bind > > > > 'Address to bind' and 'port number to bind' specify the IP address > > and port to which the socket to be listened is bound. The address > > should be "0.0.0.0" if connections are allowed from anywhere. > > > > I'd prefer to change the last sentence to > > > > The address should be "" if connections are allowed from > > anywhere. > > I like that -- we talked about several possiblities > for this during the working group meeting, but that one wasn't > mentioned -- I like it better then anything that was. > > What do other people think about this? It seems to solve the problem. Also, the ability to send "localhost" as string incase the client wants the server to listen on localhost, seems like a good idea (it makes the draft complete too). I think it's useful to make this modification in the draft. -Alok From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Aug 9 06:15:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19868 for ; Thu, 9 Aug 2001 06:15:21 -0400 (EDT) Received: (qmail 3301 invoked by uid 605); 9 Aug 2001 10:12:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3294 invoked from network); 9 Aug 2001 10:12:09 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 9 Aug 2001 10:12:09 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B928882F6E6; Thu, 9 Aug 2001 12:16:20 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id MAA08563; Thu, 9 Aug 2001 12:16:20 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: global and channel requests -- more information on failure, more flexibility on success References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> <06bf01c12022$a6cf1290$0d8a21d9@sidewinder> <07e001c12053$0b070b70$0d8a21d9@sidewinder> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 09 Aug 2001 12:16:20 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Wed, 8 Aug 2001 22:42:36 +0100" Message-ID: Lines: 11 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > I actually I think the new messages are for the best, > since the old drafts didn't actually disallow binding > to port 0 (even if it wasn't specifically allowed either.) A datapoint: lshd checks that the port is larger than 1024. I don't know what other servers do. The reason lshd does that is that it usually runs as root at the time it binds the port. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Aug 9 18:53:26 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06888 for ; Thu, 9 Aug 2001 18:53:26 -0400 (EDT) Received: (qmail 24192 invoked by uid 605); 9 Aug 2001 22:50:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24185 invoked from network); 9 Aug 2001 22:50:11 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 9 Aug 2001 22:50:11 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27402 for ; Thu, 9 Aug 2001 15:54:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id PAA13757 for ; Thu, 9 Aug 2001 15:56:30 -0700 (PDT) Received: from braveheart (portellen.Eng.Sun.COM [129.146.81.129]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f79MsLB718759 for ; Thu, 9 Aug 2001 15:54:21 -0700 (PDT) Message-Id: <200108092254.f79MsLB718759@jurassic.eng.sun.com> Date: Thu, 9 Aug 2001 15:53:03 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: draft-ietf-secsh-dh-group-exchange-01.txt To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +eFNoRJnnNZfesvJJ0uqrA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_41 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list In Section 7 of the dh-group-exchange draft there is an attempt to address backwards compatibility with the previous version of the draft by renumbering the SSH_MSG_KEX_DH_GEX_REQUEST message. This really only addresses backwards compatibility for an old client connecting to a new server but not a new client connecting to an old server. Looking at the current OpenSSH sources it seems this problem was known since there is code to match against the peer's version number to choose which of SSH_MSG_KEX_DH_GEX_REQUEST or SSH_MSG_KEX_DH_GEX_REQUEST_OLD to send. Matching against the peer's version number to try and work out which version of a particlar draft they implemented doesn't seem like a good idea. However anyone implementing this draft now will get the correct behaviour, the only issue is with servers that implemented -00 but aren't known to the OpenSSH compat "magic" compat code. The only thing I can suggest for the draft at the moment is to make it clear that the compatibility is only in one direction. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Aug 11 07:03:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05533 for ; Sat, 11 Aug 2001 07:03:36 -0400 (EDT) Received: (qmail 23052 invoked by uid 605); 11 Aug 2001 11:00:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23045 invoked from network); 11 Aug 2001 11:00:18 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Aug 2001 11:00:18 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 40B1582F70C; Sat, 11 Aug 2001 13:04:34 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA04351; Sat, 11 Aug 2001 13:04:33 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: global and channel requests -- more information on failure, more flexibility on success References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <00e701c11c5c$272acd50$2800a8c0@test.vandyke.com> <06bf01c12022$a6cf1290$0d8a21d9@sidewinder> <07e001c12053$0b070b70$0d8a21d9@sidewinder> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 11 Aug 2001 13:04:33 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Wed, 8 Aug 2001 22:42:36 +0100" Message-ID: Lines: 139 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > Actually, old client to new server would be the worst, > because the client sends a whole bunch of requests > (pty, shell, subsystem, agent, etc.) and if any of > them failed, the client would notice too much data > in the response and report a protocol error. This is the most problematic case, I guess. If for instance agent forwarding is denied, the user would have to use some --no-agent-forward option. But to be precise exactl which are the requests that are sent by default and which will reasonably fail? pty and agent forwarding are in that class (and I think they are used mostly in interactive mode, not when scripting ssh). shell and subsystem isn't in that class IMO: The typical use is to send only one of them, and if it fails, there's not much point going on anyway. I don't think it is a big problem if the user can sometimes get a message "protocol error..." rather than "the request you really needed to send failed". > Imagine an SFTP client -- you can't really disable > subsystem requests, which might generate failures. I don't think this case is no real problem. If the client wants to start sftp, and the server doesn't let it, the client will fail in one way or the other. It doesn't matter too much in which way. > For example, something along > the lines of "unless otherwise specified, a request > uses the basic version of the response messages. New > requests SHOULD use the extended version of the failure > message which is defines as follows ... " The below is your proposal (I hope I found the latest one): : byte SSH_MSG_CHANNEL_FAILURE : uint32 recipient_channel : ...request specific data : : These messages do not consume window space and can be sent even if : no window space is available. : : Unless otherwise specified, a request uses the general form : of these messages, with no request specific failure or success : data. : : If the recipient doesn't recognize the request, it : will send a SSH_MSG_CHANNEL_FAILURE without any : request specific data. This is called the generic : form. : : Requests that do send information during failure MUST : use the following format: : : byte SSH_MSG_CHANNEL_FAILURE : uint32 recipient_channel : uint32 reason : string descriptive-text [UTF8] : string language : ... further request-specific data follows : : New requests SHOULD use this extended failure message : in order to provide end users and server administrators : with information about a failure. I think I'd prefer something like byte SSH_MSG_CHANNEL_FAILURE uint32 recipient_channel uint32 reason string descriptive-text [UTF8] string language ... request-specific data follows These messages do not consume window space and can be sent even if no window space is available. For backwards compatibility, a shorter form is sometimes used, byte SSH_MSG_CHANNEL_FAILURE If a certain request REQUIRES the shorter form is described together with that request. That is mostly a wording change. I'd be happier to say that the shorter form MAY be used for backwards compatibility, but that the longer canonical form is always allowed. [ about the new tcpip forwarding request types ] > I actually I think the new messages are for the best, > since the old drafts didn't actually disallow binding > to port 0 (even if it wasn't specifically allowed either.) It will add a significant amount of complexity to clients to say that they should first try the new request, then fall back to the old ones (on the server side, it's easier to support one or both at the same time). I wouldn't do that in my client; I'd probably just use the good old tcpip-forwarding request, except when the user wants to bind port zero, in which case I'd use the new one. To me, that indicates that the idea of having two parallell request types with overlapping functionality is bad design. If there are two ways to do the same thing, it is likely that one of the ways will be the one used in practice, while the other one must still be there for conformance. The implementation of the "unusual way" of doing things will attract bugs, which may even break security. It would be better to either Extend the existing tcpip-forward, saying that binding port 0 is allowed, and that it will result in a special success message. This is the solution that I would prefer. Or invent a new request type for the _sole_ purpose of binding port 0. I think both these alternatives are backwards compatible (I don't think we have any obligation to support existing clients that use tcpip-forward to bind port 0 and expects any particular behaviour). I also feel that those changes can be made easily at any time, so I don't think we need to do anything with the core specs in this regard except perhaps to point out that they don't define the bahaviour of tcpip-forward when binding port 0. > SecureCRT probably doesn't check to make the port isn't > zero -- and there might be other clients out there that > would allow it to happen if the user requested it. > > Also, do old servers actually refuse, or does it succeed -- > I'd bet succeed -- but I don't have easy access right now > to test -- but it seems like I tested this once. I don't think any of that is behaviour that any server, client or user should use or depend on. Do you know of any real world usage? Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 13 10:12:21 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20687 for ; Mon, 13 Aug 2001 10:12:20 -0400 (EDT) Received: (qmail 8183 invoked by uid 605); 13 Aug 2001 14:09:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8176 invoked from network); 13 Aug 2001 14:09:04 -0000 Received: from mx3.sac.fedex.com (199.81.208.11) by mail.netbsd.org with SMTP; 13 Aug 2001 14:09:04 -0000 Received: from mx6.sac.fedex.com (sendmail@mx6.sac.fedex.com [199.82.159.10]) by mx3.sac.fedex.com (8.9.3/8.9.3) with ESMTP id JAA69262 for ; Mon, 13 Aug 2001 09:13:16 -0500 (CDT) (envelope-from ksb@g09.sac.fedex.com) Received: from g09.sac.fedex.com (root@g09.sac.fedex.com [199.81.124.181]) by mx6.sac.fedex.com (8.9.3/8.9.3) with ESMTP id JAA50891 for ; Mon, 13 Aug 2001 09:13:15 -0500 (CDT) (envelope-from ksb@g09.sac.fedex.com) Received: from g09.sac.fedex.com (ksb@localhost [127.0.0.1]) by g09.sac.fedex.com (8.9.3/8.9.3) with ESMTP id JAA65735; Mon, 13 Aug 2001 09:13:14 -0500 (CDT) (envelope-from ksb@g09.sac.fedex.com) Message-Id: <200108131413.JAA65735@g09.sac.fedex.com> To: Niels M ller cc: ietf-ssh@netbsd.org Subject: Re: global and channel requests -- more information on failure, more flexibility on success In-Reply-To: Your message of "09 Aug 2001 12:16:20 +0200." Date: Mon, 13 Aug 2001 09:13:13 -0500 From: K S Braunsdorf Sender: ietf-ssh-owner@netbsd.org Precedence: list >A datapoint: lshd checks that the port is larger than 1024. I don't know >what other servers do. The reason lshd does that is that it usually >runs as root at the time it binds the port. Well that brings up the issue of privileged ports. There are really a few cases the client might ask for: "give me any (unprivileged) port" "give me an explicit port numbered P" "give me a privileged port" We have 2 of those covered, 0 -> any unprivileged port P -> P But nothing in the requests I've seen allows "any privileged port", or am I behind the times? The obvious (work around) implementation is to scan all the privileged ports with requests -- really yucky, and we don't really know the rules for "privileged ports" on a remote system. -- ksb From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 13 11:28:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22090 for ; Mon, 13 Aug 2001 11:28:48 -0400 (EDT) Received: (qmail 22191 invoked by uid 605); 13 Aug 2001 15:25:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22180 invoked from network); 13 Aug 2001 15:25:33 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 13 Aug 2001 15:25:33 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 1861582F386; Mon, 13 Aug 2001 17:29:50 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id RAA06542; Mon, 13 Aug 2001 17:29:49 +0200 (MET DST) To: K S Braunsdorf Cc: ietf-ssh@netbsd.org Subject: Re: global and channel requests -- more information on failure, more flexibility on success References: <200108131413.JAA65735@g09.sac.fedex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 13 Aug 2001 17:29:49 +0200 In-Reply-To: K S Braunsdorf's message of "Mon, 13 Aug 2001 09:13:13 -0500" Message-ID: Lines: 42 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit K S Braunsdorf writes: > Well that brings up the issue of privileged ports. There are really > a few cases the client might ask for: > "give me any (unprivileged) port" > "give me an explicit port numbered P" > "give me a privileged port" > > We have 2 of those covered, > 0 -> any unprivileged port > P -> P > > But nothing in the requests I've seen allows "any privileged port", > or am I behind the times? Well, such a request could be allowed only if the client session is authenticated as root (or else, the ports are in effect not privileged anymore ;-). As it doesn't apply to ordinary user sessions, I don't think such a feature would be terribly important. > The obvious (work around) implementation is to scan all the > privileged ports with requests -- really yucky, The operation "give me a privileged port" is yucky, even if you could do it with a single ssh request. The server would have to try binding ports until it succeeds. > and we don't really know the rules for "privileged ports" on a remote > system. I think "privileged ports" is a somewhat broken concept anyway, but it isn't relative. The whole point of binding an unspecified privileged port is to be able to convince remote peers that you are indeed "privileged" in some way. Like with the .rhosts hack. This test is based on the portnumber only. So the port range is the same on all hosts, only the meaning of "privileged" varies. Bottom line: I don't think a request for binding "any privileged port" is very useful. Do you have any scenario where you'd like to use it? Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Aug 18 06:01:07 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10395 for ; Sat, 18 Aug 2001 06:01:06 -0400 (EDT) Received: (qmail 24498 invoked by uid 605); 18 Aug 2001 09:57:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24491 invoked from network); 18 Aug 2001 09:57:43 -0000 Received: from dfw-smtpout2.email.verio.net (129.250.36.42) by mail.netbsd.org with SMTP; 18 Aug 2001 09:57:43 -0000 Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15Y2vm-0006J6-00; Sat, 18 Aug 2001 10:02:14 +0000 Received: from [63.184.75.161] (helo=localhost) by dfw-mmp3.email.verio.net with esmtp id 15Y2vj-0004ff-00; Sat, 18 Aug 2001 10:02:11 +0000 X-Sender: robertlong@veriomail.com From: Bob Long To: "Mortgage Rate Info" Date: Sat, 18 Aug 2001 03:08:18 -0700 Subject: Need a Home Loan? We Can Help!! Reply-To: robertlong@veriomail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__21862366_11298.66" Message-Id: Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a Multipart MIME message. ------=_NextPart_000_001__21862366_11298.66 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__21862366_11298.66 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9 IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249 Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+ TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8 UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90 O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+ PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48 U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+ PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+ PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42 Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+ PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250 PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48 Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+ PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+ YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50 byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4 MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48 Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48 L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+ PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0 PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP TlQ+PC9QPjwvQk9EWT48L0hUTUw+ ------=_NextPart_000_001__21862366_11298.66-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Aug 20 15:27:52 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01033 for ; Mon, 20 Aug 2001 15:27:51 -0400 (EDT) Received: (qmail 17234 invoked by uid 605); 20 Aug 2001 19:24:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17227 invoked from network); 20 Aug 2001 19:24:22 -0000 Received: from dfw-smtpout2.email.verio.net (129.250.36.42) by mail.netbsd.org with SMTP; 20 Aug 2001 19:24:22 -0000 Received: from [129.250.38.61] (helo=dfw-mmp1.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 15Yuic-0000aD-00; Mon, 20 Aug 2001 19:28:14 +0000 Received: from [63.184.76.132] (helo=localhost) by dfw-mmp1.email.verio.net with esmtp id 15YuiL-00031A-00; Mon, 20 Aug 2001 19:27:57 +0000 X-Sender: roblong@veriomail.com From: Rob Long To: "Mortgage Rate Info" Date: Mon, 20 Aug 2001 12:34:12 -0700 Subject: Need a Home Loan? We Can Help!! Reply-To: roblong@veriomail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__11055252_45252.12" Message-Id: Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a Multipart MIME message. ------=_NextPart_000_001__11055252_45252.12 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__11055252_45252.12 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9 IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249 Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+ TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8 UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90 O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+ PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+ PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48 U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+ PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+ PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42 Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+ PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250 PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48 Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+ PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+ YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50 byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4 MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48 Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48 L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9 Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+ PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0 PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP TlQ+PC9QPjwvQk9EWT48L0hUTUw+ ------=_NextPart_000_001__11055252_45252.12-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 21 07:09:37 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04295 for ; Tue, 21 Aug 2001 07:09:36 -0400 (EDT) Received: (qmail 105 invoked by uid 605); 21 Aug 2001 11:06:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29997 invoked from network); 21 Aug 2001 11:06:08 -0000 Received: from unknown (HELO rafi) (213.8.76.34) by mail.netbsd.org with SMTP; 21 Aug 2001 11:06:08 -0000 Received: from mail pickup service by rafi with Microsoft SMTPSVC; Tue, 21 Aug 2001 14:11:05 +0200 From: To: Subject: Instant Messaging platform at your Web site is now a few clicks away Date: Tue, 21 Aug 2001 14:11:05 +0200 Message-ID: <10f901c12a3a$5a094030$0200a8c0@rafi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcEqOloJm3D5hsWiTSyyj8gwFjaU/g== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Aug 2001 12:11:05.0121 (UTC) FILETIME=[5A1A0910:01C12A3A] Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04295 Instant Messaging platform at your Web site is now a few clicks away ---------------------------------------------------------------------- Install a FREE Instant Messaging server at your Web site. Use it as is or customize to meet your specific branding. Cross platform servers line support 25 and up to 1000 concurrent users All servers offered can be secured with RSA 512Bit (and higher) encryption!! Download free 10 concurrent users server at: http://www.seebex.com/download/get_server.asp It is easier, faster and affordable than ever!! For further information please check seebex Web site at: http://www.seebex.com or contact our Marketing & Sales department at sales@seebex.com First 50 Web sites to download and embed the free 10 concurrent users server are entitled to a free 100 concurrent users server and will be listed on Seebex Web site. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 22 12:06:13 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14925 for ; Wed, 22 Aug 2001 12:06:12 -0400 (EDT) Received: (qmail 11199 invoked by uid 605); 22 Aug 2001 16:02:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11192 invoked from network); 22 Aug 2001 16:02:43 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 22 Aug 2001 16:02:43 -0000 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 9D228207C1; Wed, 22 Aug 2001 12:07:23 -0400 (EDT) Subject: Re: draft-ietf-secsh-dh-group-exchange-01.txt To: Darren Moffat Cc: ietf-ssh@netbsd.org From: Niels Provos In-Reply-To: Darren Moffat, Thu, 09 Aug 2001 15:53:03 PDT Date: Wed, 22 Aug 2001 12:07:23 -0400 Message-Id: <20010822160723.9D228207C1@citi.umich.edu> Sender: ietf-ssh-owner@netbsd.org Precedence: list In message <200108092254.f79MsLB718759@jurassic.eng.sun.com>, Darren Moffat wri tes: >Matching against the peer's version number to try and work out which >version of a particlar draft they implemented doesn't seem like a good idea. Thats who incompatibilities for all the other drafts have been handled, too. Look at the code, you will be surprised. >The only thing I can suggest for the draft at the moment is to make it >clear that the compatibility is only in one direction. I can add some wording mentioning that. Greetings, Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 22 19:37:50 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26386 for ; Wed, 22 Aug 2001 19:37:50 -0400 (EDT) Received: (qmail 19959 invoked by uid 605); 22 Aug 2001 23:34:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19952 invoked from network); 22 Aug 2001 23:34:20 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 22 Aug 2001 23:34:20 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f7MNcxf23684 for ; Thu, 23 Aug 2001 02:38:59 +0300 (EEST) Received: (qmail 29500 invoked from network); 22 Aug 2001 23:38:59 -0000 Received: from unknown (HELO johto.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Aug 2001 23:38:59 -0000 Received: (from sjl@localhost) by johto.hel.fi.ssh.com (8.9.3/8.9.3) id CAA26225; Thu, 23 Aug 2001 02:39:41 +0300 To: ietf-ssh@netbsd.org Subject: Re: draft-ietf-secsh-dh-group-exchange-01.txt References: <20010822160723.9D228207C1@citi.umich.edu> From: sjl@ssh.com (Sami J. Lehtinen) Date: 23 Aug 2001 02:39:41 +0300 In-Reply-To: provos@citi.umich.edu's message of "Wed, 22 Aug 2001 16:07:35 +0000 (UTC)" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Canyonlands" Sender: ietf-ssh-owner@netbsd.org Precedence: list provos@citi.umich.edu (Niels Provos) writes: > In message <200108092254.f79MsLB718759@jurassic.eng.sun.com>, Darren Moffat wri > tes: > >Matching against the peer's version number to try and work out which > >version of a particlar draft they implemented doesn't seem like a good idea. > Thats who incompatibilities for all the other drafts have been handled, too. > Look at the code, you will be surprised. Yes, but for example in our software it is mostly done against our own versions. And that is ugly enough. There are many vendors already, and there is no guarantee that the application version string stays in the same format from version to version. I don't know of a better way however; changing request names is ugly too, perhaps even more so. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Aug 22 19:46:18 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26523 for ; Wed, 22 Aug 2001 19:46:17 -0400 (EDT) Received: (qmail 22644 invoked by uid 605); 22 Aug 2001 23:42:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22635 invoked from network); 22 Aug 2001 23:42:48 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Aug 2001 23:42:48 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27057; Wed, 22 Aug 2001 17:47:21 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.36]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id QAA07366; Wed, 22 Aug 2001 16:47:30 -0700 (PDT) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.11.6+Sun/8.11.6) with SMTP id f7MNlIH366042; Wed, 22 Aug 2001 16:47:18 -0700 (PDT) Message-Id: <200108222347.f7MNlIH366042@jurassic.eng.sun.com> Date: Wed, 22 Aug 2001 16:46:37 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: draft-ietf-secsh-dh-group-exchange-01.txt To: ietf-ssh@netbsd.org, sjl@ssh.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2I1M4UauKmlABw/eCQeZvA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >provos@citi.umich.edu (Niels Provos) writes: > >> In message <200108092254.f79MsLB718759@jurassic.eng.sun.com>, Darren Moffat wri >> tes: >> >Matching against the peer's version number to try and work out which >> >version of a particlar draft they implemented doesn't seem like a good idea. >> Thats who incompatibilities for all the other drafts have been handled, too. >> Look at the code, you will be surprised. > >Yes, but for example in our software it is mostly done against our own >versions. And that is ugly enough. There are many vendors already, and >there is no guarantee that the application version string stays in the >same format from version to version. > >I don't know of a better way however; changing request names is ugly >too, perhaps even more so. This is just one of the ugly things you have to do to deal with a protocol that hasn't been standardized. If the protocol had become and RFC already and then stuff had changed the easiest way would just be to rev the protocol version number. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Aug 23 03:24:40 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19755 for ; Thu, 23 Aug 2001 03:24:40 -0400 (EDT) Received: (qmail 18688 invoked by uid 605); 23 Aug 2001 07:21:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18681 invoked from network); 23 Aug 2001 07:21:10 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 23 Aug 2001 07:21:10 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA19215; Thu, 23 Aug 2001 09:25:47 +0200 (MET DST) Date: Thu, 23 Aug 2001 09:25:47 +0200 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org, sjl@ssh.com Subject: Re: draft-ietf-secsh-dh-group-exchange-01.txt Message-ID: <20010823092547.B18952@faui02.informatik.uni-erlangen.de> References: <200108222347.f7MNlIH366042@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200108222347.f7MNlIH366042@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Aug 22, 2001 at 04:46:37PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Aug 22, 2001 at 04:46:37PM -0700, Darren Moffat wrote: > >provos@citi.umich.edu (Niels Provos) writes: > > > >> In message <200108092254.f79MsLB718759@jurassic.eng.sun.com>, Darren Moffat > wri > >> tes: > >> >Matching against the peer's version number to try and work out which > >> >version of a particlar draft they implemented doesn't seem like a good > idea. > >> Thats who incompatibilities for all the other drafts have been handled, > too. > >> Look at the code, you will be surprised. > > > >Yes, but for example in our software it is mostly done against our own > >versions. And that is ugly enough. There are many vendors already, and > >there is no guarantee that the application version string stays in the > >same format from version to version. > > > >I don't know of a better way however; changing request names is ugly > >too, perhaps even more so. > > This is just one of the ugly things you have to do to deal with a > protocol that hasn't been standardized. If the protocol had become and > RFC already and then stuff had changed the easiest way would just be > to rev the protocol version number. yes, but i don't think it's a big deal, since not many people did implement the old version of the draft. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Aug 23 23:48:39 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08470 for ; Thu, 23 Aug 2001 23:48:39 -0400 (EDT) Received: (qmail 714 invoked by uid 605); 24 Aug 2001 03:45:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 706 invoked from network); 24 Aug 2001 03:45:10 -0000 Received: from mailhub.dartmouth.edu (129.170.16.6) by mail.netbsd.org with SMTP; 24 Aug 2001 03:45:10 -0000 Received: from vixen.Dartmouth.EDU (vixen.dartmouth.edu [129.170.208.15]) by mailhub.Dartmouth.EDU (8.9.3+DND/8.9.3) with ESMTP id XAA08387 for ; Thu, 23 Aug 2001 23:49:49 -0400 (EDT) Message-id: <48534279@vixen.Dartmouth.EDU> Date: 23 Aug 2001 23:49:49 EDT From: Yasir.Ali@Dartmouth.EDU (Yasir Ali) Subject: research guidance To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: text/plain Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi all, I have been focusing on embedding the certificate infrastructure with the SSH protocol, so as to ensure the integrity and primarily to avoid the man-in-the-middle attack. There are various design aspects that come into play for a secure, manageable and deployable Public Key Infrastructure using certificates that can be used with the SSH protocol. There was a recent draft "Storing SSH Host Keys in DNS" that addressed this issue. I am interested in learning the different approaches that are being developed to use certificates with SSH. Is there currently research/coding being done to modify OpenSSH source to bring in certificates that you are aware of. Are there any other approaches adressing this issue, that are bieng developed. I would also appreciate if you can update me with any recent work on this topic and the direction where most of the research focus is within this. With best regards, Yasir Ali From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 10:25:54 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11297 for ; Tue, 28 Aug 2001 10:25:54 -0400 (EDT) Received: (qmail 11127 invoked by uid 605); 28 Aug 2001 14:22:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11118 invoked from network); 28 Aug 2001 14:22:15 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 28 Aug 2001 14:22:15 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 0C8945283 for ; Tue, 28 Aug 2001 16:27:08 +0200 (MEST) Received: from fonbella.crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id D98181DE9 for ; Tue, 28 Aug 2001 16:27:07 +0200 (MEST) Date: Tue, 28 Aug 2001 16:27:07 +0200 (MEST) From: Jakob Schlyter To: SecSH WG Subject: reauthentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list hi, has anyone considered adding reauthentication support for ssh? I like the server to request that the client reauthenticates from time to time. this could be very useful for some authentication methods, e.g. smartcard, where the authentication process requires a physical device to be attached to the client - if the device is removed, the connection could be terminated. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 15:44:30 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19851 for ; Tue, 28 Aug 2001 15:44:29 -0400 (EDT) Received: (qmail 27646 invoked by uid 605); 28 Aug 2001 19:40:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27639 invoked from network); 28 Aug 2001 19:40:50 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 28 Aug 2001 19:40:50 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28562; Tue, 28 Aug 2001 13:45:31 -0600 (MDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA06411; Tue, 28 Aug 2001 12:45:40 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SJjOLJ347292; Tue, 28 Aug 2001 12:45:24 -0700 (PDT) Date: Tue, 28 Aug 2001 12:43:58 -0700 (PDT) From: Darren J Moffat To: Jakob Schlyter cc: SecSH WG Subject: Re: reauthentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 28 Aug 2001, Jakob Schlyter wrote: > has anyone considered adding reauthentication support for ssh? I like the > server to request that the client reauthenticates from time to time. Expiring credentials was breifly touched appon at the 50th IETF when disucssing the GSS drafts - since the underlying Kerberos tickets will expire what should happen to the SSH protocol connection. > this could be very useful for some authentication methods, e.g. smartcard, > where the authentication process requires a physical device to be attached > to the client - if the device is removed, the connection could be > terminated. The server would have to trust that the client told it the card went away since the server would not have direct access to the card itself. In fact the server would never actually know a card was been used all the server knows is what authentication mech was user in ssh-userauth. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 15:57:44 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19999 for ; Tue, 28 Aug 2001 15:57:44 -0400 (EDT) Received: (qmail 28785 invoked by uid 605); 28 Aug 2001 19:54:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28778 invoked from network); 28 Aug 2001 19:54:06 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 28 Aug 2001 19:54:06 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 927EB5283; Tue, 28 Aug 2001 21:58:59 +0200 (MEST) Received: from fonbella.crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id D9FE51DE9; Tue, 28 Aug 2001 21:58:58 +0200 (MEST) Date: Tue, 28 Aug 2001 21:58:58 +0200 (MEST) From: Jakob Schlyter To: Darren J Moffat Cc: SecSH WG Subject: Re: reauthentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 28 Aug 2001, Darren J Moffat wrote: > > this could be very useful for some authentication methods, e.g. smartcard, > > where the authentication process requires a physical device to be attached > > to the client - if the device is removed, the connection could be > > terminated. > > The server would have to trust that the client told it the card went away > since the server would not have direct access to the card itself. if the card is removed the client can't reauthenticate (since the private key is only on the card). > In fact the server would never actually know a card was been used all > the server knows is what authentication mech was user in ssh-userauth. the administrator can choose only to trust public keys (raw or from x.509 certificates) known to come from smartcards. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 16:04:49 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20132 for ; Tue, 28 Aug 2001 16:04:49 -0400 (EDT) Received: (qmail 29570 invoked by uid 605); 28 Aug 2001 20:01:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29563 invoked from network); 28 Aug 2001 20:01:11 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 28 Aug 2001 20:01:11 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05537; Tue, 28 Aug 2001 13:06:01 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.36]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id NAA13512; Tue, 28 Aug 2001 13:06:01 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SK5jLJ351363; Tue, 28 Aug 2001 13:05:45 -0700 (PDT) Date: Tue, 28 Aug 2001 13:04:19 -0700 (PDT) From: Darren J Moffat To: Jakob Schlyter cc: SecSH WG Subject: Re: reauthentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 28 Aug 2001, Jakob Schlyter wrote: > if the card is removed the client can't reauthenticate (since the private > key is only on the card). Correct but that doesn't happen when the card is removed only when the reauthentication triggers from the server side of the connection, which isn't how I had read your suggestion. If you are happy with that then it takes smartcard out of the picture as far as the protocol is concerned but should provide you with near to the functionality you want with a smartcard being removed. > In fact the server would never actually know a card was been used all > > the server knows is what authentication mech was user in ssh-userauth. > > the administrator can choose only to trust public keys (raw or from x.509 > certificates) known to come from smartcards. That isn't a protocol issue then, but a site policy dependant on some functionality in a particular implementation and some knowlege of their own PKI infrastructure. Which don't get me wrong will probably work just fine. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 16:12:29 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20316 for ; Tue, 28 Aug 2001 16:12:28 -0400 (EDT) Received: (qmail 599 invoked by uid 605); 28 Aug 2001 20:08:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 592 invoked from network); 28 Aug 2001 20:08:50 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 28 Aug 2001 20:08:50 -0000 Received: from mail.crt.se (postiljon.crt.se [172.16.1.14]) by nic.crt.se (Postfix) with ESMTP id 00FDF5283; Tue, 28 Aug 2001 22:13:43 +0200 (MEST) Received: from fonbella.crt.se (fonbella.crt.se [172.16.1.169]) by mail.crt.se (Postfix) with ESMTP id C1E701DE9; Tue, 28 Aug 2001 22:13:42 +0200 (MEST) Date: Tue, 28 Aug 2001 22:13:42 +0200 (MEST) From: Jakob Schlyter To: Darren J Moffat Cc: SecSH WG Subject: Re: reauthentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 28 Aug 2001, Darren J Moffat wrote: > > if the card is removed the client can't reauthenticate (since the private > > key is only on the card). > > Correct but that doesn't happen when the card is removed only when > the reauthentication triggers from the server side of the connection, > which isn't how I had read your suggestion. reauthentication would always be requested by the server and reponded to by the client. I can't currently see why the client would like request reauthentication. > If you are happy with that then it takes smartcard out of the picture > as far as the protocol is concerned but should provide you with near > to the functionality you want with a smartcard being removed. the smartcard was just an example, I could see uses for reauthentication for other methods like passwords, challenge-response and kerberos. reauthentication is gives the server the possibly to check if "someone" is still there. once again, this is still dependant on the authentication method - e.g. if the client is using an ssh key agent, thet "someone" might always be there. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Aug 28 21:20:38 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25088 for ; Tue, 28 Aug 2001 21:20:32 -0400 (EDT) Received: (qmail 3585 invoked by uid 605); 29 Aug 2001 01:16:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3577 invoked from network); 29 Aug 2001 01:16:46 -0000 Received: from unknown (HELO market0) (208.158.105.111) by mail.netbsd.org with SMTP; 29 Aug 2001 01:16:46 -0000 Received: from mail pickup service by market0 with Microsoft SMTPSVC; Tue, 28 Aug 2001 18:18:19 -0700 From: To: Subject: ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping Date: Tue, 28 Aug 2001 18:18:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_BFBE4_01C12FED.D079EA90" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 29 Aug 2001 01:18:19.0640 (UTC) FILETIME=[7CF5E780:01C13028] Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_BFBE4_01C12FED.D079EA90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com, please click --> Un-Subscribe My E-mai l International Order Welcome FREE SHIPPING NOT APPLY Cell Phone Accessories Blow out Sale...!! Save Up to 80%...!! ***** FREE SHIPPING (in US only) ***** Why pay more in Retail Store..??? 1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for All Cell Phone (5 pack) Antenna Booster for All Cell Phone (1pack) large image Retail Price: $19.95 Blow Out Price: $5.95 (save 75%) More Details... Buy it NOW !! Free Shipping Antenna Booster for All Cell Phone (5 pack) large image Retail Price: $99.75 Blow Out Price: $19.95 (save 80%) More Details... Buy it NOW !! Free Shipping 2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable NOKIA 51xx/6xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping 3. NOKIA 82xx/33xx Black Car Charger 11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib Battery NOKIA 82xx/33xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery large image Retail Price: $65.99 Blow Out Price: $24.95 (save 62%) More Details... Buy it NOW !! Free Shipping 4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA 51xx/6xx Data Cable NOKIA 51xx/61xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping NOKIA 51xx/6xx Data Cable large image Retail Price: $69.99 Blow Out Price: $14.95 (save 79%) More Details... Buy it NOW !! Free Shipping 5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia 8260/8290 Li-ion 1200mAh Vibrating Battery NOKIA 82xx/33xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $24.95 (save 46%) More Details... Buy it NOW !! Free Shipping 6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery large image Retail Price: $79.99 Blow Out Price: $34.95 (save 56%) More Details... Buy it NOW !! Free Shipping Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery large image Retail Price: $70.99 Blow Out Price: $29.95 (save 58%) More Details... Buy it NOW !! Free Shipping 7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia 3310/3390 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $14.95 (save 67%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping 8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping ------=_NextPart_000_BFBE4_01C12FED.D079EA90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
Cell=20 Phone Accessories
Blow out Sale...!!
Save Up to 80%...!!
***** FREE=20 SHIPPING (in=20 US only) *****
Why pay more in = Retail Store..???

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 Antenna Booster for All Cell Phone = (1pack) 9.=20 Antenna Booster for All Cell Phone (5 = pack)
=20 Retail=20 Price: $19.95
Blow Out Price: $5.95 = (save 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
=20 Retail=20 Price: $99.75
Blow Out Price: $19.95 (save = 80%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
2.=20 NOKIA=20 51xx/6xx Black Car Charger 10.=20 Nokia 3310/3390 Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
3.=20 NOKIA=20 82xx/33xx Black Car Charger
 11.=20 Nokia 8260/8290 Li-ion 1200mAh 12=20 Lights Flashing=20 & Vib Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $65.99
Blow Out Price: $24.95 (save = 62%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
4.=20 NOKIA=20 51xx/61xx Hands Free with on/off = Switch 12.=20 NOKIA=20 51xx/6xx Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $69.99
Blow Out Price: $14.95 (save = 79%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
5.=20 NOKIA=20 82xx/33xx Hands Free with on/off = Switch 13.=20 Nokia 8260/8290 Li-ion 1200mAh Vibrating = Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $45.99
Blow Out Price: $24.95 (save = 46%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
6.=20 NOKIA=20 51xx/6xx Li-ion 3200mAh Vibrating = Battery 14.Nokia=20 51xx/6xx Super Slim Black Li-ion 1200mAh Vib = Battery
=20 Retail=20 Price: $79.99
Blow Out Price: $34.95 (save = 56%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $70.99
Blow Out Price: $29.95 (save = 58%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
7.=20 NOKIA=20 51xx/6xx Black NIMH-700mAh Vibrating = Battery 15.=20 Nokia 3310/3390 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $45.99
Blow Out Price: $14.95 (save = 67%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
8.=20 Nokia 8260/8290 Data Cable 16.=20 Nokia 8260/8290 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping		 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
------=_NextPart_000_BFBE4_01C12FED.D079EA90--