From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 01 00:16:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAgUe-00071g-SQ for secsh-archive@megatron.ietf.org; Thu, 01 Sep 2005 00:16: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 AAA08683 for ; Thu, 1 Sep 2005 00:16:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A48F63B139; Thu, 1 Sep 2005 04:16:01 +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 945AE63B108 for ; Thu, 1 Sep 2005 04:16:00 +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 7831421; Wed, 31 Aug 2005 22:15:59 -0600 Message-ID: <43168272.9070205@vandyke.com> Date: Wed, 31 Aug 2005 22:24:18 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: Other Socket Tunnels (Was: New draft Possibilities) References: <4316045A.5040001@vandyke.com> <200509010355.XAA11937@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509010355.XAA11937@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: >>> The extra name in there breaks the format of SSH_MSG_CHANNEL_OPEN. >>> Since you don't have any data specific to "direct-socket" apart from >>> that name, it would be better to just make it part of the channel >>> type (so "direct-udpip", "direct-unix", "direct-named-pipe"). >> Alternatively, the following format works: [type name at end] >> (I'm not commenting on which would be better... just that both are >> legal.) > > In case anyone cares what I think - I'd prefer one channel type with a > subtype field ("direct-socket" with "udp", "named-pipe", etc). Well, since no ones volunteering to write a draft (unless Sara is?), I think this is mostly a 'wouldn't it be nice' conversation :-) I wish I had time... but I'm not even keeping up with the drafts I'm on tap for. Thanks, Joseph PS. In case anyone cares what I think-- I'd love to see a draft for this functionality. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 01 00:23:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAgbp-0000FD-Rr for secsh-archive@megatron.ietf.org; Thu, 01 Sep 2005 00:23: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 AAA08934 for ; Thu, 1 Sep 2005 00:23:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AE35B63B165; Thu, 1 Sep 2005 04:23:25 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from fsau.vintela.com (unknown [202.183.100.57]) by mail.netbsd.org (Postfix) with ESMTP id 8F43F63B108 for ; Thu, 1 Sep 2005 04:23:23 +0000 (UTC) Received: from lark.vintela.com (lark.vintela.com [10.20.36.133]) by fsau.vintela.com (Postfix) with ESMTP id 8F1AA32E3F; Thu, 1 Sep 2005 14:23:22 +1000 (EST) Date: Thu, 1 Sep 2005 14:23:18 +1000 (EST) From: David Leonard X-X-Sender: davidl@lark.vintela.com To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: gskeykex - Delete_sec_context() on re-key In-Reply-To: <606125828F4E72329EA38418@sirius.fac.cs.cmu.edu> Message-ID: References: <606125828F4E72329EA38418@sirius.fac.cs.cmu.edu> Organization: Vintela; Quest Software MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 31 Aug 2005, Jeffrey Hutzelman wrote: > On Thursday, September 01, 2005 11:43:52 AM +1000 David Leonard > wrote: > > I was reading through the secsh-gsskeyex draft again and it struck > > me that when re-keying there is no message provision for passing back the > > possible token generated by a call to GSS_Delete_sec_context(). > > That's correct. When you're done with a context, which in this protocol means > pretty much as soon as key exchange has completed successfully, you can just > call GSS_Delete_sec_context() without an output token buffer, regardless of > whether you are the client or server. The only purpose of an output token > from this call is to signal _via a context token_ that the context should be > destroyed. In this protocol, you don't need to do that, because you always > know out-of-band when the context can be deleted. Ah okay, that makes sense. Some text in RFC 2743 clarifies this too: and that the token parameter was retained for backward compat. that's a relief. > > The result is that the protocol will leak unreachable context > > over a long session. > > Only if you fail to call GSS_Delete_sec_context() with a context when you are > done using it. Note that you do _not_ need to keep the context around for the > life of the session -- it's only used during key exchange. It's also used in keyex authentication. So the server does have to keep the first context around for that. Interestingly, every other context is short-lived so that should be okay: max of two contexts. Consider this example session: C: KEXGSS_INIT S: gss_accept_sec_ctx .. etc .. success -> context #1 (keep) ... C: USERAUTH gssapi-with-mic S: gss_accept_sec_ctx .. etc.. fail (say) -> context #2 (del/incomplete) ... C: KEXGSS_INIT S: gss_accept_sec_ctx .. etc .. success -> context #3 (can be deleted) ... C: USERAUTH gsskeyex "4. The GSSAPI context used with this method is always that established during an initial GSSAPI-based key exchange. [...] The client SHOULD NOT try this method more than once" S: gss_verify_mic .. etc.. <- context #1 (can now be deleted) Even without the re-key in the middle it shows how the initial kexgss context must be preserved until a gsskeyex is attempted. -- David Leonard Vintela Resource Central software engineer Quest Software; Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 01 10:45:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAqK7-0000uk-If for secsh-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:45:53 -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 KAA08701 for ; Thu, 1 Sep 2005 10:45:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7719D63B57C; Thu, 1 Sep 2005 14:45:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mtagate4.uk.ibm.com (mtagate4.uk.ibm.com [195.212.29.137]) by mail.netbsd.org (Postfix) with ESMTP id 1339563B57B for ; Thu, 1 Sep 2005 14:45:44 +0000 (UTC) Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j81EVjKT305002 for ; Thu, 1 Sep 2005 14:31:45 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j81EViMu241616 for ; Thu, 1 Sep 2005 15:31:44 +0100 Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j81EViR2029335 for ; Thu, 1 Sep 2005 15:31:44 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j81EVhFe029330; Thu, 1 Sep 2005 15:31:43 +0100 Received: from zurich.ibm.com (dhcp23-232.zurich.ibm.com [9.4.23.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA61578; Thu, 1 Sep 2005 16:31:43 +0200 Message-ID: <431710CF.5030406@zurich.ibm.com> Date: Thu, 01 Sep 2005 16:31:43 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bill Sommerfeld CC: Sam Hartman , Phillip Remaker , Joseph Galbraith , Elwyn Davies , ietf-ssh@NetBSD.org, IESG Subject: Re: DISCUSS: draft-ietf-secsh-break-04 References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> <4315AED4.7040104@cisco.com> <1125512748.13570.158.camel@thunk> In-Reply-To: <1125512748.13570.158.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I'll clear my DISCUSS when I see that note in the tracker Brian Bill Sommerfeld wrote: > On Wed, 2005-08-31 at 13:38, Sam Hartman wrote: > >> Phillip> Good point. I'm ambivalent, but I will copy ietf-ssh to >> Phillip> see what the opinion of the people who have already >> Phillip> developed the protoype code think. >> >>I did so yesterday and my reading of the consensus of that list is >>that I will add an rfc editor note removing the possibility that the >>break length field is absent. > > > That is my reading of the consensus as well. > > - Bill > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 01 17: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 1EAwdd-0004Ji-98 for secsh-archive@megatron.ietf.org; Thu, 01 Sep 2005 17: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 RAA00356 for ; Thu, 1 Sep 2005 17:30:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 73DB663B598; Thu, 1 Sep 2005 21:30:18 +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 A733463B5AB for ; Thu, 1 Sep 2005 21:30:17 +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 j81LUCHT011750; Thu, 1 Sep 2005 14:30:13 -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 j81LUCUj000755; Thu, 1 Sep 2005 17:30:12 -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 j81LU5px011181; Thu, 1 Sep 2005 17:30:06 -0400 (EDT) Subject: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Russ Housley Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <1125337411.453.8.camel@thunk> References: <1125337411.453.8.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1125610205.9587.81.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 01 Sep 2005 17:30:05 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit All of the encryption modes described in this document are RECOMMENDED or OPTIONAL. Why isn't one of them REQUIRED? This has been discussed within the working group, and there is little support for and strong opposition at this point to defining one algorithm as REQUIRED. (My personal view on this point puts me in the clear minority of those who have spoken up so far). It appears that a document listing one as REQUIRED would be unlikely to have the consensus of the WG. I'll collect the arguments made against it so far: argument 1: It's one thing to say "if you support ssh then you MUST support 3des-cbc". It's quite another to say "if you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. The former insures that ssh implementations will be interoperable; the latter does not appear to me to add any value. argument 2: Because it's not appropriate; newmodes is not so much a thing to implement or conform to in its own right as it is a collection of individual things to implement or conform to. Thus, making (say) des3-ctr REQUIRED is really just saying "you cannot claim to do newmodes if you don't do des3-ctr", but since claiming to implement newmodes is not a useful thing (as opposed to claiming implementation of particular things defined in newmodes), this is not useful. argument 3: (against my proposed aes128-ctr REQUIRED): I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH implementations are required to have 3DES code around anyway to support 3des-cbc, so anyone implementing newmodes can put in 3des-ctr support trivially, whereas aes128-ctr might be a lot more effort or even impossible (imagine a small implementation without room for both 3DES and AES). This does raise the question of how to arrange a transition to AES (or whatever) in the longer term, but I don't think it should be done on the back of newmodes. ... Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all that I think it's unnecessary. I _am_ opposed to making aes128-ctr REQUIRED. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 02 09:14:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBBNa-0004iu-9w for secsh-archive@megatron.ietf.org; Fri, 02 Sep 2005 09:14:53 -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 JAA04963 for ; Fri, 2 Sep 2005 09:14:47 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 95B2963B5D6; Fri, 2 Sep 2005 13:14:43 +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 A1B4263B5E2 for ; Fri, 2 Sep 2005 13:14:42 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EBBNR-0002Oa-00 for ietf-ssh@netbsd.org; Fri, 02 Sep 2005 14:14:41 +0100 Date: Fri, 2 Sep 2005 14:14:41 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-03.txt Message-ID: <20050902131441.GB26751@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Thanks for removing SCP. There is no text tying words like MAY and MUST to RFC2119. | 3.1 SSH connection parameters | | The following parameters are associated with an SSH connection and | are applicable to SSH and SFTP. All parameters are optional and MUST | NOT overwrite configured defaults. [...] | The fingerprint parameter contains the fingerprint of the host key | for the host specified in the URL. [...] | This parameter MUST NOT overwrite a key that is | already configured for the host. There is an ambiguity here over whether the prohibition is of overriding any cached host key for this session, or merely of permanently replacing the cached host key. Assuming both should be disallowed, "overwrite" should be changed to "override" throughout. | 6. Security Considerations [...] | If a locally configured key exists for the | server already it MUST NOT be automatically overwritten with | information from the URI. Same comment. | 3.2 SFTP Parameters [...] | typecode | | The typecode identifies the type of file which determines how it | will be treated. [...] No default behaviour is specified for the case where the typecode is not present. This could lead to interoperability problems similar to those which FTP has, where some clients default to ASCII mode, and others to binary. I think that "i" (no conversion) is an appropriate default in the absence of further information; it's supported by all filexfer implementations, and in any case is the "safe" thing to do if nothing is known about the file. I hesitate to mandate this as a default, however; implementations should probably be free to use the "text-hint" attribute to determine an appropriate transfer mode for the file, and also to open directories in "d" mode. How about the following text (new paragraph after the one above)?: In the absence of this parameter, files SHOULD be transmitted as if "i" had been specified. However, information from the server (such as the "text-hint" attribute) MAY be used to select an alternative mode. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 02 10:22:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCRJ-0001RI-0U for secsh-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:22:45 -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 KAA09631 for ; Fri, 2 Sep 2005 10:22:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A734563B5F3; Fri, 2 Sep 2005 14:21:37 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id C7B7B63B136 for ; Fri, 2 Sep 2005 14:21:36 +0000 (UTC) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j82ELaDB026365 for ; Fri, 2 Sep 2005 08:21:36 -0600 (MDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j82ELZf8009294; Fri, 2 Sep 2005 07:21:35 -0700 (PDT) Subject: break and gsskeyex passed the IESG yesterday. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1125670867.13079.34.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Fri, 02 Sep 2005 10:21:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit According to the datatracker, both draft-ietf-secsh-break and draft-ietf-secsh-gsskeyex were approved by the IESG yesterday. That will make a total of 10 documents in the RFC editor queue from this WG. next in line: -publickey-subsystem (WG last call timer expired this week; will summarize comments today) -uri (looks ready for WG last call with some nits). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 02 10:32:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBCb8-0006ZI-8p for secsh-archive@megatron.ietf.org; Fri, 02 Sep 2005 10:32:54 -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 KAA11092 for ; Fri, 2 Sep 2005 10:32:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B0A5863B2C9; Fri, 2 Sep 2005 14:32:50 +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 0284163B136 for ; Fri, 2 Sep 2005 14:32:49 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1EBCb3-0005bi-00 for ietf-ssh@netbsd.org; Fri, 02 Sep 2005 15:32:49 +0100 Date: Fri, 2 Sep 2005 15:32:49 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-09.txt Message-ID: <20050902143249.GK19805@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list [I realise that these comments are rather late as this document is on its way into the IESG. I don't think any of these comments should hold up publication, but if the document is respun for other reasons it would be nice if they were taken into account.] Neither the document title nor the abstract mention that this document defines a standard textual representation for public key fingerprints. This makes it harder than it could be to discover where the fingerprint format is defined. I suggest the following paragraph be added to the Abstract: In addition, this document defines a standard textual representation for SSH public key fingerprints. Also, typos/nits (in addition to der Mouse's list in <200508230323.XAA03425@Sparkle.Rodents.Montreal.QC.CA>): 3.5 (Differences with RFC1421 PEM formats): | Implemetors should take care to notice that while the format is s/Implemetors/Implementors/ | o The other specifications use different BEGIN/END delimeters (five s/delimeters/delimiters/ 3.6 (Examples) | (note that the examples all wrap before 72 lines to meet ietf s/lines/columns/ s/ietf/IETF/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 02 12:09:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBE6j-0001mJ-Sl for secsh-archive@megatron.ietf.org; Fri, 02 Sep 2005 12:09: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 MAA15676 for ; Fri, 2 Sep 2005 12:09:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6169463B2FF; Fri, 2 Sep 2005 16:09:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id AE00E63B2F5 for ; Fri, 2 Sep 2005 16:09:24 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 02 Sep 2005 09:09:25 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j82G9IQM004524 for ; Fri, 2 Sep 2005 09:09:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-03.txt Date: Fri, 2 Sep 2005 09:14:19 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905D3EBB9@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-03.txt Thread-Index: AcWvwQLoyAumXUOjQjicDwGThI6DEwAFulNg From: "Salowey, Joe" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable =20 > There is an ambiguity here over whether the prohibition is of=20 > overriding any cached host key for this session, or merely of=20 > permanently replacing the cached host key. >=20 > Assuming both should be disallowed, "overwrite" should be=20 > changed to "override" throughout. >=20 [Joe] Yes. The intent is not to automatically "override". I think this change should be made=20 > | 3.2 SFTP Parameters > [...] > | typecode > |=20 > | The typecode identifies the type of file which=20 > determines how it > | will be treated. [...] >=20 > No default behaviour is specified for the case where the=20 > typecode is not present. This could lead to interoperability=20 > problems similar to those which FTP has, where some clients=20 > default to ASCII mode, and others to binary. >=20 > I think that "i" (no conversion) is an appropriate default in=20 > the absence of further information; it's supported by all=20 > filexfer implementations, and in any case is the "safe" thing=20 > to do if nothing is known about the file. >=20 > I hesitate to mandate this as a default, however;=20 > implementations should probably be free to use the=20 > "text-hint" attribute to determine an appropriate transfer=20 > mode for the file, and also to open directories in "d" mode. >=20 > How about the following text (new paragraph after the one above)?: >=20 > In the absence of this parameter, files SHOULD be transmitted as > if "i" had been specified. However, information from the server > (such as the "text-hint" attribute) MAY be used to select an > alternative mode. > [Joe] Thanks for the text, I think it looks good.=20 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 03 10:12:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYkv-0007cu-Qy for secsh-archive@megatron.ietf.org; Sat, 03 Sep 2005 10:12: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 KAA07641 for ; Sat, 3 Sep 2005 10:12:27 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1AA4263B25B; Sat, 3 Sep 2005 14:12:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by mail.netbsd.org (Postfix) with ESMTP id 680C963B1A3 for ; Sat, 3 Sep 2005 14:12:23 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from virgo.cus.cam.ac.uk ([131.111.8.20]:54013) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1EBYkn-0004C8-U8 (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Sat, 03 Sep 2005 15:12:21 +0100 Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.52) id 1EBYkn-0003IE-0w for ietf-ssh@netbsd.org; Sat, 03 Sep 2005 15:12:21 +0100 Date: Sat, 3 Sep 2005 15:12:20 +0100 (BST) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Server for diffie-hellman-group-exchange-sha256? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Does anyone have a convenient server implementation of the new diffie-hellman-group-exchange-sha256 method from -dh-group-exchange-05? I think I've implemented it for PuTTY, but I'd like to test the code at least minimally. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 04 06:59:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBsDP-0000Su-EI for secsh-archive@megatron.ietf.org; Sun, 04 Sep 2005 06:59: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 GAA02387 for ; Sun, 4 Sep 2005 06:59:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1197863B44F; Sun, 4 Sep 2005 10:59:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id DACAD63B188 for ; Sun, 4 Sep 2005 10:59:01 +0000 (UTC) Received: from [172.29.84.18] (unknown [172.29.84.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Damien Miller", Issuer "mindrot.org root CA" (verified OK)) by mail.mindrot.org (Postfix) with ESMTP id 0AAA417E604; Sun, 4 Sep 2005 20:59:00 +1000 (EST) Message-ID: <431AD373.6010403@mindrot.org> Date: Sun, 04 Sep 2005 20:58:59 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050801) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris CC: ietf-ssh@NetBSD.org Subject: Re: Server for diffie-hellman-group-exchange-sha256? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ben Harris wrote: > Does anyone have a convenient server implementation of the new > diffie-hellman-group-exchange-sha256 method from -dh-group-exchange-05? > I think I've implemented it for PuTTY, but I'd like to test the code at > least minimally. http://bugzilla.mindrot.org/show_bug.cgi?id=1023 has a patch for OpenSSH. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 04 10:58:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBvwu-0006HW-Te for secsh-archive@megatron.ietf.org; Sun, 04 Sep 2005 10:58: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 KAA10399 for ; Sun, 4 Sep 2005 10:58:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3F94D63B168; Sun, 4 Sep 2005 14:56:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-9.csi.cam.ac.uk (ppsw-9.csi.cam.ac.uk [131.111.8.139]) by mail.netbsd.org (Postfix) with ESMTP id 7ED7863B126 for ; Sun, 4 Sep 2005 14:56:35 +0000 (UTC) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from virgo.cus.cam.ac.uk ([131.111.8.20]:33464) by ppsw-9.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtp id 1EBvv3-00086f-U2 (Exim 4.51) for ietf-ssh@netbsd.org (return-path ); Sun, 04 Sep 2005 15:56:29 +0100 Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.52) id 1EBvuz-00070F-P3; Sun, 04 Sep 2005 15:56:25 +0100 Date: Sun, 4 Sep 2005 15:56:25 +0100 (BST) From: Ben Harris To: Damien Miller cc: ietf-ssh@NetBSD.org Subject: Re: Server for diffie-hellman-group-exchange-sha256? In-Reply-To: <431AD373.6010403@mindrot.org> Message-ID: References: <431AD373.6010403@mindrot.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sun, 4 Sep 2005, Damien Miller wrote: > Ben Harris wrote: > > Does anyone have a convenient server implementation of the new > > diffie-hellman-group-exchange-sha256 method from -dh-group-exchange-05? > > I think I've implemented it for PuTTY, but I'd like to test the code at > > least minimally. > > http://bugzilla.mindrot.org/show_bug.cgi?id=1023 has a patch for OpenSSH. Thank you. It took a bit of effort to get the patch to go in Portable OpenSSH on NetBSD 1.6, but once I sorted that out, PuTTY connected first time, so tonight's development snapshot of PuTTY will support the new mode. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 04 13:08:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBxyc-0003IU-1s for secsh-archive@megatron.ietf.org; Sun, 04 Sep 2005 13:08: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 NAA14432 for ; Sun, 4 Sep 2005 13:08:14 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6A86863B1EB; Sun, 4 Sep 2005 17:05:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from av-tac-sj.cisco.com (firestar.cisco.com [171.68.227.75]) by mail.netbsd.org (Postfix) with ESMTP id D1BC463B10A for ; Sun, 4 Sep 2005 17:05:23 +0000 (UTC) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost [127.0.0.1]) by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j84H5DZ03774; Sun, 4 Sep 2005 10:05:13 -0700 (PDT) Received: from [10.21.104.21] (sjc-vpnasa1-21.cisco.com [10.21.104.21]) by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j84H4fn24762; Sun, 4 Sep 2005 10:04:42 -0700 (PDT) Message-ID: <431B2929.4060205@cisco.com> Date: Sun, 04 Sep 2005 10:04:41 -0700 From: Phillip Remaker User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman CC: Brian E Carpenter , galb-list@vandyke.com, Elwyn Davies , ietf-ssh@NetBSD.org, IESG Subject: Re: DISCUSS: draft-ietf-secsh-break-04 References: <43146D31.8060303@dial.pipex.com> <4315620D.1040206@zurich.ibm.com> <4315AED4.7040104@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>>"Phillip" == Phillip Remaker writes: >>>>>> >>>>>> > > Phillip> Good point. I'm ambivalent, but I will copy ietf-ssh to > Phillip> see what the opinion of the people who have already > Phillip> developed the protoype code think. > >I did so yesterday and my reading of the consensus of that list is >that I will add an rfc editor note removing the possibility that the >break length field is absent. > > I concur. Good catch, thanks. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 05 13:39:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECKwE-0004Yk-QT for secsh-archive@megatron.ietf.org; Mon, 05 Sep 2005 13:39: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 NAA26630 for ; Mon, 5 Sep 2005 13:39:20 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 402DD63B1DA; Mon, 5 Sep 2005 17:36:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from maya.nslk.com (maya.nslk.com [216.74.99.254]) by mail.netbsd.org (Postfix) with ESMTP id BAE2563B110 for ; Mon, 5 Sep 2005 17:36:01 +0000 (UTC) Received: from nobody by maya.nslk.com with local (Exim 4.50) id 1E9nok-0003PX-3G for ietf-ssh@netbsd.org; Mon, 29 Aug 2005 13:53:10 -0400 To: ietf-ssh@NetBSD.org Subject: * * * Please Verify & Update Your PayPal Account * * * Message-ID: <1125337990.21609.qmail@paypal.com> From: "PayPal" Content-Type: text/html
PayPal

Security Center Advisory!

We recently noticed one or more attempts to log in to your PayPal account from a foreign IP address and we have reasons to belive that your account was hijacked by a third party without your authorization. If you recently accessed your account while traveling, the unusual log in attempts may have been initiated by you.

If you are the rightful holder of the account you must click the link below and then complete all steps from the following page as we try to verify your identity.

Click here to verify your account




If you choose to ignore our request, you leave us no choise but to temporaly suspend your account.

Thank you for using PayPal! The PayPal Team
Please do not reply to this e-mail. Mail sent to this address cannot be answered. For assistance, log in to your PayPal account and choose the "Help" link in the footer of any page.

To receive email notifications in plain text instead of HTML, update your preferences here.

PayPal Email ID PP697
Protect Your Account Info

Make sure you never provide your password to fraudulent persons.

PayPal automatically encrypts your confidential information using the Secure Sockets Layer protocol (SSL) with an encryption key length of 128-bits (the highest level commercially available).

PayPal will never ask you to enter your password in an email.

For more information on protecting yourself from fraud, please review our Security Tips at http://www.paypal.com/securitytips
Protect Your Password
You should never give your PayPal password to anyone, including PayPal employees.
Message-Id: From: Nobody Date: Mon, 29 Aug 2005 13:53:10 -0400 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - maya.nslk.com X-AntiAbuse: Original Domain - netbsd.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - maya.nslk.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 14:07:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EChrM-0004FX-TA for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 14:07:53 -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 OAA10892 for ; Tue, 6 Sep 2005 14:07:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F64863B19F; Tue, 6 Sep 2005 18:07:40 +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 2F3E863B17F for ; Tue, 6 Sep 2005 18:07:39 +0000 (UTC) Received: (qmail 23882 invoked by uid 0); 6 Sep 2005 18:00:53 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.121) by woodstock.binhost.com with SMTP; 6 Sep 2005 18:00:53 -0000 Message-Id: <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 06 Sep 2005 14:00:55 -0400 To: Bill Sommerfeld From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <1125610205.9587.81.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill: I decided not to respond immediately to your note. Instead, I thought about it over the weekend. Here is my argument for selecting at least one of these modes as REQUIRED. We know that the current REQUIRED algorithm is not as robust as we would like. It is not so flawed that we need to rush to a new one, but we should plan an orderly migration. By making one of these algorithms REQUIRED, we are telling implementors where we are going. I would like to see AES128-CTR be REQUIRED. Russ At 05:30 PM 9/1/2005, Bill Sommerfeld wrote: > All of the encryption modes described in this document are >RECOMMENDED > or OPTIONAL. Why isn't one of them REQUIRED? > >This has been discussed within the working group, and there is little >support for and strong opposition at this point to defining one >algorithm as REQUIRED. (My personal view on this point puts me in the >clear minority of those who have spoken up so far). > >It appears that a document listing one as REQUIRED would be unlikely to >have the consensus of the WG. > >I'll collect the arguments made against it so far: > >argument 1: > > It's one thing to say "if you support ssh then you MUST support > 3des-cbc". It's quite another to say "if you support 3des-ctr then >you > MUST also support aes128-ctr" or vice versa. The former insures that >ssh > implementations will be interoperable; the latter does not appear to >me > to add any value. > >argument 2: > > Because it's not appropriate; newmodes is not so much a thing to > implement or conform to in its own right as it is a collection of > individual things to implement or conform to. Thus, making (say) > des3-ctr REQUIRED is really just saying "you cannot claim to do > newmodes if you don't do des3-ctr", but since claiming to implement > newmodes is not a useful thing (as opposed to claiming > implementation of particular things defined in newmodes), this is > not useful. > >argument 3: (against my proposed aes128-ctr REQUIRED): > > I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH > implementations are required to have 3DES code around anyway to >support > 3des-cbc, so anyone implementing newmodes can put in 3des-ctr support > trivially, whereas aes128-ctr might be a lot more effort or even > impossible (imagine a small implementation without room for both 3DES >and > AES). > > This does raise the question of how to arrange a transition to AES >(or > whatever) in the longer term, but I don't think it should be done on >the > back of newmodes. > ... > Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all > that I think it's unnecessary. I _am_ opposed to making aes128-ctr > REQUIRED. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 14:37:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECiK9-0000di-QS for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 14:37: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 OAA12327 for ; Tue, 6 Sep 2005 14:37:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F199863B28C; Tue, 6 Sep 2005 18:37:33 +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 4C23663B16E for ; Tue, 6 Sep 2005 18:37:33 +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 j86IbOHT021151; Tue, 6 Sep 2005 11:37:24 -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 j86IbNUj025061; Tue, 6 Sep 2005 14:37:24 -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 j86IbNAK001692; Tue, 6 Sep 2005 14:37:23 -0400 (EDT) Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Russ Housley Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1126031842.29672.33.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 06 Sep 2005 14:37:23 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-09-06 at 14:00, Russ Housley wrote: > We know that the current REQUIRED algorithm is not as robust as we would > like. It is not so flawed that we need to rush to a new one, but we should > plan an orderly migration. By making one of these algorithms REQUIRED, we > are telling implementors where we are going. > > I would like to see AES128-CTR be REQUIRED. "me too." Anyone with an opinion on this topic who has *not* yet spoken up should do so sooner rather than later. Please keep Russ CC:ed in this discussion. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 16:13:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECjor-0007LQ-Ms for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 16:13: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 QAA22526 for ; Tue, 6 Sep 2005 16:13:23 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C86C163B12E; Tue, 6 Sep 2005 20:13:21 +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 181A863B103 for ; Tue, 6 Sep 2005 20:13:21 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ECjoj-0008Ol-VH; Tue, 06 Sep 2005 16:13:17 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'Secure Shell (SSH) Session Channel Break Extension' to Proposed Standard Message-Id: Date: Tue, 06 Sep 2005 16:13:17 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following document: - 'Secure Shell (SSH) Session Channel Break Extension ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-break-04.txt Technical Summary The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session. Working Group Summary The consensus of the working group was to publish this as a standards-track document. Protocol Quality This extension is a replacement for vendor-specific hacks which provide the same functionality. There are known to be multiple interoperable implementations of this extension and substantial vendor interest. This specification was reviewed by Sam Hartman for the IESG. Note to RFC Editor Section 1: add reference old: "The Secure Shell (SSH) session channel" new: "The Secure Shell (SSH) [5] session channel" Section 3: The parameter is always present old: BREAK-length parameter is 0 or not present, the BREAK SHOULD be new: BREAK-length parameter is 0, the BREAK SHOULD be From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 16:36:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkBd-0005QA-U8 for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 16:36:58 -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 QAA26587 for ; Tue, 6 Sep 2005 16:36:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4570163B17F; Tue, 6 Sep 2005 20:36:22 +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 32B8963B15F for ; Tue, 6 Sep 2005 20:36:21 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ECkB2-00017d-KI; Tue, 06 Sep 2005 16:36:20 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol' to Proposed Standard Message-Id: Date: Tue, 06 Sep 2005 16:36:20 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following document: - 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-10.txt Technical Summary This document describes an extension to the Secure Shell protocol allowing the use of GSSAPI security services for authentication and key exchange. It also defines a null hostkey algorithm to allow ssh to be used by systems that do not have a host key. Working Group Summary There was smooth consensus in the working group to publish this as a Proposed Standard Protocol Quality The WG chair is aware of multiple interoperable implementations. This document has been reviewed by Sam Hartman for the IESG. Note to RFC Editor Insert in section 3.2 just before the last paragraph which begins "The client may at any time.": Note that the 'username' value is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the username and determines whether the client is authorized based on his GSSAPI credentials In particular, the encoding used by the system for user names is a matter for the ssh server implementation. However, if the client reads the username in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the username to ISO-10646 UTF-8 before transmitting, and the server MUST convert the username to the encoding used on that system for user names. Any normalization or other preparation of names is done by the ssh server based on the requirements of the system, and is outside the scope of SSH. SSH implementations which maintain private user databases SHOULD prepare user names as described by [RFC4013]. Add to the end of section 7.1: new: Because the GSSAPI mechanism uses the targ_name to authenticate the server's identity, it is important that it be determined in a secure fashion. One common way to do this is to construct the targ_name from the hostname as typed by the user; unfortunately, because some GSSAPI mechanisms do not canonicalize hostnames, it is likely that this technique will fail if the user has not typed a fully-qualified, canonical hostname. Thus, implementors may wish to use other methods, but should take care to insure they are secure. For example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, or an IP address to a hostname, since an attacker can modify the mapping and impersonate the server. Implementations of mechanisms conforming to this document MUST NOT use the results of insecure DNS queries to construct the targ_name. Clients MAY make use of a mapping provided by local configuration or use other secure means to determine the targ_name to be used. If a client system is unable to securely determine which targ_name to use, then it SHOULD NOT use this mechanism. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 17:06:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkeX-00046W-4i for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 17:06:49 -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 RAA29101 for ; Tue, 6 Sep 2005 17:06:46 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4A3E963B17F; Tue, 6 Sep 2005 21:06:46 +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 A731B63B12E for ; Tue, 6 Sep 2005 21:06:45 +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 j86L6f2B023430; Tue, 6 Sep 2005 14:06:42 -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 j86L6fUj009961; Tue, 6 Sep 2005 17:06:41 -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 j86L6ehq003611; Tue, 6 Sep 2005 17:06:41 -0400 (EDT) Subject: Re: I-D ACTION:draft-ietf-secsh-publickeyfile-09.txt From: Bill Sommerfeld To: Jacob Nevins Cc: ietf-ssh@NetBSD.org In-Reply-To: <20050902143249.GK19805@chiark.greenend.org.uk> References: <20050902143249.GK19805@chiark.greenend.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1126040800.29672.63.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 06 Sep 2005 17:06:40 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-09-02 at 10:32, Jacob Nevins wrote: > [I realise that these comments are rather late as this document is on > its way into the IESG. I don't think any of these comments should hold > up publication, but if the document is respun for other reasons it > would be nice if they were taken into account.] It's currently sitting in "Publication Requested" state waiting for Sam to have time to review it. I believe the comments you've made are reasonable editorial corrections, and should be included with any respin done (if any) for the sake of AD review. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 17:09:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECkhT-0004Wr-Vp for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 17:09:52 -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 RAA29369 for ; Tue, 6 Sep 2005 17:09:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 779AF63B2C4; Tue, 6 Sep 2005 21:09:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id 84F2A63B12E for ; Tue, 6 Sep 2005 21:09:46 +0000 (UTC) Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 06 Sep 2005 23:08:44 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j86L8eVP001249; Tue, 6 Sep 2005 23:08:40 +0200 (MEST) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id WAA29178; Tue, 6 Sep 2005 22:08:39 +0100 (BST) Date: Tue, 6 Sep 2005 22:08:39 +0100 From: Derek Fawcus To: Bill Sommerfeld Cc: Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <20050906220839.A19948@mrwint.cisco.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <1126031842.29672.33.camel@thunk>; from sommerfeld@sun.com on Tue, Sep 06, 2005 at 02:37:23PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 06, 2005 at 02:37:23PM -0400, Bill Sommerfeld wrote: > On Tue, 2005-09-06 at 14:00, Russ Housley wrote: > > We know that the current REQUIRED algorithm is not as robust as we would > > like. It is not so flawed that we need to rush to a new one, but we should > > plan an orderly migration. By making one of these algorithms REQUIRED, we > > are telling implementors where we are going. > > > > I would like to see AES128-CTR be REQUIRED. > > > "me too." > > > Anyone with an opinion on this topic who has *not* yet spoken up should > do so sooner rather than later. Please keep Russ CC:ed in this > discussion. Oh all right the :-) I tend to agree - one of the AES ciphers should be required. So given that CTR are to be preferred over CBC I'd also support AES128-CTR as REQUIRED. DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 18:48:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmEU-0001b1-Sn for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 18:48: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 SAA06673 for ; Tue, 6 Sep 2005 18:47:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C68FE63B1FA; Tue, 6 Sep 2005 22:47:56 +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 1F63E63B11B for ; Tue, 6 Sep 2005 22:47:56 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1ECmEM-000779-00; Tue, 06 Sep 2005 23:47:54 +0100 From: Ben Harris To: housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> Organization: Linux Unlimited Message-Id: Date: Tue, 06 Sep 2005 23:47:54 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> you write: >I decided not to respond immediately to your note. Instead, I thought >about it over the weekend. Here is my argument for selecting at least one >of these modes as REQUIRED. Can we just get confirmation: Is your intention that this should be required for all SSH implementations, required for all implementations that implement any mode defined by newmodes, or required for all implementations that claim to implement newmodes as a whole? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 19:34:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECmxt-0006zs-P7 for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 19:34:58 -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 TAA15819 for ; Tue, 6 Sep 2005 19:34:54 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F2A3B63B259; Tue, 6 Sep 2005 23:34:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 3904E63B235 for ; Tue, 6 Sep 2005 23:34:54 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 00BDE17E605; Wed, 7 Sep 2005 09:34:51 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id F328617E604; Wed, 7 Sep 2005 09:34:51 +1000 (EST) Date: Wed, 7 Sep 2005 09:34:51 +1000 (EST) From: Damien Miller To: Bill Sommerfeld cc: Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <1126031842.29672.33.camel@thunk> Message-ID: References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 6 Sep 2005, Bill Sommerfeld wrote: >> I would like to see AES128-CTR be REQUIRED. I would prefer not to have any required. Failing that aes128-ctr would be my choice for a REQUIRED. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 21:35:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECoqG-0000xb-P1 for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 21:35: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 VAA19700 for ; Tue, 6 Sep 2005 21:35:10 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3880D63B22C; Wed, 7 Sep 2005 01:34:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from guinness.cs.stevens.edu (guinness.cs.stevens-tech.edu [155.246.89.8]) by mail.netbsd.org (Postfix) with ESMTP id 278ED63B203 for ; Wed, 7 Sep 2005 01:34:58 +0000 (UTC) Received: from murky.cs.stevens.edu (murky.cs.stevens-tech.edu [155.246.89.22]) by guinness.cs.stevens.edu (Postfix) with ESMTP id 9B10A141647; Tue, 6 Sep 2005 21:34:56 -0400 (EDT) Received: by murky.cs.stevens.edu (Postfix, from userid 3330) id 60EB3EC61E; Tue, 6 Sep 2005 21:34:56 -0400 (EDT) Date: Tue, 6 Sep 2005 21:34:56 -0400 From: Thor Simon To: Bill Sommerfeld , housley@vigilsec.com, ietf-ssh@NetBSD.org, hartmans-ietf@mit.edu Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <20050907013456.GA29433@cs.stevens.edu> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1126031842.29672.33.camel@thunk> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Sep 06, 2005 at 02:37:23PM -0400, Bill Sommerfeld wrote: > On Tue, 2005-09-06 at 14:00, Russ Housley wrote: > > We know that the current REQUIRED algorithm is not as robust as we would > > like. It is not so flawed that we need to rush to a new one, but we should > > plan an orderly migration. By making one of these algorithms REQUIRED, we > > are telling implementors where we are going. > > > > I would like to see AES128-CTR be REQUIRED. > > > "me too." > > > Anyone with an opinion on this topic who has *not* yet spoken up should > do so sooner rather than later. Please keep Russ CC:ed in this > discussion. My opinion is that AES-CBC and AES-CTR ought to be REQUIRED. I think that the people objecting that it might be too hard to add support for additional cipher should be, if they're speaking of their own implementations, ashamed of themselves -- or if they're speaking of some hypothetical "other" implementation, brought back in touch with reality: adding support for another common cipher is just not difficult, and for those who happen to be on the certifications bandwagon (e.g. FIPS 140), can be very easily stuffed in to the next round of recertifications, since they're not allowed to make *any* changed to their product without recertifying in any event. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 21:40:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECovg-0002BI-D9 for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 21:40: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 VAA19854 for ; Tue, 6 Sep 2005 21:40:46 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8630263B203; Wed, 7 Sep 2005 01:40:44 +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 7C76463B102 for ; Wed, 7 Sep 2005 01:40:43 +0000 (UTC) Received: (qmail 20835 invoked by uid 0); 7 Sep 2005 01:40:33 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.121) by woodstock.binhost.com with SMTP; 7 Sep 2005 01:40:33 -0000 Message-Id: <6.2.1.2.2.20050906213910.05906110@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 06 Sep 2005 21:40:39 -0400 To: Ben Harris , ietf-ssh@NetBSD.org From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list In the near term, I believe that it should be REQUIRED for implementations of the newmodes document. However, I think this is an indication of where the group is going to replace the less robust cipher that is currently REQUIRED for all SSH implementations. Russ At 06:47 PM 9/6/2005, Ben Harris wrote: >In article <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> you write: > >I decided not to respond immediately to your note. Instead, I thought > >about it over the weekend. Here is my argument for selecting at least one > >of these modes as REQUIRED. > >Can we just get confirmation: Is your intention that this should be required >for all SSH implementations, required for all implementations that implement >any mode defined by newmodes, or required for all implementations that claim >to implement newmodes as a whole? > >-- >Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 06 22:38:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECppc-0005yb-7U for secsh-archive@megatron.ietf.org; Tue, 06 Sep 2005 22:38: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 WAA22303 for ; Tue, 6 Sep 2005 22:38:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2328363B203; Wed, 7 Sep 2005 02:38:30 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 4915D63B102 for ; Wed, 7 Sep 2005 02:38:29 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 4B040342A3; Wed, 7 Sep 2005 14:38:28 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00542-12; Wed, 7 Sep 2005 14:38:28 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 9A83F340A0; Wed, 7 Sep 2005 14:38:26 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C8A7B37751; Wed, 7 Sep 2005 14:38:26 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1ECppW-0005Zp-00; Wed, 07 Sep 2005 14:38:30 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: hartmans-ietf@mit.edu, housley@vigilsec.com, ietf-ssh@NetBSD.org, sommerfeld@sun.com, tls@cs.stevens.edu Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <20050907013456.GA29433@cs.stevens.edu> Message-Id: Date: Wed, 07 Sep 2005 14:38:30 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Thor Simon writes: >My opinion is that AES-CBC and AES-CTR ought to be REQUIRED. I think that >the people objecting that it might be too hard to add support for additional >cipher should be, if they're speaking of their own implementations, ashamed >of themselves -- or if they're speaking of some hypothetical "other" >implementation, brought back in touch with reality: adding support for >another common cipher is just not difficult, So they can just go out and update their deployed crypto hardware using a strong magnifying glass and very small tweezers or something? AES-CTR is problematic because support for it in crypto hardware is practically nonexistent (it's only just appeared as a recent update to PKCS #11, and I'm not aware of any hardware that supports it), and it could be years (if ever) before it's supported to a useful level. CBC OTOH is mainstream, anything that does AES does CBC. So my preference would be to have none mandatory (for the reasons given earlier), but if any are REQUIRED then only AES-CBC. In fact I wouldn't complain about MUST AES-CBC if people insist. (Is there such a thing as POSSIBLY REQUIRED for AES-CTR? If it ends up with practically no HW support, like OAEP and some other "good idea but no killer app" mechanisms have in the past, then directing people to it via REQUIRED isn't doing anyone much of a service). Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 01:32:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECsY6-0002FA-4F for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 01:32: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 BAA29900 for ; Wed, 7 Sep 2005 01:32:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C863D63B1E1; Wed, 7 Sep 2005 05:32:36 +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 8713663B170 for ; Wed, 7 Sep 2005 05:32:35 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA00971; Wed, 7 Sep 2005 01:32:34 -0400 (EDT) From: der Mouse Message-Id: <200509070532.BAA00971@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: Wed, 7 Sep 2005 01:27:06 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <20050907013456.GA29433@cs.stevens.edu> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <20050907013456.GA29433@cs.stevens.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > My opinion is that AES-CBC and AES-CTR ought to be REQUIRED. I think > that the people objecting that it might be too hard to add support > for additional cipher should be, if they're speaking of their own > implementations, ashamed of themselves -- Consider something like an implementation on a 68HC11 (an 8-bit embedded controller I once had some brushes with), where doing ssh at all, even with just DES, is a tight squeeze, and shoehorning in Rijndael too is simply impossible. > or if they're speaking of some hypothetical "other" implementation, > brought back in touch with reality: adding support for another common > cipher is just not difficult, You are thinking of a rather restricted subclass of ssh implementations when you consider that "reality": probably, implementations on "large" hardware (32-bit CPUs, multiple megabytes of memory). Speaking strictly of such implementations, I agree with you - but I do not believe they are all there 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 Wed Sep 07 01:41:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECsgD-0003pQ-6T for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 01:41: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 BAA00114 for ; Wed, 7 Sep 2005 01:41:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B843763B1E1; Wed, 7 Sep 2005 05:41:00 +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 A4CE563B170 for ; Wed, 7 Sep 2005 05:40:59 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA01009; Wed, 7 Sep 2005 01:40:58 -0400 (EDT) From: der Mouse Message-Id: <200509070540.BAA01009@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: Wed, 7 Sep 2005 01:33:23 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <6.2.1.2.2.20050906213910.05906110@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <6.2.1.2.2.20050906213910.05906110@mail.binhost.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Can we just get confirmation: Is your intention that this should be >> required for all SSH implementations, required for all >> implementations that implement any mode defined by newmodes, or >> required for all implementations that claim to implement newmodes as >> a whole? > In the near term, I believe that it should be REQUIRED for > implementations of the newmodes document. But what is an "implementation[] of the newmodes document"? (1) Any ssh implementation after newmodes reaches RFC status? (2) Any ssh implementation that supports any of the newmodes-specified ciphers? (3) Any ssh implementation whose documentation claims support for any of the things specified in newmodes? (4) Any ssy implementation whose documentation claims support for newmodes, without specifying exactly what portions of newmodes it supports? (5) Some mix of the above? (6) Something else? This makes a difference to me as an implementor, and apparently to Ben as well (though I suspect our reactions to "bad" meanings would be different). It's what I was trying to point out when I wrote that newmodes qua newmodes was not a useful thing to "implement", that it is really an umbrella under which to gather together a number of useful things - a way to avoid a blizzard of 15 different drafts, one for each cipher and each rekeying recommendation. /~\ 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 Wed Sep 07 02:58:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECtsu-0003mY-PS for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 02:58: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 CAA00968 for ; Wed, 7 Sep 2005 02:58:15 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E8C463B287; Wed, 7 Sep 2005 06:58:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 9668F63B22E for ; Wed, 7 Sep 2005 06:58:11 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 8B1E1B40A; Wed, 7 Sep 2005 08:56:55 +0200 (CEST) Message-ID: <431E8F50.4050403@siliconcircus.com> Date: Wed, 07 Sep 2005 08:57:20 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> In-Reply-To: <1126031842.29672.33.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: > > Anyone with an opinion on this topic who has *not* yet spoken up should > do so sooner rather than later. Please keep Russ CC:ed in this > discussion. Having read various other comments and thought about it a bit, my favoured solution is to REQUIRE 3des-ctr if *any* of the newmodes ciphers are implemented. Additionally, would a conditional REQUIRE be possible for aes128-ctr? Something along the lines of "we'd really, really like you to implement this, but we recognize that not everyone's hardware is going to be big enough to squeeze in both 3des and aes implementations". If that's not possible, my vote goes for just requiring 3des-ctr, since it's the thing that it's most likely to be possible to support across all implementations. In an ideal world, I'd require aes256-ctr (and none of the others), but practicality leads me instead to the above approach... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 03:37:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuUq-0003cO-7x for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 03:37: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 DAA02574 for ; Wed, 7 Sep 2005 03:37:26 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4FCF263B2A0; Wed, 7 Sep 2005 07:37:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 8FF7263B298 for ; Wed, 7 Sep 2005 07:37:23 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id BA28F34452; Wed, 7 Sep 2005 19:37:18 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24923-03; Wed, 7 Sep 2005 19:37:18 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id A842734303; Wed, 7 Sep 2005 19:37:17 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6F3FD37754; Wed, 7 Sep 2005 19:37:17 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1ECuUl-0006Ir-00; Wed, 07 Sep 2005 19:37:23 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jon@siliconcircus.com, sommerfeld@sun.com Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: hartmans-ietf@mit.edu, housley@vigilsec.com, ietf-ssh@NetBSD.org In-Reply-To: <431E8F50.4050403@siliconcircus.com> Message-Id: Date: Wed, 07 Sep 2005 19:37:23 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: >Having read various other comments and thought about it a bit, my favoured >solution is to REQUIRE 3des-ctr if *any* of the newmodes ciphers are >implemented. I think 3DES-CTR is even less likely to be supported in hardware than AES-CTR, for AES it's a new(ish) cipher so people may at some point implement trendy new modes, but 3DES has been consigned to the legacy bin and is unlikely to be updated at any point. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 03:54:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECuks-0006gk-JU for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 03:54: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 DAA03286 for ; Wed, 7 Sep 2005 03:54:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 242DB63B298; Wed, 7 Sep 2005 07:53:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 4FCE563B2A4 for ; Wed, 7 Sep 2005 07:53:58 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 3D01A4C9EE; Wed, 7 Sep 2005 09:52:42 +0200 (CEST) Message-ID: <431E9C61.60903@siliconcircus.com> Date: Wed, 07 Sep 2005 09:53:05 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: sommerfeld@sun.com, hartmans-ietf@mit.edu, housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Jon Bright writes: > > >>Having read various other comments and thought about it a bit, my favoured >>solution is to REQUIRE 3des-ctr if *any* of the newmodes ciphers are >>implemented. > > I think 3DES-CTR is even less likely to be supported in hardware than AES-CTR, > for AES it's a new(ish) cipher so people may at some point implement trendy > new modes, but 3DES has been consigned to the legacy bin and is unlikely to be > updated at any point. So long as the hardware supports 3DES (or even DES) ECB, it shouldn't be more than a few instructions to get 3DES-CTR. As far as I'm aware, there's plenty of hardware that does DES ECB... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 12:29:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2o6-00024n-6M for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 12:29:54 -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 MAA00471 for ; Wed, 7 Sep 2005 12:29:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7A43A63B2DF; Wed, 7 Sep 2005 16:29: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 773EC63B2D5 for ; Wed, 7 Sep 2005 16:29:48 +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 7848315; Wed, 07 Sep 2005 10:29:47 -0600 Message-ID: <431F1788.50407@vandyke.com> Date: Wed, 07 Sep 2005 10:38:32 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Russ Housley CC: Bill Sommerfeld , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.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 Russ Housley wrote: > Bill: > > I decided not to respond immediately to your note. Instead, I thought > about it over the weekend. Here is my argument for selecting at least > one of these modes as REQUIRED. > > We know that the current REQUIRED algorithm is not as robust as we would > like. It is not so flawed that we need to rush to a new one, but we > should plan an orderly migration. By making one of these algorithms > REQUIRED, we are telling implementors where we are going. > > I would like to see AES128-CTR be REQUIRED. Rather than making newmodes specify a REQUIRED cipher as an indication of direction, we could indicate it directly using text of some form: It is widely recognized that the 3des-cbc cipher mode that is required by [TRANS] is a relatively weak cipher; however, other alternatives (such as the aes128-ctr mode described in this document) do not yet have the same level of common hardware based support as 3des-cbc or they may be too expensive to implement in hardware for some applications. As such, no cipher mode described in this document is REQUIRED; however, implementations SHOULD support at least aes128-ctr. At some future point, aes128-ctr may become a required cipher. This would be my preferred solution. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 14:11:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED4Nz-00039i-3c for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 14:11: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 OAA06685 for ; Wed, 7 Sep 2005 14:11:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7109163B249; Wed, 7 Sep 2005 18:10:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id CF5E963B22C for ; Wed, 7 Sep 2005 18:10:56 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 07 Sep 2005 11:10:57 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j87IAq4v016162; Wed, 7 Sep 2005 11:10:52 -0700 (PDT) Date: Wed, 7 Sep 2005 11:10:54 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org cc: anil@recoil.org Subject: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt In-Reply-To: <20050814060350.GA24486@fork.recoil.org> Message-ID: References: <20050814060350.GA24486@fork.recoil.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I've updated the drafts to get all of the messages indented the same way. I also found that there were some occurances of "recipient_channel" but more of "recipient channel" (mostly in CONNECT) so I harmonized them. The new set of IDs are here: http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/ Please look them over. If no one finds any problems then I'll let the RFC Editor know that a few more non-substantiative fixes were made and that they can use these drafts to create the RFCs. Thanks, Chris On Sun, 14 Aug 2005, Anil Madhavapeddy wrote: > In Section 6.10 (Returning Exit Status) of draft-ietf-secsh-connect-25.txt, > the formatting of the "exit-signal" packet is different from the > rest and indented incorrectly. Breaks my spec-extraction regexp, > hence the motivation to point it out :) > > -- > Anil Madhavapeddy http://anil.recoil.org > University of Cambridge http://www.cl.cam.ac.uk > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 17:14:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7FC-0002B8-W4 for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 17:14: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 RAA22398 for ; Wed, 7 Sep 2005 17:14:08 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CE87963B394; Wed, 7 Sep 2005 21:14:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 0C97163B35D for ; Wed, 7 Sep 2005 21:14:03 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j87LE2DB001915 for ; Wed, 7 Sep 2005 15:14:02 -0600 (MDT) 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 j87LE1WB028265; Wed, 7 Sep 2005 17:14:01 -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 j87LE1T0008553; Wed, 7 Sep 2005 17:14:01 -0400 (EDT) Subject: draft-ietf-secsh-publickey-subsystem is now a guinea pig. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1126127641.6720.67.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Wed, 07 Sep 2005 17:14:01 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Yesterday I received a request from Russ and Bert Wijnen to nominate a document at or before WG Last Call as an experimental test of a slightly different document editing process. draft-ietf-secsh-publickey-subsystem seemed to be the right experimental subject. Here's what's going to happen: 1) Jon Bright will make edits to the .xml which are responsive to the comments received so far in the WG last call. 2) he will then forward the result to Bert, who will forward the document to the RFC editor. 3) the RFC editor will conduct a "real-time"-ish copyediting pass and send the document back to us in about a week. 4) The WG will review the copyediting changes and undo any which are not appropriate. 5) I then send the document on to the AD for review as normal. The theory is that, if successful, this will improve the quality of documents going through WG and IETF-wide Last Call and AD and IESG review, as well as reduce the post-IESG-approval latency of the RFC Editor. (currently running at about 7 months last I checked). If step (3) above stalls out we can pick up as normal and move on. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 17:53:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7qz-0003pm-Hd for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 17:53: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 RAA24107 for ; Wed, 7 Sep 2005 17:53:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 862C663B264; Wed, 7 Sep 2005 21:53:08 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id A1BBB63B1F7 for ; Wed, 7 Sep 2005 21:53:07 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa30641; 7 Sep 2005 17:52 EDT Date: Wed, 07 Sep 2005 17:52:38 -0400 From: Jeffrey Hutzelman To: Jon Bright , Bill Sommerfeld cc: Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> In-Reply-To: <431E8F50.4050403@siliconcircus.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> Originator-Info: login-token=Mulberry:01VGxxIb7U5pWgt+mih+qhkOveqEzboOrB4Z+Giuw=; 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 Wednesday, September 07, 2005 08:57:20 AM +0200 Jon Bright wrote: > Bill Sommerfeld wrote: >> >> Anyone with an opinion on this topic who has *not* yet spoken up should >> do so sooner rather than later. Please keep Russ CC:ed in this >> discussion. > > Having read various other comments and thought about it a bit, my > favoured solution is to REQUIRE 3des-ctr if *any* of the newmodes ciphers > are implemented. Why? What security or interoperability purpose would be served by such a requirement? > Additionally, would a conditional REQUIRE be possible > for aes128-ctr? Something along the lines of "we'd really, really like > you to implement this, but we recognize that not everyone's hardware is > going to be big enough to squeeze in both 3des and aes implementations". That's what SHOULD means. I really see no benefit to a requirement in which, if a particular algorithm is supported, then some other alternative algorithm must also be supported. I will note that RFC2119 says: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. So, please, show me either an interoperability need that is served or a potential for causing harm that is limited by making one encryption algorithm a prerequisite for another. Alternately, I'd like to echo der Mouse's question -- what does it mean to "implement newmodes" ? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 07 17:58:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED7wT-0005Ta-Cm for secsh-archive@megatron.ietf.org; Wed, 07 Sep 2005 17:58:53 -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 RAA24279 for ; Wed, 7 Sep 2005 17:58:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CDD1263B355; Wed, 7 Sep 2005 21:58:38 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 76B4C63B1F7 for ; Wed, 7 Sep 2005 21:58:37 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa30644; 7 Sep 2005 17:57 EDT Date: Wed, 07 Sep 2005 17:57:53 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , Russ Housley cc: Bill Sommerfeld , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <7D9E414F01713C5428D6DA74@sirius.fac.cs.cmu.edu> In-Reply-To: <431F1788.50407@vandyke.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <431F1788.50407@vandyke.com> Originator-Info: login-token=Mulberry:01h9udaPFDEtzTJhXpulnN1x5N1JMODxb0UMvNvVs=; 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 Wednesday, September 07, 2005 10:38:32 AM -0600 Joseph Galbraith wrote: > Russ Housley wrote: >> Bill: >> >> I decided not to respond immediately to your note. Instead, I thought >> about it over the weekend. Here is my argument for selecting at least >> one of these modes as REQUIRED. >> >> We know that the current REQUIRED algorithm is not as robust as we would >> like. It is not so flawed that we need to rush to a new one, but we >> should plan an orderly migration. By making one of these algorithms >> REQUIRED, we are telling implementors where we are going. >> >> I would like to see AES128-CTR be REQUIRED. > > Rather than making newmodes specify a REQUIRED cipher as an > indication of direction, we could indicate it directly using > text of some form: > > It is widely recognized that the 3des-cbc cipher mode that > is required by [TRANS] is a relatively weak cipher; however, > other alternatives (such as the aes128-ctr mode described > in this document) do not yet have the same level of common > hardware based support as 3des-cbc or they may be too > expensive to implement in hardware for some applications. > As such, no cipher mode described in this document > is REQUIRED; however, implementations SHOULD support > at least aes128-ctr. > > At some future point, aes128-ctr may become a required > cipher. > > This would be my preferred solution. Note that the AES and 3DES modes are already RECOMMENDED, which means the same thing as SHOULD. I agree that if we want to indicate direction, we should do so explicitly with text, rather than implicitly with a requirement. The other thing I think we could reasonably do is update the RECOMMENDED and REQUIRED algorithms in SSH-TRANS when it advances to draft, including adding a normative reference to newmodes. Of course, this would be possible only if there were interoperable implementations which met the new requirement. And, it doesn't really address Russ's comment today. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 02:21:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDFmm-00087u-Hc for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 02:21: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 CAA00849 for ; Thu, 8 Sep 2005 02:21:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5869163B122; Thu, 8 Sep 2005 06:21:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (drno.siliconcircus.com [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 3654663B117 for ; Thu, 8 Sep 2005 06:21:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 9578253FEA; Thu, 8 Sep 2005 08:21:16 +0200 (CEST) Message-ID: <431FD875.4050809@siliconcircus.com> Date: Thu, 08 Sep 2005 08:21:41 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Bill Sommerfeld , Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> In-Reply-To: <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > > > On Wednesday, September 07, 2005 08:57:20 AM +0200 Jon Bright > wrote: >> >> Having read various other comments and thought about it a bit, my >> favoured solution is to REQUIRE 3des-ctr if *any* of the newmodes ciphers >> are implemented. > > Why? What security or interoperability purpose would be served by such > a requirement? Security purpose: none. Interoperability: we (should) get a counter-mode cipher that's supported by anyone who supported any of the counter-mode ciphers. i.e. were the day to come and we deprecate (and eventually turn off) *-cbc, we still have interoperability. Waiting for the day that we want to turn *-cbc off to change the RECOMMENDED to a REQUIRE might be theoretically nice, but I don't view it as sane in practice. 3DES, I chose because 3DES is already required in the core drafts. Anyone who has 3DES/DES hardware, assuming it doesn't *just* do CBC, should be able to implement 3des-ctr. Anyone in a tiny embedded system who's implemented the core drafts should still be able to squeeze in 3des-ctr. >> Additionally, would a conditional REQUIRE be possible >> for aes128-ctr? Something along the lines of "we'd really, really like >> you to implement this, but we recognize that not everyone's hardware is >> going to be big enough to squeeze in both 3des and aes implementations". > > That's what SHOULD means. I was thinking of something a little stronger, but maybe no such thing exists. > I really see no benefit to a requirement in which, if a particular > algorithm is supported, then some other alternative algorithm must also > be supported. I will note that RFC2119 says: It indicates direction and achieves interoperability for the future. > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > So, please, show me either an interoperability need that is served or a > potential for causing harm that is limited by making one encryption > algorithm a prerequisite for another. If we don't have a REQUIRED cipher, then the day that the cbc ciphers are deprecated, we don't any longer have an interoperable cipher. > Alternately, I'd like to echo der Mouse's question -- what does it mean > to "implement newmodes" ? Implementing any cipher. Just because it says REQUIRED in a document, doesn't mean people are going to slavishly follow it. But if we say "you're putting in the effort to add (a) counter-mode cipher(s) to your implementation, please note that whatever cipher you choose (and maybe prefer in your keyex packets), you MUST also implement 3des-ctr, so that we have an interoperable cipher for the future", then we've at least done our best to keep interoperability. If people ignore our REQUIRED, well they might not be interoperable in future. Question back: if we don't set any of these ciphers to REQUIRED, what happens interoperability-wise when CBC gets deprecated? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 02:44:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDG8w-0004hi-Kt for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 02:44: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 CAA02397 for ; Thu, 8 Sep 2005 02:44:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 83F6263B424; Thu, 8 Sep 2005 06:44:14 +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 6950763B418 for ; Thu, 8 Sep 2005 06:44:13 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA19912; Thu, 8 Sep 2005 02:44:08 -0400 (EDT) From: der Mouse Message-Id: <200509080644.CAA19912@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: Thu, 8 Sep 2005 02:24:56 -0400 (EDT) To: ietf-ssh@NetBSD.org Cc: Russ Housley , Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <431FD875.4050809@siliconcircus.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > i.e. were the day to come and we deprecate (and eventually turn off) > *-cbc, we still have interoperability. No; you have that only if people actually do implement some common cipher. Using REQUIRED instead of RECOMMENDED might make that a little more probable, but I think it would be only a little, especially if we not only strongly recommend (say) 3des-ctr but explain *why*. >>> "we'd really, really like you to implement this, but we recognize >>> that not everyone's hardware is going to be big enough to squeeze >>> in both 3des and aes implementations". >> That's what SHOULD means. > I was thinking of something a little stronger, but maybe no such > thing exists. I don't think so, at least not within RFC2119 language. >> I really see no benefit to a requirement in which, if a particular >> algorithm is supported, then some other alternative algorithm must >> also be supported. > It indicates direction and achieves interoperability for the future. We can indicate direction without a REQUIRED, and a REQUIRED won't achieve interoperability; only actually getting some cipher (near-)universally implemented (and offered by default) will do that. A REQUIRED might lead to that, but it also might not - and the same applies to any other language we might use. It's just a judgement call as to whether the additional push in that direction (if any) is worth condemning implementations who ignore it. > Just because it says REQUIRED in a document, doesn't mean people are > going to slavishly follow it. Right - but the arguments you're presenting assume it does. > Question back: if we don't set any of these ciphers to REQUIRED, what > happens interoperability-wise when CBC gets deprecated? Nothing, same as if we do. Formally deprecating the CBC ciphers will either be acknowledging a already-present status quo, in which case pragmatics will mean we already have some suitable cipher (which may 3des-ctr, but also may not - vide infra), or it will be an attempt to lead things in that direction, in which case I think we'll be in a much better position to figure out what a good cipher will be then than now. I also don't much like mandating anything DES-based. As well-tested as DES is, it is a rather software-hostile cryptosystem, as compared to ciphers like (say) Rijndael or Blowfish. It wouldn't surprise me if, by the time deprecating the CBC modes looks practical, DES were also a fairly dead letter, with the current REQUIREment for 3des-cbc widely ignored. That said, I think this is rather a tempest in a teapot. Whatever language we put in newmodes, implementors will go off and do whatever they want anyway, and interoperate - or not. /~\ 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 Thu Sep 08 03:32:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDGtE-00071A-P9 for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 03:32: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 DAA04811 for ; Thu, 8 Sep 2005 03:32:06 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 93A3B63B1E9; Thu, 8 Sep 2005 07:32:03 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 678AF63B18B for ; Thu, 8 Sep 2005 07:32:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 5BCDF72C12; Thu, 8 Sep 2005 09:30:46 +0200 (CEST) Message-ID: <431FE884.6060503@siliconcircus.com> Date: Thu, 08 Sep 2005 09:30:12 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org, Russ Housley , Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: >>i.e. were the day to come and we deprecate (and eventually turn off) >>*-cbc, we still have interoperability. > > No; you have that only if people actually do implement some common > cipher. Using REQUIRED instead of RECOMMENDED might make that a little > more probable, but I think it would be only a little, especially if we > not only strongly recommend (say) 3des-ctr but explain *why*. I certainly think we should explain why, but I think it should be why it's REQUIRED, not why it's RECOMMENDED. Obviously we only have interoperability if people take any notice of what the document says - but if we only RECOMMEND it, then people can take notice of us and *still* not be interoperable. >>>I really see no benefit to a requirement in which, if a particular >>>algorithm is supported, then some other alternative algorithm must >>>also be supported. >> >>It indicates direction and achieves interoperability for the future. > > We can indicate direction without a REQUIRED, and a REQUIRED won't > achieve interoperability; only actually getting some cipher > (near-)universally implemented (and offered by default) will do that. Take some person who's implementing newmodes. If we just recommend that 3des-ctr be implemented, that person is comparitively more likely to blow off the recommendation with whatever justification ("Pfft, 3DES - so 90s") than if it's required. If 3des-ctr is required, it might still not get implemented. But it's likely to give someone more pause, to make them look a little more at the background (and to come upon the ML archive of this thread :-) > A REQUIRED might lead to that, but it also might not - and the same > applies to any other language we might use. It's just a judgement call > as to whether the additional push in that direction (if any) is worth > condemning implementations who ignore it. OK. What do we lose by making it REQUIRED? (Assuming all explanatory text is present whether it's REQUIRED or RECOMMENDED.) >>Just because it says REQUIRED in a document, doesn't mean people are >>going to slavishly follow it. > > Right - but the arguments you're presenting assume it does. No, my arguments say that making it REQUIRED makes it less likely that someone blows off the one cipher of the group that pretty much everyone's likely to be able to support. > I also don't much like mandating anything DES-based. As well-tested as > DES is, it is a rather software-hostile cryptosystem, as compared to > ciphers like (say) Rijndael or Blowfish. It wouldn't surprise me if, > by the time deprecating the CBC modes looks practical, DES were also a > fairly dead letter, with the current REQUIREment for 3des-cbc widely > ignored. I agree - but I also hear the view of the embedded/hardware people who can't squeeze both DES and AES in. As I said in my first mail, in a perfect world, I'd REQUIRE aes256-ctr as being (imo) the best compromise between future-proofness and widespread availability. > That said, I think this is rather a tempest in a teapot. Whatever > language we put in newmodes, implementors will go off and do whatever > they want anyway, and interoperate - or not. Agreed - but I think it has value that if they *don't* ignore us, the result is interoperable. "I did everything the RFCs said and I still can't interoperate with " is common enough already. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 04:26:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDHjg-000388-SG for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 04:26:20 -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 EAA06978 for ; Thu, 8 Sep 2005 04:26:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BB99563B3BC; Thu, 8 Sep 2005 08:26:11 +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 9696B63B18B for ; Thu, 8 Sep 2005 08:26:10 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA20127; Thu, 8 Sep 2005 04:26:09 -0400 (EDT) From: der Mouse Message-Id: <200509080826.EAA20127@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: Thu, 8 Sep 2005 04:05:34 -0400 (EDT) To: ietf-ssh@NetBSD.org Cc: Russ Housley , Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <431FE884.6060503@siliconcircus.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> [...] > Take some person who's implementing newmodes. Is there such a thing? That's the sort of thing people have been saying all along, and I really don't think it makes any sense. Take my implementation. I've implemented a handful of things whose spec is in newmodes; I've ignored a handful more. Have I "implemented newmodes"? According to the criterion given upthread - "any cipher from newmodes" - I have, but I certainly never thought of it that way. > What do we lose by making it REQUIRED? I can see two things. One is that people working on implementations which don't have room for two ciphers will end up doing DES instead of something faster and more secure; see below. Two is the "pointing and laughing" factor, which I can perhaps summarize as "lookie, they're still trying to require something DES-based! and they expect to be paid attention to! how lame!". How strong those effects are - and whether there are others - I'll leave up to others. > I agree - but I also hear the view of the embedded/hardware people > who can't squeeze both DES and AES in. Right, and which would you rather have? I'd sure rather see Rijndael, even restricted to AES, than DES, even triple-DES. Rijndael is faster in software and it's almost certainly more secure. Indeed, though I don't expect to see it happen, I'd actually prefer to see newmodes include language weakening the MUST in transport-24 and recommending that if only one fundamental cryptosystem is implemented that it be Rijndael rather than DES. >> That said, I think this is rather a tempest in a teapot. Whatever >> language we put in newmodes, implementors will go off and do >> whatever they want anyway, and interoperate - or not. > Agreed - but I think it has value that if they *don't* ignore us, the > result is interoperable. "I did everything the RFCs said and I still > can't interoperate with " is common enough already. Agreed - but that's approximately as true of RECOMMENDED/SHOULD language; in such cases typically appears to have been implemented based on a spec scribbled on the back of a napkin in a language the implementor doesn't understand - and then sold by Microsoft (okay, okay, - I had a brush with Windows telnet recently). There's not ignoring us, as in, paying attention to the meanings and doing something sensible in view of it, and there's not ignoring us, as in, obeying the letter of everything and the spirit of nothing. Which case(s) do you care about? I care about the former and not particularly about the latter, notwithstanding all the times I've jumped up and down and yammered about "buh-but it violates the RFC!". That's why I don't see any real harm in the weaker language. /~\ 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 Thu Sep 08 08:13:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLHm-0001ar-4a for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 08:13:46 -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 IAA15444 for ; Thu, 8 Sep 2005 08:13:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7531E63B27D; Thu, 8 Sep 2005 12:13:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (drno.siliconcircus.com [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 48A0263B1E3 for ; Thu, 8 Sep 2005 12:13:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id C61C8B4D9; Thu, 8 Sep 2005 14:13:38 +0200 (CEST) Message-ID: <43202AE8.7090208@siliconcircus.com> Date: Thu, 08 Sep 2005 14:13:28 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org, Russ Housley , Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: > > One is that people working on implementations which don't have room for > two ciphers will end up doing DES instead of something faster and more > secure; see below. But if they're implementing the core drafts and taking any notice of the REQUIRED entries, they'll already be doing DES. I'd *prefer* to REQUIRE aes-ctr, but given the situation in the core drafts, it's exactly to accomodate these people that I suggest requiring DES. > Two is the "pointing and laughing" factor, which I can perhaps > summarize as "lookie, they're still trying to require something > DES-based! and they expect to be paid attention to! how lame!". This point can, I think, be covered in the text. Something along the lines of "Although the only cipher which is REQUIRED is 3des-ctr, we strongly RECOMMEND that any implementation technically able to implement aes-ctr do so. If both ciphers are implemented, aes-ctr SHOULD by default be preferred during cipher negotiation, leaving 3des-ctr only for interoperability purposes". (Possibly modifying that last bit, since as I recall, some people have objections to SHOULDing cipher negotiation order, arguing this should be left to the admin or implementor.) >>I agree - but I also hear the view of the embedded/hardware people >>who can't squeeze both DES and AES in. > > > Right, and which would you rather have? I'd sure rather see Rijndael, > even restricted to AES, than DES, even triple-DES. Rijndael is faster > in software and it's almost certainly more secure. Indeed, though I > don't expect to see it happen, I'd actually prefer to see newmodes > include language weakening the MUST in transport-24 and recommending > that if only one fundamental cryptosystem is implemented that it be > Rijndael rather than DES. As above, I'd prefer AES, but as long as 3DES is REQUIRED in -transport, I don't think this is a plausible recommendation. Language altering the REQUIREment in -transport might be a sensible alternative if it's possible (what's the etiquette for these things?). The one risk with this approach is that we potentially lose interoperability between people who have just implemented the core drafts and those who've implemented newmodes ciphers. There's also the issue Peter raised about whether hardware capable of aes-ctr is yet sufficiently available. Overall, though, I think I'd welcome such language (and would then support an AES REQUIRE). > Agreed - but that's approximately as true of RECOMMENDED/SHOULD > language; in such cases typically appears to have been implemented > based on a spec scribbled on the back of a napkin in a language the > implementor doesn't understand - and then sold by Microsoft (okay, > okay, - I had a brush with Windows telnet recently). > > There's not ignoring us, as in, paying attention to the meanings and > doing something sensible in view of it, and there's not ignoring us, as > in, obeying the letter of everything and the spirit of nothing. Which > case(s) do you care about? I care about the former and not > particularly about the latter, notwithstanding all the times I've > jumped up and down and yammered about "buh-but it violates the RFC!". > > That's why I don't see any real harm in the weaker language. Fair points (and yes, I hate Windows telnet too :-). Given all this and being that I don't think our positions differ all that much, I'd be willing to compromise on a RECOMMEND with explanatory text pointing out that of the modes listed, some people may only be able to do 3des-ctr and thus although it's only a RECOMMEND, it's a really, really strong one for interoperability reasons. Basically, text to give a kind of "RECOMMEND. Oh, and we're holding a really big stick. And watching you." feeling. Maybe RFC2119 needs a revision, adding "RECOMMEND-WITH-STICK" :-) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 09:22:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMMJ-00013H-JC for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:22: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 JAA19027 for ; Thu, 8 Sep 2005 09:22:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EF8D163B29C; Thu, 8 Sep 2005 13:22:26 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by mail.netbsd.org (Postfix) with ESMTP id 6CB5F63B1E3 for ; Thu, 8 Sep 2005 13:22:25 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6A7C5E0049; Thu, 8 Sep 2005 09:22:28 -0400 (EDT) To: Jon Bright Cc: der Mouse , ietf-ssh@NetBSD.org, Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> From: Sam Hartman Date: Thu, 08 Sep 2005 09:22:28 -0400 In-Reply-To: <43202AE8.7090208@siliconcircus.com> (Jon Bright's message of "Thu, 08 Sep 2005 14:13:28 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Jon" == Jon Bright writes: Jon> der Mouse wrote: >> One is that people working on implementations which don't have >> room for two ciphers will end up doing DES instead of something >> faster and more secure; see below. Jon> But if they're implementing the core drafts and taking any Jon> notice of the REQUIRED entries, they'll already be doing DES. Jon> I'd *prefer* to REQUIRE aes-ctr, but given the situation in Jon> the core drafts, it's exactly to accomodate these people that Jon> I suggest requiring DES. I think this is actually a compelling argument for not requiring anything at the present time. We want to require aes-ctr (or at least I do), but we cannot get consensus to do so now. We recommend aes-ctr and say that when we update the 2026 applicability statement for the core ssh protocol we expect to require aes-ctr. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 09:56:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDMtM-0000HH-6V for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 09:56:42 -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 JAA20422 for ; Thu, 8 Sep 2005 09:56:37 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C2A4A63B22D; Thu, 8 Sep 2005 13:56:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id C904663B209 for ; Thu, 8 Sep 2005 13:56:35 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id A604B3455C; Fri, 9 Sep 2005 01:23:16 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15892-10; Fri, 9 Sep 2005 01:23:16 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 31CEC3454D; Fri, 9 Sep 2005 01:23:16 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2AE7537755; Fri, 9 Sep 2005 01:23:16 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EDMNB-0000GK-00; Fri, 09 Sep 2005 01:23:25 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: housley@vigilsec.com Message-Id: Date: Fri, 09 Sep 2005 01:23:25 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list I wrote: >AES-CTR is problematic because support for it in crypto hardware is >practically nonexistent (it's only just appeared as a recent update to PKCS >#11, and I'm not aware of any hardware that supports it), and it could be >years (if ever) before it's supported to a useful level. I've just checked and AES-CTR in PKCS #11 is still at the stage of a draft proposal. So effectively AES-CTR support in crypto hardware is currently nonexistent, unless there's some obscure device that handles it via a custom driver. I can't imagine anyone wanting to try synthesising it from ECB, they'll just not support it rather than kludge around the hardware, since having to kludge it with software defeats the point of having encryption hardware. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 10:41:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNaZ-0004EE-QY for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 10:41:20 -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 KAA23716 for ; Thu, 8 Sep 2005 10:41:16 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2030B63B2C1; Thu, 8 Sep 2005 14:41:14 +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 4DA8463B2B2 for ; Thu, 8 Sep 2005 14:41:13 +0000 (UTC) Received: from pc6 (1Cust9.tnt24.lnd4.gbr.da.uu.net [62.188.151.9]) by galaxy.systems.pipex.net (Postfix) with SMTP id 65086E00018A; Thu, 8 Sep 2005 15:41:10 +0100 (BST) Message-ID: <051201c5b47a$f6b69da0$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Chris Lonvick" , References: <20050814060350.GA24486@fork.recoil.org> Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt Date: Thu, 8 Sep 2005 15:39:18 +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 I see, belatedly, that secsh-arch still has a reference to SNMP and proxy forwarding in it. Since isms has now chosen to pursue SNMP over SSH and since proxy forwarding is a significant feature of SNMP and since, as far as I can establish, the reference in secsh-arch has no relationship to any of this whatsoever, I think that 'SNMP' should be elided from the document before it spreads havoc and confusion (already widespread in and around isms:-( Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Cc: Sent: Wednesday, September 07, 2005 8:10 PM Subject: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt > Hi, > > I've updated the drafts to get all of the messages indented the same way. > I also found that there were some occurances of "recipient_channel" but > more of "recipient channel" (mostly in CONNECT) so I harmonized them. > > The new set of IDs are here: > http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/ > Please look them over. If no one finds any problems then I'll let the RFC > Editor know that a few more non-substantiative fixes were made and that > they can use these drafts to create the RFCs. > > Thanks, > Chris > > > On Sun, 14 Aug 2005, Anil Madhavapeddy wrote: > > > In Section 6.10 (Returning Exit Status) of draft-ietf-secsh-connect-25.txt, > > the formatting of the "exit-signal" packet is different from the > > rest and indented incorrectly. Breaks my spec-extraction regexp, > > hence the motivation to point it out :) > > > > -- > > Anil Madhavapeddy http://anil.recoil.org > > University of Cambridge http://www.cl.cam.ac.uk > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 11:00:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDNtX-0008RR-OU for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:00:55 -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 LAA24621 for ; Thu, 8 Sep 2005 11:00:52 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 300FB63B3F7; Thu, 8 Sep 2005 15:00:52 +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 A148363B1BE for ; Thu, 8 Sep 2005 15:00:50 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa24002; 8 Sep 2005 11:00 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j88F0Uw8026660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 11:00:31 -0400 (EDT) Date: Thu, 08 Sep 2005 11:00:29 -0400 From: Jeffrey Hutzelman To: Jon Bright cc: Bill Sommerfeld , Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <2931FB0288998B47D6FE8F0A@bistromath.pc.cs.cmu.edu> In-Reply-To: <431FD875.4050809@siliconcircus.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> Originator-Info: login-token=Mulberry:01g7Dm3O0YW1DP+15dti4WSxoiHQcK5F/wJRRBuTA=; 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 Thursday, September 08, 2005 08:21:41 +0200 Jon Bright wrote: > Jeffrey Hutzelman wrote: >> >> >> On Wednesday, September 07, 2005 08:57:20 AM +0200 Jon Bright >> wrote: >>> >>> Having read various other comments and thought about it a bit, my >>> favoured solution is to REQUIRE 3des-ctr if *any* of the newmodes >>> ciphers are implemented. >> >> Why? What security or interoperability purpose would be served by such >> a requirement? > > Security purpose: none. Interoperability: we (should) get a counter-mode > cipher that's supported by anyone who supported any of the counter-mode > ciphers. i.e. were the day to come and we deprecate (and eventually turn > off) *-cbc, we still have interoperability. Except we don't, because having a counter-mode cipher that's supported by anyone who supported any of the counter-mode ciphers is not the same as having a counter-mode cipher that's supported by anyone with a compliant SSH implementation. If/when we want to deprecate *-cbc, we need to update the requirements for implementations of the SSH standard-to-be. This document could do that, but it does not presently claim to do so; it simply defines some additional encryption algorithms. >>> Additionally, would a conditional REQUIRE be possible >>> for aes128-ctr? Something along the lines of "we'd really, really like >>> you to implement this, but we recognize that not everyone's hardware is >>> going to be big enough to squeeze in both 3des and aes implementations". >> >> That's what SHOULD means. > > I was thinking of something a little stronger, but maybe no such thing > exists. The RFC2119 SHOULD is actually quite strong, and means almost exactly what you described. It does not mean "we think this is a good idea"; it means "you have to do this unless you have a really good reason not to and fully understand the implications". > If we don't have a REQUIRED cipher, then the day that the cbc ciphers are > deprecated, we don't any longer have an interoperable cipher. That's true when speaking of the ssh protocol as a whole. But the ssh protocol will always have a REQUIRED cipher, and I think it's safe to say that anyone who "implements newmodes" will also implement the core ssh protocol, and meet its requirements. > Question back: if we don't set any of these ciphers to REQUIRED, what > happens interoperability-wise when CBC gets deprecated? I think I answered that above. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 11:09:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDO1Q-0001aP-U6 for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:09: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 LAA25390 for ; Thu, 8 Sep 2005 11:09:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E6D2A63B403; Thu, 8 Sep 2005 15:09:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 26BD463B2FB for ; Thu, 8 Sep 2005 15:09:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 1377C89026; Thu, 8 Sep 2005 17:07:44 +0200 (CEST) Message-ID: <432053C5.10202@siliconcircus.com> Date: Thu, 08 Sep 2005 17:07:49 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Bill Sommerfeld , Russ Housley , ietf-ssh@NetBSD.org, Sam Hartman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <2931FB0288998B47D6FE8F0A@bistromath.pc.cs.cmu.edu> In-Reply-To: <2931FB0288998B47D6FE8F0A@bistromath.pc.cs.cmu.edu> 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 Jeffrey Hutzelman wrote: > > compliant SSH implementation. If/when we want to deprecate *-cbc, we > need to update the requirements for implementations of the SSH > standard-to-be. This document could do that, but it does not presently > claim to do so; it simply defines some additional encryption algorithms. .... >> Question back: if we don't set any of these ciphers to REQUIRED, what >> happens interoperability-wise when CBC gets deprecated? > > > I think I answered that above. I don't think you did. You basically said "when we deprecate cbc, we require something else". In my view the time between "we require people to implement a counter-mode cipher" and "we deprecate cbc" should be measured in years. Unless I've misunderstood what you're saying, your proposal is to require the new interoperable cipher at the same time as taking the old one away. This doesn't seem like a practical option to me. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 11:09:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDO1z-0001h5-JE for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:09:39 -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 LAA25427 for ; Thu, 8 Sep 2005 11:09:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1EF5563B2D7; Thu, 8 Sep 2005 15:09:36 +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 F201463B12B for ; Thu, 8 Sep 2005 15:09:34 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa24193; 8 Sep 2005 11:08 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j88F7xI5026727 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Sep 2005 11:08:00 -0400 (EDT) Date: Thu, 08 Sep 2005 11:07:58 -0400 From: Jeffrey Hutzelman To: Tom Petch , Chris Lonvick , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt Message-ID: <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> In-Reply-To: <051201c5b47a$f6b69da0$0601a8c0@pc6> References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> Originator-Info: login-token=Mulberry:01FosEYYDzedVi1nziSQk00K39O4ydv32DADLGTAs=; 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 Thursday, September 08, 2005 15:39:18 +0200 Tom Petch wrote: > I see, belatedly, that secsh-arch still has a reference to SNMP and proxy > forwarding in it. > > Since isms has now chosen to pursue SNMP over SSH and since proxy > forwarding is a significant feature of SNMP and since, as far as I can > establish, the reference in secsh-arch has no relationship to any of this > whatsoever, I think that 'SNMP' should be elided from the document before > it spreads havoc and confusion (already widespread in and around isms:-( Given that the SNMP-over-SSH work being done in ISMS currently takes the form of a subsystem rather than a connection-forwarding channel, I'm inclined to agree. Removing the mention of SNMP as an example does not meaningfully change the document, but will likely avoid considerable confusion in the future. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 12:08:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOx5-00017d-VE for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:08: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 MAA00012 for ; Thu, 8 Sep 2005 12:08:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 510A863B41D; Thu, 8 Sep 2005 16:08:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 9834563B18F for ; Thu, 8 Sep 2005 16:08:33 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Sep 2005 09:07:31 -0700 X-IronPort-AV: i="3.96,179,1122879600"; d="scan'208"; a="339887894:sNHT29074844" Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j88G7PKD020035; Thu, 8 Sep 2005 09:07:26 -0700 (PDT) Date: Thu, 8 Sep 2005 09:07:28 -0700 (PDT) From: Chris Lonvick To: Jeffrey Hutzelman cc: Tom Petch , ietf-ssh@NetBSD.org Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt In-Reply-To: <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> Message-ID: References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Current in Section 9.5.2 Proxy Forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain ... Proposed The SSH connection protocol allows for proxy forwarding of other protocols such as POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. If no one objects to this minor change then I'll let the RFC Editor know to use this update. Thanks, Chris On Thu, 8 Sep 2005, Jeffrey Hutzelman wrote: > > > On Thursday, September 08, 2005 15:39:18 +0200 Tom Petch > wrote: > >> I see, belatedly, that secsh-arch still has a reference to SNMP and proxy >> forwarding in it. >> >> Since isms has now chosen to pursue SNMP over SSH and since proxy >> forwarding is a significant feature of SNMP and since, as far as I can >> establish, the reference in secsh-arch has no relationship to any of this >> whatsoever, I think that 'SNMP' should be elided from the document before >> it spreads havoc and confusion (already widespread in and around isms:-( > > Given that the SNMP-over-SSH work being done in ISMS currently takes the form > of a subsystem rather than a connection-forwarding channel, I'm inclined to > agree. Removing the mention of SNMP as an example does not meaningfully > change the document, but will likely avoid considerable confusion in the > future. > > -- Jeff > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 12:12:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDP0j-0003Qf-Je for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:12:27 -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 MAA00662 for ; Thu, 8 Sep 2005 12:12:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 3ADFC63B4DC; Thu, 8 Sep 2005 16:12:22 +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 942E163B4BF for ; Thu, 8 Sep 2005 16:12:21 +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 j88GCGHT028119; Thu, 8 Sep 2005 09:12:16 -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 j88GCFUj024967; Thu, 8 Sep 2005 12:12:16 -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 j88GCFX1012506; Thu, 8 Sep 2005 12:12:15 -0400 (EDT) Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt From: Bill Sommerfeld To: Chris Lonvick Cc: Jeffrey Hutzelman , Tom Petch , ietf-ssh@NetBSD.org In-Reply-To: References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1126195934.11565.66.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 08 Sep 2005 12:12:15 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-09-08 at 12:07, Chris Lonvick wrote: > Current in Section 9.5.2 Proxy Forwarding > The SSH connection protocol allows for proxy forwarding of other > protocols such as SNMP, POP3, and HTTP. This may be a concern for > network administrators who wish to control the access of certain > ... Actually, I would suggest changing "SNMP" to "SMTP". SNMP makes no sense there since we don't have a UDP forwarding capability in the specs at present. Dunno about anyone else but I started doing SMTP-over-SSH forwarding on a routine basis from my laptop years ago. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 12:44:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDPVt-0005cb-Gj for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 12:44:39 -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 MAA02615 for ; Thu, 8 Sep 2005 12:44:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E8D9263B4D7; Thu, 8 Sep 2005 16:44:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 52EB463B3FE for ; Thu, 8 Sep 2005 16:44:33 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2005 09:44:33 -0700 Received: from sjc-cde-003.cisco.com (sjc-cde-003.cisco.com [171.71.162.81]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j88GiSKD013399; Thu, 8 Sep 2005 09:44:28 -0700 (PDT) Date: Thu, 8 Sep 2005 09:44:30 -0700 (PDT) From: Chris Lonvick To: Bill Sommerfeld cc: Jeffrey Hutzelman , Tom Petch , ietf-ssh@NetBSD.org Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt In-Reply-To: <1126195934.11565.66.camel@thunk> Message-ID: References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> <1126195934.11565.66.camel@thunk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Thu, 8 Sep 2005, Bill Sommerfeld wrote: > On Thu, 2005-09-08 at 12:07, Chris Lonvick wrote: >> Current in Section 9.5.2 Proxy Forwarding >> The SSH connection protocol allows for proxy forwarding of other >> protocols such as SNMP, POP3, and HTTP. This may be a concern for >> network administrators who wish to control the access of certain >> ... > > Actually, I would suggest changing "SNMP" to "SMTP". That makes sense. I've updated ARCH to reflect that. http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/ > > SNMP makes no sense there since we don't have a UDP forwarding > capability in the specs at present. > > Dunno about anyone else but I started doing SMTP-over-SSH forwarding on > a routine basis from my laptop years ago. I use pine. (...over ssh) Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 13:03:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDPoR-0002XN-9H for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 13:03:47 -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 NAA03452 for ; Thu, 8 Sep 2005 13:03:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CB67163B133; Thu, 8 Sep 2005 17:03:39 +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 A39CD63B132 for ; Thu, 8 Sep 2005 17:03:38 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA21578; Thu, 8 Sep 2005 13:03:37 -0400 (EDT) From: der Mouse Message-Id: <200509081703.NAA21578@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: Thu, 8 Sep 2005 13:02:46 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt In-Reply-To: References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Current in Section 9.5.2 Proxy Forwarding > The SSH connection protocol allows for proxy forwarding of other > protocols such as SNMP, POP3, and HTTP. This may be a concern for > network administrators who wish to control the access of certain > ... > Proposed [...] I too think it'd be better to just s/SNMP/SMTP/. But if you want to delete SNMP, the comma after POP3 should go too. /~\ 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 Thu Sep 08 14:40:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDRJz-0004K8-P3 for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 14:40: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 OAA09196 for ; Thu, 8 Sep 2005 14:40:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id EE7F863B132; Thu, 8 Sep 2005 18:40:20 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from astro.systems.pipex.net (astro.systems.pipex.net [62.241.163.6]) by mail.netbsd.org (Postfix) with ESMTP id 276E663B112 for ; Thu, 8 Sep 2005 18:40:20 +0000 (UTC) Received: from pc6 (1Cust126.tnt107.lnd4.gbr.da.uu.net [213.116.62.126]) by astro.systems.pipex.net (Postfix) with SMTP id 2AF66E000086; Thu, 8 Sep 2005 19:40:14 +0100 (BST) Message-ID: <00a001c5b49c$5d649d60$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Chris Lonvick" , "Bill Sommerfeld" Cc: "Jeffrey Hutzelman" , References: <20050814060350.GA24486@fork.recoil.org> <051201c5b47a$f6b69da0$0601a8c0@pc6> <05F84DEC04EA999D89B36338@bistromath.pc.cs.cmu.edu> <1126195934.11565.66.camel@thunk> Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt Date: Thu, 8 Sep 2005 19:25:31 +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 Yes, SMTP sounds like an excellent suggestion. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: "Bill Sommerfeld" Cc: "Jeffrey Hutzelman" ; "Tom Petch" ; Sent: Thursday, September 08, 2005 6:44 PM Subject: Re: New core drafts - was: Re: nit in draft-ietf-secsh-connect-25.txt > Hi, > > On Thu, 8 Sep 2005, Bill Sommerfeld wrote: > > > On Thu, 2005-09-08 at 12:07, Chris Lonvick wrote: > >> Current in Section 9.5.2 Proxy Forwarding > >> The SSH connection protocol allows for proxy forwarding of other > >> protocols such as SNMP, POP3, and HTTP. This may be a concern for > >> network administrators who wish to control the access of certain > >> ... > > > > Actually, I would suggest changing "SNMP" to "SMTP". > > That makes sense. I've updated ARCH to reflect that. > http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/ > > > > > SNMP makes no sense there since we don't have a UDP forwarding > > capability in the specs at present. > > > > Dunno about anyone else but I started doing SMTP-over-SSH forwarding on > > a routine basis from my laptop years ago. > > I use pine. (...over ssh) > > Thanks, > Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 15:01:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDReR-0001rH-VH for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 15:01: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 PAA11249 for ; Thu, 8 Sep 2005 15:01:33 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 81FAF63B122; Thu, 8 Sep 2005 19:01:32 +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 558A463B112 for ; Thu, 8 Sep 2005 19:01:31 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA22260; Thu, 8 Sep 2005 15:01:30 -0400 (EDT) From: der Mouse Message-Id: <200509081901.PAA22260@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: Thu, 8 Sep 2005 14:47:16 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: keyboard-interactive auth Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I'm trying to implement keyboard-interactive authentication, and I think maybe I've got something written, but when I try to use it against openssh, I see the exchange go <<< confirmation of ssh-userauth starting >>> request mouse/ssh-connection/none <<< failure, can-continue publickey,password,keyboard-interactive >>> request mouse/ssh-connection/keyboard-interactive <<< failure, can-continue publickey,password,keyboard-interactive This makes no sense to me; I'm not even sure how to interpret it, besides "server too confused to do keyboard-interactive for this user". Anyone know what's up with it? /~\ 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 Thu Sep 08 15:56:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSVc-0006vB-7Y for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 15:56: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 PAA14784 for ; Thu, 8 Sep 2005 15:56:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E1D9063B1CC; Thu, 8 Sep 2005 19:56:21 +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 A3C2063B112 for ; Thu, 8 Sep 2005 19:56:20 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA22582; Thu, 8 Sep 2005 15:56:19 -0400 (EDT) From: der Mouse Message-Id: <200509081956.PAA22582@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: Thu, 8 Sep 2005 15:49:34 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth In-Reply-To: References: <200509081901.PAA22260@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > <<< confirmation of ssh-userauth starting > >>> request mouse/ssh-connection/none > <<< failure, can-continue publickey,password,keyboard-interactive > >>> request mouse/ssh-connection/keyboard-interactive > <<< failure, can-continue publickey,password,keyboard-interactive > "Yeah, Openssh does that." Openssh does not keep track of whether an > authentication method has failed to be useful on the server side. It > [...] expects the client to deal with this. Okay, I can live with that (I have to be prepared to do *something* in the face of arbitrarily broken servers, after all, and it's not that difficult to keep a list of auth methods that appear to be misbehaving.) That answers the question of what openssh means in doing this - it's rejecting keyboard-interactive auth, just in a way that rather confused me. But it raises the question of why openssh is rejecting keyboard-interactive auth at all. Any thoughts on that? /~\ 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 Thu Sep 08 16:10:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDSj0-0001NN-Sk for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 16:10: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 QAA15059 for ; Thu, 8 Sep 2005 16:10:18 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id F196263B1EF; Thu, 8 Sep 2005 20:10:17 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mail.netbsd.org (Postfix) with ESMTP id 561BF63B1EE for ; Thu, 8 Sep 2005 20:10:17 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 493C9E0049; Thu, 8 Sep 2005 15:45:25 -0400 (EDT) To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth References: <200509081901.PAA22260@Sparkle.Rodents.Montreal.QC.CA> From: Sam Hartman Date: Thu, 08 Sep 2005 15:45:25 -0400 In-Reply-To: <200509081901.PAA22260@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Thu, 8 Sep 2005 14:47:16 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "der" == der Mouse writes: der> I'm trying to implement keyboard-interactive authentication, and I der> think maybe I've got something written, but when I try to use it der> against openssh, I see the exchange go der> <<< confirmation of ssh-userauth starting >>>> request mouse/ssh-connection/none der> <<< failure, can-continue publickey,password,keyboard-interactive >>>> request mouse/ssh-connection/keyboard-interactive der> <<< failure, can-continue publickey,password,keyboard-interactive der> This makes no sense to me; I'm not even sure how to interpret it, der> besides "server too confused to do keyboard-interactive for this user". "Yeah, Openssh does that." Openssh does not keep track of whether an authentication method has failed to be useful on the server side. It continues to offer all the authentication methods even if they don't really apply to the current user. It expects the client to deal with this. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 16:57:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDTSe-0004yT-OO for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 16:57: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 QAA17120 for ; Thu, 8 Sep 2005 16:57:28 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 91BBA63B184; Thu, 8 Sep 2005 20:57:27 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id BB19B63B11B for ; Thu, 8 Sep 2005 20:57:26 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa00543; 8 Sep 2005 16:57 EDT Date: Thu, 08 Sep 2005 16:57:21 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth Message-ID: <1BFC14CDF20A14EFC395CEC2@sirius.fac.cs.cmu.edu> In-Reply-To: <200509081956.PAA22582@Sparkle.Rodents.Montreal.QC.CA> References: <200509081901.PAA22260@Sparkle.Rodents.Montreal.QC.CA> <200509081956.PAA22582@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01fV15XOfF7tDJqPHdsNupyxTPsIcEkfLq0qfBs90=; 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 Thursday, September 08, 2005 03:49:34 PM -0400 der Mouse wrote: >> <<< confirmation of ssh-userauth starting >> >>> request mouse/ssh-connection/none >> <<< failure, can-continue publickey,password,keyboard-interactive >> >>> request mouse/ssh-connection/keyboard-interactive >> <<< failure, can-continue publickey,password,keyboard-interactive > >> "Yeah, Openssh does that." Openssh does not keep track of whether an >> authentication method has failed to be useful on the server side. It >> [...] expects the client to deal with this. > > Okay, I can live with that (I have to be prepared to do *something* in > the face of arbitrarily broken servers, after all, and it's not that > difficult to keep a list of auth methods that appear to be > misbehaving.) > > That answers the question of what openssh means in doing this - it's > rejecting keyboard-interactive auth, just in a way that rather confused > me. But it raises the question of why openssh is rejecting > keyboard-interactive auth at all. Any thoughts on that? Depending on the mechanisms in use, it is possible that the server isn't rejecting the method, but is deciding to deny access to that user without requiring further interaction. It is certainly possible to configure a PAM stack that will behave in this way. It's also possible that your server is misconfigured in such a way that keyboard-interactive is broken. If the server is configured to use PAM to support keyboard-interactive, and there is some problem with the PAM configurationm, then I would not be surprised to see behavior along these lines. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 19:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVxw-0002V5-UO for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 19:38:01 -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 TAA05674 for ; Thu, 8 Sep 2005 19:37:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E4F2863B2AD; Thu, 8 Sep 2005 23:37:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 2F58463B2A8 for ; Thu, 8 Sep 2005 23:37:55 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 6182917E639; Fri, 9 Sep 2005 09:37:53 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 5FD7D17E605; Fri, 9 Sep 2005 09:37:53 +1000 (EST) Date: Fri, 9 Sep 2005 09:37:53 +1000 (EST) From: Damien Miller To: der Mouse cc: ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth In-Reply-To: <200509081956.PAA22582@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200509081901.PAA22260@Sparkle.Rodents.Montreal.QC.CA> <200509081956.PAA22582@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 8 Sep 2005, der Mouse wrote: > That answers the question of what openssh means in doing this - it's > rejecting keyboard-interactive auth, just in a way that rather confused > me. But it raises the question of why openssh is rejecting > keyboard-interactive auth at all. Any thoughts on that? I think these implementation-specific questions are best asked on a OpenSSH list (or by reading the public source code). -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 19:56:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDWG2-0006Gm-A1 for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 19:56:42 -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 TAA06380 for ; Thu, 8 Sep 2005 19:56:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B8D9E63B264; Thu, 8 Sep 2005 23:56:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mail.netbsd.org (Postfix) with ESMTP id 125E663B223 for ; Thu, 8 Sep 2005 23:56:38 +0000 (UTC) Received: from martynakaczor (bfy68.neoplus.adsl.tpnet.pl [83.28.62.68]) by poczta.o2.pl (Postfix) with SMTP id E868C340048 for ; Fri, 9 Sep 2005 01:56:35 +0200 (CEST) Reply-To: "Martyna Kaczor" From: "Martyna Kaczor" To: Subject: Only for you Date: Fri, 9 Sep 2005 01:56:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 X-Antivirus: avast! (VPS 0536-2, 2005-09-07), Outbound message X-Antivirus-Status: Clean Message-Id: <20050908235635.E868C340048@poczta.o2.pl> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Look Free Ads http://stat4you.ovh.org Martyna Kaczor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 08 23:52:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDZw4-00029v-VU for secsh-archive@megatron.ietf.org; Thu, 08 Sep 2005 23:52: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 XAA23678 for ; Thu, 8 Sep 2005 23:52:17 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5512963B1AA; Fri, 9 Sep 2005 03:52:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 7E77D63B101 for ; Fri, 9 Sep 2005 03:52:14 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 0295534C5F; Fri, 9 Sep 2005 15:52:13 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06068-06; Fri, 9 Sep 2005 15:52:12 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id F034C34CF0; Fri, 9 Sep 2005 15:52:11 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B753E37756; Fri, 9 Sep 2005 15:52:11 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EDZw0-0003H8-00; Fri, 09 Sep 2005 15:52:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: djm@mindrot.org, mouse@Rodents.Montreal.QC.CA Subject: Re: keyboard-interactive auth Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Fri, 09 Sep 2005 15:52:16 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Damien Miller writes: >I think these implementation-specific questions are best asked on a >OpenSSH list (or by reading the public source code). I disagree. Problems in OpenSSH affect every other SSH implementation, so it's important that other SSH implementers be made aware of issues like this so they can adjust their own implementation. (OK, the real issue is that OpenSSH should adjust its behaviour, but given the huge installed base that won't happen in a hurry). Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 00:33:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDaZS-0001HI-Ik for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 00:33: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 AAA24882 for ; Fri, 9 Sep 2005 00:32:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 308C163B1FB; Fri, 9 Sep 2005 04:32:59 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 6B28C63B12C for ; Fri, 9 Sep 2005 04:32:58 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 0341C17E609; Fri, 9 Sep 2005 14:32:56 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id F026317E605; Fri, 9 Sep 2005 14:32:56 +1000 (EST) Date: Fri, 9 Sep 2005 14:32:56 +1000 (EST) From: Damien Miller To: Peter Gutmann cc: mouse@Rodents.Montreal.QC.CA, ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, 9 Sep 2005, Peter Gutmann wrote: > (OK, the real issue is that OpenSSH should adjust its behaviour, but given > the huge installed base that won't happen in a hurry). Well, no. AFAIK OpenSSH's behaviour in this regard is compliant with the kbd-int draft. The server cannot know a priori whether a delegated authentication mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going to return an instant failure when queried. The draft explicitly caters for this circumstance, allowing the server to return SSH_MSG_USERAUTH_FAILURE immediately. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 01:03:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDb2R-00073m-Sk for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 01:03: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 BAA25700 for ; Fri, 9 Sep 2005 01:02:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E7E8963B12C; Fri, 9 Sep 2005 05:02:54 +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 C5A1363B140 for ; Fri, 9 Sep 2005 05:02:53 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA07662; Fri, 9 Sep 2005 01:02:53 -0400 (EDT) From: der Mouse Message-Id: <200509090502.BAA07662@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, 9 Sep 2005 00:53:19 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth In-Reply-To: References: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> (OK, the real issue is that OpenSSH should adjust its behaviour, but >> given the huge installed base that won't happen in a hurry). > Well, no. AFAIK OpenSSH's behaviour in this regard is compliant with > the kbd-int draft. The latter does not necessarily imply the former; it's entirely possible that certain behaviour should be adjusted even though it's entirely conformant. In this case, I think it should. See below. > The server cannot know a priori whether a delegated authentication > mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going > to return an instant failure when queried. The draft explicitly > caters for this circumstance, allowing the server to return > SSH_MSG_USERAUTH_FAILURE immediately. Sure - but when that failure message lists keyboard-interactive as a productive method to continue authenticating with it is, at the very least, confusing. And that's why I think it should be "adjusted" - and the aspect of it which I think should be changed. The situation is a bit messy; as a comment in my source (in the USERAUTH_FAILURE handling) says: /* Four cases: (1) partial success, current algorithm listed in methods current alg running -> continue current alg (2) partial success, current algorithm not listed in methods current alg succeeded, more auth needed -> end current alg -> pick next alg -> start it (3) no partial success, current algorithm listed in methods not sure what this can mean - maybe, eg, public key failed, but another public key might succeed? -> retry current alg (4) no partial success, current algorithm not listed in methods current alg failed, try another -> end current alg -> pick next alg -> start it */ The semantics of these cases (the indented text with no arrow after the numbered lines) are not clearly laid out in the drafts, as far as I can tell; what I wrote in that comment was guesses. (My guess about publickey seems to have matched current practice; about keyboard-interactive, not.) /~\ 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 Sep 09 12:23:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDlfF-000191-AA for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 12:23:45 -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 MAA12671 for ; Fri, 9 Sep 2005 12:23:42 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6362E63B2AE; Fri, 9 Sep 2005 16:23:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 5E2CF63B146 for ; Fri, 9 Sep 2005 16:23:39 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j89GNcTW016568 for ; Fri, 9 Sep 2005 10:23:38 -0600 (MDT) 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 j89GNcWB012405; Fri, 9 Sep 2005 12:23:38 -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 j89GNbfG018032; Fri, 9 Sep 2005 12:23:38 -0400 (EDT) Subject: [Fwd: I-D ACTION:draft-harrington-isms-secshell-00.txt] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1126283017.17794.53.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 12:23:37 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I suspect the ISMS folk would appreciate it if folks with secure shell implementation experience took a look at this draft. Note that the use of ssh to secure SNMP is generating a lot of traffic on the main IETF list (ietf@ietf.org); you may want to wade through the relevant threads there before diving in. - Bill -----Forwarded Message----- From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-harrington-isms-secshell-00.txt Date: Thu, 08 Sep 2005 18:50:01 -0400 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Shell Security Model for SNMP Author(s) : D. Harrington Filename : draft-harrington-isms-secshell-00.txt Pages : 41 Date : 2005-9-8 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-harrington-isms-secshell-00.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-harrington-isms-secshell-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-harrington-isms-secshell-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________________________________________________ Content-Type: text/plain Content-ID: <2005-9-8162649.I-D@ietf.org> ________________________________________________________________________ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 14:52:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDnzP-0004TP-7k for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 14:52: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 OAA22021 for ; Fri, 9 Sep 2005 14:52:41 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 60B6B63B183; Fri, 9 Sep 2005 18:52:32 +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 509D563B141 for ; Fri, 9 Sep 2005 18:52:31 +0000 (UTC) Received: (qmail 29072 invoked by uid 0); 9 Sep 2005 18:52:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.96) by woodstock.binhost.com with SMTP; 9 Sep 2005 18:52:21 -0000 Message-Id: <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 09 Sep 2005 14:47:13 -0400 To: Jon Bright From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: ietf-ssh@NetBSD.org, Sam Hartman In-Reply-To: <43202AE8.7090208@siliconcircus.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Take a look at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-05.txt This document is approved and waiting publication as a standards-track RFC. In this document, Jeff Shiller references RFC 2119, and then he further defines SHOULD+ SHOULD+ This term means the same as SHOULD. However it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST. This seems like it might offer a compromise point, excpet that in the context of this document, the algorithm might become required for all SSH implementations, not just all newmodes implementations. This would need to be clear. The working group would still need to decide if 3DES-CTR or AES128-CTR or both would receive this REQUIRED+ marking. Russ At 08:13 AM 9/8/2005, Jon Bright wrote: >Basically, text to give a kind of "RECOMMEND. Oh, and we're holding a >really big stick. And watching you." feeling. Maybe RFC2119 needs a >revision, adding "RECOMMEND-WITH-STICK" :-) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 15:13:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoJy-0003HO-Qg for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:13:58 -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 PAA24282 for ; Fri, 9 Sep 2005 15:13:56 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 10B7763B1DF; Fri, 9 Sep 2005 19:13:55 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by mail.netbsd.org (Postfix) with ESMTP id 6881463B1DE for ; Fri, 9 Sep 2005 19:13:54 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 256FEE0049; Fri, 9 Sep 2005 15:13:54 -0400 (EDT) To: Russ Housley Cc: Jon Bright , ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> From: Sam Hartman Date: Fri, 09 Sep 2005 15:13:54 -0400 In-Reply-To: <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> (Russ Housley's message of "Fri, 09 Sep 2005 14:47:13 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Russ" == Russ Housley writes: Russ> The working group would still need to decide if 3DES-CTR or Russ> AES128-CTR or both would receive this REQUIRED+ marking. Russ, I would feel much more comfortable with the marking if it was done in text rather than using should+. Either solution is acceptable but I would prefer the textual marking. Would you be OK with that? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 15:20:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoQC-0004ec-3L for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:20: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 PAA24853 for ; Fri, 9 Sep 2005 15:20:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D3B263B1FE; Fri, 9 Sep 2005 19:20:20 +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 41A9A63B1DE for ; Fri, 9 Sep 2005 19:20:19 +0000 (UTC) Received: (qmail 15792 invoked by uid 0); 9 Sep 2005 19:20:13 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.96) by woodstock.binhost.com with SMTP; 9 Sep 2005 19:20:13 -0000 Message-Id: <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 09 Sep 2005 15:20:15 -0400 To: Sam Hartman From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: Jon Bright , ietf-ssh@NetBSD.org In-Reply-To: References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sam: Yes, I am comfortable with the use of text to say the same thing. Russ Sam Hartman wrote: > Russ> The working group would still need to decide if 3DES-CTR or > Russ> AES128-CTR or both would receive this REQUIRED+ marking. > >Russ, I would feel much more comfortable with the marking if it was >done in text rather than using should+. Either solution is acceptable >but I would prefer the textual marking. Would you be OK with that? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 15:28:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDoXy-0006Bx-Ha for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:28:26 -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 PAA25602 for ; Fri, 9 Sep 2005 15:28:24 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C5CF963B215; Fri, 9 Sep 2005 19:28:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148]) by mail.netbsd.org (Postfix) with ESMTP id 2635863B227 for ; Fri, 9 Sep 2005 19:28:22 +0000 (UTC) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 44417E004B; Fri, 9 Sep 2005 15:28:21 -0400 (EDT) To: Russ Housley Cc: Jon Bright , ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> From: Sam Hartman Date: Fri, 09 Sep 2005 15:28:21 -0400 In-Reply-To: <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> (Russ Housley's message of "Fri, 09 Sep 2005 15:20:15 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Russ" == Russ Housley writes: Russ> Sam: Yes, I am comfortable with the use of text to say the Russ> same thing. Russ> Russ OK. Bill, do we have a consensus to decide on a direction for what cipher we'll make mandatory to implement and to document that decision in newmodes? If so, do we have a consensus yet on what that direction is or do we need to have more discussion on that? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 15:57:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDp0B-0004CC-7Z for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 15:57: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 PAA27242 for ; Fri, 9 Sep 2005 15:57:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0EC0A63B174; Fri, 9 Sep 2005 19:57:30 +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 17E4263B242 for ; Fri, 9 Sep 2005 19:57:29 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j89JvJ2B023423; Fri, 9 Sep 2005 12:57:20 -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 j89JvIWB027775; Fri, 9 Sep 2005 15:57:18 -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 j89JvIFX018848; Fri, 9 Sep 2005 15:57:18 -0400 (EDT) Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Sam Hartman Cc: Russ Housley , Jon Bright , ietf-ssh@NetBSD.org In-Reply-To: References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> Content-Type: text/plain Message-Id: <1126295837.17794.218.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 15:57:17 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-09-09 at 15:28, Sam Hartman wrote: > >>>>> "Russ" == Russ Housley writes: > > Russ> Sam: Yes, I am comfortable with the use of text to say the > Russ> same thing. > > Russ> Russ > > OK. Bill, do we have a consensus to decide on a direction for what > cipher we'll make mandatory to implement and to document that decision > in newmodes? Yes, it looks that way. > If so, do we have a consensus yet on what that direction is or do we > need to have more discussion on that? I just reviewed this thread and the prior one on the same topic on the specific question of aes vs 3des. By my count, 9 people have expressed an opinion leading one way or the other; 6 were unambiguously in favor of aes128-ctr; one wants to wait for hardware counter mode support to materialize but seems to be leaning towards AES. One prefers 3des now but expects a migration to aes later. One person supported either aes128-ctr or aes256-ctr. Looks to me like we have rough consensus on aes128-ctr as opposed to 3des-ctr as a "SHOULD+" or "Most likely to replace 3des-cbc but not yet REQUIRED". My proposed edit is to extend the paragraph reading: The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. with: At this time it appears likely that a future revision of this specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged. - Bill - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:06:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDp8n-0000B5-70 for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:06:29 -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 QAA29813 for ; Fri, 9 Sep 2005 16:06:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7679463B21E; Fri, 9 Sep 2005 20:06:21 +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 8C58663B18D for ; Fri, 9 Sep 2005 20:06:20 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa24568; 9 Sep 2005 16:06 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j89K61mO004062 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Sep 2005 16:06:02 -0400 (EDT) Date: Fri, 09 Sep 2005 16:06:01 -0400 From: Jeffrey Hutzelman To: Bill Sommerfeld , Sam Hartman cc: Russ Housley , Jon Bright , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: In-Reply-To: <1126295837.17794.218.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> Originator-Info: login-token=Mulberry:01h+pNovFSwhbTNcUjumh9ER5chM0OHsb0X3sHvWo=; 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 Friday, September 09, 2005 15:57:17 -0400 Bill Sommerfeld wrote: > By my count, 9 people have expressed an opinion leading one way or the > other; 6 were unambiguously in favor of aes128-ctr; one wants to wait > for hardware counter mode support to materialize but seems to be leaning > towards AES. One prefers 3des now but expects a migration to aes > later. One person supported either aes128-ctr or aes256-ctr. Add me to the AES column. > My proposed edit is to extend the paragraph reading: > > The "aes128-ctr" method uses AES (the Advanced Encryption Standard, > formerly Rijndael) with 128-bit keys [AES]. The block size is 16 > bytes. > > with: > > At this time it appears likely that a future revision of this > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. s/this specification/the SSH transport protocol specification [SSH-TRANS]/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:14:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpGS-0005QK-Ei for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:14: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 QAA03287 for ; Fri, 9 Sep 2005 16:14:20 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 10D8263B249; Fri, 9 Sep 2005 20:14:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 5517063B231 for ; Fri, 9 Sep 2005 20:14:18 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j89KE91L001429; Fri, 9 Sep 2005 14:14:09 -0600 (MDT) 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 j89KE9Uj024165; Fri, 9 Sep 2005 16:14: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 j89KE8oW019381; Fri, 9 Sep 2005 16:14:09 -0400 (EDT) Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Russ Housley Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> Content-Type: text/plain Message-Id: <1126296848.17794.221.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 16:14:08 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-09-09 at 16:10, Russ Housley wrote: > Bill: > > I am not totally happy with this proposed text. It could be interpreted to > mean an update to the newmodes document , but you really mean that a future > specification is likely to require aes128-ctr for all SSH implementations. > How about we drop "revision of this", leaving: At this time it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged. I think this resolves jhutz' concern as well. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:11:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpE0-0003fX-Iy for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:11:53 -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 QAA02053 for ; Fri, 9 Sep 2005 16:11:49 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 605F863B1E0; Fri, 9 Sep 2005 20:11:48 +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 09E1F63B18D for ; Fri, 9 Sep 2005 20:11:46 +0000 (UTC) Received: (qmail 27438 invoked by uid 0); 9 Sep 2005 20:10:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.96) by woodstock.binhost.com with SMTP; 9 Sep 2005 20:10:35 -0000 Message-Id: <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 09 Sep 2005 16:10:38 -0400 To: Bill Sommerfeld From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: hartmans-ietf@mit.edu, ietf-ssh@NetBSD.org In-Reply-To: <1126295837.17794.218.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill: I am not totally happy with this proposed text. It could be interpreted to mean an update to the newmodes document , but you really mean that a future specification is likely to require aes128-ctr for all SSH implementations. Russ At 03:57 PM 9/9/2005, Bill Sommerfeld wrote: >My proposed edit is to extend the paragraph reading: > > The "aes128-ctr" method uses AES (the Advanced Encryption Standard, > formerly Rijndael) with 128-bit keys [AES]. The block size is 16 > bytes. > >with: > > At this time it appears likely that a future revision of this > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:23:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpP0-0004vs-47 for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:23: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 QAA07447 for ; Fri, 9 Sep 2005 16:23:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 17DBC63B29B; Fri, 9 Sep 2005 20:23:11 +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 0185D63B26A for ; Fri, 9 Sep 2005 20:23:09 +0000 (UTC) Received: (qmail 8547 invoked by uid 0); 9 Sep 2005 20:21:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (151.200.237.96) by woodstock.binhost.com with SMTP; 9 Sep 2005 20:21:21 -0000 Message-Id: <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 09 Sep 2005 16:21:24 -0400 To: Bill Sommerfeld From: Russ Housley Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: <1126296848.17794.221.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill: I can live with this text or the text proposed by Jeff. Russ At 04:14 PM 9/9/2005, Bill Sommerfeld wrote: >On Fri, 2005-09-09 at 16:10, Russ Housley wrote: > > Bill: > > > > I am not totally happy with this proposed text. It could be > interpreted to > > mean an update to the newmodes document , but you really mean that a > future > > specification is likely to require aes128-ctr for all SSH implementations. > > > >How about we drop "revision of this", leaving: > > At this time it appears likely that a future > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. > >I think this resolves jhutz' concern as well. > > - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:40:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDpfv-0000A1-GP for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:40: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 QAA08969 for ; Fri, 9 Sep 2005 16:40:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8FFE463B2A9; Fri, 9 Sep 2005 20:40:39 +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 6F88563B18D for ; Fri, 9 Sep 2005 20:40:38 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa25149; 9 Sep 2005 16:40 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j89KeQV3004180 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 9 Sep 2005 16:40:27 -0400 (EDT) Date: Fri, 09 Sep 2005 16:40:26 -0400 From: Jeffrey Hutzelman To: Russ Housley , Bill Sommerfeld cc: Sam Hartman , ietf-ssh@NetBSD.org, Jeffrey Hutzelman Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: In-Reply-To: <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> Originator-Info: login-token=Mulberry:01RfuBua9j9i2RRvk6eHmxKNxtuOTML/qycK8ee3s=; 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 Friday, September 09, 2005 16:21:24 -0400 Russ Housley wrote: > Bill: > > I can live with this text or the text proposed by Jeff. Me too From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 16:42:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDphC-0000n6-Uv for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 16:42: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 QAA09002 for ; Fri, 9 Sep 2005 16:42:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 21E2B63B2B6; Fri, 9 Sep 2005 20:42:00 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mail.netbsd.org (Postfix) with ESMTP id 573F663B18D for ; Fri, 9 Sep 2005 20:41:59 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j89KftXX000557; Fri, 9 Sep 2005 14:41:55 -0600 (MDT) 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 j89KftUj003148; Fri, 9 Sep 2005 16:41:55 -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 j89KftCi019450; Fri, 9 Sep 2005 16:41:55 -0400 (EDT) Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Russ Housley Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> Content-Type: text/plain Message-Id: <1126298514.17794.224.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 16:41:55 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-09-09 at 16:21, Russ Housley wrote: > Bill: > > I can live with this text or the text proposed by Jeff. I think we want the ability to amend the required/recommended algorithms with a focussed document like draft-ietf-ipsec-ikev2-algorithms-05.txt - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 19:21:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDsBO-0000af-Ug for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 19:21: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 TAA22142 for ; Fri, 9 Sep 2005 19:21:19 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BBB4263B300; Fri, 9 Sep 2005 23:21:18 +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 6BE6D63B18D for ; Fri, 9 Sep 2005 23:21:17 +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 j89NLG2B025584 for ; Fri, 9 Sep 2005 16:21:17 -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 j89NLGUj007657; Fri, 9 Sep 2005 19:21:16 -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 j89NLGqh019960; Fri, 9 Sep 2005 19:21:16 -0400 (EDT) Subject: [Fwd: Final writeup for Experiment of early Copy-editing of WG drafts] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1126308075.17794.366.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 19:21:16 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit -----Forwarded Message----- From: "Wijnen, Bert (Bert)" To: Jon Bright , Bill Sommerfeld Cc: Russ Housley (E-mail) Subject: Final writeup for Experiment of early Copy-editing of WG drafts Date: Fri, 09 Sep 2005 23:01:04 +0200 FYI, here is the final write-up of the experiment Bert ----------- Experiment: early copy-editing of WG documents by RFC-Editor Time: September 20005 - November 2005 Objectives: Improve document quality early on Experiment to perform as much of the editorial work as possible early in the process, e.g., before working group last call. This note describes a very limited initial experiment that should begin to sort out the issues. We can then decide whether further experimentation is warranted. Expected impact: - positive impact on WG Last Call, AD review, IETF Last Call and IESG review. This is expected because of clearer/better text early on. - less copy-editing, so faster process after IESG approval. This hopefully reduces the time between IESG approval and RFC publication. - Reduction of time spend in status AUTH48. This is expected because there should be less changes (if any) between the approved text and the rfc-to-be-published. NOTE: we must realize that this initial and limited experiment (with only a small set of testcases) cannot be used to draw general conclusions w.r.t. to any possible future large scale application of the process followed in this experiment. They can just be a small first set of datapoints to help us focus on where we can try to improve our process. Approach: - co-operation between I-D authors/editors, WG chairs, ADs and RFC-Editor in order to make this work. The team of people involved in this experiement are all expected to contribute to a report to describe how it went and what we measered in terms of positive (or negative) results/impacts. The AD and WG chairs already work together in the PROTO-TEAM approach, and this can continue for this experiement too. - Select 3 to 5 documents just before WG Last Call. ADs select them with their WG chairs, and channel them through Bert Wijnen so as to try and stick to a max of 5 and to try and not have them show up at RFC-Editor all at the same time. - Such documents (for this first experiment) should be in (valid) xml source that generated the I-D to be copy-edited. This experiment is being limited to xml2rfc files for simplicity. Possibly in later experiments we can do other source files or maybe nroff files, but not in this initial experiment. - Selected document checked into a source control system before copy-editing starts (by Bert Wijnen) - RFC-Editor to make copy-editing changes to the xml source. - RFC-Editor copy-editing is expected to take no longer than 1 week (This is currently only commited for the 3-5 documents to be selected for the test, and any follow up experiments or changed process will need to evaluate and decide/negotiate for this timing). - RFC-Editor will make changes that are clearly typos, or bad grammar and such. - If RFC-Editor may go into a discussion with the author/editor to get some clarifications or to discuss suggested text (by RFC-Editor). However, this is not intended to be a long iterative process. If RFC-Editor and author/editor cannot agree quickly, then RFC-Editor just adds the new proposed text with tags around it to indicate what they want to change. For example it could look like: [rfc-editor copy-editor suggests to replace] ... old text.... [rfc-editor copy-editor with] ... new text.... [rfc-editor copy-editor end replacement text] The reasoning is that we want this copy-editing to not take up more than 1 week elapsed time. The WG is then responsible to sort this out by accepting the replacement or substituting clear, unambiguous text. - When RFC-editor is done, they send the updated .xml source to Bert Wijnen. He will check it into the source control system before handing it back to author/wg. - Author/editor generates a new revision of the I-D and sends it to internet-drafts@ietf.org who publishes (normal process). A diff file will also be generated and be made available to the WG, so they can easily see the changes if they want to. - WG Last Call is to happen right after copy-editing is complete (the previous few steps). - The WG and also the authors/editors review the copy-edited document and have the right to undo changes made by the rfc-editor. All this happens during the normal 2-week WG Last Call. The WG chairs should be involved and agree when: - copy-edited text is to be undone. - suggested replacement copy-editor text is to be selected or discarded The RFC-Editor/copy-editor is not expected to be consulted for any of this WG review/change process (an occasional clarifying question is OK, but we should not end up in negotiations about the text at this time). - After WG Last Call completes and WG reaches consensus on the document, the WG submits the final I-D for AD review and processing. The xml source file of this version (if it is changed as a result of WG Last Call) is again checked into the source control system, so that easy comparisons can be made. - Document further follows normal process. When the IESG approved document is complete, we again check the xml source file into the source code control system. - RFC-editor, when document is ready to be EDITED for RFC-publication checks the changes/diffs made since they did the copy-edit run. If no changes were made, doc is ready for publication; i.e. no more extra copy-editing. If doc was changed, only copy-editing takes place in places where the changes were made. Any such changes are made in the xml source file. - The final xml-source file (from which RFC-to-be gets generated) will also be checked into the source code control system. Note: the idea is that the source xml file will have all the latest copy-edited text, so that we can run diffs to see what was changed at the end of the process, so we can analyze the results of the experiment more easily). Note: this last step is conditional pending fixes to xml2rfc to ensure that it can indeed generate the final RFC-text. - RFC is published Note: the idea of checking the files into a source code control system (i'd like to see one either at rfc-editor or on ietf system or maybe on a system controlled by the tools team) is that we can later more easily analyze what kind of changes were made between the various steps. Measurements: - RFC-Editor/copy-editor keeps track of time spend on initial copy-editing pass (both elapsed and person-hours) - RFC-Editor keeps track of time and changes when doc comes in normal RFC-Editor queue - RFC-Editor keeps track of number of issues that did not get resolved in exchanges with author/editors during early copy-editing stage. - RFC-Editor keeps track of AUTH48 progress - WG chairs keep track of: - how many changes were accepted without discussion - how many changes were accepted after discussion - how many changes were discarded (and a log why) - how many suggested text replacements were accepted; same split (with, without discussion and discarded) - evaluate if document indeed improved in readability (we know this is subjective, but yet may be helpful) - collects all the information at the end and makes a report (maybe we should have a template) - AD (with Bert Wijnen) keeps track of - elapsed times for various steps - ensures proper checkin into source code - manages the process, i.e. hand doc from WG to RFC-Editor, back to WG and further processing - collects all the information at the end and makes a report (maybe we should have a template) Maybe some of thses measurements can be automated or done by tools. Tools team, any help you can give? We understand that between now and Vancouver we can probably only get the first steps of the process, namely, have the RFC-Editor do the copy-edit run, have the WG do WG Last Call, and have the AD process the document through IETF Last Call and IESG approval. The later steps and data collection will happen after Vancopuver. But we should have some data about the initial steps in Vancouver. Based on that info we can decide if we need to do more experimentation and if so if we need to change the process/measurements. Bert From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 09 19:25:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDsFR-0002V0-Pi for secsh-archive@megatron.ietf.org; Fri, 09 Sep 2005 19:25: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 TAA22290 for ; Fri, 9 Sep 2005 19:25:30 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A280063B2B7; Fri, 9 Sep 2005 23:25:30 +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 177D063B18D for ; Fri, 9 Sep 2005 23:25:30 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j89NPT2B027111 for ; Fri, 9 Sep 2005 16:25:29 -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 j89NPTWB017990; Fri, 9 Sep 2005 19:25:29 -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 j89NPSma019971; Fri, 9 Sep 2005 19:25:29 -0400 (EDT) Subject: any reason to meet in Vancouver (IETF64)? From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1126308328.17794.375.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Fri, 09 Sep 2005 19:25:28 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit IETF64 will be in Vancouver, BC, Canada, November 6-11 November 2005 We could meet there if we're likely to get a critical mass of attendees. Possible topics which could benefit from face-to-face discussion: - finishing sftp/filexfer Specifically, locking people who think it's too complex already in the same room with people who want to add more hair until they hash out a consensus. - finishing the x.509 draft Perhaps through hallway discussions with the pkix crowd? - figuring if we want to put energy into advancement to Draft Standard, and, if so, figure out how we'll collect the interop reports required. Thoughts, anyone? - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 10 10:10:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE641-00067Z-Dr for secsh-archive@megatron.ietf.org; Sat, 10 Sep 2005 10:10: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 KAA03869 for ; Sat, 10 Sep 2005 10:10:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E0AFE63B12A; Sat, 10 Sep 2005 14:10:25 +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 3C4D263B112 for ; Sat, 10 Sep 2005 14:10:25 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1EE63f-0003jn-00; Sat, 10 Sep 2005 15:10:19 +0100 From: Ben Harris To: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: <1126296848.17794.221.camel@thunk> References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Sat, 10 Sep 2005 15:10:19 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1126296848.17794.221.camel@thunk> you write: > At this time it appears likely that a future > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. I like this. It makes the future direction clear without committing us to a particular route, and it doesn't introduce awkward concepts like "implementing newmodes". -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 10 12:48:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE8WM-0000ye-It for secsh-archive@megatron.ietf.org; Sat, 10 Sep 2005 12:48: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 MAA09371 for ; Sat, 10 Sep 2005 12:47:55 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id ACAE563B1B7; Sat, 10 Sep 2005 16:47:50 +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 900B663B151 for ; Sat, 10 Sep 2005 16:47:49 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA25393; Sat, 10 Sep 2005 12:47:44 -0400 (EDT) From: der Mouse Message-Id: <200509101647.MAA25393@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: Sat, 10 Sep 2005 12:46:18 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 In-Reply-To: References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit [Proposed wording for newmodes] >> At this time it appears likely that a future specification will >> promote aes128-ctr to be REQUIRED; implementation of this >> algorithm is very strongly encouraged. [Ben Harris] > I like this. It makes the future direction clear without committing > us to a particular route, and it doesn't introduce awkward concepts > like "implementing newmodes". "What he said." /~\ 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 Sep 10 20:50:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEG2b-0002mN-23 for secsh-archive@megatron.ietf.org; Sat, 10 Sep 2005 20:50: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 UAA26819 for ; Sat, 10 Sep 2005 20:49:40 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D415563B1BB; Sun, 11 Sep 2005 00:49:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from fork.recoil.org (fork.recoil.org [194.70.3.132]) by mail.netbsd.org (Postfix) with SMTP id 9977663B110 for ; Sun, 11 Sep 2005 00:49:32 +0000 (UTC) Received: (qmail 4313 invoked from network); 11 Sep 2005 00:42:50 -0000 Received: from localhost (HELO ???@IPv6:::1?) (127.0.0.1) by fork.recoil.org with SMTP; 11 Sep 2005 00:42:50 -0000 In-Reply-To: <1126296848.17794.221.camel@thunk> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: Russ Housley , Sam Hartman , ietf-ssh@NetBSD.org Content-Transfer-Encoding: 7bit From: Anil Madhavapeddy Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Date: Sun, 11 Sep 2005 01:42:45 +0100 To: Bill Sommerfeld X-Mailer: Apple Mail (2.734) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On 9 Sep 2005, at 21:14, Bill Sommerfeld wrote: > > How about we drop "revision of this", leaving: > > At this time it appears likely that a future > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. Yes, I like this suggestion best. Anil From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 11 18:48:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEacY-0008Fh-Dn for secsh-archive@megatron.ietf.org; Sun, 11 Sep 2005 18:48:52 -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 SAA27693 for ; Sun, 11 Sep 2005 18:48:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 47AC963B1DA; Sun, 11 Sep 2005 22:47:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from guinness.cs.stevens.edu (guinness.cs.stevens-tech.edu [155.246.89.8]) by mail.netbsd.org (Postfix) with ESMTP id 9F4D963B1D5 for ; Sun, 11 Sep 2005 22:47:37 +0000 (UTC) Received: from murky.cs.stevens.edu (murky.cs.stevens-tech.edu [155.246.89.22]) by guinness.cs.stevens.edu (Postfix) with ESMTP id EC00E14164C; Sun, 11 Sep 2005 18:47:36 -0400 (EDT) Received: by murky.cs.stevens.edu (Postfix, from userid 3330) id AD723EC620; Sun, 11 Sep 2005 18:47:36 -0400 (EDT) Date: Sun, 11 Sep 2005 18:47:36 -0400 From: Thor Simon To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 Message-ID: <20050911224736.GA1009@cs.stevens.edu> References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Sep 10, 2005 at 03:10:19PM +0100, Ben Harris wrote: > In article <1126296848.17794.221.camel@thunk> you write: > > At this time it appears likely that a future > > specification will promote aes128-ctr to be REQUIRED; > > implementation of this algorithm is very strongly encouraged. > > I like this. It makes the future direction clear without committing us to a > particular route, and it doesn't introduce awkward concepts like > "implementing newmodes". I agree. Thor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 11 22:03:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEdfM-0003Vh-CN for secsh-archive@megatron.ietf.org; Sun, 11 Sep 2005 22:03: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 WAA05159 for ; Sun, 11 Sep 2005 22:03:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 8329063B128; Mon, 12 Sep 2005 02:03:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by mail.netbsd.org (Postfix) with ESMTP id 9206863B113 for ; Mon, 12 Sep 2005 02:03:22 +0000 (UTC) Received: from toshiba (pcp04095760pcs.mtsano01.ga.comcast.net[68.47.47.93]) by comcast.net (sccrmhc13) with SMTP id <20050912020320013004sejte>; Mon, 12 Sep 2005 02:03:21 +0000 Message-ID: <002701c5b73e$27748450$6401a8c0@TOSHIBA> From: "Claudio Robles" To: References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <20050911224736.GA1009@cs.stevens.edu> Subject: SCP under SSH2 Date: Sun, 11 Sep 2005 22:03:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Not sure if I can ask this question here.... It is possible to use SCP under SSH2? and if this is the case, where can I find the SCP protocol? I understand that the protocol is in fact, RCP protocol, but also I have not being able to find it.... I have read all the drafts and found no mention to SCP. I do understand that it was kind of replaced by SFTP, but I still imagine that it is possible to do a transfer with SCP, mainly because it does not require much from the client, just one command. Thanks in advance. Claudio Robles From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 04:33:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjkN-0003Ax-Jw for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 04:33:06 -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 EAA03764 for ; Mon, 12 Sep 2005 04:33:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AD54963B292; Mon, 12 Sep 2005 08:32:58 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id DB37163B102 for ; Mon, 12 Sep 2005 08:32:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 773E53C10; Mon, 12 Sep 2005 10:31:36 +0200 (CEST) Message-ID: <43253CE4.7030707@siliconcircus.com> Date: Mon, 12 Sep 2005 10:31:32 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld CC: Russ Housley , Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> In-Reply-To: <1126296848.17794.221.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: > > How about we drop "revision of this", leaving: > > At this time it appears likely that a future > specification will promote aes128-ctr to be REQUIRED; > implementation of this algorithm is very strongly encouraged. Works for me. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 04:38:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEjpt-0003no-PF for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 04:38:47 -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 EAA04102 for ; Mon, 12 Sep 2005 04:38:35 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1DC9163B292; Mon, 12 Sep 2005 08:38:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 6999A63B102 for ; Mon, 12 Sep 2005 08:38:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 9CB073D44; Mon, 12 Sep 2005 10:37:18 +0200 (CEST) Message-ID: <43253E3A.8080706@siliconcircus.com> Date: Mon, 12 Sep 2005 10:37:14 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Robles CC: ietf-ssh@NetBSD.org Subject: Re: SCP under SSH2 References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <20050911224736.GA1009@cs.stevens.edu> <002701c5b73e$27748450$6401a8c0@TOSHIBA> In-Reply-To: <002701c5b73e$27748450$6401a8c0@TOSHIBA> 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 Claudio Robles wrote: > > It is possible to use SCP under SSH2? Yes. > and if this is the case, where can I find the SCP protocol? You pretty much need to read the source for scp. > I have read all the drafts and found no mention to SCP. The protocol never got standardised (at least, never got standardised as scp - and I don't believe it ever got standardised as rcp either). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 05:11:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEkLH-0000uv-Bz for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 05:11: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 FAA05751 for ; Mon, 12 Sep 2005 05:10:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 05FD163B2A3; Mon, 12 Sep 2005 09:10:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id 4657063B102 for ; Mon, 12 Sep 2005 09:10:56 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 4747A3408A; Mon, 12 Sep 2005 21:10:55 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09698-29; Mon, 12 Sep 2005 21:10:55 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id E22AD3403C; Mon, 12 Sep 2005 21:10:54 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id ABD5237749; Mon, 12 Sep 2005 21:10:54 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EEkL7-0000TJ-00; Mon, 12 Sep 2005 21:11:01 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: crobles7@comcast.net, jon@siliconcircus.com Subject: Re: SCP under SSH2 Cc: ietf-ssh@NetBSD.org In-Reply-To: <43253E3A.8080706@siliconcircus.com> Message-Id: Date: Mon, 12 Sep 2005 21:11:01 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright >Claudio Robles wrote: >> I have read all the drafts and found no mention to SCP. > >The protocol never got standardised (at least, never got standardised as scp >- and I don't believe it ever got standardised as rcp either). Yup, you need to find someone else's source and read it to reverse-engineer the protocol details. However before doing that, two questions: 1. Why do you need to run scp under SSHv2? 2. If there's really some need for this, why not tunnel rcp over SSH? Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 11:01:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEpoc-0005PY-VQ for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 11:01:51 -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 LAA23873 for ; Mon, 12 Sep 2005 11:01:48 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6573763B295; Mon, 12 Sep 2005 15:01:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 1C56763B109 for ; Mon, 12 Sep 2005 15:01:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 2706378B34; Mon, 12 Sep 2005 17:00:24 +0200 (CEST) Message-ID: <43259824.6080707@siliconcircus.com> Date: Mon, 12 Sep 2005 17:00:52 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: > > Lines 242-244: > The version packet, as well as all requests and responses described > in Section 3 are a description of the 'name' field and the data part > of the packet. > s/3/3,/ Done. > Line 304: > SHOULD be sent. Note that normally, status messages are only sent by > s/only sent by/sent by only/ I've not done this one - the result struck me as more awkward than what we have. Instead, I've made it "Note that normally, status messages are only sent by the server (in response to requests from the client)." I presume this achieves the clarification you were after... > Line 367: > SSH_PUBLICKEY_ACCESS_DENIED > s/$/./ Done. > find it as clear as I do; you might want to reword it. Suggestion: > SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a > mandatory attribute, mere storage of the attribute is not > sufficient; the server must understand and implement the intent of > the attribute. I've gone with: "For the purposes of a mandatory attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute." -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 13:03:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErht-00070m-AB for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 13:03:07 -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 NAA02290 for ; Mon, 12 Sep 2005 13:02:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9E50E63B3B9; Mon, 12 Sep 2005 17:02:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from guinness.cs.stevens.edu (guinness.cs.stevens-tech.edu [155.246.89.8]) by mail.netbsd.org (Postfix) with ESMTP id E19B063B1D7 for ; Mon, 12 Sep 2005 17:02:43 +0000 (UTC) Received: from murky.cs.stevens.edu (murky.cs.stevens-tech.edu [155.246.89.22]) by guinness.cs.stevens.edu (Postfix) with ESMTP id 1AB25141659; Mon, 12 Sep 2005 13:02:38 -0400 (EDT) Received: by murky.cs.stevens.edu (Postfix, from userid 3330) id CE251EC83A; Mon, 12 Sep 2005 13:02:32 -0400 (EDT) Date: Mon, 12 Sep 2005 13:02:32 -0400 From: Thor Simon To: Claudio Robles Cc: ietf-ssh@NetBSD.org Subject: Re: SCP under SSH2 Message-ID: <20050912170232.GA24060@cs.stevens.edu> References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <20050911224736.GA1009@cs.stevens.edu> <002701c5b73e$27748450$6401a8c0@TOSHIBA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002701c5b73e$27748450$6401a8c0@TOSHIBA> User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sun, Sep 11, 2005 at 10:03:22PM -0400, Claudio Robles wrote: > Not sure if I can ask this question here.... > > It is possible to use SCP under SSH2? and if this is the case, where can I > find the SCP protocol? I understand that the protocol is in fact, RCP > protocol, but also I have not being able to find it.... Unfortuantely, one of the longest-overdue documents from anyone to anyone in this working group is my often-promised informational RFC documenting the rcp protocol. It's not hard to do, it's just mechanical work with the rcp source code (the canonical version is the one in 4.4BSD-Lite2 tree -- what one really wants is to describe that, then document the very slight differences in behaviour of the other 4.3-derived code out there in the wild). If you are doing a from-scratch implementation and want to produce such an RFC, please don't allow my failure to ever get enough round tuits to stop you. Thor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 13:07:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EErmT-0008BI-FU for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 13:07:47 -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 NAA02559 for ; Mon, 12 Sep 2005 13:07:34 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 34BA963B3C8; Mon, 12 Sep 2005 17:06:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from guinness.cs.stevens.edu (guinness.cs.stevens-tech.edu [155.246.89.8]) by mail.netbsd.org (Postfix) with ESMTP id 4022D63B3C6 for ; Mon, 12 Sep 2005 17:06:56 +0000 (UTC) Received: from murky.cs.stevens.edu (murky.cs.stevens-tech.edu [155.246.89.22]) by guinness.cs.stevens.edu (Postfix) with ESMTP id 7EE06141659; Mon, 12 Sep 2005 13:06:55 -0400 (EDT) Received: by murky.cs.stevens.edu (Postfix, from userid 3330) id 416FCEC83A; Mon, 12 Sep 2005 13:06:55 -0400 (EDT) Date: Mon, 12 Sep 2005 13:06:55 -0400 From: Thor Simon To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: SCP under SSH2 Message-ID: <20050912170655.GB24060@cs.stevens.edu> References: <43253E3A.8080706@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Sep 12, 2005 at 09:11:01PM +1200, Peter Gutmann wrote: > Jon Bright > >Claudio Robles wrote: > >> I have read all the drafts and found no mention to SCP. > > > >The protocol never got standardised (at least, never got standardised as scp > >- and I don't believe it ever got standardised as rcp either). > > Yup, you need to find someone else's source and read it to reverse-engineer > the protocol details. However before doing that, two questions: > > 1. Why do you need to run scp under SSHv2? > 2. If there's really some need for this, why not tunnel rcp over SSH? FreSSH did #2. It worked fine. Whether you call that "running scp under SSHvWhatever" is largely immaterial -- after all, with the command line arguments bashed appropriately, 4.4BSD 'rcp' will talk perfectly happily to OpenSSH 'scp'; the protocol is really the same. There are legitimate reasons to not implement sftp -- it's a pig (let us leave aside whether it is a necessary pig or a useful pig; it is still a pig). There's nothing inherently wrong with rcp except that you have to be careful about the server-side globbing -- but a small embedded implementation would be entirely free to omit globbing entirely, and then the problem disappears right along with it. It's unfortunate that rcp is not documented -- and largely my fault, since I said I'd do it one of the first times this came up in the WG but never produced the document. Thor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 13:23:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEs1v-00024x-5F for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 13:23: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 NAA03241 for ; Mon, 12 Sep 2005 13:23:32 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C130963B3D9; Mon, 12 Sep 2005 17:23:31 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 24AA563B3D7 for ; Mon, 12 Sep 2005 17:23:31 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j8CHNR1L023823; Mon, 12 Sep 2005 11:23:27 -0600 (MDT) 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 j8CHNQWB015162; Mon, 12 Sep 2005 13:23:26 -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 j8CHNPoM000625; Mon, 12 Sep 2005 13:23:25 -0400 (EDT) Subject: Re: SCP under SSH2 From: Bill Sommerfeld To: Thor Simon Cc: Peter Gutmann , ietf-ssh@NetBSD.org In-Reply-To: <20050912170655.GB24060@cs.stevens.edu> References: <43253E3A.8080706@siliconcircus.com> <20050912170655.GB24060@cs.stevens.edu> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1126545804.395.2.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 12 Sep 2005 13:23:25 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-09-12 at 13:06, Thor Simon wrote: > It's unfortunate that rcp is not documented -- and largely my fault, > since I said I'd do it one of the first times this came up in the WG > but never produced the document. It's not too late to correct this. (Even if this WG is shut down for being done, someone could still send in an Informational individual submission documenting the scp and rcp protocol). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 13:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsWZ-0007fj-KZ for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 13:55: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 NAA04732 for ; Mon, 12 Sep 2005 13:55:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BC98763B3E2; Mon, 12 Sep 2005 17:55: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 1434B63B3E1 for ; Mon, 12 Sep 2005 17:55:11 +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 j8CHt52B028420; Mon, 12 Sep 2005 10:55:05 -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 j8CHt5Uj023337; Mon, 12 Sep 2005 13:55:05 -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 j8CHt40J000783; Mon, 12 Sep 2005 13:55:04 -0400 (EDT) Subject: Re: Your DISCUSS on draft-ietf-secsh-newmodes-05 From: Bill Sommerfeld To: Russ Housley Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> References: <1125337411.453.8.camel@thunk> <1125610205.9587.81.camel@thunk> <6.2.1.2.2.20050906135509.06ae0520@mail.binhost.com> <1126031842.29672.33.camel@thunk> <431E8F50.4050403@siliconcircus.com> <9EE95C3FAFFF2EFB50E06BDC@sirius.fac.cs.cmu.edu> <431FD875.4050809@siliconcircus.com> <200509080644.CAA19912@Sparkle.Rodents.Montreal.QC.CA> <431FE884.6060503@siliconcircus.com> <200509080826.EAA20127@Sparkle.Rodents.Montreal.QC.CA> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <6.2.1.2.2.20050909151930.04670610@mail.binhost.com> <1126295837.17794.218.camel@thunk> <6.2.1.2.2.20050909160853.07d9d0e0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <6.2.1.2.2.20050909162053.082203e0@mail.binhost.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1126547703.395.13.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Mon, 12 Sep 2005 13:55:04 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ok, based on the apparent outbreak of smooth consensus, we should move forward with my revised edit, namely, to extend the paragraph reading: The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. with: At this time it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged. I assume this is something that can be dealt with using an RFC Editor note, right? Do you need anything else from the WG before moving forward? - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 14:02:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsdL-0000Cs-Su for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 14:02: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 OAA05033 for ; Mon, 12 Sep 2005 14:02:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A860163B3DD; Mon, 12 Sep 2005 18:02: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 6D1F263B3EE for ; Mon, 12 Sep 2005 18:02:17 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA00418; Mon, 12 Sep 2005 14:02:12 -0400 (EDT) From: der Mouse Message-Id: <200509121802.OAA00418@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: Mon, 12 Sep 2005 13:49:37 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt In-Reply-To: <43259824.6080707@siliconcircus.com> References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> <43259824.6080707@siliconcircus.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Line 304: >> SHOULD be sent. Note that normally, status messages are only sent by >> s/only sent by/sent by only/ > I've not done this one - the result struck me as more awkward than > what we have. Instead, I've made it "Note that normally, status > messages are only sent by the server (in response to requests from > the client)." I presume this achieves the clarification you were > after... It still suffers from the problem: the "only" is attached to the wrong thing. See http://webster.commnet.edu/grammar/modifiers.htm for a short discussion of the issue. If you really think that this is clear enough even with "only" in the wrong place, well, go ahead. I just point out things I think need fixing. You don't have to agree with me about all (or even any) of them; it's your document, not mine. :) >> Suggestion: >> SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a >> mandatory attribute, mere storage of the attribute is not >> sufficient; the server must understand and implement the intent of >> the attribute. > "For the purposes of a mandatory attribute, mere storage of the > attribute is not sufficient -- rather, the server must understand and > implement the intent of the attribute." Fine by me. /~\ 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 Mon Sep 12 14:13:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsnf-0002Oi-7K for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 14:13: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 OAA05487 for ; Mon, 12 Sep 2005 14:13:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 4D6C863B3E1; Mon, 12 Sep 2005 18:12:58 +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 684E663B3EE for ; Mon, 12 Sep 2005 18:12:57 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa26468; 12 Sep 2005 14:12 EDT Received: from [192.168.0.100] (c-67-165-91-20.hsd1.pa.comcast.net [67.165.91.20]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j8CIChhT021357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 12 Sep 2005 14:12:45 -0400 (EDT) Date: Mon, 12 Sep 2005 14:12:43 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt Message-ID: In-Reply-To: <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> <43259824.6080707@siliconcircus.com> <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01NMNBU54rtseADrnUZ0Fxwss1eH6797qhOG+4akM=; 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, September 12, 2005 13:49:37 -0400 der Mouse wrote: >>> Line 304: >>> SHOULD be sent. Note that normally, status messages are only sent by >>> s/only sent by/sent by only/ >> I've not done this one - the result struck me as more awkward than >> what we have. Instead, I've made it "Note that normally, status >> messages are only sent by the server (in response to requests from >> the client)." I presume this achieves the clarification you were >> after... > > It still suffers from the problem: the "only" is attached to the wrong > thing. See http://webster.commnet.edu/grammar/modifiers.htm for a > short discussion of the issue. If you really think that this is clear > enough even with "only" in the wrong place, well, go ahead. I just > point out things I think need fixing. You don't have to agree with me > about all (or even any) of them; it's your document, not mine. :) Indeed it does. However, I believe another permutation solves the problem without sounding quite as awkward. If you say 'sent only by', then 'only' attaches to the prepositional phrase "by the server". OTOH, it could be argued that if status messages are sent only by the server, and the server never talks to itself, then they are also only sent by the server, and never received by it. :-) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 14:33:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEt7L-000660-G6 for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 14:33: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 OAA06325 for ; Mon, 12 Sep 2005 14:33:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AF37263B3FE; Mon, 12 Sep 2005 18:33:11 +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 A258963B3FC for ; Mon, 12 Sep 2005 18:33:10 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA00724; Mon, 12 Sep 2005 14:33:09 -0400 (EDT) From: der Mouse Message-Id: <200509121833.OAA00724@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: Mon, 12 Sep 2005 14:25:19 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt In-Reply-To: References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> <43259824.6080707@siliconcircus.com> <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit [warning: linguistic logic-chopping ahead. Executive summary: "sent only by" is OK with me.] >> It still suffers from the problem: the "only" is attached to the >> wrong thing. [...] > Indeed it does. However, I believe another permutation solves the > problem without sounding quite as awkward. If you say 'sent only > by', then 'only' attaches to the prepositional phrase "by the > server". Mmm, that's true. When I get into misplaced-modifier mode, I start reading such things far more strictly, which leads to interpreting "sent only by the server" as "sent only by, not below, on, without, or any other preposition, the server". But I think you're right, that without special marking, the whole prepositional phrase is what the modifier will attach to; I'd write "sent only *by* the server" (and emphasize correspondingly if speaking) if I really meant to attach it to the preposition itself. > OTOH, it could be argued that if status messages are sent only by the > server, and the server never talks to itself, then they are also only > sent by the server, and never received by it. :-) Yes - but are they generated by it? Logged by it? Soldered by it? Lubricated by it? There are lots of other verbs which could go there, some of which (unlike my latter two examples :-) aren't excluded by semantic considerations. /~\ 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 Mon Sep 12 18:06:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEwRC-0004xo-I4 for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 18:06:06 -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 SAA04723 for ; Mon, 12 Sep 2005 18:05:58 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 6A43D63B211; Mon, 12 Sep 2005 22:05:52 +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 BB96F63B238 for ; Mon, 12 Sep 2005 22:05:51 +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 7876837; Mon, 12 Sep 2005 16:05:50 -0600 Message-ID: <4325FDDC.6070904@vandyke.com> Date: Mon, 12 Sep 2005 16:14:52 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: any reason to meet in Vancouver (IETF64)? References: <1126308328.17794.375.camel@thunk> In-Reply-To: <1126308328.17794.375.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: > IETF64 will be in Vancouver, BC, Canada, November 6-11 November 2005 > > We could meet there if we're likely to get a critical mass of attendees. > > Possible topics which could benefit from face-to-face discussion: > - finishing sftp/filexfer > > Specifically, locking people who think it's too complex already in the > same room with people who want to add more hair until they hash out a > consensus. > > - finishing the x.509 draft > > Perhaps through hallway discussions with the pkix crowd? Well, I'm on tap for both those drafts... I'll be there if we want to meet... and if we can get a group of people together that: a. Have read the drafts. b. Are willing to sit down with me and work on text And for the x.509 draft: c. Are an PKIX expert :-) I think we can get a lot done. > - figuring if we want to put energy into advancement to Draft Standard, > and, if so, figure out how we'll collect the interop reports required. > > Thoughts, anyone? I'm definitely interested in seeing this move forward. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 19:33:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExnc-0007OA-IC for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 19:33:20 -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 TAA08714 for ; Mon, 12 Sep 2005 19:33:07 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id A2BA163B2F4; Mon, 12 Sep 2005 23:33:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mail.netbsd.org (Postfix) with ESMTP id F329163B171 for ; Mon, 12 Sep 2005 23:32:59 +0000 (UTC) Received: from martynakaczor5 (bgt244.neoplus.adsl.tpnet.pl [83.28.83.244]) by poczta.o2.pl (Postfix) with SMTP id 8C94A7480B8 for ; Tue, 13 Sep 2005 01:32:58 +0200 (CEST) Reply-To: "Martin" From: "Martin" To: Subject: Only you Date: Tue, 13 Sep 2005 01:33:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Message-Id: <20050912233258.8C94A7480B8@poczta.o2.pl> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This is for you http://adsfree.50megs.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 20:02:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEyFL-000540-TY for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 20:02: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 UAA09497 for ; Mon, 12 Sep 2005 20:01:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 9C73F63B34D; Tue, 13 Sep 2005 00:01:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [63.240.76.22]) by mail.netbsd.org (Postfix) with ESMTP id BA64463B171 for ; Tue, 13 Sep 2005 00:01:54 +0000 (UTC) Received: from toshiba (pcp04095760pcs.mtsano01.ga.comcast.net[68.47.47.93]) by comcast.net (sccrmhc12) with SMTP id <20050913000153012002gr89e>; Tue, 13 Sep 2005 00:01:53 +0000 Message-ID: <00a001c5b7f6$5b092150$6401a8c0@TOSHIBA> From: "Claudio Robles" To: References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <20050911224736.GA1009@cs.stevens.edu> <002701c5b73e$27748450$6401a8c0@TOSHIBA> <43253E3A.8080706@siliconcircus.com> Subject: Re: SCP under SSH2 Date: Mon, 12 Sep 2005 20:01:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Thanks a lot for all the answers, specially Sara. I do see that SCP could be used and take part of the market, since SFTP is a little big and continue growing. Anybody knows of SFTP implementation (client or server) newer than version 4? I will take a look at OpenSSH to understand the details, in particular the time (second from when), modes(octal), and basename. Thanks again. Claudio Robles ----- Original Message ----- From: "Sara Golemon" To: "Claudio Robles" Sent: Monday, September 12, 2005 12:24 AM Subject: Re: SCP under SSH2 >> It is possible to use SCP under SSH2? and if this is the case, where can >> I >> find the SCP protocol? I understand that the protocol is in fact, RCP >> protocol, but also I have not being able to find it.... >> > SCP is done over a "session"/"exec" channel (with the assumption that > the "scp" command will be in the remote path. Check OpenSSH's source > for the specific conversation language. > > Generally for receiving files it's: > exec: "scp -pf /path/to/file" > C: \0 (Literally, send a null byte) > S: T 99999 99999 99999 999999 (mtime.sec mtime.usec atime.sec > atime.usec) > C: \0 > S: C 0999 99999999 SSSSS (mode[octal] filelen basename) > C: \0 > S: XXXXXXXXXXXXXXX (File Data, bytes) > > Sending is the same conversation with roles reversed > exec: "scp -pt /path/to/file" > S: \0 (Literally, send a null byte) > C: T 99999 99999 99999 999999 (mtime.sec mtime.usec atime.sec > atime.usec) > S: \0 > C: C 0999 99999999 SSSSSS (mode[octal] filelen basename) > S: \0 > C: XXXXXXXXXXXXXXX (File Data, bytes) > > In both cases, if the 'p' is ommitted from the options then > mtime/atime is not sent. > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 21:12:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEzLw-00023C-Bc for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 21:12:52 -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 VAA11967 for ; Mon, 12 Sep 2005 21:12:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 961D063B37D; Tue, 13 Sep 2005 01:12:48 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id C6B6B63B37B for ; Tue, 13 Sep 2005 01:12:47 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 20A6517E655; Tue, 13 Sep 2005 11:12:46 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 1E98B17E625; Tue, 13 Sep 2005 11:12:46 +1000 (EST) Date: Tue, 13 Sep 2005 11:12:45 +1000 (EST) From: Damien Miller To: Thor Simon cc: ietf-ssh@NetBSD.org Subject: Re: SCP under SSH2 In-Reply-To: <20050912170655.GB24060@cs.stevens.edu> Message-ID: References: <43253E3A.8080706@siliconcircus.com> <20050912170655.GB24060@cs.stevens.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 12 Sep 2005, Thor Simon wrote: > There are legitimate reasons to not implement sftp -- it's a pig (let us > leave aside whether it is a necessary pig or a useful pig; it is still a > pig). I would say that the current drafts of sftp tend to the porcine, but the older ones are quite lean. For example OpenSSH's sftp-server, which implements v.3 of the protocol, is under 30kb, and it could be shrunk if the buffer API and support code common with the rest of the implementation was linked into a shared library. Actually, OpenSSH's scp binary is slightly larger: [djm@fuyu djm]$ size /usr/libexec/sftp-server /usr/bin/scp text data bss dec hex 23708 684 2436 26828 68cc /usr/libexec/sftp-server 27750 752 896 29398 72d6 /usr/bin/scp -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 12 22:15:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF0Ie-0004uP-Nh for secsh-archive@megatron.ietf.org; Mon, 12 Sep 2005 22:13: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 WAA14920 for ; Mon, 12 Sep 2005 22:13:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CE7A663B38D; Tue, 13 Sep 2005 02:13:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mail.netbsd.org (Postfix) with ESMTP id 1146F63B38B for ; Tue, 13 Sep 2005 02:13:10 +0000 (UTC) Received: from toshiba (pcp04095760pcs.mtsano01.ga.comcast.net[68.47.47.93]) by comcast.net (sccrmhc12) with SMTP id <2005091302130901200n2d90e>; Tue, 13 Sep 2005 02:13:10 +0000 Message-ID: <002201c5b808$b19be400$6401a8c0@TOSHIBA> From: "Claudio Robles" To: References: <1125337411.453.8.camel@thunk> <43202AE8.7090208@siliconcircus.com> <6.2.1.2.2.20050909144043.07c2aeb0@mail.binhost.com> <1126296848.17794.221.camel@thunk> <20050911224736.GA1009@cs.stevens.edu> <002701c5b73e$27748450$6401a8c0@TOSHIBA> <43253E3A.8080706@siliconcircus.com> <00a001c5b7f6$5b092150$6401a8c0@TOSHIBA> <3cf130880509121854299dd6ad@mail.gmail.com> Subject: Re: SCP under SSH2 Date: Mon, 12 Sep 2005 22:13:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sara, Yup, I was looking at the openssh source code and figure it out. Being a little more specific, it seems that there is no blank space after the first letter, in "Tmtime.sec mtime.usec atime.sec, atime.usec\n", and in "Cpermission size name\n". Question, how do you transfer a file to/from an specific folder? Thanks again. Claudio ----- Original Message ----- From: "Sara Golemon" To: "Claudio Robles" Cc: Sent: Monday, September 12, 2005 9:54 PM Subject: Re: SCP under SSH2 >> I will take a look at OpenSSH to understand the details, in particular >> the >> time (second from when), modes(octal), and basename. >> > time: From the unix epoch (Jan 1, 1970 00:00:00 +0000) > modes: What mode the received file has, or sent file should have (i.e. > -rwxrwxrwx => 0777) > basename: basename(/foo/bar/baz.ext) == baz.ext > > -Sara > > P.S. - Nothing wrong with echoing to list, it's what I meant to do but > hit the wrong button. > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 13 05:25:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF723-0001Np-3N for secsh-archive@megatron.ietf.org; Tue, 13 Sep 2005 05:25: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 FAA11709 for ; Tue, 13 Sep 2005 05:24:39 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 1A5B563B3D4; Tue, 13 Sep 2005 09:24:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 3B69263B3D2 for ; Tue, 13 Sep 2005 09:24:33 +0000 (UTC) Received: from [172.29.84.18] (unknown [172.29.84.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Damien Miller", Issuer "mindrot.org root CA" (verified OK)) by mail.mindrot.org (Postfix) with ESMTP id D523C17E606; Tue, 13 Sep 2005 19:24:31 +1000 (EST) Message-ID: <43269ACE.7060300@mindrot.org> Date: Tue, 13 Sep 2005 19:24:30 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050801) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: tls@cs.stevens.edu, ietf-ssh@NetBSD.org Subject: Re: SCP under SSH2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Damien Miller writes: > > >>I would say that the current drafts of sftp tend to the porcine, but the >>older ones are quite lean. > > SFTP also exhibits the performance handbrake, whereas scp doesn't. You have > to do quite a bit of work (and the other side has to as well) to avoid > performance penalties. The "handbrake" is only effects naive implementations. BTW "quite a bit of work" for OpenSSH was exactly: 1 files changed, 227 insertions(+), 93 deletions(-) for upload and download pipelining support. It would be less except for the silly requirement of the protocol that the server be allowed to reorder requests on a file handle. Only the client has to implement this, the server doesn't need any extra smarts at all (in fact, you can't even implement them there). -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 13 05:29:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF76q-00027y-BU for secsh-archive@megatron.ietf.org; Tue, 13 Sep 2005 05:29: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 FAA11897 for ; Tue, 13 Sep 2005 05:29:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id B899863B3B4; Tue, 13 Sep 2005 09:29:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by mail.netbsd.org (Postfix) with ESMTP id 08E9563B328 for ; Tue, 13 Sep 2005 09:29:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8708B3413F; Tue, 13 Sep 2005 21:11:49 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20696-18; Tue, 13 Sep 2005 21:11:49 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 404B533E90; Tue, 13 Sep 2005 21:11:48 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 721E33774A; Tue, 13 Sep 2005 21:11:48 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EF6pX-0002Vt-00; Tue, 13 Sep 2005 21:11:55 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: djm@mindrot.org, tls@cs.stevens.edu Subject: Re: SCP under SSH2 Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Tue, 13 Sep 2005 21:11:55 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Damien Miller writes: >I would say that the current drafts of sftp tend to the porcine, but the >older ones are quite lean. SFTP also exhibits the performance handbrake, whereas scp doesn't. You have to do quite a bit of work (and the other side has to as well) to avoid performance penalties. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 13 05:56:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF7WY-0005zP-Qo for secsh-archive@megatron.ietf.org; Tue, 13 Sep 2005 05:56:27 -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 FAA12660 for ; Tue, 13 Sep 2005 05:56:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 08F6B63B3ED; Tue, 13 Sep 2005 09:56:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 463B163B3D2 for ; Tue, 13 Sep 2005 09:56:11 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 4C78386B53; Tue, 13 Sep 2005 11:54:55 +0200 (CEST) Message-ID: <4326A200.6050603@siliconcircus.com> Date: Tue, 13 Sep 2005 11:55:12 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> <43259824.6080707@siliconcircus.com> <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: >>>Line 304: >>> SHOULD be sent. Note that normally, status messages are only sent by >>>s/only sent by/sent by only/ >> >>I've not done this one - the result struck me as more awkward than >>what we have. Instead, I've made it "Note that normally, status >>messages are only sent by the server (in response to requests from >>the client)." I presume this achieves the clarification you were >>after... > > > It still suffers from the problem: the "only" is attached to the wrong > thing. See http://webster.commnet.edu/grammar/modifiers.htm for a I disagree. Maybe I'm wrong, but imho, "only" is modifying the verb, not the server. As such, it complies with the strict interpretation on that page: 'Many careful writers will insist that "only" be placed immediately before the word or phrase it modifies'. In their example, "barely" is indeed modifying "twenty yards" and not "kicked", but I don't think that's the case here. Aside from what the strictest rules of grammar say on the subject, "...are sent by only the server..." sounds.. well.. awful (to my ears). -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 13 06:03:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF7dZ-00072U-KW for secsh-archive@megatron.ietf.org; Tue, 13 Sep 2005 06:03: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 GAA12829 for ; Tue, 13 Sep 2005 06:03:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id BAA8163B3E9; Tue, 13 Sep 2005 10:03:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id BDB2363B3D2 for ; Tue, 13 Sep 2005 10:03:20 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 969F586BC6; Tue, 13 Sep 2005 12:02:04 +0200 (CEST) Message-ID: <4326A3AE.3050907@siliconcircus.com> Date: Tue, 13 Sep 2005 12:02:22 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-04.txt Content-Type: multipart/mixed; boundary="------------080408010802060204050402" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------080408010802060204050402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-04.txt Thanks, -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------080408010802060204050402 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-04.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-04.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: March 17, 2006 B. McClure VanDyke Software J. Bright Silicon Circus September 13, 2005 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-04.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 March 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client Galbraith, et al. Expires March 17, 2006 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem September 2005 software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the Section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 4 2.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 4 2.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5 2.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5 2.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 7 3.1. Adding a public key . . . . . . . . . . . . . . . . . . . 7 3.2. Removing a public key . . . . . . . . . . . . . . . . . . 10 3.3. Listing public keys . . . . . . . . . . . . . . . . . . . 10 3.4. Listing server capabilities . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Conventions for Names . . . . . . . . . . . . . . . . 13 5.2.2. Future Assignments of Names . . . . . . . . . . . . . 13 5.3. Request names . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Response names . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Attribute names . . . . . . . . . . . . . . . . . . . . . 14 5.6. Status codes . . . . . . . . . . . . . . . . . . . . . . . 15 5.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 15 5.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 15 5.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Galbraith, et al. Expires March 17, 2006 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem September 2005 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires March 17, 2006 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem September 2005 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1. Opening the Public-Key Subsystem The public-key subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally sent only by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the publickey subsystem (for example because the user authenticated with a restricted public key). It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires March 17, 2006 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem September 2005 2.2. Requests and Responses All public-key subsystem requests and responses are sent in the following form: uint32 length string name ... request/response specific data follows The length field describes the length of the name field and the request/response-specific data, but does not include the length of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. The version packet, as well as all requests and responses described in Section 3, are a description of the 'name' field and the data part of the packet. 2.3. The Status Message A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1. Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Expires March 17, 2006 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem September 2005 If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names. 2.4. The Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number The version of the protocol described by this document is version 2. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message. Both sides MUST wait to receive this version before continuing. The "version" packet MUST NOT be sent again after this initial exchange. The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request. Galbraith, et al. Expires March 17, 2006 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem September 2005 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 3.1. Adding a public key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED. Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. Galbraith, et al. Expires March 17, 2006 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem September 2005 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key. "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" Galbraith, et al. Expires March 17, 2006 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem September 2005 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. Galbraith, et al. Expires March 17, 2006 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem September 2005 3.2. Removing a public key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.3. Listing public keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.4. Listing server capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the Galbraith, et al. Expires March 17, 2006 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem September 2005 attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. An example of use of the "compulsory" attribute would be a server with a configuration file specifying that the user is not permitted shell access. Given this, the server would return the "shell" attribute, with "compulsory" marked true. Whatever attributes the user subsequently asked the server to apply to their key, the server would also apply the "shell" attribute, rendering it impossible for the user to use a shell. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires March 17, 2006 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem September 2005 4. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires March 17, 2006 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem September 2005 5. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 5.1. Registrations Consistent with section 7 of [1], this document makes the following registration: The subsystem name "publickey". 5.2. Names In the following sections, the values for the name spaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections. 5.2.1. Conventions for Names All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at- sign ("@"), comma (","), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign in them. Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceeding the at-sign is the name. The format of the part preceding the at-sign is not specified, however these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified internet domain name [8] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [7] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [7]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). 5.2.2. Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Galbraith, et al. Expires March 17, 2006 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem September 2005 CONSENSUS method as described in [9]. 5.3. Request names The following table lists the initial assignments of Request names Request Name ------------- version add remove list listattributes 5.4. Response names The following table lists the initial assignments of Response names Response Name -------------- version status publickey attribute 5.5. Attribute names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Response names Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward Galbraith, et al. Expires March 17, 2006 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem September 2005 5.6. Status codes The status code is a byte value, describing the status of a request. 5.6.1. Conventions Status responses have status codes in the range 0 to 255. These numbers are allocated as follows. Of these, the range 192 to 255 is reserved for use by local, private extensions. 5.6.2. Initial Assignments The following table identifies the initial assignments of the status code values. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 5.6.3. Future Assignments Requests for assignments of new message numbers in the range of 0 to 191 MUST be done through the STANDARDS ACTION method as described in [9]. The IANA will not control the message numbers range of 192 through 255. This range will be left for PRIVATE USE. Galbraith, et al. Expires March 17, 2006 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem September 2005 6. References 6.1. Normative References [1] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [2] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [3] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [4] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 6.2. Informative References [7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Expires March 17, 2006 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem September 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 Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: jpv@vandyke.com Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 Email: jon@siliconcircus.com Galbraith, et al. Expires March 17, 2006 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem September 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, et al. Expires March 17, 2006 [Page 18] --------------080408010802060204050402-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 13 16:11:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFH7s-0008Hc-10 for secsh-archive@megatron.ietf.org; Tue, 13 Sep 2005 16:11: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 QAA16235 for ; Tue, 13 Sep 2005 16:11:25 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C906163B1CF; Tue, 13 Sep 2005 20:11:22 +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 87A7A63B13A for ; Tue, 13 Sep 2005 20:11:21 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA16792; Tue, 13 Sep 2005 16:11:19 -0400 (EDT) From: der Mouse Message-Id: <200509132011.QAA16792@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, 13 Sep 2005 16:04:49 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Linguistic logic-chopping Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-03.txt In-Reply-To: <4326A200.6050603@siliconcircus.com> References: <200508281348.JAA10592@Sparkle.Rodents.Montreal.QC.CA> <43259824.6080707@siliconcircus.com> <200509121802.OAA00418@Sparkle.Rodents.Montreal.QC.CA> <4326A200.6050603@siliconcircus.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>> SHOULD be sent. Note that normally, status messages are only sent by >>>> s/only sent by/sent by only/ >>> [...] status messages are only sent by the server [...] >> It still suffers from the problem: the "only" is attached to the >> wrong thing. See http://webster.commnet.edu/grammar/modifiers.htm > I disagree. Maybe I'm wrong, but imho, "only" is modifying the verb, > not the server. Yes, I see it that way too - and that's why I see it as wrong. Perhaps I'm misunderstanding the intent, but in the context, it seemed clear (to me) that the intent was to say "normally, nobody but the server sends these" (in which case the "only" needs to be attached to the server, or perhaps the "by the server" phrase, as was mentioned upthread), not "normally, the server does nothing with these but send them" (which is what you have if the "only" modifies the verb). > Aside from what the strictest rules of grammar say on the subject, > "...are sent by only the server..." sounds.. well.. awful (to my > ears). I agree, though I'd put it less strongly than "awful". That's part of the reason I'd be content with "... are sent only by the server". /~\ 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 Wed Sep 14 15: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 1EFdGl-00028E-Mm for secsh-archive@megatron.ietf.org; Wed, 14 Sep 2005 15: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 PAA29537 for ; Wed, 14 Sep 2005 15:50:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 212FF63B16E; Wed, 14 Sep 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 1ADAB63B141 for ; Wed, 14 Sep 2005 19:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EFdGb-00022c-Ja; Wed, 14 Sep 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-publickey-subsystem-04.txt Message-Id: Date: Wed, 14 Sep 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 : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-04.txt Pages : 18 Date : 2005-9-14 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the Section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-04.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-publickey-subsystem-04.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-publickey-subsystem-04.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-9-14123202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-14123202.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 14 17:22:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFehn-0007mb-RQ for secsh-archive@megatron.ietf.org; Wed, 14 Sep 2005 17:22: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 RAA12840 for ; Wed, 14 Sep 2005 17:22:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 046A763B2DB; Wed, 14 Sep 2005 21:22:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 2B43163B2C6 for ; Wed, 14 Sep 2005 21:22:06 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa10182; 14 Sep 2005 17:21 EDT Date: Wed, 14 Sep 2005 17:21:55 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-04.txt Message-ID: <487CA8F97CA331AA93690C48@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01/TF0SWeZ6b1JfOzKMK+kuJSjq3SEZe1qpqKuM7E=; 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 Wednesday, September 14, 2005 03:50:01 PM -0400 Internet-Drafts@ietf.org wrote: > SECSH defines an authentication mechanism that is based on public > keys, but does not define any mechanism for key distribution. No > common key management solution exists in current implementations. > This document describes a protocol that can be used to configure > public keys in an implementation-independent fashion, allowing client > software to take on the burden of this configuration. > > This protocol is intended to be used from the Secure Shell Connection > Protocol [4] as a subsystem, as described in the Section "Starting a > Shell or a Command". The subsystem name used with this protocol is > "publickey". > > The public-key subsystem provides a server-independent mechanism for > clients to add public keys, remove public keys, and list the current > public keys known by the server. Rights to manage public keys are > specific and limited to the authenticated user. > > A public key may also be associated with various restrictions, > including a mandatory command or subsystem. 'SECSH' is the name of this working group, because 'SSH' was already taken, and the IETF doesn't reuse WG acronyms. It is not the name of the protocol, which is properly called "SSH" or "Secure Shell". -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 15 04:20:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFoz9-0007Hb-PU for secsh-archive@megatron.ietf.org; Thu, 15 Sep 2005 04:20: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 EAA26187 for ; Thu, 15 Sep 2005 04:20:45 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D71F63B103; Thu, 15 Sep 2005 08:20:39 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (unknown [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 5BF9763B12A for ; Thu, 15 Sep 2005 08:20:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 6F48C78D2B; Thu, 15 Sep 2005 10:19:22 +0200 (CEST) Message-ID: <43292E6B.8030303@siliconcircus.com> Date: Thu, 15 Sep 2005 10:18:51 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-publickey-subsystem-04.txt References: <487CA8F97CA331AA93690C48@sirius.fac.cs.cmu.edu> In-Reply-To: <487CA8F97CA331AA93690C48@sirius.fac.cs.cmu.edu> 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 Hi Jeff, Jeffrey Hutzelman wrote: > > 'SECSH' is the name of this working group, because 'SSH' was already > taken, and the IETF doesn't reuse WG acronyms. It is not the name of > the protocol, which is properly called "SSH" or "Secure Shell". A fine point - but the document is now with the RFC Editor for copy editing. I'll send a mail there with this correction. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 15 16:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG0dU-00085E-Re for secsh-archive@megatron.ietf.org; Thu, 15 Sep 2005 16:47: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 QAA09617 for ; Thu, 15 Sep 2005 16:47:09 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 21EEF63B122; Thu, 15 Sep 2005 20:47:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fsmail-out.f-secure.com (fsmail-out.f-secure.com [193.110.109.20]) by mail.netbsd.org (Postfix) with ESMTP id 37D8963B28C for ; Thu, 15 Sep 2005 20:47:05 +0000 (UTC) Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id EC8955B932; Thu, 15 Sep 2005 23:13:58 +0300 (EEST) Received: from fsintra.f-secure.com (fsintra.f-secure.com [10.128.128.79]) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.42.185 Release) with SMTP; Thu, 15 Sep 2005 20:13:56 -0000 (envelope-from ) Received: from [127.0.0.1] (info.f-secure.com [193.110.108.50]) by fsintra.f-secure.com (Postfix) with ESMTP id 3E87B5BD22; Thu, 15 Sep 2005 23:13:56 +0300 (EEST) Message-ID: <4329D5BB.6020007@f-secure.com> Date: Thu, 15 Sep 2005 23:12:43 +0300 From: Oskari Saarenmaa User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: any reason to meet in Vancouver (IETF64)? References: <1126308328.17794.375.camel@thunk> In-Reply-To: <1126308328.17794.375.camel@thunk> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > IETF64 will be in Vancouver, BC, Canada, November 6-11 November 2005 > > We could meet there if we're likely to get a critical mass of attendees. I will be in Vancouver if we have a meeting there. > - finishing the x.509 draft > > Perhaps through hallway discussions with the pkix crowd? Sounds good. Cheers, Oskari From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 19 02:33:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHFDP-0001QZ-VH for secsh-archive@megatron.ietf.org; Mon, 19 Sep 2005 02:33: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 CAA01456 for ; Mon, 19 Sep 2005 02:33:21 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E7D6163B117; Mon, 19 Sep 2005 06:33:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mail.netbsd.org (Postfix) with ESMTP id D9E8F63B101 for ; Mon, 19 Sep 2005 06:33:15 +0000 (UTC) Received: from dodgynet.dyndns.org (203-217-17-96.perm.iinet.net.au [203.217.17.96]) (authenticated bits=0) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j8J3eMQc025761; Mon, 19 Sep 2005 13:40:25 +1000 Received: from [127.0.0.1] (hydra.dodgy.net.au [192.168.32.12]) by dodgynet.dyndns.org (8.13.1/8.13.1) with ESMTP id j8J3eC1t012070; Mon, 19 Sep 2005 13:40:16 +1000 Message-ID: <432E331C.8000907@zip.com.au> Date: Mon, 19 Sep 2005 13:40:12 +1000 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: keyboard-interactive auth References: <200509090502.BAA07662@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509090502.BAA07662@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0537-2, 16/09/2005), Outbound message X-Antivirus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: [...] >>The server cannot know a priori whether a delegated authentication >>mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going >>to return an instant failure when queried. The draft explicitly >>caters for this circumstance, allowing the server to return >>SSH_MSG_USERAUTH_FAILURE immediately. > > Sure - but when that failure message lists keyboard-interactive as a > productive method to continue authenticating with it is, at the very > least, confusing. Just because a given kbdint attempt failed immedaiately does not mean that the next one will. The underlying authentication system may provide no way for the server to know. PAM, for example, makes it pretty much impossible to tell. The admin might configure, for example, a time-based access module before the password prompt in the auth stack. Under those conditions, if your first attempt was before the permitted time, the second one might not be. The admin can arrange for a PAM module to perform pretty much any arbitrary test, including external factors. (server load? currently logged on users? direction of prevailing breeze?) Those factors could have changed between auth attempts, and the server has no way of knowing other than letting the user try again. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 19 15:09:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHR0w-0003jv-CI for secsh-archive@megatron.ietf.org; Mon, 19 Sep 2005 15:09: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 PAA15253 for ; Mon, 19 Sep 2005 15:09:13 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 02D6963B26D; Mon, 19 Sep 2005 19:09:11 +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 29F4563B10A for ; Mon, 19 Sep 2005 19:09:10 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EHR0m-0001g4-Nx; Mon, 19 Sep 2005 15:09:08 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'SSH Transport Layer Encryption Modes' to Proposed Standard Message-Id: Date: Mon, 19 Sep 2005 15:09:08 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following document: - 'SSH Transport Layer Encryption Modes ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Sam Hartman and Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-05.txt Technical Summary Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new counter-mode based symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Working Group Summary This document was non-controversial and well-received by the WG. Protocol Quality The spec is relatively simple, and the working group is aware of multiple implementations, has received informal reports of successful interoperability, and has not received reports of any implementation difficulties. Sam hartman reviewed the specification for the IESG. Note to RFC Editor Section 4: Add note about future directions old: The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. new: The "aes128-ctr" method uses AES (the Advanced Encryption Standard, formerly Rijndael) with 128-bit keys [AES]. The block size is 16 bytes. At this time it appears likely that a future specification will promote aes128-ctr to be REQUIRED; implementation of this algorithm is very strongly encouraged. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 21 10:10:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5JE-0008Ku-Or for secsh-archive@megatron.ietf.org; Wed, 21 Sep 2005 10:10:52 -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 KAA22600 for ; Wed, 21 Sep 2005 10:10:50 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 76E0D63B1A4; Wed, 21 Sep 2005 14:10:44 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (drno.siliconcircus.com [62.141.33.100]) by mail.netbsd.org (Postfix) with ESMTP id 5798C63B118 for ; Wed, 21 Sep 2005 14:10:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 6237A8B27C; Wed, 21 Sep 2005 16:10:03 +0200 (CEST) Message-ID: <433169AE.9070003@siliconcircus.com> Date: Wed, 21 Sep 2005 16:09:50 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internet-drafts@ietf.org, ietf-ssh@NetBSD.org Subject: Submission: draft-ietf-secsh-publickey-subsystem-05.txt Content-Type: multipart/mixed; boundary="------------060802080803060603070900" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------060802080803060603070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached draft-ietf-secsh-publickey-subsystem-05.txt Thanks, -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com --------------060802080803060603070900 Content-Type: text/plain; name="draft-ietf-secsh-publickey-subsystem-05.txt" Content-Disposition: inline; filename="draft-ietf-secsh-publickey-subsystem-05.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: March 25, 2006 B. McClure VanDyke Software J. Bright Silicon Circus September 21, 2005 Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-05.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 March 25, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client Galbraith, et al. Expires March 25, 2006 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem September 2005 software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . . 4 2.1. Opening the Public-Key Subsystem . . . . . . . . . . . . . 4 2.2. Requests and Responses . . . . . . . . . . . . . . . . . . 5 2.3. The Status Message . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Status Codes . . . . . . . . . . . . . . . . . . . . . 5 2.4. The Version Packet . . . . . . . . . . . . . . . . . . . . 6 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . . 7 3.1. Adding a Public Key . . . . . . . . . . . . . . . . . . . 7 3.2. Removing a Public Key . . . . . . . . . . . . . . . . . . 10 3.3. Listing Public Keys . . . . . . . . . . . . . . . . . . . 10 3.4. Listing Server Capabilities . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Names . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1. Conventions for Names . . . . . . . . . . . . . . . . 13 5.2.2. Future Assignments of Names . . . . . . . . . . . . . 13 5.3. Request Names . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Response Names . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Attribute Names . . . . . . . . . . . . . . . . . . . . . 14 5.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 15 5.6.1. Conventions . . . . . . . . . . . . . . . . . . . . . 15 5.6.2. Initial Assignments . . . . . . . . . . . . . . . . . 15 5.6.3. Future Assignments . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Galbraith, et al. Expires March 25, 2006 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem September 2005 1. Introduction Secure Shell is a protocol for secure remote login and other secure network services over an insecure network. Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the Secure Shell transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the Secure Shell architecture [1] and Secure Shell connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires March 25, 2006 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem September 2005 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove, and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1. Opening the Public-Key Subsystem The public-key subsystem is started by a client sending an SSH_MSG_CHANNEL_REQUEST over an existing session's channel. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally sent only by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the public-key subsystem (for example, because the user authenticated with a restricted public key). It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires March 25, 2006 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem September 2005 2.2. Requests and Responses All public-key subsystem requests and responses are sent in the following form: uint32 length string name ... request/response specific data follows The length field describes the length of the name field and of the request/response-specific data, but does not include the length of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. The version packet, as well as all requests and responses described in Section 3, are a description of the 'name' field and the data part of the packet. 2.3. The Status Message A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets, and the request SHOULD NOT close the subsystem. 2.3.1. Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Expires March 25, 2006 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem September 2005 If a request completed successfully, the server MUST send the status code SSH_PUBLICKEY_SUCCESS. The meaning of the failure codes is as implied by their names. 2.4. The Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number This document describes version 2 of the protocol. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Note that, normally, status messages are only sent by the server (in response to requests from the client). This is the only occasion on which the client sends a status message. Both sides MUST wait to receive this version before continuing. The "version" packet MUST NOT be sent again after this initial exchange. The SSH_PUBLICKEY_VERSION_NOT_SUPPORTED status code must not be sent in response to any other request. Galbraith, et al. Expires March 25, 2006 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem September 2005 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and listattributes. 3.1. Adding a Public Key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists, but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED. Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add, with the status code SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED. For the purposes of a mandatory attribute, mere storage of the attribute is not sufficient -- rather, the server must understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. Galbraith, et al. Expires March 25, 2006 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem September 2005 The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specify the language for that attribute [5]. The client MAY specify more than one comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment with its language attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorization checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. If the "subsystem" attribute is not specified, no restrictions are placed on which subsystems may be started when authenticated using this key. "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" Galbraith, et al. Expires March 25, 2006 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem September 2005 "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorization purposes, the authorization attempt MUST be denied. The server SHOULD make a log entry regarding this. The server MAY provide a method for administrators to disallow the appearance of a host in this list. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except those to hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, except for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to enforce certain attributes compulsorily. Galbraith, et al. Expires March 25, 2006 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem September 2005 3.2. Removing a Public Key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.3. Listing Public Keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.4. Listing Server Capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the Galbraith, et al. Expires March 25, 2006 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem September 2005 attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. An example of use of the "compulsory" attribute would be a server with a configuration file specifying that the user is not permitted shell access. Given this, the server would return the "shell" attribute, with "compulsory" marked true. Whatever attributes the user subsequently asked the server to apply to their key, the server would also apply the "shell" attribute, rendering it impossible for the user to use a shell. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires March 25, 2006 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem September 2005 4. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorize keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires March 25, 2006 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem September 2005 5. IANA Considerations This section contains conventions used in naming the namespaces, the initial state of the registry, and instructions for future assignments. 5.1. Registrations Consistent with Section 7 of [1], this document makes the following registration: The subsystem name "publickey". 5.2. Names In the following sections, the values for the namespaces are textual. The conventions and instructions to the IANA for future assignments are given in this section. The initial assignments are given in their respective sections. 5.2.1. Conventions for Names All names registered by the IANA in the following sections MUST be printable US-ASCII strings, and MUST NOT contain the characters at- sign ("@"), comma (","), or whitespace or control characters (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT be longer than 64 characters. A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign in them. Names with the at-sign in them will have the format of "name@domainname" (without the double quotes) where the part preceeding the at-sign is the name. The format of the part preceding the at-sign is not specified, however these names MUST be printable US-ASCII strings, and MUST NOT contain the comma character (","), or whitespace, or control characters (ASCII codes 32 or less). The part following the at-sign MUST be a valid, fully qualified Internet domain name [8] controlled by the person or organization defining the name. Names are case-sensitive, and MUST NOT be longer than 64 characters. It is up to each domain how it manages its local namespace. It has been noted that these names resemble STD 11 [7] email addresses. This is purely coincidental and actually has nothing to do with STD 11 [7]. An example of a locally defined name is "ourcipher-cbc@example.com" (without the double quotes). 5.2.2. Future Assignments of Names Requests for assignments of new Names MUST be done through the IETF Galbraith, et al. Expires March 25, 2006 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem September 2005 Consensus method as described in [9]. 5.3. Request Names The following table lists the initial assignments of Request names. Request Name ------------- version add remove list listattributes 5.4. Response Names The following table lists the initial assignments of Response names. Response Name -------------- version status publickey attribute 5.5. Attribute Names Attributes are used to define properties or restrictions for public keys. The following table lists the initial assignments of Attribute names. Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward Galbraith, et al. Expires March 25, 2006 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem September 2005 5.6. Status Codes The status code is a byte value, describing the status of a request. 5.6.1. Conventions Status responses have status codes in the range 0 to 255. These numbers are allocated as follows. Of these, the range 192 to 255 is reserved for use by local, private extensions. 5.6.2. Initial Assignments The following table identifies the initial assignments of the status code values. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 5.6.3. Future Assignments Requests for assignments of new message numbers in the range of 0 to 191 MUST be done through the Standards Action method as described in [9]. The IANA will not control the message numbers range of 192 through 255. This range will be left for private use. Galbraith, et al. Expires March 25, 2006 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem September 2005 6. References 6.1. Normative References [1] Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", draft-ietf-secsh-architecture-22 (work in progress), March 2005. [2] Lonvick, C., "SSH Transport Layer Protocol", draft-ietf-secsh-transport-24 (work in progress), March 2005. [3] Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-27 (work in progress), March 2005. [4] Lonvick, C. and T. Ylonen, "SSH Connection Protocol", draft-ietf-secsh-connect-25 (work in progress), March 2005. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 6.2. Informative References [7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Expires March 25, 2006 [Page 16] Internet-Draft Secure Shell Public-Key Subsystem September 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 Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: jpv@vandyke.com Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 Email: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 Email: jon@siliconcircus.com Galbraith, et al. Expires March 25, 2006 [Page 17] Internet-Draft Secure Shell Public-Key Subsystem September 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, et al. Expires March 25, 2006 [Page 18] --------------060802080803060603070900-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 21 10:17:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5Pf-0002zD-7S for secsh-archive@megatron.ietf.org; Wed, 21 Sep 2005 10:17: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 KAA23451 for ; Wed, 21 Sep 2005 10:17:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 2623063B1B7; Wed, 21 Sep 2005 14:17: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.100]) by mail.netbsd.org (Postfix) with ESMTP id 7BF7C63B118 for ; Wed, 21 Sep 2005 14:17:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id BB9008B8E9 for ; Wed, 21 Sep 2005 16:16:11 +0200 (CEST) Message-ID: <43316B1D.8020501@siliconcircus.com> Date: Wed, 21 Sep 2005 16:15:57 +0200 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Submission: draft-ietf-secsh-publickey-subsystem-05.txt References: <433169AE.9070003@siliconcircus.com> In-Reply-To: <433169AE.9070003@siliconcircus.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 Jon Bright wrote: > > Please publish the attached draft-ietf-secsh-publickey-subsystem-05.txt For the information of the list, this draft includes copy edits from the RFC Editor as well as a swap of all occurrences of "SECSH" for "Secure Shell". -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 21 15:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIAbd-000852-TU for secsh-archive@megatron.ietf.org; Wed, 21 Sep 2005 15:50: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 PAA15333 for ; Wed, 21 Sep 2005 15:50:11 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D281163B14E; Wed, 21 Sep 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 BD47F63B10C for ; Wed, 21 Sep 2005 19:50:04 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EIAbR-00063t-LY; Wed, 21 Sep 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-publickey-subsystem-05.txt Message-Id: Date: Wed, 21 Sep 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 : Secure Shell Public-Key Subsystem Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-publickey-subsystem-05.txt Pages : 18 Date : 2005-9-21 Secure Shell defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in the section "Starting a Shell or a Command". The subsystem name used with this protocol is "publickey". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-05.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-publickey-subsystem-05.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-publickey-subsystem-05.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-9-21105339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-21105339.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 22 21:08:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIc3c-0005YO-Qa for secsh-archive@megatron.ietf.org; Thu, 22 Sep 2005 21:08:56 -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 VAA17066 for ; Thu, 22 Sep 2005 21:08:53 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id CAC7763B272; Fri, 23 Sep 2005 01:08:49 +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 87A3063B1ED for ; Fri, 23 Sep 2005 01:08:48 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA21474; Thu, 22 Sep 2005 21:08:47 -0400 (EDT) From: der Mouse Message-Id: <200509230108.VAA21474@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: Thu, 22 Sep 2005 20:47:55 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Practical forwarding problem Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I've finally got around to cutting over to my own ssh implementation on my home machines. I've run into a problem. I know where it's coming from but I'm not sure what the best tack to take on dealing with it is. I'm writing the list because I'd be interested to hear if anyone else has dealt with the same problem, and if so how, and also interested in any thoughts anyone may have on it. What's happening is: - User authentication succeeds. - Client opens a "session" channel (call it A). - Server confirms the open. - Client requests agent and X11 forwarding on A. - Server accepts forwardings. - Client sends an "exec" request on A. The requested command is an X terminal emulator. - Terminal emulator starts (opening an X connection) and backgrounds itself (which looks like dying, to the server). - Server notices command death and sends EOF and CLOSE on A. - Client sends CLOSE on A, acking the server's CLOSE. - Server tears down forwardings for A, 'cause the channel's closed. - Something running under the terminal emulator does something which wants agent access, or which wants a new X connection, but the forwarding is now gone! Obviously, something here needs to change. But what? Everything leading up to the problem looks reasonable, but it sure adds up to "broken" in practice. The most dubious point I see is the terminal emulator backgrounding itself - but that worked fine with the old ssh1 implementation, and it doesn't seem totally unreasonable to expect it to work still. Thoughts, anyone? /~\ 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 Thu Sep 22 21:31:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIcP3-0002P0-5S for secsh-archive@megatron.ietf.org; Thu, 22 Sep 2005 21:31: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 VAA18081 for ; Thu, 22 Sep 2005 21:31:01 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 62E7563B1ED; Fri, 23 Sep 2005 01:31:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9FDD863B11D for ; Fri, 23 Sep 2005 01:30:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7919485; Thu, 22 Sep 2005 19:30:58 -0600 Message-ID: <43335AD3.3050601@vandyke.com> Date: Thu, 22 Sep 2005 19:30:59 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> 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 Only two possibilities really occur to me... der Mouse wrote: > - Client requests agent and X11 forwarding on A. > - Server accepts forwardings. > - Client sends an "exec" request on A. The requested command is an X > terminal emulator. > - Terminal emulator starts (opening an X connection) and backgrounds > itself (which looks like dying, to the server). > - Server notices command death and sends EOF and CLOSE on A. The server could notice that their are still child processes alive and send EOF but not CLOSE. Not great, since it might be that the user intended these child processes to run in the background after logout... > - Client sends CLOSE on A, acking the server's CLOSE. > - Server tears down forwardings for A, 'cause the channel's closed. The Server could 'associate' the forwarding with the connection instead of the channel... and not tear it down until the connection dies. In this model, a second agent-forwarding request on a second session channel would not result in a second unix domain socket being created, but would simply result in th environment variable being set to point to the 'connection' forwarding. The same for x11... I'm not sure this is a good idea either... but it might be better than the first one. -- In the end, I think it comes down to the fact that agent and x11 forwarding really should be connection level operations... but they are requested over a session channel because they require setting environment for a given session. I think it would have been better to make them connection level requests, and then, maybe, have the session level 'forward-x11' request imply that a connection level forwarding had already been set up and this was a request to make it available to this particular session. Waaaaaaay to late now, though... Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 23 00:36:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIfIn-0006ez-3H for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 00:36:50 -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 AAA06720 for ; Fri, 23 Sep 2005 00:36:44 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D35C563B115; Fri, 23 Sep 2005 04:36:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id 1742D63B10E for ; Fri, 23 Sep 2005 04:36:41 +0000 (UTC) Received: from manatee.savecore.net (manatee.savecore.net [209.234.108.155]) by hoth.savecore.net (Postfix) with ESMTP id BDEC02AC40; Thu, 22 Sep 2005 21:35:32 -0700 (PDT) Date: Thu, 22 Sep 2005 21:35:18 -0700 From: Frank Cusack To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem Message-ID: <72B46300515713F582EA4DE0@manatee.savecore.net> In-Reply-To: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On September 22, 2005 8:47:55 PM -0400 der Mouse wrote: > - User authentication succeeds. > - Client opens a "session" channel (call it A). > - Server confirms the open. > - Client requests agent and X11 forwarding on A. > - Server accepts forwardings. > - Client sends an "exec" request on A. The requested command is an X > terminal emulator. > - Terminal emulator starts (opening an X connection) and backgrounds > itself (which looks like dying, to the server). > - Server notices command death and sends EOF and CLOSE on A. > - Client sends CLOSE on A, acking the server's CLOSE. > - Server tears down forwardings for A, 'cause the channel's closed. > - Something running under the terminal emulator does something which > wants agent access, or which wants a new X connection, but the > forwarding is now gone! > > Obviously, something here needs to change. But what? Everything > leading up to the problem looks reasonable, but it sure adds up to > "broken" in practice. The most dubious point I see is the terminal > emulator backgrounding itself - but that worked fine with the old ssh1 > implementation, and it doesn't seem totally unreasonable to expect it > to work still. This is a known problem, for openssh at least. You shouldn't send EOF and CLOSE (are these actual protocol messages?) on command termination, you should only send it on EOF from the read fd connected to the command's stdout. The problem with that is you end up with "hung" sessions if you start a background process that doesn't close it's stdout (e.g. attempting to run a process as a daemon that really is meant to run in the foreground). So a compromise is that you note process death but wait until your select() or poll() loop indicates that there is no data ready. For some reason, openssh on BSD and openssh on Linux act differently here, due to kernel differences. It's been so long that I don't remember the details. Now, if you implemented the compromise method, this wouldn't solve your problem, because an idle xterm isn't going to have data ready. But that's all a red herring, because really you should notice that the forwarded session is still open and delay closing the session until the forwarding has gone bye-bye. At least, that's what openssh does. Even if I'm off track here, I suggest sending a note to the openssh list. It sounds off topic for this list. -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 23 01:28:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIg6O-0001lM-LE for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 01:28:06 -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 BAA08617 for ; Fri, 23 Sep 2005 01:28:03 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D755663B110; Fri, 23 Sep 2005 05:28:00 +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 26DE863B10F for ; Fri, 23 Sep 2005 05:27:59 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA05282; Fri, 23 Sep 2005 01:27:58 -0400 (EDT) From: der Mouse Message-Id: <200509230527.BAA05282@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, 23 Sep 2005 01:03:29 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem In-Reply-To: <43335AD3.3050601@vandyke.com> <20050923014546.GB28009@sphinx.chicagopeoplez.org> <72B46300515713F582EA4DE0@manatee.savecore.net> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> <43335AD3.3050601@vandyke.com> <20050923014546.GB28009@sphinx.chicagopeoplez.org> <72B46300515713F582EA4DE0@manatee.savecore.net> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Replying to three messages at once, here. >> [issue with forwardings being torn down before they're wanted] [Joseph Galbraith ] > The server could notice that their are still child processes alive > and send EOF but not CLOSE. This is approximately impossible on at least some of my target OSes; if A forks B and B forks C and B then dies, A has no way (well, no easy or clean way) to find out that B forked C at all, much less that C still exists. > Not great, since it might be that the user intended these child > processes to run in the background after logout... There's that, too. >> - Client sends CLOSE on A, acking the server's CLOSE. >> - Server tears down forwardings for A, 'cause the channel's closed. > The Server could 'associate' the forwarding with the connection > instead of the channel... and not tear it down until the connection > dies. That breaks connection sharing. What I considered is allowing the active forwardings to keep the session channel alive when it would otherwise be closed, but then there's the problem of telling when you *do* want to shut it down. (But see David Terrell's idea, below.) > In this model, a second agent-forwarding request on a second session > channel would not result in a second unix domain socket being > created, but would simply result in th environment variable being set > to point to the 'connection' forwarding. That sounds good, except it breaks if the two agent forwarding requests are trying to provide forwarded access to different agent instantiations. (Mutatis mutandis for X, of course.) > In the end, I think it comes down to the fact that agent and x11 > forwarding really should be connection level operations... Perhaps, but that point of view is fundamentally incompatible with connection sharing (which is *very* desirable for someone who, like me, is on old half-lung hardware that can quite literally take minutes to do kex and authentication). Or at least with connection-sharing for decoupled sessions. [David Terrell ] > Option 1) Keep the terminal open until you're done This is what I've started doing. I didn't like it at all at first, and still don't really like it that much, but I've made a mental shift to seeing the old way's working as an accident of that implementation rather than a "how it's supposed to work", which makes it easier to accept the difference when I switch. > Option 2) Keep open all forwardings as long as there's > a) a forwarded session > b) a forwarded x session That is a sensible suggestion. I may try it someday. The real problem here is that I want to hand a capability to a process, to pass on to descendants, and I want to know as soon as nobody who has it is still alive any longer. The only thing I can think of which fits this in stock Unix is a file descriptor. I could do that for agent access, but I don't think I could for X access, not without hacking up Xlib as well - and even for agent access, it's hard to get the descriptor past things like shells which (not unreasonably) go to some lengths to close all file descriptors they don't understand. [Frank Cusack ] > This is a known problem, for openssh at least. You shouldn't send > EOF and CLOSE (are these actual protocol messages?) Yes - SSH_MSG_CHANNEL_EOF and SSH_MSG_CHANNEL_CLOSE, to give them their full names. > on command termination, you should only send it on EOF from the read > fd connected to the command's stdout. Perhaps, but... > The problem with that is you end up with "hung" sessions if you start > a background process that doesn't close [its] stdout [...] ...I've run into that kind of wedgitude in the past, so I'm reluctant to do that in that form. > So a compromise is that you note process death but wait until your > select() or poll() loop indicates that there is no data ready. That helps with races between process exit and output flushing, but not with a situation like this one, where the process quite likely will _never_ produce any output. > But that's all a red herring, because really you should notice that > the forwarded session is still open and delay closing the session > until the forwarding has gone bye-bye. At least, that's what openssh > does. Not according to connect-25: X11 connection forwarding should stop when the session channel is closed. However, already opened forwardings should not be automatically closed when the session channel is closed. To me, that quite clearly says that I *should* shut down the forwarding when the session channel closes. > Even if I'm off track here, I suggest sending a note to the openssh > list. It sounds off topic for this list. Really? OpenSSH is not involved in any way in the cases in which I ran into this. Anyway, thanks for all the thoughts. I'll let them (and any more that may show up) rattle around for a day or two and see if I can't settle on something. /~\ 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 Sep 23 02:28:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIh3F-0006Ww-RT for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 02:28:53 -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 CAA24615 for ; Fri, 23 Sep 2005 02:28:51 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C60E863B14C; Fri, 23 Sep 2005 06:28:45 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id 2139A63B10F for ; Fri, 23 Sep 2005 06:28:45 +0000 (UTC) Received: from manatee.savecore.net (manatee.savecore.net [209.234.108.155]) by hoth.savecore.net (Postfix) with ESMTP id 235C62AC40; Thu, 22 Sep 2005 23:27:44 -0700 (PDT) Date: Thu, 22 Sep 2005 23:27:44 -0700 From: Frank Cusack To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem Message-ID: <1B923AF6EBC363A715D42652@manatee.savecore.net> In-Reply-To: <200509230527.BAA05282@Sparkle.Rodents.Montreal.QC.CA> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> <43335AD3.3050601@vandyke.com> <20050923014546.GB28009@sphinx.chicagopeoplez.org> <72B46300515713F582EA4DE0@manatee.savecore.net> <200509230527.BAA05282@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On September 23, 2005 1:03:29 AM -0400 der Mouse wrote: > [Frank Cusack ] >> But that's all a red herring, because really you should notice that >> the forwarded session is still open and delay closing the session >> until the forwarding has gone bye-bye. At least, that's what openssh >> does. > > Not according to connect-25: > > X11 connection forwarding should stop when the session channel is > closed. However, already opened forwardings should not be > automatically closed when the session channel is closed. > > To me, that quite clearly says that I *should* shut down the forwarding > when the session channel closes. I don't read that. What I read is that new X11 requests should no longer be accepted, but that existing (_already opened_) forwardings should live on. The point of the paragraph is to note that just because an already opened [X11] forwarding is left open, doesn't mean new X11 requests must be honored. Interesting that the text does not capitalize SHOULD and SHOULD NOT. >> Even if I'm off track here, I suggest sending a note to the openssh >> list. It sounds off topic for this list. > > Really? OpenSSH is not involved in any way in the cases in which I ran > into this. No, but they deal with this case. My suggestion was just that you discuss it with an implementor that has addressed it. But now that I have a clearer idea of what you're asking, maybe this list is more appropriate. -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 23 02:45:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIhIs-0001rk-S4 for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 02:45: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 CAA25729 for ; Fri, 23 Sep 2005 02:45:00 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D723D63B14C; Fri, 23 Sep 2005 06:44:57 +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 9370663B10F for ; Fri, 23 Sep 2005 06:44:56 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id CAA06236; Fri, 23 Sep 2005 02:44:55 -0400 (EDT) From: der Mouse Message-Id: <200509230644.CAA06236@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, 23 Sep 2005 02:31:09 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem In-Reply-To: <1B923AF6EBC363A715D42652@manatee.savecore.net> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> <43335AD3.3050601@vandyke.com> <20050923014546.GB28009@sphinx.chicagopeoplez.org> <72B46300515713F582EA4DE0@manatee.savecore.net> <200509230527.BAA05282@Sparkle.Rodents.Montreal.QC.CA> <1B923AF6EBC363A715D42652@manatee.savecore.net> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> X11 connection forwarding should stop when the session channel is >> closed. However, already opened forwardings should not be >> automatically closed when the session channel is closed. >> To me, that quite clearly says that I *should* shut down the >> forwarding when the session channel closes. > I don't read that. What I read is that new X11 requests should no > longer be accepted, but that existing (_already opened_) forwardings > should live on. I suspect we may be in furious agreement here, just using different words to describe it. In particular, a "forwarding" may be different things to you and to me. By "new X11 requests" do you mean "x11-req" CHANNEL_REQUESTs, do you mean new X connections on the server host (and the "x11" CHANNEL_OPENs that result from them), or what? By "existing...forwardings" do you mean existing channels opened with type "x11", do you mean the listen for new X connections that's set up on the server, or what? My reading is that the "X11 connection forwarding should stop" means that the server side should stop listening for new X connections and "already opened forwardings should not be automatically closed" is referring to existing X connections, and their associated "x11" channels. And when I equate that to "shut down the forwarding when the session channel closes", I'm talking about the server stopping listening for new X connections. >>> Even if I'm off track here, I suggest sending a note to the openssh >>> list. It sounds off topic for this list. >> Really? OpenSSH is not involved in any way in the cases in which I >> ran into this. > No, but they deal with this case. My suggestion was just that you > discuss it with an implementor that has addressed it. Ah, I think I see what you mean. Not so much "take it to openssh" as "take it to a implementation list rather than protocol design list"? Perhaps a parallel list for implementation issues would be appropriate. > But now that I have a clearer idea of what you're asking, maybe this > list is more appropriate. Well, perhaps. It *is* an implementation issue, not something that has anything to do with the protocol per se - but the spec is intended to guide implementations, and if the spec ends up compelling something that cripples implementations, it needs fixing. (In this case, I now think it's not that bad, but it looked at first as though it might be.) /~\ 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 Sep 23 03:35:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIi5m-0004g7-B3 for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 03:35: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 DAA28100 for ; Fri, 23 Sep 2005 03:35:31 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0804063B17F; Fri, 23 Sep 2005 07:35:29 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.mindrot.org (fuyu.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 0064263B10F for ; Fri, 23 Sep 2005 07:35:27 +0000 (UTC) Received: by mail.mindrot.org (Postfix, from userid 1000) id 407A217E625; Fri, 23 Sep 2005 17:35:26 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.mindrot.org (Postfix) with ESMTP id 3EAEE17E606; Fri, 23 Sep 2005 17:35:26 +1000 (EST) Date: Fri, 23 Sep 2005 17:35:26 +1000 (EST) From: Damien Miller To: Frank Cusack cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem In-Reply-To: <72B46300515713F582EA4DE0@manatee.savecore.net> Message-ID: References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> <72B46300515713F582EA4DE0@manatee.savecore.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 22 Sep 2005, Frank Cusack wrote: > This is a known problem, for openssh at least. You shouldn't send > EOF and CLOSE (are these actual protocol messages?) on command termination, > you should only send it on EOF from the read fd connected to the command's > stdout. > On September 22, 2005 8:47:55 PM -0400 der Mouse > wrote: >> - User authentication succeeds. >> - Client opens a "session" channel (call it A). >> - Server confirms the open. >> - Client requests agent and X11 forwarding on A. >> - Server accepts forwardings. >> - Client sends an "exec" request on A. The requested command is an X >> terminal emulator. >> - Terminal emulator starts (opening an X connection) and backgrounds >> itself (which looks like dying, to the server). >> - Server notices command death and sends EOF and CLOSE on A. >> - Client sends CLOSE on A, acking the server's CLOSE. >> - Server tears down forwardings for A, 'cause the channel's closed. >> - Something running under the terminal emulator does something which >> wants agent access, or which wants a new X connection, but the >> forwarding is now gone! >> >> Obviously, something here needs to change. But what? Everything >> leading up to the problem looks reasonable, but it sure adds up to >> "broken" in practice. The most dubious point I see is the terminal >> emulator backgrounding itself - but that worked fine with the old ssh1 >> implementation, and it doesn't seem totally unreasonable to expect it >> to work still. > > > The problem with that is you end up with "hung" sessions if you start > a background process that doesn't close it's stdout (e.g. attempting > to run a process as a daemon that really is meant to run in the foreground). > So a compromise is that you note process death but wait until your select() > or poll() loop indicates that there is no data ready. > > For some reason, openssh on BSD and openssh on Linux act differently here, > due to kernel differences. It's been so long that I don't remember the > details. > > Now, if you implemented the compromise method, this wouldn't solve your > problem, because an idle xterm isn't going to have data ready. > > But that's all a red herring, because really you should notice that the > forwarded session is still open and delay closing the session until > the forwarding has gone bye-bye. At least, that's what openssh does. > > Even if I'm off track here, I suggest sending a note to the openssh > list. It sounds off topic for this list. > > -frank > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 23 05:33:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIjvw-0006Rf-2E for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 05:33: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 FAA03187 for ; Fri, 23 Sep 2005 05:33:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id D198863B1DC; Fri, 23 Sep 2005 09:33:26 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from hoth.savecore.net (hoth.savecore.net [209.234.108.136]) by mail.netbsd.org (Postfix) with ESMTP id 3784163B1D1 for ; Fri, 23 Sep 2005 09:33:26 +0000 (UTC) Received: from maguro.savecore.net (maguro.savecore.net [209.234.108.152]) by hoth.savecore.net (Postfix) with ESMTP id 063862AC40; Fri, 23 Sep 2005 02:32:22 -0700 (PDT) Date: Fri, 23 Sep 2005 02:32:22 -0700 From: Frank Cusack To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem Message-ID: <9BF046D8554A677C0534EF6B@maguro.savecore.net> In-Reply-To: <200509230644.CAA06236@Sparkle.Rodents.Montreal.QC.CA> References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> <43335AD3.3050601@vandyke.com> <20050923014546.GB28009@sphinx.chicagopeoplez.org> <72B46300515713F582EA4DE0@manatee.savecore.net> <200509230527.BAA05282@Sparkle.Rodents.Montreal.QC.CA> <1B923AF6EBC363A715D42652@manatee.savecore.net> <200509230644.CAA06236@Sparkle.Rodents.Montreal.QC.CA> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On September 23, 2005 2:31:09 AM -0400 der Mouse wrote: >>> X11 connection forwarding should stop when the session channel is >>> closed. However, already opened forwardings should not be >>> automatically closed when the session channel is closed. > >>> To me, that quite clearly says that I *should* shut down the >>> forwarding when the session channel closes. > >> I don't read that. What I read is that new X11 requests should no >> longer be accepted, but that existing (_already opened_) forwardings >> should live on. > > I suspect we may be in furious agreement here, We are, and I misread your original message as saying that the xterm started in the background is no longer functional. If you start a command in that xterm which requires a new X connection, it should fail, from my reading of connect-25. However, I realize now that I don't quite understand the difference between a session and a channel, so I'll bow out, hopefully gracefully. Interestingly, this has just come up as an openssh bug, . -frank From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 23 07:34:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlpT-00010O-B7 for secsh-archive@megatron.ietf.org; Fri, 23 Sep 2005 07:34:59 -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 HAA08979 for ; Fri, 23 Sep 2005 07:34:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 5B05763B194; Fri, 23 Sep 2005 11:34:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id 3B9A563B115 for ; Fri, 23 Sep 2005 11:34:50 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BD3231B8046; Fri, 23 Sep 2005 13:34:45 +0200 (CEST) Received: from mail.lysator.liu.se ([127.0.0.1]) by localhost (lenin.lysator.liu.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30564-01-88; Fri, 23 Sep 2005 13:34:45 +0200 (CEST) Received: from adriana.lysator.liu.se (adriana.lysator.liu.se [130.236.254.28]) by mail.lysator.liu.se (Postfix) with ESMTP id D96B91B8016; Fri, 23 Sep 2005 13:34:44 +0200 (CEST) Received: (from nisse@localhost) by adriana.lysator.liu.se (8.12.10/8.12.8) id j8NBYf1K005320; Fri, 23 Sep 2005 13:34:41 +0200 (MEST) X-Authentication-Warning: adriana.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Practical forwarding problem References: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 23 Sep 2005 13:34:41 +0200 In-Reply-To: <200509230108.VAA21474@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > I'm writing the list because I'd be interested to hear if anyone else > has dealt with the same problem, and if so how, and also interested in > any thoughts anyone may have on it. I have a couple of comments: You say it's dubious to have the terminal emulator background itself. I agree. Don't do that; if you want to have your local shell prompt back, you should background the *local* ssh client, not the remote terminal emulator. Some clients have a command line option "background process after initial handshake and user authentication is complete". > - Terminal emulator starts (opening an X connection) and backgrounds > itself (which looks like dying, to the server). > - Server notices command death and sends EOF and CLOSE on A. The server should merely generate a CHANNEL_REQUEST "exit-status" on process death, not CHANNEL_EOF or CHANNEL_CLOSE here. (The correct close logic is somewhat hairy, but it's not really central to what you are asking about). > - Server tears down forwardings for A, 'cause the channel's closed. Whenever the session channel is closed, it makes sense to tear down the forwardings (i.e. let existing forwarded channels live on, but don't allow opening of any new ones, and close any related listening sockets, etc). > - Something running under the terminal emulator does something which > wants agent access, or which wants a new X connection, but the > forwarding is now gone! If the session channel is dead, I think this is the correct behaviour. Even if the server keeps its side of the forwarding open, it would make sense for the client side to refuse to open new forwarded channels for a closed sesssion. (And here we get into the connection sharing issues; the client has some difficulty in handling the request properly, since it's hard to identify a CHANNEL_OPEN request with the session for which the corresponding forwarding was set up, in particular if that session is dead, closed and deallocated.) Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 26 17:41:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK0j6-00075Y-8e for secsh-archive@megatron.ietf.org; Mon, 26 Sep 2005 17:41: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 RAA12969 for ; Mon, 26 Sep 2005 17:41:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 58DF663B1A4; Mon, 26 Sep 2005 21:41:27 +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 4671263B128 for ; Mon, 26 Sep 2005 21:41:26 +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 j8QLfPHT017137 for ; Mon, 26 Sep 2005 14:41:25 -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 j8QLfPUj012491 for ; Mon, 26 Sep 2005 17:41:25 -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 j8QLfOS2159189; Mon, 26 Sep 2005 17:41:24 -0400 (EDT) Subject: Start of short WG Last Call on revised draft-ietf-secsh-publickey-subsystem-05 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Cc: Jon Bright Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1127770883.156519.105.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 26 Sep 2005 17:41:24 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit The draft returned from the RFC editor early-copy-editing experiment with only a few changes. Diffs can be found at: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/draft-ietf-secsh-publickey-subsystem-05-from-04.diff.html In looking at the changes, I see none which change the technical content of the document. Since I might have missed something, this message marks the start of a one-week Last Call, ending on October 3rd, 2005. Reviewer should focus primarily on the changes between the -04 and -05 revisions. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 27 15:45:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLOp-0004Yh-Be for secsh-archive@megatron.ietf.org; Tue, 27 Sep 2005 15:45:59 -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 PAA04980 for ; Tue, 27 Sep 2005 15:45:57 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id C80D663B134; Tue, 27 Sep 2005 19:45:53 +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 288E063B125 for ; Tue, 27 Sep 2005 19:45:53 +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 7930991; Tue, 27 Sep 2005 13:45:52 -0600 Message-ID: <4339A3B5.2000309@vandyke.com> Date: Tue, 27 Sep 2005 13:55:33 -0600 From: Joseph Galbraith User-Agent: Thunderbird 1.0+ (Windows/20050816) MIME-Version: 1.0 To: Bill Sommerfeld CC: ietf-ssh@NetBSD.org Subject: Re: any reason to meet in Vancouver (IETF64)? References: <1126308328.17794.375.camel@thunk> In-Reply-To: <1126308328.17794.375.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 Did we decide to meet? Thanks, Joseph Bill Sommerfeld wrote: > IETF64 will be in Vancouver, BC, Canada, November 6-11 November 2005 > > We could meet there if we're likely to get a critical mass of attendees. > > Possible topics which could benefit from face-to-face discussion: > - finishing sftp/filexfer > > Specifically, locking people who think it's too complex already in the > same room with people who want to add more hair until they hash out a > consensus. > > - finishing the x.509 draft > > Perhaps through hallway discussions with the pkix crowd? > > - figuring if we want to put energy into advancement to Draft Standard, > and, if so, figure out how we'll collect the interop reports required. > > Thoughts, anyone? > > - Bill > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 27 16:04:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKLgs-0001b3-5G for secsh-archive@megatron.ietf.org; Tue, 27 Sep 2005 16:04: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 QAA08430 for ; Tue, 27 Sep 2005 16:04:36 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 7641063B2E9; Tue, 27 Sep 2005 20:04:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 4564863B2A1 for ; Tue, 27 Sep 2005 20:04:23 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j8RK4M1L016113 for ; Tue, 27 Sep 2005 14:04:22 -0600 (MDT) 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 j8RK4MWB017200 for ; Tue, 27 Sep 2005 16:04:22 -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 j8RK4LlB163741; Tue, 27 Sep 2005 16:04:21 -0400 (EDT) Subject: Re: any reason to meet in Vancouver (IETF64)? From: Bill Sommerfeld To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org In-Reply-To: <4339A3B5.2000309@vandyke.com> References: <1126308328.17794.375.camel@thunk> <4339A3B5.2000309@vandyke.com> Content-Type: text/plain Message-Id: <1127851460.162251.336.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Tue, 27 Sep 2005 16:04:21 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-09-27 at 15:55, Joseph Galbraith wrote: > Did we decide to meet? I didn't see enough of a response to believe we have critical mass so we will not meet. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 27 17:23:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKMvD-00009l-CF for secsh-archive@megatron.ietf.org; Tue, 27 Sep 2005 17:23: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 RAA21832 for ; Tue, 27 Sep 2005 17:23:29 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0ABA063B2EB; Tue, 27 Sep 2005 21:23:27 +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 D085563B2E8 for ; Tue, 27 Sep 2005 21:23:25 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA11109; Tue, 27 Sep 2005 17:23:24 -0400 (EDT) From: der Mouse Message-Id: <200509272123.RAA11109@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, 27 Sep 2005 17:19:40 -0400 (EDT) To: ietf-ssh@NetBSD.org Subject: Re: Start of short WG Last Call on revised draft-ietf-secsh-publickey-subsystem-05 In-Reply-To: <1127770883.156519.105.camel@thunk> References: <1127770883.156519.105.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > The draft returned from the RFC editor early-copy-editing experiment > with only a few changes. > Diffs can be found at: > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/draft-ietf-secsh-publickey-subsystem-05-from-04.diff.html That doesn't work for me - I get a large number of lines intermixed without any indication what's what, probably because the page depends on font or background changes or some such that doesn't show up in a text-only view. I also don't see a copy of -04 in the IETF internet-drafts directory. So I fetched -05 and diffed it against my saved copy of -03. Based on that, I see nothing I would change but copy-edit tweaks. If you want them, I'll be happy to go through and write up a list, but the language of your message seems to imply that you're looking for substantive content issues, not fiddly copy-edit bits. /~\ 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 Sep 27 18:23:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKNrW-0008GD-0J for secsh-archive@megatron.ietf.org; Tue, 27 Sep 2005 18:23:46 -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 SAA25253 for ; Tue, 27 Sep 2005 18:23:43 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id E864263B2F7; Tue, 27 Sep 2005 22:23:40 +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 CA9F463B2F2 for ; Tue, 27 Sep 2005 22:23:39 +0000 (UTC) Received: from CRUNCHBERRY.SRV.CS.CMU.EDU ([128.2.203.75]) by currant.srv.cs.cmu.edu id aa16606; 27 Sep 2005 18:23 EDT Received: from c-24-3-51-180.hsd1.pa.comcast.net (IDENT:U2FsdGVkX19CC6huupEUshVwRf1FiP4tS+XUh0ub+BA@c-24-3-51-180.hsd1.pa.comcast.net [24.3.51.180]) (authenticated bits=0) by crunchberry.srv.cs.cmu.edu (8.13.4/8.13.4) with ESMTP id j8RMN7Cr005921 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 27 Sep 2005 18:23:10 -0400 (EDT) Date: Tue, 27 Sep 2005 18:23:06 -0400 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org cc: Jeffrey Hutzelman Subject: Re: Start of short WG Last Call on revised draft-ietf-secsh-publickey-subsystem-05 Message-ID: <9BF991DA8D03C24E911AC395@bistromath.pc.cs.cmu.edu> In-Reply-To: <200509272123.RAA11109@Sparkle.Rodents.Montreal.QC.CA> References: <1127770883.156519.105.camel@thunk> <200509272123.RAA11109@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01XOxxYcZU5tWoN+nij2qh0PNeqIzjIOrJYZ/Gkmw=; 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 Tuesday, September 27, 2005 05:19:40 PM -0400 der Mouse wrote: >> The draft returned from the RFC editor early-copy-editing experiment >> with only a few changes. > >> Diffs can be found at: > >> http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/draf >> t-ietf-secsh-publickey-subsystem-05-from-04.diff.html > > That doesn't work for me - I get a large number of lines intermixed > without any indication what's what, probably because the page depends > on font or background changes or some such that doesn't show up in a > text-only view. Yeah, the rfcdiff tool used to generate those is really quite good, but it does depend on background color to get the point across. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 27 20:41:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKQ1B-0002RP-Nh for secsh-archive@megatron.ietf.org; Tue, 27 Sep 2005 20:41:53 -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 UAA01922 for ; Tue, 27 Sep 2005 20:41:52 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id 0BA8863B225; Wed, 28 Sep 2005 00:41:49 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mail.netbsd.org (Postfix) with ESMTP id 5A91B63B131 for ; Wed, 28 Sep 2005 00:41:48 +0000 (UTC) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j8S0fl1L019492 for ; Tue, 27 Sep 2005 18:41:48 -0600 (MDT) 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 j8S0flUj004981 for ; Tue, 27 Sep 2005 20:41:47 -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 j8S0fkxA174070; Tue, 27 Sep 2005 20:41:47 -0400 (EDT) Subject: Re: Start of short WG Last Call on revised draft-ietf-secsh-publickey-subsystem-05 From: Bill Sommerfeld To: der Mouse Cc: ietf-ssh@NetBSD.org In-Reply-To: <200509272123.RAA11109@Sparkle.Rodents.Montreal.QC.CA> References: <1127770883.156519.105.camel@thunk> <200509272123.RAA11109@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain Message-Id: <1127868105.162251.592.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Tue, 27 Sep 2005 20:41:46 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-09-27 at 17:19, der Mouse wrote: > > Diffs can be found at: > > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-publickey-subsystem/draft-ietf-secsh-publickey-subsystem-05-from-04.diff.html > > That doesn't work for me - I get a large number of lines intermixed > without any indication what's what, probably because the page depends > on font or background changes or some such that doesn't show up in a > text-only view. the diffs on tools.ietf.org are generated by a tool which has multiple output formats; the default used on that site uses background colors. you can get the tool from: http://tools.ietf.org/tools/rfcdiff/ (compared with a conventional "diff", it reduces the amount of noise in the output from things like pagination changes). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 29 15:06:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL3jd-0003RL-Ds for secsh-archive@megatron.ietf.org; Thu, 29 Sep 2005 15:06: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 PAA28897 for ; Thu, 29 Sep 2005 15:06:22 -0400 (EDT) Received: by mail.netbsd.org (Postfix, from userid 0) id AC2F263B486; Thu, 29 Sep 2005 19:06:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from portal.hamachi.org (portal.hamachi.org [69.25.196.17]) by mail.netbsd.org (Postfix) with ESMTP id A222663B485 for ; Thu, 29 Sep 2005 19:06:17 +0000 (UTC) Received: from 127.0.0.1 (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id D69AA17942; Thu, 29 Sep 2005 14:35:59 -0400 (EDT) Subject: DISCUSS comments on publickeyfile-09 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1128018959.1506.60.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Thu, 29 Sep 2005 14:35:59 -0400 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit (these were sent directly to the list but got tripped up on an overly exuberant regexp in the spam filter. my apologes for the delay in getting these out to the list). Note that there are a few other non-DISCUSS comments in the datatracker which at first glance look like reasonable things to pick up if we respin the draft. - Bill To: ietf-ssh@netbsd.org Subject: [Scott Hollenbeck] DISCUSS: draft-ietf-secsh-publickeyfile-09.txt From: Sam Hartman Date: Fri, 23 Sep 2005 14:11:49 -0400 Message-ID: --=-=-= You know, the draft might actually even mean bytes in this instance. I'm trying to imagine what I'd do if I took this file to tops-20. I think it is either bytes or characters, octet seems clearly wrong. --=-=-= From: "Scott Hollenbeck" To: "'Internet Engineering Steering Group'" Date: Fri, 23 Sep 2005 09:21:31 -0400 Message-ID: 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. -Scott- --=-=-=-- To: ietf-ssh@netbsd.org Subject: [Russ Housley] DISCUSS: draft-ietf-secsh-publickeyfile-09 From: Sam Hartman Date: Tue, 27 Sep 2005 00:29:44 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Another discuss. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Date: Mon, 26 Sep 2005 16:33:03 -0400 To: iesg@ietf.org From: Russ Housley Subject: DISCUSS: draft-ietf-secsh-publickeyfile-09 SSH Public Key File Format (Informational) DISCUSS 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. Section 3.4 says: > > The body of a public key file consists of the public key blob as > described in [I-D.ietf-secsh-transport], section 4.6, ... > There is no section 4.6 in the referenced document. I assume that this should be a reference to section 6.6. 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. > 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. In section 3.6, please change "me@myhost" to "me@example.com". 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 ... --=-=-=--