From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 01 13:16:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0gb-0001xn-Lp for secsh-archive@megatron.ietf.org; Tue, 01 Nov 2005 13:16:41 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05916 for ; Tue, 1 Nov 2005 13:16:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8263D63B2E5; Tue, 1 Nov 2005 18:16:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from warspite.cnchost.com (warspite.concentric.net [207.155.248.9]) by mail.netbsd.org (Postfix) with ESMTP id B5F8163B2DA for ; Tue, 1 Nov 2005 18:16:30 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by warspite.cnchost.com id MAA10059; Tue, 1 Nov 2005 12:54:11 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: denis bider To: X-Mailer: Barca 1.4 (1000) - Licensed Version Date: Tue, 1 Nov 2005 18:54:57 +0100 Message-ID: <2005111185457.544937@nucleus> In-Reply-To: <01c301c5dd9a$a078f1b0$0200a8c0@weidaih1> Subject: DSA keys larger than 1024 bits Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable My colleague Wei tried to post the following message, but it didn't get= through to the list. I'm forwarding it here: ----- Original Message ----- From: Wei Dai To: ietf-ssh@netbsd.org Sent: Saturday, October 29, 2005 2:56 PM Subject: DSA keys larger than 1024 bits Some SSH2 implementations, including OpenSSH, can apparently generate and use=A0DSA keys larger than 1024 bits. I'm not sure about other implementations, but at least with OpenSSH, there are two major problems with the way this works. 1. This violates FIPS 186-2, the DSS standard, which limits the key size to 1024. 2. Even though the size of the prime modulus, p, can exceed 1024, the size of the subgroup order, q, is still limited to 160 bits. (OpenSSH can not interoperate with other implementations that use larger subgroups and complains about invalid signature size.) But this implies 80 bit security no matter how big the key is, because there is an attack whose running time depends exponentially on the size of sqrt(q), but only polynomially on the size of p. [1]=A0To increase security, the sizes of p and q must both be increased. In Crypto++, by default the size of q is chosen as 2* DiscreteLogWorkFactor(modulusSize), where DiscreteLogWorkFactor is: unsigned int DiscreteLogWorkFactor(unsigned int n) { // extrapolated from the table in Odlyzko's "The Future of Integer // Factorization" // updated to reflect the factoring of RSA-130 // assuming discrete log takes about the same time as factoring if (n<5) return 0; else return (unsigned int)(2.4 * pow((double)n, 1.0/3.0) * pow(log(double(n)), 2.0/3.0) - 5); } This translates to q sizes of 226 and 304 for p sizes of 2048 and 4096 respectively. To fix these problems, I suggest the following: 1. Stop using "ssh-dss"=A0with non-standard DSA key sizes. 2. Create a new algorithm name for non-standard DSA key sizes. 3. For the new algorithm, allow arbitrary key sizes as long as p and q are=A0at least=A01024 and 160 bits respectively. 4. When generating new keys, use something like the above DiscreteLogWorkFactor function to derive the size of q from p. [1] http://en.wikipedia.org/wiki/Baby-step_giant-step From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 01 14:09:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1Vv-0007jX-8w for secsh-archive@megatron.ietf.org; Tue, 01 Nov 2005 14:09:43 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08486 for ; Tue, 1 Nov 2005 14:09:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 68CCD63B39E; Tue, 1 Nov 2005 19:09:30 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 2606463B393 for ; Tue, 1 Nov 2005 19:09:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id B2AE61B8032; Tue, 1 Nov 2005 20:09:24 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23293-01-9; Tue, 1 Nov 2005 20:09:23 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 8F5B01B80D2; Tue, 1 Nov 2005 20:09:23 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.3+Sun/8.12.8) with ESMTP id jA1J9MSC002346; Tue, 1 Nov 2005 20:09:22 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id jA1J9Kvs002342; Tue, 1 Nov 2005 20:09:20 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: denis bider Cc: Subject: Re: DSA keys larger than 1024 bits References: <2005111185457.544937@nucleus> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 01 Nov 2005 20:09:09 +0100 In-Reply-To: <2005111185457.544937@nucleus> Message-ID: Lines: 62 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA08486 denis bider writes: > My colleague Wei tried to post the following message, but it didn't get= through to the list. > ----- Original Message ----- > From: Wei Dai > To: ietf-ssh@netbsd.org > Sent: Saturday, October 29, 2005 2:56 PM > Subject: DSA keys larger than 1024 bits >=20 > Some SSH2 implementations, including OpenSSH, can apparently > generate and use=A0DSA keys larger than 1024 bits. I'm not sure about > other implementations, but at least with OpenSSH, there are two > major problems with the way this works. I recently got reports on interoperation problems between lsh and an openssh server using 4096 bit or so dsa key. lsh currently allows keys that are a bit larger than specified by the standard (the limit is around 2048 bits or so), but I don't think it's a good idea to use non-standard DSA key sizes (and then, I think all the key sizes but 1024 bits have been deprecated because they're too small today). > 2. Even though the size of the prime modulus, p, can exceed 1024, > the size of the subgroup order, q, is still limited to 160 bits. And it's not clear how to generalize the specification of dsa to use a larger q; if you use a p larger than the hash size, you're using an algorithm that's quite different from dsa. May be it would make sense to use 256 or 512 bits for q, together with sha256 or sha512. But the point is that there's no single obvious way to generalize dsa to larger groups, and it's no longer the standardized "dsa" algorithm. > To fix these problems, I suggest the following: >=20 > 1. Stop using "ssh-dss"=A0with non-standard DSA key sizes. >=20 > 2. Create a new algorithm name for non-standard DSA key sizes. I'm not sure if step 2 really is important. I meen, if a 1024 bit key is too small, why not use rsa instead? That's simple, standardized, and fairly well understood. Sure, ssh-dss is REQUIRED while ssh-rsa is only RECOMMENDED, but as far as I'm aware, using non-standard dsa key sizes is not supported at all according to the ssh spec and FIPS-186-2. S= o just sticking to rsa keys seems like a better choice, both for practical interoperability, and formal standards compliance. I suspect that most ssh users that have generated a 4096 bit dsa key are unaware that the security is tied to the 160 bit subgroup, and that most would be better served by using a large rsa key instead. By supporting huge dsa keys, one confuses the users. If you want to spend time and energy on developing a new signature algorithm for use in ssh, instead of constructing a parametrized variant of dsa, perhaps it would make more sense to investigate elliptic curve techniques. I'm not very familiar with that area, since it appears to be a patent marsh, but perhaps there's some good well studied signature scheme in there that's not encumbered by patents? (The only obvious advantage of dsa over rsa seems to be the shorter signatures, hence my association to eliptic curves). Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 01 23:06:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX9tE-0002mV-PZ for secsh-archive@megatron.ietf.org; Tue, 01 Nov 2005 23:06:23 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08276 for ; Tue, 1 Nov 2005 23:05:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4E94C63B412; Wed, 2 Nov 2005 04:06:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 7CF4663B3CF for ; Wed, 2 Nov 2005 04:06:13 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 61C6F3478A; Wed, 2 Nov 2005 17:06:12 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08074-03; Wed, 2 Nov 2005 17:06:12 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id EA5513449D; Wed, 2 Nov 2005 17:06:09 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8E28D3775A; Wed, 2 Nov 2005 17:06:09 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EX9t8-00008j-00; Wed, 02 Nov 2005 17:06:14 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@denisbider.com, nisse@lysator.liu.se Subject: Re: DSA keys larger than 1024 bits Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Wed, 02 Nov 2005 17:06:14 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >I suspect that most ssh users that have generated a 4096 bit dsa key >are unaware that the security is tied to the 160 bit subgroup, and >that most would be better served by using a large rsa key instead. By >supporting huge dsa keys, one confuses the users. I know that at least some users are aware that they're not getting any extra security, but are using 4Kbit keys anyway for warm fuzzies (hey, don't look at me, they probably wear tinfoil hats too :-). The real fault though is with the software and/or the documentation, it shouldn't let you generate illogical key sizes, or should warn against doing so. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 02 06:35:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXGts-0002dG-P0 for secsh-archive@megatron.ietf.org; Wed, 02 Nov 2005 06:35:29 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28656 for ; Wed, 2 Nov 2005 06:35:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E243F63B481; Wed, 2 Nov 2005 11:35:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id BC8ED63B483 for ; Wed, 2 Nov 2005 11:35:20 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 5DD611B80D4; Wed, 2 Nov 2005 12:35:16 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18574-01-71; Wed, 2 Nov 2005 12:35:15 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 0944F1B80CB; Wed, 2 Nov 2005 12:35:14 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.3+Sun/8.12.8) with ESMTP id jA2BZDtE010346; Wed, 2 Nov 2005 12:35:14 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id jA2BZC93010343; Wed, 2 Nov 2005 12:35:12 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: =?iso-8859-1?q?Henrick_Hellstr=F6m?= Cc: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" References: <43623022.6070800@streamsec.se> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 02 Nov 2005 12:35:10 +0100 In-Reply-To: <43623022.6070800@streamsec.se> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA28656 Henrick Hellstr=F6m writes: > This ought to be a simple question, but it seems it is not spelled out > anywhere in specification: >=20 > Exactly what is to be included in the calculation of the length of a > "packet", when checking if it exceeds the Maximum Packet Size > parameter sent during SSH Connection establishment? If we're talking about CHANNEL_OPEN / CHANNEL_OPEN_CONFIRM, I think it's best to interpret the max pcket size as the maximum amount of channel "upper layer" data in a CHANNEL_DATE or CHANNEL_EXTENDED_DATA message. I think this has been discussed earlier, and I think that was the conclusion. When reading data to be sent over an ssh channel, the length for the underlying read call can be selected as MIN(channel max packet size, current channel window size), which is nice and simple. I have earlier thought that the channel's max packet size should be interpreted as a the payload size for the ssh *transport* layer, but that makes the read logic unnecessarily complicated. This means that if you want to limit the ssh transport layer payload size of sent or received transport packets to 32768 bytes, then you need to limit the received or sent max packet size for a channel to 32768 - transport overhead. I agree a clarification would be nice, but perhaps it's too late. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 02 12:08:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM67-0003Qy-5K for secsh-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:08:27 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21707 for ; Wed, 2 Nov 2005 12:08:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8168C63B49D; Wed, 2 Nov 2005 17:08:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 4F43863B49A for ; Wed, 2 Nov 2005 17:08:21 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 282781B8042 for ; Wed, 2 Nov 2005 18:08:17 +0100 (CET) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22295-01-98 for ; Wed, 2 Nov 2005 18:08:16 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3AE071B8013 for ; Wed, 2 Nov 2005 18:08:16 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.13.3+Sun/8.12.8) with ESMTP id jA2H8FX5014486 for ; Wed, 2 Nov 2005 18:08:15 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.13.4+Sun/8.12.8/Submit) id jA2H8E2u014483; Wed, 2 Nov 2005 18:08:14 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" References: <43623022.6070800@streamsec.se> <20051029225003.GA29394@chiark.greenend.org.uk> <20051030122611.GA21120@chiark.greenend.org.uk> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 02 Nov 2005 18:08:12 +0100 In-Reply-To: <20051030122611.GA21120@chiark.greenend.org.uk> Message-ID: Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jacob Nevins writes: > How about the following change to secsh-connect 5.1, which makes the > 'maximum packet size' language match that used for 'initial window > size'?: > > The 'maximum packet size' specifies the > maximum number of bytes of channel data that may be sent to the > sender in a single SSH packet. It's not entirely trivial to make this clear. I would propose a change to section "5.2 Data transfer", in the description of SSH_MSG_CHANNEL_DATA. Before: The maximum amount of data allowed is the current window size. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. After: The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. *Maybe* also add a clarification along these lines: Implementations are expected to have some limit on the ssh transport layer packet size (any limit for rececived packets MUST be 32768 bytes or larger, as described in [SSH-TRANSPORT]). The implementation of the SSH connection layer * MUST NOT advertise a maximum packet size that would result in transport packets larger than its transport layer is willing to receive. * MUST NOT generate data packets larger that its transport layer is willing to send, even if the remote end would be willing to accept very large packets. Although I feel this text is much too long, and we probably shouldn't say anything about this at all if we can't say it more concisely. The first point is a clarification of the actual wire protocol, it says that if the other end advertises a huge maximum packet size, it can also be expected to accept huge packets, and in this case it is safe to send packets larger than 32768 bytes. The second point is almost self-evident; if your transport layer can't send a 10 MB packet, don't do that, and don't rely in the *remote* end to advertize a maximum packet size that is supported by your implementation. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 03 09:34:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXgAY-0002jo-28 for secsh-archive@megatron.ietf.org; Thu, 03 Nov 2005 09:34:22 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04003 for ; Thu, 3 Nov 2005 09:33:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 785E463B120; Thu, 3 Nov 2005 14:34:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id A525563B102 for ; Thu, 3 Nov 2005 14:34:14 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2005 06:34:14 -0800 X-IronPort-AV: i="3.97,287,1125903600"; d="scan'208"; a="671559087:sNHT24108156" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA3EYBTI016643; Thu, 3 Nov 2005 06:34:12 -0800 (PST) Date: Thu, 3 Nov 2005 06:34:11 -0800 (PST) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" In-Reply-To: Message-ID: References: <43623022.6070800@streamsec.se> <20051029225003.GA29394@chiark.greenend.org.uk> <20051030122611.GA21120@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1254324197-1131028451=:22919" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1254324197-1131028451=:22919 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, I'm inclined to include everything that Niels proposes below. Some=20 lengthy notations are acceptable for clarity. Please send OBJECTIONS or=20 CORRECTIONS to the proposed text quickly. Thanks, Chris On Wed, 2 Nov 2005, Niels M=F6ller wrote: > Jacob Nevins writes: > >> How about the following change to secsh-connect 5.1, which makes the >> 'maximum packet size' language match that used for 'initial window >> size'?: >> >> The 'maximum packet size' specifies the >> maximum number of bytes of channel data that may be sent to the >> sender in a single SSH packet. > > It's not entirely trivial to make this clear. I would propose a change > to section "5.2 Data transfer", in the description of > SSH_MSG_CHANNEL_DATA. > > Before: > > The maximum amount of data allowed is the current window size. The > window size is decremented by the amount of data sent. Both parties > MAY ignore all extra data sent after the allowed window is empty. > > After: > > The maximum amount of data allowed is determined by the maximum > packet size for the channel, and the current window size, whichever > is smaller. The window size is decremented by the amount of data > sent. Both parties MAY ignore all extra data sent after the allowed > window is empty. > > *Maybe* also add a clarification along these lines: > > Implementations are expected to have some limit on the ssh > transport layer packet size (any limit for rececived packets MUST > be 32768 bytes or larger, as described in [SSH-TRANSPORT]). The > implementation of the SSH connection layer > > * MUST NOT advertise a maximum packet size that would result in > transport packets larger than its transport layer is willing to > receive. > > * MUST NOT generate data packets larger that its transport layer is > willing to send, even if the remote end would be willing to > accept very large packets. > > Although I feel this text is much too long, and we probably shouldn't > say anything about this at all if we can't say it more concisely. The > first point is a clarification of the actual wire protocol, it says > that if the other end advertises a huge maximum packet size, it can > also be expected to accept huge packets, and in this case it is safe > to send packets larger than 32768 bytes. The second point is almost > self-evident; if your transport layer can't send a 10 MB packet, don't > do that, and don't rely in the *remote* end to advertize a maximum > packet size that is supported by your implementation. > > Regards, > /Niels > ---559023410-1254324197-1131028451=:22919-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 03 09:40:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXgGO-0004Je-Lw for secsh-archive@megatron.ietf.org; Thu, 03 Nov 2005 09:40:24 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04266 for ; Thu, 3 Nov 2005 09:40:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 14B5C63B135; Thu, 3 Nov 2005 14:40:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 31E8D63B133 for ; Thu, 3 Nov 2005 14:40:19 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2005 06:40:19 -0800 X-IronPort-AV: i="3.97,287,1125903600"; d="scan'208"; a="671560706:sNHT25013104" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA3EeHTI019438 for ; Thu, 3 Nov 2005 06:40:17 -0800 (PST) Date: Thu, 3 Nov 2005 06:40:17 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <1130446268.1347.408.camel@thunk> Message-ID: References: <1130446268.1347.408.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I appreciate the input everyone has generated so far. I, too, am going through these things very carefully now (besides doing the day job, and trying to get ready for next week). The process that I plan on using: - I'll post my edits to the proto-RFCs to this list for comments before I submit them to the RFC Editor. Hopefully I'll have my review done by this weekend. - I'll ask the RFC Editor post new proto-RFCs for review before accepting, and give everyone a few days to review those. - I'll give the WG a final heads-up before accepting. Thanks, Chris On Thu, 27 Oct 2005, Bill Sommerfeld wrote: > The RFC Editor is nearly done with the five core drafts and two of the > extension documents, and they have now entered the "AUTH48" ("Authors 48 > hours") period. (Which almost never lasts that little time, but I > digress..). > > At this point, when the listed authors say they're done, they're done. > > Since these documents have been the joint work of the entire working > group, I'd like to ask interested parties to double check the changes > made by the RFC editor in the course of converting from internet-draft > to RFC. > > As a reminder, the time for wholesale changes is long past; typos and > accidental changes to the protocol are what we're looking to correct at > this time. > > Here are the current almost-an-RFC drafts and visual diffs with the > underlying I-D: > > draft-ietf-secsh-assignednumbers-12.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt > > draft-ietf-secsh-architecture-22.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt > > draft-ietf-secsh-userauth-27.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252.txt > > draft-ietf-secsh-transport-24.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253.txt > > draft-ietf-secsh-connect-25.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254.txt > > draft-ietf-secsh-dns-05.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255.txt > > draft-ietf-secsh-auth-kbdinteract-07.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256.txt > > Send comments either to me, or to the list as a whole; I'll review them > and relay them to the RFC editor. > > Thanks for your time... > > - Bill > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 03 13:59:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkIt-0002tc-NY for secsh-archive@megatron.ietf.org; Thu, 03 Nov 2005 13:59:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20262 for ; Thu, 3 Nov 2005 13:58:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0A0B563B1AA; Thu, 3 Nov 2005 18:59:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 1679D63B17B for ; Thu, 3 Nov 2005 18:59:09 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jA3Ix84u019660 for ; Thu, 3 Nov 2005 10:59:08 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jA3Ix4H0013139; Thu, 3 Nov 2005 13:59:04 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jA3Ix4J5006775; Thu, 3 Nov 2005 13:59:04 -0500 (EST) Subject: NIST spec for hash-based key derivation. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1131044344.6406.27.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Thu, 03 Nov 2005 13:59:04 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Russ Housley sent the enclosed message to the saag@mit.edu list last week (SAAG is the IETF Security Area Advisory Group; it's a public list). There's been some discussion on this which followed. I took a look at this draft-dang-nistkdf-00, and the NIST draft SP 800-56 it references. It specifies a method for using a hash function to derive arbitrary-length session keys from a shared secret (such as the result of a DH exchange). In addition, Appendix B of the NIST draft lists a few alternatives as well as a few design principles for KDF's. At first glance it looks to me that the key derivation used in SSHv2 violates a few of these design principles. In addition, there's a secondary consideration for folks building systems aimed at certain markets. To quote from a later message in the thread from Tim Polk: Since we currently don't have a standard, cryptomodules can currently implement any KDF they choose. Once this document is finalized, cryptomodules would be limited to "approved" KDFs (at least in FIPS mode). I've asked Tim to ask NIST to look at the SSH KDF; I haven't heard back from him but cryptographers usually take their time. If people are interested in using SSH with FIPS-certified crypto modules the path of least resistance may well be to define a new key exchange which uses this KDF. - Bill -----Forwarded Message----- From: Russ Housley To: saag@mit.edu Subject: [saag] Hash-Based Key Derivation Date: Tue, 25 Oct 2005 12:44:42 -0400 I wanted call your attention to an individual draft on "Hash-Based Key Derivation." http://www.ietf.org/internet-drafts/draft-dang-nistkdf-00.txt This draft specifies a soon to be NIST-approved algorithm for deriving secret key material from a shared secret using a hash algorithm. This algorithm is in the NIST draft SP 800-56. I encourage review and comment. If you have concerns with this document, then the concerns probably apply to he NIST draft SP 800-56 document too. I am considering sponsoring this document as an Informational RFC. Please let me know if you have any concerns with this proposed action. Thanks, Russ _______________________________________________ saag mailing list saag@mit.edu https://jis.mit.edu/mailman/listinfo/saag From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 03 14:37:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXktz-0004Lg-FL for secsh-archive@megatron.ietf.org; Thu, 03 Nov 2005 14:37:35 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21825 for ; Thu, 3 Nov 2005 14:37:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B201A63B1A3; Thu, 3 Nov 2005 19:37:30 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 2EB8263B19E for ; Thu, 3 Nov 2005 19:37:29 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8099366; Thu, 03 Nov 2005 12:37:28 -0700 Message-ID: <436A69A3.8090701@vandyke.com> Date: Thu, 03 Nov 2005 12:48:51 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: NIST spec for hash-based key derivation. References: <1131044344.6406.27.camel@thunk> In-Reply-To: <1131044344.6406.27.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > Russ Housley sent the enclosed message to the saag@mit.edu list last > week > (SAAG is the IETF Security Area Advisory Group; it's a public list). > There's been some discussion on this which followed. > > I took a look at this draft-dang-nistkdf-00, and the NIST draft SP > 800-56 it references. It specifies a method for using a hash function > to derive arbitrary-length session keys from a shared secret (such as > the result of a DH exchange). In addition, Appendix B of the NIST draft > lists a few alternatives as well as a few design principles for KDF's. > > At first glance it looks to me that the key derivation used in SSHv2 > violates a few of these design principles. > > In addition, there's a secondary consideration for folks building > systems aimed at certain markets. To quote from a later message in the > thread from Tim Polk: > > Since we currently don't have a standard, cryptomodules can > currently implement any KDF they choose. Once this document is > finalized, cryptomodules would be limited to "approved" KDFs (at > least in FIPS mode). > > I've asked Tim to ask NIST to look at the SSH KDF; I haven't heard back > from him but cryptographers usually take their time. > > If people are interested in using SSH with FIPS-certified crypto modules > the path of least resistance may well be to define a new key exchange > which uses this KDF. Currently, we specify the shared secret (rather than the session keys) as the output of key exchange... which means, as currently defined, the KDF isn't part of "the key exchange algorithm" Not a big deal... we'd just override this in any document... but perhaps unfortunate since implementors may have drawn similar architectural lines in their software. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 04 22:49:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYF3H-00041g-BR for secsh-archive@megatron.ietf.org; Fri, 04 Nov 2005 22:49:11 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05671 for ; Fri, 4 Nov 2005 22:48:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id ACD5463B1F8; Sat, 5 Nov 2005 03:49:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 2758F63B15D for ; Sat, 5 Nov 2005 03:49:05 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2005 19:49:05 -0800 X-IronPort-AV: i="3.97,293,1125903600"; d="scan'208"; a="361127964:sNHT21372756" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA53n3Qr016258 for ; Fri, 4 Nov 2005 19:49:03 -0800 (PST) Date: Fri, 4 Nov 2005 19:49:03 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Consistency of references in core ids In-Reply-To: <43623022.6070800@streamsec.se> Message-ID: References: <43623022.6070800@streamsec.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Just a note that the references for the new RFCs in the text are inconsistent with the references for the other RFCs; [SSH-ARCH] as opposed to [RFC4251]. I think that the way that the RFC Editor has them is more informative to a reader so I'm going to leave them that way. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 04 22:52:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYF67-0004ea-DA for secsh-archive@megatron.ietf.org; Fri, 04 Nov 2005 22:52:07 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05751 for ; Fri, 4 Nov 2005 22:51:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E007C63B22C; Sat, 5 Nov 2005 03:52:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 5A0E363B15D for ; Sat, 5 Nov 2005 03:52:04 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2005 19:52:04 -0800 X-IronPort-AV: i="3.97,293,1125903600"; d="scan'208"; a="361128447:sNHT21549276" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA53q2P0010923 for ; Fri, 4 Nov 2005 19:52:03 -0800 (PST) Date: Fri, 4 Nov 2005 19:52:02 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: version and identification string in core ids Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, In [SSH-TRANS], Section 4.2 (Protocol Version Exchange) identifies the identification string. Other places in the document use the term version string for the same thing. This is most notable in Section 8 (Diffie-Hellman Key Exchange). I'm going to replace all appropriate occurrences of with . Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 04 22:54:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYF8M-0004up-9m for secsh-archive@megatron.ietf.org; Fri, 04 Nov 2005 22:54:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05843 for ; Fri, 4 Nov 2005 22:54:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 393E663B271; Sat, 5 Nov 2005 03:54:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.netbsd.org (Postfix) with ESMTP id B11D663B26E for ; Sat, 5 Nov 2005 03:54:22 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 04 Nov 2005 19:53:20 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA53rJNm021153 for ; Fri, 4 Nov 2005 19:53:19 -0800 (PST) Date: Fri, 4 Nov 2005 19:53:18 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: ASCII code 127 in names in core ids Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, In many places throughout the documents we say that "whitespace, or control characters (ASCII codes 32 or less)" are not to be used in names. Should this also include ASCII code 127 (del)? If I don't recieve any objections, I'll change this to something like "...whitespace, control characters (ASCII codes 32 or less), or ASCII code 127..." Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 08 11:41:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWXi-0001Ru-28 for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 11:41:54 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16008 for ; Tue, 8 Nov 2005 11:41:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 009FF63B481; Tue, 8 Nov 2005 16:41:48 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.ipnet.kiev.ua (cielago.ip.net.ua [82.193.96.7]) by mail.netbsd.org (Postfix) with ESMTP id 00B2D63B47E for ; Tue, 8 Nov 2005 16:41:45 +0000 (UTC) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA8GfhO2049886 for ; Tue, 8 Nov 2005 18:41:43 +0200 (EET) (envelope-from ni4@ukr.net) Received: from mail.ipnet.kiev.ua ([82.193.96.7]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 31814-03-2 for ; Tue, 8 Nov 2005 18:41:42 +0200 (EET) Received: from INFERNAL (172.16.2.165.cl.ipnet.kiev.ua [172.16.2.165]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA8Gbt02049398 for ; Tue, 8 Nov 2005 18:37:55 +0200 (EET) (envelope-from ni4@ukr.net) Date: Tue, 8 Nov 2005 18:36:10 +0200 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <1814725437.20051108183610@ukr.net> To: ietf-ssh@NetBSD.org Subject: SFTP SSH_FXP_REALPATH packet question MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ip.net.ua Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello, In draft-ietf-secsh-filexfer-10.txt said, that packet has the following format : byte SSH_FXP_REALPATH uint32 request-id string original-path [UTF-8] byte control-byte [optional] string compose-path[0..n] [optional] So the question is : how do I logicaly-correct recognize, is the control-byte present, or absent? The way is to see the first byte after other fields, if it zero (It seems that compose-path will not be bigger than 2^24), the control-byte is absent. But this way not looks like the best.. And another question, are there any available implementations of clients/server which supports versions 5 or/and 6 of SFTP protocol? -- Best regards,Nickolay mailto: From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 08 12:06:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWvy-00066E-Ts for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:06:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17598 for ; Tue, 8 Nov 2005 12:06:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B04463B486; Tue, 8 Nov 2005 17:06:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id E797663B484 for ; Tue, 8 Nov 2005 17:06:54 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8112335; Tue, 08 Nov 2005 10:06:53 -0700 Message-ID: <4370DB18.6030004@vandyke.com> Date: Tue, 08 Nov 2005 10:06:32 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Nickolay L." CC: ietf-ssh@NetBSD.org Subject: Re: SFTP SSH_FXP_REALPATH packet question References: <1814725437.20051108183610@ukr.net> In-Reply-To: <1814725437.20051108183610@ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nickolay L. wrote: > Hello, > > In draft-ietf-secsh-filexfer-10.txt said, that packet has the > following format : > > byte SSH_FXP_REALPATH > uint32 request-id > string original-path [UTF-8] > byte control-byte [optional] > string compose-path[0..n] [optional] > > So the question is : how do I logicaly-correct recognize, is the > control-byte present, or absent? The way is to see the first byte > after other fields, if it zero (It seems that compose-path will not > be bigger than 2^24), the control-byte is absent. But this way not > looks like the best.. Sorry that it isn't clear. control-byte is _not_ optional if compose-path is specified. In other words, it is permissible to omit: a.) both control-byte & compose-path b.) compose-path only It is not permissible to omit the control-byte if the compose-path is present. > And another question, are there any available implementations of > clients/server which supports versions 5 or/and 6 of SFTP protocol? The WinSCP client supports v5. VanDykes VShell server supports v5. I don't know of any v6 implementations yet, though I know both VanDyke's VShell and WinSCP do support some of the extensions from v6. Thanks, Joseph From grayxucd@graycat.com Tue Nov 08 12:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXEb-0005Rd-TZ for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:26:13 -0500 Received: from 168-220.82-139.bia.tkb.net.pl (168-220.82-139.bia.tkb.net.pl [82.139.168.220]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19020 for ; Tue, 8 Nov 2005 12:25:46 -0500 (EST) Received: from mail.graycat.com by 168-220.82-139.bia.tkb.net.pl (Postfix) with ESMTP id 24937C1721 for ; Tue, 8 Nov 2005 12:30:42 -0500 Received: from unknown (151.115.152.113) by mail.graycat.com (qmail-ldap-1.03) with SMTP for ; Tue, 8 Nov 2005 12:30:42 -0500 Reply-To: "Harvey Stubbs" From: "Harvey" Message-ID: <8623675348.20051108123042@jzaza> Date: Tue, 8 Nov 2005 12:30:42 -0500 To: Subject: Photoshop CS 8.0 $59.95 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wakey wakey! A caricature is putting the face of a joke on the body of a truth. You save about: 80-85% MS Visual Studio.NET 2003 Enterprise Architect $129.95 Adobe Acrobat V 6.0 Professional PC $49.95 Autodesk AutoCAD Electrical 2005 $99.95 Macromedia Contribute 1.0 $29.95 http://save80software.com Men are sent into the world with bills of credit, and seldom draw to their full extent.I told my doctor I get very tired when I go on a diet, so he gave me pep pills. Know what happened? I ate faster. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 08 12:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXIU-0006eN-8O for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:30:14 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19212 for ; Tue, 8 Nov 2005 12:29:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BA4EF63B175; Tue, 8 Nov 2005 17:30:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.ipnet.kiev.ua (cielago.ip.net.ua [82.193.96.7]) by mail.netbsd.org (Postfix) with ESMTP id B7D5E63B108 for ; Tue, 8 Nov 2005 17:30:09 +0000 (UTC) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA8HU8Xj056061 for ; Tue, 8 Nov 2005 19:30:08 +0200 (EET) (envelope-from ni4@ukr.net) Received: from mail.ipnet.kiev.ua ([82.193.96.7]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 32353-01-6 for ; Tue, 8 Nov 2005 19:30:06 +0200 (EET) Received: from INFERNAL (172.16.2.165.cl.ipnet.kiev.ua [172.16.2.165]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA8HPpRh055652 for ; Tue, 8 Nov 2005 19:25:51 +0200 (EET) (envelope-from ni4@ukr.net) Date: Tue, 8 Nov 2005 19:24:06 +0200 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <1631485888.20051108192406@ukr.net> To: Joseph Galbraith Subject: Re[2]: SFTP SSH_FXP_REALPATH packet question In-Reply-To: <4370DB18.6030004@vandyke.com> References: <1814725437.20051108183610@ukr.net> <4370DB18.6030004@vandyke.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ip.net.ua Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello Joseph, JG> Sorry that it isn't clear. control-byte is _not_ optional JG> if compose-path is specified. JG> In other words, it is permissible to omit: JG> a.) both control-byte & compose-path JG> b.) compose-path only JG> It is not permissible to omit the control-byte if the compose-path JG> is present. Thank you for a quick answer. I think, it would be useful to insert such note to draft? -- Best regards,Nickolay mailto: From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 08 12:32:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXKc-0006tR-Ft for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:32:26 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19292 for ; Tue, 8 Nov 2005 12:31:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5C2C263B488; Tue, 8 Nov 2005 17:32:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 857AE63B484 for ; Tue, 8 Nov 2005 17:32:18 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8112459; Tue, 08 Nov 2005 10:32:17 -0700 Message-ID: <4370E10B.8070103@vandyke.com> Date: Tue, 08 Nov 2005 10:31:55 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Nickolay L." CC: Joseph Galbraith Subject: Re: SFTP SSH_FXP_REALPATH packet question References: <1814725437.20051108183610@ukr.net> <4370DB18.6030004@vandyke.com> <1631485888.20051108192406@ukr.net> In-Reply-To: <1631485888.20051108192406@ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nickolay L. wrote: > Hello Joseph, > > JG> Sorry that it isn't clear. control-byte is _not_ optional > JG> if compose-path is specified. > > JG> In other words, it is permissible to omit: > > JG> a.) both control-byte & compose-path > JG> b.) compose-path only > > JG> It is not permissible to omit the control-byte if the compose-path > JG> is present. > > Thank you for a quick answer. > I think, it would be useful to insert such note to draft? Yes, I'll take care of this in the next round of editing. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 08 17:34:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZc2w-0006iB-O3 for secsh-archive@megatron.ietf.org; Tue, 08 Nov 2005 17:34:30 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10666 for ; Tue, 8 Nov 2005 17:34:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 049F163B1FA; Tue, 8 Nov 2005 22:34:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id DE15963B146 for ; Tue, 8 Nov 2005 22:34:10 +0000 (UTC) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jA8MYA3F013559 for ; Tue, 8 Nov 2005 15:34:10 -0700 (MST) Received: from localhost.sfbay.sun.com (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jA8MY7Tk007448 for ; Tue, 8 Nov 2005 14:34:10 -0800 (PST) Received: from localhost.sfbay.sun.com (localhost [127.0.0.1]) by localhost.sfbay.sun.com (8.13.4+Sun/8.13.4) with ESMTP id jA8MY4Cd001043; Tue, 8 Nov 2005 14:34:04 -0800 (PST) Received: (from sommerfeld@localhost) by localhost.sfbay.sun.com (8.13.4+Sun/8.13.4/Submit) id jA8MY3Ql001042; Tue, 8 Nov 2005 14:34:03 -0800 (PST) X-Authentication-Warning: localhost.sfbay.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [rt.icann.org #2774] draft-ietf-secsh-transport From: Bill Sommerfeld To: iana-drafts@icann.org Cc: Chris Lonvick , ietf-ssh@NetBSD.org, hartmans-ietf@mit.edu In-Reply-To: References: Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1131489242.929.34.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Tue, 08 Nov 2005 14:34:03 -0800 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-11-08 at 14:17, Michelle Cotton via RT wrote: > This message is to follow-up on our recent discussion. > Please reply back to this message to let us know what changes need to > take place in the registry > > Please copy approrpriate persons on your reply so everyone knows what's > going on (ADs, other authors/WG chairs). > > Thank you, Currently, you have: 30 SSH_MSG_KEXDH_INIT [SSH-TRANS] 31 SSH_MSG_KEXDH_REPLY [SSH-TRANS] 32-49 RESERVED (method specific) This should be: 30-49 RESERVED (key exchange method specific) [SSH-ARCH] future key exchange methods will define how *that method* uses the messages in range 30-49. reuse of those codepoints is okay because the peers pick a specific key exchange method before you use any messages in that range. see draft-ietf-secsh-architecture-22, section 7. Similarly, you have: 60 SSH_MSG_USERAUTH_INFO_REQUEST [RFC-ietf-secsh-auth-kbdinteract-07.txt] 61 SSH_MSG_USERAUTH_INFO_RESPONSE 62-79 RESERVED (User authentication method specific) which should be: 60-79 RESERVED (User authentication method specific) [SSH-ARCH] Future documents defining new user authentication methods will define how *that method* uses the 60-79; this should not be a mistaken for an assignment of values in that range to that specific method. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 09:51:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZrIA-0002ha-3z for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 09:51:14 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13706 for ; Wed, 9 Nov 2005 09:50:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E51FA63B17D; Wed, 9 Nov 2005 14:51:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.ipnet.kiev.ua (cielago.ip.net.ua [82.193.96.7]) by mail.netbsd.org (Postfix) with ESMTP id E530663B176 for ; Wed, 9 Nov 2005 14:51:06 +0000 (UTC) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA9Ep4uG098532 for ; Wed, 9 Nov 2005 16:51:04 +0200 (EET) (envelope-from ni4@ukr.net) Received: from mail.ipnet.kiev.ua ([82.193.96.7]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 50192-01-48 for ; Wed, 9 Nov 2005 16:51:02 +0200 (EET) Received: from INFERNAL (172.16.2.165.cl.ipnet.kiev.ua [172.16.2.165]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jA9El7K5097692 for ; Wed, 9 Nov 2005 16:47:08 +0200 (EET) (envelope-from ni4@ukr.net) Date: Wed, 9 Nov 2005 16:45:23 +0200 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <398832291.20051109164523@ukr.net> To: ietf-ssh@NetBSD.org Subject: SFTP : Byte-range locks MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ip.net.ua Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello, In 10th version of draft-ietf-secsh-filexfer written : uLockMask A bit mask of SSH_FXF_ACCESS_BLOCK_* values; the meanings are described in Section 8.1.1.3. What means for server SSH_FXF_ACCESS_BLOCK_READ & SSH_FXF_ACCESS_BLOCK_WRITE, is clear. But what means two other flags, SSH_FXF_ACCESS_BLOCK_DELETE & SSH_FXF_ACCESS_BLOCK_ADVISORY? -- Best regards,Nickolay mailto: From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 11:40:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsze-0001lS-Mm for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 11:40:15 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20561 for ; Wed, 9 Nov 2005 11:39:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3FC0863B214; Wed, 9 Nov 2005 16:40:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 8669463B206 for ; Wed, 9 Nov 2005 16:40:09 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8116234; Wed, 09 Nov 2005 09:40:08 -0700 Message-ID: <4372265B.4060302@vandyke.com> Date: Wed, 09 Nov 2005 09:39:55 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Nickolay L." CC: ietf-ssh@NetBSD.org Subject: Re: SFTP : Byte-range locks References: <398832291.20051109164523@ukr.net> In-Reply-To: <398832291.20051109164523@ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nickolay L. wrote: > Hello, > > In 10th version of draft-ietf-secsh-filexfer written : > > uLockMask > A bit mask of SSH_FXF_ACCESS_BLOCK_* values; the meanings are > described in Section 8.1.1.3. > > What means for server SSH_FXF_ACCESS_BLOCK_READ & > SSH_FXF_ACCESS_BLOCK_WRITE, is clear. But what means two other > flags, SSH_FXF_ACCESS_BLOCK_DELETE & SSH_FXF_ACCESS_BLOCK_ADVISORY? 8.1.1.3 seems pretty clear on this. If BLOCK_DELETE is specified, the file cannot be deleted. This doesn't make much sense in a byte-range lock... I suppose it needs a bit of text there. If ADVISORY is specified, the server doesn't enforce the locks. In the context of byte-range locks, this means that the server will not grant a second, overlapping byte-range lock, but it will not stop other callers from reading / writing the locked range. If ADVISORY is not set, the server will do MANDATORY locking; not only will it not grant a second, overlapping byte-range lock, but it will also not allow any conflicting IO operation to proceed. Which kind of locking is supported by the server is reflected in the "supported2" extension sent by the server during protocol startup. I'll try to clarify the locking here as it applies to byte range locks. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:27:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea29a-0005Qu-DH for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:27:06 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27950 for ; Wed, 9 Nov 2005 21:26:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 341EE63B16B; Thu, 10 Nov 2005 02:27:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 7281B63B167 for ; Thu, 10 Nov 2005 02:26:59 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Nov 2005 18:26:59 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="363123342:sNHT24493760" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2Qubi028243; Wed, 9 Nov 2005 18:26:57 -0800 (PST) Date: Wed, 9 Nov 2005 18:26:56 -0800 (PST) From: Chris Lonvick To: Jon Bright cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <4361C956.50404@siliconcircus.com> Message-ID: References: <1130446268.1347.408.camel@thunk> <4361C956.50404@siliconcircus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Fri, 28 Oct 2005, Jon Bright wrote: > Bill Sommerfeld wrote: >> >> draft-ietf-secsh-assignednumbers-12.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4250.txt > > I didn't catch anything. > >> draft-ietf-secsh-architecture-22.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4251.txt > > There are a couple of places where I disagree with the change from "which" to > "that", but I guess that's a taste thing. I'm also told that British English > (which I speak) tends to use "which" more than US English, so maybe it's just > my dialect showing through. > > End of section 9.3.1: "If there are no unsent packages, ..." should be "If > there are no unsent packets, ...". I'll get that changed. > > Middle of 9.3.3: "If the session stays active long enough, however, this > sequence number, will wrap." - the comma added after "number" seems > superfluous to me. I'll get that changed. > > 9.5.1: "Implementors SHOULD provide mechanisms for administrators to control > which services are exposed to limit the..." - seems to me there should be an > extra comma here: "...which services are exposed, to limit the...". It looks OK to me without the extra comma. > Also, > we're using "implementor" here (which I prefer). But at the start of 9.4.3, > we have "implementer". Hopefully no-one's going to mention hobgoblins if I > suggest that one or the other should be picked and used :-) I'm going to ask for a global change s/implementor/implementer/ since the sections at the end use the latter. > > 9.5.3: The sentence beginning "It is RECOMMENDED that X11 display > implementations default to allow the display..." seems to me more awkward > after the RFC Editor's changes than it was before them. My version would be: > "It is RECOMMENDED that X11 display implementations default to allowing the > display to be opened only over local IPC. It is RECOMMENDED that SSH server > implementations that support X11 forwarding default to allowing the display > to be opened only over local IPC. On single-user systems systems, it might > be reasonable to default to allowing the local display to be opened over > TCP/IP." It looks OK to me the way it is. > > > That's all I saw in -architecture. I'll be reading the others later. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:27:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea29l-0005Rx-Tc for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:27:17 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27964 for ; Wed, 9 Nov 2005 21:26:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 83C4A63B1C5; Thu, 10 Nov 2005 02:27:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id EB2B663B167 for ; Thu, 10 Nov 2005 02:27:12 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2005 18:27:12 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="673450548:sNHT22295392" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2RAbi028372 for ; Wed, 9 Nov 2005 18:27:11 -0800 (PST) Date: Wed, 9 Nov 2005 18:27:10 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <20051028134659.GA30930@chiark.greenend.org.uk> Message-ID: References: <20051028134659.GA30930@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Caught those. Bill has asked the IANA people here to make changes. Thanks, Chris On Fri, 28 Oct 2005, Jacob Nevins wrote: > Bill Sommerfeld writes: >> draft-ietf-secsh-assignednumbers-12.txt: >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt > > Only one of Ben Harris' comments from 14 June appears to have been > addressed here. (original message attached for convenience) > > The IANA registry doesn't appear to have addressed any of those comments. > > > I think all the comments I raised about the core drafts have been > addressed. > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2AG-0005bV-1K for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:27:49 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28006 for ; Wed, 9 Nov 2005 21:27:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AE08063B194; Thu, 10 Nov 2005 02:27:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id ACFA563B167 for ; Thu, 10 Nov 2005 02:27:43 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Nov 2005 18:27:44 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="363123689:sNHT28210628" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2Rf4B015525; Wed, 9 Nov 2005 18:27:42 -0800 (PST) Date: Wed, 9 Nov 2005 18:27:41 -0800 (PST) From: Chris Lonvick To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <200510282209.SAA06413@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <1130446268.1347.408.camel@thunk> <200510282209.SAA06413@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Fri, 28 Oct 2005, der Mouse wrote: > There are numerous changes made which I either agree with or don't care > about; I'm mentioning only the things that I would change back or do > entirely differently. > > I'm restricting myself to copy-edits. I note at least one semantic > point, but you say it's too late for them, and it's by no means a > catastrophic showstopper. > > I'm also basing this on diffs between the drafts and the proto-RFCs. I > may miss a few things this way, but it means I can get this done in > hours rather than days. > > Section numbers are those of the proto-RFC, when they differ from those > of the draft. > >> draft-ietf-secsh-assignednumbers-12.txt: >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt > > 4.1, 4.2, 4.4, 4.5.2: I too would prefer "which" over "that" here, though I > agree the difference is slight. Again, I'm not going to address these unless someone really pushes. > > 4.3.4, first bullet point: I prefer "...'reason code' value consistent > with the...". I'd also take the last sentence out of the passive > voice; perhaps something like "Implementors should first attempt...". I made a change. Please review. > > 4.5.2, in the description of the XCASE value: a backslash processing > glitch has struck here: > > - equivalents with "\". > + equivalents with " > > (Despite the indentation difference in the diff output, the new text > looks right when viewed alone - there presumably is a tab-vs-spaces > difference involved.) I'll get that reinstated. > > 4.9.5: I think this change is wrong, unless s/Names/names/ is also > done, and even then I don't like it. It's more -r- less consistent with the similar paragraphs in the rest of the document. > > 4.11.1: When describing des-cbc, I see "FIPS-46-3" on one line and > "FIPS 46-3" on the next line, apparently referring to the same > document. Shouldn't they both be spelled the same? Yup. > > 6.2: When describing [FIPS-46-3], I'd like to see it made explicit that > the NIST is a *USA* body; I see nothing there indicating which nation's > National Institutes of Standards and Technology is relevant. OK. That's many places. Please review to make sure I caught them all. > >> draft-ietf-secsh-architecture-22.txt: >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html >> ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt > > 4.5, second-last paragraph: I think the original text is substantially > better here; I think this is more like synonyms used as parenthetical > explanation than a list of qualifiers. OK. > > 5, describing a name-list: I think the last comma here needs to go (it > was in the original; there is a change here - ; to , - but I think it's > good). That is, s/names, nor/names nor/. OK. > > 8, last paragraph: everywhere else "as described in [RFC2434]" has been > preceded by a comma; for consistency, I think it should be here too. OK. > > 9.1: I'd > s/when knowing/given/ > s/in properly implementing/of properly implementing/ "when knowing" can be different from "given". I'm going to leave these. > > 9.2: s/messages to the user/messages, to the user/ - "such as error or > debug messages" is an explanatory parenthesis, so it needs a comma > after it as well as before. I modified it. Please check. > > 9.3.1, end of third paragraph: s/longer/long/ OK. > > 9.3.3, second paragraph: s/more so true/more true/ OK. > > 9.3.3, third paragraph: the editor inserted a comma into the "If the > session stays active lojng enough" sentence; I think this comma is > wrong and should be removed: s/sequence number,/sequence number/ Yup. > > 9.3.4, last paragraph: s/non-security critical/non-security-critical/. OK. > > 9.3.7: shouldn't the reference to [SSH-TRANS] give an explicit section > number instead of just saying `the section "Diffie-Hellman Key > Exchange"'? Nah. > > 9.3.9: I'd like to see s/attempts of traffic/attempts at traffic/. OK. > > 10: As in 4250 section 6.2, I'd like to see the NIST explicitly called > out as a USA body. OK. > > That's all I have time for right now. I'm going to be AFK all weekend; > if the authors want to push them out before I get done, then, well, I > just won't get a proofread done on the rest. :-/ > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML mouse@rodents.montreal.qc.ca > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:28:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2AS-0005eT-5u for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:28:00 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28048 for ; Wed, 9 Nov 2005 21:27:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4E36463B203; Thu, 10 Nov 2005 02:27:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 712FB63B167 for ; Thu, 10 Nov 2005 02:27:55 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Nov 2005 18:27:55 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="363123779:sNHT24181088" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2Rrbi028555; Wed, 9 Nov 2005 18:27:53 -0800 (PST) Date: Wed, 9 Nov 2005 18:27:52 -0800 (PST) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" In-Reply-To: Message-ID: References: <43623022.6070800@streamsec.se> <20051029225003.GA29394@chiark.greenend.org.uk> <20051030122611.GA21120@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1903590565-1131588960=:4527" Content-ID: Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1903590565-1131588960=:4527 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, Changes made. Thanks, Chris On Wed, 2 Nov 2005, Niels M=F6ller wrote: > Jacob Nevins writes: > >> How about the following change to secsh-connect 5.1, which makes the >> 'maximum packet size' language match that used for 'initial window >> size'?: >> >> The 'maximum packet size' specifies the >> maximum number of bytes of channel data that may be sent to the >> sender in a single SSH packet. > > It's not entirely trivial to make this clear. I would propose a change > to section "5.2 Data transfer", in the description of > SSH_MSG_CHANNEL_DATA. > > Before: > > The maximum amount of data allowed is the current window size. The > window size is decremented by the amount of data sent. Both parties > MAY ignore all extra data sent after the allowed window is empty. > > After: > > The maximum amount of data allowed is determined by the maximum > packet size for the channel, and the current window size, whichever > is smaller. The window size is decremented by the amount of data > sent. Both parties MAY ignore all extra data sent after the allowed > window is empty. > > *Maybe* also add a clarification along these lines: > > Implementations are expected to have some limit on the ssh > transport layer packet size (any limit for rececived packets MUST > be 32768 bytes or larger, as described in [SSH-TRANSPORT]). The > implementation of the SSH connection layer > > * MUST NOT advertise a maximum packet size that would result in > transport packets larger than its transport layer is willing to > receive. > > * MUST NOT generate data packets larger that its transport layer is > willing to send, even if the remote end would be willing to > accept very large packets. > > Although I feel this text is much too long, and we probably shouldn't > say anything about this at all if we can't say it more concisely. The > first point is a clarification of the actual wire protocol, it says > that if the other end advertises a huge maximum packet size, it can > also be expected to accept huge packets, and in this case it is safe > to send packets larger than 32768 bytes. The second point is almost > self-evident; if your transport layer can't send a 10 MB packet, don't > do that, and don't rely in the *remote* end to advertize a maximum > packet size that is supported by your implementation. > > Regards, > /Niels > ---559023410-1903590565-1131588960=:4527-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:28:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2Ay-0005mT-HS for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:28:32 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28097 for ; Wed, 9 Nov 2005 21:28:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 30C9D63B1E1; Thu, 10 Nov 2005 02:28:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 02E0F63B167 for ; Thu, 10 Nov 2005 02:28:27 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2005 18:27:25 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2RNZD006793; Wed, 9 Nov 2005 18:27:24 -0800 (PST) Date: Wed, 9 Nov 2005 18:27:23 -0800 (PST) From: Chris Lonvick To: Jon Bright cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <436241AF.9000707@siliconcircus.com> Message-ID: References: <1130446268.1347.408.camel@thunk> <436241AF.9000707@siliconcircus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Fri, 28 Oct 2005, Jon Bright wrote: > Bill Sommerfeld wrote: >> >> draft-ietf-secsh-userauth-27.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4252.txt > > Section 5.2: "Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and > MAY return it with a list of authentication 'method name' values." - the > "that can continue" phrase has been lost here. I remember recently seeing a > discussion about OpenSSH being unable to determine what can or cannot > continue and hence returning a list of all available methods - but was this > change in the draft desired? Good catch. It's been that way for some time but SSH_MSG_USERAUTH_FAILURE only has 'authentications that can continue' - which can only come from the server. > > Section 8, third paragraph: "Systems supporting non-ASCII passwords SHOULD > always normalize passwords and user names whenever they are added to the > database, or compare them (with or without hashing) to existing entries in > the database." - the "username" -> "user name" change seems fine, but the > "compared" -> "compare them" change seems to have erroneously changed the > meaning of the sentence. I'll change that. > >> draft-ietf-secsh-transport-24.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4253.txt > > Section 4: "SSH works over any 8-bit, clean, binary-transparent transport. > The underlying transport SHOULD protect against transmission errors, as such > errors cause the SSH connection to terminate." - the first comma added here > is incorrect. The transport's "8-bit clean", not "8-bit" and "clean", much > as the concept of a clean and tidy transport is appealing. Changing it to > "8-bit-clean" might emphasise the point. I'll go back to "8-bit clean". > > 6.1: "The maximum of 35000 bytes is an arbitrarily chosen value that is > larger than uncompressed size." - should probably be something like "...that > is larger than the uncompressed payload length above." See later note. > > 6.3: "The ciphers in each direction MUST run independent of each other." > -> "The ciphers in each direction MUST run independently of one another."? I'll stick with the original. > > 6.5: "SSH maintains its own group identifier space that is logically distinct > from Oakley..." - I found "which" much better in this context, but see the > note at the start of my previous mail. Maybe it's just me. > Maybe I'm wrong. I'll reconsider "which"es and "that"s if someone really presses. > > 8, paragraph 2: "...and I_S is S's KEXINIT message that have been exchanged > before this part begins." - again, I preferred "which". But it should > definitely be "has", not "have". "Exchanged" also seems wrong. Maybe > "...and I_S is S's KEXINIT message, as previously sent from S to C."? I made some changes to this paragraph but it really is "have". See my note about the proposed changes. > > 8, further down: "Either side MUST NOT send or accept 'e' or 'f' values that > are not in the range [1, p-1]." should probably be "Values of 'e' or 'f' that > are not in the range [1, p-1] MUST NOT be sent or accepted by either side." Again, I've made some changes. Please review. > >> draft-ietf-secsh-connect-25.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4254.txt > > 6.5, penultimate paragraph: "It is RECOMMENDED that the reply for these > messages be requested and checked ." - an extra space has crept in here. Yup. > > 6.9: "'signal names' will be encoded as discussed in the "exit-signal" > SSH_MSG_CHANNEL_REQUEST." - there's no field here called 'signal names'. > I think the text should be "Signal names..." as before. Got it. > > 6.10: If I'm following the quoting conventions used here correctly, 'signal > name' here should be swapped for "signal name". Yup. > > 7.1: ""localhost" means to listen on all protocol families supported by the > SSH implementation on loopback addresses only ([RFC3330] and [RFC3513])." - > probably add a "see" at the start of the parenthesis? OK > > 7.2: "The 'originator IP address' is the numeric IP address of the machine > where the connection request comes from, and the 'originator port' is the > port on the host from where the connection originated." - should probably be > "...from which the connection originated."? I made some changes here. > >> draft-ietf-secsh-dns-05.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4255-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4255.txt Not my document. :) > > 1: In other places, at least initial references to "SSH" have been expanded > to be "Secure Shell (SSH)". Here not. > > Didn't spot anything else in this document. > >> draft-ietf-secsh-auth-kbdinteract-07.txt: >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html >> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4256.txt > > Abstract: "The Secure Shell Protocol (SSH) is..." should perhaps be "The > Secure Shell (SSH) protocol is..."? > > 3.1: If the "language tag is deprecated and SHOULD be the empty string", then > it's surely not "as defined in [RFC-3066]"? Should the 3066 reference maybe > move down to the "If the language tag is not the empty string..." paragraph? > > 3.2: As for 3.1 (or not, if I'm wrong). Further down, I'm pretty sure > "backended" isn't a word (since "back end"/"backend" isn't a verb). I'm not > too vehement on the point, but this may be a stumbling block for non-native > English speakers. > > 3.4: (Similarly to section 8 of userauth.) "Systems supporting non-ASCII > passwords SHOULD always normalize passwords and user names whenever they are > added to the database, or compare them (with or without hashing) to existing > entries in the database.". The "username" -> "user name" change from > userauth hasn't been applied here (though that doesn't really bother me). > Again, the "compared" -> "compare them" change seems to have erroneously > changed the meaning of the sentence. > > -- > Jon Bright > Silicon Circus Ltd. > http://www.siliconcircus.com > Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:28:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2BP-0005yZ-Gg for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:28:59 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28118 for ; Wed, 9 Nov 2005 21:28:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C556663B218; Thu, 10 Nov 2005 02:28:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 9AC3C63B259 for ; Thu, 10 Nov 2005 02:28:53 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Nov 2005 18:28:54 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="363124875:sNHT29666412" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2Sqbi029947 for ; Wed, 9 Nov 2005 18:28:52 -0800 (PST) Date: Wed, 9 Nov 2005 18:28:52 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: authors 48 hours: RFC 4251 NOW AVAILABLE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Again. Thanks, Chris === 1) There is an inconsistency in the spellings of "implementer" and "implementor". Since all other RFCs use "implementer" in their Intellectual Property section, please change all instances of "implementor" to "implementer". 2) Section 4.1, 5th paragraph - insert a clause in a line OLD: available on the Internet, this option makes the protocol much more NEW: available on the Internet at the time of this writing, this option ^^^^^^^^^^^^^^^^^^^^^^^^^^^ makes the protocol much more... 3) Section 4.1, last paragraph - restore the previous wording OLD: Thus, providing the option to not check the server host key is ^^^^^^ NEW: Thus, providing the option not to check the server host key is ^^^^^^ 4) Section 4.3, third bullet in the first paragraph - modify a line OLD: depend on the location from which the user is trying to log in. NEW: depend on the location from where the client is trying to gain access. 5) Section 4.4, last paragraph - modify a line OLD: Specific concessions were made to make widespread fast deployment NEW: Specific concessions were made to make widespread, fast deployment ^ 6) Section 4.5, next to last paragraph - reword the last line OLD: names. Straight, bit-wise, binary comparison is RECOMMENDED. ^ ^ NEW: names. Straight bit-wise binary comparison is RECOMMENDED. 7) Section 5.4, third paragraph - remove a comma OLD: names. Straight, bit-wise, binary comparison is RECOMMENDED. ^ NEW: names. Straight bit-wise, binary comparison is RECOMMENDED. 8) Section 6, first bullet in second paragraph - add a clause OLD: at-sign ("@"), a comma (","), whitespace, or control characters ^^^ (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT NEW: at-sign ("@"), a comma (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ case-sensitive, and MUST NOT 9) Section 6, second bullet in second paragraph - replace the bullet/paragraph OLD: o Anyone can define additional algorithms or methods by using names in the format name@domainname, e.g., "ourcipher-cbc@example.com". The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified domain name [RFC1034] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It should be noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822]. NEW: o Anyone can define additional algorithms or methods by using names in the format name@domainname, e.g., "ourcipher-cbc@example.com". The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). They MUST have only a single at-sign in them. The part following the at-sign MUST be a valid, fully qualified domain name [RFC1034] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It should be noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822]. 10) Section 8, third paragraph - replace the paragraph OLD: These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ("@"), comma (","), whitespace, or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. NEW: These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ("@"), comma (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are case-sensitive, and MUST NOT be longer than 64 characters. 11) Section 8, last paragraph - replace the paragraph OLD: Message numbers (see Section 7) in the range of 0..191 are allocated via IETF CONSENSUS as described in [RFC2434]. Message numbers in the 192..255 range (the "Local extensions" set) are reserved for PRIVATE USE, also as described in [RFC2434]. NEW: Message numbers (see Section 7) in the range of 0 to 191 are allocated via IETF CONSENSUS, as described in [RFC2434]. Message numbers in the 192 to 255 range (local extensions) are reserved for PRIVATE USE, also as described in [RFC2434]. 12) Section 9, fourth paragraph - replace the paragraph OLD: The connection protocol [SSH-CONNECT] specifies a mechanism to multiplex multiple streams (channels) of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. NEW: The connection protocol [SSH-CONNECT] specifies a mechanism to multiplex multiple streams (channels) of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for proxy-forwarding various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure subsystems on the server host. 13) Section 9.2 - replace a line OLD: When displaying text, such as error or debug messages to the user, New: When displaying text to a user, such as error or debug messages, 14) Section 9.3.1, third paragraph - replace a word in a line OLD: considered fully practicable, especially if relatively longer block ^^^^^^ NEW: considered fully practicable, especially if relatively long block 15) Section 9.3.1, fourth paragraph - remove a comma OLD: of the next block that is going to be encrypted. In CBC mode, that ^ NEW: of the next block that is going to be encrypted. In CBC mode that 16) Section 9.3.1, fifth paragraph - change a word OLD: from the kernel or buffers. If there are no unsent packages, then a ^^^^^^^^ NEW: from the kernel or buffers. If there are no unsent packets, then a 17) Section 9.3.1, seventh paragraph, bullet "2" - replace a word in a line OLD: 2. Record 2 is *not* at the beginning of the TCP segment and never ^^^^^ NEW: 2. Record 2 is not at the beginning of the TCP segment and never 18) Section 9.3.1, eighth paragraph - replace the paragraph OLD: As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. NEW: As this example indicates, it is unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether an empty packet is needed, since when the second write() is performed the buffers will contain the un-ACKed Record 1. 19) Section 9.3.1, ninth paragraph - replace a word in the first line OLD: On the other hand, it's perfectly safe to have the following ^^^^ NEW: On the other hand, it is perfectly safe to have the following 20) Section 9.3.3, first paragraph - add a reference OLD: protocol uses this to prevent replay of signatures from previous NEW: protocol ([SSH-USERAUTH]) uses this to prevent replay of signatures from previous... 21) In Section 9.3.3, second paragraph - remove a word in the second paragraph OLD: more so true when specifying larger hash function outputs and DH ^^ NEW: more true when specifying larger hash function outputs and DH 22) Section 9.3.3, third paragraph - remove an inserted comma OLD: the session stays active long enough, however, this sequence number number, will wrap ^ NEW: the session stays active long enough, however, this sequence number number will wrap. 23) Section 9.3.4, last paragraph - modify some words OLD: non-security critical environments, and will still provide protection ^ NEW: non-security-critical environments, and will still provide protection 24) Section 9.3.5, first paragraph - remove double quotes OLD: Denial of service attacks of this type ("wire cutter") are almost ^ ^ NEW: Denial of service attacks of this type (wire cutter) are almost 25) Section 9.3.5, last paragraph - change wording OLD: of IPs known to have valid users. ^^^ NEW: of clients known to have valid users. 26) Section 9.3.7, first paragraph - remove double quotes OLD: the diffie-hellman methods described in the section "Diffie-Hellman ^ Key Exchange" of [SSH-TRANS] (including diffie-hellman-group1-sha1 ^ NEW: the diffie-hellman methods described in the section Diffie-Hellman Key Exchange of [SSH-TRANS] (including "diffie-hellman-group1-sha1" ^ ^ 27) Section 9.3.8, first paragraph - remove double quotes OLD: As stated in the section on "Algorithm Negotiation" of [SSH-TRANS], ^ ^ NEW: As stated in the section on Algorithm Negotiation of [SSH-TRANS], 28) Section 9.3.9, - change a word OLD: attempts of traffic analysis. Other methods may also be found and ^^ NEW: attempts at traffic analysis. Other methods may also be found and 29) Section 9.4, last paragraph - remove double quotes OLD: The server may go into a "sleep" period after repeated unsuccessful ^ ^ NEW: The server may go into a sleep period after repeated unsuccessful 30) Section 9.4.3, second paragraph - remove single quotes and add a hyphen OLD: lines of 'anything goes' where there are no restrictions placed upon ^ ^ ^ NEW: lines of anything-goes where there are no restrictions placed upon 31) Section 9.4.3, second paragraph - remove single quotes and add a hyphen OLD: users, or it may be along the lines of 'excessively restrictive', in ^ ^ ^ NEW: users, or it may be along the lines of excessively-restrictive, in 32) Section 9.4.3, last paragraph - change wording in a line OLD: this policy to meet their needs. Alternatively, it may be some ^^^^^^^^^^^ NEW: the initial default parameters to meet their needs. Alternatively, it may be some... 33) Section 9.4.3, last paragraph - change case of MUST OLD: effort to get SSH working. Whatever choice is made MUST be applied ^^^^ NEW: effort to get SSH working. Whatever choice is made must be applied 34) Section 9.4.4, last paragraph - change words in the last line OLD: server (see section on password authentication below.) ^ ^ NEW: server (see the section on Password Authentication below.) ^^^ 35) Section 9.5.1, last two paragraphs - combine the paragraphs and make some nit changes OLD: If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be targeted in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. NEW: If the client has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementers SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be targeted in port-forwarding operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 36) Section 10.2 - modify the reference to FIPS-180-2 OLD: [FIPS-180-2] National Institute of Standards and Technology, NEW: [FIPS-180-2] US National Institute of Standards and Technology, 37) Section 10.2 - modify the reference to FIPS-186-2 OLD: [FIPS-186-2] National Institute of Standards and Technology, NEW: [FIPS-186-2] US National Institute of Standards and Technology, 38) Section 10.2 - properly indent the reference for FIPS-197 and modify OLD: [FIPS-197] National Institute of Standards NEW: [FIPS-197] US National Institute of Standards and Technology, === ---------- Forwarded message ---------- Date: Wed, 26 Oct 2005 16:11:01 -0700 From: RFC Editor To: ylo@ssh.com, clonvick@cisco.com Cc: RFC Editor , Russ Housley , Sam Hartman , sommerfeld@sun.com Subject: authors 48 hours: RFC 4251 NOW AVAILABLE ****IMPORTANT***** Updated 2005/10/26 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-secsh-architecture-22.txt, once the document is published as an RFC we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt ATTENTION: The editing process occasionally introduces errors that were not in the Internet Draft. Although the RFC Editor tries very hard to catch all errors, proofreading the text at least twice, typos can slip through. You, as an author of the RFC, are taking responsibility for the correctness of the final product when you OK publication. You should therefore proofread the entire RFC carefully and without assumptions. Errors in RFCs last forever. NOTE: We have run a diff tool that compares the approved internet-draft against our edited RFC version of the document. Please review this file at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html The document will NOT BE PUBLISHED until ALL of the authors listed in the RFC have affirmed that the document is ready to be published, as ALL of the authors are equally responsible for verifying the documents readiness for publication. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary This document will NOT be published until we receive agreement, from ALL listed authors, that the document is ready for publication. Thanks for your cooperation, -RFC Editor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:29:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2Bg-0006A9-HD for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:29:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28136 for ; Wed, 9 Nov 2005 21:28:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AA8F863B23A; Thu, 10 Nov 2005 02:29:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 599FA63B24F for ; Thu, 10 Nov 2005 02:29:11 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2005 18:29:11 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="673451288:sNHT37557970" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2T94B017235 for ; Wed, 9 Nov 2005 18:29:10 -0800 (PST) Date: Wed, 9 Nov 2005 18:29:09 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: authors 48 hours: RFC 4252 NOW AVAILABLE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, === 1) Section 4, second paragraph - change a line OLD: always reject this request, unless the client is to be allowed in ^^^^^^^^^^ NEW: always reject this request, unless the client is to be granted access 2) Section 5, packet description after the first paragrah - the packet syntax is not consistent with the format used in RFC 4254. OLD: byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string method name in US-ASCII The rest of the packet is method-specific. NEW: byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string method name in US-ASCII .... method specific fields follow 3) Section 5.1, 9th paragraph - replace the paragraph OLD: A request that results in further exchange of messages will be aborted by a second request. It is not possible to send a second request without waiting for a response from the server, if the first request will result in a further exchange of messages. No SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method. NEW: A request that requires further messages to be exchanged will be aborted by a subsequent request. A client MUST NOT send a subsequent request if it has not recieved a response from the server for a previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be sent for an aborted method. 4) Section 5.2, second paragraph - replace the paragraph OLD: If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return it with a list of authentication 'method name' values. NEW: If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return it a list of methods that may continue in its 'authentications that can continue' value. 5) Section 5.4, first paragraph - repace the paragraph OLD: In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from '/etc/issue', use "tcp wrappers", or similar software to display a banner before issuing a login prompt. NEW: In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from /etc/issue, use tcp wrappers, or similar software to display a banner before issuing a login prompt. 6) Section 5.4, packet description below second paragraph - remove extra words OLD: string language tag as defined in [RFC3066] NEW: string language tag [RFC3066] 7) Section 6, last paragraph - change a line (consistent with other range notation) OLD: (60...79) reserved for method-specific messages. These messages are NEW: (60 to 79) reserved for method-specific messages. These messages are 8) Section 7, Second paragraph - replace the paragraph OLD: With this method, the possession of a private key serves as authentication. This method works by sending a 'signature' created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the 'signature' is valid. If both hold, the authentication request MUST be accepted; otherwise, it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) NEW: With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise, it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) 9) Section 7, third paragraph - insert words OLD: authentication using the key would be acceptable. NEW: authentication using the "publickey" method would be acceptable. 10) Section 8, second paragraph - remove a comma OLD: From an internationalization standpoint, it is desired that, if a ^ NEW: From an internationalization standpoint, it is desired that if a 11) Section 8, second paragraph - change the wording OLD: added to the database, or compare them (with or without hashing) to ^^^^^^^^^^^^ NEW: added to the database, or compared (with or without hashing) to 12) Section 8, packet description after 5th paragraph - remove words OLD: string language tag as defined in [RFC3066] NEW: string language tag [RFC3066] 13) Section 9, in the fourth paragraph - add a reference OLD: key' are defined in the transport layer specification. The 'public NEW: key' are defined in the transport layer specification [RFC4253]. The 'public 14) Section 9, the last paragraph - change a line OLD: It is RECOMMENDED that, whenever possible, the server perform NEW: Whenever possible, it is RECOMMENDED that the server perform === ---------- Forwarded message ---------- Date: Wed, 26 Oct 2005 16:12:33 -0700 From: RFC Editor To: ylo@ssh.com, clonvick@cisco.com Cc: RFC Editor , Russ Housley , Sam Hartman , sommerfeld@sun.com Subject: authors 48 hours: RFC 4252 NOW AVAILABLE ****IMPORTANT***** Updated 2005/10/26 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-secsh-userauth-27.txt, once the document is published as an RFC we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252.txt ATTENTION: The editing process occasionally introduces errors that were not in the Internet Draft. Although the RFC Editor tries very hard to catch all errors, proofreading the text at least twice, typos can slip through. You, as an author of the RFC, are taking responsibility for the correctness of the final product when you OK publication. You should therefore proofread the entire RFC carefully and without assumptions. Errors in RFCs last forever. NOTE: We have run a diff tool that compares the approved internet-draft against our edited RFC version of the document. Please review this file at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html The document will NOT BE PUBLISHED until ALL of the authors listed in the RFC have affirmed that the document is ready to be published, as ALL of the authors are equally responsible for verifying the documents readiness for publication. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary This document will NOT be published until we receive agreement, from ALL listed authors, that the document is ready for publication. Thanks for your cooperation, -RFC Editor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:29:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2C8-0006RV-QO for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:29:44 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28183 for ; Wed, 9 Nov 2005 21:29:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 603D863B24F; Thu, 10 Nov 2005 02:29:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id E18D363B24A for ; Thu, 10 Nov 2005 02:29:38 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2005 18:28:37 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2SZZD008071 for ; Wed, 9 Nov 2005 18:28:36 -0800 (PST) Date: Wed, 9 Nov 2005 18:28:35 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: authors 48 hours: RFC 4250 NOW AVAILABLE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Here's what I intend to send to the RFC Editors. Please review and send specific edits or comments to the list. Thanks, Chris === 1) Section 4.1.2, remove the following lines from the table SSH_MSG_KEXDH_INIT 30 [SSH-TRANS] SSH_MSG_KEXDH_REPLY 31 [SSH-TRANS] 2) Section 4.3.4, first bullet after first paragraph - remove a comma OLD: consistent with the proposed, local 'channel type'. It is assumed ^ NEW: consistent with the proposed local 'channel type'. It is assumed 3) Section 4.5 - replace the paragraph OLD: SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain "encoded terminal modes". These "encoded terminal modes" are opcode-argument pairs consisting of an opcode and an argument. NEW: SSH_MSG_CHANNEL_REQUEST messages with a "pty-req" string MUST contain 'encoded terminal modes'. The 'encoded terminal modes' value is a byte stream of opcode-argument pairs. 4) Section 4.5.1, first paragraph - replace the paragraph OLD: Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with a "pty-req" string MUST contain "encoded terminal modes" with an opcode of 1 byte. The opcode values are in the range of 1 to 255. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined. NEW: Protocol packets containing the SSH_MSG_CHANNEL_REQUEST message with a "pty-req" string MUST contain a 'encoded terminal modes' value. The opcode values consist of a single byte and are in the range of 1 to 255. Opcodes 1 to 159 have a uint32 argument. Opcodes 160 to 255 are not yet defined. 5) Section 4.5.2, first paragraph - replace the paragraph OLD: The following table identifies the initial assignments of the opcode and argument values that make up the "encoded terminal modes" values. NEW: The following table identifies the initial assignments of the opcode values that are used in the 'encoded terminal modes' value. 6) Section 4.5.2, table - replace the table header OLD: opcode argument description ^^^^^^^^ NEW: opcode mnemonic description 7) Section 4.5.2, table - reinstate deleted text OLD: 52 XCASE Enable input and output of uppercase characters by preceding their lowercase equivalents with " NEW: 52 XCASE Enable input and output of uppercase characters by preceding their lowercase equivalents with "\". ^^^ 8) Section 4.6.1, first paragraph - add a clause OLD: at-sign ("@"), a comma (","), whitespace, or control characters ^^^ (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT NEW: at-sign ("@"), a comma (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). Names are ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ case-sensitive, and MUST NOT ... 9) Section 4.6.1, third paragraph - replace the paragraph OLD: Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceding the at-sign is the name. The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified internet domain name [RFC1034] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). NEW: Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceding the at-sign is the name. The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), whitespace, control characters (ASCII codes 32 or less), or the ASCII code 127 (DEL). They MUST have only a single at-sign in them. The part following the at-sign MUST be a valid, fully qualified internet domain name [RFC1034] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [RFC0822] email addresses. This is purely coincidental and has nothing to do with STD 11 [RFC0822]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). 10) Section 4.6.2, first paragraph - change the case of Name OLD: Requests for assignments of new Names MUST be done through the IETF ^ NEW: Requests for assignments of new names MUST be done through the IETF 11) Section 4.7, first paragraph - replace the paragraph OLD: The Service Name is used to describe a protocol layer. The following table lists the initial assignments of the Service Names. NEW: The 'service name' is used to describe a protocol layer. The following table lists the initial assignments of the 'service name' values. 12) Section 4.9.5 - substitute "to" for "of" OLD: There are no initial assignments of the Connection Protocol Subsystem ^^ NEW: There are no initial assignments to the Connection Protocol Subsystem ^^ 13) Section 4.10, first paragraph - quote a value OLD: diffie-hellman-group14-sha1 for the name of the second defined group. NEW: "diffie-hellman-group14-sha1" for the name of the second defined group. ^ ^ 14) Section 4.10, second paragraph - remove a dash OLD: The following table identifies the initial assignments of the key- ^ NEW: The following table identifies the initial assignments of the key 15) Section 4.11.1, FIPS-46-3 reference - insert a dash OLD: des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-3] ^ NEW: des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS-46-3] 16) Section 6.2, FIPS-46-3 reference - modify the reference to FIPS-46-3 OLD: [FIPS-46-3] National Institute of Standards and Technology, "Data NEW: [FIPS-46-3] US National Institute of Standards and Technology, ^^ === ---------- Forwarded message ---------- Date: Wed, 26 Oct 2005 16:09:38 -0700 From: RFC Editor To: sjl@ssh.com, clonvick@cisco.com Cc: RFC Editor , Russ Housley , Sam Hartman , sommerfeld@sun.com Subject: authors 48 hours: RFC 4250 NOW AVAILABLE ****IMPORTANT***** Updated 2005/10/26 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-secsh-assignednumbers-12.txt, once the document is published as an RFC we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt ATTENTION: The editing process occasionally introduces errors that were not in the Internet Draft. Although the RFC Editor tries very hard to catch all errors, proofreading the text at least twice, typos can slip through. You, as an author of the RFC, are taking responsibility for the correctness of the final product when you OK publication. You should therefore proofread the entire RFC carefully and without assumptions. Errors in RFCs last forever. NOTE: We have run a diff tool that compares the approved internet-draft against our edited RFC version of the document. Please review this file at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html The document will NOT BE PUBLISHED until ALL of the authors listed in the RFC have affirmed that the document is ready to be published, as ALL of the authors are equally responsible for verifying the documents readiness for publication. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary This document will NOT be published until we receive agreement, from ALL listed authors, that the document is ready for publication. Thanks for your cooperation, -RFC Editor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:29:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2CI-0006WL-04 for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:29:54 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28205 for ; Wed, 9 Nov 2005 21:29:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 862BE63B167; Thu, 10 Nov 2005 02:29:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 4B31363B262 for ; Thu, 10 Nov 2005 02:29:46 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2005 18:29:46 -0800 X-IronPort-AV: i="3.97,310,1125903600"; d="scan'208"; a="673451363:sNHT39739268" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2Ti4B017468 for ; Wed, 9 Nov 2005 18:29:45 -0800 (PST) Date: Wed, 9 Nov 2005 18:29:44 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: authors 48 hours: RFC 4253 NOW AVAILABLE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Once more... === 1) Section 4, first paragaph - remove a comma OLD: SSH works over any 8-bit, clean, binary-transparent transport. The ^ NEW: SSH works over any 8-bit clean, binary-transparent transport. The 2) Section 5.1, first paragraph - replace the paragraph OLD: Server implementations MAY support a configurable "compatibility" flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its protocol version as "1.99". Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode, the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. NEW: Server implementations MAY support a configurable compatibility flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its 'protoversion' as "1.99". Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode, the server SHOULD NOT send the Carriage Return character (ASCII 13) after the identification string. 3) Section 5.1, second paragraph - replace the paragraph OLD: In the compatibility mode, the server SHOULD NOT send any further data after its initialization string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the version string. NEW: In the compatibility mode, the server SHOULD NOT send any further data after sending its identification string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the identification string. 4) Section 5.2, first paragraph - reword the second line OLD: identification string (before receiving server's identification), the NEW: identification string (before receiving the server's identification string), the 5) Section 6.1, first paragraph - revise a line OLD: larger packets MAY be sent if the version string indicates that the ^^^^^^^ NEW: larger packets MAY be sent if the identification string indicates that the ^^^^^^^^^^^^^^ 6) Section 6.1, first paragraph - revise a line OLD: than uncompressed size. NEW: than the uncompressed length noted above. 7) Section 6.4, third paragraph - replace the paragraph OLD: where 'unencrypted_packet' is the entire packet without 'mac' (the length fields, 'payload' and 'random padding'), and 'sequence_number' is an implicit packet sequence number represented as uint32. The 'sequence_number' is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet 'sequence_number' itself is not included in the packet sent over the wire. NEW: where unencrypted_packet is the entire packet without 'mac' (the length fields, 'payload' and 'random padding'), and sequence_number is an implicit packet sequence number represented as uint32. The sequence_number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence_number itself is not included in the packet sent over the wire. 8) Section 6.4, fourth paragraph - add a sentence OLD: The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. NEW: The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. In practice however, it is RECOMMENDED that the same algorithm be used in both directions. 9) Section 7, 5th paragraph - replace the paragraph OLD: A key exchange method uses "explicit server authentication" if the key exchange messages include a signature or other proof of the server's authenticity. A key exchange method uses "implicit server authentication" if, in order to prove its authenticity, the server also has to prove that it knows the shared secret, K, by sending a message and a corresponding MAC that the client can verify. NEW: A key exchange method uses explicit server authentication if the key exchange messages include a signature or other proof of the server's authenticity. A key exchange method uses implicit server authentication if, in order to prove its authenticity, the server also has to prove that it knows the shared secret, K, by sending a message and a corresponding MAC that the client can verify. 10) Section 7.1, packet description - please do not split this over a page boundary 11) Section 7.1, fourth paragraph (not including bulleted items) - add keywords OLD: After the KEXINIT packet exchange, the key exchange algorithm is run. NEW: After the SSH_MSG_KEXINIT message exchange, the key exchange algorithm is run. ... 12) Section 7.1, fifth paragraph and bulleted items - replace the paragraph an bullet OLD: Once a party has sent a KEXINIT message for key exchange or re- exchange, until it has sent a NEWKEYS message (Section 7.3), it MUST NOT send any messages other than: o Transport layer generic messages (1 to 19) (but SERVICE_REQUEST and SERVICE_ACCEPT MUST NOT be sent); o Algorithm negotiation messages (20 to 29) (but further KEXINITs MUST NOT be sent); o Specific key exchange method messages (30 to 49). NEW: Once a party has sent a SSH_MSG_KEXINIT message for key exchange or re-exchange, until it has sent a SSH_MSG_NEWKEYS message (Section 7.3), it MUST NOT send any messages other than: o Transport layer generic messages (1 to 19) (but SSH_MSG_SERVICE_REQUEST and SSH_MSG_SERVICE_ACCEPT MUST NOT be sent); o Algorithm negotiation messages (20 to 29) (but further SSH_MSG_KEXINIT messages MUST NOT be sent); o Specific key exchange method messages (30 to 49). 13) Section 7.1, seventh paragraph - replace the paragraph OLD: Note, however, that during a key re-exchange, after sending a KEXINIT message, each party MUST be prepared to process an arbitrary number of messages that may be in-flight before receiving a KEXINIT from the other party. NEW: Note, however, that during a key re-exchange, after sending a SSH_MSG_KEXINIT message, each party MUST be prepared to process an arbitrary number of messages that may be in-flight before receiving a SSH_MSG_KEXINIT messages from the other party. 14) Section 7.2, first paragraph - insert an additional space after a period OLD: exchange hash H. Encryption and authentication keys are derived from ^ NEW: exchange hash H. Encryption and authentication keys are derived from 15) Section 8, second paragraph with bullets - replace the paragraph with bullets - do not break the bulleted sections across page boundaries OLD: The following steps are used to exchange a key. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S is S's KEXINIT message that have been exchanged before this part begins. 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. NEW: The following steps are used to exchange a key. In this, C is the client; S is the server; p is a large safe prime; g is a generator for a subgroup of GF(p); q is the order of the subgroup; V_S is S's identification string; V_C is C's identification string; K_S is S's public host key; I_C is C's SSH_MSG_KEXINIT message and I_S is S's SSH_MSG_KEXINIT message that have been exchanged before this part begins. 1. C generates a random number x (1 < x < q) and computes 'e' = g^x mod p. C sends 'e' to S. 2. S generates a random number y (0 < y < q) and computes 'f' = g^y mod p. S receives 'e'. It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and s ('signature of H') with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g., using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the 'signature of H' (s). 16) Section 8, third paragraph - replace the paragraph OLD: Either side MUST NOT send or accept 'e' or 'f' values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. NEW: Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be sent or accepted by either side. If this condition is violated, the key exchange fails. 17) Section 8, fourth paragraph - modify a word in a line OLD: the KEXINIT messages. NEW: the SSH_MSG_KEXINIT messages. 18) Section 11.1, packet description - add description in a line OLD: string description [RFC3629] NEW: string description in ISO-10646 UTF-8 encoding [RFC3629] 19) Section 11.2, first paragraph - change a word OLD: time (after receiving the protocol version). No implementation is ^^^^^^^^^^^^^^^^ NEW: time (after receiving the identification string). No implementation is ^^^^^^^^^^^^^^^^^^^^^ 20) Section 11.3, message description - add description to a line OLD: string message [RFC3629] NEW: string message in ISO-10646 UTF-8 encoding [RFC3629] 21) Section 12, table - remove the following lines REMOVE: SSH_MSG_KEXDH_INIT 30 SSH_MSG_KEXDH_REPLY 31 22) Section 15.1, all FIPS references - Add "US" before "National..." OLD: [FIPS-180-2] National Institute of Standards and Technology, NEW: [FIPS-180-2] US National Institute of Standards and Technology, 23) Section 15.1, all FIPS references - Add "US" before "National..." OLD: [FIPS-186-2] National Institute of Standards and Technology, NEW: [FIPS-186-2] US National Institute of Standards and Technology, 24) Section 15.1, all FIPS references - Add "US" before "National..." OLD: [FIPS-197] National Institute of Standards and Technology, NEW: [FIPS-197] US National Institute of Standards and Technology, 25) Section 15.1, all FIPS references - Add "US" before "National..." OLD: [FIPS-46-3] National Institute of Standards and Technology, "Data NEW: [FIPS-46-3] US National Institute of Standards and Technology, "Data... === ---------- Forwarded message ---------- Date: Wed, 26 Oct 2005 16:13:50 -0700 From: RFC Editor To: ylo@ssh.com, clonvick@cisco.com Cc: RFC Editor , Russ Housley , Sam Hartman , sommerfeld@sun.com Subject: authors 48 hours: RFC 4253 NOW AVAILABLE ****IMPORTANT***** Updated 2005/10/26 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-secsh-transport-24.txt, once the document is published as an RFC we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253.txt ATTENTION: The editing process occasionally introduces errors that were not in the Internet Draft. Although the RFC Editor tries very hard to catch all errors, proofreading the text at least twice, typos can slip through. You, as an author of the RFC, are taking responsibility for the correctness of the final product when you OK publication. You should therefore proofread the entire RFC carefully and without assumptions. Errors in RFCs last forever. NOTE: We have run a diff tool that compares the approved internet-draft against our edited RFC version of the document. Please review this file at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html The document will NOT BE PUBLISHED until ALL of the authors listed in the RFC have affirmed that the document is ready to be published, as ALL of the authors are equally responsible for verifying the documents readiness for publication. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary This document will NOT be published until we receive agreement, from ALL listed authors, that the document is ready for publication. Thanks for your cooperation, -RFC Editor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 09 21:30:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea2Ci-0006zs-BH for secsh-archive@megatron.ietf.org; Wed, 09 Nov 2005 21:30:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28245 for ; Wed, 9 Nov 2005 21:29:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 564EE63B259; Thu, 10 Nov 2005 02:30:16 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id BB81863B24A for ; Thu, 10 Nov 2005 02:30:13 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2005 18:30:14 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAA2UCZD008903 for ; Wed, 9 Nov 2005 18:30:12 -0800 (PST) Date: Wed, 9 Nov 2005 18:30:12 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: authors 48 hours: RFC 4254 NOW AVAILABLE (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Last one. === 1) Section 1, first paragraph - insert references OLD: SSH transport layer and user authentication protocols. It provides NEW: SSH transport layer and user authentication protocols ([SSH-TRANS] and [SSH-USERAUTH]). It provides... 2) Section 1, first paragraph - The last sentence needs to be a separate paragraph (consistent with [SSH-USRAUTH] OLD: TCP/IP connections, and forwarded X11 connections. The service name for this protocol is "ssh-connection". NEW: TCP/IP connections, and forwarded X11 connections. The 'service name' for this protocol is "ssh-connection". 3) Section 4, packet definition after third paragraph - change five dots to four OLD: ..... response specific data ^ NEW: .... response specific data 4) Section 5.1, packet definition after fourth paragraph - remove unneeded words OLD: string language tag as defined in [RFC3066] ^^^^^^^^^^^^^^ NEW: string language tag [RFC3066] 5) Section 5.1, seventh paragraph - add a comma to a line OLD: to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as NEW: to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as ^ 6) Section 5.1, seventh paragraph - add a comma to a line OLD: range are left for PRIVATE USE as described in [RFC2434]. NEW: range are left for PRIVATE USE, as described in [RFC2434]. ^ 7) Section 5.2, fourth paragraph - replace the paragraph OLD: The maximum amount of data allowed is the current window size. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. NEW: The maximum amount of data allowed is determined by the maximum packet size for the channel, and the current window size, whichever is smaller. The window size is decremented by the amount of data sent. Both parties MAY ignore all extra data sent after the allowed window is empty. Implementations are expected to have some limit on the ssh transport layer packet size (any limit for rececived packets MUST be 32768 bytes or larger, as described in [SSH-TRANS]). The implementation of the SSH connection layer o MUST NOT advertise a maximum packet size that would result in transport packets larger than its transport layer is willing to receive. o MUST NOT generate data packets larger that its transport layer is willing to send, even if the remote end would be willing to accept very large packets. 8) Section 5.2, last paragraph - add a comma to a line OLD: 'data_type_code' values in that range are left for PRIVATE USE as NEW: 'data_type_code' values in that range are left for PRIVATE USE, as ^ 9) Section 6.5, next to last paragraph - replace the paragraph OLD: It is RECOMMENDED that the reply for these messages be requested and checked . The client SHOULD ignore these messages. NEW: It is RECOMMENDED that the reply to these messages be requested and checked. The client SHOULD ignore these messages. 10) Section 6.9, packet definition following the first paragraph - modify a line OLD: string signal name without the "SIG" prefix. NEW: string signal name (without the "SIG" prefix) 11) Section 6.9, last paragraph - replace the paragraph OLD: 'signal names' will be encoded as discussed in the "exit-signal" SSH_MSG_CHANNEL_REQUEST. NEW: 'signal name' values will be encoded as discussed in the passage describing SSH_MSG_CHANNEL_REQUEST messages using "exit-signal" in this section. 12) Section 6.10, packet definition following the second paragraph - modify a line OLD: string signal name without the "SIG" prefix. NEW: string signal name (without the "SIG" prefix) 13) Section 6.10, third paragraph - add a period to the line OLD: The 'signal name' is one of the following (these are from [POSIX]) NEW: The 'signal name' is one of the following (these are from [POSIX]). ^ 14) Section 6.10, fourth paragraph - do not break a hyphen segmented name OLD: Additional 'signal name' values MAY be sent in the format "sig- name@xyz", where "sig-name" and "xyz" may be anything a particular NEW: Additional 'signal name' values MAY be sent in the format "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular 15) Section 6.10, fourth paragraph - correct spelling OLD: implementor wants (except the "@" sign). However, it is suggested ^ NEW: implementer wants (except the "@" sign). However, it is suggested 16) Section 6.10, last paragraph - add a clause to a line OLD: error message. The message may consist of multiple lines. The NEW: error message. The message may consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. The... 17) Section 7.2, SSH_MSG_CHANNEL_OPEN packet definition - do not split this across a page break 18) Section 7.2, fifth paragraph - replace the paragraph OLD: The 'originator IP address' is the numeric IP address of the machine where the connection request comes from, and the 'originator port' is the port on the host from where the connection originated. NEW: The 'originator IP address' is the numeric IP address of the machine from where the connection request originates, and the 'originator port' is the port on the host from where the connection originated. 19) Section 8, first two paragraphs - combine the paragraphs into a single paragraph with clarification OLD: All "encoded terminal modes" (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The tty mode description is a stream of bytes. The stream consists of opcode-argument pairs wherein the opcode is a byte value. It is terminated by opcode TTY_OP_END (0x00). Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). NEW: All 'encoded terminal modes' (as passed in a pty request) are encoded into a byte stream. It is intended that the coding be portable across different environments. The stream consists of opcode-argument pairs wherein the opcode is a byte value. Opcodes 1 to 159 have a single uint32 argument. Opcodes 160 to 255 are not yet defined, and cause parsing to stop (they should only be used after any other data). The stream is terminated by opcode TTY_OP_END (0x00). 20) Section 8, table of opcodes - replace the argument header OLD: opcode argument description ^^^^^^^^ NEW: opcode mnemonic description === That's all, folks! ---------- Forwarded message ---------- Date: Wed, 26 Oct 2005 16:15:09 -0700 From: RFC Editor To: ylo@ssh.com, clonvick@cisco.com Cc: RFC Editor , Russ Housley , Sam Hartman , sommerfeld@sun.com Subject: authors 48 hours: RFC 4254 NOW AVAILABLE ****IMPORTANT***** Updated 2005/10/26 RFC AUTHOR(S): -------------- This is your LAST CHANCE to make changes to your RFC to be: draft-ietf-secsh-connect-25.txt, once the document is published as an RFC we *WILL NOT* make any changes. Please check your document at ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254.txt ATTENTION: The editing process occasionally introduces errors that were not in the Internet Draft. Although the RFC Editor tries very hard to catch all errors, proofreading the text at least twice, typos can slip through. You, as an author of the RFC, are taking responsibility for the correctness of the final product when you OK publication. You should therefore proofread the entire RFC carefully and without assumptions. Errors in RFCs last forever. NOTE: We have run a diff tool that compares the approved internet-draft against our edited RFC version of the document. Please review this file at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html The document will NOT BE PUBLISHED until ALL of the authors listed in the RFC have affirmed that the document is ready to be published, as ALL of the authors are equally responsible for verifying the documents readiness for publication. ** Please send us a list of suitable keywords for this document, over and above those which appear in the title. Frequently INCORRECT information includes - Contact Information - References (are they up to date) - Section Numbers (especially if you originally put the copyright somewhere other than the VERY end of the document, or if you numbered the "Status of the Memo" field) Please send us the changes, *DO NOT* send a new document with the changes made. (If we think that the changes might be more than editorial we will contact the AD or the IESG to confirm that the changes do not require review.) Send us the changes in THIS format. 1)*** SECTION #'s*** [i.e. Section 5, 2nd paragraph] 2) the text you want changed, 3) the new correct text and 4) if the changes are spacing or indentation than please note that. FOR EXAMPLE: Section 5.6, 3rd paragraph OLD: The quick brown fox jumped over the lazy dog. NEW: The quick brown dog jumps over the lazy fox. ^^^ ^ ^^^ If you have a whole paragraph to replace you do not need to use the arrow to point out the differences INTRODUCTION, 2nd paragraph Replace OLD: alsdfja;sldjf;lajsd;fljas;dlfj; With NEW: nv;alkjd;lsf;aoisj;ltjka;sldkjf Spacing or indentation problems... Section 10, 1st paragraph (remove spaces between bit and of, add space after butter) OLD: Better botter bought a bit of bitter butterMary mary quite contrary NEW: Better botter bought a bit of bitter butter Mary mary quite contrary This document will NOT be published until we receive agreement, from ALL listed authors, that the document is ready for publication. Thanks for your cooperation, -RFC Editor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 10 02:19:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea6iM-0002By-R7 for secsh-archive@megatron.ietf.org; Thu, 10 Nov 2005 02:19:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12841 for ; Thu, 10 Nov 2005 02:18:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2553763B2B0; Thu, 10 Nov 2005 07:18:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.102]) by mail.netbsd.org (Postfix) with ESMTP id 6A62863B12C for ; Thu, 10 Nov 2005 07:18:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 168C1992DE; Thu, 10 Nov 2005 08:17:01 +0100 (CET) Message-ID: <4372F3CF.3060808@siliconcircus.com> Date: Thu, 10 Nov 2005 08:16:31 +0100 From: Jon Bright User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Chris Lonvick CC: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. References: <1130446268.1347.408.camel@thunk> <436241AF.9000707@siliconcircus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Chris Lonvick wrote: >> >> 6.3: "The ciphers in each direction MUST run independent of each >> other." -> "The ciphers in each direction MUST run independently of >> one another."? > > I'll stick with the original. I maybe shouldn't have put that question mark there. The original is grammatically wrong. "Independent" is an adjective, "independently" is the adverb. Since we're modifying the verb "run" here, we need the adverb. The "each other"/"one another" thing, I don't care about. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 10 09:52:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaDmt-0000KL-N4 for secsh-archive@megatron.ietf.org; Thu, 10 Nov 2005 09:52:27 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07488 for ; Thu, 10 Nov 2005 09:51:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DB05163B287; Thu, 10 Nov 2005 14:52:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 430B763B110 for ; Thu, 10 Nov 2005 14:52:22 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EaDmn-0008WP-00 for ietf-ssh@netbsd.org; Thu, 10 Nov 2005 14:52:21 +0000 Date: Thu, 10 Nov 2005 14:52:21 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: authors 48 hours: RFC 4251 NOW AVAILABLE (fwd) Message-ID: <20051110145221.GA31913@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Are HTML diffs for these changes available? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 10 14:04:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaHiw-0003bQ-OU for secsh-archive@megatron.ietf.org; Thu, 10 Nov 2005 14:04:38 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26472 for ; Thu, 10 Nov 2005 14:04:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8AEE063B297; Thu, 10 Nov 2005 19:04:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id 0374E63B10A for ; Thu, 10 Nov 2005 19:04:30 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2005 11:03:29 -0800 X-IronPort-AV: i="3.99,113,1131350400"; d="scan'208"; a="229039425:sNHT149296886" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAAJ3RZD027392 for ; Thu, 10 Nov 2005 11:03:28 -0800 (PST) Date: Thu, 10 Nov 2005 11:03:27 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: authors 48 hours: RFC 4251 NOW AVAILABLE (fwd) In-Reply-To: <20051110145221.GA31913@chiark.greenend.org.uk> Message-ID: References: <20051110145221.GA31913@chiark.greenend.org.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 10 Nov 2005, Jacob Nevins wrote: > Are HTML diffs for these changes available? > Unfortunately not. I got the text files from the RFC Editors and not the .xml files. Any changes made in that would just be discarded. Please review the proposed changes and I'll submit them to the RFC Editor. Once they get them they'll make up new diffs and I can also create a diff. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 10 17:00:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKTS-0001x8-Bg for secsh-archive@megatron.ietf.org; Thu, 10 Nov 2005 17:00:50 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19253 for ; Thu, 10 Nov 2005 17:00:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E03FF63B240; Thu, 10 Nov 2005 22:00:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 583E263B1DD for ; Thu, 10 Nov 2005 22:00:44 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2005 14:00:44 -0800 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAAM0gZD010265; Thu, 10 Nov 2005 14:00:42 -0800 (PST) Date: Thu, 10 Nov 2005 14:00:41 -0800 (PST) From: Chris Lonvick To: Jon Bright cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <4372F3CF.3060808@siliconcircus.com> Message-ID: References: <1130446268.1347.408.camel@thunk> <436241AF.9000707@siliconcircus.com> <4372F3CF.3060808@siliconcircus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 10 Nov 2005, Jon Bright wrote: > Chris Lonvick wrote: >> > >> > 6.3: "The ciphers in each direction MUST run independent of each other." >> > -> "The ciphers in each direction MUST run independently of one >> > another."? >> >> I'll stick with the original. > > I maybe shouldn't have put that question mark there. The original is > grammatically wrong. "Independent" is an adjective, "independently" is the > adverb. Since we're modifying the verb "run" here, we need the adverb. The > "each other"/"one another" thing, I don't care about. Ahh... that language thing... OK. I'll get the change submitted. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 13 13:03:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbMCG-0004TM-EE for secsh-archive@megatron.ietf.org; Sun, 13 Nov 2005 13:03:20 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23597 for ; Sun, 13 Nov 2005 13:02:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8E28E63B15F; Sun, 13 Nov 2005 18:03:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 760D263B31C for ; Sun, 13 Nov 2005 18:03:14 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EbMC9-0006qR-00 for ietf-ssh@netbsd.org; Sun, 13 Nov 2005 18:03:13 +0000 Date: Sun, 13 Nov 2005 18:03:13 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051113180313.GA21370@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051028134659.GA30930@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Quoting attached message, Ben Harris wrote (14 June): | The following entries in the Public Key Algorithm Names table shouldn't | have been mentioned in draft-ietf-secsh-assignednumbers-12, since they're | not mentioned in draft-ietf-secsh-transport-24: | | pgp-sign-rsa [SSH-TRANS, Section 6.6] | pgp-sign-dss [SSH-TRANS, Section 6.6] This statement doesn't appear to be true. The copy of transport-24 I have mentions "pgp-sign-rsa" and "pgp-sign-dss" (as does every version since at least -09). I missed this before, as I had a recollection that the PGP signature formats had been dropped due to being underspecified. However, there is nothing in the mailing list to indicate that that decision was made (although it was discussed in February). So, for the avoidance of doubt, I now think they should remain in the IANA registry. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 13 13:32:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbMeO-0001FN-Mi for secsh-archive@megatron.ietf.org; Sun, 13 Nov 2005 13:32:24 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24853 for ; Sun, 13 Nov 2005 13:31:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A127A63B325; Sun, 13 Nov 2005 18:32:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 072B763B290 for ; Sun, 13 Nov 2005 18:32:21 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EbMeK-0007JC-00 for ietf-ssh@netbsd.org; Sun, 13 Nov 2005 18:32:20 +0000 Date: Sun, 13 Nov 2005 18:32:20 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? Message-ID: <20051113183220.GA22266@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: > I'm seeing some logged gripes when using my client to connect to > another implementation, and I think it's not my fault - but I want to > check before treating this as someone else's bug. [snip] FWIW, your reading looks fine to me. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 13 13:58:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbN3g-0004x6-S6 for secsh-archive@megatron.ietf.org; Sun, 13 Nov 2005 13:58:32 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25795 for ; Sun, 13 Nov 2005 13:58:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 87C7B63B33D; Sun, 13 Nov 2005 18:58:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id D7BBF63B290 for ; Sun, 13 Nov 2005 18:58:28 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EbN3c-00032W-00 for ietf-ssh@netbsd.org; Sun, 13 Nov 2005 18:58:28 +0000 Date: Sun, 13 Nov 2005 18:58:28 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: authors 48 hours: RFC 4252 NOW AVAILABLE (fwd) Message-ID: <20051113185828.GA9286@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list A couple of miniscule nits. Chris Lonvick writes: > 3) > Section 5.1, 9th paragraph [...] > NEW: [...] > request if it has not recieved a response from the server for a s/recieved/received/ > 5) > Section 5.4, first paragraph [...] > NEW: [...] > use tcp wrappers, or similar software to display a banner before s/tcp/TCP/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 17:22:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecs9b-0004Iv-UW for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 17:22:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00311 for ; Thu, 17 Nov 2005 17:22:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D984963B44E; Thu, 17 Nov 2005 22:22:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 1233E63B44A for ; Thu, 17 Nov 2005 22:22:45 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Ecs9U-0002xJ-00 for ietf-ssh@netbsd.org; Thu, 17 Nov 2005 22:22:44 +0000 Date: Thu, 17 Nov 2005 22:22:44 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051117222244.GA5569@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org References: <1130446268.1347.408.camel@thunk> <20051031142258.GA21786@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051031142258.GA21786@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I wrote: > Bill Sommerfeld writes: > > draft-ietf-secsh-dns-05.txt: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255-diff.html > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255.txt > > The following change appears: > > | [5] Eastlake, D., "Domain Name System Security Extensions", RFC > | 2535, March 1999. > > has been changed to > > | [5] Berc, L., Fenner, W., Frederick, R., McCanne, S., and P. > | Stewart, "RTP Payload Format for JPEG-compressed Video", RFC > | 2435, October 1998. > > That's utterly wrong, surely? I note that this has already been fixed on rfc-editor.org. (It now refers to RFC4033/4/5.) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 17:29:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsFu-0005Td-Gn for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 17:29:22 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00630 for ; Thu, 17 Nov 2005 17:28:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 008DB63B44E; Thu, 17 Nov 2005 22:29:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 32EB463B454 for ; Thu, 17 Nov 2005 22:29:06 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EcsFd-0004KJ-00 for ietf-ssh@netbsd.org; Thu, 17 Nov 2005 22:29:05 +0000 Date: Thu, 17 Nov 2005 22:29:05 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051117222905.GB5569@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1130446268.1347.408.camel@thunk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: > draft-ietf-secsh-auth-kbdinteract-07.txt: > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256.txt Values for SSH_MSG_USERAUTH_INFO_REQUEST and _RESPONSE appear in the section "IANA Considerations", even though they're no concern of IANA, being method-specific. (This is also true of the document that went to the RFC Editor.) Since Chris has removed SSH_MSG_KEXDH_INIT and _REPLY from the table in assignednumbers, I assume we should remove these from this section too (although they'll have to go somewhere else to avoid being lost entirely). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 19:16:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ectv7-00025L-Ty for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 19:16:01 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07088 for ; Thu, 17 Nov 2005 19:15:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1E3AE63B183; Fri, 18 Nov 2005 00:15:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6250363B149 for ; Fri, 18 Nov 2005 00:15:53 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1Ectuy-0001P3-00 for ietf-ssh@netbsd.org; Fri, 18 Nov 2005 00:15:52 +0000 Date: Fri, 18 Nov 2005 00:15:52 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051118001552.GC5569@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436241AF.9000707@siliconcircus.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: > Bill Sommerfeld wrote: > > draft-ietf-secsh-auth-kbdinteract-07.txt: > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html > > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256.txt > > 3.1: If the "language tag is deprecated and SHOULD be the empty string", > then it's surely not "as defined in [RFC-3066]"? Should the 3066 > reference maybe move down to the "If the language tag is not the empty > string..." paragraph? Agree, I think. > 3.2: As for 3.1 (or not, if I'm wrong). In addition, I think the second language tag paragraph in section 3.2 ("If the language tag is not the empty string...") should be mostly cut. It seems to have been lifted straight from 3.1 and doesn't make much sense in 3.2 (talking about requirements it places on the server when it's emitted _by_ the server). However, if that's too drastic at this stage, so be it. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 19:24:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecu3i-0006iX-PP for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 19:24:55 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07542 for ; Thu, 17 Nov 2005 19:24:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 248DE63B218; Fri, 18 Nov 2005 00:24:47 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id 8418E63B279 for ; Fri, 18 Nov 2005 00:24:46 +0000 (UTC) Received: from [192.168.1.106] (unknown [209.76.127.102]) by hoth.savecore.net (Postfix) with ESMTP id F07E92AC4E for ; Thu, 17 Nov 2005 16:24:10 -0800 (PST) Date: Thu, 17 Nov 2005 16:24:01 -0800 From: Frank Cusack To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <67AE3B88A9B41D52891BD13B@maguro.local> In-Reply-To: <20051118001552.GC5569@chiark.greenend.org.uk> References: <20051118001552.GC5569@chiark.greenend.org.uk> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On November 18, 2005 12:15:52 AM +0000 Jacob Nevins wrote: > Jon Bright writes: >> Bill Sommerfeld wrote: >> > draft-ietf-secsh-auth-kbdinteract-07.txt: >> > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html >> > ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256.txt >> >> 3.1: If the "language tag is deprecated and SHOULD be the empty string", >> then it's surely not "as defined in [RFC-3066]"? Should the 3066 >> reference maybe move down to the "If the language tag is not the empty >> string..." paragraph? > > Agree, I think. > >> 3.2: As for 3.1 (or not, if I'm wrong). > > In addition, I think the second language tag paragraph in section 3.2 > ("If the language tag is not the empty string...") should be mostly cut. > It seems to have been lifted straight from 3.1 and doesn't make much > sense in 3.2 (talking about requirements it places on the server when > it's emitted _by_ the server). > > However, if that's too drastic at this stage, so be it. Sorry, I haven't really been paying attention here. Does Martin or myself need to do anything? The changes being proposed sound fine to me. -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 19:42:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcuL9-0005rL-6l for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 19:42:55 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08609 for ; Thu, 17 Nov 2005 19:42:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D43AE63B196; Fri, 18 Nov 2005 00:42:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id B829563B149 for ; Fri, 18 Nov 2005 00:42:50 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EcuL4-0006Xg-00 for ietf-ssh@netbsd.org; Fri, 18 Nov 2005 00:42:50 +0000 Date: Fri, 18 Nov 2005 00:42:50 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: collated comments for -dns (RFC 4255) and -kbdinteract (RFC 4256) Message-ID: <20051118004250.GD5569@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Since there hasn't been any obvious activity on -dns (4255) and -kbdinteract (4256), I've taken it upon myself to collate the comments I've made and seen on the list in the format the RFC Editor appears to want. Since I'm not a listed author, I don't plan to actually send this to the RFC Editor (unless someone suggests that I do); I hope that it saves someone some time. (In fact, now that the references have been fixed, I can't see any edits that -dns desperately needs; so what's below just covers -kbdinteract.) This includes the changes that I recently posted about to the "Eyeballs needed" thread. I could lose the language-tag stuff if it's deemed too disruptive. 1) Abstract - modify a line (for consistency with other documents) OLD: The Secure Shell Protocol (SSH) is a protocol for secure remote login ^^^^^^^^ ^^^^^ NEW: The Secure Shell (SSH) Protocol is a protocol for secure remote login ^^^^^ ^^^^^^^^ 2) Section 3 "Protocol Exchanges" - insert the following text after the 1st paragraph: These are the values of the method-specific constants used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 3) Section 3.1 "Initial Exchange", 2nd para - remove words OLD: string language tag (as defined in [RFC-3066]) ^^^^^^^^^^^^^^^^^^^^^^^^^^ NEW: string language tag 4) Section 3.1 "Initial Exchange", 4th para - insert words OLD: the specified language for any messages sent to the client as part of NEW: the specified language (as defined in [RFC-3066]) for any messages... ^^^^^^^^^^^^^^^^^^^^^^^^^^ 5) Section 3.2 "Information Requests", 4th para - remove words OLD: string language tag (as defined in [RFC-3066]) ^^^^^^^^^^^^^^^^^^^^^^^^^^ NEW: string language tag 6) Section 3.2 "Information Requests", 6th para - replace paragraph OLD: If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. If the server does not support the requested language, the language to be used is implementation-dependent. NEW: If the language tag is not the empty string, it MUST be as defined in [RFC-3066]. 7) Section 3.2 "Information Requests", 7th para - replace text OLD: ...method would typically be backended by [PAM]... ^^^^^^^^^ NEW: ...method would typically be implemented on the server by [PAM]... ^^^^^^^^^^^^^^^^^^^^^^^^^ 8) Section 3.4 "Information Responses", 5th para - modify 2 lines OLD: normalize passwords and usernames whenever they are added to the database, or compare them (with or without hashing) to existing ^^^^^^^^^^^^ NEW: normalize passwords and user names whenever they are added to the ^ database, or compared (with or without hashing) to existing ^^^^^^^^ 9) Section 5 "IANA Considerations" - remove the following text: The following method-specific constants are used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 10) Section 7.1 "Normative References" - remove spurious year OLD: [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, November 2005. 2005. ^^^^^ NEW: [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, November 2005. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 17 19:46:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcuOO-0007Ek-Hx for secsh-archive@megatron.ietf.org; Thu, 17 Nov 2005 19:46:16 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08722 for ; Thu, 17 Nov 2005 19:45:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1887763B2A9; Fri, 18 Nov 2005 00:46:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 6AD4C63B149 for ; Fri, 18 Nov 2005 00:46:13 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EcuOK-0007Ab-00 for ietf-ssh@netbsd.org; Fri, 18 Nov 2005 00:46:12 +0000 Date: Fri, 18 Nov 2005 00:46:12 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051118004612.GE5569@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67AE3B88A9B41D52891BD13B@maguro.local> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Frank Cusack writes: > Sorry, I haven't really been paying attention here. Does Martin or > myself need to do anything? The changes being proposed sound fine to > me. From the forwarded messages Chris has included, it looks like you need to send corrections to the RFC Editor. I've just collated them and posted my interpretation to the list, but I'm not sure that the RFC Editor will accept corrections from me. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 19 07:00:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdROG-0001Je-Q1 for secsh-archive@megatron.ietf.org; Sat, 19 Nov 2005 07:00:22 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24151 for ; Sat, 19 Nov 2005 06:59:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 171D663B565; Sat, 19 Nov 2005 12:00:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.ipnet.kiev.ua (cielago.ip.net.ua [82.193.96.7]) by mail.netbsd.org (Postfix) with ESMTP id 0FF2163B100 for ; Sat, 19 Nov 2005 12:00:07 +0000 (UTC) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jAJC00X8074997 for ; Sat, 19 Nov 2005 14:00:00 +0200 (EET) (envelope-from ni4@ukr.net) Received: from mail.ipnet.kiev.ua ([82.193.96.7]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 65097-01-22 for ; Sat, 19 Nov 2005 13:59:59 +0200 (EET) Received: from INFERNAL (172.16.2.165.cl.ipnet.kiev.ua [172.16.2.165]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id jAJBwNc3074681 for ; Sat, 19 Nov 2005 13:58:23 +0200 (EET) (envelope-from ni4@ukr.net) Date: Sat, 19 Nov 2005 13:56:23 +0200 From: "Nickolay L." X-Mailer: The Bat! (v3.0.1.33) Professional Reply-To: "Nickolay L." X-Priority: 3 (Normal) Message-ID: <134337182.20051119135623@ukr.net> To: ietf-ssh@NetBSD.org Subject: SFTP : 'supported2' extension. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at ip.net.ua Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello here, The question is about supported-open-flags field. How should be treated lower 3 bits of this fields? In Flags field, used in SSH_FXP_OPEN command, they means the SSH_FXF_ACCESS_DISPOSITION 3-bit field, so it seems meaningless to apply bit mask here. Or these 3 bits should be silently ignored? -- Best regards,Nickolay mailto: , . /_`, `' | &*._.,. .# ) $, //./--//\\. & \/ \. \. -- - - ... - - --. `'`' ` `' -- - - [> http://ansiart.org.ua <] [The Bat!3.0.1.33/Windows 5.1/Far 1.70a6b2008] [Now playing : Savatage - Mozart And Madness] From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 19 18:27:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Edc75-00045n-KD for secsh-archive@megatron.ietf.org; Sat, 19 Nov 2005 18:27:19 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20659 for ; Sat, 19 Nov 2005 18:26:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C3E8163B1DB; Sat, 19 Nov 2005 23:27:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 17AD763B1E4 for ; Sat, 19 Nov 2005 23:27:14 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1Edc6u-0007Vl-00 for ietf-ssh@netbsd.org; Sat, 19 Nov 2005 23:27:08 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <20051113180313.GA21370@chiark.greenend.org.uk> References: <20051028134659.GA30930@chiark.greenend.org.uk> <20051113180313.GA21370@chiark.greenend.org.uk> Organization: Linux Unlimited Message-Id: Date: Sat, 19 Nov 2005 23:27:08 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <20051113180313.GA21370@chiark.greenend.org.uk> you write: >Quoting attached message, Ben Harris wrote (14 June): >| The following entries in the Public Key Algorithm Names table shouldn't >| have been mentioned in draft-ietf-secsh-assignednumbers-12, since they're >| not mentioned in draft-ietf-secsh-transport-24: >| >| pgp-sign-rsa [SSH-TRANS, Section 6.6] >| pgp-sign-dss [SSH-TRANS, Section 6.6] > >This statement doesn't appear to be true. The copy of transport-24 I >have mentions "pgp-sign-rsa" and "pgp-sign-dss" (as does every version >since at least -09). This seems to have been a mistake on my part. The message I actually sent to IANA got it right: | The following entries in the Public Key Algorithm Names table shouldn't have | been mentioned in draft-ietf-secsh-assignednumbers-12, since they're not | mentioned in draft-ietf-secsh-transport-24: | | spki-sign-rsa [SSH-TRANS, Section 6.6] | spki-sign-dss [SSH-TRANS, Section 6.6] This seems to have been addressed already. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 30 10:16:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhTgv-0008WN-6H for secsh-archive@megatron.ietf.org; Wed, 30 Nov 2005 10:16:17 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29004 for ; Wed, 30 Nov 2005 10:15:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8F63E63B11B; Wed, 30 Nov 2005 15:16:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id EA25B63B108 for ; Wed, 30 Nov 2005 15:16:06 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 30 Nov 2005 07:16:08 -0800 X-IronPort-AV: i="3.99,196,1131350400"; d="scan'208"; a="679756491:sNHT24564264" Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.70.90.145]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAUFG5s3020453 for ; Wed, 30 Nov 2005 07:16:05 -0800 (PST) Date: Wed, 30 Nov 2005 07:16:04 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Core IDs - last review Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, The RFC Editor has integrated the last nits into the documents. The latest set of documents are here: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252.txt ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253.txt ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254.txt The diffs from the IDs are here: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html I've placed a set of diffs from what the RFC Editor had previously proposed to what is currently being proposed here: http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4250diff.html http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4251diff.html http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4252diff.html http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4253diff.html http://www.employees.org/~lonvick/secsh-wg/2005-nov-30/4254diff.html These are your documents. Please look them over. I've noticed some very minor cosmetic issues such as page breaks across a message definition. I'll look more closely over the next few days and would appreciate additional eyes and feedback. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 30 21:11:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhdvM-0004M3-4W for secsh-archive@megatron.ietf.org; Wed, 30 Nov 2005 21:11:52 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04327 for ; Wed, 30 Nov 2005 21:11:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AB1C363B222; Thu, 1 Dec 2005 02:11:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 069FF63B169 for ; Thu, 1 Dec 2005 02:11:45 +0000 (UTC) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB11TeD7015532 for ; Wed, 30 Nov 2005 18:29:40 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id jB11Td5I021148 for ; Wed, 30 Nov 2005 18:29:40 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id jB11Td4L022239; Wed, 30 Nov 2005 19:29:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id jB11TdBT022238; Wed, 30 Nov 2005 19:29:39 -0600 (CST) Date: Wed, 30 Nov 2005 19:29:39 -0600 From: Nicolas Williams To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? Message-ID: <20051201012929.GA22059@binky.Central.Sun.COM> References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Oct 21, 2005 at 12:26:29AM -0400, der Mouse wrote: > The thing is, the implementation I'm talking to (which is bannering as > "SSH-1.99-OpenSSH_3.4 NetBSD_Secure_Shell-20020626") is logging > "Received window adjust for non-open channel 0." in response to this. This sort of thing can happen with "window-change" channel requests received before the shell/exec/subsystem channel requests on the same channel. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 30 23:18:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhftU-0003Pi-Mc for secsh-archive@megatron.ietf.org; Wed, 30 Nov 2005 23:18:05 -0500 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14904 for ; Wed, 30 Nov 2005 23:17:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 40E0D63B198; Thu, 1 Dec 2005 04:18:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 916DF63B124 for ; Thu, 1 Dec 2005 04:17:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 8222109; Wed, 30 Nov 2005 21:17:58 -0700 Message-ID: <438E7C7B.8070501@vandyke.com> Date: Wed, 30 Nov 2005 21:30:51 -0700 From: Joseph Galbraith User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Nicolas Williams CC: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Who's at fault here? References: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> <20051201012929.GA22059@binky.Central.Sun.COM> In-Reply-To: <20051201012929.GA22059@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > On Fri, Oct 21, 2005 at 12:26:29AM -0400, der Mouse wrote: >> The thing is, the implementation I'm talking to (which is bannering as >> "SSH-1.99-OpenSSH_3.4 NetBSD_Secure_Shell-20020626") is logging >> "Received window adjust for non-open channel 0." in response to this. > > This sort of thing can happen with "window-change" channel requests > received before the shell/exec/subsystem channel requests on the same > channel. But it shouldn't, should it? My reading of the draft has always been it is legal to send a window adjust any time the channel is open. Wait... did you say "window-change" ? As in the size of the screen changed message. Are you saying the error is ... unclear ... and should really read "Received window-change for non-open channel 0?" and it occurs because a "window-change" was sent before pty has been allocated? Thanks, Joseph