From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 01 14:47:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmOS-0005oy-QN for secsh-archive@megatron.ietf.org; Sat, 01 Oct 2005 14:47:32 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13634 for ; Sat, 1 Oct 2005 14:47:28 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D35863B601; Sat, 1 Oct 2005 18:47:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail2.panix.com (mail2.panix.com [166.84.1.73]) by mail.netbsd.org (Postfix) with ESMTP id 4435263B627 for ; Sat, 1 Oct 2005 18:47:23 +0000 (UTC) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id 649F29DC95; Sat, 1 Oct 2005 14:47:22 -0400 (EDT) Received: (from tls@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j91IlMM11813; Sat, 1 Oct 2005 14:47:22 -0400 (EDT) Date: Sat, 1 Oct 2005 14:47:22 -0400 From: Thor Lancelot Simon To: Alejandro Perez Mendez Cc: ietf-ssh@NetBSD.org Subject: Re: [Ipsec] Rekeying SA bundles Message-ID: <20051001184722.GA1138@panix.com> Reply-To: tls@rek.tjls.com References: <1128169399.2349.15.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1128169399.2349.15.camel@localhost.localdomain> User-Agent: Mutt/1.5.10i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Oct 01, 2005 at 02:23:19PM +0200, Alejandro Perez Mendez wrote: > > c) The REKEY_SA identifies only one of the SAs in the bundle, but this > is enough to identify the entire SA bundle. The responder knows all the > SPI values. From my point of view, this is the only option that really makes sense. Anything else would seem to either waste space on the wire, require the peer to keep extra state across multiple IKE messages or payloads, or both. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 15:03:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMs4K-0003K1-UY for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 15:03:17 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17941 for ; Tue, 4 Oct 2005 15:03:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4707863B255; Tue, 4 Oct 2005 19:03:04 +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 8A72E63B117 for ; Tue, 4 Oct 2005 19:03:03 +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 7952028; Tue, 04 Oct 2005 13:03:02 -0600 Message-ID: <4342D43E.7020909@vandyke.com> Date: Tue, 04 Oct 2005 13:13:02 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org, Sam Hartman , Russ Housley Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> In-Reply-To: <1128018959.1506.60.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 > The examples in section 3.6 do not seem to match the key blob > description in [I-D.ietf-secsh-transport], section 6.6, which says: > > > > The key type MUST always be explicitly known (from algorithm > > negotiation or some other source). It is not normally included in > > the key blob. Argh.... This statement in the transport draft is wrong! (Unless I'm somehow not understanding what it means.) "ssh-dss" and "ssh-rsa" keys (the only keys actually specified by the transport, both specify the key type in the key blob. As in (from 6.6 in transport) The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q mpint g mpint y Or (again 6.6): The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n > But in this context, it is needed. This document should make this > clear with a MUST statement. Note that it is included in each of > the examples. I base64 decoded them and checked. It is only there because the transport draft specifies that ssh-dss and ssh-rsa key blobs have it. The x.509 draft also specifies that it should be there for x.509 keys. The agent@openssh.com agent protocol requires it to be there in order to operate correctly (though the expired agent draft from the working group does not.) If it is not too late, I think that paragraph should be removed from the transport draft. But it is probably too late. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 15:25:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsPu-0000fa-NK for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 15:25:36 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19787 for ; Tue, 4 Oct 2005 15:25:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 044A463B26B; Tue, 4 Oct 2005 19:25:29 +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 5889763B267 for ; Tue, 4 Oct 2005 19:25:28 +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 7952080; Tue, 04 Oct 2005 13:25:26 -0600 Message-ID: <4342D97E.9020707@vandyke.com> Date: Tue, 04 Oct 2005 13:35:26 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org, "Scott Hollenbeck" , Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> In-Reply-To: <1128018959.1506.60.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 > Section 3, second paragraph, and elsewhere: "MUST NOT be longer than 72 > bytes". "bytes" is an imprecise term. Do they really mean "8-bit ASCII > characters", octets, or are 9-bit bytes as implemented on older hardware > architectures also acceptable? > > Section 3.4 uses the term "characters" to describe a line length > limitation. > Consistency would be good. I agree that consistency would be good. We do specify that that header-values MUST be encoded in UTF8. So changing to allow 72 characters could mean a significant growth in the number of bytes allowed on a line (*3 for Japanese text, for example.) 8-bit ASCII characters is close, except for those UTF-8 header values. What if we specified "MUST NOT be longer than 72 8-bit bytes?" Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 15:45:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMsit-0007Lf-U0 for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 15:45:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20958 for ; Tue, 4 Oct 2005 15:45:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E533863B292; Tue, 4 Oct 2005 19:44:33 +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 4464763B273 for ; Tue, 4 Oct 2005 19:44:32 +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 7952192; Tue, 04 Oct 2005 13:44:31 -0600 Message-ID: <4342DDF7.9010002@vandyke.com> Date: Tue, 04 Oct 2005 13:54:31 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org, Russ Housley , Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> In-Reply-To: <1128018959.1506.60.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 > The introduction to this document is very lightweight. Please expand > it to provide some context. At a minimum, this needs to say that the > document is about the SSH protocol and the role of public keys. It > is also desirable to cover the trust model, explaining why these > files are very important. > > The introduction should be expanded to discuss fingerprints and how > they are used in SSH. Is this better: The SSH protocol supports the use of public/private key pairs in order to perform authentication (public-key authentication.) However, in order to use public-key authentication in the SSH protocol, public keys must first be exchanged between client and server. This document formally describes an existing public-key file format which can be used with any of the common existing file transfer mechanisms in order to exchange public keys. The SSH protocol also uses public/private key pairs to authenticate the server. In this scenario, it is important to verify that the public key provided by the server is indeed the server's public-key. This document describes a mechanism for creating a short text string that uniquilly represents a public-key (fingerprinting) for use in manually comparing public keys. > In section 3.6, please change "me@myhost" to "me@example.com". Done. > The last paragraph of the security considerations needs to be > expanded to provide a bit of context. MD5 has some known weakness, > but they are not a problem in this situation because ... Is this better? The public-key fingerprint method presented here relies on the MD5 hash, which is known to have certain weaknesses regarding it's collision-resistance; however, the particular use made of MD5 here depends solely on it's 2nd-preimage resistance, not on it's collision-resistance. MD5 is used here for historical reasons. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 16:39:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtZQ-0004U1-Gi for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 16:39:28 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02262 for ; Tue, 4 Oct 2005 16:39:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5AD5A63B247; Tue, 4 Oct 2005 20:38:18 +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 7067C63B28F for ; Tue, 4 Oct 2005 20:38:15 +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 7952427; Tue, 04 Oct 2005 14:38:13 -0600 Message-ID: <4342EA8D.8090304@vandyke.com> Date: Tue, 04 Oct 2005 14:48:13 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Scott Hollenbeck CC: "'Bill Sommerfeld'" , ietf-ssh@NetBSD.org, "'Sam Hartman'" Subject: Re: DISCUSS comments on publickeyfile-09 References: <20051004201510.NJMX28234.eastrmmtao05.cox.net@A31P> In-Reply-To: <20051004201510.NJMX28234.eastrmmtao05.cox.net@A31P> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Done. Once the rest of the DISCUSSes are resolved, I'll spin -10. Thanks, Joseph Scott Hollenbeck wrote: > That would be fine with me. Please check for other uses of the "byte" word, > though, too. > > -Scott- > >> -----Original Message----- >> From: Joseph Galbraith [mailto:galb-list@vandyke.com] >> Sent: Tuesday, October 04, 2005 3:35 PM >> To: Bill Sommerfeld >> Cc: ietf-ssh@netbsd.org; Scott Hollenbeck; Sam Hartman >> Subject: Re: DISCUSS comments on publickeyfile-09 >> >>> Section 3, second paragraph, and elsewhere: "MUST NOT be >> longer than >>> 72 bytes". "bytes" is an imprecise term. Do they really >> mean "8-bit >>> ASCII characters", octets, or are 9-bit bytes as >> implemented on older >>> hardware architectures also acceptable? >>> >>> Section 3.4 uses the term "characters" to describe a line length >>> limitation. >>> Consistency would be good. >> I agree that consistency would be good. >> >> We do specify that that header-values MUST be encoded in >> UTF8. So changing to allow 72 characters could mean a >> significant growth in the number of bytes allowed on a line >> (*3 for Japanese text, for example.) >> >> 8-bit ASCII characters is close, except for those >> UTF-8 header values. >> >> What if we specified "MUST NOT be longer than 72 8-bit bytes?" >> >> Thanks, >> >> Joseph >> >> >> > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 16:52:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtlj-00030Z-Bm for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 16:52:12 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06909 for ; Tue, 4 Oct 2005 16:52:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7EF3E63B176; Tue, 4 Oct 2005 20:52:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by mail.netbsd.org (Postfix) with SMTP id 9367D63B12B for ; Tue, 4 Oct 2005 20:52:06 +0000 (UTC) Received: (qmail 23457 invoked by uid 0); 4 Oct 2005 20:51:58 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.51.217) by woodstock.binhost.com with SMTP; 4 Oct 2005 20:51:58 -0000 Message-Id: <6.2.1.2.2.20051004165005.06b867c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 04 Oct 2005 16:51:55 -0400 To: Joseph Galbraith From: Russ Housley Subject: Re: DISCUSS comments on publickeyfile-09 Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <4342D43E.7020909@vandyke.com> References: <1128018959.1506.60.camel@thunk> <4342D43E.7020909@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list It is not too late to fix the [I-D.ietf-secsh-transport] document if the WG consensus is that the paragraph is incorrect. It is up to the WG chair to work with Sam and I to get this changed while it is still in the RFC Editor queue if that is the will of the WG. Russ At 03:13 PM 10/4/2005, Joseph Galbraith wrote: >> The examples in section 3.6 do not seem to match the key blob >> description in [I-D.ietf-secsh-transport], section 6.6, which says: >> > >> > The key type MUST always be explicitly known (from algorithm >> > negotiation or some other source). It is not normally included in >> > the key blob. > >Argh.... > >This statement in the transport draft is wrong! >(Unless I'm somehow not understanding what >it means.) > >"ssh-dss" and "ssh-rsa" keys (the only keys actually >specified by the transport, both specify the key >type in the key blob. > >As in (from 6.6 in transport) > > The "ssh-dss" key format has the following specific encoding: > > string "ssh-dss" > mpint p > mpint q > mpint g > mpint y > >Or (again 6.6): > > The "ssh-rsa" key format has the following specific encoding: > > string "ssh-rsa" > mpint e > mpint n > > >> But in this context, it is needed. This document should make this >> clear with a MUST statement. Note that it is included in each of >> the examples. I base64 decoded them and checked. > >It is only there because the transport draft >specifies that ssh-dss and ssh-rsa key blobs have it. > >The x.509 draft also specifies that it should be there >for x.509 keys. > >The agent@openssh.com agent protocol requires it to be >there in order to operate correctly (though the expired >agent draft from the working group does not.) > >If it is not too late, I think that paragraph should >be removed from the transport draft. But it is probably >too late. > >Thanks, > >Joseph > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 17:05:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMtyD-0008Pd-8X for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 17:05:05 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09011 for ; Tue, 4 Oct 2005 17:05:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4226563B1CC; Tue, 4 Oct 2005 21:05:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by mail.netbsd.org (Postfix) with SMTP id 1C2D163B12B for ; Tue, 4 Oct 2005 21:05:00 +0000 (UTC) Received: (qmail 32666 invoked by uid 0); 4 Oct 2005 21:04:51 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (212.147.51.217) by woodstock.binhost.com with SMTP; 4 Oct 2005 21:04:51 -0000 Message-Id: <6.2.1.2.2.20051004165857.06925a70@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 04 Oct 2005 17:04:48 -0400 To: Joseph Galbraith , Bill Sommerfeld From: Russ Housley Subject: Re: DISCUSS comments on publickeyfile-09 Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <4342DDF7.9010002@vandyke.com> References: <1128018959.1506.60.camel@thunk> <4342DDF7.9010002@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph: The replacement introduction looks good, but I have a few editorial suggestions below. > The SSH protocol supports the use of public/private key pairs > in order to perform authentication (public-key authentication.) ... perform authentication based on public-key cryptography. > However, in order to use public-key authentication in the SSH > protocol, public keys must first be exchanged between client > and server. > > This document formally describes an existing public-key file > format which can be used with any of the common existing file > transfer mechanisms in order to exchange public keys. > > The SSH protocol also uses public/private key pairs to > authenticate the server. In this scenario, it is important > to verify that the public key provided by the server is > indeed the server's public-key. > > This document describes a mechanism for creating a short text > string that uniquilly represents a public-key (fingerprinting) ... that uniquely represents a particular public key, called fingerprinting. > for use in manually comparing public keys. The replacement security considerations text looks good, but I have a few editorial suggestions below. > The public-key fingerprint method presented here relies on > the MD5 hash, which is known to have certain weaknesses ... MD5 one-way hash function, which ... > regarding it's collision-resistance; however, the particular > use made of MD5 here depends solely on it's 2nd-preimage > resistance, not on it's collision-resistance. > > MD5 is used here for historical reasons. Russ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 17:53:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMujG-00014q-Q8 for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 17:53:43 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11295 for ; Tue, 4 Oct 2005 17:53:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2B81B63B26C; Tue, 4 Oct 2005 21:53:37 +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 6B73263B26A for ; Tue, 4 Oct 2005 21:53:36 +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 7952646; Tue, 04 Oct 2005 15:53:35 -0600 Message-ID: <4342FC37.9080303@vandyke.com> Date: Tue, 04 Oct 2005 16:03:35 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Russ Housley CC: Bill Sommerfeld , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> <4342DDF7.9010002@vandyke.com> <6.2.1.2.2.20051004165857.06925a70@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20051004165857.06925a70@mail.binhost.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 Done... Thanks, Joseph Russ Housley wrote: > Joseph: > > The replacement introduction looks good, but I have a few editorial > suggestions below. > >> The SSH protocol supports the use of public/private key pairs >> in order to perform authentication (public-key authentication.) > > ... perform authentication based on public-key cryptography. > >> However, in order to use public-key authentication in the SSH >> protocol, public keys must first be exchanged between client >> and server. >> >> This document formally describes an existing public-key file >> format which can be used with any of the common existing file >> transfer mechanisms in order to exchange public keys. >> >> The SSH protocol also uses public/private key pairs to >> authenticate the server. In this scenario, it is important >> to verify that the public key provided by the server is >> indeed the server's public-key. >> >> This document describes a mechanism for creating a short text >> string that uniquilly represents a public-key (fingerprinting) > > ... that uniquely represents a particular public key, called > fingerprinting. > >> for use in manually comparing public keys. > > > > The replacement security considerations text looks good, but I have a > few editorial suggestions below. > >> The public-key fingerprint method presented here relies on >> the MD5 hash, which is known to have certain weaknesses > > ... MD5 one-way hash function, which ... > >> regarding it's collision-resistance; however, the particular >> use made of MD5 here depends solely on it's 2nd-preimage >> resistance, not on it's collision-resistance. >> >> MD5 is used here for historical reasons. > > Russ > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 18:50:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvcE-0006aa-9j for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 18:50:30 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14966 for ; Tue, 4 Oct 2005 18:50:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id DDF1563B185; Tue, 4 Oct 2005 22:50:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id BAA7263B15B for ; Tue, 4 Oct 2005 22:50:24 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA21551; Tue, 4 Oct 2005 18:50:23 -0400 (EDT) From: der Mouse Message-Id: <200510042250.SAA21551@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 4 Oct 2005 18:49:01 -0400 (EDT) To: ietf-ssh@NetBSD.org Cc: Russ Housley , Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 In-Reply-To: <4342DDF7.9010002@vandyke.com> References: <1128018959.1506.60.camel@thunk> <4342DDF7.9010002@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Is this better? > The public-key fingerprint method presented here relies on > the MD5 hash, which is known to have certain weaknesses > regarding it's collision-resistance; however, the particular > use made of MD5 here depends solely on it's 2nd-preimage > resistance, not on it's collision-resistance. > > MD5 is used here for historical reasons. s/it's/its/ in all three occurrences. I'd also s/collision-resistance/collision resistance/, but that's less important. /~\ 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 18:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvhk-0000NY-V7 for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 18:56:13 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15110 for ; Tue, 4 Oct 2005 18:56:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6C0DD63B23E; Tue, 4 Oct 2005 22:56:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from eastrmmtai04.cox.net (eastrmmtai04.cox.net [68.230.240.55]) by mail.netbsd.org (Postfix) with ESMTP id 5798A63B15B for ; Tue, 4 Oct 2005 22:56:07 +0000 (UTC) Received: from A31P ([68.100.55.187]) by eastrmmtao05.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051004201510.NJMX28234.eastrmmtao05.cox.net@A31P>; Tue, 4 Oct 2005 16:15:10 -0400 From: "Scott Hollenbeck" To: "'Joseph Galbraith'" , "'Bill Sommerfeld'" Cc: , "'Sam Hartman'" Subject: RE: DISCUSS comments on publickeyfile-09 Date: Tue, 4 Oct 2005 16:15:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4342D97E.9020707@vandyke.com> Thread-Index: AcXJGWGsT1znuED+S0Gtmjn2IaW2qQABsTgw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Message-Id: <20051004201510.NJMX28234.eastrmmtao05.cox.net@A31P> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit That would be fine with me. Please check for other uses of the "byte" word, though, too. -Scott- > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Tuesday, October 04, 2005 3:35 PM > To: Bill Sommerfeld > Cc: ietf-ssh@netbsd.org; Scott Hollenbeck; Sam Hartman > Subject: Re: DISCUSS comments on publickeyfile-09 > > > Section 3, second paragraph, and elsewhere: "MUST NOT be > longer than > > 72 bytes". "bytes" is an imprecise term. Do they really > mean "8-bit > > ASCII characters", octets, or are 9-bit bytes as > implemented on older > > hardware architectures also acceptable? > > > > Section 3.4 uses the term "characters" to describe a line length > > limitation. > > Consistency would be good. > > I agree that consistency would be good. > > We do specify that that header-values MUST be encoded in > UTF8. So changing to allow 72 characters could mean a > significant growth in the number of bytes allowed on a line > (*3 for Japanese text, for example.) > > 8-bit ASCII characters is close, except for those > UTF-8 header values. > > What if we specified "MUST NOT be longer than 72 8-bit bytes?" > > Thanks, > > Joseph > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 18:56:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMviA-0000Pk-Mq for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 18:56:38 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15136 for ; Tue, 4 Oct 2005 18:56:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2A9A663B267; Tue, 4 Oct 2005 22:56:33 +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 2734F63B15B for ; Tue, 4 Oct 2005 22:56:32 +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 7952856; Tue, 04 Oct 2005 16:56:31 -0600 Message-ID: <43430AF7.3030301@vandyke.com> Date: Tue, 04 Oct 2005 17:06:31 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org, Russ Housley , Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> <4342DDF7.9010002@vandyke.com> <200510042250.SAA21551@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200510042250.SAA21551@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Done. Thanks as usual for the review. Joseph der Mouse wrote: >> Is this better? > >> The public-key fingerprint method presented here relies on >> the MD5 hash, which is known to have certain weaknesses >> regarding it's collision-resistance; however, the particular >> use made of MD5 here depends solely on it's 2nd-preimage >> resistance, not on it's collision-resistance. >> >> MD5 is used here for historical reasons. > > s/it's/its/ in all three occurrences. I'd also > s/collision-resistance/collision resistance/, but that's less > important. > > /~\ 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 > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 04 19:01:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMvmR-00022o-IT for secsh-archive@megatron.ietf.org; Tue, 04 Oct 2005 19:01:03 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15309 for ; Tue, 4 Oct 2005 19:00:59 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A897963B286; Tue, 4 Oct 2005 23:00:59 +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 CDA2163B283 for ; Tue, 4 Oct 2005 23:00:58 +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 7952866; Tue, 04 Oct 2005 17:00:58 -0600 Message-ID: <43430C02.1090808@vandyke.com> Date: Tue, 04 Oct 2005 17:10:58 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org CC: Russ Housley , Sam Hartman Subject: Re: DISCUSS comments on publickeyfile-09 References: <1128018959.1506.60.camel@thunk> <4342D43E.7020909@vandyke.com> <6.2.1.2.2.20051004165005.06b867c0@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20051004165005.06b867c0@mail.binhost.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 Comments from others? > The key type MUST always be explicitly known (from algorithm > negotiation or some other source). It is not normally included in > the key blob. > > Certificates and public keys are encoded as follows: > string certificate or public key format identifier > byte[n] key/certificate data > The first paragraph definitely seems in conflict with the second, since the second clearly states that a public key or certificate has a type identifier... add to that the fact that all the currently defined public-key types also include the identifier... I think we should strike the first paragraph. Thoughts? Thanks, Joseph Russ Housley wrote: > It is not too late to fix the [I-D.ietf-secsh-transport] document if the > WG consensus is that the paragraph is incorrect. It is up to the WG > chair to work with Sam and I to get this changed while it is still in > the RFC Editor queue if that is the will of the WG. > > Russ > > At 03:13 PM 10/4/2005, Joseph Galbraith wrote: >>> The examples in section 3.6 do not seem to match the key blob >>> description in [I-D.ietf-secsh-transport], section 6.6, which says: >>> > >>> > The key type MUST always be explicitly known (from algorithm >>> > negotiation or some other source). It is not normally included in >>> > the key blob. >> >> Argh.... >> >> This statement in the transport draft is wrong! >> (Unless I'm somehow not understanding what >> it means.) >> >> "ssh-dss" and "ssh-rsa" keys (the only keys actually >> specified by the transport, both specify the key >> type in the key blob. >> >> As in (from 6.6 in transport) >> >> The "ssh-dss" key format has the following specific encoding: >> >> string "ssh-dss" >> mpint p >> mpint q >> mpint g >> mpint y >> >> Or (again 6.6): >> >> The "ssh-rsa" key format has the following specific encoding: >> >> string "ssh-rsa" >> mpint e >> mpint n >> >> >>> But in this context, it is needed. This document should make this >>> clear with a MUST statement. Note that it is included in each of >>> the examples. I base64 decoded them and checked. >> >> It is only there because the transport draft >> specifies that ssh-dss and ssh-rsa key blobs have it. >> >> The x.509 draft also specifies that it should be there >> for x.509 keys. >> >> The agent@openssh.com agent protocol requires it to be >> there in order to operate correctly (though the expired >> agent draft from the working group does not.) >> >> If it is not too late, I think that paragraph should >> be removed from the transport draft. But it is probably >> too late. >> >> Thanks, >> >> Joseph >> > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 05 20:19:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENJTd-0006J3-Vb for secsh-archive@megatron.ietf.org; Wed, 05 Oct 2005 20:19:14 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10852 for ; Wed, 5 Oct 2005 20:19:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 334BE63B126; Thu, 6 Oct 2005 00:18:56 +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 0F30563B170 for ; Thu, 6 Oct 2005 00:18:54 +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 7956301; Wed, 05 Oct 2005 18:18:53 -0600 Message-ID: <43446FC8.3060509@vandyke.com> Date: Wed, 05 Oct 2005 18:28:56 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Internet-Drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Please publish the attached draft-galb-filexfer-extensions-00.txt Content-Type: multipart/mixed; boundary="------------090406050101070109010806" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------090406050101070109010806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------090406050101070109010806 Content-Type: text/plain; name="draft-galb-filexfer-extensions-00.txt" Content-Disposition: inline; filename="draft-galb-filexfer-extensions-00.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: April 8, 2006 O. Saarenmaa F-Secure October 5, 2005 SSH File Transfer Protocol draft-galb-filexfer-extensions-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 8, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The SSH File Transfer Protocol provides a rich infrastructure for sharing information about files. This document describes several optional extensions that build on this infrastructure. Galbraith & Saarenmaa Expires April 8, 2006 [Page 1] Internet-Draft SSH File Transfer Protocol October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Vendor Id . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. File Hashing . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Querying Available Space . . . . . . . . . . . . . . . . . . . 5 5. Querying User Home Directory . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Galbraith & Saarenmaa Expires April 8, 2006 [Page 2] Internet-Draft SSH File Transfer Protocol October 2005 1. Introduction This is a collection of optional extensions to the SSH File Transfer Protocol [I-D.ietf-secsh-filexfer]. This extensions make it possible for clients to query the server for additional information which may not be widely supported, but can increase the quality of the users experience when the server can support them. 2. Vendor Id It is often necessary to detect the version of the server so that bugs can be worked around. This extension allows the client to do so. (It may also be sent by the client using an EXTENDED request.) string "vendor-id" string vendor-structure string vendor-name [UTF-8] string product-name [UTF-8] string product-version [UTF-8] uint64 product-build-number vendor-name Arbitrary name identifying the maker of the product. product-name Arbitrary name identifying the product. product-name Arbitrary string identifying the version of the product. product-build-number A build-number for the product, such that if a bug is fixed in build-number 'x', it can be assumed that (barring regression in the product) it is fixed in all build-numbers > 'x'. 3. File Hashing This extension allows a client to easily check if a file (or portion thereof) that it already has matches what is on the server. Galbraith & Saarenmaa Expires April 8, 2006 [Page 3] Internet-Draft SSH File Transfer Protocol October 2005 byte SSH_FXP_EXTENDED uint32 request-id string "check-file-handle" / "check-file-name" string handle / name string hash-algorithm-list uint64 start-offset uint64 length uint32 block-size handle For "check-file-handle", 'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST return SSH_FX_INVALID_HANDLE. If ACE4_READ_DATA was not included when the file was opened, the server MUST return STATUS_PERMISSION_DENIED. If this file handle was opened in SSH_FXF_ACCESS_TEXT_MODE mode, the check must be performed on the data as it would be sent on the wire. name For "check-file-name", 'name' is the path to the file to check. If 'check-file-name' is a directory, SSH_FX_FILE_IS_A_DIRECTORY SHOULD be returned. If 'check-file-name' refers to a SSH_FILEXFER_TYPE_SYMLINK, the target should be opened. The results are undefined file types other than SSH_FILEXFER_TYPE_REGULAR. The file MUST be opened without the SSH_FXF_ACCESS_TEXT_MODE access flag (in binary mode.) hash-algorithm-list A comma separated list of hash algorithms the client is willing to accept for this operation. The server MUST pick the first hash on the list that it supports. Currently defined algorithms are "md5", "sha1", "sha224", "sha256", "sha384", "sha512", and "crc32". Additional algorithms may be added by following the DNS extensibility naming convention outlined in [I-D.ietf-secsh-architecture]. MD5 is described in [RFC1321]. SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 are described in [FIPS-180-2]. [ISO.3309.1991] describes crc32, and is the same algorithm used in [RFC1510] Galbraith & Saarenmaa Expires April 8, 2006 [Page 4] Internet-Draft SSH File Transfer Protocol October 2005 start-offset The starting offset of the data to include in the hash. length The length of data to include in the hash. If length is zero, all the data from start-offset to the end-of-file should be included. block-size An independent hash MUST be computed over every block in the file. The size of blocks is specified by block-size. The block-size MUST NOT be smaller than 256 bytes. If the block-size is 0, then only one hash, over the entire range, MUST be made. The response is either a SSH_FXP_STATUS packet, indicating an error, or the following extended reply packet: byte SSH_FXP_EXTENDED_REPLY uint32 request-id string "check-file" string hash-algo-used byte hash[n][block-count] hash-algo-used The hash algorithm that was actually used. hash The computed hashes. The hash algorithm used determines the size of n. The number of block-size chunks of data in the file determines block-count. The hashes are placed in the packet one after another, with no decoration. Note that if the length of the range is not an even multiple of block-size, the last hash will have been computed over only the remainder of the range instead of a full block. 4. Querying Available Space The following extension provides a way to discover the available space for an arbitrary path. byte SSH_FXP_EXTENDED uint32 request-id string "space-available" string path [UTF-8] Galbraith & Saarenmaa Expires April 8, 2006 [Page 5] Internet-Draft SSH File Transfer Protocol October 2005 path 'path' for which the available space should be reported. This 'path' is not required to be the mount point path, but MAY be a directory or file contained within the mount. The reply to the request is as follows: byte SSH_FXP_EXTENDED_REPLY uint32 request-id uint64 bytes-on-device uint64 unused-bytes-on-device uint64 bytes-available-to-user uint64 unused-bytes-available-to-user uint32 bytes-per-allocation-unit bytes-on-device The total number of bytes on the device which stores 'path', both used and unused, or 0 if unknown. unused-bytes-on-device The total number of unused bytes available on the device which stores 'path', or 0 if unknown. bytes-available-to-user The total number of bytes, both used and unused, available to the authenticated user on the device which stores 'path', or 0 if unknown. unused-bytes-available-to-user The total number of unused bytes available to the authenticated user on the device which stores 'path', or 0 if unknown. bytes-per-allocation-unit The number of bytes in each allocation unit on the device, or in other words, the minimum number of bytes that a file allocation size can grow or shrink by. If the server does not know this information, or the file-system in use does not use allocation blocks, this value MUST be 0. 5. Querying User Home Directory Many users are used to being able to type '~' as an alias for their home directory, or ~username as an alias for another user's home directory. To support this feature, a server MAY support following extension. Galbraith & Saarenmaa Expires April 8, 2006 [Page 6] Internet-Draft SSH File Transfer Protocol October 2005 byte SSH_FXP_EXTENDED uint32 request-id string "home-directory" string username [UTF-8] username Username whose home directory path is being requested. An empty string implies the current user. The reply to the request is either a SSH_FXP_STATUS packet or the following extended reply: byte SSH_FXP_EXTENDED_REPLY uint32 request-id string "home-directory" string absolute-pathname absolute-pathname Absolute pathname of the specified user's home directory, suitable for use in operations such as REALPATH or OPENDIR. 6. Security Considerations The home directory extension could be used to discover whether a given user is valid; however, since users are assumed to be authenticated by the underlying protocol, this is probably not significant in most situations. If a server would not normally allow an authenticated user to query the existance of another user, the server MUST NOT allow the "home-directory" extension. 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [I-D.ietf-secsh-architecture] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. Galbraith & Saarenmaa Expires April 8, 2006 [Page 7] Internet-Draft SSH File Transfer Protocol October 2005 [I-D.ietf-secsh-transport] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [I-D.ietf-secsh-filexfer] Galbraith, J., "SSH File Transfer Protocol", draft-ietf-secsh-filexfer-09 (work in progress), June 2005. [FIPS-180-2] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", Federal Information Processing Standards Publication 180-2, August 2002. [ISO.3309.1991] International Organization for Standardization, "Information Technology - Telecommunications and information exchange between systems - High-level data link control (HDLC) procedures - Frame structure", ISO Standard 3309, June 1991. 7.2. Informative References Trademark notice "ssh" is a registered trademark in the United States and/or other countries. Galbraith & Saarenmaa Expires April 8, 2006 [Page 8] Internet-Draft SSH File Transfer Protocol October 2005 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Oskari Saarenmaa F-Secure Tammasaarenkatu 7 Helsinki 00180 FI Email: oskari.saarenmaa@f-secure.com Galbraith & Saarenmaa Expires April 8, 2006 [Page 9] Internet-Draft SSH File Transfer Protocol October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Saarenmaa Expires April 8, 2006 [Page 10] --------------090406050101070109010806-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 05 20:34:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENJib-0003Ab-3S for secsh-archive@megatron.ietf.org; Wed, 05 Oct 2005 20:34:41 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11371 for ; Wed, 5 Oct 2005 20:34:38 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AFB9463B2D7; Thu, 6 Oct 2005 00:34:36 +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 255C863B127 for ; Thu, 6 Oct 2005 00:34:34 +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 7956339; Wed, 05 Oct 2005 18:34:33 -0600 Message-ID: <43447374.2000003@vandyke.com> Date: Wed, 05 Oct 2005 18:44:36 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Internet-Drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Please publish attached draft-ietf-secsh-publickeyfile-10.txt Content-Type: multipart/mixed; boundary="------------000507020604010503070101" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------000507020604010503070101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Joseph --------------000507020604010503070101 Content-Type: text/plain; name="draft-ietf-secsh-publickeyfile-10.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickeyfile-10.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft VanDyke Software Expires: April 8, 2006 R. Thayer The Tillerman Group October 5, 2005 SSH Public Key File Format draft-ietf-secsh-publickeyfile-10.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 8, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. Galbraith & Thayer Expires April 8, 2006 [Page 1] Internet-Draft SSH Public Key File Format October 2005 Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Galbraith & Thayer Expires April 8, 2006 [Page 2] Internet-Draft SSH Public Key File Format October 2005 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Galbraith & Thayer Expires April 8, 2006 [Page 3] Internet-Draft SSH Public Key File Format October 2005 2. Introduction The SSH protocol supports the use of public/private key pairs in order to perform perform authentication based on public-key cryptography. However, in order to use public-key authentication in the SSH protocol, public keys must first be exchanged between client and server. This document formally describes an existing public-key file format which can be used with any of the common existing file transfer mechanisms in order to exchange public keys. The SSH protocol also uses public/private key pairs to authenticate the server. In this scenario, it is important to verify that the public key provided by the server is indeed the server's public-key. This document describes a mechanism for creating a short text string that that uniquely represents a particular public key, called fingerprinting. Galbraith & Thayer Expires April 8, 2006 [Page 4] Internet-Draft SSH Public Key File Format October 2005 3. Key File Format In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line in the file MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.1. Line Termination Characters Implementations SHOULD generate public key files using their system's local text file representation. In the event that public key files are not transferred as text files, implementations SHOULD be prepared to read files using any of the common line termination sequence, , or . 3.2. Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3. Key File Header The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value The Header-tag MUST NOT be more than 64 8-bit bytes, and is case- insensitive. The Header-value MUST NOT be more than 1024 8-bit bytes. Each line in the header MUST NOT be more than 72 8-bit bytes. A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of the line is formed by removing the '\' and the line termination characters, and appending the contents of the next line. The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be Galbraith & Thayer Expires April 8, 2006 [Page 5] Internet-Draft SSH Public Key File Format October 2005 encoded in UTF-8. [RFC3629] A line that is not a continuation line that has no ':' in it is the first line of the base 64 encoded body (See Section 3.4.) Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. 3.3.1. Subject Header This field is used to store the login-name that the key was generated under. For example: Subject: user 3.3.2. Comment Header The comment header contains a user specified comment. The comment SHOULD be displayed when using the key. It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: Comment: user@example.com Currently, common practice is to quote the Header-value of the Comment by prefixing and suffixing it with '"' characters, and some existing implementations fail if these quotation marks are omitted Compliant implementations MUST function correctly if the quotation marks are omitted. Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value. 3.3.3. New Headers New headers that are of the from "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. 3.4. Public Key File Body The body of a public key file consists of the public key blob as described in [I-D.ietf-secsh-transport], section 4.6, "Public Key Galbraith & Thayer Expires April 8, 2006 [Page 6] Internet-Draft SSH Public Key File Format October 2005 Algorithms", encoded in base 64 as specified in [RFC2045], section 6.8, "Base64 Content-Transfer-Encoding". As with all other lines, each line in the body MUST NOT be longer than 72 8-bit bytes excluding line termination characters. 3.5. Differences with RFC1421 PEM formats Implemetors should take care to notice that while the format is superficially similar to those specified by PEM [RFC1421] and OpenPGP [RFC2440], it is not identical; most notably: o The other specifications use different BEGIN/END delimeters (five dashes, no space rather than four dashes and a space). o There is no blank line before the start of the base64-encoded contents. o There is no CRC at the end of the base64-encoded block. o Header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. 3.6. Examples The following are some example public key files that are compliant (note that the examples all wrap before 72 bytes to meet ietf document requirements; however, they are still compliant.) ---- BEGIN SSH2 PUBLIC KEY ---- Comment: "1024-bit RSA, converted from OpenSSH by me@example.com" x-command: /home/galb/bin/lock-in-guest.sh AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires April 8, 2006 [Page 7] Internet-Draft SSH Public Key File Format October 2005 ---- BEGIN SSH2 PUBLIC KEY ---- Comment: This is my public key for use on \ servers which I don't like. AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Comment: DSA Public Key for use with MyIsp AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV ---- END SSH2 PUBLIC KEY ---- ---- BEGIN SSH2 PUBLIC KEY ---- Subject: galb Comment: 1024-bit rsa, created by me@example.com Mon Jan 15 08:31:24 2001 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= ---- END SSH2 PUBLIC KEY ---- Galbraith & Thayer Expires April 8, 2006 [Page 8] Internet-Draft SSH Public Key File Format October 2005 4. Public Key Fingerprints The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community. The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC1321]. The input to the algorithm is the public key blob as described in [I-D.ietf-secsh-transport]. The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" Galbraith & Thayer Expires April 8, 2006 [Page 9] Internet-Draft SSH Public Key File Format October 2005 5. IANA Considerations There are no IANA registries or other considerations associated with this document. Galbraith & Thayer Expires April 8, 2006 [Page 10] Internet-Draft SSH Public Key File Format October 2005 6. Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. The public-key fingerprint method presented here relies on the MD5 one-way hash function, which is known to have certain weaknesses regarding its collision resistance; however, the particular use made of MD5 here depends solely on its 2nd-preimage resistance, not on its collision resistance. MD5 is used here for historical reasons. Galbraith & Thayer Expires April 8, 2006 [Page 11] Internet-Draft SSH Public Key File Format October 2005 7. References 7.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [I-D.ietf-secsh-transport] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. 7.2. Informative References [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. Galbraith & Thayer Expires April 8, 2006 [Page 12] Internet-Draft SSH Public Key File Format October 2005 Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: galb-list@vandyke.com Rodney Thayer The Tillerman Group 370 Altair Way, PMB 321 Sunnyvale, CA 94086 Phone: +1 408 757 9693 Email: rodney@tillerman.to Galbraith & Thayer Expires April 8, 2006 [Page 13] Internet-Draft SSH Public Key File Format October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith & Thayer Expires April 8, 2006 [Page 14] --------------000507020604010503070101-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 05 20:36:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENJkF-0003oe-3l for secsh-archive@megatron.ietf.org; Wed, 05 Oct 2005 20:36:23 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11519 for ; Wed, 5 Oct 2005 20:36:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4582063B150; Thu, 6 Oct 2005 00:36:20 +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 A45B163B127 for ; Thu, 6 Oct 2005 00:36:19 +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 7956348 for ietf-ssh@NetBSD.org; Wed, 05 Oct 2005 18:36:19 -0600 Message-ID: <434473DE.1070905@vandyke.com> Date: Wed, 05 Oct 2005 18:46:22 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Published new filexfer draft... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I just published a new version of the filexfer draft. As some people had requested, I split some of the extensions into a separate draft. I wasn't sure whether to publish this as a working group item or not... I think it should be, but what do I know :-) For now, I published it as a individual submission. (Though I think I messed up the name... hopefully they'll let me know :-) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 06 15:50:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbkn-0006YC-7p for secsh-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:50:09 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26723 for ; Thu, 6 Oct 2005 15:50:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CB46263B244; Thu, 6 Oct 2005 19:50:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 3F5FF63B224 for ; Thu, 6 Oct 2005 19:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkf-0002oi-JF; Thu, 06 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-10.txt Message-Id: Date: Thu, 06 Oct 2005 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-10.txt Pages : 14 Date : 2005-10-6 This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickeyfile-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-6114149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6114149.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 06 15:50:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENbkz-0006ei-1P for secsh-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:50:21 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26778 for ; Thu, 6 Oct 2005 15:50:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D965863B25A; Thu, 6 Oct 2005 19:50:05 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from newodin.ietf.org (unknown [132.151.6.50]) by mail.netbsd.org (Postfix) with ESMTP id 37A4863B1FF for ; Thu, 6 Oct 2005 19:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENbkf-0002oU-GH; Thu, 06 Oct 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-10.txt Message-Id: Date: Thu, 06 Oct 2005 15:50:01 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH File Transfer Protocol Author(s) : J. Galbraith, O. Saarenmaa Filename : draft-ietf-secsh-filexfer-10.txt Pages : 56 Date : 2005-10-6 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-filexfer-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-filexfer-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-6113411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-6113411.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Oct 18 19:48:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES1CC-0002ds-6g for secsh-archive@megatron.ietf.org; Tue, 18 Oct 2005 19:48:40 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07641 for ; Tue, 18 Oct 2005 19:48:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9208563B374; Tue, 18 Oct 2005 23:48:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from 192.168.1.34 (cable245a164.usuarios.retecal.es [212.183.245.164]) by mail.netbsd.org (Postfix) with SMTP id 2BC1E63B100 for ; Tue, 18 Oct 2005 23:48:32 +0000 (UTC) From: "INSAIKO S.L." To: Subject: «Publicidad» Solicitud de autorización Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 19 Oct 2005 01:48:31 +0200 Reply-To: "INSAIKO S.L." Message-Id: <20051018234832.2BC1E63B100@mail.netbsd.org> 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 TAA07641 =ABPublicidad=BB Nuestra empresa espa=F1ola INSAIKO S.L., desea enviarle una "Propuesta-Of= erta Especial" de dise=F1o web para usted y su empresa.=20 Para adaptarnos a la Normativa establecida por la LSSI-CE en su T=EDtulo = III, art=EDculos 19 a 22, le solicitamos su expresa autorizaci=F3n para enviar= le por este medio nuestra oferta de dise=F1o web.=20 En este sentido, si nos autoriza a enviarle nuestra oferta, por favor responda a este mensaje con el asunto: "Autorizo a enviarme oferta web".=20 Si no obtenemos respuesta vuestra ser=E1 considerada como una negativa a recibir dicha oferta, no siendo necesario en ning=FAn caso darse de baja = de ninguna lista de distribuci=F3n.=20 No obstante, le informamos que una respuesta positiva a este correo podr=E1 suponer un ahorro e impulso en la promoci=F3n de su empresa en Internet.=20 Ante todo, le damos las gracias anticipadas, quedamos a su disposici=F3n.= =20 Su direcci=F3n de correo electr=F3nico ha sido obtenida de fuentes accesi= bles al p=FAblico, por lo que no podr=E1 ser tratada como dato de car=E1cter p= rivado y sometido a la legislaci=F3n referente a la protecci=F3n de datos de car=E1= cter personal. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 13:06:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET0LS-0005Di-0D for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 13:06:18 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18956 for ; Fri, 21 Oct 2005 13:06:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D069663B12E; Fri, 21 Oct 2005 17:06:11 +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 3B50C63B11B for ; Fri, 21 Oct 2005 17:06:11 +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 8058124 for ietf-ssh@NetBSD.org; Fri, 21 Oct 2005 11:06:10 -0600 Message-ID: <43592288.2070706@vandyke.com> Date: Fri, 21 Oct 2005 11:16:56 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: 64th Ietf... 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 I know we aren't meeting... but I will be there if anyone that feels strongly about the SFTP draft wants to hook up and hash out differences :-) Thanks, Joseph PS. This also serves as a test post to see if this list is still alive :-) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 14:30:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1eq-0005Pe-GQ for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 14:30:25 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24094 for ; Fri, 21 Oct 2005 14:30:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B284663B4B8; Fri, 21 Oct 2005 18:30:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 9881A63B4B6 for ; Fri, 21 Oct 2005 18:30:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA02527; Fri, 21 Oct 2005 14:30:15 -0400 (EDT) From: der Mouse Message-Id: <200510211830.OAA02527@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 21 Oct 2005 14:27:26 -0400 (EDT) To: ietf-ssh@NetBSD.org Cc: Joseph Galbraith Subject: Re: 64th Ietf... In-Reply-To: <43592288.2070706@vandyke.com> References: <43592288.2070706@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > PS. This also serves as a test post to see if this list is still > alive :-) Well, it seems to be at least mostly alive. But my post of 2005-10-21 00:50 -0400 seems to have fallen into a black hole. I wonder what's wrong.... I'll ping ietf-ssh-owner and see if they have anything to say. Thanks for the help; it seems to be distinctive to me, whatever it is. /~\ 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 16:23:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3Po-0001YV-1s for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:23:00 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16029 for ; Fri, 21 Oct 2005 16:22:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 219ED63B1CF; Fri, 21 Oct 2005 20:22:56 +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 8460863B17E for ; Fri, 21 Oct 2005 20:22:55 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9LKMs4u020282; Fri, 21 Oct 2005 13:22:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j9LKMs0t025991; Fri, 21 Oct 2005 16:22:54 -0400 (EDT) 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 j9LKMsC9012650; Fri, 21 Oct 2005 16:22:54 -0400 (EDT) Subject: Re: 64th Ietf... From: Bill Sommerfeld To: der Mouse Cc: ietf-ssh@NetBSD.org, Joseph Galbraith In-Reply-To: <200510211830.OAA02527@Sparkle.Rodents.Montreal.QC.CA> References: <43592288.2070706@vandyke.com> <200510211830.OAA02527@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain Message-Id: <1129926173.11974.64.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Fri, 21 Oct 2005 16:22:54 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-10-21 at 14:27, der Mouse wrote: > But my post of 2005-10-21 00:50 -0400 seems to have fallen into a black > hole. I wonder what's wrong.... The text part of the hexdump included in the message body triggered a spam filter (three characters in a row with the 0x80 bit set) by using the iso-latin-1 centered-dot character (code 0xb7) instead of the more typical ASCII '.'. it landed in a mailbox which I check about once a day because it's normally just paypal and ebay phish attempts. I just approved it and it should have gone through to subscribers. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 16:14:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3HZ-00030F-Kv for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:14:31 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10879 for ; Fri, 21 Oct 2005 16:14:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2CC5A63B30F; Fri, 21 Oct 2005 20:14:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id B3C4B63B147 for ; Fri, 21 Oct 2005 04:50:40 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA26839; Fri, 21 Oct 2005 00:50:39 -0400 (EDT) From: der Mouse Message-Id: <200510210450.AAA26839@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 21 Oct 2005 00:26:29 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Who's at fault here? Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit 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. Specifically, here is what I'm seeing (logged on the cleartext side of the encryption etc layer): (394) In data (1): (395) 0 34 4 (396) Out data (24): (397) 0 5a 00 00 00 07 73 65 73 73 69 6f 6e 00 00 00 00 Z?session? (398) 10 00 00 00 00 00 00 88 b8 ?? (399) In data (17): (400) 0 5b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 [??? (401) 10 00 (402) Out data (9): (403) 0 5d 00 00 00 00 00 01 00 00 ]?? As I read it: - The first packet (server to me) is a USERAUTH_SUCCESS. - The second (me to server) is a CHANNEL_OPEN, requesting a "session" channel, my number 0, initial window 0, max packet size 35000. - The third (server to me) is a CHANNEL_OPEN_CONFIRMATION, both channel numbers 0, initial window 0, max packet size 32768. - The fourth (me to server) is a CHANNEL_WINDOW_ADJUST, adding 65536 bytes of window to this new channel. 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. I've done enough experiments watching the logs for my end in one window and the other end in the other to convince me that there is a direct causal relationship between behaviour such as this from the client and such messages being logged by the server. But before I file a NetBSD problem report on this, I wanted to get another pair of eyes confirming that the above trace does indeed look perfectly reasonable and is not an example of what the server-logged message seems to think it is. /~\ 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 16:34:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3ab-0002i4-Up for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 16:34:10 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22723 for ; Fri, 21 Oct 2005 16:33:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 068F463B17E; Fri, 21 Oct 2005 20:34:05 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C657263B16A for ; Fri, 21 Oct 2005 20:34:03 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA03252; Fri, 21 Oct 2005 16:34:03 -0400 (EDT) From: der Mouse Message-Id: <200510212034.QAA03252@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 21 Oct 2005 16:27:41 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: 64th Ietf... In-Reply-To: <1129926173.11974.64.camel@thunk> References: <43592288.2070706@vandyke.com> <200510211830.OAA02527@Sparkle.Rodents.Montreal.QC.CA> <1129926173.11974.64.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> But my post of 2005-10-21 00:50 -0400 seems to have fallen into a >> black hole. I wonder what's wrong.... > The text part of the hexdump [tripped filters] by using the > iso-latin-1 centered-dot character (code 0xb7) instead of the more > typical ASCII '.'. I'll try to remember to avoid that when writing to the list in the future. I also may add a way to restrict the text part of hex dumps to ASCII.... > I just approved it and it should have gone through to subscribers. Yes; indeed, I've already received my on-list copy. The list filters rather mangled the non-ASCII stuff (most of it turned into question marks, but there are fewer question marks than there were centered-dots), but for the purposes of the message that doesn't really matter. (I wouldn't even mention it here except that otherwise anyone looking at it could be somewhat dismayed by how the text and hex parts of the dump don't seem to match up.) Since I'm already writing, I'd also like to apologize to Bill for rattling his cage about this prematurely. List admin is a thankless enough task already without his catching unnecesary heat because he's not watching the quarantine mailbox closely enough to catch this right off the mark. /~\ 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 21 17:11:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET4AG-0006tL-13 for secsh-archive@megatron.ietf.org; Fri, 21 Oct 2005 17:11:00 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12262 for ; Fri, 21 Oct 2005 17:10:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 02D8063B51F; Fri, 21 Oct 2005 21:10:49 +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 B9C5363B2D0 for ; Fri, 21 Oct 2005 21:10:46 +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 8058812 for ietf-ssh@NetBSD.org; Fri, 21 Oct 2005 15:10:45 -0600 Message-ID: <43595BDC.7030102@vandyke.com> Date: Fri, 21 Oct 2005 15:21:32 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 CC: ietf-ssh@NetBSD.org Subject: Re: 64th Ietf... References: <43592288.2070706@vandyke.com> In-Reply-To: <43592288.2070706@vandyke.com> 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 Joseph Galbraith wrote: > I know we aren't meeting... but I will be there if anyone > that feels strongly about the SFTP draft wants to hook up > and hash out differences :-) Or a PKI expert interested in consulting on the x.509 draft... oh please, oh please, oh please :-) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 24 10:53:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3h8-0001ki-Ax for secsh-archive@megatron.ietf.org; Mon, 24 Oct 2005 10:53:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13735 for ; Mon, 24 Oct 2005 10:52:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AB7C263B1AD; Mon, 24 Oct 2005 14:52:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (beacon.psc.process.com [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id E42EA63B1A7 for ; Mon, 24 Oct 2005 14:52:54 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: ssh filexfer Date: Mon, 24 Oct 2005 10:56:01 -0400 Message-ID: <3EF96AF20489A34296050FBD5C36ECB918851D@beacon.PSC.process.com> Thread-Topic: Published new filexfer draft... Thread-Index: AcXKDmXM2VU5bkFTR72l71zXcPi7YQOmuLbg From: "Richard Whalen" To: "Joseph Galbraith" , Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I ran across a problem last week that doesn't appear to be covered in = the latest draft. Customer was doing a text transfer of a file. The program does an = SSH_FXP_FSETSTAT at the end with file size specified. This ended up as = an ftruncate, which returned an error because the file was opened for = record access and the offset specified wasn't a record boundary. I've modified my implementation to ignore the setting of the file length = in this situation. I think that we need some text in either the SSH_FXP_OPEN or = SSH_FXP_FSETSTAT stating the it may not be a legal operation to attempt = to set the length for a file that is opened in TEXT transfer mode. ---------------------- Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 24 10:58:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU3mi-00042c-Dp for secsh-archive@megatron.ietf.org; Mon, 24 Oct 2005 10:58:48 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14075 for ; Mon, 24 Oct 2005 10:58:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E685E63B1A7; Mon, 24 Oct 2005 14:58:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from currant.srv.cs.cmu.edu (CURRANT.SRV.CS.CMU.EDU [128.2.194.193]) by mail.netbsd.org (Postfix) with SMTP id C803963B1A3 for ; Mon, 24 Oct 2005 14:58:43 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa24056; 24 Oct 2005 10:58 EDT Received: from jhutz-dyn0.pc.cs.cmu.edu (IDENT:U2FsdGVkX18q+4r+xNS+g5+Gr1vHor7fcoFk56OMEO4@JHUTZ-DYN0.PC.CS.CMU.EDU [128.2.200.136]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j9OEwUYv002892 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Oct 2005 10:58:31 -0400 (EDT) Date: Mon, 24 Oct 2005 10:58:30 -0400 From: Jeffrey Hutzelman To: Richard Whalen , Joseph Galbraith , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: ssh filexfer Message-ID: <009442681EE6DAC4ED312C7F@bistromath.pc.cs.cmu.edu> In-Reply-To: <3EF96AF20489A34296050FBD5C36ECB918851D@beacon.PSC.process.com> References: <3EF96AF20489A34296050FBD5C36ECB918851D@beacon.PSC.process.com> Originator-Info: login-token=Mulberry:01cvTIltxcPQq+P0AXpXL4BQlm/8H5KEHfafb7qHQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) 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 Monday, October 24, 2005 10:56:01 AM -0400 Richard Whalen wrote: > I ran across a problem last week that doesn't appear to be covered in the > latest draft. > > Customer was doing a text transfer of a file. The program does an > SSH_FXP_FSETSTAT at the end with file size specified. This ended up as > an ftruncate, which returned an error because the file was opened for > record access and the offset specified wasn't a record boundary. It could have been worse -- the specified size could have happened to be on a record boundary, but still too small. Perhaps clients transferring files in text mode SHOULD NOT attempt to set the file size. It seems like doing so is likely to do more harm than good. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Oct 26 21:05:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwCj-00019w-87 for secsh-archive@megatron.ietf.org; Wed, 26 Oct 2005 21:05:17 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12141 for ; Wed, 26 Oct 2005 21:05:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 66A0B63B46C; Thu, 27 Oct 2005 01:05:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mail.netbsd.org (Postfix) with ESMTP id F355763B431 for ; Thu, 27 Oct 2005 01:05:09 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9R159dK018812 for ; Wed, 26 Oct 2005 18:05:09 -0700 (PDT) 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 j9R158H0028413; Wed, 26 Oct 2005 21:05:08 -0400 (EDT) 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 j9R158MV009057; Wed, 26 Oct 2005 21:05:08 -0400 (EDT) Subject: [Fwd: WG Action: RECHARTER: Integrated Security Model for SNMP (isms)] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1130375108.6688.346.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Wed, 26 Oct 2005 21:05:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI: ISMS has been rechartered to work on a revision to SNMP which runs over SSH. - Bill -----Forwarded Message----- From: IESG Secretary To: IETF Announcement list Cc: isms@ietf.org, Juergen Quittek Subject: WG Action: RECHARTER: Integrated Security Model for SNMP (isms) Date: Mon, 24 Oct 2005 17:29:15 -0400 The Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Integrated Security Model for SNMP (isms) ========================================== Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Juergen Quittek Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals and Milestones: Done Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution Done Decision about which architecture the WG will focus its efforts on Oct 05 Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models Oct 05 Initial version of a document specifying the SSH security model for SNMP Feb 06 Initial version of an applicability statement that sets up reasonable mandatory to implement methods Feb 06 Submit TMSM document to IESG Jun 06 Submit SSH TMSM to IESG Jun 06 Submit RADIUS mapping model for SNMP to IESG Aug 06 Submit applicability statement to IESG Dec 06 Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Oct 27 16:51:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEia-0007Cq-QF for secsh-archive@megatron.ietf.org; Thu, 27 Oct 2005 16:51:24 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16500 for ; Thu, 27 Oct 2005 16:51:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B59E263B586; Thu, 27 Oct 2005 20:51: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 04B8663B58D for ; Thu, 27 Oct 2005 20:51: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 j9RKp94u018051 for ; Thu, 27 Oct 2005 13:51:09 -0700 (PDT) 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 j9RKp9H0022735; Thu, 27 Oct 2005 16:51:09 -0400 (EDT) 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 j9RKp8Io002337; Thu, 27 Oct 2005 16:51:09 -0400 (EDT) Subject: Eyeballs needed. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1130446268.1347.408.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Thu, 27 Oct 2005 16:51:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit 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 Oct 27 23:19:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKmL-0000b8-I6 for secsh-archive@megatron.ietf.org; Thu, 27 Oct 2005 23:19:41 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15205 for ; Thu, 27 Oct 2005 23:19:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D7B763B30C; Fri, 28 Oct 2005 03:19:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mail.netbsd.org (Postfix) with ESMTP id A163663B1A8 for ; Fri, 28 Oct 2005 03:19:29 +0000 (UTC) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP100E4QVRVWL@szxga01-in.huawei.com> for ietf-ssh@netbsd.org; Fri, 28 Oct 2005 11:16:43 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP100LJ7VRV2U@szxga01-in.huawei.com> for ietf-ssh@netbsd.org; Fri, 28 Oct 2005 11:16:43 +0800 (CST) Received: from m19684 ([10.110.100.54]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IP100IZEW079N@szxml01-in.huawei.com>; Fri, 28 Oct 2005 11:21:43 +0800 (CST) Date: Fri, 28 Oct 2005 11:10:35 +0800 From: Miao Fuyou Subject: RE: [Fwd: WG Action: RECHARTER: Integrated Security Model for SNMP (isms)] In-reply-to: <1130375108.6688.346.camel@thunk> To: "'Bill Sommerfeld'" , ietf-ssh@NetBSD.org Message-id: <000201c5db6d$2a36cd80$36646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7BIT IMHO, ISMS working group will need a SSH MIB to be developed because now SNMP may also manage underlying SSH to make itselft works well. I believe ISMS WG will not do the work because of scope . Shall secsh working group develop a SSH MIB to meet the requirement? -----Original Message----- From: ietf-ssh-owner@NetBSD.org [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Bill Sommerfeld Sent: Thursday, October 27, 2005 9:05 AM To: ietf-ssh@netbsd.org Subject: [Fwd: WG Action: RECHARTER: Integrated Security Model for SNMP (isms)] FYI: ISMS has been rechartered to work on a revision to SNMP which runs over SSH. - Bill -----Forwarded Message----- From: IESG Secretary To: IETF Announcement list Cc: isms@ietf.org, Juergen Quittek Subject: WG Action: RECHARTER: Integrated Security Model for SNMP (isms) Date: Mon, 24 Oct 2005 17:29:15 -0400 The Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Integrated Security Model for SNMP (isms) ========================================== Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Juergen Quittek Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Sam Hartman Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem, for which there is one currently defined model - the User-based Security Model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new security model for SNMP that integrates with widely deployed user and key management systems, as a supplement to the USM security model. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. However, the integration of a transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. This item may be a RADEXT work item last-aclled in both groups. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals and Milestones: Done Cut-off date for internet-drafts to be submitted to the working group for consideration as a proposed solution Done Decision about which architecture the WG will focus its efforts on Oct 05 Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models Oct 05 Initial version of a document specifying the SSH security model for SNMP Feb 06 Initial version of an applicability statement that sets up reasonable mandatory to implement methods Feb 06 Submit TMSM document to IESG Jun 06 Submit SSH TMSM to IESG Jun 06 Submit RADIUS mapping model for SNMP to IESG Aug 06 Submit applicability statement to IESG Dec 06 Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 01:29:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVMnb-00018t-QR for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 01:29:08 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21565 for ; Fri, 28 Oct 2005 01:28:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9B40263B5CE; Fri, 28 Oct 2005 05:29:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtp.sina.com.cn (unknown [202.108.3.176]) by mail.netbsd.org (Postfix) with SMTP id 50D6A63B1A4 for ; Fri, 28 Oct 2005 05:29:00 +0000 (UTC) Received: (qmail 76458 invoked from network); 28 Oct 2005 05:28:46 -0000 Received: from unknown (HELO mss-8894ba634c0) (202.103.154.87) by smtp.sina.com.cn with SMTP; 28 Oct 2005 05:28:46 -0000 From: "Steven Lee" Subject: $ 3.9 /1,000 stitches digitize To: ietf-ssh@NetBSD.org Reply-To: Steven.Lee@micolong.com Date: Fri, 28 Oct 2005 13:25:20 +0800 X-Priority: 3 X-Library: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Message-Id: <20051028052900.50D6A63B1A4@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hello, I am Steven Lee, sales manager of Micolong Manufactory Ltd. Here we want to offer high quality and low price digitizing service with the following: 1. Free 2,000 stitches for first order 2. Low price: $ 3.9 per 1,000 stitches 3. Short cycle time: normal within 48 hours we can send back digitizing orders if image received first. 4. Free editing in most 5. Free format change (DST, EXP, CND, DSB, DSZ, EMB, KSM, T04, T05, T09,100) If you are interested, welcome email to the following: Steven.Lee@micolong.com Steven.Lee88@163.com Looking forward to hearing from you soon. Steven Lee Sales Manager Micolong Manufacture Ltd. www.micolong.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 03:20:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVOXS-0006H3-Rr for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 03:20:35 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27399 for ; Fri, 28 Oct 2005 03:20:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A33AA63B5DB; Fri, 28 Oct 2005 07:20:28 +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 CA02263B5DA for ; Fri, 28 Oct 2005 07:20:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 7AB2892D5E; Fri, 28 Oct 2005 08:45:17 +0200 (CEST) Message-ID: <4361C956.50404@siliconcircus.com> Date: Fri, 28 Oct 2005 08:46:46 +0200 From: Jon Bright User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. References: <1130446268.1347.408.camel@thunk> In-Reply-To: <1130446268.1347.408.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: > > 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, ...". 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. 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...". 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 :-) 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." That's all I saw in -architecture. I'll be reading the others later. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 05:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQda-0005xO-0R for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:35:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03921 for ; Fri, 28 Oct 2005 05:34:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F05F463B5DD; Fri, 28 Oct 2005 09:34:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from galaxy.systems.pipex.net (galaxy.systems.pipex.net [62.241.162.31]) by mail.netbsd.org (Postfix) with ESMTP id DD62663B13B for ; Fri, 28 Oct 2005 09:34:54 +0000 (UTC) Received: from pc6 (1Cust65.tnt3.lnd4.gbr.da.uu.net [62.188.132.65]) by galaxy.systems.pipex.net (Postfix) with SMTP id 78B21E00018C; Fri, 28 Oct 2005 10:34:51 +0100 (BST) Message-ID: <04bf01c5db9a$4b9aa640$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Bill Sommerfeld" , References: <1130446268.1347.408.camel@thunk> Subject: Re: Eyeballs needed. Date: Fri, 28 Oct 2005 10:32:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Just to check the obvious, the underlying I-Ds that were given to the RFC Editor are the ones that came out in September with an updated file name but with the previous name on the first page eg file name draft-ietf-secsh-architecture-23.txt: title inside draft-ietf-secsh-architecture-22.txt: Yes? Tom Petch ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Thursday, October 27, 2005 10:51 PM Subject: Eyeballs needed. > 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 Fri Oct 28 09:47:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUa1-0002fT-3y for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:47:37 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15148 for ; Fri, 28 Oct 2005 09:47:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C0A8F63B304; Fri, 28 Oct 2005 13:47:09 +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 9972C63B234 for ; Fri, 28 Oct 2005 13:47:08 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EVUZP-0001aM-00 for ietf-ssh@netbsd.org; Fri, 28 Oct 2005 14:46:59 +0100 Date: Fri, 28 Oct 2005 14:46:59 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051028134659.GA30930@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="hOcCNbCCxyk/YU74" 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 --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. --hOcCNbCCxyk/YU74 Content-Type: message/rfc822 Content-Disposition: attachment; filename=bjh21-assignednumbers MIME-Version: 1.0 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jun 14 06:27:13 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00501 for ; Tue, 14 Jun 2005 06:27:12 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 010773A410; Tue, 14 Jun 2005 10:27: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 EC30C3A3B3 for ; Tue, 14 Jun 2005 10:27:04 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1Di8dL-0005Pl-00; Tue, 14 Jun 2005 11:27:03 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org, sommerfeld@sun.com Subject: Re: IANA protocol registry for secure shell protocol parameters now exists. In-Reply-To: <1118684487.26495.3.camel@thunk> References: <1118684487.26495.3.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Tue, 14 Jun 2005 11:27:03 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Status: RO Content-Length: 1738 Lines: 45 In article <1118684487.26495.3.camel@thunk> you write: >FYI, the IANA registry for Secure Shell protocol parameters has been >created: > >http://www.iana.org/assignments/ssh-parameters Oh dear. This reveals several errors in the core drafts that somehow slipped through (though I'm sure I noticed most of them and even got acks from the editor). I'll mail IANA and ask what's to be done. For reference, here's the list I'm sending them: The following entries in the Message Numbers table shouldn't have been listed in draft-ietf-secsh-assignednumbers-12, since they're in the method-specific space: 30 SSH_MSG_KEXDH_INIT [SSH-TRANS] 31 SSH_MSG_KEXDH_REPLY [SSH-TRANS] The following entries in the Message Numbers table shouldn't have been registered by draft-ietf-secsh-auth-kbdinteract-07 because they're in the method-specific space: 60 SSH_MSG_USERAUTH_INFO_REQUEST [RFC-ietf-secsh-auth-kbdinteract-07.txt] 61 SSH_MSG_USERAUTH_INFO_RESPONSE The following entry for the Pseudo-Terminal Encoded Terminal Modes table provides the correct reference: 0 TTY_OP_END Indicates end of options. [SSH-CONNECT, section 8] The following entry is missing from the Authentication Method Names table, despite being defined by draft-ietf-secsh-auth-kbdinteract-07: keyboard-interactive [RFC-ietf-secsh-auth-kbdinteract-07.txt] 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] -- Ben Harris --hOcCNbCCxyk/YU74-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 10: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 1EVVEQ-0001iE-LU for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 10:29:22 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20238 for ; Fri, 28 Oct 2005 10:29:05 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 60EFA63B624; Fri, 28 Oct 2005 14:29:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av11-2-sn2.hy.skanova.net (av11-2-sn2.hy.skanova.net [81.228.8.184]) by mail.netbsd.org (Postfix) with ESMTP id 7F5EE63B623 for ; Fri, 28 Oct 2005 14:29:16 +0000 (UTC) Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id C548A3830D; Fri, 28 Oct 2005 16:05:27 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id B176137F5E for ; Fri, 28 Oct 2005 16:05:27 +0200 (CEST) Received: from [192.168.0.101] (h220n1fls34o850.telia.com [217.208.158.220]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9914737E4C for ; Fri, 28 Oct 2005 16:05:27 +0200 (CEST) Message-ID: <43623022.6070800@streamsec.se> Date: Fri, 28 Oct 2005 16:05:22 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Definition of "packet" 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 This ought to be a simple question, but it seems it is not spelled out anywhere in specification: 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? a) Just the raw packet load b) Packet load + SSH specific formatting (e.g. 4 for the length specifier of a "string") c) Packet load + formatting + channel packet header (e.g. 5 for byte SSH_MSG_CHANNEL_DATA; uint32 recipient channel) d) Packet load + formatting + channel packet header + transport packet formatting (as per SSH Transport Layer Protocol draft paragraph 6) e) Packet load + formatting + channel packet header + transport packet formatting + TCP/IP headers ...etc From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 11:19:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW0y-0001no-Qs for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 11:19:33 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24099 for ; Fri, 28 Oct 2005 11:19:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F85263B631; Fri, 28 Oct 2005 15:19:27 +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 C202063B62C for ; Fri, 28 Oct 2005 15:19:25 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 9E9CB32B02; Fri, 28 Oct 2005 17:18:09 +0200 (CEST) Message-ID: <436241AF.9000707@siliconcircus.com> Date: Fri, 28 Oct 2005 17:20:15 +0200 From: Jon Bright User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. References: <1130446268.1347.408.camel@thunk> In-Reply-To: <1130446268.1347.408.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: > > 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? 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. > 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. 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." 6.3: "The ciphers in each direction MUST run independent of each other." -> "The ciphers in each direction MUST run independently of one another."? 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. 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."? 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." > 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. 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. 6.10: If I'm following the quoting conventions used here correctly, 'signal name' here should be swapped for "signal name". 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? 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."? > 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 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Oct 28 18:09:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVcPi-0002YI-Ky for secsh-archive@megatron.ietf.org; Fri, 28 Oct 2005 18:09:30 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22769 for ; Fri, 28 Oct 2005 18:09:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E990E63B18E; Fri, 28 Oct 2005 22:09:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id A5D3663B16E for ; Fri, 28 Oct 2005 22:09:20 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA06413; Fri, 28 Oct 2005 18:09:14 -0400 (EDT) From: der Mouse Message-Id: <200510282209.SAA06413@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Fri, 28 Oct 2005 16:42:36 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <1130446268.1347.408.camel@thunk> References: <1130446268.1347.408.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit 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. 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...". 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.) 4.9.5: I think this change is wrong, unless s/Names/names/ is also done, and even then I don't like it. 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? 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. > 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. 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/. 8, last paragraph: everywhere else "as described in [RFC2434]" has been preceded by a comma; for consistency, I think it should be here too. 9.1: I'd s/when knowing/given/ s/in properly implementing/of properly implementing/ 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. 9.3.1, end of third paragraph: s/longer/long/ 9.3.3, second paragraph: s/more so true/more true/ 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/ 9.3.4, last paragraph: s/non-security critical/non-security-critical/. 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"'? 9.3.9: I'd like to see s/attempts of traffic/attempts at traffic/. 10: As in 4250 section 6.2, I'd like to see the NIST explicitly called out as a USA body. 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 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 29 18:50:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVzWd-0000KV-Qr for secsh-archive@megatron.ietf.org; Sat, 29 Oct 2005 18:50:11 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29054 for ; Sat, 29 Oct 2005 18:49:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1FF1A63B25D; Sat, 29 Oct 2005 22:50: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 608E563B264 for ; Sat, 29 Oct 2005 22:50:05 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EVzWV-0001Dj-00 for ietf-ssh@netbsd.org; Sat, 29 Oct 2005 23:50:03 +0100 Date: Sat, 29 Oct 2005 23:50:03 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" Message-ID: <20051029225003.GA29394@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: <43623022.6070800@streamsec.se> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Henrick Hellstrom writes: > This ought to be a simple question, but it seems it is not spelled out > anywhere in specification: > > 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? I assume that you're referring to the parameter in the SSH_MSG_CHANNEL_OPEN packet. > a) Just the raw packet load > b) Packet load + SSH specific formatting (e.g. 4 for the length > specifier of a "string") > c) Packet load + formatting + channel packet header (e.g. 5 for byte > SSH_MSG_CHANNEL_DATA; uint32 recipient channel) > d) Packet load + formatting + channel packet header + transport packet > formatting (as per SSH Transport Layer Protocol draft paragraph 6) > e) Packet load + formatting + channel packet header + transport packet > formatting + TCP/IP headers > ...etc I agree this is not absolutely clear. I think, given the context, that I'd expect it to refer to the maximum amount of actual channel data in a packet (i.e., the maximum length of the `data' field, not including the string length, in the SSH_MSG_CHANNEL_DATA packet), and similar for related types of packet. I think this is your option `a'. PuTTY at least appears to agree with this. If there's consensus on this, can we get a note into the RFC before it's published? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Oct 29 22:11:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW2f0-00016p-46 for secsh-archive@megatron.ietf.org; Sat, 29 Oct 2005 22:11:02 -0400 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06192 for ; Sat, 29 Oct 2005 22:10:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EB0FA63B28C; Sun, 30 Oct 2005 02:10:56 +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 6086163B126 for ; Sun, 30 Oct 2005 02:10:56 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2005 19:09:54 -0700 X-IronPort-AV: i="3.97,266,1125903600"; d="scan'208"; a="670405082:sNHT22312788" Received: from sjc-cde-001.cisco.com (sjc-cde-001.cisco.com [171.71.155.95]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9U29pJi028752; Sat, 29 Oct 2005 19:09:52 -0700 (PDT) Date: Sat, 29 Oct 2005 19:09:51 -0700 (PDT) From: Chris Lonvick To: Tom Petch cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. In-Reply-To: <04bf01c5db9a$4b9aa640$0601a8c0@pc6> Message-ID: References: <1130446268.1347.408.camel@thunk> <04bf01c5db9a$4b9aa640$0601a8c0@pc6> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Tom, Yes. The diffs (.html files) are between the September drafts and what the RFC Editor has changed. Thanks, Chris On Fri, 28 Oct 2005, Tom Petch wrote: > Just to check the obvious, the underlying I-Ds that were given to the RFC Editor > are the ones that came out in September with an updated file name but with the > previous name on the first page eg > file name draft-ietf-secsh-architecture-23.txt: > title inside draft-ietf-secsh-architecture-22.txt: > > Yes? > Tom Petch From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Oct 30 07:26:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWCGP-0005oJ-HG for secsh-archive@megatron.ietf.org; Sun, 30 Oct 2005 07:26: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 HAA02188 for ; Sun, 30 Oct 2005 07:25:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CFA8F63B23D; Sun, 30 Oct 2005 12:26:13 +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 15D6663B10E for ; Sun, 30 Oct 2005 12:26:13 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EWCGK-0007rr-00 for ietf-ssh@netbsd.org; Sun, 30 Oct 2005 12:26:12 +0000 Date: Sun, 30 Oct 2005 12:26:12 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Definition of "packet" Message-ID: <20051030122611.GA21120@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org References: <43623022.6070800@streamsec.se> <20051029225003.GA29394@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051029225003.GA29394@chiark.greenend.org.uk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I wrote: > I assume that you're referring to the parameter in the > SSH_MSG_CHANNEL_OPEN packet. [...] > I agree this is not absolutely clear. > > I think, given the context, that I'd expect it to refer to the maximum > amount of actual channel data in a packet (i.e., the maximum length of > the `data' field, not including the string length, in the > SSH_MSG_CHANNEL_DATA packet), and similar for related types of packet. I > think this is your option `a'. > > PuTTY at least appears to agree with this. From my brief reading of the source, OpenSSH (4.2p1) also appears to take this interpretation. > If there's consensus on this, can we get a note into the RFC before it's > published? 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. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 31 09:23:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWaZ4-00016i-UF for secsh-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:23: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 JAA10600 for ; Mon, 31 Oct 2005 09:22:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F09CE63B214; Mon, 31 Oct 2005 14:23:05 +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 34DFD63B104 for ; Mon, 31 Oct 2005 14:23:05 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EWaYs-0000n3-00 for ietf-ssh@netbsd.org; Mon, 31 Oct 2005 14:22:58 +0000 Date: Mon, 31 Oct 2005 14:22:58 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051031142258.GA21786@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 A couple more comments: 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? The reference to [5] in the body of the new text is: | The method described here can provide out-of-band verification by | looking up a fingerprint of the server public key in the DNS [1][2] | and using DNSSEC [5] to verify the lookup. (RFC2535 may not be the correct reference any more; it looks like it should be one of RFC4033/4/5 these days.) > 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 I echo Jon Bright's comment about the semantic change to the text about normalizing passwords. However, I make it section 3.4, not section 8. In section 7.1 (Normative References), an extra "2005." has snuck in: | [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell | (SSH) Protocol Architecture", RFC 4251, November | 2005. 2005. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 31 09:30:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWafz-0002oZ-6m for secsh-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:30: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 JAA10985 for ; Mon, 31 Oct 2005 09:29:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0222563B393; Mon, 31 Oct 2005 14:29:40 +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 2E50163B38B for ; Mon, 31 Oct 2005 14:29:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id E83F0933BE for ; Mon, 31 Oct 2005 15:28:22 +0100 (CET) Message-ID: <43662AA6.5050100@siliconcircus.com> Date: Mon, 31 Oct 2005 15:31:02 +0100 From: Jon Bright User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. References: <20051031142258.GA21786@chiark.greenend.org.uk> In-Reply-To: <20051031142258.GA21786@chiark.greenend.org.uk> 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 Jacob Nevins wrote: > > I echo Jon Bright's comment about the semantic change to the text > about normalizing passwords. However, I make it section 3.4, not > section 8. Just to clarify: this appears in two places. It's 3.4 in -kbdinteract and 8 in -userauth. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Oct 31 09:43:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWasl-0005hu-0G for secsh-archive@megatron.ietf.org; Mon, 31 Oct 2005 09:43:31 -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 JAA11635 for ; Mon, 31 Oct 2005 09:43:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7100163B3A3; Mon, 31 Oct 2005 14:43:27 +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 CCC7363B3A2 for ; Mon, 31 Oct 2005 14:43:26 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EWasg-0007iL-00 for ietf-ssh@netbsd.org; Mon, 31 Oct 2005 14:43:26 +0000 Date: Mon, 31 Oct 2005 14:43:26 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: Eyeballs needed. Message-ID: <20051031144326.GA27020@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: <43662AA6.5050100@siliconcircus.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: > Just to clarify: this appears in two places. It's 3.4 in -kbdinteract > and 8 in -userauth. So it does. Sorry.