From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 2 19:35:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17611 for ; Wed, 2 Mar 2005 19:35:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DBFA951A2; Thu, 3 Mar 2005 00:35:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from draco.cus.cam.ac.uk (draco.cus.cam.ac.uk [131.111.8.18]) by mail.netbsd.org (Postfix) with ESMTP id 4CFD35164 for ; Thu, 3 Mar 2005 00:35:38 +0000 (UTC) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1D6eJV-0004sc-7f for ietf-ssh@netbsd.org; Thu, 03 Mar 2005 00:35:37 +0000 Date: Thu, 3 Mar 2005 00:35:37 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Key lengths for algorithms for variable-length keys Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list transport-23, in section 7.2, says: 128 bits (16 bytes) MUST be used for algorithms with variable-length keys. The only variable key length algorithm defined in this document is arcfour). Apart from the mismatched parenthesis, this seems like a strange pair of sentences. The "arcfour" algorithm as specified in section 6.3 is defined to have a 128-bit key anyway. RC4 does generally support variable key lengths, but so do Blowfish and CAST-128, so why aren't they mentioned? If this stipulation is meant to apply to all future algorithms, it seems like a particularly bad idea. Is it intended to prevent me defining "arcfour-256@bjh21.me.uk" to be RC4 with a 256-bit key, for instance? If not, what does it do? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 3 03:10:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17762 for ; Thu, 3 Mar 2005 03:10:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F22CA5207; Thu, 3 Mar 2005 08:09:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id D3693516A for ; Thu, 3 Mar 2005 08:09:54 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id B89931B80D9; Thu, 3 Mar 2005 09:09:37 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 15030-01-89; Thu, 3 Mar 2005 09:09:27 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B610F1B806E; Thu, 3 Mar 2005 09:09:27 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2389RXa008465; Thu, 3 Mar 2005 09:09:27 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2389MD3008462; Thu, 3 Mar 2005 09:09:22 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: Key lengths for algorithms for variable-length keys References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 03 Mar 2005 09:09:22 +0100 In-Reply-To: Message-ID: Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Ben Harris writes: > transport-23, in section 7.2, says: > > 128 bits (16 bytes) MUST be used for algorithms with variable-length > keys. The only variable key length algorithm defined in this > document is arcfour). I agree this is awkward. I'd suggest the paragraph is cut down from Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) MUST be used for algorithms with variable-length keys. The only variable key length algorithm defined in this document is arcfour). For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. [...] to Key data MUST be taken from the beginning of the hash output. As many bytes as are needed are taken from the beginning of the hash value. [...] For key length, we already have the general recommendation "All ciphers SHOULD use keys with an effective key length of 128 bits or more." in 6.3. For arcfour in particular, it may be a little confusing that it's named "arcfour" rather than "arcfour-128", but the description The "arcfour" is the Arcfour stream cipher with 128 bit keys. makes it clear which key length is used. (Small nit: "cipher" should be inserted like The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys. ) For improved clarity, one could also add the arcfour keylength to the table. Before: ... serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode ... After: ... serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher with 128 bit key idea-cbc OPTIONAL IDEA in CBC mode ... > If this stipulation is meant to apply to all future algorithms, it > seems like a particularly bad idea. Is it intended to prevent me > defining "arcfour-256@bjh21.me.uk" to be RC4 with a 256-bit key, for > instance? If not, what does it do? I agree this doesn't make sense. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 3 05:56:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05931 for ; Thu, 3 Mar 2005 05:56:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3BD785219; Thu, 3 Mar 2005 10:56:09 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by mail.netbsd.org (Postfix) with ESMTP id 091615164 for ; Thu, 3 Mar 2005 10:56:07 +0000 (UTC) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel12.hp.com (Postfix) with ESMTP id B58BA40CB93 for ; Thu, 3 Mar 2005 02:56:01 -0800 (PST) Received: from laddie.tcpip.zko.hp.com (unknown [16.116.92.55]) by mailrelay01.cac.cpqcorp.net (Postfix) with SMTP id 633ED480 for ; Thu, 3 Mar 2005 02:56:01 -0800 (PST) Date: Thu, 3 Mar 2005 05:14:04 -0500 (EST) Message-Id: <05030305140465_21400454@ucx.lkg.dec.com> From: Karol.Zielonko@hp.com (Karol Zielonko) To: IETF-SSH@NetBSD.org Subject: Where to find protocol spec for SCP under SSH-1 X-VMS-To: IETF-SSH@NETBSD.ORG X-VMS-True-From: zielonko@ucx.lkg.dec.com (Karol Zielonko) Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm a relative newbie to the SSH space. At the highest level I think I'm looking for an old SSH-1 protocol specification to try to understand how SCP worked. A customer has hit the problem described at: http://www.snailbook.com/faq/scp-ossh-to-ssh2.auto.html with our SSH implementation (OpenVMS). In a nutshell this problem involves the SCP client (RH Linux in our case) sending "scp -f file.name" as an rexec style command to our SSH-2 only implementation. (Our implementation expects SCP to be implemented "layered" on SFTP.) Our implementation is fprintfing the following text to stderr: tcpip$ssh_scp2.exe: warning: Executing scp1 compatibility. tcpip$ssh_scp2.exe: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). In our implementation of SSH stderr turns out to be the PTY going to the SSH server parent process and all data sent to the PTY from the child (which is running the "scp -f file.name" command) ends up being sent over the encrypted channel to the client. However the data is not being displayed to the client as an error message. Instead we get this at the client: [user@rhlinux user]$ scp user@serverhost:z.z z.z protocol error: unexpected [user@rhlinux user]$ What I would like to see is: [user@rhlinux user]$ scp user@serverhost:z.z z.z tcpip$ssh_scp2.exe: warning: Executing scp1 compatibility. tcpip$ssh_scp2.exe: FATAL: Executing ssh1 in compatibility mode failed (Check that scp1 is in your PATH). [user@rhlinux user]$ Well, we should change our code to use different text, since scp1 is simply not implemented on our platform. So we might have: [user@rhlinux user]$ scp user@serverhost:z.z z.z tcpip$ssh_scp2.exe: FATAL: scp1 compatibility mode is not supported [user@rhlinux user]$ The point is that I want to be able to package the error text data being sent back to the client in such a way that the client recognizes the data as error text and displays it to the user as such. Is there a way to do this? I would think that to find out if there is I need to know what sort of data the scp client is expecting to see on the wire. Perhaps there is a provision for the server to send an error text message? In some debug traces I have seen that the client is apparently sending a single byte of 0 to our side at the beginning of all of this. Some sort of SCP message? In some other cases I've seen it send its own error text, "protocol error: unexpected ", with a single leading byte of 1. Here's a dump from our ssh server parent log: debug: SshUnixFdStream/SSHUNIXFDSTREAM.C:663: ssh_stream_fd_write wrote 43 bytes debug: SshUnixFdStream/SSHUNIXFDSTREAM.C:665: data: debug: 00000000: 0173 6370 3a20 7072 6f74 6f63 6f6c 2065 .scp: protocol e debug: 00000010: 7272 6f72 3a20 756e 6578 7065 6374 6564 rror: unexpected debug: 00000020: 203c 6e65 776c 696e 653e 0a . Note that the first byte of the sequence is 01. Is this an old-style scp message type byte? I dunno. Anyway I think I need a spec to figure it out. Thanks in advance, Karol From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 3 16:28:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17034 for ; Thu, 3 Mar 2005 16:28:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EFC91535C; Thu, 3 Mar 2005 21:27:57 +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 A629C5164 for ; Thu, 3 Mar 2005 21:27:53 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 844731B8028; Thu, 3 Mar 2005 22:27:22 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 02002-01-41; Thu, 3 Mar 2005 22:27:12 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 6BC181B802E; Thu, 3 Mar 2005 22:27:12 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j23LRBXa018086; Thu, 3 Mar 2005 22:27:11 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j23LR6Ds018081; Thu, 3 Mar 2005 22:27:06 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Karol.Zielonko@hp.com (Karol Zielonko) Cc: IETF-SSH@NetBSD.org Subject: Re: Where to find protocol spec for SCP under SSH-1 References: <05030305140465_21400454@ucx.lkg.dec.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 03 Mar 2005 22:26:58 +0100 In-Reply-To: <05030305140465_21400454@ucx.lkg.dec.com> Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Karol.Zielonko@hp.com (Karol Zielonko) writes: > In our implementation of SSH stderr turns out to be the PTY going to the SSH > server parent process and all data sent to the PTY from the child (which is > running the "scp -f file.name" command) ends up being sent over the encrypted > channel to the client. I guess this is where you get stderr and stdout mixed up. > The point is that I want to be able to package the error text data being sent > back to the client in such a way that the client recognizes the data as error > text and displays it to the user as such. I think the Right Way to do this is to have sshd spawn the process with a pty only for its stdin and stdout, and a plain pipe for stderr. And then forward data from the stderr pipe as SSH_MSG_CHANNEL_EXTENDED_DATA. Then the ssh client end has sufficient information to do the right thing. And I'd expect most instances of foo-over-ssh will Just Work, as the ssh client will forward data between the ssh connection and the foo application, and direct and SSH_MSG_CHANNEL_EXTENDED_DATA to the terminal. Unfortunately, on the server side, some interactive programs, e.g. bash, are confused if stderr is a pipe or other non-tty. If that is a problem, you can have sshd create *two* pty pairs, one for stdin/stdout, and one for stderr. Slightly overkill, but it should work. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 3 19:30:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03329 for ; Thu, 3 Mar 2005 19:30:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B5A09539C; Fri, 4 Mar 2005 00:30:08 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by mail.netbsd.org (Postfix) with ESMTP id 80B065373 for ; Fri, 4 Mar 2005 00:30:06 +0000 (UTC) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id D45D399F for ; Thu, 3 Mar 2005 16:23:40 -0800 (PST) Received: from tcpi64.tcpip.zko.hp.com (unknown [16.116.92.210]) by mailrelay01.cce.cpqcorp.net (Postfix) with SMTP id 1B24B1168 for ; Thu, 3 Mar 2005 18:23:40 -0600 (CST) Received: from zielonkoxp.americas.hpqcorp.net (16.115.193.255) by tcpi64.tcpip.zko.hp.com (V5.5-11); Thu, 3 Mar 2005 19:23:37 -0500 (EST) Message-ID: <002e01c52050$6919d3e0$6401a8c0@americas.cpqcorp.net> From: "Karol Zielonko" To: References: <04d501c5204a$b1983c20$d7b7fea9@devel.testdomain> Subject: Re: Where to find protocol spec for SCP under SSH-1 Date: Thu, 3 Mar 2005 19:23:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Thanks. After doing a lot of poking around on the web I was able to find an SSH1 protocol spec but it made no explicit mention of scp1. I was unable to find a spec for scp1. I did find this rather unencouraging text: The protocol it uses (let's call it "SCP1") remained entirely undocumented, even when Ylönen wrote the first RFC documenting the SSH-1 protocol. at http://www.hn.edu.cn/book/NetWork/NetworkingBookshelf_2ndEd/ssh/ch03_08.htm After a few hacks I managed to get We now prepend the \001 byte to the string "scp1 compatibility mode is not supported." in the SCP2 mainline, running in the SSH server child process, and write the text to stderr when -f or -t are being employed. (For our implementation on OpenVMS stderr and stdout both point to the PTY.) After solving some problems with the VMS PTY driver polluting the text with CRLFs I managed to get the text coming cleanly out of the PTY code (no formatting characters added) into the SSH server parent process. This data is sent over the channel to the client and, voila: [user@rhlinux user]$ scp user@16.116.92.54:z.z z.z scp1 compatibility mode is not supported. lost connection [user@rhlinux user]$ This is not graceful, granted, with the lost connection but for our purposes it's fine. Thanks for the confirmation. Karol Zielonko ----- Original Message ----- From: "denis bider" To: "'Karol Zielonko'" ; Sent: Thursday, March 03, 2005 6:42 PM Subject: RE: Where to find protocol spec for SCP under SSH-1 > > Note that the first byte of the sequence is 01. Is this an > > old-style scp message type byte? > > Yes, you need to prefix error messages with \001. I also think that you can > just send them to stdout. > > denis > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 3 19:57:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05706 for ; Thu, 3 Mar 2005 19:57:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 939DA5384; Fri, 4 Mar 2005 00:57:48 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from glatton.cnchost.com (glatton.cnchost.com [207.155.248.47]) by mail.netbsd.org (Postfix) with ESMTP id 2FD0F5186 for ; Fri, 4 Mar 2005 00:57:47 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by glatton.cnchost.com id SAA27640; Thu, 3 Mar 2005 18:42:34 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Karol Zielonko'" , Subject: RE: Where to find protocol spec for SCP under SSH-1 Date: Fri, 4 Mar 2005 00:42:41 +0100 Message-ID: <04d501c5204a$b1983c20$d7b7fea9@devel.testdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <05030305140465_21400454@ucx.lkg.dec.com> Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Note that the first byte of the sequence is 01. Is this an > old-style scp message type byte? Yes, you need to prefix error messages with \001. I also think that you can just send them to stdout. denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 4 02:47:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07416 for ; Fri, 4 Mar 2005 02:47:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F34E053F5; Fri, 4 Mar 2005 07:47:21 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 196C65186 for ; Fri, 4 Mar 2005 07:47:19 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 479651B803C; Fri, 4 Mar 2005 08:47:08 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 16492-01-26; Fri, 4 Mar 2005 08:46:58 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 4F3B91B802F; Fri, 4 Mar 2005 08:46:58 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j247kvXa029766; Fri, 4 Mar 2005 08:46:57 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j247kqwK029763; Fri, 4 Mar 2005 08:46:52 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Karol Zielonko" Cc: Subject: Re: Where to find protocol spec for SCP under SSH-1 References: <04d501c5204a$b1983c20$d7b7fea9@devel.testdomain> <002e01c52050$6919d3e0$6401a8c0@americas.cpqcorp.net> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 04 Mar 2005 08:46:51 +0100 In-Reply-To: <002e01c52050$6919d3e0$6401a8c0@americas.cpqcorp.net> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 "Karol Zielonko" writes: > The protocol it uses (let's call it "SCP1") remained entirely undocumented, > even when Ylönen wrote the first RFC documenting the SSH-1 protocol. If I have understood history correctly, scp uses is exactly the same protocol as rcp. That may help you when searching for a spec. But I still think you're attacking the problem at the wrong level; the ssh implementation shouldn't need to know anything about the structure in the contents of a data channel. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Mar 5 08:46:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15665 for ; Sat, 5 Mar 2005 08:46:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 753B1547D; Sat, 5 Mar 2005 13:46:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mail.netbsd.org (Postfix) with ESMTP id CB634515B for ; Sat, 5 Mar 2005 13:46:23 +0000 (UTC) Received: from marketmailer ([207.253.108.88]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0ICV00KTVPWPDD@VL-MO-MR010.ip.videotron.ca> for ietf-ssh@netbsd.org; Sat, 05 Mar 2005 07:41:15 -0500 (EST) Date: Sat, 05 Mar 2005 06:31:27 -0500 From: Nagra Offshore Subject: Re:HardWare Upgrade Nagra2 Software Atmegas/Fta/Rom UpGrades To: Private Member Premium Message-id: <3857-22005365113126923@marketmailer> Organization: Nagra Offshore MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7BIT Members And Fellow Testers, -->>NagraCode.com--<< Urgent News Has Erupted In our community of the Nagra 2 Stream commecing for Bev(BellxPressVu) and also Dishnet(Charlies Den).We are proud to announce with all our current members that are signed are currentls very very happy with our servuce non the less performance.We have N2 Compatible software at -->>NagraCode.com--<< and are encouraging you to join.We have NEW product lineup comin This Sundat Fta Recievers and Much More. -->>NagraCode.com--<< We ensure safety and Coding for all smartcards and Fta reciever presently up and running with no flaw whatsoever.Signup today and get full Access to P4/P5 testing files to prepare you for the near near future as the breakthrough has commence.Dishnet Bev DTV testing is our game and our Goal Signup and get FULL PREMIUM ACCESS TODAY... -->>NagraCode.com--<< Signature That Is Digital Spectru-uiweuiyth jhheuyeoouwoeuop From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Mar 6 17:22:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02477 for ; Sun, 6 Mar 2005 17:22:40 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8CCFA5284; Sun, 6 Mar 2005 22:22:35 +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 DC73F51E2 for ; Sun, 6 Mar 2005 22:22:33 +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 j26MMXX8006948 for ; Sun, 6 Mar 2005 15:22:33 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j26MMWQp022792; Sun, 6 Mar 2005 17:22:32 -0500 (EST) Subject: UTF8 username/password issue summary From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1110147677.77748.35.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Sun, 06 Mar 2005 16:21:19 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit The current userauth document specifies the use of unnormalized UTF-8 on the wire and recommends the use of saslprep to normalize them on the server end. This allows for considerable flexibility in implementation; for passwords, you may even be able to store per-user hints for this normalization. Ultimately, however, local OS considerations on the server will dominate and may constrain what can be done on the server. There was considerable discussion of this approach in Jan/Feb of this year. My conclusion from this discussion is that there is no known technical problem with a "just send unnormalized utf8" approach; however, because there's a general shortage of implementation experience with non-USASCII usernames and passwords, I don't have a whole lot of confidence that it won't need tweaks in the future. As an aside, the userauth doc mentions the normalization issue for user names only in passing (during the password discussion). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 8 10:42:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08042 for ; Tue, 8 Mar 2005 10:42:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E1D43528F; Tue, 8 Mar 2005 15:42:42 +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 4FDEB51CE for ; Tue, 8 Mar 2005 15:42:41 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j28FgeNV018678 for ; Tue, 8 Mar 2005 07:42:40 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j28FgeOp029123; Tue, 8 Mar 2005 10:42:40 -0500 (EST) Subject: Very Late Agenda: meeting in Minneapolis From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1110296554.590.140.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Mar 2005 09:42:37 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We will be meeting on Thursday afternoon. As a reminder, the core drafts remain stalled waiting for the IPR working group to clarify and correct the trademark policy in RFC3667. In the meantime we've been finding and fixing nits in the core drafts. (We seem to be suffering from a general lack of energy.) The IETF tools team has been working on some improved tools for document status tracking; see http://tools.ietf.org/wg/secsh/ to see the sorry state we're in -- partly my fault. Proposed agenda: 5 minutes: agenda bashing & bluesheets 5 minutes: document status 20 minutes: review of nits fixes to core drafts 10 minutes: review milestones Send comments/proposed additions to me. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 8 14:59:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09281 for ; Tue, 8 Mar 2005 14:59:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2D95051D9; Tue, 8 Mar 2005 19:59:10 +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 C72065171 for ; Tue, 8 Mar 2005 19:59:07 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 12:13:09 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28Jx3uC007696 for ; Tue, 8 Mar 2005 11:59:04 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01548 for ; Tue, 8 Mar 2005 11:59:05 -0800 (PST) Date: Tue, 8 Mar 2005 11:59:05 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Key lengths for algorithms for variable-length keys In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, On Thu, 3 Mar 2005, [iso-8859-1] Niels M=F6ller wrote: > Ben Harris writes: > > > transport-23, in section 7.2, says: > > > > 128 bits (16 bytes) MUST be used for algorithms with variable-lengt= h > > keys. The only variable key length algorithm defined in this > > document is arcfour). > > I agree this is awkward. I'd suggest the paragraph is cut down from > > Key data MUST be taken from the beginning of the hash output. 128 > bits (16 bytes) MUST be used for algorithms with variable-length > keys. The only variable key length algorithm defined in this > document is arcfour). For other algorithms, as many bytes as are > needed are taken from the beginning of the hash value. [...] > > to > > Key data MUST be taken from the beginning of the hash output. As > many bytes as are needed are taken from the beginning of the hash > value. [...] I'll make these changes unless I hear objections. > > For key length, we already have the general recommendation "All ciphers > SHOULD use keys with an effective key length of 128 bits or more." in > 6.3. For arcfour in particular, it may be a little confusing that it's > named "arcfour" rather than "arcfour-128", but the description > > The "arcfour" is the Arcfour stream cipher with 128 bit keys. > > makes it clear which key length is used. (Small nit: "cipher" should be > inserted like > > The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys. OK. > > ) > > For improved clarity, one could also add the arcfour keylength to the > table. Before: > > ... > serpent128-cbc OPTIONAL Serpent with 128-bit key > arcfour OPTIONAL the ARCFOUR stream cipher > idea-cbc OPTIONAL IDEA in CBC mode > ... > > After: > > ... > serpent128-cbc OPTIONAL Serpent with 128-bit key > arcfour OPTIONAL the ARCFOUR stream cipher > with 128 bit key > idea-cbc OPTIONAL IDEA in CBC mode > ... OK. I also see that about half of the occurances of bit lengths are of the form "nnn-bit" and the other half are of the form "nnn bit". All of the occurances of byte lengths are of the format of "mmm bytes". Unless I hear objections, I'm going to change these to be "nnn bit" and clean up the syntax a bit. As in the above, it will be: Formerly: serpent128-cbc OPTIONAL Serpent with 128-bit key Proposed: serpent128-cbc OPTIONAL Serpent with a 128 bit key > > > If this stipulation is meant to apply to all future algorithms, it > > seems like a particularly bad idea. Is it intended to prevent me > > defining "arcfour-256@bjh21.me.uk" to be RC4 with a 256-bit key, for > > instance? If not, what does it do? > > I agree this doesn't make sense. Does anything further need to be edited or clarified if the above changes are made? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 8 15:04:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10569 for ; Tue, 8 Mar 2005 15:04:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D592D51EC; Tue, 8 Mar 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 EA3A25171 for ; Tue, 8 Mar 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 j28K4Nhl029958 for ; Tue, 8 Mar 2005 13:04:23 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j28K4MOp012537; Tue, 8 Mar 2005 15:04:23 -0500 (EST) Subject: MP3 audio streaming for IETF 62 From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1110311952.590.221.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Mar 2005 14:04:19 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI, for folks who not in Minneapolis who want to listen in, all meeting rooms here are equipped to stream audio in MP3 format. We will be meeting starting at 13:00 CST (19:00 GMT) on Thursday, March 10th. The audio is one-way, but feedback can be made through the Jabber/XMPP chat rooms: http://www.xmpp.org/ietf-chat.html Feedback through xmpp on audio quality ("Use the !$@#@# mike") as well as on the technical content of the meeting is appropriate. - Bill -----Forwarded Message----- From: Joel Jaeggli To: ietf@ietf.org Subject: MP3 audio streaming for IETF 62 Date: Sun, 06 Mar 2005 06:04:33 -0800 Just to recap: IETF 62 inagurates a new streaming effort. Instead of covering only two rooms it is our intention to cover all eight. Instead of multicast video delivery, unicast audio-only. It is our hope that this new effort will provide more useful timely and accessible access to the proceedings of the IETF as they happen. An internet draft decribing what the effort is intended to do, and the efforts up to this point is available at: http://www.ietf.org/internet-drafts/draft-jaeggli-ietftv-ng-00.txt Streams are delivered as 64Kb/s unicast-http-streamed mp3 audio, a popular and relativly standard way to deliver internet radio. Most platforms should have a client immediatly available (windows media player, quicktime, real, winamp, vlc, mplayer, zinf etc) capable of playing back the stream. Information on getting access to the streams is available from the webpage located at: http://videolab.uoregon.edu/events/ietf/ietf62.html Streaming begins March 7th 0900 CST 1500 GMT Regards Joel Jaeggli -- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 12:14:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27290 for ; Wed, 9 Mar 2005 12:14:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BF74952F9; Wed, 9 Mar 2005 17:14:08 +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 1FE9252A1 for ; Wed, 9 Mar 2005 17:14:07 +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 j29HE4ZO021611; Wed, 9 Mar 2005 09:14:04 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j29HE3Op000015; Wed, 9 Mar 2005 12:14:03 -0500 (EST) Subject: moving auth-kbdinteract forward. From: Bill Sommerfeld To: frank@google.com, maf@apgate.com Cc: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ASCII Message-Id: <1110388438.4733.783.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 09 Mar 2005 11:14:00 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Refer to: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-auth-kbdinteract/ http://tools.ietf.org/wg/secsh/draft-ietf-secsh-auth-kbdinteract/draft-ietf-secsh-auth-kbdinteract-06.nits.txt https://datatracker.ietf.org/public/pidtracker.cgi?command=search_list&search_button=SEARCH&sub_state_id=6&search_filename=draft-ietf-secsh-auth-kbdinteract select "details" and then "IESG evaluation record". The comments appear to be relevant to -05 of the draft, though for some reason the status lists -06 (appears to be a tools glitch). Many of the IESG comments have been dealt with in -06; however, I think we need to apply our recent discussions relating to UTF8 usernames, passwords, etc., to this draft as well. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 12:27:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29034 for ; Wed, 9 Mar 2005 12:27:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9CB5152CE; Wed, 9 Mar 2005 17:27: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 0F596528F for ; Wed, 9 Mar 2005 17:27:48 +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 j29HRhhl014949; Wed, 9 Mar 2005 10:27:43 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j29HRfOp003925; Wed, 9 Mar 2005 12:27:41 -0500 (EST) Subject: moving dh-group-exchange forward. From: Bill Sommerfeld To: markus@openbsd.org, provos@citi.umich.edu, wsimpson@greendragon.com Cc: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1110389257.4733.791.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 09 Mar 2005 11:27:37 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We need a new revision of this document to resolve IESG concerns and to adapt to new process guidelines. The new IETF tools team has a status page up for this document at: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-dh-group-exchange/ for nits, see: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-dh-group-exchange/draft-ietf-secsh-dh-group-exchange-04.nits.txt for IESG concerns, see: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1151&filename=draft-ietf-secsh-dh-group-exchange it appears that the document is for the most part acceptable; it just needs to be rebuilt to current format standards (3667/3668) and have the current copyright notice replaced. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 15:49:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19105 for ; Wed, 9 Mar 2005 15:49:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BEA1E533B; Wed, 9 Mar 2005 20:49:14 +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 049CB5333 for ; Wed, 9 Mar 2005 20:49:12 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2005 14:06:28 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107734400"; d="scan'208"; a="233238430:sNHT21566812" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j29Kn7q8025183 for ; Wed, 9 Mar 2005 12:49:07 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA14604 for ; Wed, 9 Mar 2005 12:49:09 -0800 (PST) Date: Wed, 9 Mar 2005 12:49:09 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Arcfour & RC4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I went to the IPR WG meeting on Monday and learned lots. But enough about me... The current [TRANS] document references Arcfour as an acceptable algorithm. It also references RC4 in a somewhat oblique way as follows: The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and should be used with caution. The parts about RC4 sound editorial to me. I also don't think that the document should say that there is a "belief" in compatability; they either are provably compatible, or the document should remain silent on that point. As such, I propose to change the text to the following: The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys [SCHNEIER]. Arcfour has problems with weak keys, and should be used with caution. Please let me know if you disagree with this proposal. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 17:09:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25701 for ; Wed, 9 Mar 2005 17:09:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7D3425341; Wed, 9 Mar 2005 22:09:11 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by mail.netbsd.org (Postfix) with ESMTP id AD7975195 for ; Wed, 9 Mar 2005 22:09:09 +0000 (UTC) Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO010B4E; 9 Mar 05 17:17:47 -0500 Received: from spooler by Lamicro.com (Mercury/32 v3.32); 9 Mar 05 17:17:39 -0500 Received: from connotech.com (209.71.204.124) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG010B4C; 9 Mar 05 17:17:32 -0500 Message-ID: <422F7A59.4030307@connotech.com> Date: Wed, 09 Mar 2005 17:36:09 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: "Host name" definition somewhere in the ID set? 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 Dear all: As an outsider of the SSH protocol community (if any), I looked at the latest Internet-Drafts. I was looking at the initial trust on a host public key (well explained in tha architecture draft at 4.1 Host Keys). My question refers to the definition of a server host name, from a security perspective. It should be in a security certificate sent by the SSH server. Q.1 Should "host name" be defined? Q.2 Should the specification mandate that security certificates MUST use the so-defined "host name" perhaps with some encoding? Sorry if I should have found this information in one of the references. The OpenPGP certificate specification isn't very explicit. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 17:22:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26701 for ; Wed, 9 Mar 2005 17:22:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2BD1A5312; Wed, 9 Mar 2005 22:22:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from cz.mit.edu (wireless-130-129-135-90.ietf62.ietf.org [130.129.135.90]) by mail.netbsd.org (Postfix) with ESMTP id DA13B5195 for ; Wed, 9 Mar 2005 22:22:10 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 38EEBE0075; Wed, 9 Mar 2005 16:45:27 -0500 (EST) To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 References: From: Sam Hartman Date: Wed, 09 Mar 2005 16:45:27 -0500 In-Reply-To: (Chris Lonvick's message of "Wed, 9 Mar 2005 12:49:09 -0800 (PST)") 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 I think it is valuable to point out to people that arcfour is rc4. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 18:08:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00595 for ; Wed, 9 Mar 2005 18:08:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 41868536B; Wed, 9 Mar 2005 23:08:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yancy.b70.net (yancy.pkiclue.com [209.172.115.117]) by mail.netbsd.org (Postfix) with ESMTP id 40B6C516F for ; Wed, 9 Mar 2005 23:08:20 +0000 (UTC) Received: from [127.0.0.1] (IDENT:rodney@localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id PAA13644; Wed, 9 Mar 2005 15:12:04 -0800 Message-ID: <422F8008.6090905@canola-jones.com> Date: Wed, 09 Mar 2005 15:00:24 -0800 From: Rodney Thayer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This is an artifact of history. Arcfour was brought into the IETF world back in the TLS days. The folks at SSH and I coded ARCFOUR, from Schneier, so that we'd have a copy of the algorithm that wasn't tied up inside the RSA intellectual property. The term "RC4" is trade marked by RSA. The algorithm leaked into the public domain several years ago, in effect (#include ) The text you refer to sounds like the ARCFOUR draft from way back when ;-) Chris Lonvick wrote: > Hi, > > I went to the IPR WG meeting on Monday and learned lots. But enough about > me... > > The current [TRANS] document references Arcfour as an acceptable > algorithm. It also references RC4 in a somewhat oblique way as follows: > > The "arcfour" is the Arcfour stream cipher with 128 bit keys. The > Arcfour cipher is believed to be compatible with the RC4 cipher > [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and > should be used with caution. > > The parts about RC4 sound editorial to me. I also don't think that the > document should say that there is a "belief" in compatability; they either > are provably compatible, or the document should remain silent on that > point. As such, I propose to change the text to the following: > > The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys > [SCHNEIER]. Arcfour has problems with weak keys, and should be used > with caution. > > Please let me know if you disagree with this proposal. > > Thanks, > Chris > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 18:29:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03127 for ; Wed, 9 Mar 2005 18:29:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id ECDBA537B; Wed, 9 Mar 2005 23:28:34 +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 E47695368 for ; Wed, 9 Mar 2005 23:28:32 +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 j29NSUX8021502; Wed, 9 Mar 2005 16:28:31 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j29NSUQp008599; Wed, 9 Mar 2005 18:28:30 -0500 (EST) Subject: Re: "Host name" definition somewhere in the ID set? From: Bill Sommerfeld To: Thierry Moreau Cc: "ietf-ssh@netbsd.org" In-Reply-To: <422F7A59.4030307@connotech.com> References: <422F7A59.4030307@connotech.com> Content-Type: text/plain Message-Id: <1110410902.7932.2.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 09 Mar 2005 17:28:25 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-03-09 at 16:36, Thierry Moreau wrote: > As an outsider of the SSH protocol community (if any), I looked at the > latest Internet-Drafts. I was looking at the initial trust on a host > public key (well explained in tha architecture draft at 4.1 Host Keys). > > My question refers to the definition of a server host name, from a > security perspective. It should be in a security certificate sent by the > SSH server. specifications for optional use of certificates of any sort with SSH would be desirable, but everyone who has stepped up and volunteered to write a draft on how to do this has later had to apologize for not having time to follow through... are you volunteering? :-) - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 18:44:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04287 for ; Wed, 9 Mar 2005 18:44:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 24C05538A; Wed, 9 Mar 2005 23:44:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.netbsd.org (Postfix) with ESMTP id 342435383 for ; Wed, 9 Mar 2005 23:44:32 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2005 15:59:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,152,1107763200"; d="scan'208"; a="618628478:sNHT19400260" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j29NiTZV025688; Wed, 9 Mar 2005 15:44:30 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA16390; Wed, 9 Mar 2005 15:44:29 -0800 (PST) Date: Wed, 9 Mar 2005 15:44:29 -0800 (PST) From: Chris Lonvick To: Rodney Thayer Cc: ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 In-Reply-To: <422F8008.6090905@canola-jones.com> Message-ID: References: <422F8008.6090905@canola-jones.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Rodney, Can you tell me why draft-kaukonen-cipher-arcfour-03.txt expired rather than being published as an RFC? IANAL either. Thanks, Chris On Wed, 9 Mar 2005, Rodney Thayer wrote: > This is an artifact of history. > > Arcfour was brought into the IETF world back in the TLS days. The folks > at SSH and I coded ARCFOUR, from Schneier, so that we'd have a copy of > the algorithm that wasn't tied up inside the RSA intellectual property. > > The term "RC4" is trade marked by RSA. The algorithm leaked into the > public domain several years ago, in effect > (#include ) > > The text you refer to sounds like the ARCFOUR draft from way back when ;-) > > Chris Lonvick wrote: > > Hi, > > > > I went to the IPR WG meeting on Monday and learned lots. But enough about > > me... > > > > The current [TRANS] document references Arcfour as an acceptable > > algorithm. It also references RC4 in a somewhat oblique way as follows: > > > > The "arcfour" is the Arcfour stream cipher with 128 bit keys. The > > Arcfour cipher is believed to be compatible with the RC4 cipher > > [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and > > should be used with caution. > > > > The parts about RC4 sound editorial to me. I also don't think that the > > document should say that there is a "belief" in compatability; they either > > are provably compatible, or the document should remain silent on that > > point. As such, I propose to change the text to the following: > > > > The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys > > [SCHNEIER]. Arcfour has problems with weak keys, and should be used > > with caution. > > > > Please let me know if you disagree with this proposal. > > > > Thanks, > > Chris > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 19:19:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07753 for ; Wed, 9 Mar 2005 19:19:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8BE4052E5; Thu, 10 Mar 2005 00:19:01 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yancy.b70.net (yancy.pkiclue.com [209.172.115.117]) by mail.netbsd.org (Postfix) with ESMTP id 6726A516F for ; Thu, 10 Mar 2005 00:18:59 +0000 (UTC) Received: from [127.0.0.1] (IDENT:rodney@localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id QAA14007; Wed, 9 Mar 2005 16:30:08 -0800 Message-ID: <422F9253.4050204@canola-jones.com> Date: Wed, 09 Mar 2005 16:18:27 -0800 From: Rodney Thayer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 References: <422F8008.6090905@canola-jones.com> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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 Basically because there was no clear mechanism at the time to get it to informational. The IETF has been a rat's nest of arcane, undocumented, and inconsistent procedures, of course, and it is apparently getting better, but at the time we couldn't figure out how to get it to RFC status. That's the vulnerability in the IETF - it's easier to route around it than work through it. Chris Lonvick wrote: > Hi Rodney, > > Can you tell me why draft-kaukonen-cipher-arcfour-03.txt expired rather > than being published as an RFC? IANAL either. > > Thanks, > Chris > > On Wed, 9 Mar 2005, Rodney Thayer wrote: > > >>This is an artifact of history. >> >>Arcfour was brought into the IETF world back in the TLS days. The folks >>at SSH and I coded ARCFOUR, from Schneier, so that we'd have a copy of >>the algorithm that wasn't tied up inside the RSA intellectual property. >> >>The term "RC4" is trade marked by RSA. The algorithm leaked into the >>public domain several years ago, in effect >>(#include ) >> >>The text you refer to sounds like the ARCFOUR draft from way back when ;-) >> >>Chris Lonvick wrote: >> >>>Hi, >>> >>>I went to the IPR WG meeting on Monday and learned lots. But enough about >>>me... >>> >>>The current [TRANS] document references Arcfour as an acceptable >>>algorithm. It also references RC4 in a somewhat oblique way as follows: >>> >>> The "arcfour" is the Arcfour stream cipher with 128 bit keys. The >>> Arcfour cipher is believed to be compatible with the RC4 cipher >>> [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and >>> should be used with caution. >>> >>>The parts about RC4 sound editorial to me. I also don't think that the >>>document should say that there is a "belief" in compatability; they either >>>are provably compatible, or the document should remain silent on that >>>point. As such, I propose to change the text to the following: >>> >>> The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys >>> [SCHNEIER]. Arcfour has problems with weak keys, and should be used >>> with caution. >>> >>>Please let me know if you disagree with this proposal. >>> >>>Thanks, >>>Chris >>> >>> >> > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 19:53:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10330 for ; Wed, 9 Mar 2005 19:53:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6AA175387; Thu, 10 Mar 2005 00:53:50 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from SMTP.Lamicro.com (66-163-8-251.ip.tor.radiant.net [66.163.8.251]) by mail.netbsd.org (Postfix) with ESMTP id 2DFB5516F for ; Thu, 10 Mar 2005 00:53:47 +0000 (UTC) Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO010D0A; 9 Mar 05 20:02:24 -0500 Received: from spooler by Lamicro.com (Mercury/32 v3.32); 9 Mar 05 20:02:19 -0500 Received: from connotech.com (209.71.204.101) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG010D09; 9 Mar 05 20:02:09 -0500 Message-ID: <422FA0ED.8080609@connotech.com> Date: Wed, 09 Mar 2005 20:20:45 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld , "ietf-ssh@netbsd.org" Subject: Re: "Host name" definition somewhere in the ID set? References: <422F7A59.4030307@connotech.com> <1110410902.7932.2.camel@unknown.hamachi.org> In-Reply-To: <1110410902.7932.2.camel@unknown.hamachi.org> 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 Bill Sommerfeld wrote: > On Wed, 2005-03-09 at 16:36, Thierry Moreau wrote: > > >>As an outsider of the SSH protocol community (if any), I looked at the >>latest Internet-Drafts. I was looking at the initial trust on a host >>public key (well explained in tha architecture draft at 4.1 Host Keys). >> >>My question refers to the definition of a server host name, from a >>security perspective. It should be in a security certificate sent by the >>SSH server. > > > specifications for optional use of certificates of any sort with SSH would be > desirable, but everyone who has stepped up and volunteered to write a draft > on how to do this has later had to apologize for not having time to follow > through... > > are you volunteering? :-) > > - Bill Actually, I found the security certificate usage in SSH IDs well explained. My single concern is that "host name" is not defined anywhere in the SSH Internet drafts. This definition would be by reference to another document, I guess. May I apologize immediately for lack of voluntary contribution from my part. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 21:05:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16734 for ; Wed, 9 Mar 2005 21:05:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 390095394; Thu, 10 Mar 2005 02:05:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id 619CE516F for ; Thu, 10 Mar 2005 02:05:08 +0000 (UTC) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 18:04:05 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,152,1107763200"; d="scan'208"; a="166302671:sNHT1053153540" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2A243YO014131; Wed, 9 Mar 2005 18:04:03 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA17859; Wed, 9 Mar 2005 18:04:03 -0800 (PST) Date: Wed, 9 Mar 2005 18:04:03 -0800 (PST) From: Chris Lonvick To: Rodney Thayer Cc: ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 In-Reply-To: <422F9253.4050204@canola-jones.com> Message-ID: References: <422F8008.6090905@canola-jones.com> <422F9253.4050204@canola-jones.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Then I'll go with the advice given by our AD and Jeffrey; no changes to the IDs for this. As there is a process to produce an Informational RFC now, (and we're kind'a cooling our heels for the moment,) would you consider resurrecting cipher-arcfour? It's still viable and would be a good reference for this and other efforts. I agree that the IETF process is improving - we're becoming an acknowledged Standards Developing Organization (SDO). Thanks, Chris On Wed, 9 Mar 2005, Rodney Thayer wrote: > Basically because there was no clear mechanism at the time to get it to > informational. The IETF has been a rat's nest of arcane, undocumented, > and inconsistent procedures, of course, and it is apparently getting > better, but at the time we couldn't figure out how to get it to RFC status. > > That's the vulnerability in the IETF - it's easier to route around it > than work through it. > > Chris Lonvick wrote: > > Hi Rodney, > > > > Can you tell me why draft-kaukonen-cipher-arcfour-03.txt expired rather > > than being published as an RFC? IANAL either. > > > > Thanks, > > Chris > > > > On Wed, 9 Mar 2005, Rodney Thayer wrote: > > > > > >>This is an artifact of history. > >> > >>Arcfour was brought into the IETF world back in the TLS days. The folks > >>at SSH and I coded ARCFOUR, from Schneier, so that we'd have a copy of > >>the algorithm that wasn't tied up inside the RSA intellectual property. > >> > >>The term "RC4" is trade marked by RSA. The algorithm leaked into the > >>public domain several years ago, in effect > >>(#include ) > >> > >>The text you refer to sounds like the ARCFOUR draft from way back when ;-) > >> > >>Chris Lonvick wrote: > >> > >>>Hi, > >>> > >>>I went to the IPR WG meeting on Monday and learned lots. But enough about > >>>me... > >>> > >>>The current [TRANS] document references Arcfour as an acceptable > >>>algorithm. It also references RC4 in a somewhat oblique way as follows: > >>> > >>> The "arcfour" is the Arcfour stream cipher with 128 bit keys. The > >>> Arcfour cipher is believed to be compatible with the RC4 cipher > >>> [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and > >>> should be used with caution. > >>> > >>>The parts about RC4 sound editorial to me. I also don't think that the > >>>document should say that there is a "belief" in compatability; they either > >>>are provably compatible, or the document should remain silent on that > >>>point. As such, I propose to change the text to the following: > >>> > >>> The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys > >>> [SCHNEIER]. Arcfour has problems with weak keys, and should be used > >>> with caution. > >>> > >>>Please let me know if you disagree with this proposal. > >>> > >>>Thanks, > >>>Chris > >>> > >>> > >> > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 9 21:16:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18026 for ; Wed, 9 Mar 2005 21:16:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BA04D5393; Thu, 10 Mar 2005 02:16:13 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from liandra.pc.cs.cmu.edu (wireless-130-129-131-221.ietf62.ietf.org [130.129.131.221]) by mail.netbsd.org (Postfix) with SMTP id 26852516F for ; Thu, 10 Mar 2005 02:16:12 +0000 (UTC) Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa06437; 9 Mar 2005 15:47 CST Date: Wed, 09 Mar 2005 16:47:34 -0500 From: Jeffrey Hutzelman To: Chris Lonvick , ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 Message-ID: <185050000.1110404854@liandra.pc.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (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, March 09, 2005 12:49:09 -0800 Chris Lonvick wrote: > Hi, > > I went to the IPR WG meeting on Monday and learned lots. But enough about > me... > > The current [TRANS] document references Arcfour as an acceptable > algorithm. It also references RC4 in a somewhat oblique way as follows: > > The "arcfour" is the Arcfour stream cipher with 128 bit keys. The > Arcfour cipher is believed to be compatible with the RC4 cipher > [SCHNEIER]. Arcfour (and RC4) has problems with weak keys, and > should be used with caution. > > The parts about RC4 sound editorial to me. I also don't think that the > document should say that there is a "belief" in compatability; they either > are provably compatible, or the document should remain silent on that > point. This is actually pretty standard boilerplate for this situation. I see no reason to make this change. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 06:13:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02305 for ; Thu, 10 Mar 2005 06:13:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 520895290; Thu, 10 Mar 2005 11:13:28 +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 C0B6D516F for ; Thu, 10 Mar 2005 11:13:26 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D9LbZ-0000vC-00; Thu, 10 Mar 2005 11:13:25 +0000 From: Ben Harris To: clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Arcfour & RC4 In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Thu, 10 Mar 2005 11:13:25 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >As such, I propose to change the text to the following: > > The "arcfour" cipher is the Arcfour stream cipher with 128 bit keys > [SCHNEIER]. Arcfour has problems with weak keys, and should be used > with caution. > >Please let me know if you disagree with this proposal. I disagree. The term "Arcfour" doesn't appear anywhere in [SCHNEIER] -- he calls it RC4. Thus, if we're referencing [SCHNEIER] for it, we need to mention the name RC4 as well. The current text isn't perfect, but it's good enough. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 07:39:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08774 for ; Thu, 10 Mar 2005 07:39:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1720D53AD; Thu, 10 Mar 2005 12:39:31 +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 BAF3D5178 for ; Thu, 10 Mar 2005 12:39:28 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D9Mwp-0003hD-00; Thu, 10 Mar 2005 12:39:27 +0000 From: Ben Harris To: clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Key lengths for algorithms for variable-length keys In-Reply-To: References: Organization: Linux Unlimited Message-Id: Date: Thu, 10 Mar 2005 12:39:27 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >> Key data MUST be taken from the beginning of the hash output. As >> many bytes as are needed are taken from the beginning of the hash >> value. [...] > >I'll make these changes unless I hear objections. Sounds good to me. >I also see that about half of the occurances of bit lengths are of the >form "nnn-bit" and the other half are of the form "nnn bit". All of the >occurances of byte lengths are of the format of "mmm bytes". Unless I >hear objections, I'm going to change these to be "nnn bit" and clean up >the syntax a bit. I don't really care, but: If you want an adjective, you should write "128-bit"; if you want a noun, write "128 bits". On this basis, the errors I can find are: one initialization vector). This is a block cipher with 8 byte (should be "8-byte") The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys (should be "128-bit") [SCHNEIER]. This is a block cipher with 8 byte blocks. (should be "8-byte") The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described [TWOFISH]. This is a block cipher (should be "256-bit") with 16 byte blocks. (should be ("16-byte") The "arcfour" is the Arcfour stream cipher with 128 bit keys. The (should be "128-bit") The value for 'dss_signature_blob' is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or (should be "160-bit-long integers" or "160-bit integers") The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit (should be "1024-bit") The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526] (2048bit (should be "2048-bit") in [SSH-ARCH]: Because MACs use a 32 bit sequence number, they might start to leak (should be "32-bit") >> > If this stipulation is meant to apply to all future algorithms, it >> > seems like a particularly bad idea. Is it intended to prevent me >> > defining "arcfour-256@bjh21.me.uk" to be RC4 with a 256-bit key, for >> > instance? If not, what does it do? >> >> I agree this doesn't make sense. > >Does anything further need to be edited or clarified if the above changes >are made? No. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 09:12:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17848 for ; Thu, 10 Mar 2005 09:12:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D262853E5; Thu, 10 Mar 2005 14:11:49 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-5.csi.cam.ac.uk (ppsw-5.csi.cam.ac.uk [131.111.8.135]) by mail.netbsd.org (Postfix) with ESMTP id 13D68516F for ; Thu, 10 Mar 2005 14:11:48 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:41599) by ppsw-5.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.135]:25) with esmtp id 1D9O5v-0006Xx-JL (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Thu, 10 Mar 2005 13:52:56 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1D9O5u-00038j-Gs for ietf-ssh@netbsd.org; Thu, 10 Mar 2005 13:52:54 +0000 Date: Thu, 10 Mar 2005 13:52:54 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Silliness: Some symbolic values undefined Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list It looks like the following message types don't have their numeric values specified anywhere in the current drafts, which is unfortunate: SSH_MSG_KEXDH_INIT 30 SSH_MSG_KEXDH_REPLY 31 I'd suggest that they be put back into the "Summary of Message Numbers" in [SSH-TRANS]. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 12:26:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08797 for ; Thu, 10 Mar 2005 12:26:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5A1D7542A; Thu, 10 Mar 2005 17:26: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 DC04D5420 for ; Thu, 10 Mar 2005 17:26:44 +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 j2AHQcZO006802; Thu, 10 Mar 2005 09:26:38 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2AHQbQp021543; Thu, 10 Mar 2005 12:26:37 -0500 (EST) Subject: Re: Silliness: Some symbolic values undefined From: Bill Sommerfeld To: Ben Harris Cc: "ietf-ssh@netbsd.org" In-Reply-To: References: Content-Type: text/plain Message-Id: <1110475590.10971.45.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 10 Mar 2005 11:26:32 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-10 at 07:52, Ben Harris wrote: > It looks like the following message types don't have their numeric values > specified anywhere in the current drafts, which is unfortunate: > > SSH_MSG_KEXDH_INIT 30 > SSH_MSG_KEXDH_REPLY 31 > > I'd suggest that they be put back into the "Summary of Message Numbers" in > [SSH-TRANS]. Whoops. Yes. Good catch. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 15:16:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00755 for ; Thu, 10 Mar 2005 15:16:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9152B5397; Thu, 10 Mar 2005 20:16:10 +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 C268951A2 for ; Thu, 10 Mar 2005 20:16:08 +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 j2AKG0X8016588; Thu, 10 Mar 2005 13:16:00 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2AKFxOp000340; Thu, 10 Mar 2005 15:15:59 -0500 (EST) Subject: IETF62 Secure Shell (secsh) WG session summary From: Bill Sommerfeld To: Russ Housley , Sam Hartman Cc: "ietf-ssh@netbsd.org" In-Reply-To: <6.2.0.14.2.20050307101011.05fceeb0@mail.binhost.com> References: <6.2.0.14.2.20050307101011.05fceeb0@mail.binhost.com> Content-Type: text/plain Message-Id: <1110485752.10971.145.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 10 Mar 2005 14:15:53 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Secure Shell (secsh) WG Session Summary IETF62. 10 March 2005. The Secure Shell WG met briefly on thursday. The meeting opened with an edict from Russ Housley to move the documents forward promptly. They've been stuck at the IESG review stage for approximately 18 months due to a series of blocking issues. The most recent blocking issue (since approximately October of last year) relates to the handling of trademark references from IETF documents, which was left underspecified by RFC3667. The IESG referred this question to the IPR working group. Russ stated that if revised documents are not ready for IESG review by six weeks from today, he would be forced to restart the AD review and IETF-wide last-call process. However, also said that we should proceed with revised documents under the assumption that the in-room consensus on trademark references in IPR on monday would stand. Several other extensions documents are waiting for revised drafts to be submitted at present; others have expired. Revised milestones were discussed and will be submitted shortly. Several previous milestones (relating to the ssh-agent and x.509 were dropped due to lack of interested editors. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 15:20:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01838 for ; Thu, 10 Mar 2005 15:20:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BBA4252D4; Thu, 10 Mar 2005 20:20:09 +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 E25DE53A3 for ; Thu, 10 Mar 2005 20:19:51 +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 j2AKJmhl000338; Thu, 10 Mar 2005 13:19:49 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2AKJmOp001144; Thu, 10 Mar 2005 15:19:48 -0500 (EST) Subject: IETF-62 Proceedings Submission: secsh slides From: Bill Sommerfeld To: proceedings@ietf.org Cc: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=-TptnbZ4KDfTyXREtzLYU" Message-Id: <1110485982.10971.153.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 10 Mar 2005 14:19:43 -0600 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-TptnbZ4KDfTyXREtzLYU Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit attached find the slides presented at the secsh wg meeting. - Bill --=-TptnbZ4KDfTyXREtzLYU Content-Disposition: attachment; filename=outline.pdf Content-Type: application/pdf; name=outline.pdf Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nEWQwU7DMAyG73kKHzeJBSdp0gYhhIYG4sABGonLLlOXrYV2pakqXh+nSocs y9Hn37L/DIBcAMZIterYwG4/MjiPTCD8MgEN0wgCEXRBj0JKhOBZyQaC80wqVQdbR7MWBLgTQ1AF bCgRpNbcaENCyU2Rg+vYqvTVFDys3RdTPMsMydyRcO3bdqaSaxSJ7lejr8Z6v056rRf9Zx++m8s5 cZvpxF9CP/1ESNsVbCjpHmm5lRlIS26tms943blnI2/SfKGWefIUkeDKJvJ2CFWddHjdLxF1ZBuh eK7iJi5ygXpuPtWHJtwlN/+3bZtkUXAjFotl33U+nHx7nFv0YaZIrfvx2nscpwuv+u4hanYO3lmM P8JBaZ9lbmRzdHJlYW0KZW5kb2JqCjcgMCBvYmoKMjc5CmVuZG9iagoxMyAwIG9iago8PC9MZW5n dGggMTQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzFlk1vEzEQhs/dX+EjHOrY M/488iXEEYjgnCabNqhJ1exW8PMZO/5EIKUVUEXard/MzoznfbzpPRNcMhE+6b7eD/eDFOz7INlu 0IJJIZh29IcDEOw4Dp+HexJjcLqt9+z1clh88kyy5XYQDCz37DJeBTOOUw5gyoc7suV+eMFeLr8N goO13oeY5ebva6+ux8NmFb9ggFxRQ+FKXSvBvfnv/UTt3ZJ9HHyYLoLjhnnnOUrF9r2A7JYEidz4 okgUMgRYywF0WRqI366HLCjLFY27PI46PX7Kn5YhXiHXsgnQunv+tGzyn4RSPz1e2uv6X5/FyW9s kUJxRBlt+fBlsYouxtkp7tCmYV6tppvd4XpxdfswTjfjOE/sIsSQpxZSjE4uOMTqwn53eJjHKXxz KWknApE64DZs+Z+5/kcSpDeeO9li0CmRA68VbzDwCmJA9iGvq1FZyU6mBNnnXKGS4J3iNLYa4U2f IK2bEkkpTaQMpcl+F4+nAYTmgjK0OHx9v3h7XG3nRINSOg10mlfzw3RxEREgKsX5CEgulYwIKAvC PQMDoJXj4BoGeiUwABqRYz1doEHGiDT/si4OFSV5WDIkj0uNQgFog1z6JsLqPkNaNzWSUrpIGUqX /T6eQAHV8pShpeDN3XGM04OGgE3hAmjOeciH3ZypoJ6zSpWDIqvSEUG0GHUigu76GYhACXRgsSGi VwIRKKlRUU8cCm9jRPKirItbRUl+lgzJ71KjEEFXOsW6idCyz5DWtUZWchc5Q+7yl308nggEwTVl aInY7m7HH9vxyE7HHwBbKgoADvVZBFDHwp0A0IbseQYAqCx3tgWgUyIAhl65vr4S0FiIEXn0eV3N yUq2L2fI9uYaFQAr6bVeXxJowXQZ8rrWyEruImcoXfb7eAIA1tEPg+0A2BMA03x3GPNpp39UJJ5j dhx3+PwEC+ZFumVuZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKNzEyCmVuZG9iagoxNyAwIG9iago8 PC9MZW5ndGggMTggMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzFU8Fu1DAQvfsr 5giHTu2xHdsnRCUuSCBg8wPZbCoCDdVmU/h9bMd2YgRSQUAVKdl5Hr95fs97Bo4CeHjSt5/YmQkO 35iAkWkOgnPQ1v+wRBzmgR3Y2YOxOX36CW5adv3BgYD2lnEggw6u4puD4Sg1J1AOPZeEdmLP4Hn7 iXEkY5wLPe3p72MvT9P4Zbws8/h17OI6kETldYW3Fy816sb9d10Re9XCe+aCy2QUehXOOpRCwfQD IuHOI9qhMQURpEzsMAaJ9FY3FNd7VhD/Ud77wuDPvDKkGakOOzx5szVILiqCXG8jMlJErARFY32K /lH35mf5CK5QShHzefNORvu8CKmSn93Dabzvu8sSFq7CUCU9CarGkP13Cf4yVWE1ob9Pu0QrJCZq pUFBm1uWdOzIZuZ6szsjOZDMkAPLM7ZEbdOgU7sO42qGVO9mJKSoSAxFZX2OP8jUSZSeYZ/p6+54 HObon1+UOhl66OfxOFy/vV+Gpfs8zC9ivNrHq9d4DfGniJeU5Kh36VZACJeU8DfXFoQUl6EhuZrL YnsGUi5le8ot85dgSSmNSuwatKn2r+WOfwXK/LS9yKv0/36opAUKXWV6c/cwpD8qmezh4eMwLJdi ZHi+AxbfU11lbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjQ3NgplbmRvYmoKMjEgMCBvYmoKPDwv TGVuZ3RoIDIyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic1VZNTxsxEL3vr/AR pGL8sf66tqWol35AJC5corBAqoRANoi/37F3PPaG0EJFi6pIm8zL7Jux31vP3jHBJRPxg9+zZXPX SMEeGsnmjRFMCsGMhx9eKcHWXXPa3AGYkvFrtmTvJ83hSWCSTS4bwZTjgR2kq2BOcLiftYEDlWaT ZbPH9ic/GsGVcyHElMnF62NnxwlVGJ5uppv7PuUxpXkL7cUrrEFbLp3/5/0l7GjCvjchbrbygkMX wQeuZcuWW4hmC0Cs4d4RIpXRKcM5rpQpsVXp/1lDSOt4KxQjBm2QAWtgHO8IhttQMrRwI4YclxoZ oS6Qgbocr2P2LAPtUkiKlmstk0IfVutu0Je3rcEt/bieXm56hAPBD9P5Zn5zlXDNdRbgcrVOkKwY Pn87QazcfnYckQPZcqPBHweKO/jvr1niSZvIAPshZW2REZIsEoTnquy9DzYlZG1yXNTLSNYXCbL8 uUIxSNCeizrDiDEBxqVERnITmSE3ubWKlxtECcFbYKgN8nVz3a3RCrCfuJsXtUMKvJjeXN3P+2tw SdIaDi7pB6m1fgOplYHds7qSeoxEqZWBHXdlG+FRNykDt5liEoIQlIoYUEqqQWIrA2TGVBlQbMSA cVUDEeoCGajL8Tr+QGwLIgNDLfaX7gE1VXBO4KN8NPn06ITY9Xzfrlezru/xeKi8spoNIDTm4zxL V2ggKC5bvXtg+G19/w9gcJ03nrfxxJaSGxldt4WA63wLSCAEYjFkCJDHlBie8vj/rCmIB8QxYpDO DAxYA+N4h/VcuyrD2TFDjksNRKgLZKAux+t4lut2ig4TlVszuG7d3S6msw6NY6CzYUeVUBadZ0R+ /3iYb64RFMYiqK117/Jp5Avo88QBl8IxJLlWJqg3d8mrOU1LEbionbaNLBotAiDFaRDLIWPQmGJy QUEGnxAD+ohqkNO0jPK6KgPeWWsGiqlGRnIXmSF3ubWOlztNSzg5xfOcFv1z6POLjba/9Fpw/rHX ggs73om1gzvVE0fcP5mAcMIHruoJOEbiBNRWwQgoE1BbqVIGzh6KaToRgvOLGHC+UQ2agNqaFh78 KsPaMQPGVQ1EqAtkoC7H63j5BMzq/HYC9v1915/vbZbn+7Sx8fMTMNvWd2VuZHN0cmVhbQplbmRv YmoKMjIgMCBvYmoKODU1CmVuZG9iagoyNSAwIG9iago8PC9MZW5ndGggMjYgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdWE2P1EYQvftXWJxAynb6y263ciIIEIdEBEbiwsXrNbsO M/au7clq/33K7apqe8ZCQBAoaKWZ7dflquru51fVc5dKoVI5/eF3dUjuEiXT+0SlTZLJVEmZZgX8 U2gt075O3iZ3AAZj/KoO6e+75Nc3PlXp7kMiU+2ETy/Cp0ydFCaTOrVegC+T7g7J4/TJ7u9ECu2c 95PN7urbY3/W9wHWABeIvRqGYz28fzwe3j8Jj6TaCAupTp/TeozwXn33VAP2fJf+lXjYeJ8VApLw hRdG2fSwBky6T7yd8iwY8UYFA+eE1hkPcx1mq4QA64SFk+DHTTY/jv5xCPbOCDjuaFBkq+dxGP0j QPHpcUpvnX/1WRTaOhclrTBGhXN53XdVPQxh6yAcbeV9OeCpyyxH7NhW+7rs0TTLHOJ9fV32V017 HWasmFg6z+z+CJASTms2/lD3dVvVYiaOKiaOh08YGIhnim3iFKcn//8AAh+VzpyAhSmtlMgUkPEU 2QMy8cIyorTxswUcm83iWHkzzVdJRApAXMoelMtmDxgDx9MTOSB6YQHfKw80jjEQ4SzQA2e5Xsdn sXLz0MGTyLOZla/aqmuHZhiBKQ9hG3NgLBHxsh7v67pFusmM9vu2HEZkrcpZq56/fYlgzmB/3BNf NZDTIFy2V0hYbylYy/qnFJH4dn5pJvhC50Lm8DpeKGGsduaHE+7bkTaDI1XZkrQnCJA2k0poFelg gTjBAulC40goRpBy5IEoSTEiaTOthPQLC+3XHmjMMQihLMgDZXmyjq8gLbDeBg+RtO+QZ7iR1U3Z 9EgdC0ks9K+vr1BFoXzhxNgh9SLNJur+hh4iIbcJ/SVuX79hllNa715u1fHCCu3zH1jHlcshy3xR xNfIVMWVA9WTGSPKGRsssIzymOssI1iI2QPWaY7BlVw5l4uiWFgUxdoDjhcxEOEs0ANnuV7HV1Rz PJ1lNX/z4pnJc0eFeFGi745NpEck06Fux6Zrqfwb4kP34Yw2Y19e1Yey/zhsVG6tdHgffrrKrUHc 1yJ4iuwByVYiqKVdiSCPWaAiMksYe0CJ4xgsglo6QBYGzq8dOH8awvl1ErMDzjH/jxJIR76UwEdP 93tq+aw9I84vYS5bEDPMoZpFtC0PNRovG82h7v9pqhrxqKnB94x+opB3403dn4WCUn7bN/VY9g+Y nFynkc5V3gurpxoP7Ib50A4P+D5N8k5BmhbjxrYZwiIW5fpZ1459c3nkdw+2MGfJvinHs+zLnrzE dqWvy6Fry8s9pa7Yx9YG3Nb9ZL5Hc7t43T+23T2JQGydNmoHLebCSOGgaVt1PbyqrseEtLafyD9c JzCbKS7t+1U9NNdtOeL+wrpoBm8lENSQ4+FY3eAxGL69wEkTTaRUp9tVi0fcumU+tG6ZK1TxwxXn 26lWoVeKdDhDQLUK+E+7qAgFCEWwQMGgcZQURlB0yAOJEsWIqlWYlY7B2K890DjGQISzMCudOl3H V+gWFGYbPETdenocbzq62UbSblRBLq96cc8dyge6LkdijjcNsbVgkCDiM55hNLg8XouNVswoB9Lz /X/9iZQy0ksh9aIVWyNTK2YkHLOKP1EYmZtggU0Qj7lNYgQbKfaAjRbH4FbMTP2ON9ECuLXyQOMY gxDKgjxwlut1fHkrRqfzOa1YuR+6swtl1R0OzThzg5jw6vnuxdn1YUOSeyheWHb0svGnqosZxBn+ CYZqG2hyYefiprXBksplOT54+XCmvlWU/K220EDTa2ETfrq20Di4teZuIbCnCLwNuYedNYyYHEQv WMzSxmMWv4jM8sgeUD45BgusceA7VwsL5VceeMwxCKEsyANlebKOLxdYOvSlwO5IDPWizp+IYdtR 27O8106/LWIjAPcdwjcagU0t5QOb/v4FXyUHw2VuZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKMTQz MgplbmRvYmoKMjkgMCBvYmoKPDwvTGVuZ3RoIDMwIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnic1ZZNj9s2EIbv+hXEnpKDWH5/9FggCXJp09RAWyAXR5ZjNStpV9Jm+/M7koYjybsG ksJFUBiwPS9HwyHn4VD3THDJxPjB36LO7jMp2GMmWZVZwaQQzAb4E5QSrCuz37J7ECdn/Clq9tMu ++F9ZJLtjplgkeURdKN5tEIxEzlE0WxXZy/Yy91fmeDK+xgD+OwO19d+Lh8nWYGctLd9/1D2H14M 9YeX06Dh0VgcVFMQpjQ3LJ++BfORCyfNxeTjMwlcTXu1Y79mEYrgReRjFjFEruG3PlM0u81cNNzD NifFBTV7eM+Vsovt1DReZKQYzw08SRG0nTxoDrSLzCvDLcQiD+02EcimOUjBLCgCZnm+juJrwHq2 QlIYrrWcKnTo9schr8rhmFd3XT50+0NZ77vPfS4EH/4ept2Vmluo6Lzfj101DGUz6rm0PDitYQbu jYzyvyvwxaJLbSXs16rgW2UsuNSwt7DgpEgNezt64FaTTcUgBctFEbCcNAcVXGrnOPxbPHzYRkB7 NQcqlAVGoCy36/j2gktoKAoirAv+y8e+7L6UBzzTTqa67u/u9l3ZDDgwZjQP9HXbDqdJBg6sR7lo m75s+od+GrFc2NQ6qmamBiSXusm79/nvb+bQKHVtW2PXseTXNj/OrUUGDk1x+gbDSy4vtZYnje3/ IczwOhP4eCKVlNzKEd4zBeB1GjAhAUwxOwgosl1sGfU4XmSLEkDxLAWQ3s4BcAa0xwds4CKsPEYQ 1wGSvUyBCiWBESjJ7Sq+Ct1nSy6V5c7O6N78gVwlZKuZPZkIxp0OOjFG7ewGIZU01H6eO9h4GgN0 sJHW6NV35+J6bAWogdFrts4UYCsAGiYudQuAzuSBdU32UnlSkI0UIbGT5ljoCsCG9isPYGcTIdnL HKhQFhiBstyu41/QFYGuKcJV6MKWCRdUguuIsaRUKP15cxa+afFy5c6FMygdF0bPUDpY7XcH6mpQ KjH2cLWC8ly5BUWDsjQTsOXsMeNANgGzKDNSFAGRozkISgWHHfZ25eH8NkKylzlQoSwwAmW5Xce3 Qzk+qKYIC5Sv264uu3T3Ljd1ue96VENMhA7tE+o+lom6hGb/cDxWRbW+6M3l5++6cnpdQF9JpHbV p9PQ4/3tlb4M/lCnFELK4dTeHkpawPJK8VgNp/ZhTixXcIMAQeMZiD6E1cqr5lM6cfSS8kzupz3m rbgx9CLyaveaxPRw2Rzari+fbGhxu69qTvCOn38Ap5fwq2VuZHN0cmVhbQplbmRvYmoKMzAgMCBv YmoKOTM5CmVuZG9iagozMyAwIG9iago8PC9MZW5ndGggMzQgMCBSL0ZpbHRlciAvRmxhdGVEZWNv ZGU+PgpzdHJlYW0KeJzVlk1vm0AQhu/8im1OrdSs9xvIrZWqqrfWtZQzwTimCeAAVpR/31mYHSB1 paRKG1WWsOdlPnaZhx3fMcElE/6D33kV3UVSsPtIsjKygkkhmE3gR6KUYG0RfY/uQByc8Suv2MdN tFqnTLLNLhJMxTxl58NVsFhwbYViJuWQS7NNFb1l7zY/IsFVHKep99lsX1770nXHYrihuHMJqps2 y2/K+vpiuGO4Du7roirrbdEOmZjS3MAO/BW2aTRX8p9vYNA+bdi3KPXt0FZCj9Ik5VoaVi0FzW5B 0I7LlBSplfEOccyVsmQ6NdzNoyCYmBvoD4Vri+FjfjS9v3NcyJlDnCziR3OWfxSoPobT8hbrz58E 1om2SAFd1HJoy9cyvym2w4ODezH1djNIkjspUco6lLQ2KLXHGrVYadSuHn5xW2f19gFLSOLq47Hb r9bNFWLlXKj94dj1RVkjVvMXQ9rYP++/j9XysSmp4YV8RZqVsIrbGckLwZOshI65nUhWQlnvgCQF k0gLApJI4QhqyE8kK+HAU84c4nQRP5qz/KNA9TGclrdY//NJxpbMSd73/aG7WK3anh+6a5431dhK mXiChivEGckB1ZOtTB734v8QRkI0bAlOCCUlt9ITshSAEK1BcKSALQcHAU/UkilT7e/mEQkJCDGj cBnbMXzMj6b3tylXZuYALZ/HoznlHwWqj+G0vMX6n0TIqU5L4NzZkZDb5ppONYWPsAwnmLDu9wfd WVn0u7P3YTaiesi67r5pt3iCWdjm3B29tQq1dk2LmQ3sGIvVTf1QNcexpoU7IUmW50XXefUcpo6B BsDeuDZCmFdn7uW4dUJ5PGbgPlKAXJvCM59YUDYxoweiE+yJLVIQvpAhsBlqTPQCEf7X5KHEIgPZ VCMoYRUhQ1jlo338AcEw/e2QYUI4624QoYTgvPw8koZmvs/KFtmbODvF3n1b9uH/nk7SBXf8xBzU 0nEDZ8DrDUItoB2wgmkSLhU/CrVwiW9IUDS82YMHziKyaViRgtOMMuCwoxo0DrVIE66SyUNKscgQ 7KlGUGgVmIFWudzH80di6M58Jl5mdR8OLTryqqYNXbd2OsvavszLQ9aXTY1n0fSXbNc2FYZMb/G2 yY9VgQXmf+CyY79v2u4Ntc1/fgIhb780ZW5kc3RyZWFtCmVuZG9iagozNCAwIG9iago4NjcKZW5k b2JqCjM3IDAgb2JqCjw8L0xlbmd0aCAzOCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVh bQp4nNVWX2/TMBB/z6cwb/Aw139jm7cCAyGhSdB+gSpNt7C0YWmmad+es3O2k7JJGwImFCnJ/Xy5 O9/9cucbwignzF/4rPbFTcEZuSs4aQrNCGeMaAsvVghG+rpYFTcABmV8VHvybl0svjnCyXpXMCIM deQs3BkxjML3RDkKpiRZ74vX5M36e8GoMMY5r7Le/nnsU32o+00bliS1UiN+0QzHAAoEPnZ9kDk1 xiK2bFvEpI0GP/Sb3XAMnoiQVMEG/R2yIDV1zvzzHQbsfE2+Fs6XSxhLIQpnHZVckf0JIkkLSKko KxPCheZBwxgqhM5yKcJ6VSREGaqYIMkC7Hm0gD5Q9l84SLfNGpLpmYUoZx8RSVGghRTlfB/Vkyj4 UIU4U1RKHip0Ud+NNICkxrIfm6HGulupENwMCHEeKXM1DD/eLhZD17VH2tTDjnb95cJrnRkgu5Lg mRqpuPt7hX+UDNxxC1SeEmGGBCI4BimeEME6HjRiCaKcixSRWMZoIZY5+shEcFLSckIEp/TcAsrZ R0RiFNFCjPJkH79BBOeASXMiLG+Hbr8Z6m1IoYYyx8pv/R+fSBIzfYgNZEqS6qqurpvDJQ0k4BxY YEYWAAn4C7BA6JJB85qwYI54FggN+VY5n0JDvr0G5j/JqUIJwRomC1jj5COxQGijqXATDWvmFlCe +EAkRYEWUpTzfTyfBb6HcbAwZcGqrm77ZriP8yJmtOoOx2YLk2Ro4C2sltSIOE2OdeUXxqkA7ISx F+7gxAFp9CNTwZ7W8P8ARmZZ7ShsjAtPc+6ZdYIAsyxsu5QJAZmPGtA1lM4y/OJ+vSoyYqV/Jgsc qh8soA+U/Rel829ZAwgzsxDl7AORFAVaSFHO9/EkZj1YdBibtNQjs7503TWeOKhTJeazrzdte49w WRqE282+RlCpSLJmh+XIB5TV+XtUk3lQgc1futUOJlONDQt+3XQMGq6a46sHDjMS/ksOPfflDjNS Opa7vu9cc8R3Limh5ibPLynLcVJgz0hy6ioJwb6TLGBfSj5S55IKjiU6dy4Y52ZmIcrZR0RiFNFC inK+j+d3rlidaef6vLxYRh6lE8rT2hZNSffXTwxrhE1lbmRzdHJlYW0KZW5kb2JqCjM4IDAgb2Jq CjgyOAplbmRvYmoKNDEgMCBvYmoKPDwvTGVuZ3RoIDQyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicvZLLTsQwDEX3+QovQaLBdhLabEEgsWToD4z6gCI6oz5G8/s4Ie0wiAULhCIl zcnttWNnANQEGEZaq14NihCOiqBTDoEQwRXyUTAjjI16VoPAKE5L1cNtqa43HgjKViFwrj1kcUbI URuHDNZr8TJQ9uoCLss3hZrz3PugKeu/Z/W4beesa+Y2m5pqes3q3RRlwEZbSS/McgfjdGH9v6cX 2X0JT8qHYsuZlix84bUhC/03YuBdyA1rV6yE2GFUiJDZnfYiC+eVWokVK2nB6iB3/nRIMdI+/OFZ WzopDNozh2V/irGQNYvksGZ5fo/qVw/opw6RBDKGYoced7F+pIk4FXTzcBeZJGZMYk3dzfsxYal+ wsOhOTRXERtR3yR83HZzt3tZ+KJukwNpa11i1X5ski2z+friprWvYXwAuge2bGVuZHN0cmVhbQpl bmRvYmoKNDIgMCBvYmoKMzIxCmVuZG9iago0NSAwIG9iago8PC9MZW5ndGggNDYgMCBSL0ZpbHRl ciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJy9lE2P0zAQhu/+FXOEQwd/xvaRj2W1N9hG4hzalDVK tmqTpfx8bGvsNHxICAGKlGQej1+PPa98Ao4CeHrouxvZiQkOFyYgMMNBcA7GxR8nJYdzz7bsFGFO ps9uhFcte3HvQUB7YBykRQ+b/OZgOcb5oD1GKQXtyJ7B8/Yz4yit9T6ltPu/z14fz33mErU2BN+c u8M8EfYVb+dufpqyCEiFOtae3nGDqkFh3X8vPrObFt4znzohHcdYhXceldAwfkcUDJE0Bp2tREij coa1KKVZ4kbm8R2rRFvUXEJVUIYUaA2K0wxvsPFLhuJ2pVDiZY1CahWkUKtc72P3W+76WYcE16iU yB16OYzHac5nqCLUdKjdMGQm4lk7Ync321uyQ9MUGKbpqZ9ovhCS8Md+CP2Xfp8HNHJeBvZ9N8zV aw3RS5gfEtsIjzKZZxNHreTu3znmly4SzsQizLWDViQ7yOl4hHrpjVMyZ5TelXjpbiGl/0Wh+KOs sTjIWY2iucpwzVqB4qs1iNQqSKFWud7HHzjIx14m5SsHvQ1fw+OnH+6Jx0CXh0BXbXV5CEO5aYyp 3e/CXCSiCUtLDsczCSyX0t27+82H29qr9HwDpO4sTWVuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoK NDYzCmVuZG9iago0OSAwIG9iago8PC9MZW5ndGggNTAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJy9VcGO0zAQvfsrfASpO2uP7di+gtg7kP2AkhrosknahKW/z8SxnaQCBAhWkZLM 8+TNjN+re+YCJBfTlZ5Ny85MCn5hkh+ZEVwKwY2jF4co+BDYe3YmMCanR9PyVzW7fee55PVHJjha 8Pwm3gW3ApQRyLUH4lK8btkL/rJ+YALQWu+nnPrw77G7py7CCELIhF2OXz9n0FQJvK/v3EzAUYGm xqc7TacMmMo/e+MRe1Pzt8xPMqDVQF1450FJzdsrRPFHQowH6woiUduYYS0gmiWuMK43rCD00CRO YaCZZ4ZUI8XTF0ReLQlKyA1BjpcSGSlNzASlx+0UzW8Z60f6SKFBKRn1ue9OQ9+EcQyHuI0VyMpf 64xgadQZfBrD0O3bsIsrhryCaeW0H8dLP8w8N7ICJbyi4mDR4f8T/qdmkF4qEBsjbJBoBOcdSLts snNVzMga5HhRKSNZx8yQdc41FiN4XPnEa7H5PMdLgYzkFuLnub+rCf7CBN5T4a0JhtD0bRu6Q9LU GJt2c9yPj6chnOKCpjMgL/TzWSFB5Y0nX3wLQ0TV6rAYj4eQDaFRzIaYJn9+Q6AxGnBtiC0yGQKN otdlw9HQqYyLGiUuehUkKVoYkuKlRjEE0o8QUK4ynNwypHhVIyGli8RQutzO8ee2wEqBwa0tXvcd KfopdE1IZ8NU+xd/DJNbdglVSif0Sxg+hKEfd8lEWud8ACjiTNd3SuaJkWVuZHN0cmVhbQplbmRv YmoKNTAgMCBvYmoKNTQ3CmVuZG9iago1MyAwIG9iago8PC9MZW5ndGggNTQgMCBSL0ZpbHRlciAv RmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdV01vGzcQve+vIHwo2oMZfn9c2xpN0KZobR3ak6GsV7YK aVVLcvL3O+QOZ0lBBuIgTdBagNbzODsz5Hs7O3pkgksm0gev/bZ77KRgHzrJ1p0VTArBbIB/glKC 7YfupnsEMDvjpd+y7xfdq+vIJFusOsGU55Fd5m/BvODaCsVM5BBLs8W2+5Z9t/irE1x5H2PyWdx9 fuzt+tAPm81yHHZPh+zguJMaV/vduHo6rMf7vGK4tQFX3q2Pk7vkQRsEv8EM0Zg5w4fd/u6wXR8f IExeZkpzAxtP33A6Bq5RfvGNZ+xqwX7vYqJRW82hihgi19Kw7Qmi2QYQHcmUWrm87D1Xys62U3m9 7wgxnhtgdrpdW7wdo6Od3F3gQVUeQbS3o10lQIRKwAhUYruD/qNEeY4bKQzXWmZurofVsB/Gfpjo h2KjxCM97lARUiqElvt+tXvav7r+wUwkMBmS6vM3GM7wGP158sMpe/8NIGtK2gDkeyaVlNzKpKcT BPRkgTjYdEGkBf6yh4Bjt7Mto07rwDghARC4lgjS2ykC5kA73RGzCMnDAZV1BLIpR0GoCoxAVbb7 +ChVnSVdKsudnVQ1Funo8nz2D8vxfsiorvrOdnk3nOkiSkYo8hkhfZEuAscROFQwd5AWSR1ESThT 5QhRIsrsgU8w2fSME4JdgCJgl6Ac1EcU9BkuQuVhbBsB7TlHQUoVJUKp8mQfL+8jhZ26j2BnQIKJ 9vfL/Xr5blOIh7PGhc0w3h8fEBaiNJh+/ffDsE/opVTcpvouFfcqRvXvEf68CLzND0clggbJIvBG cVGJAIrNHuX4iz0TVJBCYYlQKC45ZhF4D+/lSgQeHvcmAtpVDkSoCoxAVbb7+AQRQAIfWxFcjJcw SFzkA1Q86jJ3vC+zxdxbL8bycgnl3NMMcpGp99w7kZk3Nlr7FZjXWoP8KuIbIPEOe/bczhOE1sIm BzzwYhIjBUDK6HaktMQnzrVOnrJysLG5fzKr+BNA+fF2Kq+p/+V8awPd3DZ0b9cHGiY1d87PY+bh uBxxoqzHzNVuf25u0A6q+j/ODdpp0c4NpwgIySlZzw3aQeer3thk0zt9Rqa3PkXAqYBy0NygnRH1 3AB2aCOYcJrDhLYKjEBVtvt4+dxQSK/nhpub17dvb366/fnqjx9f37759c2CwV/uCYYL+EGVbufQ eoz76gR/PpEED4duapGcICCS4OAJm08/WDs5IDvFnvkjBBnGAEUAJcMskRDSr4PKA0aVJkCx5xSI UBEYgYpsd/EJEoFULkd4TiLXV7/98iedZPr8A1szP81lbmRzdHJlYW0KZW5kb2JqCjU0IDAgb2Jq Cjk4MAplbmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDU4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnic3ZjNcuM2DMfvegoe25ma5adETk/ttMce2voFHJmOteuPxFKa5O0LUgQoeZ3M erubTjOZsY2/YQAkiJ+k3DPBJRPxL7+3++q+koI9VpJ1lRVMCsGsgw9OKcFOofqrugcxOee3ds9+ WVY//umZZMtNJZhquGeL9CpYI7i2QjHjOcTSbLmvvmPfLz9Ugqum8T76LNdfX/u969ukK661zuKv p9Vm6JM3U5obqDK+wlK05XXt37zKpP22ZH9UPu65aqAMz7zzXEvD9meKZjtQasGbhhSpjEseTcOV ssWuVfq+rUgxDTfQCYoAax4j5BzZjr/wgtfFQQs1C4B2SYEKFTEGoBrnq2g/6xRd6o8UBtopU3/W sZmLLgybRR/afrtYPQzbxcebdXcYwmnVDnFvF1BiDQ1dSC5qWPm36+KLnZVWGQ7bNunqTEldtQJO niw7ZnyTPHBD0S5bjgo2BSNg0zBH6arVjns98bByHiHbJQcqWAVGwCrP1vEFfYWjGOnwal/X28Xt 6fhwtwhP7XZ1uA3jAEsXMZNeo+G4US9gxp336f8hjKfHKQmbDzMkJbcynp4zBU6Pg0/KkSKd0KMH vBtbbOl1/B46S4oDpWEUQcKkpgg5R7bjL7Tksp54aD+PgHbJkRWqIkegKufr+KzTc7HpUgEd7Hh6 Dt3Qp92T3GmTt/N42D3/hFcDnNDH2+xnbZ0lOF7dKfsZKHlUtyuKiL/th263y2IDFYzqTQiH/Ot4 qEdxt9qHT0Kubo4PQ1ap6Zvjbnd8fLi7cH1SRnPt3v4qWs6h0lZxN6XYXIkUU1rDRb9QTGlojCv8 IJsIQ0pmEEXIjKIcRDGl64Y3euLR+HmEbE9yZIWqyBGoyvk6rqcYdudVih3C4/64Dv0FeKnacAeT 8e7gpeDWcTry+08UODQWgDLBgLLQnuQxYoNsAktRRvRQhIwmykHwUtaDUhzgjmAWgGxKgQoVMQag GueruB5d2PIpusLTXXcKa85Y2kE4S14iqzKCFBcEq7tTGIZnhEiDI9vujn3gY4i4BuzKv8Hdi2C7 gCotPUzXC4f5TVClpazhrm+CqrkSUaWlkLBmUrSIH2qCBNmEEVIyaChCBhHlIFTBK1zgmolH5MQ0 QrZLDlSwCoyAVZ6t43pUYXdeRdVt338Mz+HpAqo01B4P0LtDlTYSDvcUVecKHBoTH3MKqrT2ZvQY KUE2caQoI2koQiYR5SBUabih4XbioMU8ANqUAhUsIgfAGs9WcT2qsOVTVMVHreMJGSP1V0IHPNJo GKn/EB3Oq4KFhI6ZktDhYDptuX/QrrbJA4cW7TLWqODgYwQEA+Yo6PACtsIWDw9zO42AdsmBClaB EajK+Tq+AB25O6+iY9PtwtMmnC6gw8C7g8l7d+gwcTIaN0HHubIDRcKNriHFSGhP8hinlmya66KM k08RMhkoB6HDxP+SNGriAVeTWQS0S46sUBU5AlU5X8f18MCmT+Hxczt0f4cMDyHwHmfd9e1D33fH ww/pu3hPhw9w7ao8bk2el05ZKzcv7XG/D4fxf3ypOfHvH/3MVTRlbmRzdHJlYW0KZW5kb2JqCjU4 IDAgb2JqCjExNjgKZW5kb2JqCjYxIDAgb2JqCjw8L0xlbmd0aCA2MiAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nM2W21LbMBCG7/0UumwvrOh84LIzPEDbvAAkTkhJSLDNAG/ftdDq 0DIEMi0wmbGzf+R/V/vJUm4Jo5yw6RPvi11z23BG7htONo1mhDNGtIMvTghG+q752dyCGAbH22JH vs2b2Q9POJmvGkaEpZ604cqIZVRqJojyFLwkme+aL+Tr/FfDqLDW+2nMfPnvtatxPJzNZuN+vx3o phtXdN+vZ/fr2dAthqvZ9ETLqZwKpVZ4q/9LFc9p5w+HTd8tz8JPREiqoIbpCh11jCr+7r0K2vmc fG/8RN5CNZx456nkiuxqQZItCMxR7pPCjTfTAGupEDqFRoRfFw0KylIFSyE9LvXT49E/hjDeSkcZ LwZoVj3/FGb/KGB+fBzLq+tfvGoNP4OFM0Wl5AHLsr9Yje20rtqwoNrLvru4bpkICwsKM8APFhgz XJh3W1oZJPeWU6VKipUSMHptqJa5T16pMAL7iHFuNCpIAh0QFObIKL0zsAEUI7yrHWJc5IhKqiI6 pCrrebwdp2CaCnB4ked6GK67x+6hZe4PpFIq7j4AqRBOUlMirZUJqRDGwXaWFGigCSNiM1Oc2p2U CCQ5RGApR0IqBADSGamQnFUOGOccqKQqokOqsp7HCUilococQXrT3e/2y274PG+p0JJTb0uklRKQ am6hwNwsDXOcRmAzMc7tRgWBoAMCwxwZqVaGOleM0K52iHGRIyqpiuiQqqzncQJSwymcyy8jPdxd bjcLeFHb4e5yeBzGbtcy/swL6z+CroPdkld0KyXQdcJTUdB1wIoXfcU4dx4VZIMOyA5zZLpOe8oK ug520MohxkWOqKQqokOqsp7HCXS9oLAsX0l3tdl2LdOfhKvksGXKkmutTFxBh1Mqc5UcKMnc0RSn niclUkkOkVrKkbhKDpSEK0bANlo5xLjIEZVURXRIVdbzeDtXCXcrj3C9WHc349+78IfxVHDk6Ypn pQSeSsMRVfBUQEcXncQ49xoVpIEOSAtzZJ4K6KiCp/K6dohxkSMqqYrokKqs53ECTw1HiT7Cc7W5 WXf9od9MVD/L7ist/Gu3FdVKCVSt0dQVVC0wskU/Mc4dRwWZoAMywxyZqgVGpqDqmK0cMM45UElV RIdUZT2PE6jCX2puj1AdFod2WI1wgeCu30S0obnT5zfyuGV0ZW5kc3RyZWFtCmVuZG9iago2MiAw IG9iago4NzQKZW5kb2JqCjY1IDAgb2JqCjw8L0xlbmd0aCA2NiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nL1WyVLjMBA946/QEQ4RWrwemWGZVEEVg33gwEXYCngmXrAUIH8/st1S EhIolpmpVGVptbtfv9fdygMimCLSv+Azr7wHjxL05FFUegFBlBAUxOZLzBhBnfRS78EYB2f4yCv0 LfMOrxJEUTbzCGIRTtBkeCcoItg8j/wEm1AcZZW3jw6yXx7BLIqSpHfJir9vuyjnUummlmo4DTAJ Ijg66uRgozjmPtiupJjPl4OZG9cQzKkWczlER5TjAE2G9/5HiH1CN6o6Nsn2ENobYwSE2RiL26rU EJpbfNNay66WenLcidl4GmIa2uOmBojugTT9MWGYDGZ/rZq2a3STN/PePqGxSRwbmJhzxujg8Bqu Y5mXhXyJaztx1olatU2nIXXgUp+LpewGK8OG+xeAIHLMAzgQGkJTajFcyKq9LxVE5k6O6Ul2ioeK mI9jI2pfEUv84M2KLhulAQ5zcDr5WCpZIOtMwZ430AbGmXEwKpmre7DGNkLRK6RGfg3IpG8DTELK 2Ztoduu+M+2YYYtJ3WwRNj1Jz8AvDGMwzpoOHH3fkt0ubudlLnQJgvYDYP2Fsho7wo1obWNp8k0c q7HSoi5EV4ximJEOoL185n9cDPmsZa0MJrUF6hUOdtXWSyqfRkFMiJC/UxAtOgvJ6aFkXZT1HcgU xZ8GukOsc+EooE6s72bRjGQSk27sbM5jPq6m1la7Wk2E2WL6lrHWszQ9upzabeBqLNw22ZwBUSzf Re3cQl5HkFvINDTERZv6vx/yZd+SMF58bY3sxry9iGr5ZNl0FOfdsgXmzd52w101hVRbkAkLx60j lk6W6E3IR3eyttDihP4fkgMc0rEvaGIa5GOIv0rytRmY5JEftr/LZ7iV+gsOhmXRuouAG5TWfrPv qgyc661aVNJtdmsvazcobsHeKSXaEqKuJmWAfHMwkMJN5Ua9T8r4VVLMVV2VtVhdaTawkt0jXIHr fxuAp9WV/KIBzdULWVfP7EZ+av7GWLocX7q/kWcub7jJ2L9qzJMM/fT61x+7cG1HZW5kc3RyZWFt CmVuZG9iago2NiAwIG9iago3NzUKZW5kb2JqCjY5IDAgb2JqCjw8L0xlbmd0aCA3MCAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nL1Uy27bMBA8m1+xx+Qghk9J7M1F0iBAC6SxDj3k Ist0osZ6mJTj9u9L0aTsIkWRAEEgQI/Z9ezs7tBbIJgCGa/wrBq0RZTAHlGokSRACQGZu5ecMQJG owXaOtAnh0fVwOcCXdwpoFCsEQGWYQWJvxPICOaSMBAKOy4ORYPO4Lz4iQhmWabUmFOs3h/7Vm+0 HbpW+6DAUmYhYgdT7puy9T8CyrGExN/dB8ux4PQvsfPeeAqKcy4CBZEzgNmIMsxYRK8Xi/ntTahH XM8HeGXK9QAhOYv6jC5XvwOaTei6i8WEkAHblHZ4oaAqN5sRS2iKucpcB5hzxnzs9Yq/OupkpJpE 0xBp9b7pVtr6GjkmUvkSTAnh45em6yMjP2lr/qDb2Gyu6MeMwG2XhBEQlv5X3+1uuantIxzwoyn+ rbBrQ1UekR+ulHrmF/1T/cvHUjwaJThr1/edGQJ5SiN+fzb1JKfUpd010ZycR7xuhy52Gms+WFv2 dWClaX4q+f7cj4BTTKg4rCh/sw3utN0Zo6shyElp9G7ZrgKHEunJMo6mcX2m08nSlX1Mlm6vT3Ex LOfROPKNqr64ExxTp1m4s9vatTZT7fxjLOb+zCTznQgS5nupq8BMZJwNyWazA8lR2c3V4jokHsGy 7033XMaDRyevdOuggk5LqDqjY2eMn/ZrX7T2KTk44qqA72i8/gAUeF8iZW5kc3RyZWFtCmVuZG9i ago3MCAwIG9iago1MjkKZW5kb2JqCjczIDAgb2JqCjw8L0xlbmd0aCA3NCAwIFIvRmlsdGVyIC9G bGF0ZURlY29kZT4+CnN0cmVhbQp4nK2MUQrCMBBE//cU86kfrpvYmuZLFDyAujeoVVtMISqItzcJ 9QYysLO8md0IYQPJmrwNFMkI3mTQUy0wIqibtDTWCh4dnSgmWMqTtQE7peXRw0AvJLCOPRZlCpxw ukflOb1aQQPNMNeBhK1z3ueKnv/PtuPndevHa8kqNutf0N2f3SbDveJAWV8UNjcbZW5kc3RyZWFt CmVuZG9iago3NCAwIG9iagoxNDIKZW5kb2JqCjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94 IFswIDAgNTk3LjYgODQyLjRdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTAgMCBSCi9Gb250IDExIDAgUgo+PgovQ29u dGVudHMgNiAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5Ny42IDg0Mi40XQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1Nl dFsvUERGIC9UZXh0XQovRm9udCAxNSAwIFIKPj4KL0NvbnRlbnRzIDEzIDAgUgo+PgplbmRvYmoK MTYgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk3LjYgODQyLjRdCi9Sb3RhdGUg OTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDE5 IDAgUgo+PgovQ29udGVudHMgMTcgMCBSCj4+CmVuZG9iagoyMCAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA1OTcuNiA4NDIuNF0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMjMgMCBSCj4+Ci9Db250ZW50cyAyMSAw IFIKPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5Ny42IDg0 Mi40XQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9U ZXh0XQovRm9udCAyNyAwIFIKPj4KL0NvbnRlbnRzIDI1IDAgUgo+PgplbmRvYmoKMjggMCBvYmoK PDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk3LjYgODQyLjRdCi9Sb3RhdGUgOTAvUGFyZW50 IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDMxIDAgUgo+Pgov Q29udGVudHMgMjkgMCBSCj4+CmVuZG9iagozMiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3gg WzAgMCA1OTcuNiA4NDIuNF0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMzUgMCBSCj4+Ci9Db250ZW50cyAzMyAwIFIKPj4KZW5k b2JqCjM2IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5Ny42IDg0Mi40XQovUm90 YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9u dCAzOSAwIFIKPj4KL0NvbnRlbnRzIDM3IDAgUgo+PgplbmRvYmoKNDAgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk3LjYgODQyLjRdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDQzIDAgUgo+PgovQ29udGVudHMg NDEgMCBSCj4+CmVuZG9iago0NCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTcu NiA4NDIuNF0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0ZvbnQgNDcgMCBSCj4+Ci9Db250ZW50cyA0NSAwIFIKPj4KZW5kb2JqCjQ4IDAg b2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5Ny42IDg0Mi40XQovUm90YXRlIDkwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA1MSAwIFIK Pj4KL0NvbnRlbnRzIDQ5IDAgUgo+PgplbmRvYmoKNTIgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk3LjYgODQyLjRdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDU1IDAgUgo+PgovQ29udGVudHMgNTMgMCBSCj4+ CmVuZG9iago1NiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTcuNiA4NDIuNF0K L1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0K L0ZvbnQgNTkgMCBSCj4+Ci9Db250ZW50cyA1NyAwIFIKPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5Ny42IDg0Mi40XQovUm90YXRlIDkwL1BhcmVudCAzIDAg UgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA2MyAwIFIKPj4KL0NvbnRl bnRzIDYxIDAgUgo+PgplbmRvYmoKNjQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAg NTk3LjYgODQyLjRdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9Gb250IDY3IDAgUgo+PgovQ29udGVudHMgNjUgMCBSCj4+CmVuZG9iago2 OCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTcuNiA4NDIuNF0KL1JvdGF0ZSA5 MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNzEg MCBSCj4+Ci9Db250ZW50cyA2OSAwIFIKPj4KZW5kb2JqCjcyIDAgb2JqCjw8L1R5cGUvUGFnZS9N ZWRpYUJveCBbMCAwIDU5Ny42IDg0Mi40XQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA3NSAwIFIKPj4KL0NvbnRlbnRzIDczIDAg Ugo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo1IDAgUgoxMiAwIFIK MTYgMCBSCjIwIDAgUgoyNCAwIFIKMjggMCBSCjMyIDAgUgozNiAwIFIKNDAgMCBSCjQ0IDAgUgo0 OCAwIFIKNTIgMCBSCjU2IDAgUgo2MCAwIFIKNjQgMCBSCjY4IDAgUgo3MiAwIFIKXSAvQ291bnQg MTcKL1JvdGF0ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMg MCBSCj4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlL05hbWUvUjQvVFIvSWRlbnRp dHk+PgplbmRvYmoKMTAgMCBvYmoKPDwvUjQKNCAwIFI+PgplbmRvYmoKMTEgMCBvYmoKPDwvUjkK OSAwIFI+PgplbmRvYmoKMTUgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwv UjkKOSAwIFI+PgplbmRvYmoKMjMgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMjcgMCBvYmoK PDwvUjkKOSAwIFI+PgplbmRvYmoKMzEgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMzUgMCBv YmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKMzkgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNDMg MCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNDcgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoK NTEgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNTUgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRv YmoKNTkgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNjMgMCBvYmoKPDwvUjkKOSAwIFI+Pgpl bmRvYmoKNjcgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKNzEgMCBvYmoKPDwvUjkKOSAwIFI+ PgplbmRvYmoKNzUgMCBvYmoKPDwvUjkKOSAwIFI+PgplbmRvYmoKOSAwIG9iago8PC9TdWJ0eXBl L1R5cGUxL0Jhc2VGb250L0hlbHZldGljYS9UeXBlL0ZvbnQvTmFtZS9SOT4+CmVuZG9iago4IDAg b2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvSGVsdmV0aWNhPj4KZW5kb2JqCjIg MCBvYmoKPDwvUHJvZHVjZXIoR05VIEdob3N0c2NyaXB0IDcuMDUpCi9DcmVhdG9yKG1ncDJwcykK L1RpdGxlKG91dGxpbmUubWdwKT4+ZW5kb2JqCnhyZWYKMCA3NgowMDAwMDAwMDAwIDY1NTM1IGYg CjAwMDAwMTY0OTYgMDAwMDAgbiAKMDAwMDAxNzI2OSAwMDAwMCBuIAowMDAwMDE2MzE0IDAwMDAw IG4gCjAwMDAwMTY1NDQgMDAwMDAgbiAKMDAwMDAxMzc2NSAwMDAwMCBuIAowMDAwMDAwMDE1IDAw MDAwIG4gCjAwMDAwMDAzNjQgMDAwMDAgbiAKMDAwMDAxNzIxMCAwMDAwMCBuIAowMDAwMDE3MTM5 IDAwMDAwIG4gCjAwMDAwMTY1OTkgMDAwMDAgbiAKMDAwMDAxNjYyOSAwMDAwMCBuIAowMDAwMDEz OTMwIDAwMDAwIG4gCjAwMDAwMDAzODMgMDAwMDAgbiAKMDAwMDAwMTE2NyAwMDAwMCBuIAowMDAw MDE2NjU5IDAwMDAwIG4gCjAwMDAwMTQwNzkgMDAwMDAgbiAKMDAwMDAwMTE4NyAwMDAwMCBuIAow MDAwMDAxNzM1IDAwMDAwIG4gCjAwMDAwMTY2ODkgMDAwMDAgbiAKMDAwMDAxNDIyOCAwMDAwMCBu IAowMDAwMDAxNzU1IDAwMDAwIG4gCjAwMDAwMDI2ODIgMDAwMDAgbiAKMDAwMDAxNjcxOSAwMDAw MCBuIAowMDAwMDE0Mzc3IDAwMDAwIG4gCjAwMDAwMDI3MDIgMDAwMDAgbiAKMDAwMDAwNDIwNiAw MDAwMCBuIAowMDAwMDE2NzQ5IDAwMDAwIG4gCjAwMDAwMTQ1MjYgMDAwMDAgbiAKMDAwMDAwNDIy NyAwMDAwMCBuIAowMDAwMDA1MjM4IDAwMDAwIG4gCjAwMDAwMTY3NzkgMDAwMDAgbiAKMDAwMDAx NDY3NSAwMDAwMCBuIAowMDAwMDA1MjU4IDAwMDAwIG4gCjAwMDAwMDYxOTcgMDAwMDAgbiAKMDAw MDAxNjgwOSAwMDAwMCBuIAowMDAwMDE0ODI0IDAwMDAwIG4gCjAwMDAwMDYyMTcgMDAwMDAgbiAK MDAwMDAwNzExNyAwMDAwMCBuIAowMDAwMDE2ODM5IDAwMDAwIG4gCjAwMDAwMTQ5NzMgMDAwMDAg biAKMDAwMDAwNzEzNyAwMDAwMCBuIAowMDAwMDA3NTMwIDAwMDAwIG4gCjAwMDAwMTY4NjkgMDAw MDAgbiAKMDAwMDAxNTEyMiAwMDAwMCBuIAowMDAwMDA3NTUwIDAwMDAwIG4gCjAwMDAwMDgwODUg MDAwMDAgbiAKMDAwMDAxNjg5OSAwMDAwMCBuIAowMDAwMDE1MjcxIDAwMDAwIG4gCjAwMDAwMDgx MDUgMDAwMDAgbiAKMDAwMDAwODcyNCAwMDAwMCBuIAowMDAwMDE2OTI5IDAwMDAwIG4gCjAwMDAw MTU0MjAgMDAwMDAgbiAKMDAwMDAwODc0NCAwMDAwMCBuIAowMDAwMDA5Nzk2IDAwMDAwIG4gCjAw MDAwMTY5NTkgMDAwMDAgbiAKMDAwMDAxNTU2OSAwMDAwMCBuIAowMDAwMDA5ODE2IDAwMDAwIG4g CjAwMDAwMTEwNTYgMDAwMDAgbiAKMDAwMDAxNjk4OSAwMDAwMCBuIAowMDAwMDE1NzE4IDAwMDAw IG4gCjAwMDAwMTEwNzcgMDAwMDAgbiAKMDAwMDAxMjAyMyAwMDAwMCBuIAowMDAwMDE3MDE5IDAw MDAwIG4gCjAwMDAwMTU4NjcgMDAwMDAgbiAKMDAwMDAxMjA0MyAwMDAwMCBuIAowMDAwMDEyODkw IDAwMDAwIG4gCjAwMDAwMTcwNDkgMDAwMDAgbiAKMDAwMDAxNjAxNiAwMDAwMCBuIAowMDAwMDEy OTEwIDAwMDAwIG4gCjAwMDAwMTM1MTEgMDAwMDAgbiAKMDAwMDAxNzA3OSAwMDAwMCBuIAowMDAw MDE2MTY1IDAwMDAwIG4gCjAwMDAwMTM1MzEgMDAwMDAgbiAKMDAwMDAxMzc0NSAwMDAwMCBuIAow MDAwMDE3MTA5IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzYgL1Jvb3QgMSAwIFIgL0luZm8g MiAwIFIKPj4Kc3RhcnR4cmVmCjE3MzU2CiUlRU9GCk== --=-TptnbZ4KDfTyXREtzLYU-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 10 16:04:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06727 for ; Thu, 10 Mar 2005 16:04:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9E79053C2; Thu, 10 Mar 2005 21:04:24 +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 C58EF51A2 for ; Thu, 10 Mar 2005 21:04:22 +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 j2AL4Ehl001397; Thu, 10 Mar 2005 14:04:15 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2AL4DOp012337; Thu, 10 Mar 2005 16:04:14 -0500 (EST) Subject: Editing instructions for core drafts. From: Bill Sommerfeld To: Chris Lonvick Cc: ietf-ssh@NetBSD.org, Russ Housley , Sam Hartman Content-Type: text/plain Message-Id: <1110488647.10971.202.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 10 Mar 2005 15:04:09 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit In addition to the changes you've acknowledged on the list and to me, please make the following changes to the core drafts and re-submit them. 1) Based on the tentative resolution to the trademark reference question in the IPR working group, insert in each of the five core drafts a new section, "Trademark Notice", after "Author's Addresses" and before "Intellectual Property Statement" containing the text: "ssh" is a registered trademark in the United States and/or other countries. The above notice is equivalent to the original notice that was deleted in 2001, with the name of the trademark registrant deleted. This is my interpretation of a reasonable intersection between the IPR-WG's in-the-room consensus that mentioning the identity of a trademark holder in an IETF draft was inapropriate, and the provision in RFC3667 requiring the IETF to preserve trademark notices provided by contributors. The IESG should issue instructions to the RFC editor in the event the above notice needs to be moved or changed. 2) Restore Tatu Ylonen as a listed author for the four original drafts. Restore Sami Lehtinen as a listed author for -assignednumbers. 3) In the -transport draft, fix the issue mentioned this morning by Ben Harris: Insert into the "Summary of Message Numbers" SSH_MSG_KEXDH_INIT 30 SSH_MSG_KEXDH_REPLY 31 When these drafts re-issue, I'll inform Russ & Sam that we've resolved all known issues and the documents should be put on the IESG agenda. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 11 09:55:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29236 for ; Fri, 11 Mar 2005 09:55:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 179B95441; Fri, 11 Mar 2005 14:54:36 +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 F2BF15309 for ; Fri, 11 Mar 2005 14:54:33 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1D9lX6-0004h3-00; Fri, 11 Mar 2005 14:54:32 +0000 From: Ben Harris To: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: Editing instructions for core drafts. In-Reply-To: <1110488647.10971.202.camel@unknown.hamachi.org> References: <1110488647.10971.202.camel@unknown.hamachi.org> Organization: Linux Unlimited Message-Id: Date: Fri, 11 Mar 2005 14:54:32 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1110488647.10971.202.camel@unknown.hamachi.org> you write: >1) Based on the tentative resolution to the trademark reference question >in the IPR working group, insert in each of the five core drafts a new >section, "Trademark Notice", after "Author's Addresses" and before "Intellectual Property Statement" containing the text: > >"ssh" is a registered trademark in the United States and/or other countries. "RC4" is also a registered trademark in the US (registration number 1911168), which was mentioned in earlier drafts. Is it worth mentioning it there? -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 11 10:25:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03661 for ; Fri, 11 Mar 2005 10:25:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 108115309; Fri, 11 Mar 2005 15:25:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-6.csi.cam.ac.uk (ppsw-6.csi.cam.ac.uk [131.111.8.136]) by mail.netbsd.org (Postfix) with ESMTP id 493C25191 for ; Fri, 11 Mar 2005 15:25:18 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:60034) by ppsw-6.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtp id 1D9lm8-0008Iv-JW (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Fri, 11 Mar 2005 15:10:04 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1D9lm6-0007Gr-MW for ietf-ssh@netbsd.org; Fri, 11 Mar 2005 15:10:02 +0000 Date: Fri, 11 Mar 2005 15:10:02 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Better reference for SHA-1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list It's getting a bit late, but I discovered yesterday that there's actually an RFC for SHA-1, so the references in [SSH-TRANS] to [FIPS-180-2] can be changed to refer to RFC 3174. Aside: This has the interesting consequence that it gives us KEX (diffie-hellman-group14-sha1), host-key (ssh-rsa), MAC (hmac-sha1), and cipher (cast128-cbc) algorithms which are specified entirely by RFCs. It's a pity they're not all the required ones, really. No, that's NOT a suggestion that the requirements be changed. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 11 11:59:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14534 for ; Fri, 11 Mar 2005 11:59:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BBC635467; Fri, 11 Mar 2005 16:59:31 +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 06F82544A for ; Fri, 11 Mar 2005 16:59:29 +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 j2BGxQZO018087; Fri, 11 Mar 2005 08:59:26 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2BGxPQp003136; Fri, 11 Mar 2005 11:59:25 -0500 (EST) Subject: Re: Editing instructions for core drafts. From: Bill Sommerfeld To: Ben Harris Cc: "ietf-ssh@netbsd.org" In-Reply-To: References: <1110488647.10971.202.camel@unknown.hamachi.org> Content-Type: text/plain Message-Id: <1110560357.10971.325.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 11 Mar 2005 10:59:18 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-03-11 at 08:54, Ben Harris wrote: > I > >"ssh" is a registered trademark in the United States and/or other countries. > > "RC4" is also a registered trademark in the US (registration number > 1911168), which was mentioned in earlier drafts. Is it worth mentioning it > there? Not under my understanding of (a) the IETF IPR policy with respect to trademark notices, or (b) current trademark law. I am not a lawyer, but, in the process of un-jamming this document, I've learned far more than I ever wanted to know about trademarks. Items #1 and #2 of the editing instructions are tied together. There was a long discussion of this in the IPR-WG archives. The author of 3667 has asserted that the text in rfc3667 that appears to require that authors identify all known 3rd-party trademarks does not actually require that. That said, trademark registrants undermine their own trademarks by not mentioning the registration status in the documents they originate that use the mark. As I understand it, the legally required notice does not require identifying the holder of the mark, just a registration authority. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 11 12:37:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19459 for ; Fri, 11 Mar 2005 12:37:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 29DB75470; Fri, 11 Mar 2005 17:37:13 +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 8B99151F0 for ; Fri, 11 Mar 2005 17:37:11 +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 j2BHb7Rr022115; Fri, 11 Mar 2005 10:37:08 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2BHb6Qp013559; Fri, 11 Mar 2005 12:37:07 -0500 (EST) Subject: Re: Better reference for SHA-1 From: Bill Sommerfeld To: Ben Harris Cc: "ietf-ssh@netbsd.org" In-Reply-To: References: Content-Type: text/plain Message-Id: <1110562619.10971.350.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Fri, 11 Mar 2005 11:37:00 -0600 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-03-11 at 09:10, Ben Harris wrote: > It's getting a bit late, but I discovered yesterday that there's actually > an RFC for SHA-1, so the references in [SSH-TRANS] to [FIPS-180-2] can be > changed to refer to RFC 3174. I'd let the FIPS reference stand as the document is available for free download from the NIST web site. The IESG can opt to instruct the rfc editor to fix this but this is not worth a respin at this stage. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Mar 13 11:52:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23486 for ; Sun, 13 Mar 2005 11:52:08 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 458345302; Sun, 13 Mar 2005 16:51:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id C358E5168 for ; Sun, 13 Mar 2005 16:51:16 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id E3ED01B803E; Sun, 13 Mar 2005 17:50:59 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 17472-02-48; Sun, 13 Mar 2005 17:50:50 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 110871B8039; Sun, 13 Mar 2005 17:50:50 +0100 (CET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2DGomXa006658; Sun, 13 Mar 2005 17:50:49 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2DGod7m006653; Sun, 13 Mar 2005 17:50:39 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Thierry Moreau Cc: Bill Sommerfeld , "ietf-ssh@netbsd.org" Subject: Re: "Host name" definition somewhere in the ID set? References: <422F7A59.4030307@connotech.com> <1110410902.7932.2.camel@unknown.hamachi.org> <422FA0ED.8080609@connotech.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 13 Mar 2005 17:50:37 +0100 In-Reply-To: <422FA0ED.8080609@connotech.com> Message-ID: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Thierry Moreau writes: > My single concern is that "host name" is not defined anywhere in the > SSH Internet drafts. This definition would be by reference to > another document, I guess. Why do you think "host name" needs to be defined? For the "known-hosts database", which assocaites keys to host names? The known-hosts database is mostly an implementation issue. I think it's best to associate keys with whatever name the user types on the command line to connect to it. I've considered if it might be better to use the dns name used to look up the corresponding A/AAAA record, i.e. after processing of the search directive in /etc/resolv.conf, and cname processing. But then one might get fooled by a rogue dns or dhcp server, which defeats the purpose of host authentication. (I think openssh also records the ip address together with the host keys, but I'm not sure how that information is used). /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 15:25:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17674 for ; Mon, 14 Mar 2005 15:25:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3F6B351D0; Mon, 14 Mar 2005 20:25:19 +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 28F2F518C for ; Mon, 14 Mar 2005 20:25:17 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2005 12:40:29 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2EKPFZV017946 for ; Mon, 14 Mar 2005 12:25:15 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA24907 for ; Mon, 14 Mar 2005 12:25:14 -0800 (PST) Date: Mon, 14 Mar 2005 12:25:14 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Core IDs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I've updated the IDs per instructions and have submitted them to the ID Editor. Items of Note: - xml2rfc does not like sections after the authors addresses; it changes them into appendixes. I've placed a note there to tell the RFC Editor that this will need to be changed. Unless someone can hack up the xml2rfc tcl it will probably be done manually in the Authors-48. - Tables and paragraphs are currently not kept closely together - another somthing to be worked on in xml2rfc. As the headers of the documents will change from ID format to RFC format, it's not worth doing at this time. The RFC Editor or I will review to close up tables and remove orphan lines before publication. - We have one ID reference for sasl-saslprep in [USERAUTH]. That ID is in the RFC Editors queue already so it should have an RFC number assigned to it before these IDs are considered. Either the RFC Editor or I will make that change before publication. - I have placed all of the xml sources here: http://www.employees.org/~lonvick/secsh-wg/2005-mar-14/ I've created subdirectories for the includes which match how I've been working on them and how my script works for putting them together (makeem). The directories of 'MiscReferences' and 'references' are populated from xml.resource.org so I didn't duplicate them. - All of the issues have been resolved in rt ( http://rt.psg.com/ ). Anyone wishing to view them will need to go to https://rt.psg.com/ and login with userid=ietf and passwd=ietf Select the secsh-wg issues. It may be easiest to find the ones pertaining to the core IDs by refining the search to my id (clonvick@cisco.com) and selecting status = resolved. - I'm going to be real hard to find for the rest of this week (spring break :) so I wanted to get these out soonest. If anyone finds problems in this set please bring it up on the list and I'll address it just as soon as I get back. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 15:36:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19019 for ; Mon, 14 Mar 2005 15:36:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 94C7E518C; Mon, 14 Mar 2005 20:36:21 +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 DE571516A for ; Mon, 14 Mar 2005 20:36:19 +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 j2EKaDRr005424; Mon, 14 Mar 2005 13:36:14 -0700 (MST) Received: from thunk (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 j2EKaDOp027450; Mon, 14 Mar 2005 15:36:13 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2EKaDAf029249; Mon, 14 Mar 2005 15:36:13 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2EKaDWg029248; Mon, 14 Mar 2005 15:36:13 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Core IDs From: Bill Sommerfeld To: Chris Lonvick Cc: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1110832571.27077.177.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 14 Mar 2005 15:36:12 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-03-14 at 15:25, Chris Lonvick wrote: > - I'm going to be real hard to find for the rest of this week (spring > break :) so I wanted to get these out soonest. If anyone finds problems > in this set please bring it up on the list and I'll address it just as > soon as I get back. Excellent. Thanks for the prompt work. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 16:57:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26354 for ; Mon, 14 Mar 2005 16:57:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D3E051BA; Mon, 14 Mar 2005 21:57:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.netbsd.org (Postfix) with ESMTP id C22915164 for ; Mon, 14 Mar 2005 21:57:22 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 14 Mar 2005 13:57:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2ELuoZV000341 for ; Mon, 14 Mar 2005 13:56:50 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA26756 for ; Mon, 14 Mar 2005 13:56:50 -0800 (PST) Date: Mon, 14 Mar 2005 13:56:50 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Core IDs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, Dang! I knew I forgot something. The nit checker http://ietf.levkowetz.com/tools/idnits/ shows that I have two lines that are too long; one in [ARCH] and one in [NUMBERS]. If we need another revision I'll correct that. If not, I'll correct it when it gets to the RFC Editor. I would appreciate it if someone else would run that on the IDs as well. When I run the checker on my SuSE system, it tells me that [a-z] and [0-9] are non-ascii characters so I'm ignoring those warnings. If you find something, send me the --verbose output and I'll look into it. Thanks, Chris On Mon, 14 Mar 2005, Chris Lonvick wrote: > Hi Folks, > > I've updated the IDs per instructions and have submitted them to the ID > Editor. > > Items of Note: > > - xml2rfc does not like sections after the authors addresses; it changes > them into appendixes. I've placed a note there to tell the RFC Editor > that this will need to be changed. Unless someone can hack up the xml2rfc > tcl it will probably be done manually in the Authors-48. > > - Tables and paragraphs are currently not kept closely together - another > somthing to be worked on in xml2rfc. As the headers of the documents will > change from ID format to RFC format, it's not worth doing at this time. > The RFC Editor or I will review to close up tables and remove orphan > lines before publication. > > - We have one ID reference for sasl-saslprep in [USERAUTH]. That ID is in > the RFC Editors queue already so it should have an RFC number assigned to > it before these IDs are considered. Either the RFC Editor or I will make > that change before publication. > > - I have placed all of the xml sources here: > http://www.employees.org/~lonvick/secsh-wg/2005-mar-14/ > I've created subdirectories for the includes which match how I've been > working on them and how my script works for putting them together > (makeem). The directories of 'MiscReferences' and 'references' are > populated from xml.resource.org so I didn't duplicate them. > > - All of the issues have been resolved in rt ( http://rt.psg.com/ ). > Anyone wishing to view them will need to go to > https://rt.psg.com/ > and login with userid=ietf and passwd=ietf > Select the secsh-wg issues. It may be easiest to find the ones pertaining > to the core IDs by refining the search to my id (clonvick@cisco.com) and > selecting status = resolved. > > - I'm going to be real hard to find for the rest of this week (spring > break :) so I wanted to get these out soonest. If anyone finds problems > in this set please bring it up on the list and I'll address it just as > soon as I get back. > > Thanks, > Chris > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 17:17:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27601 for ; Mon, 14 Mar 2005 17:17:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 970FD51E0; Mon, 14 Mar 2005 22:17:17 +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 01DF55164 for ; Mon, 14 Mar 2005 22:17:15 +0000 (UTC) Received: (qmail 9817 invoked by uid 0); 14 Mar 2005 22:10:28 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.150.189) by woodstock.binhost.com with SMTP; 14 Mar 2005 22:10:28 -0000 Message-Id: <6.2.0.14.2.20050314170947.0709daf0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 14 Mar 2005 17:10:31 -0500 To: Chris Lonvick , ietf-ssh@NetBSD.org From: Russ Housley Subject: Re: Core IDs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list If this is the only change needed, do not worry. This can be resolved with the RFC Editor. Russ At 04:56 PM 3/14/2005, Chris Lonvick wrote: >Dang! I knew I forgot something. The nit checker > http://ietf.levkowetz.com/tools/idnits/ >shows that I have two lines that are too long; one in [ARCH] and one in >[NUMBERS]. If we need another revision I'll correct that. If not, I'll >correct it when it gets to the RFC Editor. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 17:36:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28608 for ; Mon, 14 Mar 2005 17:36:22 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 99FA051BC; Mon, 14 Mar 2005 22:36: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 D0A2C518E for ; Mon, 14 Mar 2005 22:36:16 +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 j2EMaFZO006009; Mon, 14 Mar 2005 14:36:16 -0800 (PST) Received: from thunk (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 j2EMaFOp003285; Mon, 14 Mar 2005 17:36:15 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2EMaFW9029802; Mon, 14 Mar 2005 17:36:15 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2EMaFb3029801; Mon, 14 Mar 2005 17:36:15 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Core IDs From: Bill Sommerfeld To: Chris Lonvick Cc: ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1110839774.27077.219.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 14 Mar 2005 17:36:14 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-03-14 at 16:56, Chris Lonvick wrote: > Hi, > > Dang! I knew I forgot something. The nit checker > http://ietf.levkowetz.com/tools/idnits/ > shows that I have two lines that are too long; one in [ARCH] and one in > [NUMBERS]. If we need another revision I'll correct that. If not, I'll > correct it when it gets to the RFC Editor. no need to respin for this. > I would appreciate it if someone else would run that on the IDs as well. > When I run the checker on my SuSE system, it tells me that [a-z] and [0-9] > are non-ascii characters so I'm ignoring those warnings. If you find > something, send me the --verbose output and I'll look into it. my run of idnits 1.61 on solaris reported the same without the [a-z] and [0-9] warnings.. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 14 19:31:49 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11812 for ; Mon, 14 Mar 2005 19:31:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E0FBD5249; Tue, 15 Mar 2005 00:31:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (cpe-24-28-76-59.austin.res.rr.com [24.28.76.59]) by mail.netbsd.org (Postfix) with ESMTP id 87E4C51BC for ; Tue, 15 Mar 2005 00:31:41 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 8C5C9E0063; Mon, 14 Mar 2005 19:04:49 -0500 (EST) To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Core IDs References: From: Sam Hartman Date: Mon, 14 Mar 2005 19:04:49 -0500 In-Reply-To: (Chris Lonvick's message of "Mon, 14 Mar 2005 12:25:14 -0800 (PST)") 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 >>>>> "Chris" == Chris Lonvick writes: Chris> - We have one ID reference for sasl-saslprep in [USERAUTH]. Chris> That ID is in the RFC Editors queue already so it should Chris> have an RFC number assigned to it before these IDs are Chris> considered. Either the RFC Editor or I will make that Chris> change before publication. That would be RFC 4013. (It's already published). No need to respin, rfc-editor will be happy to deal with this. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 15:48:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07049 for ; Wed, 16 Mar 2005 15:48:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F35F526A; Wed, 16 Mar 2005 20:48:20 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 87D325193 for ; Wed, 16 Mar 2005 20:48:17 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07033; Wed, 16 Mar 2005 15:48:14 -0500 (EST) Message-Id: <200503162048.PAA07033@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-27.txt Date: Wed, 16 Mar 2005 15:48:14 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : C. Lonvick, T. Ylonen Filename : draft-ietf-secsh-userauth-27.txt Pages : 17 Date : 2005-3-16 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-27.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-userauth-27.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-userauth-27.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-3-16161058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-27.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161058.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 15:48:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07181 for ; Wed, 16 Mar 2005 15:48:53 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3CDA25449; Wed, 16 Mar 2005 20:48:50 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 3B7AF542D for ; Wed, 16 Mar 2005 20:48:46 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07138; Wed, 16 Mar 2005 15:48:43 -0500 (EST) Message-Id: <200503162048.PAA07138@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-25.txt Date: Wed, 16 Mar 2005 15:48:43 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick, T. Ylonen Filename : draft-ietf-secsh-connect-25.txt Pages : 25 Date : 2005-3-16 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-25.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-connect-25.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-connect-25.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-3-16161105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-25.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161105.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 15:49:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07287 for ; Wed, 16 Mar 2005 15:49:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 44B44544F; Wed, 16 Mar 2005 20:49:14 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id C11AF5193 for ; Wed, 16 Mar 2005 20:49:11 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07244; Wed, 16 Mar 2005 15:49:09 -0500 (EST) Message-Id: <200503162049.PAA07244@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-22.txt Date: Wed, 16 Mar 2005 15:49:09 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick, T. Ylonen Filename : draft-ietf-secsh-architecture-22.txt Pages : 31 Date : 2005-3-16 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-22.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-architecture-22.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-architecture-22.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-3-16161112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161112.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 15:49:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07468 for ; Wed, 16 Mar 2005 15:49:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 20D7E544E; Wed, 16 Mar 2005 20:49:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 95DC65444 for ; Wed, 16 Mar 2005 20:49:37 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07428; Wed, 16 Mar 2005 15:49:35 -0500 (EST) Message-Id: <200503162049.PAA07428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-12.txt Date: Wed, 16 Mar 2005 15:49:34 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick, S. Lehtinen Filename : draft-ietf-secsh-assignednumbers-12.txt Pages : 23 Date : 2005-3-16 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-12.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-assignednumbers-12.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-assignednumbers-12.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-3-16161119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161119.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 15:50:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07573 for ; Wed, 16 Mar 2005 15:50:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id ACCDA5453; Wed, 16 Mar 2005 20:50:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 28A045450 for ; Wed, 16 Mar 2005 20:50:04 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07533; Wed, 16 Mar 2005 15:50:01 -0500 (EST) Message-Id: <200503162050.PAA07533@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-24.txt Date: Wed, 16 Mar 2005 15:50:00 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick, T. Ylonen Filename : draft-ietf-secsh-transport-24.txt Pages : 32 Date : 2005-3-16 SSH is a protocol for secure remote login and other secure network services over an insecure network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-24.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-transport-24.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-transport-24.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-3-16161126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161126.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 18:58:46 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15445 for ; Wed, 16 Mar 2005 18:58:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 744B252C8; Wed, 16 Mar 2005 23:58:42 +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 63D425164 for ; Wed, 16 Mar 2005 23:58:39 +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 j2GNwVX8028424; Wed, 16 Mar 2005 16:58:31 -0700 (MST) Received: from thunk (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 j2GNwUQp012885; Wed, 16 Mar 2005 18:58:30 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2GNwUe4013730; Wed, 16 Mar 2005 18:58:30 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2GNwT6s013729; Wed, 16 Mar 2005 18:58:30 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Secure Shell core drafts ready for IESG rereview. From: Bill Sommerfeld Cc: Sam Hartman , ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111017508.10564.376.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 16 Mar 2005 18:58:29 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Russ, I believe the most recent revisions of the five Secure Shell core drafts have resolved all outstanding IESG issues and represent the consensus of the secure shell WG. The documents are fundamentally sound; as with any document set of this size we could spend unbounded time tweaking the wording. There have been multiple independant interoperable implementations written from these specs. Publishing them as Proposed Standard is long overdue. I'm turning them over to you to pass to the IESG: draft-ietf-secsh-architecture-22 draft-ietf-secsh-assignednumbers-12 draft-ietf-secsh-connect-25 draft-ietf-secsh-transport-24 draft-ietf-secsh-userauth-27 Editorial Notes: 1) There was a trivial typo introduced in the latest round of edits, most obviously seen in the tools.ietf.org diff page: http://tools.ietf.org/wg/secsh/draft-ietf-secsh-transport/draft-ietf-secsh-transport-24-from-23.diff.html namely: "The "serpent128-cbc" ciphera is the same as above but with a 128-bit key." "ciphera" should of course be "cipher". 2) You requested that we proceed based on the assumption that the in-room consensus of the IPR-WG of last week would stand. The contents of the tradmark notice are the result of my interpretation as an IPR-WG participant of a reasonable combination of the IPR-WG's apparent in-the-room consensus, and the provision in RFC3667 requiring the IETF to preserve trademark notices provided by contributors. Due to limitations of the xml2rfc tools used by the document editor, the "trademark notice" section restored (in modified form) to these drafts appears as an Appendix rather than as an unnumbered section. 3) SHA1 is referenced as [FIPS-180-2] as we were unaware until recently that SHA1 is also described in RFC 3174 (which includes a reference implementation in C combined with text from FIPS 180-2). Either reference alone or both together works for us. 4) The current idnits script generates a few "weird spacing" false positives due to the multi-column notation used within these drafts to describe on-the-wire message formatting. These should be ignored. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 20:16:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21774 for ; Wed, 16 Mar 2005 20:16:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9720E52DF; Thu, 17 Mar 2005 01:16:05 +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 42B985193 for ; Thu, 17 Mar 2005 01:16:03 +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 j2H0rVX8005116; Wed, 16 Mar 2005 17:53:31 -0700 (MST) Received: from thunk (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 j2H0rUQp022522; Wed, 16 Mar 2005 19:53:30 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2H0rUWu013896; Wed, 16 Mar 2005 19:53:30 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2H0rUj5013895; Wed, 16 Mar 2005 19:53:30 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@east.sun.com using -f Subject: Re: WG Chair Copyediting for draft-ietf-secsh-break-02 From: Bill Sommerfeld To: Phillip Remaker Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org In-Reply-To: <01e401c427f9$d8101890$0e6745ab@amer.cisco.com> References: <200404212040.i3LKepQU029100@thunk.east.sun.com> <01e401c427f9$d8101890$0e6745ab@amer.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111020809.10564.434.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 16 Mar 2005 19:53:29 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Exactly. I knew what you meant. But since there is "the implementation of > sshd" and the "implementation of the drivers" and the "implementation of the > UART/chipset," I want to be clear that implementation specific is not the > responsibility of the writer of the SSHD > > "If the SSH server responsible for sending the break has no control over the > hardware that sends break length (as in an opaque UART driver), or has no > way to pass break length information (as in an SSH to telnet gateway), the > implementation MAY (MUST?) still send a BREAK signal, omitting the length > information. Sending a break signal without the length information is still > considered a successful sending of a BREAK." > > Bottom line: Break length is a SUGGESTION, which may be used by the > receiver if it is so capable.. [responding to ~1-year old message]. Now that the core drafts have unwedged, let's get this one going again. -02 has expired. I'd like to start a WGLC on this document as soon as you publish an -03 version. If you don't have previous discussion on this handy, let me know. In addition to the comments I sent in last year, please be aware that there's a new internet-draft "lint" tool called idnits, downloadable from: http://ietf.levkowetz.com/tools/idnits/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 16 21:04:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26046 for ; Wed, 16 Mar 2005 21:04:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C8D2F519D; Thu, 17 Mar 2005 02:04: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 569D95164 for ; Thu, 17 Mar 2005 02:03:58 +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 j2H23vX8017766 for ; Wed, 16 Mar 2005 19:03:57 -0700 (MST) Received: from thunk (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 j2H23vQp003890; Wed, 16 Mar 2005 21:03:57 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2H23vWJ014188; Wed, 16 Mar 2005 21:03:57 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2H23v8Z014187; Wed, 16 Mar 2005 21:03:57 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Secure Shell: Milestone Update. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111025036.10564.461.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 16 Mar 2005 21:03:56 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit As mentioned in our meeting session last week, our milestones are extremely stale because we've been quasi-inactive until issues out of our control were resolved Now that the core drafts have apparently been unwedged, I propose to update our active milestones as follows: DELETE: Drop Agent draft ready for last call Drop Publish draft on X.509v3/pkix support Update: Apr 05 GSSAPI draft ready for last call Apr 05 Resurrect and last-call newmodes Apr 05 Resurrect and last-call secsh-break Apr 05 File transfer draft ready for last call May 05 IESG approval of core drafts We have a large number of nearly complete extensions drafts which expired while the core drafts were wedged. Most just require a little wordsmithing and process tweaking before they can move forward. I'd like to get those done soon so that we can *really* go inactive. I'm proposing to toss two much-requested items over the side because we've had several attempts at writing them fizzle due to lack of energy. The appearance of a volunteer to write them with a committed completion date could well bring them back but I'm not holding my breath. On the other hand, in reviewing RFC2026's requirements for Draft Standard, it is apparent that we are pretty much already there: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. The one thing we are missing is, of course: A specification shall remain at the Proposed Standard level for at least six (6) months. The fine print: The Working Group chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations. The documentation must include information about the support of each of the individual options and features. This documentation should be submitted to the Area Director with the protocol action request. (see Section 6) *IF* I can find a volunteer willing to produce the above documentation for two (or more) SSHv2 implementations, I'll be inclined to add an additional: Jan 06 Submit documentation to Security AD required to advance secure shell protocol core to Draft Standard. Comments? I'd like to send these in by next week. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 02:27:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15317 for ; Thu, 17 Mar 2005 02:27:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9791D5181; Thu, 17 Mar 2005 07:27:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id C50FE5164 for ; Thu, 17 Mar 2005 07:27:27 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 19313390240; Thu, 17 Mar 2005 08:27:21 +0100 (CET) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 0212852753; Thu, 17 Mar 2005 08:27:20 +0100 (CET) Message-ID: <4239336C.1050500@siliconcircus.com> Date: Thu, 17 Mar 2005 08:36:12 +0100 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> In-Reply-To: <1111025036.10564.461.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: > > Drop Agent draft ready for last call > > I'm proposing to toss two much-requested items over the side because > we've had several attempts at writing them fizzle due to lack of > energy. The appearance of a volunteer to write them with a committed > completion date could well bring them back but I'm not holding my > breath. How much work is needed on the Agent draft? I'd be prepared to put some time into it rather than see it die, but I don't know what its most recent status was. I know I've managed to create an interoperable implementation from an old version I found... -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 05:31:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05886 for ; Thu, 17 Mar 2005 05:31:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 113825329; Thu, 17 Mar 2005 10:30:57 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id AFDE05327 for ; Thu, 17 Mar 2005 10:30:53 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 3CEAF39023E; Thu, 17 Mar 2005 11:30:52 +0100 (CET) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 3751952753; Thu, 17 Mar 2005 11:30:52 +0100 (CET) Message-ID: <42395E49.4090608@siliconcircus.com> Date: Thu, 17 Mar 2005 11:39:05 +0100 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Core IDs 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 Hi, Chris Lonvick wrote: > > - xml2rfc does not like sections after the authors addresses; it changes > them into appendixes. I've placed a note there to tell the RFC Editor > that this will need to be changed. Unless someone can hack up the xml2rfc > tcl it will probably be done manually in the Authors-48. Having just done this for a respin of the publickey subsystem draft, I've found the following seems to produce the desired result (after the last : "ssh" is a registered trademark in the United States and/or other countries. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 07:51:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21026 for ; Thu, 17 Mar 2005 07:51:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4B2705341; Thu, 17 Mar 2005 12:51:17 +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 52E085171 for ; Thu, 17 Mar 2005 12:51:15 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1DBuT4-0002h2-00 for ietf-ssh@netbsd.org; Thu, 17 Mar 2005 12:51:14 +0000 Date: Thu, 17 Mar 2005 12:51:14 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: publickeyfile draft (was Re: Secure Shell: Milestone Update.) Message-ID: <20050317125114.GA3827@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: <1111025036.10564.461.camel@thunk> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: > Apr 05 GSSAPI draft ready for last call > Apr 05 Resurrect and last-call newmodes > Apr 05 Resurrect and last-call secsh-break > Apr 05 File transfer draft ready for last call [...] > We have a large number of nearly complete extensions drafts which > expired while the core drafts were wedged. Most just require a little > wordsmithing and process tweaking before they can move forward. I'd > like to get those done soon so that we can *really* go inactive. I notice there's been no mention of the publickeyfile draft. I'm not aware of anything seriously wrong with this document, although I'm not intimately familiar with it. Is there sufficient interest to get it cleaned up for publication? Skimming through draft-ietf-secsh-publickeyfile-05, the only concern I immediately have is the unspecified "interim periods" and "transition periods", such as in the following: | 3.3 Key File Header [...] | Existing implementations may not correctly handle unrecognized | fields. During a transition period, implementations SHOULD generate | key file headers that contain only a Subject field followed by a | Comment field. and | 3.3.2 Comment Header [...] | Currently, common practice is to quote the Header-value of the | Comment, and some existing implementations fail if these quotes are | omitted. | | Compliant implementations MUST function correctly if the quotes are | omitted. | | During an interim period implementations MAY include the quotes. If | the first and last characters of the Header-value are matching | quotes, implementations SHOULD remove them before using the value. Are implementations for which these would cause trouble still worth humouring, or can these be relegated to historical notes or deleted entirely? If not, we need to replace the "interim periods" with something else. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 08:01:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22099 for ; Thu, 17 Mar 2005 08:01:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 480E6534C; Thu, 17 Mar 2005 13:01:23 +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 8AF105171 for ; Thu, 17 Mar 2005 13:01:21 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1DBucq-0003Uo-00 for ietf-ssh@netbsd.org; Thu, 17 Mar 2005 13:01:20 +0000 Date: Thu, 17 Mar 2005 13:01:20 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: agent draft (was Re: Secure Shell: Milestone Update.) Message-ID: <20050317130120.GA11347@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: <4239336C.1050500@siliconcircus.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: > How much work is needed on the Agent draft? I'd be prepared to put some > time into it rather than see it die, but I don't know what its most > recent status was. I know I've managed to create an interoperable > implementation from an old version I found... From a skim of draft-ietf-secsh-agent-02, at least: | The client can add a new private key to the agent with the following | message. Using this message over the net has security implications, and | the implementation SHOULD warn the user before decryption or sending the | private key. (XXX how does ssh-add detect this condition?) | XXX Additional key-types (for private keys), for example "ssh-rsa- | encrypted"? | /* Argument is string defining the allowed forwarding steps for | this key. XXX define this. */ | #define SSH_AGENT_CONSTRAINT_FORWARDING_PATH 100 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 08:47:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27231 for ; Thu, 17 Mar 2005 08:47:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D283535C; Thu, 17 Mar 2005 13:47: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 0D74B5171 for ; Thu, 17 Mar 2005 13:46:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id IAA11540; Thu, 17 Mar 2005 08:46:57 -0500 (EST) From: der Mouse Message-Id: <200503171346.IAA11540@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, 17 Mar 2005 08:41:19 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. In-Reply-To: <1111025036.10564.461.camel@thunk> References: <1111025036.10564.461.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > The Working Group chair is responsible for documenting the > specific implementations which qualify the specification for Draft > or Internet Standard status along with documentation about testing > of the interoperation of these implementations. > *IF* I can find a volunteer willing to produce the above > documentation for two (or more) SSHv2 implementations, Well, I have an independent implementation of much of it which I'd be happy to do interop testing of if anyone else would care to collaborate on it. My code is known to work as a client for basic use (remote login, simple remote commands) against some small number of OpenSSH servers (that being what ships with modern NetBSD), but I'd like to test it against some other implementations. (I can do OpenSSH client against my server - I just haven't yet.) Whether this can happen "by next week" is doubtful.... /~\ 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 Mar 17 09:38:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03391 for ; Thu, 17 Mar 2005 09:38:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 234FF5379; Thu, 17 Mar 2005 14:38:20 +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 5BF8951EF for ; Thu, 17 Mar 2005 14:38:18 +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 j2HEcHX8003917; Thu, 17 Mar 2005 07:38:18 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2HEcHQp021955; Thu, 17 Mar 2005 09:38:17 -0500 (EST) Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: der Mouse Cc: "ietf-ssh@netbsd.org" In-Reply-To: <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ASCII Message-Id: <1111070283.18152.3606.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 17 Mar 2005 09:38:05 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 08:41, der Mouse wrote: > Well, I have an independent implementation of much of it which I'd be > happy to do interop testing of if anyone else would care to collaborate > on it. My code is known to work as a client for basic use (remote > login, simple remote commands) against some small number of OpenSSH > servers (that being what ships with modern NetBSD), but I'd like to > test it against some other implementations. (I can do OpenSSH client > against my server - I just haven't yet.) > > Whether this can happen "by next week" is doubtful.... to clarify: If we want to propose to the IESG that we keep the WG active in order to promptly progress to Draft, I need signs that people are willing to do the required work. Multiple volunteers for this would be good. Because of the required six month "soak time" at Proposed, anyone interested in doing this work will have a minimum of six months to get this done. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 10:02:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07032 for ; Thu, 17 Mar 2005 10:02:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9136D5228; Thu, 17 Mar 2005 15:01:57 +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 358EC51BF for ; Thu, 17 Mar 2005 15:01:55 +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 7246742; Thu, 17 Mar 2005 08:01:53 -0700 Message-ID: <42399BCD.2040607@vandyke.com> Date: Thu, 17 Mar 2005 08:01:33 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> In-Reply-To: <1111025036.10564.461.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 Oskari Saarenmaa is co-authoring the x.509 draft with me. He has a first cut that he is reviewing, and then we will publish the (extremely short) draft. Thanks, Joseph Bill Sommerfeld wrote: > As mentioned in our meeting session last week, our milestones are > extremely stale because we've been quasi-inactive until issues out of > our control were resolved > > Now that the core drafts have apparently been unwedged, I propose to > update our active milestones as follows: > > DELETE: > > Drop Agent draft ready for last call > Drop Publish draft on X.509v3/pkix support > > Update: > > Apr 05 GSSAPI draft ready for last call > Apr 05 Resurrect and last-call newmodes > Apr 05 Resurrect and last-call secsh-break > Apr 05 File transfer draft ready for last call > May 05 IESG approval of core drafts > > We have a large number of nearly complete extensions drafts which > expired while the core drafts were wedged. Most just require a little > wordsmithing and process tweaking before they can move forward. I'd > like to get those done soon so that we can *really* go inactive. > > I'm proposing to toss two much-requested items over the side because > we've had several attempts at writing them fizzle due to lack of > energy. The appearance of a volunteer to write them with a committed > completion date could well bring them back but I'm not holding my > breath. > > On the other hand, in reviewing RFC2026's requirements for Draft > Standard, > it is apparent that we are pretty much already there: > > A specification from which at least two independent and interoperable > implementations from different code bases have been developed, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. > > The one thing we are missing is, of course: > > A specification shall remain at the Proposed Standard level for at > least six (6) months. > > The fine print: > > The Working Group chair is responsible for documenting the specific > implementations which qualify the specification for Draft or Internet > Standard status along with documentation about testing of the > interoperation of these implementations. The documentation must > include information about the support of each of the individual > options and features. This documentation should be submitted to the > Area Director with the protocol action request. (see Section 6) > > *IF* I can find a volunteer willing to produce the above documentation > for two (or more) SSHv2 implementations, I'll be inclined to add an > additional: > > Jan 06 Submit documentation to Security AD required to advance secure > shell protocol core to Draft Standard. > > Comments? I'd like to send these in by next week. > > - Bill > > > > > > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 12:00:58 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24159 for ; Thu, 17 Mar 2005 12:00:57 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A96851E1; Thu, 17 Mar 2005 17:00:55 +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 A0B075176 for ; Thu, 17 Mar 2005 17:00:53 +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 j2HH0qZO029157; Thu, 17 Mar 2005 09:00:52 -0800 (PST) Received: from thunk (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 j2HH0pQp002572; Thu, 17 Mar 2005 12:00:51 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2HH0pS6016625; Thu, 17 Mar 2005 12:00:51 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2HH0pT8016624; Thu, 17 Mar 2005 12:00:51 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org In-Reply-To: <42399BCD.2040607@vandyke.com> References: <1111025036.10564.461.camel@thunk> <42399BCD.2040607@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111078850.16519.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 17 Mar 2005 12:00:50 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 10:01, Joseph Galbraith wrote: > Oskari Saarenmaa is co-authoring the x.509 draft with me. > He has a first cut that he is reviewing, and then we will > publish the (extremely short) draft. i'll restore the milestones if you can promise a publication date for the draft. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 12:16:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26195 for ; Thu, 17 Mar 2005 12:16:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 29E4D5239; Thu, 17 Mar 2005 17:16:30 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id 0F25F5176 for ; Thu, 17 Mar 2005 17:16:28 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 5DF20390465; Thu, 17 Mar 2005 18:16:26 +0100 (CET) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 8B87A52753; Thu, 17 Mar 2005 18:16:26 +0100 (CET) Message-ID: <4239BD50.2030305@siliconcircus.com> Date: Thu, 17 Mar 2005 18:24:32 +0100 From: Jon Bright 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: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200503171346.IAA11540@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: > > Well, I have an independent implementation of much of it which I'd be I have an independent client implementation. I'd be happy to do and document interop testing. What level of documentation is needed? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 14:11:58 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08036 for ; Thu, 17 Mar 2005 14:11:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2A6D552D4; Thu, 17 Mar 2005 19:11:53 +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 1BA0651DE for ; Thu, 17 Mar 2005 19:11:51 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2HJBnNV011353; Thu, 17 Mar 2005 11:11:49 -0800 (PST) Received: from thunk (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 j2HJBnOp001802; Thu, 17 Mar 2005 14:11:49 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2HJBnpe017006; Thu, 17 Mar 2005 14:11:49 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2HJBm06017005; Thu, 17 Mar 2005 14:11:48 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: Jon Bright Cc: der Mouse , ietf-ssh@NetBSD.org In-Reply-To: <4239BD50.2030305@siliconcircus.com> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111086707.16519.135.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 17 Mar 2005 14:11:48 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 12:24, Jon Bright wrote: > > Well, I have an independent implementation of much of it which I'd be > > I have an independent client implementation. I'd be happy to do and > document interop testing. What level of documentation is needed? See the "Implementation reports" filed in: http://www.ietf.org/IESG/implementation.html Some of these are very informal, but as with everything else in the IETF there has been increasing formality over time. There's some history here; see, in particular, http://www.iab.org/appeals/snmpv2smi-appeal.html, which caused RFC2026 to specifically call for feature-by-feature testing. In our case, the protocol is large and complex and has a large number of optional and occasionally-used features. I think the way to go would be: 1) go through the documents, coming up with a list of distinct features. Post this feature list to the WG for review. 2) based on this list, send out an implementation survey asking, for each feature: - have you implemented it? - has it successfully interoperated with another implementation (and, if so, who?) Separate client and server surveys may be appropriate. 3) collect survey responses 4) figure out which features don't have coverage, and either prod implementors to fill in the gap or decide the gap isn't a problem (stripping/deprecating the feature). Some working groups have held interoperability tests, either at/concurrent with IETF meetings, independently, or at other events. Given that many of our implementors have very limited travel/expense budgets, pairwise interoperability testing over the internet by mutual arrangement may be the best bet. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 14:21:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09579 for ; Thu, 17 Mar 2005 14:21:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 62EED533E; Thu, 17 Mar 2005 19:21:30 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (goldfinger.siliconcircus.com [62.141.33.103]) by mail.netbsd.org (Postfix) with ESMTP id 8DDC451DE for ; Thu, 17 Mar 2005 19:21:28 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id B9B4C433C7; Thu, 17 Mar 2005 20:21:22 +0100 (CET) Message-ID: <4239D8AB.2060603@siliconcircus.com> Date: Thu, 17 Mar 2005 20:21:15 +0100 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> In-Reply-To: <1111086707.16519.135.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: > On Thu, 2005-03-17 at 12:24, Jon Bright wrote: > >>>Well, I have an independent implementation of much of it which I'd be >> >>I have an independent client implementation. I'd be happy to do and >>document interop testing. What level of documentation is needed? > > > See the "Implementation reports" filed in: > > http://www.ietf.org/IESG/implementation.html OK, that doesn't seem too onerous. > Some of these are very informal, but as with everything else in the IETF > there has been increasing formality over time. There's some history > here; see, in particular, > http://www.iab.org/appeals/snmpv2smi-appeal.html, which caused RFC2026 > to specifically call for feature-by-feature testing. If no-one else volunteers, I'll see if I can work up a list of features in the next few days. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 17:02:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25358 for ; Thu, 17 Mar 2005 17:02:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5602851ED; Thu, 17 Mar 2005 22:02:10 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 378565164 for ; Thu, 17 Mar 2005 22:02:08 +0000 (UTC) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2HM27NV010141 for ; Thu, 17 Mar 2005 14:02:07 -0800 (PST) Received: from thunk (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 j2HM27Op016299; Thu, 17 Mar 2005 17:02:07 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2HM27dP018655; Thu, 17 Mar 2005 17:02:07 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2HM27AC018654; Thu, 17 Mar 2005 17:02:07 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: <20050317130120.GA11347@chiark.greenend.org.uk> References: <20050317130120.GA11347@chiark.greenend.org.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111096926.16519.321.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 17 Mar 2005 17:02:06 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 08:01, Jacob Nevins wrote: > | The client can add a new private key to the agent with the following > | message. Using this message over the net has security implications, and > | the implementation SHOULD warn the user before decryption or sending the > | private key. (XXX how does ssh-add detect this condition?) > > | XXX Additional key-types (for private keys), for example "ssh-rsa- > | encrypted"? Besides the XXX questions, there's a broader architectural question involved with agent forwarding. Namely, the SSH_AGENT_ADD_KEY request involves sending a valuable private signature key with normally unbounded lifetime over the wire protected only by SSH's underlying cryptographic channel. This exposes the private key far more than most protocols, and precludes use of hardware tokens (such as smart cards) which allow cryptographic operations to be requested without providing all users with a copy of the key. A couple possible alternatives: 1) Some sort of proxy key arrangement such that the private keys don't move and instead the signing requests move to the key rather than the key move to the "root" agent. 2) Some sort of ticket/certificate style arragement where the long term key at a remote agent client is used to sign a certificate "delgating" to a temporary agent key for a limited time. 3) if the agent is the only trusted one and the remote system is not trusted to see the cleartext private key, the key could be stored remotely in encrypted form and decrypted by the agent (using a passphrase or other means). (very different use model.) There's also the "mission creep" question of whether the agent should act as a proxy for other forms of authentication (gssapi/kerberos/...) - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 17:52:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29953 for ; Thu, 17 Mar 2005 17:52:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 36A2A51C7; Thu, 17 Mar 2005 22:52:24 +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 28C9B5164 for ; Thu, 17 Mar 2005 22:52:22 +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 7248080; Thu, 17 Mar 2005 15:52:21 -0700 Message-ID: <423A0A10.6030000@vandyke.com> Date: Thu, 17 Mar 2005 15:52:00 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) References: <20050317130120.GA11347@chiark.greenend.org.uk> <1111096926.16519.321.camel@thunk> In-Reply-To: <1111096926.16519.321.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: > On Thu, 2005-03-17 at 08:01, Jacob Nevins wrote: > >>| The client can add a new private key to the agent with the following >>| message. Using this message over the net has security implications, and >>| the implementation SHOULD warn the user before decryption or sending the >>| private key. (XXX how does ssh-add detect this condition?) >> >>| XXX Additional key-types (for private keys), for example "ssh-rsa- >>| encrypted"? > > > Besides the XXX questions, there's a broader architectural question > involved with agent forwarding. > > Namely, the SSH_AGENT_ADD_KEY request involves sending a valuable > private signature key with normally unbounded lifetime over the wire > protected only by SSH's underlying cryptographic channel. This exposes > the private key far more than most protocols, and > precludes use of hardware tokens (such as smart cards) which allow > cryptographic operations to be requested without providing all users > with a copy of the key. > > A couple possible alternatives: > > 1) Some sort of proxy key arrangement such that the private keys don't > move and instead the signing requests move to the key rather than the > key move to the "root" agent. Outside of the implementation specific issue of how to tell the 'root' agent about key material, I believe the agent protocol can operate in this mode. If an implementation provides some other way to tell the agent about key material and how to access it, the ADD_KEY command is not necessary. For example, the agent running on my local machine could be told about my smart cards and private keys (through some implementation specific means.) Then, agent clients would send "SSH_AGENT_PRIVATE_KEY_OP" with "sign" as the operation to the agent, which eventually gets forwarded to my local agent, where it access the smart card to make the signature. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 20:04:00 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11106 for ; Thu, 17 Mar 2005 20:03:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 72616526A; Fri, 18 Mar 2005 01:03:22 +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 7DA375165 for ; Fri, 18 Mar 2005 01:03:20 +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 j2I13JZO012356 for ; Thu, 17 Mar 2005 17:03:20 -0800 (PST) Received: from thunk (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 j2I13JQp028198; Thu, 17 Mar 2005 20:03:19 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2I13J8n019658; Thu, 17 Mar 2005 20:03:19 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2I13IDv019657; Thu, 17 Mar 2005 20:03:18 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: publickeyfile draft (was Re: Secure Shell: Milestone Update.) From: Bill Sommerfeld To: ietf-ssh@NetBSD.org In-Reply-To: <20050317125114.GA3827@chiark.greenend.org.uk> References: <20050317125114.GA3827@chiark.greenend.org.uk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111107796.16519.681.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 17 Mar 2005 20:03:17 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 07:51, Jacob Nevins wrote: > I notice there's been no mention of the publickeyfile draft. I'm not > aware of anything seriously wrong with this document, although I'm not > intimately familiar with it. Is there sufficient interest to get it > cleaned up for publication? I suspect there may be and I'll be happy to add a May 05 milestone for it when the current document editor responds to the mail I just sent. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 21:31:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16540 for ; Thu, 17 Mar 2005 21:31:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3532A51EF; Fri, 18 Mar 2005 02:31: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 6B505524A for ; Fri, 18 Mar 2005 02:31:22 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA14998; Thu, 17 Mar 2005 21:31:17 -0500 (EST) From: der Mouse Message-Id: <200503180231.VAA14998@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, 17 Mar 2005 21:18:57 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) In-Reply-To: <1111096926.16519.321.camel@thunk> References: <20050317130120.GA11347@chiark.greenend.org.uk> <1111096926.16519.321.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > [T]here's a broader architectural question involved with agent > forwarding. > Namely, the SSH_AGENT_ADD_KEY request involves sending a valuable > private signature key with normally unbounded lifetime over the wire > protected only by SSH's underlying cryptographic channel. True, as far as it goes. > This exposes the private key far more than most protocols, True. > and precludes use of hardware tokens (such as smart cards) which > allow cryptographic operations to be requested without providing all > users with a copy of the key. False, fortunately. There is no reason why SSH_AGENT_ADD_KEY has to be the only mechanism for rendering the agent capable of handling a PRIVATE_KEY_OP request. An agent could easily have some private channel to a smartcard; such an agent might well come up with the appropriate key already installed, or might have it appear mid-run (as if some other client had added it, as far as all clients are concerned). It is probably beyond our scope to try to define how such an agent might talk to its smartcard or whatever, or how it would be configured to do so - but there is nothing in what we've got that prevents it from being done if someone cares to. /~\ 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 Mar 17 22:22:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21375 for ; Thu, 17 Mar 2005 22:22:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6B5D35181; Fri, 18 Mar 2005 03:22:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 6D6245165 for ; Fri, 18 Mar 2005 03:22:02 +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 7248528; Thu, 17 Mar 2005 20:22:01 -0700 Message-ID: <423A4946.1090006@vandyke.com> Date: Thu, 17 Mar 2005 20:21:42 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> <42399BCD.2040607@vandyke.com> <1111078850.16519.38.camel@thunk> In-Reply-To: <1111078850.16519.38.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: > On Thu, 2005-03-17 at 10:01, Joseph Galbraith wrote: > >>Oskari Saarenmaa is co-authoring the x.509 draft with me. >>He has a first cut that he is reviewing, and then we will >>publish the (extremely short) draft. > > > i'll restore the milestones if you can promise a publication date for > the draft. Well, how about I send a draft tomorrow or Monday, and if I manage to come through w/ that you can restore the milestone :-) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 17 23:29:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27618 for ; Thu, 17 Mar 2005 23:29:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AFCCD518A; Fri, 18 Mar 2005 04:29:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id 57E955165 for ; Fri, 18 Mar 2005 04:29:10 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id E39CA76F2A; Thu, 17 Mar 2005 23:28:44 -0500 (EST) To: Bill Sommerfeld Cc: Jon Bright , der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> From: Sam Hartman Date: Thu, 17 Mar 2005 23:28:44 -0500 In-Reply-To: <1111086707.16519.135.camel@thunk> (Bill Sommerfeld's message of "Thu, 17 Mar 2005 14:11:48 -0500") Message-ID: <871xadinlv.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> 1) go through the documents, coming up with a list of Bill> distinct features. Post this feature list to the WG for Bill> review. I've never advanced something to draft before, so I'll be new at this too. It will be a bit of a race to see whether ssh or Kerberos deals with this documentation challenge first. My understanding is that the construction of the feature list is the most challenging part of the process. You want to avoid having too many features; treating each MUST/SHOULD/mAY as a feature is clearly too much effort and in many cases results in untestable features. However if your feature list is too course you risk appeal or a discuss vote at the IESG. I've talked to Russ about this and received some advice I'll pass along. Avoid getting yourself into a situation where you need to test a MUST NOT. For example, it would be difficult to verify conformance if you listed "MUST NOT crash on badly formed input," as a feature. In general, if testing something to go to draft requires you to write code to generate invalid input or to create a can't happen situation then you are doing something wrong and probably doing too much work. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 05:53:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19715 for ; Fri, 18 Mar 2005 05:53:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6055F51A5; Fri, 18 Mar 2005 10:53:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ixion.tartarus.org (ixion.tartarus.org [62.197.40.170]) by mail.netbsd.org (Postfix) with ESMTP id 303FF516C for ; Fri, 18 Mar 2005 10:53:10 +0000 (UTC) Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1DCErB-0004QE-00; Fri, 18 Mar 2005 10:37:29 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <1111096926.16519.321.camel@thunk> Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) Message-Id: Date: Fri, 18 Mar 2005 10:37:29 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: > 3) if the agent is the only trusted one and the remote system is not > trusted to see the cleartext private key, the key could be stored > remotely in encrypted form and decrypted > by the agent (using a passphrase or other means). (very different use > model.) The PuTTY team has had quite a lot of requests for a use model like this, because it provides other desirable features such as the ability to store all your keys encrypted until they're first needed and ask for their passphrases as required. The slightly fiddly bit is that there's currently no standard for the format of an encrypted private key, and every implementation I know of has its own format and would probably be reluctant to switch to a standard one. Therefore I was planning to implement this (if and when I get round to it at all) by means of a user-defined- extension mechanism in the agent protocol, rather than attempting to suggest a standardised form. -- Simon Tatham "My heart bleeds. (That's how it works.)" -- Gareth Taylor From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 08:14:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05832 for ; Fri, 18 Mar 2005 08:14:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 65AE052E1; Fri, 18 Mar 2005 13:14:24 +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 A5DBA51D6 for ; Fri, 18 Mar 2005 13:14:21 +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 j2IDEDZO026560; Fri, 18 Mar 2005 05:14:13 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2IDECQp015779; Fri, 18 Mar 2005 08:14:12 -0500 (EST) Subject: Re: Secure Shell: Milestone Update. From: Bill Sommerfeld To: Sam Hartman Cc: Jon Bright , der Mouse , "ietf-ssh@netbsd.org" In-Reply-To: <871xadinlv.fsf@luminous.mit.edu> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> <871xadinlv.fsf@luminous.mit.edu> Content-Type: text/plain Message-Id: <1111151638.18152.4340.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 18 Mar 2005 08:13:59 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-17 at 23:28, Sam Hartman wrote: > >>>>> "Bill" == Bill Sommerfeld writes: > You want to avoid having too > many features; treating each MUST/SHOULD/mAY as a feature is clearly > too much effort and in many cases results in untestable features. > However if your feature list is too course you risk appeal or a > discuss vote at the IESG. though clearly major features which are known to have caused interop difficulty in the past (rekey comes to mind) should be on the list as distinct test points. > Avoid getting yourself into a situation where you need to test a MUST > NOT. For example, it would be difficult to verify conformance if you > listed "MUST NOT crash on badly formed input," as a feature. In > general, if testing something to go to draft requires you to write > code to generate invalid input or to create a can't happen situation > then you are doing something wrong and probably doing too much work. That sounds like very good advice. Such tests are often valuable but are probably better left as regression/stress/abuse tests. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 08:44:51 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07594 for ; Fri, 18 Mar 2005 08:44:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D8E0752CD; Fri, 18 Mar 2005 13:44:43 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 9FE6751D6 for ; Fri, 18 Mar 2005 13:44:39 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 9AE5E1B8062; Fri, 18 Mar 2005 14:44:22 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 10129-02-15; Fri, 18 Mar 2005 14:44:09 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 757901B8064; Fri, 18 Mar 2005 14:44:09 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2IDi9Xa020966; Fri, 18 Mar 2005 14:44:09 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2IDi3X4020960; Fri, 18 Mar 2005 14:44:03 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 18 Mar 2005 14:44:00 +0100 In-Reply-To: Message-ID: Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Simon Tatham writes: > Bill Sommerfeld wrote: > > 3) if the agent is the only trusted one and the remote system is not > > trusted to see the cleartext private key, the key could be stored > > remotely in encrypted form and decrypted > > by the agent (using a passphrase or other means). (very different use > > model.) > > The PuTTY team has had quite a lot of requests for a use model like > this, because it provides other desirable features such as the > ability to store all your keys encrypted until they're first needed > and ask for their passphrases as required. This leads to an interesting twist of password authentication. Setup: User creates a keypair, and encrypts the private half using a passphrase. (This naturally has to be done on a trusted machine). User transfers public key and encrypted private key to one or more servers. Login: Client asks server for encrypted private key. User types in passphrase to decrypt it. Key is used to sign the session id, just like for plain publickey authentication. At a first look, the security properties seem quite similar to plain password authentication, but with the important difference that the server never, not even temporarily, has access to the clear text passphrase, and that it should be reasonable safe to use the same passphrase with several mutually untrusting servers. I think I've read a few papers on session setup, where the scenario is that the user sits at a (trusted) terminal, but has no keys, certificates, hostkeys or any other personal information stored locally. However, the user knows a secret passphrase. The objective is to make use of this passphrase to download private keys, certificates etc from the server in a secure way, with as little trust as possible put on the server. But for login, I think it would be even better with something in the srp/speke class of password authentication. Important objectives are: Use passphrase also to authenticate the server (so we can bootstrap without hostkeys). And don't transmit anything on the wire that allows an eavesdropper or MITM to mount a dictionary attack. It's REALLY a shame almost everything in that area seem to be patented. (I think http://www.watersprings.org/pub/id/draft-perlman-strong-pass-00.txt was written in an attempt to get around patents, but there are broad patents in the area that might cover even this fairly unique construction). Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 09:44:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13291 for ; Fri, 18 Mar 2005 09:44:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9AC7452DA; Fri, 18 Mar 2005 14:44:06 +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 D927C5179 for ; Fri, 18 Mar 2005 14:44:04 +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 j2IEi2Rr017256; Fri, 18 Mar 2005 07:44:02 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2IEi1Op022582; Fri, 18 Mar 2005 09:44:02 -0500 (EST) Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) From: Bill Sommerfeld To: Niels M?ller Cc: Simon Tatham , "ietf-ssh@netbsd.org" In-Reply-To: References: Content-Type: text/plain; charset=ASCII Message-Id: <1111157028.18152.4375.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Fri, 18 Mar 2005 09:43:49 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Fri, 2005-03-18 at 08:44, Niels M?ller wrote: > But for login, I think it would be even better with something in the > srp/speke class of password authentication. Important objectives are: > Use passphrase also to authenticate the server (so we can bootstrap > without hostkeys). And don't transmit anything on the wire that allows > an eavesdropper or MITM to mount a dictionary attack. It's REALLY a > shame almost everything in that area seem to be patented. The patent isn't the issue -- it's the license terms offered. compare: http://www.ietf.org/ietf/IPR/WU-SRP with: http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt Given that many important implementations of ssh are free-as-in-beer, anything but royalty-free license terms is not worth our time. The patents in this space have been very frustrating to a number of IETF WG's. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 16:32:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11338 for ; Fri, 18 Mar 2005 16:32:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6226E532F; Fri, 18 Mar 2005 21:32:43 +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 2144051B0 for ; Fri, 18 Mar 2005 21:32:41 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12693; 18 Mar 2005 16:32 EST Date: Fri, 18 Mar 2005 16:32:05 -0500 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) Message-ID: In-Reply-To: <200503180231.VAA14998@Sparkle.Rodents.Montreal.QC.CA> References: <20050317130120.GA11347@chiark.greenend.org.uk> <1111096926.16519.321.camel@thunk> <200503180231.VAA14998@Sparkle.Rodents.Montreal.QC.CA> Originator-Info: login-token=Mulberry:01b42TINn1CJS72AuhogvDjwb/ykv2wQzcAsGFpQ0=; 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, March 17, 2005 09:18:57 PM -0500 der Mouse wrote: > There is no reason why SSH_AGENT_ADD_KEY has to be the only mechanism > for rendering the agent capable of handling a PRIVATE_KEY_OP request. > An agent could easily have some private channel to a smartcard; such an > agent might well come up with the appropriate key already installed, or > might have it appear mid-run (as if some other client had added it, as > far as all clients are concerned). This is not just theoretical. I have been using a smartcard-enabled ssh agent for over a year, using off-the-shelf components from OpenSSH, OpenSC, and PCSC-Lite. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 16:38:07 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12005 for ; Fri, 18 Mar 2005 16:38:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5D04E5369; Fri, 18 Mar 2005 21:38:04 +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 ED96B5164 for ; Fri, 18 Mar 2005 21:38:01 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12696; 18 Mar 2005 16:37 EST Date: Fri, 18 Mar 2005 16:37:37 -0500 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) Message-ID: <7B4F4E878E851CA3CD6B4B1F@sirius.fac.cs.cmu.edu> In-Reply-To: References: Originator-Info: login-token=Mulberry:01bmWgYNjNFdS6sBjhoePQzwXX14v1mRnb2s7FpOU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, March 18, 2005 02:44:00 PM +0100 Niels M=F6ller=20 wrote: > Simon Tatham writes: > >> Bill Sommerfeld wrote: >> > 3) if the agent is the only trusted one and the remote system is not >> > trusted to see the cleartext private key, the key could be stored >> > remotely in encrypted form and decrypted >> > by the agent (using a passphrase or other means). (very different use >> > model.) >> >> The PuTTY team has had quite a lot of requests for a use model like >> this, because it provides other desirable features such as the >> ability to store all your keys encrypted until they're first needed >> and ask for their passphrases as required. > > This leads to an interesting twist of password authentication. > > Setup: User creates a keypair, and encrypts the private half using a > passphrase. (This naturally has to be done on a trusted machine). User > transfers public key and encrypted private key to one or more servers. > > Login: Client asks server for encrypted private key. User types in > passphrase to decrypt it. Key is used to sign the session id, just > like for plain publickey authentication. This seems like an interesting model, and quite possibly the subject of a=20 draft describing a new userauth method. Whether that's something this WG=20 would want to accept as a work item, I don't know -- we seem to already=20 have a lot of documents on our plate that aren't getting enough attention. My main concern at the moment is that the approach you describe would make=20 it fairly easy to obtain a copy of the encrypted private key on which to=20 perform an offline dictionary attack... I suppose I could also insert a plug here for the gssapi-with-mic userauth=20 method, used in conjunction with the Kerberos GSSAPI mechanism. It is=20 entirely reasonable for an ssh client to prompt a user to obtain Kerberos=20 tickets by typing a password, then use the resulting tickets to=20 authenticate to the ssh server. In fact, I believe there are=20 configurations in use today which work this way, when the user doesn't=20 already have tickets. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 18 16:39:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12222 for ; Fri, 18 Mar 2005 16:39:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CCF03536E; Fri, 18 Mar 2005 21:39:42 +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 260B95164 for ; Fri, 18 Mar 2005 21:39:41 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa12699; 18 Mar 2005 16:39 EST Date: Fri, 18 Mar 2005 16:39:13 -0500 From: Jeffrey Hutzelman To: Sam Hartman , Bill Sommerfeld Cc: Jon Bright , der Mouse , ietf-ssh@NetBSD.org Subject: Re: Secure Shell: Milestone Update. Message-ID: <5414F45ED18E016712F63D63@sirius.fac.cs.cmu.edu> In-Reply-To: <871xadinlv.fsf@luminous.mit.edu> References: <1111025036.10564.461.camel@thunk> <200503171346.IAA11540@Sparkle.Rodents.Montreal.QC.CA> <4239BD50.2030305@siliconcircus.com> <1111086707.16519.135.camel@thunk> <871xadinlv.fsf@luminous.mit.edu> Originator-Info: login-token=Mulberry:01v5b6aCn+b9wL4XLp8hQq11YIMZNGynMsCyjN9RY=; 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, March 17, 2005 11:28:44 PM -0500 Sam Hartman wrote: > I've never advanced something to draft before, so I'll be new at this > too. It will be a bit of a race to see whether ssh or Kerberos deals > with this documentation challenge first. Ooh, a race. That sounds fun! :-) -- Jeff (Kerberos WG chair) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Mar 19 15:00:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17600 for ; Sat, 19 Mar 2005 15:00:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CF6B1546A; Sat, 19 Mar 2005 20:00:19 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mail.netbsd.org (Postfix) with ESMTP id 0E3D75189 for ; Sat, 19 Mar 2005 20:00:18 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:63535) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DCjrz-0004So-Rg (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Sat, 19 Mar 2005 19:44:23 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DCjrz-0001F6-8S for ietf-ssh@netbsd.org; Sat, 19 Mar 2005 19:44:23 +0000 Date: Sat, 19 Mar 2005 19:44:23 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: "arcfour-fixes" draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list As [SSH-TRANS] mentions, its definition of the "arcfour" algorithm suffers from weak keys. I've written a specification for a variant of the algorithm that prevents this by just discarding the beginning of the Arcfour keystream. I've posted it as , and invite the WG to comment on it. I think this is at least as important as newmodes, but I appreciate that it may be rather too late to get it turned into a WG draft. Incidentally, having read more of Fluhrer and McGrew's paper, I think my recommendation in the Security Considerations section to rekey every 1G of data is useless and I intend to remove it in the next revision. I'll try to work out some text that describes the real impact of their discriminator to replace it. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Mar 20 21:13:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16588 for ; Sun, 20 Mar 2005 21:13:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AF3CB5268; Mon, 21 Mar 2005 02:12:56 +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 1DDA35164 for ; Mon, 21 Mar 2005 02:12:53 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA11526; Sun, 20 Mar 2005 21:12:52 -0500 (EST) From: der Mouse Message-Id: <200503210212.VAA11526@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: Sun, 20 Mar 2005 21:14:19 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: latest drafts Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I just finished reading over the latest set of drafts. I seem to have missed a set before the latest; all my comparisons were to two drafts back (eg, userauth-27 is compared to userauth-25, not -26). Here's the latest round of things I notice. userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he message may consist of multiple lines", but gives no indication how line breaks are to be encoded. Most notably, it's not clear whether CRLF or bare NL should be used, nor whether there are other possibilities that implementations should be prepared for. (Note that transport-24's description of SSH_MSG_DEBUG explicitly says to use CRLF.) Various places speak of doing control character filtering as discussed in [SSH-ARCH]. I've been unable to find the referenced discussion in architecture-22. Searching for "filter" returns no hits; searching for "control" returns only false positives. I even went so far as to read the whole document through, and while I could have missed something, I feel confident in saying that at the very least the discussion is hidden excessively well. architecture-22 section 8 says "which may be superceded in the future"; the word is actually spelled "superseded". architecture-22 has a line the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of which is missing a sentence-end period. architecture-22 9.3.5 says that publickey makes no server security assumptions. But this is not quite true; a compromised server may be able to use a publickey authentication attempt to play MitM to authenticate to another host as if it held a public key it does not in fact hold. I'm not sure how feasible this is, because public-key signatures are over data blobs including session-specific portions, but it's certainly not obvious to me that it's impossible. connect-25 6.10 has a message description with a "o" bullet for each line; the rest of the message descriptions look different. conenct-25 7.1 sez address or domain name and port to which the socket to be listened is [page break] bound. I'd prefer to see "is to be bound"; there also seems to be a "to" missing after "listened". (I'm not entirely sure I like to see "socket" here, since there is no requirement that the TCP interface in question be sockets. I'm not sure this is worth fixing.) Various specifications in transport-24 break rather badly if the cipher in use has a block size that is less than 8 bytes but which does not divide evenly into 8 bytes. The spec for per-packet padding is perhaps the most obvious, but by no means the only, such; I can go through and extract a full list if desired. /~\ 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 Mar 21 03:51:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05888 for ; Mon, 21 Mar 2005 03:51:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6DCB85224; Mon, 21 Mar 2005 08:50:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id AEA83516D for ; Mon, 21 Mar 2005 08:50:54 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 01D2E1B8071; Mon, 21 Mar 2005 09:50:47 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 04162-01-47; Mon, 21 Mar 2005 09:50:37 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 1FC1C1B8070; Mon, 21 Mar 2005 09:50:37 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2L8oaXa007405; Mon, 21 Mar 2005 09:50:36 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2L8oUxR007402; Mon, 21 Mar 2005 09:50:30 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Bill Sommerfeld Cc: Simon Tatham , "ietf-ssh@netbsd.org" Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) References: <1111157028.18152.4375.camel@unknown.hamachi.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 21 Mar 2005 09:50:29 +0100 In-Reply-To: <1111157028.18152.4375.camel@unknown.hamachi.org> Message-ID: Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > The patent isn't the issue -- it's the license terms offered. > > compare: http://www.ietf.org/ietf/IPR/WU-SRP > with: http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt I guess Phoenix haven't cared to indicate which claims of their patent 6,226,383 are infringed by SRP or by http://www.watersprings.org/pub/id/draft-perlman-strong-pass-00.txt? I think the inventor, David Jablon, is or used to be a member of this wg. Would you mind clarifying? To me, the first claim of US patent 6,226,383 is really bizarre. It is of the form [...desirable properties for a key exhange protocol based on a shared secret S, including dictionary attack...] Claimed: Any method that meets those objectives, by using some public-key mechanism in some way parametrized by S. And then the patent even goes on to cite prior art that meets precisely the same objectives, using exactly the same high level "method"! The draft by Radia Perlman and Charlie Kaufman is quite different from all other secure password authentication methods, in that the choice of primes is parametrized by the password. But of course, like any other method that solves the problem using any public-key techniques whatsoever, I guess it could infringe Jablon's claim 1, assuming that claim really is valid. BTW, is it correct that it is possible to update one's patent claims during the time between patent application and patent issue? In this case, the timing is as follows: Patent application: March 25, 1997. Perlman-Kaufman draft: June 26, 2000. Patent issued: May 1, 2001. Sorry if this discussion is off-topic, but it's really frustrating. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 03:52:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05963 for ; Mon, 21 Mar 2005 03:52:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5C86E5236; Mon, 21 Mar 2005 08:52:40 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id 2589A522A for ; Mon, 21 Mar 2005 08:52:37 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 99F621B8071; Mon, 21 Mar 2005 09:52:35 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 04162-01-51; Mon, 21 Mar 2005 09:52:26 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id CAF5A1B8070; Mon, 21 Mar 2005 09:52:26 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2L8qQXa007415; Mon, 21 Mar 2005 09:52:26 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2L8qMvn007412; Mon, 21 Mar 2005 09:52:22 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: agent draft (was Re: Secure Shell: Milestone Update.) References: <7B4F4E878E851CA3CD6B4B1F@sirius.fac.cs.cmu.edu> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 21 Mar 2005 09:52:21 +0100 In-Reply-To: <7B4F4E878E851CA3CD6B4B1F@sirius.fac.cs.cmu.edu> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 Jeffrey Hutzelman writes: > On Friday, March 18, 2005 02:44:00 PM +0100 Niels Möller > wrote: > > Login: Client asks server for encrypted private key. User types in > > passphrase to decrypt it. Key is used to sign the session id, just > > like for plain publickey authentication. [...] > My main concern at the moment is that the approach you describe would > make it fairly easy to obtain a copy of the encrypted private key on > which to perform an offline dictionary attack... Right. That's why one would want to use something more sophisticated, like SRP. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 07:06:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25804 for ; Mon, 21 Mar 2005 07:06:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 370645288; Mon, 21 Mar 2005 12:06:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 2C079516D for ; Mon, 21 Mar 2005 12:06:07 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DDLfZ-0003NE-00; Mon, 21 Mar 2005 12:06:05 +0000 From: Ben Harris To: mouse@Rodents.Montreal.QC.CA, ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Mon, 21 Mar 2005 12:06:05 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> you write: >Various places speak of doing control character filtering as discussed >in [SSH-ARCH]. I've been unable to find the referenced discussion in >architecture-22. It looks like it got lost when the Security Considerations section was rewritten in architecture-14 (2003-07-14). Before that, it said: When displaying text, such as error or debug messages to the user, the client software SHOULD replace any control characters (except tab, carriage return and newline) with safe sequences to avoid attacks by sending terminal control characters. >architecture-22 9.3.5 says that publickey makes no server security >assumptions. But this is not quite true; a compromised server may be >able to use a publickey authentication attempt to play MitM to >authenticate to another host as if it held a public key it does not in >fact hold. I'm not sure how feasible this is, because public-key >signatures are over data blobs including session-specific portions, but >it's certainly not obvious to me that it's impossible. The protocol is designed to make this kind of attack impossible. publickey signatures are over (amongst other things) the session ID. For a server to MITM a publickey authentication, it would have to get the session IDs for the two connections to be the same, which would mean getting two hashes with partially different inputs (since some input in each case is the other side's KEXINIT cookie) to have the same output. This is at least as hard as finding a collision in the hash, which is assumed to be sufficiently difficult. If it isn't sufficiently difficult, you need a stronger exchange hash. >Various specifications in transport-24 break rather badly if the cipher >in use has a block size that is less than 8 bytes but which does not >divide evenly into 8 bytes. The spec for per-packet padding is perhaps >the most obvious, but by no means the only, such; I can go through and >extract a full list if desired. I think the simple answer is that you can't use such a cipher with SSH, which seems fine to me. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 09:00:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05812 for ; Mon, 21 Mar 2005 09:00:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 382A35347; Mon, 21 Mar 2005 14:00:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id E35C45211 for ; Mon, 21 Mar 2005 14:00:07 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 063B71B807A; Mon, 21 Mar 2005 14:59:59 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 22999-01-46; Mon, 21 Mar 2005 14:59:43 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 481861B80D4; Mon, 21 Mar 2005 14:59:43 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2LDxgXa010141; Mon, 21 Mar 2005 14:59:42 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2LDxY2p010138; Mon, 21 Mar 2005 14:59:34 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: latest drafts References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 21 Mar 2005 14:59:33 +0100 In-Reply-To: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > architecture-22 9.3.5 says that publickey makes no server security > assumptions. But this is not quite true; a compromised server may be > able to use a publickey authentication attempt to play MitM to > authenticate to another host as if it held a public key it does not in > fact hold. I'm not sure how feasible this is, because public-key > signatures are over data blobs including session-specific portions, but > it's certainly not obvious to me that it's impossible. I agree it would be desirable to clarify this, as it's not crystal clear what the MiTM can do and can't do in the scenario with no host authentication, and publickey userauth. > Various specifications in transport-24 break rather badly if the cipher > in use has a block size that is less than 8 bytes but which does not > divide evenly into 8 bytes. I think this is a non-issue. There's no exisitng block cipher in wide use that have a block size that isn't a power of two, as far as I'm aware. And block ciphers that are adopted in the future ought to have a block size no smaller than 8 bytes, for the same reasons that AES uses a larger block size. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 10:22:34 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15592 for ; Mon, 21 Mar 2005 10:22:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E5F085398; Mon, 21 Mar 2005 15:22:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mail.netbsd.org (Postfix) with ESMTP id 5635F516D for ; Mon, 21 Mar 2005 15:22:20 +0000 (UTC) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Mar 2005 10:22:20 -0500 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2LFMHjI000582 for ; Mon, 21 Mar 2005 10:22:18 -0500 (EST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA20854 for ; Mon, 21 Mar 2005 07:22:17 -0800 (PST) Date: Mon, 21 Mar 2005 07:22:17 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Sun, 20 Mar 2005, der Mouse wrote: > I just finished reading over the latest set of drafts. I seem to have > missed a set before the latest; all my comparisons were to two drafts > back (eg, userauth-27 is compared to userauth-25, not -26). Here's the > latest round of things I notice. > > userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he > message may consist of multiple lines", but gives no indication how > line breaks are to be encoded. Most notably, it's not clear whether > CRLF or bare NL should be used, nor whether there are other > possibilities that implementations should be prepared for. (Note that > transport-24's description of SSH_MSG_DEBUG explicitly says to use > CRLF.) Suggestions from anyone? > > Various places speak of doing control character filtering as discussed > in [SSH-ARCH]. I've been unable to find the referenced discussion in > architecture-22. Searching for "filter" returns no hits; searching for > "control" returns only false positives. I even went so far as to read > the whole document through, and while I could have missed something, I > feel confident in saying that at the very least the discussion is > hidden excessively well. This text appeared in [ARCH]-11: When displaying text, such as error or debug messages to the user, the client software SHOULD replace any control characters (except tab, carriage return and newline) with safe sequences to avoid attacks by sending terminal control characters. There were three paragraphs in the Security Considerations section. This text appeared in [ARCH]-12: When displaying text, such as error or debug messages to the user, the client software SHOULD replace any control characters (except tab, carriage return and newline) with safe sequences to avoid attacks by sending terminal control characters. There were 4 paragraphs then. After that, the WG revised the Security Considerations section so that the security considerations of all other documents were incorporated into the Security Considerations section of [ARCH]. Such text does not seem to appear in any of the IDs at this time. Should it be restored in the general Security Considerations section like the section on "Pseudo-Random Number Generation", or should it be restored within a particular section (Transport, Connection, User Auth)? > > architecture-22 section 8 says "which may be superceded in the future"; > the word is actually spelled "superseded". The spellchecker in kate doesn't object to it. Nontheless, I'll change it. > > architecture-22 has a line > the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of > which is missing a sentence-end period. OK. > > architecture-22 9.3.5 says that publickey makes no server security > assumptions. But this is not quite true; a compromised server may be > able to use a publickey authentication attempt to play MitM to > authenticate to another host as if it held a public key it does not in > fact hold. I'm not sure how feasible this is, because public-key > signatures are over data blobs including session-specific portions, but > it's certainly not obvious to me that it's impossible. Does Ben's note cover this? > > connect-25 6.10 has a message description with a "o" bullet for each > line; the rest of the message descriptions look different. Yuck. I'll fix it. > > conenct-25 7.1 sez > address or domain name and port to which the socket to be listened is > [page break] > bound. > I'd prefer to see "is to be bound"; there also seems to be a "to" > missing after "listened". Which do you want; The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket to be listened to is bound. Some strings used for the 'address to bind' have special-case semantics. -or- The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket is to be bound. Some strings used for the 'address to bind' have special-case semantics. > (I'm not entirely sure I like to see > "socket" here, since there is no requirement that the TCP interface in > question be sockets. I'm not sure this is worth fixing.) If we can get some quick consensus we can probably squeeze it in. > > Various specifications in transport-24 break rather badly if the cipher > in use has a block size that is less than 8 bytes but which does not > divide evenly into 8 bytes. The spec for per-packet padding is perhaps > the most obvious, but by no means the only, such; I can go through and > extract a full list if desired. Does Ben's note address this? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 12:14:23 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27719 for ; Mon, 21 Mar 2005 12:14:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 24C1553BF; Mon, 21 Mar 2005 17:14:19 +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 A5F6B515B for ; Mon, 21 Mar 2005 17:14:16 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA28883; Mon, 21 Mar 2005 12:14:15 -0500 (EST) From: der Mouse Message-Id: <200503211714.MAA28883@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, 21 Mar 2005 12:02:17 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> architecture-22 9.3.5 says that publickey makes no server security >> assumptions. But this is not quite true; a compromised server may >> be able to use a publickey authentication attempt to play MitM to >> authenticate to another host as if it held a public key it does not >> in fact hold. I must have been short of sleep when I wrote this. What I had in mind was authenticating via some other protocol, not via ssh, using the ssh client connection as a public-key engine. But of course the defenses put in place to prevent MitM use this way for ssh also prevent its use as a general-purpose signing engine - anything that allows an ssh client connection to be used as a generic public-key engine will of necessity work perfectly well to perform MitM attacks on ssh as well. So please ignore that paragraph. >> Various specifications in transport-24 break rather badly if the >> cipher in use has a block size that is less than 8 bytes but which >> does not divide evenly into 8 bytes. [...] > I think the simple answer is that you can't use such a cipher with > SSH, which seems fine to me. Yes, but I would prefer to see this stated explicitly. Otherwise someone reading it could wonder, as I did, "but what about, say, a cipher with 7-byte blocks, how would I add that to my implementation?". Or a cipher with a block size that's not a multiple of 8 bits. Before you laugh too hard at the idea that such a cipher might exist, note that DES has 7-byte keys (though they're normally stored as 8 bytes with 7 bits/byte, for hysterical raisins). While keys != blocks, it does indicate to me that there is nothing holy about powers of two. I could imagine, for example, a cipher depending on number-theoretic properties of 2^56 that 2^64 doesn't have. (I'm thinking in particular of the way IDEA dependens on 2^16+1 being prime, and the difficulty of converting it to 32-bit basic blocks because 2^32+1 isn't.) I'm perfectly satisfied with "you can't do that with ssh" as the response; I just think it'd be good to see it stated explicitly. /~\ 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 Mar 21 12:44:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00107 for ; Mon, 21 Mar 2005 12:44:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 404A453C5; Mon, 21 Mar 2005 17:44:35 +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 2856F515B for ; Mon, 21 Mar 2005 17:44:32 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA29031; Mon, 21 Mar 2005 12:44:31 -0500 (EST) From: der Mouse Message-Id: <200503211744.MAA29031@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, 21 Mar 2005 12:22:32 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he >> message may consist of multiple lines", but gives no indication how >> line breaks are to be encoded. > Suggestions from anyone? I'd argue for CRLF line breaks, largely for the sake of uniformity. Maybe The message may consist of multiple lines, with line breaks indicated by CRLF pairs. (Of course, implementations need to be prepared to have arbitrarily nasty binary data thrown at them in such places - this gets into the control character filtering topic.) >> Various places speak of doing control character filtering as >> discussed in [SSH-ARCH]. I've been unable to find the referenced >> discussion in architecture-22. [...] > [...]. Such text does not seem to appear in any of the IDs at this > time. Should it be restored in the general Security Considerations > section like the section on "Pseudo-Random Number Generation", or > should it be restored within a particular section [...]? I'd prefer to see it as a general security consideration, since it applies anywhere where an implementation may try to print a string received from the peer, and that's lots of places. But as long as it's easy to find from the table of contents, I'd be content. >> architecture-22 section 8 says "which may be superceded in the >> future"; the word is actually spelled "superseded". > The spellchecker in kate doesn't object to it. Nontheless, I'll > change it. Well, I wasn't sure. Dictionary.com produces nothing when asked for "superceded" and finds it when asked for "superseded", which provoked my note. Checking my own 2600-page paper dictionary now shows "supercede var of supersede"; it probably would be defensible to keep it, but if a non-anglophone starts looking puzzling words up online, I suspect the "supersede" version will make things easier. >> architecture-22 9.3.5 says that publickey makes no server security >> assumptions. [MitM concerns] > Does Ben's note cover this? Yes (with my own realization), as noted in my reply to Ben. >> conenct-25 7.1 sez >> address or domain name and port to which the socket to be listened is >> [page break] >> bound. >> I'd prefer to see "is to be bound"; there also seems to be a "to" >> missing after "listened". > Which do you want; > The 'address to bind' and 'port number to bind' specify the IP > address or domain name and port to which the socket to be listened to > is bound. Some strings used for the 'address to bind' have > special-case semantics. > -or- > The 'address to bind' and 'port number to bind' specify the IP > address or domain name and port to which the socket is to be bound. > Some strings used for the 'address to bind' have special-case > semantics. Between those two, I'd prefer the former - but see below. It's wordier, but, trying to get my head into the new-reader headspace, I expect the latter to produce more of a "...socket? this is the first I've heard of any socket!" response. (Logically, the former should too, but I think it will do so significantly less.) >> (I'm not entirely sure I like to see "socket" here, since there is >> no requirement that the TCP interface in question be sockets. I'm >> not sure this is worth fixing.) > If we can get some quick consensus we can probably squeeze it in. Hmm. How about this? The 'address to bind' and 'port number to bind' specify the IP address (or domain name) and port on which connections for forwarding are to be accepted. Some strings used for 'address to bind' have special-case semantics. (Note the added parens, which make it a little clearer that it's not "(IP address) or (domain name and port)", but rather "(IP address or domain name) and port". I also dropped a "the" in the last sentence, though I wouldn't object if you want to leave it present.) >> Various specifications in transport-24 break rather badly if the >> cipher in use has [block-size properties]. > Does Ben's note address this? Mostly. See my list message in response to Ben's. /~\ 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 Mar 21 13:14:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02382 for ; Mon, 21 Mar 2005 13:14:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 858EC53E3; Mon, 21 Mar 2005 18:14:12 +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 EE5EA515B for ; Mon, 21 Mar 2005 18:14:08 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1DDRPk-0005Pf-00 for ietf-ssh@netbsd.org; Mon, 21 Mar 2005 18:14:08 +0000 Date: Mon, 21 Mar 2005 18:14:08 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: latest drafts Message-ID: <20050321181408.GB19423@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: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list If we're considering changes to the drafts, I have a trivial typo in draft-ietf-secsh-transport-24 sec 6.6 "Public Key Algorithms": The certificate part may have be a zero length string, but a public key is required. [...] should probably be The certificate part may be a zero length string, but a public key is required. [...] (remove "have") From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 14:43:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10452 for ; Mon, 21 Mar 2005 14:43:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 14CBB5400; Mon, 21 Mar 2005 19:43:42 +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 2B508524B for ; Mon, 21 Mar 2005 19:43:40 +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 j2LJhYX8010236; Mon, 21 Mar 2005 12:43:34 -0700 (MST) Received: from thunk (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 j2LJhYOp013457; Mon, 21 Mar 2005 14:43:34 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2LJhYpR006156; Mon, 21 Mar 2005 14:43:34 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2LJhXwM006155; Mon, 21 Mar 2005 14:43:33 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: latest drafts From: Bill Sommerfeld To: der Mouse Cc: ietf-ssh@NetBSD.org In-Reply-To: <200503211714.MAA28883@Sparkle.Rodents.Montreal.QC.CA> References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> <200503211714.MAA28883@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111434213.5683.177.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 21 Mar 2005 14:43:33 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-03-21 at 12:02, der Mouse wrote: > Yes, but I would prefer to see this stated explicitly. Otherwise > someone reading it could wonder, as I did, "but what about, say, a > cipher with 7-byte blocks, how would I add that to my implementation?". > Or a cipher with a block size that's not a multiple of 8 bits. I do not believe this comment is particularly timely. The current versions of the documents are before the IESG again, up for approval in their next concall (on Thursday, march 31st). Typographical errors can be corrected by the RFC editor, but it's really the wrong time for substantive changes of this form. Moreover, block ciphers with non-power-of-two blocksizes are, to the best of my knowledge, not used anywhere of note. And we already support a very large number of ciphers in the spec (perhaps too many). - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 15:34:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15406 for ; Mon, 21 Mar 2005 15:34:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BB85851A5; Mon, 21 Mar 2005 20:34:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 0F3005175 for ; Mon, 21 Mar 2005 20:34:29 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15378; Mon, 21 Mar 2005 15:34:26 -0500 (EST) Message-Id: <200503212034.PAA15378@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-07.txt Date: Mon, 21 Mar 2005 15:34:25 -0500 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 : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-07.txt Pages : 12 Date : 2005-3-21 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-07.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-auth-kbdinteract-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-07.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-3-21154328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154328.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 15:34:46 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15470 for ; Mon, 21 Mar 2005 15:34:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A5CB351B5; Mon, 21 Mar 2005 20:34:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 767695175 for ; Mon, 21 Mar 2005 20:34:38 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15411; Mon, 21 Mar 2005 15:34:36 -0500 (EST) Message-Id: <200503212034.PAA15411@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-06.txt Date: Mon, 21 Mar 2005 15:34:35 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-06.txt Pages : 11 Date : 2005-3-21 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickeyfile-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-06.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-3-21154335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154335.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 17:09:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02091 for ; Mon, 21 Mar 2005 17:09:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D768C51A7; Mon, 21 Mar 2005 22:09:05 +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 A72F3516D for ; Mon, 21 Mar 2005 22:09:03 +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 j2LM92NV006881; Mon, 21 Mar 2005 14:09:02 -0800 (PST) Received: from thunk (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 j2LM92Qp011672; Mon, 21 Mar 2005 17:09:02 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2LM92HR007074; Mon, 21 Mar 2005 17:09:02 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2LM91QH007073; Mon, 21 Mar 2005 17:09:01 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: galb-list@vandyke.com, rodney@tillerman.to Cc: ietf-ssh@NetBSD.org In-Reply-To: <200503212034.PAA15411@ietf.org> References: <200503212034.PAA15411@ietf.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111442941.5683.257.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Mon, 21 Mar 2005 17:09:01 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2005-03-21 at 15:34, Internet-Drafts@ietf.org wrote: > Title : SSH Public Key File Format > Author(s) : J. Galbraith, R. Thayer > Filename : draft-ietf-secsh-publickeyfile-06.txt > Pages : 11 > Date : 2005-3-21 I am starting an official WG Last Call on this document, for publication as an Informational RFC. This last call period expires on April 4th, 2005. During this Last Call period, comments supporting publication are appropriate, as are comments suggesting changes to the spec. This Last Call assumes that the following nits will be corrected in a new revision submitted in the near future: 1) The draft references: [RFC2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. which was obsoleted by RFC2279, which was in turn obsoleted by RFC3629. 2) as discussed on the WG list about a year ago, this format is (alas) subtly different from the formats documented in rfc1113 and rfc1421 in two ways: a) the BEGIN/END markers start/end with four dashes and a space rather than five dashes. since the center part of the markers are also different from other PEM-type delimeters. b) no blank line between comment/header section and the start of the base64-encoded key. As there is running code using these formats I don't think it's worthwhile to spec a migration path to 1421-style delimeters, but since implementors may want to reuse existing PEM-format code here, we should explicitly mention the deltas from RFC1421 and cite 1421 as an informative reference. Proposed edits: 1) replace references to RFC2044 with references to RFC3629. 2) insert a new subsection of section 3 titled "Differences with RFC1421 PEM formats" containing the following text or equivalent: Implemetors should take care to notice that while the format is superficially similar to that specified by PEM [RFC1421] and PGP [RFC1991], it is not identical; most notably: 1) The other specifications use different BEGIN/END delimeters (five dashes, no space rather than four dashes and a space). 2) there is no blank line before the start of the base64-encoded contents. (end proposed edits) - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 18:26:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11613 for ; Mon, 21 Mar 2005 18:26:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 36E205235; Mon, 21 Mar 2005 23:26:26 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (unknown [IPv6:3ffe:200:75:fe00:202:b3ff:fe35:7167]) by mail.netbsd.org (Postfix) with ESMTP id CBEA7516D for ; Mon, 21 Mar 2005 23:26:21 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id CF5D31B80E5; Tue, 22 Mar 2005 00:25:57 +0100 (CET) Received: from mail.lysator.liu.se ([130.236.254.45]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 10705-01-24; Tue, 22 Mar 2005 00:25:48 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5AD721B801F; Tue, 22 Mar 2005 00:25:48 +0100 (CET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j2LNPlXa014888; Tue, 22 Mar 2005 00:25:47 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j2LNPhud014885; Tue, 22 Mar 2005 00:25:43 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: latest drafts References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> <200503211744.MAA29031@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 22 Mar 2005 00:25:42 +0100 In-Reply-To: <200503211744.MAA29031@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > >> userauth-27 says, of SSH_MSG_USERAUTH_BANNER messages, that "[t]he > >> message may consist of multiple lines", but gives no indication how > >> line breaks are to be encoded. > > Suggestions from anyone? > > I'd argue for CRLF line breaks, largely for the sake of uniformity. I'd agree with this. I believe all places elsewhere in the protocol where line breaks are specified, it's CRLF. (Although I haven't made any full search for such places). > I'd prefer to see it as a general security consideration, since it > applies anywhere where an implementation may try to print a string > received from the peer, and that's lots of places. Except when channel data is directed to the terminal, in particular if the channel is a session channel on which a pty request succeeded (this is the common case where the client puts the local terminal into raw mode, and wants to have it controlled by the remote end). One might consider control character filtering on channels that (i) are directed to a terminal, and (ii) for which the client haven't requested a pty. But I doubt it's a good idea. It will be confusing if "ssh host echo-some-control-chars" and "ssh host echo-some-control-chars | cat" gives different results, just because in the first case the stdout is a terminal, and in the second it isn't. /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 21 23:10:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05146 for ; Mon, 21 Mar 2005 23:10:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C4C4051B7; Tue, 22 Mar 2005 04:09: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 C5C935196 for ; Tue, 22 Mar 2005 04:09:52 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA01427; Mon, 21 Mar 2005 23:09:51 -0500 (EST) From: der Mouse Message-Id: <200503220409.XAA01427@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, 21 Mar 2005 23:06:06 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: <1111434213.5683.177.camel@thunk> References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> <200503211714.MAA28883@Sparkle.Rodents.Montreal.QC.CA> <1111434213.5683.177.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> [unusual cryptosystems incompatible with transport-24] >> Yes, but I would prefer to see this stated explicitly. [...] > [I]t's really the wrong time for substantive changes of this form. Ah well. If it's believed more important to get these out this time around than to "correct" minor "problems" (quotes because I'm not totally convinced this really is a problem that needs correction), then please, feel free to ignore this point. Given what you say about the timing, I suspect this is the case for this point. > Moreover, block ciphers with non-power-of-two blocksizes are, to the > best of my knowledge, not used anywhere of note. All the more reason to consider it not worth fixing. :) /~\ 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 Mar 22 05:20:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26550 for ; Tue, 22 Mar 2005 05:20:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C1618531E; Tue, 22 Mar 2005 10:20: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 74A4851B7 for ; Tue, 22 Mar 2005 10:20:47 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id FAA13471; Tue, 22 Mar 2005 05:20:46 -0500 (EST) From: der Mouse Message-Id: <200503221020.FAA13471@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, 22 Mar 2005 05:14:29 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: latest drafts In-Reply-To: References: <200503210212.VAA11526@Sparkle.Rodents.Montreal.QC.CA> <200503211744.MAA29031@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> I'd prefer to see [control character filtering] as a general >> security consideration, since it applies anywhere where an >> implementation may try to print a string received from the peer, and >> that's lots of places. > [Except for channel data] Well, yes; I guess I don't think of normal channel data traffic as "a string received from the peer", though of course there's no reason it can't be thought of that way. I agree that control-character filtering applied to normal data traffic would be Weird and Wrong. (At least absent explicit configuration that way, and that's a configuration option I see no need for an implementation to provide.) What channel data - or string data, for that matter - is directed to on the client side should not, I think, matter, but that's a quality of implementation issue, not something I think the WG should specify. > One might consider control character filtering on channels that (i) > are directed to a terminal, and (ii) for which the client haven't > requested a pty. But I doubt it's a good idea. Me too. "ssh my-home-box cat term-stuff/$TERM/init-it" ought to do what it looks as though it's doing, just like "ssh my-home-box" followed once the prompt appears by "cat term-stuff/$TERM/init-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 Tue Mar 22 13:48:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17407 for ; Tue, 22 Mar 2005 13:48:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B5E9053FE; Tue, 22 Mar 2005 18:48:07 +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 45519537E for ; Tue, 22 Mar 2005 18:48:05 +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 7256036; Tue, 22 Mar 2005 11:48:02 -0700 Message-ID: <4240685E.9040200@vandyke.com> Date: Tue, 22 Mar 2005 11:47:58 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: rodney@tillerman.to, ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> In-Reply-To: <1111442941.5683.257.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 > This Last Call assumes that the following nits will be corrected in a > new revision submitted in the near future: I just submitted it. > Proposed edits: > > 1) replace references to RFC2044 with references to RFC3629. Done. > 2) insert a new subsection of section 3 titled "Differences with > RFC1421 PEM formats" containing the following text or equivalent: > > Implemetors should take care to notice that while the format is > superficially similar to that specified by PEM [RFC1421] and PGP > [RFC1991], it is not identical; most notably: > 1) The other specifications use different BEGIN/END delimeters (five > dashes, no space rather than four dashes and a space). > 2) there is no blank line before the start of the base64-encoded > contents. Done. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 22 16:14:01 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07224 for ; Tue, 22 Mar 2005 16:14:00 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DA1BA51C6; Tue, 22 Mar 2005 21:13:55 +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 29BBC518F for ; Tue, 22 Mar 2005 21:13:54 +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 j2MLDnX8011782; Tue, 22 Mar 2005 14:13:53 -0700 (MST) Received: from thunk (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 j2MLDmOp025600; Tue, 22 Mar 2005 16:13:48 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2MLDlxA012585; Tue, 22 Mar 2005 16:13:47 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2MLDlLb012584; Tue, 22 Mar 2005 16:13:47 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: rodney@tillerman.to, ietf-ssh@NetBSD.org In-Reply-To: <4240685E.9040200@vandyke.com> References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4240685E.9040200@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111526026.10516.408.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Tue, 22 Mar 2005 16:13:47 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2005-03-22 at 13:47, Joseph Galbraith wrote: > > 1) replace references to RFC2044 with references to RFC3629. > > Done. > > 2) insert a new subsection of section 3 titled "Differences with > > RFC1421 PEM formats" containing the following text or equivalent: > > ... > > Done. > > Thanks, Excellent. Thank you! - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 08:11:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11427 for ; Wed, 23 Mar 2005 08:11:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 178BB52B1; Wed, 23 Mar 2005 13:11:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 280AF519F for ; Wed, 23 Mar 2005 13:11:17 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DE5dk-0003IT-00; Wed, 23 Mar 2005 13:11:16 +0000 From: Ben Harris To: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt In-Reply-To: <1111442941.5683.257.camel@thunk> References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Wed, 23 Mar 2005 13:11:16 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1111442941.5683.257.camel@thunk> you write: >On Mon, 2005-03-21 at 15:34, Internet-Drafts@ietf.org wrote: >> Title : SSH Public Key File Format >> Author(s) : J. Galbraith, R. Thayer >> Filename : draft-ietf-secsh-publickeyfile-06.txt >> Pages : 11 >> Date : 2005-3-21 > >I am starting an official WG Last Call on this document, for publication >as an Informational RFC. This last call period expires on April 4th, >2005. > >During this Last Call period, comments supporting publication are >appropriate, as are comments suggesting changes to the spec. I took a printout with me on a train yesterday, and it's now covered in blue ink. Most of my suggestions are in the form of a diff, but there are a few things that merit explanation. I think having things specified as being permitted (or encouraged) "for an interim period," without specifying the length of that period, is pointless. My patch removes such references on the assumption that the spec can be amended if the interim period ever ends. The case-sensitivity or otherwise of Header-tags is unspecified. Since RFC-822 headers are case-insensitive, I think this spec needs to be clear. Existing implementations may not correctly handle unrecognized fields. During a transition period, implementations SHOULD generate key file headers that contain only a Subject field followed by a Comment field. It's unclear whether this means that implementations SHOULD emit both fields, or at most one of each in that order. Contain a user specified comment which will be displayed when using the key. I think "will" needs to be replaced with "MAY", "SHOULD", or "MUST", but I don't know which is intended. The sentence should perhaps also be recast in the active voice to make it clear who's doing the displaying. There should perhaps be an example of wrapped lines. There's no mechanism for defining new headers. I'm not sure whether there needs to be, but it seems to be usual to at least allocate some namespace for private use. It's traditional to list RFCs in the References section in numerical order. I don't think the Trademark Notice is required, since neither of the authors is affiliated with ssh.com. Now for the dull fixes -- I've avoided rewrapping paragraphs so as to keep the diff intelligible. --- draft-ietf-secsh-publickeyfile-06.txt Mon Mar 21 16:26:06 2005 +++ draft-ietf-secsh-publickeyfile-bjh.txt Wed Mar 23 12:48:20 2005 @@ -43,7 +43,7 @@ Abstract - This document formally documents the existing public key file format + This document formally documents an existing public key file format in use for exchanging public keys between different SSH implementations. @@ -61,8 +61,8 @@ 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1 Line termination Characters . . . . . . . . . . . . . . . 5 + 3.1 Line Termination Characters . . . . . . . . . . . . . . . 5 - 3.2 Begin and end markers . . . . . . . . . . . . . . . . . . 5 + 3.2 Begin and End Markers . . . . . . . . . . . . . . . . . . 5 3.3 Key File Header . . . . . . . . . . . . . . . . . . . . . 5 3.3.1 Subject Header . . . . . . . . . . . . . . . . . . . . 6 3.3.2 Comment Header . . . . . . . . . . . . . . . . . . . . 6 @@ -172,7 +172,7 @@ In order to use public key authentication, public keys must be exchanged between client and server. This document formally - describes the existing public key file format, with few exceptions. + describes an existing public key file format. Where this document departs from current practice, it also suggests a mechanism for backwards compatibility. @@ -226,37 +226,38 @@ 3. Key File Format + In order to implement public key authentication, SSH implementations must share public key files between the client and the server in order to interoperate. A key file is a text file, containing a sequence of lines. Each line - in the file MUST NOT be longer than 72 bytes. + in the file MUST NOT be longer than 72 bytes excluding line + termination characters. -3.1 Line termination Characters +3.1 Line Termination Characters - In order to achieve the goal of being able to exchange public key - files between servers, implementations are REQUIRED to read files + Implementations are REQUIRED to read files using any of the common line termination sequence, , or . - Implementations may generate files using which ever line termination - convention is most convenient + Implementations may generate files using whichever of these line + termination conventions is most convenient. -3.2 Begin and end markers +3.2 Begin and End Markers The first line of a conforming key file MUST be a begin marker, which is the literal text: ---- BEGIN SSH2 PUBLIC KEY ---- - The last line of a conforming key file MUST be a end marker, which is + The last line of a conforming key file MUST be an end marker, which is the literal text: ---- END SSH2 PUBLIC KEY ---- 3.3 Key File Header - The key file header section consists of multiple RFC822 - style + The key file header section consists of multiple RFC822-style header fields. Each field is a line of the following format: Header-tag ':' ' ' Header-value @@ -267,10 +268,12 @@ A line is continued if the last character in the line is a '\'. If the last character of a line is a '\', then the logical contents of - the line is formed by removing the '\' and appending the contents of + the line is formed by removing the '\' and the line termination + characters, and appending the contents of the next line. - The Header-tag MUST be US-ASCII. The Header-value MUST be encoded in + The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be + encoded in UTF-8. [RFC2044] @@ -281,20 +284,20 @@ A line that is not a continuation line that has no ':' in it is - assumed to be the first line of the base 64 encoded body (Section 8) + the first line of the base64-encoded body (Section 3.4). Compliant implementations MUST ignore unrecognized header fields. Implementations SHOULD preserve unrecognized header fields when manipulating the key file. Existing implementations may not correctly handle unrecognized - fields. During a transition period, implementations SHOULD generate + fields. Implementations SHOULD generate key file headers that contain only a Subject field followed by a Comment field. 3.3.1 Subject Header - This field currently is used to store the login-name that the key was + This field is used to store the login-name that the key was generated under. For example: Subject: user @@ -307,26 +310,26 @@ It is suggested that this field default to user@hostname for the user and machine used to generate the key. For example: - Comment: user@mycompany.com + Comment: user@example.com Currently, common practice is to quote the Header-value of the - Comment, and some existing implementations fail if these quotes are + Comment by prefixing and suffixing it with '"' characters, and + some existing implementations fail if these quotation marks are omitted. - Compliant implementations MUST function correctly if the quotes are + Compliant implementations MUST function correctly if the quotation marks are omitted. - During an interim period implementations MAY include the quotes. If + Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching - quotes, implementations SHOULD remove them before using the value. + quotation marks, implementations SHOULD remove them before using the value. 3.4 Public Key File Body The body of a public key file consists of the public key blob as - described in the SSH transport draft [I-D.ietf-secsh-transport], - section 4.6, "Public Key Algorithms", encoded in base 64 as specified - in RFC-2045, section 6.8, "Base64 Content-Transfer-Encoding". - [RFC2045] + described in [I-D.ietf-secsh-transport], + section 4.6, "Public Key Algorithms", encoded in base64 as specified + in [RFC2045], section 6.8, "Base64 Content-Transfer-Encoding". @@ -337,7 +340,7 @@ As with all other lines, each line in the body MUST NOT be longer - than 72 characters. + than 72 characters excluding line termination characters. 3.5 Examples @@ -394,7 +397,7 @@ 4. IANA Considerations - There are non IANA registries or other considerations associated with + There are no IANA registries or other considerations associated with this document. @@ -477,9 +480,6 @@ [RFC2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. - - [RFC2026] Bradner, S., "The Internet Standards Process -- Revision - 3", October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 13:27:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16232 for ; Wed, 23 Mar 2005 13:27:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 09B2C53A1; Wed, 23 Mar 2005 18:27: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 4556451ED for ; Wed, 23 Mar 2005 18:26:57 +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 7258430; Wed, 23 Mar 2005 11:26:56 -0700 Message-ID: <4241B4EF.3080102@vandyke.com> Date: Wed, 23 Mar 2005 11:26:55 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris Cc: sommerfeld@sun.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> 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: > I took a printout with me on a train yesterday, and it's now covered in blue > ink. Most of my suggestions are in the form of a diff, but there are a few > things that merit explanation. Thanks. > I think having things specified as being permitted (or encouraged) "for an > interim period," without specifying the length of that period, is pointless. > My patch removes such references on the assumption that the spec can be > amended if the interim period ever ends. I have an alternate proposal. The draft has been around for a while now; how about we declare the interim period as ended. I've edited the draft accordingly. > The case-sensitivity or otherwise of Header-tags is unspecified. Since > RFC-822 headers are case-insensitive, I think this spec needs to be clear. Specified as insensitive. > Existing implementations may not correctly handle unrecognized > fields. During a transition period, implementations SHOULD generate > key file headers that contain only a Subject field followed by a > Comment field. > > It's unclear whether this means that implementations SHOULD emit both > fields, or at most one of each in that order. Removed completely as 'transition period' is now over. > Contain a user specified comment which will be displayed when using > the key. > > I think "will" needs to be replaced with "MAY", "SHOULD", or "MUST", but I > don't know which is intended. The sentence should perhaps also be recast in > the active voice to make it clear who's doing the displaying. Done. > There should perhaps be an example of wrapped lines. Done. > There's no mechanism for defining new headers. I'm not sure whether there > needs to be, but it seems to be usual to at least allocate some namespace > for private use. How about: New headers that are of the from "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. > It's traditional to list RFCs in the References section in numerical order. Done. > I don't think the Trademark Notice is required, since neither of the authors > is affiliated with ssh.com. Removed. I wasn't sure. > Now for the dull fixes -- I've avoided rewrapping paragraphs so as to keep > the diff intelligible. Thanks... since I don't work on the text, but rather an XML source, I applied manually. Hopefully I didn't mess anything up. > @@ -172,7 +172,7 @@ > > In order to use public key authentication, public keys must be > exchanged between client and server. This document formally > - describes the existing public key file format, with few exceptions. > + describes an existing public key file format. > > Where this document departs from current practice, it also suggests a > mechanism for backwards compatibility. Done. Also removed: - Where this document departs from current practice, it also suggests a - mechanism for backwards compatibility. > Existing implementations may not correctly handle unrecognized > - fields. During a transition period, implementations SHOULD generate > + fields. Implementations SHOULD generate > key file headers that contain only a Subject field followed by a > Comment field. Removed this paragraph entirely. > - During an interim period implementations MAY include the quotes. If > + Implementations MAY include the quotation marks. If > the first and last characters of the Header-value are matching > - quotes, implementations SHOULD remove them before using the value. > + quotation marks, implementations SHOULD remove them before using the value. Here I did exactly as your patch did and left in the MAY include quotes; this doesn't seem to be that large a burden to just leave permenantly. Thanks, Joseph PS. I'll wait a day for other comments and then send an updated version. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 13:47:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18652 for ; Wed, 23 Mar 2005 13:47:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E39E154EC; Wed, 23 Mar 2005 18:47:00 +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 22D68534C for ; Wed, 23 Mar 2005 18:46:59 +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 j2NIkrZO021151; Wed, 23 Mar 2005 10:46:53 -0800 (PST) Received: from thunk (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 j2NIkrQp014843; Wed, 23 Mar 2005 13:46:53 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2NIkrNv016918; Wed, 23 Mar 2005 13:46:53 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2NIkqp3016917; Wed, 23 Mar 2005 13:46:52 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: <4241B4EF.3080102@vandyke.com> References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4241B4EF.3080102@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1111603611.16353.42.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 23 Mar 2005 13:46:52 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ok, so this is "mission creep", but from looking through the other expired drafts, it occurred to me that maybe the right thing to do with the expired (and tiny) draft-ietf-secsh-fingerprint-01.txt is to fold its content into this draft. http://tools.ietf.org/wg/secsh/draft-ietf-secsh-fingerprint/draft-ietf-secsh-fingerprint-01.txt though, given the current status of MD5 we need to defend its use in a security considerations section. we should note that (1) use of MD5 in this form is documents existing practice, (2) the MD5 property which we rely on is 2nd-preimage resistance, not collision-resistance. thoughts? From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 16:14:42 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05748 for ; Wed, 23 Mar 2005 16:14:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 61F705526; Wed, 23 Mar 2005 21:13:36 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 0C1CB5181 for ; Wed, 23 Mar 2005 21:13:32 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05606; Wed, 23 Mar 2005 16:13:30 -0500 (EST) Message-Id: <200503232113.QAA05606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" 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-02.txt Date: Wed, 23 Mar 2005 16:13:30 -0500 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-02.txt Pages : 19 Date : 2005-3-23 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-02.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-02.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-02.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-3-23164438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickey-subsystem-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickey-subsystem-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164438.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 16:14:56 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05790 for ; Wed, 23 Mar 2005 16:14:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 827725529; Wed, 23 Mar 2005 21:13:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id C6FEF5181 for ; Wed, 23 Mar 2005 21:13:42 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05645; Wed, 23 Mar 2005 16:13:39 -0500 (EST) Message-Id: <200503232113.QAA05645@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-07.txt Date: Wed, 23 Mar 2005 16:13:39 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-07.txt Pages : 12 Date : 2005-3-23 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickeyfile-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-07.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-3-23164445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164445.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 16:15:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05968 for ; Wed, 23 Mar 2005 16:15:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 61EF1552C; Wed, 23 Mar 2005 21:14:08 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id ACB5C5181 for ; Wed, 23 Mar 2005 21:14:04 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05686; Wed, 23 Mar 2005 16:14:01 -0500 (EST) Message-Id: <200503232114.QAA05686@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-newmodes-03.txt Date: Wed, 23 Mar 2005 16:14:01 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Encryption Modes Author(s) : M. Bellare, et al. Filename : draft-ietf-secsh-newmodes-03.txt Pages : 12 Date : 2005-3-23 Researchers have recently discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for the SSH Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey. Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH application implements the modifications described in this document, then the symmetric cryptographic portion of that application will provably resist chosen-plaintext, chosen-ciphertext, reaction-based privacy and integrity/authenticity attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-03.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-newmodes-03.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-newmodes-03.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-3-23164452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-newmodes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-newmodes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164452.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 16:15:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06080 for ; Wed, 23 Mar 2005 16:15:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B3A74552A; Wed, 23 Mar 2005 21:14:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 0487F5524 for ; Wed, 23 Mar 2005 21:14:27 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05736; Wed, 23 Mar 2005 16:14:24 -0500 (EST) Message-Id: <200503232114.QAA05736@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-x509-00.txt Date: Wed, 23 Mar 2005 16:14:24 -0500 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 : X.509 authentication in SSH2 Author(s) : J. Galbraith, O. Saarenmaa Filename : draft-ietf-secsh-x509-00.txt Pages : 11 Date : 2005-3-23 The X.509 extension specifies how X.509 keys and signatures are used within the SSH2 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-x509-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-ietf-secsh-x509-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-ietf-secsh-x509-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. --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-3-23164458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-x509-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-x509-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-23164458.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 16:36:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12888 for ; Wed, 23 Mar 2005 16:36:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0926C5538; Wed, 23 Mar 2005 21:35:31 +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 AFF535532 for ; Wed, 23 Mar 2005 21:35:27 +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 7258937; Wed, 23 Mar 2005 14:35:26 -0700 Message-ID: <4241E11E.50303@vandyke.com> Date: Wed, 23 Mar 2005 14:35:26 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: Ben Harris , ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4241B4EF.3080102@vandyke.com> <1111603611.16353.42.camel@thunk> In-Reply-To: <1111603611.16353.42.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: > ok, so this is "mission creep", but from looking through the other > expired drafts, it occurred to me that maybe the right thing to do with > the expired (and tiny) draft-ietf-secsh-fingerprint-01.txt is to fold > its content into this draft. > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-fingerprint/draft-ietf-secsh-fingerprint-01.txt > > though, given the current status of MD5 we need to defend its use in a > security considerations section. > > we should note that (1) use of MD5 in this form is documents existing > practice, (2) the MD5 property which we rely on is 2nd-preimage > resistance, not collision-resistance. > > thoughts? Done. Should I hold off a while before assaulting the draft editor with another version or repost now? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 17:04:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27939 for ; Wed, 23 Mar 2005 17:04:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7A1B35550; Wed, 23 Mar 2005 22:04:16 +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 8DEF45373 for ; Wed, 23 Mar 2005 22:04:14 +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 j2NM46NV013450; Wed, 23 Mar 2005 14:04:06 -0800 (PST) Received: from thunk (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 j2NM46Qp013297; Wed, 23 Mar 2005 17:04:06 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2NM46Wj017525; Wed, 23 Mar 2005 17:04:06 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2NM45oN017524; Wed, 23 Mar 2005 17:04:05 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt From: Bill Sommerfeld To: Joseph Galbraith Cc: Ben Harris , ietf-ssh@NetBSD.org In-Reply-To: <4241E11E.50303@vandyke.com> References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <4241B4EF.3080102@vandyke.com> <1111603611.16353.42.camel@thunk> <4241E11E.50303@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111615444.16353.59.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 23 Mar 2005 17:04:05 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-03-23 at 16:35, Joseph Galbraith wrote: > Bill Sommerfeld wrote: > > ok, so this is "mission creep", but from looking through the other > > expired drafts, it occurred to me that maybe the right thing to do with > > the expired (and tiny) draft-ietf-secsh-fingerprint-01.txt is to fold > > its content into this draft. > > > > http://tools.ietf.org/wg/secsh/draft-ietf-secsh-fingerprint/draft-ietf-secsh-fingerprint-01.txt > > > > though, given the current status of MD5 we need to defend its use in a > > security considerations section. > > > > we should note that (1) use of MD5 in this form is documents existing > > practice, (2) the MD5 property which we rely on is 2nd-preimage > > resistance, not collision-resistance. > > > > thoughts? > > Done. Excellent. > Should I hold off a while before assaulting the draft editor with > another version or repost now? I would hold off for a day or two to see who else has comments and then send it in. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 17:24:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00218 for ; Wed, 23 Mar 2005 17:24:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 66E9E5560; Wed, 23 Mar 2005 22:24:35 +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 98784555D for ; Wed, 23 Mar 2005 22:24:33 +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 j2NMOUZO017725; Wed, 23 Mar 2005 14:24:31 -0800 (PST) Received: from thunk (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 j2NMOUOp011005; Wed, 23 Mar 2005 17:24:30 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2NMOUob017739; Wed, 23 Mar 2005 17:24:30 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2NMOTYF017738; Wed, 23 Mar 2005 17:24:29 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Start of WG Last Call on: draft-ietf-secsh-newmodes-03.txt From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Cc: Tadayoshi Kohno In-Reply-To: <200503232114.QAA05686@ietf.org> References: <200503232114.QAA05686@ietf.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111616668.16353.77.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 23 Mar 2005 17:24:29 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Title : SSH Transport Layer Encryption Modes > Author(s) : M. Bellare, et al. > Filename : draft-ietf-secsh-newmodes-03.txt > Pages : 12 > Date : 2005-3-23 I am starting an official WG Last Call on this document, for publication as an Proposed Standard. This last call period expires on April 6th, 2005. This is an important draft; please read it carefully. During this Last Call period, comments supporting publication are encouraged as are comments pointing out problems or suggesting changes to the spec. Reports of successful implementation of this draft are encouraged. As a reminder, tests of interoperability are *not* a prerequisite for publication as Proposed Standard but any obstacles to implementation or spec ambiguities should be corrected before publication.. Please send comments to the WG list as a whole. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 23 20:55:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20015 for ; Wed, 23 Mar 2005 20:55:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 62BD45586; Thu, 24 Mar 2005 01:55:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id 99FD25165 for ; Thu, 24 Mar 2005 01:55:08 +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 j2O1t8NV000728 for ; Wed, 23 Mar 2005 17:55:08 -0800 (PST) Received: from thunk (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 j2O1t7Qp029152; Wed, 23 Mar 2005 20:55:07 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2O1t70F018390; Wed, 23 Mar 2005 20:55:07 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2O1t7rj018389; Wed, 23 Mar 2005 20:55:07 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Comments on draft-ietf-secsh-x509-00 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111629306.16353.502.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 23 Mar 2005 20:55:07 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit [WG chair hat off...] I've been following the efforts of the PKI4IPsec working group as it struggles to hash out a profile for the use of X.509 with IPsec. In reading this document I'm struck by how little it says about what ought to go inside certificates. I would have hoped to see: 1) expected relationship(s), if any between the certificate Subject and/or subjectAltName fields and the identity of the server or user which owns the certificate. (This of course opens up the "Naming is Hard" discussion.) 2) text regarding KeyUsage and ExtendedKeyUsage. 3) text regarding recommendations for certificate revocation checks. 4) discussion of how to handle certificate chains. 5) more text about the use of certificates for user authentication or a claim that it's entirely out of scope for the document.. and I bet someone who actually follows PKIX closely would have a somewhat longer list of concerns... - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 03:20:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12779 for ; Thu, 24 Mar 2005 03:20:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7D1F35626; Thu, 24 Mar 2005 08:20:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av10-1-sn2.hy.skanova.net (av10-1-sn2.hy.skanova.net [81.228.8.181]) by mail.netbsd.org (Postfix) with ESMTP id 18012516C for ; Thu, 24 Mar 2005 08:20:11 +0000 (UTC) Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 3E7A037E60; Thu, 24 Mar 2005 08:48:15 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 2B32F37E60; Thu, 24 Mar 2005 08:48:15 +0100 (CET) Received: from [192.168.0.105] (h85n2fls33o850.telia.com [217.208.157.85]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 35FBD37E4D; Thu, 24 Mar 2005 08:48:14 +0100 (CET) Message-ID: <424270BD.2050400@streamsec.se> Date: Thu, 24 Mar 2005 08:48:13 +0100 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> In-Reply-To: <1111629306.16353.502.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld wrote: > I would have hoped to see: > > 1) expected relationship(s), if any between the certificate Subject > and/or subjectAltName fields and the identity of the server or user > which owns the certificate. (This of course opens up the "Naming is > Hard" discussion.) I mostly agree with these points. Without these there seems to be little point in using X.509 certificates at all. I can only see a point in using X.509 certificates with SSH, in case secure distribution of public keys between the server and the clients is not feasible. In the case of naming, what would really make sense would be a relationship between: a) On one hand the URI and version string of the server, and on the other hand the subject and/or subjectAltName of the server certificate b) On one hand the username of the client, and on the other hand the subject and/or subjectAltName of the client certificate. The presumption of the secsh wg ought to be that the URI of the server and the username of the client user already identifies these entities. The draft should not go into details about the theory of names. If any, such discussions should occur in the X.509 documents and/or Analytical Philosophy 101. > 2) text regarding KeyUsage and ExtendedKeyUsage. This is application specific, so it should go into the secsh-x509 spec. > 3) text regarding recommendations for certificate revocation checks. > > 4) discussion of how to handle certificate chains. These two points are already covered by PKIX documents. I don't think there are any secsh specific considerations here. > 5) more text about the use of certificates for user authentication or > a claim that it's entirely out of scope for the document.. Agreed. -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 07:57:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06992 for ; Thu, 24 Mar 2005 07:57:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AF0CE557D; Thu, 24 Mar 2005 12:57:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id DB4A65165 for ; Thu, 24 Mar 2005 12:57:07 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DERtZ-0004OU-00; Thu, 24 Mar 2005 12:57:05 +0000 From: Ben Harris To: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt In-Reply-To: <4240685E.9040200@vandyke.com> References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1111442941.5683.257.camel@thunk> <4240685E.9040200@vandyke.com> Organization: Linux Unlimited Message-Id: Date: Thu, 24 Mar 2005 12:57:05 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <4240685E.9040200@vandyke.com> you write: >> 2) insert a new subsection of section 3 titled "Differences with >> RFC1421 PEM formats" containing the following text or equivalent: >> >> Implemetors should take care to notice that while the format is >> superficially similar to that specified by PEM [RFC1421] and PGP >> [RFC1991], it is not identical; most notably: >> 1) The other specifications use different BEGIN/END delimeters (five >> dashes, no space rather than four dashes and a space). >> 2) there is no blank line before the start of the base64-encoded >> contents. > >Done. Wouldn't it be better to reference OpenPGP (RFC 2440), rather than PGP (RFC 1991)? Other differences that might be worth mentioning: 3) there is no CRC at the end of the base64-encoded block. 4) header continuation uses a backslash at the end of the continued line rather then whitespace at the start of the next line. Also, since the PEM and OpenPGP formats are different, "that specified" should read "those specified". A random interesting problem I observe with the header continuation format: there's no way to write a header whose value ends with a backslash. I don't think this is worth worrying about. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 10:08:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20236 for ; Thu, 24 Mar 2005 10:08:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BA11B55DA; Thu, 24 Mar 2005 15:08:18 +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 876E155D1 for ; Thu, 24 Mar 2005 15:08:16 +0000 (UTC) Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 2D0AA5B7FC; Thu, 24 Mar 2005 16:39:56 +0200 (EET) Received: from fsintra.f-secure.com[10.128.128.79]:52993 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Thu, 24 Mar 2005 14:39:54 -0000 Received: from [127.0.0.1] (info.f-secure.com [193.110.108.50]) by fsintra.f-secure.com (Postfix) with ESMTP id 3432D5BD22; Thu, 24 Mar 2005 16:39:54 +0200 (EET) Message-ID: <4242D138.40908@f-secure.com> Date: Thu, 24 Mar 2005 16:39:52 +0200 From: Oskari Saarenmaa User-Agent: Mozilla Thunderbird 1.0.2-1.3.1 (X11/20050323) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> In-Reply-To: <1111629306.16353.502.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: > 1) expected relationship(s), if any between the certificate Subject > and/or subjectAltName fields and the identity of the server or user > which owns the certificate. (This of course opens up the "Naming is > Hard" discussion.) Host certificate matching against the server name should probably be mentioned in the Implementation Considerations section. Currently there are implementations that check either the host certificate subject CN, subjectAltName DNS names, or both, so we should recommend checking both of these for interoperability purposes. Defining how to use user certificates is out of scope for this document in my opinion; mapping of certificates to system accounts is mostly just a configuration issue. There are a lot of different ways to do it, and I don't think we should place any requirements for the format of the certificates. > 2) text regarding KeyUsage and ExtendedKeyUsage. > > 3) text regarding recommendations for certificate revocation checks. > > 4) discussion of how to handle certificate chains. These are already covered by other documents. I don't really see the need for new ssh-specific extendedKeyUsage flags. Regards, Oskari From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 10:25:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23087 for ; Thu, 24 Mar 2005 10:25:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 39BF65171; Thu, 24 Mar 2005 15:25:35 +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 803FD516D for ; Thu, 24 Mar 2005 15:25:33 +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 j2OFPWRr018010; Thu, 24 Mar 2005 08:25:32 -0700 (MST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j2OFPVQp023733; Thu, 24 Mar 2005 10:25:31 -0500 (EST) Subject: Re: Comments on draft-ietf-secsh-x509-00 From: Bill Sommerfeld To: Henrick Hellstr?m Cc: ietf-ssh@NetBSD.org In-Reply-To: <42427077.2090606@streamsec.se> References: <1111629306.16353.502.camel@thunk> <42427077.2090606@streamsec.se> Content-Type: text/plain; charset=ASCII Message-Id: <1111677926.9762.59.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 24 Mar 2005 10:25:27 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-24 at 02:47, Henrick Hellstr?m wrote: > > 3) text regarding recommendations for certificate revocation checks. > > > > 4) discussion of how to handle certificate chains. > > These two points are already covered by PKIX documents. I don't think > there are any secsh specific considerations here. There's at least one: we should either provide an in-band way to carry cert chains, CRL's, OCSP, etc., or explicitly declare that such traffic must flow out-of-band. A use case which came up in pki4ipsec: a firewalled enclave with its pki infrastructure inside it, with as the only way in. I was in some sense trolling for text explicitly ruling that use case out of scope for this document.... - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 11:59:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03388 for ; Thu, 24 Mar 2005 11:59:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 02D3F51A8; Thu, 24 Mar 2005 16:59:55 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 6660C515B for ; Thu, 24 Mar 2005 16:59: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 7266483; Thu, 24 Mar 2005 09:59:52 -0700 Message-ID: <4242F20A.50507@vandyke.com> Date: Thu, 24 Mar 2005 09:59:54 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Heikki Nousiainen Cc: oskari.saarenmaa@F-Secure.com, "ietf-ssh@netbsd.org" Subject: Re: draft-ietf-secsh-x509 References: <4242C8D6.5080804@F-Secure.com> In-Reply-To: <4242C8D6.5080804@F-Secure.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 Heikki Nousiainen wrote: > Hello Joseph, Oskari, > > I was talking with Oskari today about the draft on X.509 certificates > and figured I might as well write my thoughts down on e-mail. Thanks... I've cc'd the mailing list on this so we can get more input. > I recall there was an issue about signature schemes used in X.509 specs > on the IETF SecSh list a long time ago (alas, I can't find any of the > e-mails). IIRC, It was noted that locking a method for specific hash > scheme might be problematic as not all hardware tokens can do multiple > schemes. This issue is pretty much moot as virtually any token out there > does signatures over SHA1, which is used in the X.509 spec as well. > However, it might be a problem in future, if local policy, say NIST in > FIPS, would mandate use of SHA256 instead of SHA1. Now, x509v3-sign and > PKCS#7 can handle all kinds of imaginable signatures, but there's no way > of communicating capabilities or policy variables of either the client > or the server to the other end. > > Consider the following: client has a token that can do SHA1 and SHA256, > server only allows SHA256 by local policy. Client first signs over SHA1, > which is refused by server. Client has no way of knowing what went > wrong, should it now re-try with SHA256 or skip that certificate? Yes... I know this is a problem. > In the spirit of the rest of the protocol, I'd suggest naming the > methods along the lines 'x509-sign-dss-sha1' and > 'x509-sign-rsa-sha1-pkcs1.5' to remove that ambiguity. Unfortunately, this doesn't help for userauth as the server never sends a list of publickey algorithms it is willing to accept for userauth. And in the hostkey case, we just really can't solve the problem adequately, and I've been kind of reluctant to introduce the ugliness for a inadequate solution. Consider a certificate chain that uses mixed algorithms; the leaf certificate user DSA w/ SHA1, an intermediate certificate doing RSA w/ MD5 and a root certificate doing RSA w/ SHA256. Such algorithm requirements can't be expressed in the SSH protocol-- well, not reasonably anyway. We could do something like make the algorithm name: x509v3-sign-{algo-hash-method}-{algo-hash-method}-...-{algo-hash-method} where the first {algo-hash-method} was for the leaf certificate, and the last was for the root certificate. But if I remember correctly, the algorithm list in total must be less that 255 characters... so I can easily imagine us running short of space here. For hostkeys, I think the only solution is for admins to make sure that their certificate chains are compatilble with the servers and clients in use-- I don't think we can really solve this problem (without a prohibitive amount of work.) For the user auth request, I suppose we could define a new message: byte SSH_MSG_USERAUTH_SIGN_ALGORITHM_UNSUPPORTED string hash[0..n] where hash[0..n] is a list of algorithm oids of hashes which can be used with the server. The server MUST send this message if the algorithms used in the pkcs7 signature are not acceptable, regardless of whether the signature is correct or incorrect. The server SHOULD NOT count the attempt as a authentication attempt. I'm mildly against such a proposal, but I could live with it. I'm not sure if it would need to be more complex; are there more algorithms than the hash which need to be negotiated? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 12:08:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04238 for ; Thu, 24 Mar 2005 12:08:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8E81451E1; Thu, 24 Mar 2005 17:08:14 +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 CE4DF51D1 for ; Thu, 24 Mar 2005 17:08:11 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7266501; Thu, 24 Mar 2005 10:08:10 -0700 Message-ID: <4242F3FC.7070803@vandyke.com> Date: Thu, 24 Mar 2005 10:08:12 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Cc: Henrick Hellstr?m , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> <42427077.2090606@streamsec.se> <1111677926.9762.59.camel@unknown.hamachi.org> In-Reply-To: <1111677926.9762.59.camel@unknown.hamachi.org> 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: > On Thu, 2005-03-24 at 02:47, Henrick Hellstr?m wrote: > > >>> 3) text regarding recommendations for certificate revocation checks. >>> >>> 4) discussion of how to handle certificate chains. >> >>These two points are already covered by PKIX documents. I don't think >>there are any secsh specific considerations here. > > > There's at least one: we should either provide an in-band way to carry > cert chains, CRL's, OCSP, etc., or explicitly declare that such traffic > must flow out-of-band. Well... hmmm... Now, I'll admit, I'm not an PKI expert (I'm an SSH expert which is why you got a document describing how to encode x.509 into the SSH protocol :-) So perhaps this is naive... But, can we really safely carry the data? Let's say the client is trying to authenticate using a revoked certificate. If we allow the client to send us the revocation list, doesn't the bad guy just not send anything? Or does even the empty revocation list have to be signed in some fashion? And if so, what if the root certificate is revoked? Or is that even possible? Or is securing the CRL during transit from a untrusted source stuff we have to specify as part of specifying a way to carry CRLs in the SSH protocol? I'm afraid my x.509 knowledge is sufficient to call someone elses (Microsoft's) API and let them deal with all of this stuff. > A use case which came up in pki4ipsec: a firewalled enclave with its pki > infrastructure inside it, with as the only > way in. Unfortunately, this may be a more common use case in SSH than in ipsec because of it's adhoc nature. In particular, this use case applies to me! (I suspect it is not unusual for SSH to be the only thing going through a firewall.) I can imagine extending the format to be string name ("x509v3-sign-rsa2", "x509v3-sign-dss2" or "x509v3-sign") string der-encoded certificate string der-encode crl list string certs-in-chain[0..n] I'm mildly reluctant to do so, since the sender has no way to probe whether the (potentially volumous) data is needed by the peer or not. If we have to worry about securing the CRL list and the certificate chain, I begin to get more than just mildly reluctant. Adding language to explicitly state that we refuse to carry such information in the SSH protocol and that it must be out-of-band is pretty easy (and wimpy, but I'm a first class wimp.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 12:21:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05606 for ; Thu, 24 Mar 2005 12:21:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EEC8A51F5; Thu, 24 Mar 2005 17:21:11 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 89F2B5191 for ; Thu, 24 Mar 2005 17:21:09 +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 7266538; Thu, 24 Mar 2005 10:21:07 -0700 Message-ID: <4242F704.6070107@vandyke.com> Date: Thu, 24 Mar 2005 10:21:08 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1111442941.5683.257.camel@thunk> <4240685E.9040200@vandyke.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 Ben Harris wrote: > In article <4240685E.9040200@vandyke.com> you write: > >>> 2) insert a new subsection of section 3 titled "Differences with >>>RFC1421 PEM formats" containing the following text or equivalent: >>> >>>Implemetors should take care to notice that while the format is >>>superficially similar to that specified by PEM [RFC1421] and PGP >>>[RFC1991], it is not identical; most notably: >>> 1) The other specifications use different BEGIN/END delimeters (five >>>dashes, no space rather than four dashes and a space). >>> 2) there is no blank line before the start of the base64-encoded >>>contents. >> >>Done. > > Wouldn't it be better to reference OpenPGP (RFC 2440), rather than PGP > (RFC 1991)? Okay. > Other differences that might be worth mentioning: > 3) there is no CRC at the end of the base64-encoded block. > 4) header continuation uses a backslash at the end of the continued line > rather then whitespace at the start of the next line. Done. > Also, since the PEM and OpenPGP formats are different, "that specified" > should read "those specified". Done. > A random interesting problem I observe with the header continuation format: > there's no way to write a header whose value ends with a backslash. I don't > think this is worth worrying about. I think you are right in that it isn't worth worrying about it; the trivial solution would be to specify that '\\' at the end of a header line signifies a '\' at the end of the value rather than a continuation. But I say let's not bother. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 12:31:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06826 for ; Thu, 24 Mar 2005 12:31:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 323EE51D1; Thu, 24 Mar 2005 17:31:07 +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 034B2515B for ; Thu, 24 Mar 2005 17:31:03 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7266565; Thu, 24 Mar 2005 10:31:01 -0700 Message-ID: <4242F954.8070205@vandyke.com> Date: Thu, 24 Mar 2005 10:31:00 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> In-Reply-To: <424270BD.2050400@streamsec.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Henrick Hellström wrote: > Bill Sommerfeld wrote: > >> I would have hoped to see: >> >> 1) expected relationship(s), if any between the certificate Subject >> and/or subjectAltName fields and the identity of the server or user >> which owns the certificate. (This of course opens up the "Naming is >> Hard" discussion.) > > I mostly agree with these points. Without these there seems to be little > point in using X.509 certificates at all. > > I can only see a point in using X.509 certificates with SSH, in case > secure distribution of public keys between the server and the clients is > not feasible. To be honest, this covers most SSH cases, right? Or at least, in most cases, password authentication must also be enable to enable the secure distribution of publickeys, and host keys are generally not distributed securely. > In the case of naming, what would really make sense would be a > relationship between: > > a) On one hand the URI and version string of the server, and on the > other hand the subject and/or subjectAltName of the server certificate So what you are saying is that the draft ought to include text along the lines of: When the certificate is used as a hostkey, either the subject name or the subjectaltname SHOULD match the canonical name of the server. (Are their multiple names in the subject name or subject alt name; I don't recall?) Or should match the name used by the user? Are there DNS issues in saying canonical name? > b) On one hand the username of the client, and on the other hand the > subject and/or subjectAltName of the client certificate. And what you are saying here is that the draft ought to include text along the lines of: When the certificate is used as part of publickey authentication, the username specified in the publickey packet SHOULD match either the subject name or the subjectAltName in the certificate. > The presumption of the secsh wg ought to be that the URI of the server > and the username of the client user already identifies these entities. Is this saying what I said above? >> 2) text regarding KeyUsage and ExtendedKeyUsage. > > This is application specific, so it should go into the secsh-x509 spec. It sounds like there is a missing 'not' in this sentance? If their isn't a missing 'not', can you give me some more details as to what you are thinking? >> 5) more text about the use of certificates for user authentication or >> a claim that it's entirely out of scope for the document.. > > Agreed. This I can handle. They can be used for authentication... once I start to get a handle on what other changes we are going to make to the document to address the other concerns, I'll make sure this is clear. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 12:50:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08763 for ; Thu, 24 Mar 2005 12:50:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id AFCFC5205; Thu, 24 Mar 2005 17:50:02 +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 2DE50515B for ; Thu, 24 Mar 2005 17:50:00 +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 j2OHnxRr024525; Thu, 24 Mar 2005 10:49:59 -0700 (MST) Received: from thunk (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 j2OHnwQp015666; Thu, 24 Mar 2005 12:49:58 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2OHnwxQ021100; Thu, 24 Mar 2005 12:49:58 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2OHnwrK021099; Thu, 24 Mar 2005 12:49:58 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Comments on draft-ietf-secsh-x509-00 From: Bill Sommerfeld To: Joseph Galbraith Cc: Henrick Hellstr?m , ietf-ssh@NetBSD.org In-Reply-To: <4242F3FC.7070803@vandyke.com> References: <1111629306.16353.502.camel@thunk> <42427077.2090606@streamsec.se> <1111677926.9762.59.camel@unknown.hamachi.org> <4242F3FC.7070803@vandyke.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1111686597.21058.11.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 24 Mar 2005 12:49:57 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-24 at 12:08, Joseph Galbraith wrote: > Let's say the client is trying to authenticate using a revoked certificate. > If we allow the client to send us the revocation list, doesn't the bad guy just > not send anything? if the relying party is set up to require CRL's, bits don't move. > Or does even the empty revocation list have to be signed in some > fashion? Correct. > And if so, what if the root certificate is revoked? Or > is that even possible? CRL's are signed and have validity periods; they must be periodically reissued. If you're doing CRL checking and the peer hands you a stale CRL, you reject it. > And if so, what if the root certificate is revoked? Or > is that even possible? It's not. > Adding language to explicitly state that we refuse to carry > such information in the SSH protocol and that it must be > out-of-band is pretty easy (and wimpy, but I'm a first class > wimp.) This is probably the right way to go for now. Note that in the firewall-traversal case you can reduce information leaks through a published CRL by having a distinct CA for the access points which is *not* the CA for your users or your internal servers, and by having your remote clients configured to trust the access-point-CA directly. The firewall-traversal server can presumably talk to the internal PKI infrastructure for validating the client certificates. and if you only have one access point, you don't need to be using X.509 for the access points. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 13:20:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11942 for ; Thu, 24 Mar 2005 13:20:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0DF975216; Thu, 24 Mar 2005 18:20:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mail.netbsd.org (Postfix) with ESMTP id 125DF515B for ; Thu, 24 Mar 2005 18:20:45 +0000 (UTC) Received: from draco.cus.cam.ac.uk ([131.111.8.18]:59338) by ppsw-8.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtp id 1DEWwd-00072H-Rt (Exim 4.44) for ietf-ssh@netbsd.org (return-path ); Thu, 24 Mar 2005 18:20:35 +0000 Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.50) id 1DEWwd-0005Ct-4H; Thu, 24 Mar 2005 18:20:35 +0000 Date: Thu, 24 Mar 2005 18:20:35 +0000 (GMT) From: Ben Harris To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt In-Reply-To: <4242F704.6070107@vandyke.com> Message-ID: References: <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> <1111442941.5683.257.camel@thunk> <4240685E.9040200@vandyke.com> <4242F704.6070107@vandyke.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 24 Mar 2005, Joseph Galbraith wrote: > Ben Harris wrote: >> A random interesting problem I observe with the header continuation format: >> there's no way to write a header whose value ends with a backslash. I >> don't >> think this is worth worrying about. > > I think you are right in that it isn't worth worrying about it; Especially since it isn't true. A trailing backslash can be encoded as two backslashes followed by two linefeeds. Sorry for the false alarm. Something that does occur to me, though, is that the range of characters allowed in header-tags and header-values should perhaps be limited a bit. I'd suggest requiring those in header-tags to be printable and not ' ' or ':', which is what RFC 822 requires. I'm not sure I know Unicode well enough to know what's sensible in header-values, but I feel that at least excluding U+0000 would make life easier for C implementations, and it's obviously necessary to exclude U+000A and U+000D. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 13:30:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13305 for ; Thu, 24 Mar 2005 13:30:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 71470521B; Thu, 24 Mar 2005 18:30:24 +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 E8CAE515B for ; Thu, 24 Mar 2005 18:30:22 +0000 (UTC) Received: from jurassic.eng.sun.com ([129.146.86.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j2OIUMNV006862; Thu, 24 Mar 2005 10:30:22 -0800 (PST) Received: from 192.9.61.6 (punchin-darrenm.SFBay.Sun.COM [192.9.61.6]) by jurassic.eng.sun.com (8.13.4.Beta0+Sun/8.13.4.Beta0) with ESMTP id j2OIULH9234642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Mar 2005 10:30:22 -0800 (PST) Subject: Re: Comments on draft-ietf-secsh-x509-00 From: Darren J Moffat To: Henrick =?iso-8859-15?Q?Hellstr=F6m?= Cc: Bill Sommerfeld , ietf-ssh@NetBSD.org In-Reply-To: <424270BD.2050400@streamsec.se> References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1111689067.1327.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 24 Mar 2005 10:31:07 -0800 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Given that the SSH protocol already has support for GSSAPI and there are GSSAPI mechanisms that can use X.509 certs, is there really any need for this other than to cause more complications ? This might be particularly important on the client side since a user may be able to use their key and cert via a GSSAPI mechanism already. -- Darren J Moffat From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 17:11:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11346 for ; Thu, 24 Mar 2005 17:11:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E3F475293; Thu, 24 Mar 2005 22:11:40 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by mail.netbsd.org (Postfix) with ESMTP id 5CEBA5255 for ; Thu, 24 Mar 2005 22:11:35 +0000 (UTC) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4CC833800C; Thu, 24 Mar 2005 22:39:29 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3FBDE37FD7; Thu, 24 Mar 2005 22:39:29 +0100 (CET) Received: from [192.168.0.105] (h85n2fls33o850.telia.com [217.208.157.85]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 02F6637E42; Thu, 24 Mar 2005 22:39:28 +0100 (CET) Message-ID: <42433390.80903@streamsec.se> Date: Thu, 24 Mar 2005 22:39:28 +0100 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en, sv MIME-Version: 1.0 To: Joseph Galbraith Cc: Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> <4242F954.8070205@vandyke.com> In-Reply-To: <4242F954.8070205@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith wrote: > Henrick Hellström wrote: >> I can only see a point in using X.509 certificates with SSH, in case >> secure distribution of public keys between the server and the clients is >> not feasible. > > > To be honest, this covers most SSH cases, right? > > Or at least, in most cases, password authentication must also > be enable to enable the secure distribution of publickeys, > and host keys are generally not distributed securely. I haven't conducted any empirical studies of actual world wide SSH usage (), but I would argue e.g. that it is recommended to only accept server host keys you already acquired securely out-of-band. For example, if you use SSH for connecting to your home computer from work (or vice versa), it would be recommended to not let the client software accept any public key sent by the server unless it is identical to the one you carry with you on an USB stick. Please note that I don't buy any arguments of the kind: "We already have a PKI infrastructure and management tells us to use it for everything so we really want to send X.509 certificates over SSH." If the host already maps user accounts to KNOWN certificates, the server might just as well extract the public keys from the certificates and use them as regular public keys. The only valid reason I can see for using X.509 certificates would be to take advantage of the fact that a trusted CA has already mapped the name of the certificate subject to the private key of certificate subject. IOW the host administrator would just have to enter the username (and possibly other personal info likely to end up in a certificate) of a new user into a database (what ever), and send an unprotected email to the user instructing him to get a client certificate. Note that no confidential (password) or authenticated (publickey) information is exchanged directly between the host and the user at this stage. The client would instead go to a trusted CA to get a client certificate. The first time the client connects with the certificate the server would be able to immediately authenticate the identity of the user. > When the certificate is used as a hostkey, either the subject name > or the subjectaltname SHOULD match the canonical name of the server. > (Are their multiple names in the subject name or subject alt name; > I don't recall?) > > Or should match the name used by the user? Are there DNS issues > in saying canonical name? I don't know. Typically, server certificates used by SSL/TLS servers have a subject.commonName identical to the *domain name* of the server. Note that both the subject name and the subjectAltName might contain a lot of other name fields, such as organizationName, country, stateOrProvince, etc. > And what you are saying here is that the draft ought to include text > along the lines of: > > When the certificate is used as part of publickey authentication, > the username specified in the publickey packet SHOULD match > either the subject name or the subjectAltName in the certificate. It is a lot more complex than that. Perhaps it would be a better idea to state that the user<->certificate mapping is assumed to be implementation specific and/or server specific. >>> 2) text regarding KeyUsage and ExtendedKeyUsage. >> >> >> This is application specific, so it should go into the secsh-x509 spec. > > > It sounds like there is a missing 'not' in this sentance? > > If their isn't a missing 'not', can you give me some more > details as to what you are thinking? No, there is no 'not' missing. Example: "A host server certificate SHOULD include the id_kp_serverAuth OID in the extKeyUsage extension, and a client user certificate SHOULD include the id_kp_clientAuth OID. The extKeyUsage extension SHOULD be marked as critical. Client implementations SHOULD reject host server certificates that contain the id_kp_clientAuth OID in the extKeyUsage extension, and server implementations SHOULD reject client certificates that contain the id_kp_serverAuth OID in the extKeyUsage extension." Please note that I don't suggest that the above paragraph should be added. It just serves as an example of an application specific PKI policy. -- Henrick Hellström www.streamsec.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 20:24:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29530 for ; Thu, 24 Mar 2005 20:24:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 38BB452C4; Fri, 25 Mar 2005 01:24:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 0EFFB5198 for ; Fri, 25 Mar 2005 01:24:31 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id DBA8934DFB; Fri, 25 Mar 2005 13:24:29 +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 31707-04; Fri, 25 Mar 2005 13:24:29 +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 A167034927; Fri, 25 Mar 2005 13:24:28 +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 9B70F37759; Fri, 25 Mar 2005 13:24:28 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DEdYt-0003E5-00; Fri, 25 Mar 2005 13:24:31 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, sommerfeld@sun.com Subject: Re: Comments on draft-ietf-secsh-x509-00 Cc: henrick@streamsec.se, ietf-ssh@NetBSD.org In-Reply-To: <4242F3FC.7070803@vandyke.com> Message-Id: Date: Fri, 25 Mar 2005 13:24:31 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: >But, can we really safely carry the data? Let's say the client is trying to >authenticate using a revoked certificate. If we allow the client to send us >the revocation list, doesn't the bad guy just not send anything? The assumption is that you always have to send some sort of CRL, if there's nothing revoked then you send an empty one. This weird requirement is an unfortunate side-effect of the blacklist-based checking used in X.509, if it was done properly with a liveness proof this wouldn't be an issue. >Or does even the empty revocation list have to be signed in some fashion? >And if so, what if the root certificate is revoked? Or is that even >possible? Or is securing the CRL during transit from a untrusted source stuff >we have to specify as part of specifying a way to carry CRLs in the SSH >protocol? I would just ignore all this, allow the server to send a cert or cert chain and leave the rest to the user. Otherwise you have to deal with cached CRLs, fetched CRLs, OCSP, out-of-band checks, etc etc etc. Then you have to decide what you want to do with delta CRLs (do you send the last full CRL and all deltas, the latest delta, ... )?. This is a complete mess, and given that the interest in use of X.509 certs in SSH to date has been within epsilon of absolute zero, it's just not worth bothering with. Tell 'em they can include certs/cert chains and leave it at that. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 20:29:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00152 for ; Thu, 24 Mar 2005 20:29:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1A13A52C2; Fri, 25 Mar 2005 01:29:34 +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 21F005184 for ; Fri, 25 Mar 2005 01:29:32 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 229B334117; Fri, 25 Mar 2005 13:29:31 +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 22299-22; Fri, 25 Mar 2005 13:29:31 +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 5E2E133F01; Fri, 25 Mar 2005 13:29:30 +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 5A4A337759; Fri, 25 Mar 2005 13:29:30 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DEddl-0003EP-00; Fri, 25 Mar 2005 13:29:33 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, henrick@streamsec.se Subject: Re: Comments on draft-ietf-secsh-x509-00 Cc: ietf-ssh@NetBSD.org, sommerfeld@sun.com In-Reply-To: <42433390.80903@streamsec.se> Message-Id: Date: Fri, 25 Mar 2005 13:29:33 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= writes: >Please note that I don't buy any arguments of the kind: "We already have a >PKI infrastructure and management tells us to use it for everything so we >really want to send X.509 certificates over SSH." If the host already maps >user accounts to KNOWN certificates, the server might just as well extract >the public keys from the certificates and use them as regular public keys. I was just about to make the same point. Putting in a huge amount of work to describe some elaborate infrastructure when to date everyone has got along just fine with raw public keys (so that by extension any attacker who wants to sidestep it can just extract and send the raw key) is pretty pointless. X.509 is a convenient alternative bit-bagging technique for use if you've already got a pile of PKI set up, not a reason to re-work half the SSH trust model. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 24 20:38:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01242 for ; Thu, 24 Mar 2005 20:38:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9F88552C3; Fri, 25 Mar 2005 01:38:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from srv04.zergon.net (srv04.zergon.net [67.15.0.20]) by mail.netbsd.org (Postfix) with ESMTP id F06DC5184 for ; Fri, 25 Mar 2005 01:38:21 +0000 (UTC) X-ClientAddr: 213.240.194.190 Received: from [213.240.194.190] (213-240-194-190.1699525.ddns.cablebg.net [213.240.194.190]) (authenticated bits=0) by srv04.zergon.net (8.12.10/8.12.10) with ESMTP id j2P1enFF027030; Fri, 25 Mar 2005 03:40:51 +0200 Message-ID: <42435E27.40402@roumenpetrov.info> Date: Fri, 25 Mar 2005 02:41:11 +0200 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: bg, ru, de-de, de, en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Cc: Joseph Galbraith , Bill Sommerfeld , ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> <4242F954.8070205@vandyke.com> <42433390.80903@streamsec.se> In-Reply-To: <42433390.80903@streamsec.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Henrick Hellström wrote: > Joseph Galbraith wrote: > >> Henrick Hellström wrote: >> >>> I can only see a point in using X.509 certificates with SSH, in case >>> secure distribution of public keys between the server and the >>> clients is >>> not feasible. >> >> [SNIP] >> >> To be honest, this covers most SSH cases, right? >> >> [SNIP] > > No, there is no 'not' missing. Example: > > "A host server certificate SHOULD include the id_kp_serverAuth OID in > the extKeyUsage extension, and a client user certificate SHOULD > include the id_kp_clientAuth OID. The extKeyUsage extension SHOULD be > marked as critical. Client implementations SHOULD reject host server > certificates that contain the id_kp_clientAuth OID in the extKeyUsage > extension, and server implementations SHOULD reject client > certificates that contain the id_kp_serverAuth OID in the extKeyUsage > extension." One part is "Public Key Authentication Method" and example above cover only it. Other method is "Host-Based Authentication" and in this case host key (certificate) may contain both extentions id_kp_clientAuth and id_kp_serverAuth. > Please note that I don't suggest that the above paragraph should be > added. It just serves as an example of an application specific PKI > policy. I agree with this. RFC 3280 cover enough "Certificate Extensions". -- Roumen Petrov http://roumenpetrov.info/openssh/ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Mar 25 12:22:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19603 for ; Fri, 25 Mar 2005 12:22:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CED275340; Fri, 25 Mar 2005 17:22:08 +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 85D235180 for ; Fri, 25 Mar 2005 17:22:06 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DEsVZ-0002Lp-00; Fri, 25 Mar 2005 17:22:05 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org, sommerfeld@sun.com Subject: Re: Start of WG Last Call on: draft-ietf-secsh-newmodes-03.txt In-Reply-To: <1111616668.16353.77.camel@thunk> References: <200503232114.QAA05686@ietf.org> <200503232114.QAA05686@ietf.org> <1111616668.16353.77.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Fri, 25 Mar 2005 17:22:05 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1111616668.16353.77.camel@thunk> you write: >> Title : SSH Transport Layer Encryption Modes >> Author(s) : M. Bellare, et al. >> Filename : draft-ietf-secsh-newmodes-03.txt >> Pages : 12 >> Date : 2005-3-23 > >I am starting an official WG Last Call on this document, for publication >as an Proposed Standard. This last call period expires on April 6th, >2005. > >This is an important draft; please read it carefully. > >During this Last Call period, comments supporting publication are >encouraged as are comments pointing out problems or suggesting changes >to the spec. The semantics af the specification seem fine to me, but there are a few nits: The abstract and the introduction state that the security problems with CBC modes were identified "recently". I'd suggest dropping the word "recently" in both cases since it's over two years ago now. The abstract mentions [ACM CCS 2002], which doesn't appear in the references. In section 3, "Section 7" should read "Section 9". In section 4, "Section 4.3" should read "Section 6.3", and "Section 5.2" should read "Section 7.2". "vice versa" is mis-spelt as "visa-versa" in sections 3 and 6.1. There should perhaps be an explicit note in section 4 that blowfish-ctr uses a different key size from blowfish-cbc. In the paragraph describing blowfish-ctr, "256 bit" should read "256-bit". The reference for triple-DES in section 4 should be changed from [SCHNEIER] to FIPS PUB 46-3. The sentence "IDEA is patented by Ascom AG" shoud be removed. The key size of cast128-ctr should be specified. In section 6.2, the phrase "Although there may be networks savings for padding to only 8-bytes" should read "Although there may be network savings from padding to only 8 bytes". The reference for [AES] should be to FIPS PUB 197 rather than to the Rijndael submission. References [BN] and [KRAWCZYK] are never used. >Reports of successful implementation of this draft are encouraged. I've written a client implementation of aes128-ctr, aes192-ctr, aes256-ctr, 3des-ctr, and blowfish-ctr for PuTTY, and tested the first three against OpenSSH 3.9p1. I haven't yet found a server implementation of 3des-ctr or blowfish-ctr to test against (though I haven't looked hard). -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 28 08:02:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12324 for ; Mon, 28 Mar 2005 08:02:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 766F75481; Mon, 28 Mar 2005 13:02:12 +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 09B23516F for ; Mon, 28 Mar 2005 13:02:08 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DFtsd-0006Xf-00 for ietf-ssh@netbsd.org; Mon, 28 Mar 2005 14:02:07 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt In-Reply-To: <1111442941.5683.257.camel@thunk> References: <200503212034.PAA15411@ietf.org> <200503212034.PAA15411@ietf.org> <1111442941.5683.257.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Mon, 28 Mar 2005 14:02:07 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1111442941.5683.257.camel@thunk> you write: >On Mon, 2005-03-21 at 15:34, Internet-Drafts@ietf.org wrote: >> Title : SSH Public Key File Format >> Author(s) : J. Galbraith, R. Thayer >> Filename : draft-ietf-secsh-publickeyfile-06.txt >> Pages : 11 >> Date : 2005-3-21 > >I am starting an official WG Last Call on this document, for publication >as an Informational RFC. This last call period expires on April 4th, >2005. > >During this Last Call period, comments supporting publication are >appropriate, as are comments suggesting changes to the spec. I've just noticed another bug: In section 3.1 (Line Termination Characters), there should be a sentence: "A public key file MUST use the same line termination convention throughout." Without this, the spec could be interpreted as allowing for different line-endings on different lines, which would make some files ambiguous. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 28 11:08:40 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01741 for ; Mon, 28 Mar 2005 11:08:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 120CA51A7; Mon, 28 Mar 2005 16:08:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 5C840516F for ; Mon, 28 Mar 2005 16:08:31 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01640; Mon, 28 Mar 2005 11:08:24 -0500 (EST) Message-Id: <200503281608.LAA01640@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-07.txt Date: Mon, 28 Mar 2005 11:08:23 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH File Transfer Protocol Author(s) : J. Galbraith, et al. Filename : draft-ietf-secsh-filexfer-07.txt Pages : 57 Date : 2005-3-25 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-filexfer-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-filexfer-07.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-3-28113427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-28113427.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 28 11:27:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07619 for ; Mon, 28 Mar 2005 11:27:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8EE1451A7; Mon, 28 Mar 2005 16:27:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from beacon.PSC.process.com (unknown [192.42.95.237]) by mail.netbsd.org (Postfix) with ESMTP id 85CDA516F for ; Mon, 28 Mar 2005 16:27:19 +0000 (UTC) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: comments on draft-ietf-secsh-filexfer-07.txt Date: Mon, 28 Mar 2005 11:26:10 -0500 Message-ID: <3EF96AF20489A34296050FBD5C36ECB905A32E@beacon.PSC.process.com> Thread-Topic: comments on draft-ietf-secsh-filexfer-07.txt Thread-Index: AcUzsrm1QV7YmBSySpauKBZAhhwNyA== From: "Richard Whalen" To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable 4.1 Is it ok for a client to use 'version-select' after sending '4' as a = requested version number? Should this state a minimum value of '3'? 4.5 "seperated" should be "separated" (multiple occurrences). In the = example of a 'comma-seperated-versions' string the terminating quote = after "3,6,7 is missing. The sentence that follows the example is = awkward "Versions defined by are:" How about "The defined versions = are:" 6.9 in the discussion of the SPARSE flag, "Some server may store..." = should be "Some servers may store..." 6.10 Can an FSETSTAT operation with the text hint be used to convert a = text file handle to a binary file handle if the value is set to one of = the binary value types or is the value ignored and this is always a = request to convert a binary file handle to a text file handle? 7.4 Should there be a way to specify that a created directory should be = case sensitive or case insensitive? If it is not specified, which is = it? The implication based upon 6.9 is that it should be case sensitive, = but what if that is not the default/possible for the file system? 7.7 "The SSH_FXP_LINK request creates a symbolic link..." strike = "symbolic" as it can create either a symbolic or hard link. 7.8.1 "A client that use REALPATH(".", "") and treats..." should be "A = client that uses REALPATH(".", "") and treats..." 9.2 "The total number of unused bytes availabe on the device..." should = be "The total number of unused bytes available on the device..." ---------------------- Richard Whalen Process Software From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Mar 28 13:47:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28345 for ; Mon, 28 Mar 2005 13:47:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3A11554C1; Mon, 28 Mar 2005 18:47:32 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from infoblox.com (cerberus.infoblox.com [128.242.99.209]) by mail.netbsd.org (Postfix) with ESMTP id 146D154B2 for ; Mon, 28 Mar 2005 18:47:30 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by infoblox.com (Postfix) with ESMTP id 4F23DDCC14D for ; Mon, 28 Mar 2005 10:29:54 -0800 (PST) Received: from infoblox.com ([127.0.0.1]) by localhost (cerberus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02384-09 for ; Mon, 28 Mar 2005 10:29:54 -0800 (PST) Received: from hermes.infoblox.com (hermes.infoblox.com [205.158.171.211]) by infoblox.com (Postfix) with ESMTP id C6C96DCC157 for ; Mon, 28 Mar 2005 10:29:52 -0800 (PST) Received: from CTSearch ([205.158.171.199]) by hermes.infoblox.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Mar 2005 10:30:29 -0800 From: Sandy Perlman To: ietf-ssh@NetBSD.org Date: Mon, 28 Mar 2005 10:30:23 -0800 Subject: Software DNS Position MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 28 Mar 2005 18:30:29.0949 (UTC) FILETIME=[38345ED0:01C533C4] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at infoblox.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I work in the staffing department at Infoblox. We are looking for a Senior Software DNS Internals expert to join our company. I would appreciate any referrals you might have. Infoblox www.infoblox.com designs, develops and sales DNS/DHCP, Radius and LDAP appliances. Founded in 1999, Infoblox has shipped over 2000 products to over 400 customers with over 50 fortune 500 companies as customers. The technical team combines next generation database experts with notable contributors to key internet technologies including: Cricket Liu, author of O'Reilly's "DNS and Bind"; Stu Bailey, former tech lead at National Center for Data Mining at University of Illinois, Chicago; Alan Dekok, principal contributor to FreeRadius. Location: Sunnyvale, CA (Silicon Valley) Title: Senior Software DNS Internals Engineer The key responsibilities: · Design and implement Secure DNS (DNS-SEC) · Provide extensions, enhancements, transitions from current products to nextgen products · Analyze customer and marketing requests for feasibility, costs and effort · Provide input to project schedules and report progress · Analyze defect reports, provide patches when required · Write technical specification and internal operation guides If you have any questions or would like to apply, please send me your resume or give me a call. For a complete list of positions visit: http://www.infoblox.com/company/careers.cfm Sandy Perlman Technical Staffing Manager 408-331-6945 Desk 408-483-1122 Cell 408-331-6971 Fax www.Infoblox.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 29 02:19:56 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21357 for ; Tue, 29 Mar 2005 02:19:55 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2963E51A5; Tue, 29 Mar 2005 07:19:47 +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 C9CFD516F for ; Tue, 29 Mar 2005 07:19:43 +0000 (UTC) Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id 4F1565BA0F; Tue, 29 Mar 2005 10:19:37 +0300 (EEST) Received: from fsintra.f-secure.com[10.128.128.79]:53743 (EHLO fsintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.41.150 Release) with SMTP; Tue, 29 Mar 2005 07:19:34 -0000 Received: from [10.128.131.76] (unknown [10.128.131.76]) by fsintra.f-secure.com (Postfix) with ESMTP id E560A5BD22; Tue, 29 Mar 2005 10:19:34 +0300 (EEST) Message-ID: <4249018A.30803@F-Secure.com> Date: Tue, 29 Mar 2005 10:19:38 +0300 From: Heikki Nousiainen User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: galb-list@vandyke.com Cc: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-x509 References: <4242C8D6.5080804@F-Secure.com> <4242F20A.50507@vandyke.com> In-Reply-To: <4242F20A.50507@vandyke.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > In the spirit of the rest of the protocol, I'd suggest naming the > > methods along the lines 'x509-sign-dss-sha1' and > > 'x509-sign-rsa-sha1-pkcs1.5' to remove that ambiguity. > > Unfortunately, this doesn't help for userauth as the server > never sends a list of publickey algorithms it is willing > to accept for userauth. True, of course. I overlooked that everything goes under the publickey authentication. What I missed as well, is that client can offer the certificate without signature to see whether the server accepts the certificate for authentication, and then proceed the actual requests with different signature schemes. An another option is to include multiple signatures within PKCS#7 blob. I'm not sure whether this is doing certificate authentication the right way, but it probably works. Cons I can think of: extra roundtrips, hardware token having to do extra encryption passes and/or having to enter pin or passphrase multiple times. > And in the hostkey case, we just really can't solve > the problem adequately, and I've been kind of reluctant > to introduce the ugliness for a inadequate solution. Kex already includes the list of host key algorithms, so the signature scheme [if key types were named more verbose] would be explicitly agreed upon by the client and the server. PKCS#7 fall-back could actually be counter-productive here: if client and server don't agree on a scheme, they wrap the bits into PKCS#7, cross fingers and hope for the best. Host certificates carry a problem of their own: client and server have no way of knowing whether they share or trust a common CA until they are both committed to performing server authentication using certificates. I can't say I see a clean and easy way to change that with the current algorithm negotiation. > Consider a certificate chain that uses mixed algorithms; > the leaf certificate user DSA w/ SHA1, an intermediate > certificate doing RSA w/ MD5 and a root certificate doing > RSA w/ SHA256. > Such algorithm requirements can't be expressed in the > SSH protocol-- well, not reasonably anyway. > We could do something like make the algorithm name: > x509v3-sign-{algo-hash-method}-{algo-hash-method}-...-{algo-hash-method} > > where the first {algo-hash-method} was for the leaf certificate, > and the last was for the root certificate. But if I remember > correctly, the algorithm list in total must be less that > 255 characters... so I can easily imagine us running short > of space here. I don't think that information is really required, It's a unrecoverable error anyway. Besides, a holder of the certificate may not know such information about the certificate chain. For userauth, it's easier just to offer the certificate. > For hostkeys, I think the only solution is for admins to make > sure that their certificate chains are compatilble with the > servers and clients in use-- I don't think we can really > solve this problem (without a prohibitive amount of work.) > > For the user auth request, I suppose we could define a new > message: > > byte SSH_MSG_USERAUTH_SIGN_ALGORITHM_UNSUPPORTED > string hash[0..n] > > where hash[0..n] is a list of algorithm oids of hashes which > can be used with the server. The server MUST send this > message if the algorithms used in the pkcs7 signature are > not acceptable, regardless of whether the signature is > correct or incorrect. The server SHOULD NOT count the > attempt as a authentication attempt. > > I'm mildly against such a proposal, but I could live with it. > I'm not sure if it would need to be more complex; are there more > algorithms than the hash which need to be negotiated? I think that's little bit backwards, and client can probably do fine without it. I wonder if it would be worthwhile to separate certificate authentication from publickey authentication in userauth, though. In addition to supported signature schemes, the new authentication method could be drafted to include sending certificate chains, CRLs and whatever certificate related is needed. I'll see if I can come up with a sensible proposal to share with the working group. I'd still consider naming the key types more verbose regardless of any of the issues above. If nothing else, it's a good precaution against possible compatibility issues. Regards, Heikki Nousiainen From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Mar 29 04:36:38 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07284 for ; Tue, 29 Mar 2005 04:36:38 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C6ABF520C; Tue, 29 Mar 2005 09:36:31 +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 64E9C516E for ; Tue, 29 Mar 2005 09:36:21 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA18173; Tue, 29 Mar 2005 04:36:20 -0500 (EST) From: der Mouse Message-Id: <200503290936.EAA18173@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, 29 Mar 2005 04:36:07 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: filexfer-07 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I just looked over draft-ietf-secsh-filexfer-07.txt and have some comments. Section 3, before the beginning of 3.1, says that "Implementations MUST ignore excess data after an otherwise valid packet", but it is not clear exactly what this means: it could be taken to mean that extra data may appear after a valid [length;type;request-id;data] blob, or whether it means that extra data may appear after the data within such a blob. Because of the difficulty of packetizing the octet stream in the former, I assume it's the latter, but I think the wording could do with clarification. In section 3.2, two is hardly "several"; I'd suggest just "This document defines these data types in addition...". In section 3.2, in the definition of "extension-pair", should it read s/consensus/CONSENSUS/ as is done elsewhere RFC2434 language is used? In 3.3, RESERVED_FOR_EXTENSIONS is not a packet type value and I would argue it should not appear in the list of packet type values, at least not in a way that makes it look like a value. Perhaps instead of SSH_FXP_EXTENDED 200 SSH_FXP_EXTENDED_REPLY 201 Galbraith, et al. Expires September 25, 2005 [Page 7] ^L Internet-Draft SSH File Transfer Protocol March 2005 RESERVED_FOR_EXTENSIONS 210-255 Additional packet types should only be defined if the protocol have it read SSH_FXP_EXTENDED 200 SSH_FXP_EXTENDED_REPLY 201 Galbraith, et al. Expires September 25, 2005 [Page 7] ^L Internet-Draft SSH File Transfer Protocol March 2005 In addition, values 210 through 255 are reserved for extensions as defined in Section {whatever}. Additional packet types should only be defined if the protocol Also, the last-quoted line above suffers from the misplaced-only problem; it should be "...should be defined only if the..." or, in this particular case, perhaps even "...defined only when the...". Section 4, first paragraph, ast line: "...adhere to particular versino of..." needs s/to par/to that par/. In 4.1, I'd rather see s/dis-contiguous/discontiguous/. 4.2, last sentence: s/name/&s/ 4.3, second paragraph, last sentence: \r\n is C notation; I'd rather see this read something like "...uses CRLF pairs as the...". Similar notation exists in the discussion of the "newline" extension. 4.3, third paragraph, reads "Servers for systems blah blah or systems blah blah, MUST translate...". I'd get rid of the comma, or add another comma just after the parenthetical note. But I'd prefer to replace the whole sentence with something like "Servers for systems using other conventions MUST translate to and from the canonical form.". (Note I added "and from" as well.) 4.4, second sentence, last paragraph: this needs a comma between "following extension" and "which all". 4.4, in the description of max-read-size, has another misplaced "only": s/only complete/complete only/. The second paragraph of this description is technically inconsistent; it says that a server MUST do something, and then describes cases under which it might not. I think it needs a little rewording. 5, describing filename-translation-control, perhaps should indicate which value of do-translate indicates which action. Perhaps "MUST enable or disable filename translation according as 'do-translate' is true or false"? 6 describes a "new compound data type is defined for encoding file attributes", but does not give it any name. By exclusion and back-reference, I assume this is the ATTRS that appears in (eg) 7.1.1; I'd prefer to see the ATTRS name shown here in 6 as well. 6 describes the *time_nseconds fields as "if flag SUBSECOND_TIMES", but 6.7 makes it clear they really are "if flags {ACCESS,CREATE,MODIFY}TIME and SUBSECOND_TIMES". I'd prefer this be stated clearly here, perhaps by indenting the "if flag" clauses: int64 atime if flag ACCESSTIME uint32 atime_nseconds if flag SUBSECOND_TIMES 6 inconsistently names attributes with dashes or underscores separating words (eg, allocation-size, mime-type, but atime_nseconds, extended_count). I'd prefer to see this uniform (I'd rather see dashes, but I'd rather see uniform underscores than the mixed mess that's there). 6 describes a createtime field. Based on the close match of the rest of the attributes, and the lack of a last-change-time field, this appears to be an example of the common misunderstanding of the ctime stat() field: it is not a create time, but a last-inode-change-time. I'm not sure how fixable this is, though I would like to see somewhere to put the ctime. 6.4 says that "the number of bytes tha tthe file consumes on disk" "is greater than or equal to [the EOF location]". This appears to mean that it cannot be used on filesystems supporting holes in files, and must be artifically increased, or not provided, for files containing sufficient holes to outweigh any indirect blocks or other overhead. Since I assume this is supposed to be a palce to report the st_blocks value, I suspect this is not what's intended. 6.4, second paragraph, I'd prefer s/removed/& (if it was created)/, since it's possible that preallocation and creation may be an atomic operation. 6.4, third paragraph, last sentence: "If the operation succeeds, it should be the min of the 'size' before the operation and the new 'allocation-size'.". (1) I'd prefer s/min/&imum/; (2) it's not clear what the "it" is referring back to. I conjecture it's the 'size' of the file, since that's the subject of the previous sentence, but it appears to be referring to "the operation" from the "If" clause. It's not clear what to do if the same operation tries to set the size and the allocation-size to different values. 6.5, second paragraph, third line, appears to be missing an open ". 6.5, second paragraph: "...should not place any special meaning with the attribute value" - I'd s/with/on/. 6.5, last paragraph: I'd add "for a modification operation" to the end of the sentence. 6.6, second paragraph: s/posix/POSIX/. 6.9, describing SSH_FILEXFER_ATTR_FLAGS_SYSTEM: "The file is part of operating system". There is an article missing here after "of". 6.9, describing SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE: another mispalced "only". s/can only apply/applies only/ 6.9, describing SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY: another misplaced "only". "The file can be opened for writing only in append mode." 6.9, describing SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE, first paragraph: missing comma after "created to this file". 6.10, section heading should be "text-hint", since that's what it's called above. 6.10 says that "If this flag is present during an fsetstat operation, the file handle is converted to a text-mode handle, as if it had been opened with SSH_FXF_ACCESS_TEXT_MODE"; this seems wrong if the value given is one of the _BINARY values, especially KNOWN_BINARY. 6.11, section heading should be "mime-type". 6.12, section heading should be "link-count". There is no description of the untranslated-name field. In 6.13, the edict that an implementation "SHOULD ignore" extended data fields it doesn't understand seems to conflict with the general dictum that unsupported attributes in a set operation should produce errors. What's the thinking behind this? 7.1.1.2, first paragraph, refers to section 5.7, which as far as I can tell does not exist. This appears to be intended to refer to what is now 6.8. Furthermore, as far as I can see, nowhere are the actual semantics of the various access types defined, either for open purposes or for ACL purposes (though in the latter case there is a reasonably strong implication that they should be interpreted per NFSv4). 7.1.1.2, second paragraph: s/it's/its/ and s/equivilants/equivalents/. I'd also s/can not/cannot/, but that's less important. 7.1.1.2, last paragraph: s/limitted/limited/ (twice). 7.1.1.3, describing SSH_FXF_TEXT, second paragraph: I'd remove "both the" and s/function/&s/. 7.1.1.3, describing SSH_FXF_TEXT, third paragraph: this contains two "correctly"s, one of which should go. 7.1.1.3, describing SSH_FXF_TEXT, describing "text-seek": does this really belong here? It seems odd to describe this nested inside this flag bit description. 7.1.1.3, describing SSH_FXF_ACCESS_READ_LOCK: s/gaurantee/guarantee/ (twice). Also, it's not clear whether "the exclusive reader" means with respect to other sftp clients or with respect to all other OS activity; and, an exclusive read lock is a very peculiar thing, and not at all what a "read lock" normally does. 7.1.1.3, describing SSH_FXF_ACCESS_WRITE_LOCK: s/gaurantee/guarantee/. Also, it's not clear whether "the exclusive writer" means with respect to other sftp clients or with respect to all other OS activity. 7.1.1.3, describing SSH_FXF_ACCESS_DELETE_LOCK: s/gaurantee/guarantee/. Also, it's not clear whether the guarantee applies to the file itself or to the name with which it aws opened. 7.1.1.3 says that "The 'attrs' field is ignored if an exiting file is opened" - this needs s/exiting/existing/. 7.1.1.3, "The following table is provided to assist in mapping posix semantics" - s/posix/POSIX/. 7.1.3 mentions that a close can fail, but it does not indicate what happens if so - interpreted under the usual assumption that a failed operation did not happen, it would appear that there is now a handle that is still open but which cannot be accessed (since the handle goes invalid from the client's POV upon sending the request). 7.2.1, last paragraph: I'd refer to see this worded differently. Perhaps "If the server returned 'max-read-size' in the "supported2" extension in its version packet (see section 4.4), then failure...". 7.2.2, describing "handle": s/oridinary/ordinary/ 7.2.3, describing writing beyond EOF, says that it writes "zeroes". It is not clear whether this is all-bits-0 bytes or the character 0 in some character set or what; I'd prefer to see this made clearer. 7.5 requires that SSH_FXP_FSTAT return an invalid-handle error for directory handles. I think this should be fixed. 7.6, last paragraph, last sentence: s/client/&s/. 7.7 says that SSH_FXP_LINK creates a symbolic link, but the description makes it clear that it is also for creating hardlinks as well. Maybe remove "symbolic" from the description sentence? 7.7, last paragraph, last sentence: s/server/&s/. 7.8, describing control-byte, third or fourth paragraph: s/syntaticly/syntactically/. 7.8.1, RFCEDITOR note, first paragraph: s/it's/its/ - I don't know if these paragraphs are worth fixing; I include this in case they are. 8 describes "error message" and conflates the description of "language tag" into it. I'd prefer to see "language tag" described on its own, parallel to the way "error message" and "error/status code" are. 8, describing SSH_FX_NO_CONNECTION and SSH_FX_CONNECTION_LOST: more misplaced "only"s. They should be moved to after their "locally"s. 8, describing SSH_FX_QUOTA_EXCEEDED: s/users/user's/ 8, describing SSH_FX_UNKNOWN_PRINCIPLE: this needs to be SSH_FX_UNKNOWN_PRINCIPAL, with s/princple/principal/ in the description. (Since the wire protocol does not use the names, such a change would be backward-compatible.) 8, describing SSH_FX_BYTE_RANGE_LOCK_CONFLICT and SSH_FX_BYTE_RANGE_LOCK_REFUSED, speaks of "byte range" locks. As far as I can tell, this is the only place in the entire document that such a thing is mentioned. I have no idea why two error codes were allocated to refer to conflicts with something that is undefined and outside the scope of the protocol anyway, but it is not at all clear what this is all about. 8, describing the end-of-file field in an SSH_FXP_DATA response: s/limitted/limited/. 8, describing SSH_FXP_NAME responses, says that "the remaining fields repeat 'count' times", but this is true of only the next two fields, not of the end-of-list optional field, which never repeats. 9, describing "request-specific data": another misplaced "only". It needs to move to just before the "if". 9, describing how to allocate packet types for extensions: "in additional to any other data" - s/additional/addition/. 9.1.2, describing "block-size": s/ever/&y/. Also, s/entire range/&,/. 9.1.2, last paragraph (part of the SSH_FXP_EXTENDED_REPLY "hash" description): s/computer/computed/. 9.2, last paragraph ("bytes-per-allocation-unit" description): s/block/&s/. 9.3: I'd prefer to see it explicitly stated that the returned pathname is suitable for use in operations such as realpath. 10, third paragraph: s/channels/channel's/. 11, second paragraph, first sentence: swap "only" with "constrained". 11, seventh paragraph: while the text as it stands is not really _wrong_, I'd prefer to s/insure/ensure/. 13, isn't the canonical tardemark sentence shorter now? /~\ 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 Mar 29 04:51:52 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08737 for ; Tue, 29 Mar 2005 04:51:51 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5100E527E; Tue, 29 Mar 2005 09:51:47 +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 6AA83516E for ; Tue, 29 Mar 2005 09:51:45 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id EAA18261; Tue, 29 Mar 2005 04:51:44 -0500 (EST) From: der Mouse Message-Id: <200503290951.EAA18261@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, 29 Mar 2005 04:45:38 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: filexfer-07 In-Reply-To: <200503290936.EAA18173@Sparkle.Rodents.Montreal.QC.CA> References: <200503290936.EAA18173@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit (I hate to respond to myself...) > 6.9, describing SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY: another misplaced > "only". "The file can be opened for writing only in append mode." Depending on what the attribute means, this actually might need to be "The file can be opened only for writing in append mode.". (This is an example of why the misplaced "only"s are misplaced: it's not clear what they apply to.) I also see various typos, which I somehow couldn't see when reading it over before sending :-(, but as they're not in replacement text, I won't bother fixing them individually. /~\ 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 Mar 29 08:13:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25943 for ; Tue, 29 Mar 2005 08:13:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 051CC52A5; Tue, 29 Mar 2005 13:13:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [195.20.116.97]) by mail.netbsd.org (Postfix) with ESMTP id BCFFA516C for ; Tue, 29 Mar 2005 13:13:20 +0000 (UTC) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id j2TCgWDQ025001 for ; Tue, 29 Mar 2005 15:42:32 +0300 (EEST) Received: (qmail 2750 invoked from network); 29 Mar 2005 12:42:31 -0000 Received: from unknown (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 29 Mar 2005 12:42:31 -0000 Received: (from ttsalo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id PAA07577; Tue, 29 Mar 2005 15:42:31 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16969.19766.387870.462736@torni.hel.fi.ssh.com> Date: Tue, 29 Mar 2005 15:42:30 +0300 From: Tomi Salo To: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 In-Reply-To: <4242F954.8070205@vandyke.com> References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> <4242F954.8070205@vandyke.com> X-Mailer: VM 6.88 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Organization: SSH Communications Security Corp, Finland Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Joseph Galbraith writes: > Henrick Hellstr=F6m wrote: > > a) On one hand the URI and version string of the server, and on th= e > > other hand the subject and/or subjectAltName of the server certifi= cate >=20 > So what you are saying is that the draft ought to include text along= > the lines of: >=20 > When the certificate is used as a hostkey, either the subject name > or the subjectaltname SHOULD match the canonical name of the server.= > (Are their multiple names in the subject name or subject alt name; > I don't recall?) There is only one subject name, but the number of alternative names is unlimited.=20 RFC 2818 (HTTP Over TLS) describes a procedure of comparing a=20 hostname against a X.509 cerficate received from a server.=20 (Section 3, Endpoint Identification).=20 =20 In short: "If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used." Additionally a subjectAltName of type iPAddress may be allowed to match the server's IP address.=20 --=20 Tomi T. Salo From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 14:45:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03043 for ; Wed, 30 Mar 2005 14:45:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9C6225268; Wed, 30 Mar 2005 19:45:02 +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 CAB32539F for ; Wed, 30 Mar 2005 19:44:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7277179; Wed, 30 Mar 2005 12:44:58 -0700 Message-ID: <424B01CF.60709@vandyke.com> Date: Wed, 30 Mar 2005 12:45:19 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomi Salo Cc: ietf-ssh@NetBSD.org Subject: Re: Comments on draft-ietf-secsh-x509-00 References: <1111629306.16353.502.camel@thunk> <424270BD.2050400@streamsec.se> <4242F954.8070205@vandyke.com> <16969.19766.387870.462736@torni.hel.fi.ssh.com> In-Reply-To: <16969.19766.387870.462736@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Tomi Salo wrote: > Joseph Galbraith writes: > > Henrick Hellström wrote: > > > a) On one hand the URI and version string of the server, and on the > > > other hand the subject and/or subjectAltName of the server certificate > > > > So what you are saying is that the draft ought to include text along > > the lines of: > > > > When the certificate is used as a hostkey, either the subject name > > or the subjectaltname SHOULD match the canonical name of the server. > > (Are their multiple names in the subject name or subject alt name; > > I don't recall?) > > There is only one subject name, but the number of alternative names > is unlimited. > > RFC 2818 (HTTP Over TLS) describes a procedure of comparing a > hostname against a X.509 cerficate received from a server. > (Section 3, Endpoint Identification). > > In short: "If a subjectAltName extension of type dNSName is present, > that MUST be used as the identity. Otherwise, the (most specific) > Common Name field in the Subject field of the certificate MUST be > used." Additionally a subjectAltName of type iPAddress may be > allowed to match the server's IP address. Perhaps we should include similar text a new section specifically about hostnames... or maybe we should reference RFC2818 directly? Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 14:49:36 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03275 for ; Wed, 30 Mar 2005 14:49:35 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 96B8C517A; Wed, 30 Mar 2005 19:49:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 1EAC45165 for ; Wed, 30 Mar 2005 19:49:32 +0000 (UTC) Received: from [127.0.0.1] (HELO [0.0.0.0]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7277196 for ietf-ssh@netbsd.org; Wed, 30 Mar 2005 12:49:31 -0700 Message-ID: <424B02E0.8070808@vandyke.com> Date: Wed, 30 Mar 2005 12:49:52 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ietf-ssh@netbsd.org" Subject: SHA1 weaknesses... Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I kind of hate to do this, but... In light of recent SHA1 weaknesses, which, if I understand correctly, may not really effect SSH, but are still worrisome, should we be looking at introducing a document for using SHA256? Or are the vulnerabilities too remote, and so much not an issue for our SSH usage, that we don't need to do anything in response? Thanks, Joseph, the non-cryptographer From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 15:02:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04080 for ; Wed, 30 Mar 2005 15:02:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A7D22519C; Wed, 30 Mar 2005 20:02:41 +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 AC55D5165 for ; Wed, 30 Mar 2005 20:02:39 +0000 (UTC) Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa10637; 30 Mar 2005 15:02 EST Date: Wed, 30 Mar 2005 15:02:28 -0500 From: Jeffrey Hutzelman To: Joseph Galbraith , "ietf-ssh@netbsd.org" Subject: Re: SHA1 weaknesses... Message-ID: In-Reply-To: <424B02E0.8070808@vandyke.com> References: <424B02E0.8070808@vandyke.com> Originator-Info: login-token=Mulberry:016q7ghlQWVfo2+VgHHSwQ9YEgF7Fx4llXIw7rIC4=; 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, March 30, 2005 12:49:52 PM -0700 Joseph Galbraith wrote: > I kind of hate to do this, but... > > In light of recent SHA1 weaknesses, which, if I understand > correctly, may not really effect SSH, but are still worrisome, > should we be looking at introducing a document for using > SHA256? > > Or are the vulnerabilities too remote, and so much > not an issue for our SSH usage, that we don't need > to do anything in response? I would encourage anyone pondering this question to read - The saag proceedings from IETF62, particularly Eric Rescorla's talk. - draft-hoffman-hash-attacks-00.txt - The current discussion on this topic on the saag mailing list. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 15:07:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04754 for ; Wed, 30 Mar 2005 15:07:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3B5F3522A; Wed, 30 Mar 2005 20:07:02 +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 2EC0F5165 for ; Wed, 30 Mar 2005 20:06:58 +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 j2UK6vRr026524 for ; Wed, 30 Mar 2005 13:06:57 -0700 (MST) Received: from thunk (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 j2UK6vQp017670; Wed, 30 Mar 2005 15:06:57 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UK6vXO022290; Wed, 30 Mar 2005 15:06:57 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UK6uNR022289; Wed, 30 Mar 2005 15:06:56 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Ben Harris's individual submissions: arcfour-fixes and rsa-kex From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112213215.20951.264.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 15:06:56 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I've just noticed: http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt and Ben recently mentioned: http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt Is there any interest in either of these as working group items? rsa-kex is a weaker kex (as it allows the client to completely determine the session key); arcfour-fixes is a stronger version of the existing arcfour cipher. I don't believe either of these is in conflict with existing work in the WG; the path of least resistance may be for Ben to submit these as individual submissions to the IESG. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 17:31:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03176 for ; Wed, 30 Mar 2005 17:31:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2E6F652D8; Wed, 30 Mar 2005 22:31: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 938FB5165 for ; Wed, 30 Mar 2005 22:31:01 +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 j2UMV1Rr013317 for ; Wed, 30 Mar 2005 15:31:01 -0700 (MST) Received: from thunk (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 j2UMV0Op008381; Wed, 30 Mar 2005 17:31:00 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2UMV07j022790; Wed, 30 Mar 2005 17:31:00 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2UMV0FX022789; Wed, 30 Mar 2005 17:31:00 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: draft-ietf-secsh-auth-kbdinteract-07 approved for publication.. From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112221859.20951.593.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Wed, 30 Mar 2005 17:31:00 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit FYI: I've just noticed via http://tools.ietf.org/wg/secsh/ that auth-kbdinteract has just passed the IESG and moved into "Approved-announcement to be sent" state. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 18:09:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07939 for ; Wed, 30 Mar 2005 18:09:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 967975327; Wed, 30 Mar 2005 23:09:24 +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 DC6175165 for ; Wed, 30 Mar 2005 23:09:22 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DGmJJ-0001sC-00; Thu, 31 Mar 2005 00:09:17 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Cc: sommerfeld@sun.com Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex In-Reply-To: <1112213215.20951.264.camel@thunk> References: <1112213215.20951.264.camel@thunk> Organization: Linux Unlimited Message-Id: Date: Thu, 31 Mar 2005 00:09:17 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <1112213215.20951.264.camel@thunk> you write: >I don't believe either of these is in conflict with existing work in the >WG; the path of least resistance may be for Ben to submit these as >individual submissions to the IESG. I'm happy to do that if there's no interest in turning them into WG drafts. I'd kind of like to know whether anyone thinks they're worthwhile at all, though. >rsa-kex is a weaker kex (as it allows the client to completely determine >the session key); I'm not convinced that this is a problem, since K gets hashed with server-supplied data at least once before it's used, so unless the client can break the hash function they can't usefully determine the exchange hash or session keys. If someone can explain why there's a problem here, I may be able to work out a way around it. Of course, being weaker isn't the point of rsa-kex; using much less CPU time on the client side is. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 19:00:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12141 for ; Wed, 30 Mar 2005 19:00:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6F9FF51B0; Thu, 31 Mar 2005 00:00:33 +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 2D0EC515B for ; Thu, 31 Mar 2005 00:00:31 +0000 (UTC) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DGm3z-0003Fs-JY; Wed, 30 Mar 2005 17:53:27 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , secsh mailing list , secsh chair Subject: Protocol Action: 'Generic Message Exchange Authentication For SSH' to Proposed Standard Message-Id: Date: Wed, 30 Mar 2005 17:53:27 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has approved the following document: - 'Generic Message Exchange Authentication For SSH ' as a Proposed Standard This document is the product of the Secure Shell Working Group. The IESG contact persons are Russ Housley and Sam Hartman. Technical Summary Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanisms without knowing the specifics of the actual authentication mechanisms. Working Group Summary The SecSH Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Mar 30 19:28:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14243 for ; Wed, 30 Mar 2005 19:28:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1B93151BD; Thu, 31 Mar 2005 00: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 01B7E515B for ; Thu, 31 Mar 2005 00:27:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA04837; Wed, 30 Mar 2005 19:27:57 -0500 (EST) From: der Mouse Message-Id: <200503310027.TAA04837@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, 30 Mar 2005 19:07:01 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex In-Reply-To: <1112213215.20951.264.camel@thunk> References: <1112213215.20951.264.camel@thunk> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I've just noticed: > http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt I've implemented these, and also arcfour-64k@rodents.montreal.qc.ca, which is just like stock arcfour except it drops the first 65536 bytes of the keystream. I'd be happy to do interop testing with anyone else who's done any of them. > and Ben recently mentioned: > http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt I haven't implemented this yet, but I certainly intend to. > rsa-kex is a weaker kex (as it allows the client to completely > determine the session key); Well, it's weaker in some respects, perhaps, but the parenthetical note is false; see the last paragraph of section 8 of the draft. Note that there is no point trying to defend against a malicious client producing weak secrecy, since the client has direct access to the decrypted data stream and can leak it any way it pleases - especially since the protocol is full of opportunities for covert channels, including covert channels between an endpoint and a passive eavesdropper. /~\ 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 Mar 30 22:09:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28883 for ; Wed, 30 Mar 2005 22:09:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 838E45186; Thu, 31 Mar 2005 03:09:18 +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 5413A515B for ; Thu, 31 Mar 2005 03:09:16 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id BF61834285; Thu, 31 Mar 2005 15:09:14 +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 24310-18; Thu, 31 Mar 2005 15:09:14 +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 46AD93413D; Thu, 31 Mar 2005 15:09:14 +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 450F93774E; Thu, 31 Mar 2005 15:09:14 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DGq3a-00086b-00; Thu, 31 Mar 2005 15:09:18 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: SHA1 weaknesses... In-Reply-To: <424B02E0.8070808@vandyke.com> Message-Id: Date: Thu, 31 Mar 2005 15:09:18 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: >In light of recent SHA1 weaknesses, which, if I understand correctly, >may not really effect SSH, but are still worrisome, should we be >looking at introducing a document for using SHA256? > >Or are the vulnerabilities too remote, and so much not an issue for >our SSH usage, that we don't need to do anything in response? It doesn't affect its use in either PRFs or HMAC, so SSH is unaffected (I've been working on an article for IEEE S&P for this, but it'll probably be awhile before it appears). There's no need to rush out and change anything because of this, better to wait until we know whether SHA-2 or Whirlpool is the way to go. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 01:50:17 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17897 for ; Thu, 31 Mar 2005 01:50:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0023551D0; Thu, 31 Mar 2005 06:50:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from asclepius.uwa.edu.au (asclepius3.uwa.edu.au [130.95.128.60]) by mail.netbsd.org (Postfix) with ESMTP id 4D1DA515B for ; Thu, 31 Mar 2005 06:50:02 +0000 (UTC) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 3B6CC183E83 for ; Thu, 31 Mar 2005 14:18:54 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 2B99F183C99 for ; Thu, 31 Mar 2005 14:18:54 +0800 (WST) X-UWA-Client-IP: 130.95.13.9 (UWA) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.input (Postfix) with ESMTP id 12906183C8C for ; Thu, 31 Mar 2005 14:18:54 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 376E617F23; Thu, 31 Mar 2005 14:18:51 +0800 (WST) Received: from morwong.ucc.gu.uwa.edu.au (morwong.ucc.gu.uwa.edu.au [130.95.13.19]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id C983417F1E; Thu, 31 Mar 2005 14:18:50 +0800 (WST) Received: by morwong.ucc.gu.uwa.edu.au (8.11.1/1.1.29.3/07Oct02-0318AM) id j2V6Ii80000048657; Thu, 31 Mar 2005 14:18:45 +0800 (WST) Date: Thu, 31 Mar 2005 14:18:43 +0800 From: Matt Johnston To: Peter Gutmann Cc: galb-list@vandyke.com, ietf-ssh@NetBSD.org Subject: Re: SHA1 weaknesses... Message-ID: <20050331061843.GA44424@morwong.ucc.gu.uwa.edu.au> Mail-Followup-To: Peter Gutmann , galb-list@vandyke.com, ietf-ssh@netbsd.org References: <424B02E0.8070808@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SpamTest-Info: Profile: Formal (217/050329) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Mar 31, 2005 at 03:09:18PM +1200, Peter Gutmann wrote: > Joseph Galbraith writes: > > >In light of recent SHA1 weaknesses, which, if I understand correctly, > >may not really effect SSH, but are still worrisome, should we be > >looking at introducing a document for using SHA256? > > > It doesn't affect its use in either PRFs or HMAC, so SSH is unaffected > (I've been working on an article for IEEE S&P for this, but it'll > probably be awhile before it appears). There's no need to rush out and > change anything because of this, better to wait until we know whether > SHA-2 or Whirlpool is the way to go. Wouldn't lack of collision resistance in SHA1 leave a vulnerability with using fingerprints of host public keys for verification? (mentioned in the -architecture draft). Of course this isn't a mandatory part of the spec, though it's common in various implementations. Matt From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 06:29:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09009 for ; Thu, 31 Mar 2005 06:29:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2605B5258; Thu, 31 Mar 2005 11:29:40 +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 4A1E7515B for ; Thu, 31 Mar 2005 11:29:38 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DGxrk-0005ah-00; Thu, 31 Mar 2005 12:29:36 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org, matt@ucc.asn.au Subject: Re: SHA1 weaknesses... In-Reply-To: <20050331061843.GA44424@morwong.ucc.gu.uwa.edu.au> References: <424B02E0.8070808@vandyke.com> <20050331061843.GA44424@morwong.ucc.gu.uwa.edu.au> Organization: Linux Unlimited Message-Id: Date: Thu, 31 Mar 2005 12:29:36 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <20050331061843.GA44424@morwong.ucc.gu.uwa.edu.au> you write: >On Thu, Mar 31, 2005 at 03:09:18PM +1200, Peter Gutmann wrote: >> Joseph Galbraith writes: >> >> >In light of recent SHA1 weaknesses, which, if I understand correctly, >> >may not really effect SSH, but are still worrisome, should we be >> >looking at introducing a document for using SHA256? >> > >> It doesn't affect its use in either PRFs or HMAC, so SSH is unaffected >> (I've been working on an article for IEEE S&P for this, but it'll >> probably be awhile before it appears). There's no need to rush out and >> change anything because of this, better to wait until we know whether >> SHA-2 or Whirlpool is the way to go. > >Wouldn't lack of collision resistance in SHA1 leave a >vulnerability with using fingerprints of host public keys >for verification? (mentioned in the -architecture draft). No. A collision attack might allow an attacker to make two different keys that have the same fingerprint, but it wouldn't allow them to make a single key that has the same fingerprint as some other existing key. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 14:54:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28026 for ; Thu, 31 Mar 2005 14:54:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BC08952EE; Thu, 31 Mar 2005 19:54:02 +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 A8C8752D2 for ; Thu, 31 Mar 2005 19:53:59 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1DH5jq-000858-00 for ietf-ssh@netbsd.org; Thu, 31 Mar 2005 20:53:58 +0100 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Ben Harris's individual submissions: arcfour-fixes and rsa-kex In-Reply-To: <200503310027.TAA04837@Sparkle.Rodents.Montreal.QC.CA> References: <1112213215.20951.264.camel@thunk> <1112213215.20951.264.camel@thunk> <200503310027.TAA04837@Sparkle.Rodents.Montreal.QC.CA> Organization: Linux Unlimited Message-Id: Date: Thu, 31 Mar 2005 20:53:58 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200503310027.TAA04837@Sparkle.Rodents.Montreal.QC.CA> you write: >> I've just noticed: >> http://www.ietf.org/internet-drafts/draft-harris-ssh-arcfour-fixes-00.txt > >I've implemented these, and also arcfour-64k@rodents.montreal.qc.ca, >which is just like stock arcfour except it drops the first 65536 bytes >of the keystream. I'd be happy to do interop testing with anyone else >who's done any of them. I've got an untested implementation of my ones for PuTTY (client-only of course). I haven't yet made the patches available anywhere, but I intend to. >> and Ben recently mentioned: >> http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-01.txt > >I haven't implemented this yet, but I certainly intend to. I've got client and server implementations of the -00 version in OpenSSH, and Simon's done an independent client implementation of it for PuTTY. I don't think either of us has yet updated for -01. >> rsa-kex is a weaker kex (as it allows the client to completely >> determine the session key); > >Well, it's weaker in some respects, perhaps, but the parenthetical note >is false; see the last paragraph of section 8 of the draft. This is true, but discussions of SHA-1 have convinced me that there's a slight weakness here that I should perhaps guard against. Because the client can see all the other input to the exchange hash before it generates K, if it's got a working collision attack against HASH it can create two sessions with the same session ID. This isn't the case for DH KEX, though there the server could do the same thing by varying its host key (at the expense of having to convince the client that the new key was valid). While my choice of hashes is designed to make brute-force birthday attacks about as expensive as cracking the transient RSA key, this doesn't take account of the propensity of MD4-derived hashes towards better-than-brute-force collision attacks. I'm still undecided whether it's worth trying to avoid this by any means other than using stronger hashes. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 15:26:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02348 for ; Thu, 31 Mar 2005 15:26:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A94AD51BA; Thu, 31 Mar 2005 20:26:37 +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 E87905175 for ; Thu, 31 Mar 2005 20:26:35 +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 j2VKQXX8025515; Thu, 31 Mar 2005 13:26:33 -0700 (MST) Received: from thunk (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 j2VKQWOp007664; Thu, 31 Mar 2005 15:26:32 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2VKQWQX028810; Thu, 31 Mar 2005 15:26:32 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2VKQVST028809; Thu, 31 Mar 2005 15:26:31 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: SHA1 weaknesses... From: Bill Sommerfeld To: Peter Gutmann Cc: Joseph Galbraith , ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1112300790.27244.371.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 31 Mar 2005 15:26:31 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2005-03-30 at 22:09, Peter Gutmann wrote: > There's no need to rush out and > change anything because of this, better to wait until we know whether > SHA-2 or Whirlpool is the way to go. strongly agreed. And I may be mistaken but my understanding is that we're still waiting for the researchers to show all their work; a better understanding of their attack should influence whether to go with SHA-2, whirlpool, or some yet-to-be-designed hash algorithm. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 16:51:59 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15989 for ; Thu, 31 Mar 2005 16:51:58 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 020555250; Thu, 31 Mar 2005 21:51:49 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from liandra.pc.cs.cmu.edu (unknown [128.237.233.236]) by mail.netbsd.org (Postfix) with SMTP id 96B575230 for ; Thu, 31 Mar 2005 21:51:47 +0000 (UTC) Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa03739; 31 Mar 2005 14:51 EST Date: Thu, 31 Mar 2005 14:51:21 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: Sam Hartman Cc: Subject: Re: draft-ietf-secsh-gss-keyex and null host keys In-Reply-To: <20030716085645.3ECEA151D60@konishi-polis.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 16 Jul 2003, Sam Hartman wrote: > Second, I believe we should add text to the GSSAPI draft proposing two > possible ways of handling the host key transmitted by the GSSAPI key > exchange. > > 1) We clarify that environments may update their ssh keys much more > frequently if they typically use GSSAPI auth, and that user > interfaces should take this into account when noting that GSSAPI > key exchange has proposed a host key that would update a host key > the client already knows about. In particular, strong warnings > about man in the middle attacks normally presented when a host key > has changed are probably not appropriate if the host key change is > authenticated by GSSAPI. > > Second we should say that implementations SHOULD store any host key > sent via GSSAPI for the duration of the session so it can be used for > rekeing, even if the key was not stored for long-term use. I'm adding the following text to the next version of the draft: In traditional SSH deployments, host keys are normally expected to change infrequently, and there is often no mechanism for validating host keys not already known to the client. As a result, the use of a new host key by an already-known host is usually considered an indication of a possible man-in-the-middle attack, and clients often present strong warnings and/or abort the connection in such cases. By contrast, when GSSAPI-based key exchange is used, host keys sent via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as part of the GSSAPI key exchange, even when previously unknown to the client. Further, in environements in which GSSAPI-based key exchange is used heavily, it is possible and even likely that host keys will change much more frequently and/or without advance warning. Therefore, when a new key for an already-known host is received via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong warnings or abort the connection, provided the GSSAPI-based key exchange succeeds. In order to facilitate key re-exchange after the user's GSSAPI credentials have expired, client implementations SHOULD store host keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the session, even when such keys are not stored for long-term use. -- Jeff From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 16:54:20 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16296 for ; Thu, 31 Mar 2005 16:54:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 38A5E5251; Thu, 31 Mar 2005 21:54:17 +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 DDC9A51E3 for ; Thu, 31 Mar 2005 21:54:14 +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 7279822; Thu, 31 Mar 2005 14:54:13 -0700 Message-ID: <424C719E.3030207@vandyke.com> Date: Thu, 31 Mar 2005 14:54:38 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys 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 Jeffrey Hutzelman wrote: > On Wed, 16 Jul 2003, Sam Hartman wrote: > >>Second, I believe we should add text to the GSSAPI draft proposing two >>possible ways of handling the host key transmitted by the GSSAPI key >>exchange. >> >>1) We clarify that environments may update their ssh keys much more >> frequently if they typically use GSSAPI auth, and that user >> interfaces should take this into account when noting that GSSAPI >> key exchange has proposed a host key that would update a host key >> the client already knows about. In particular, strong warnings >> about man in the middle attacks normally presented when a host key >> has changed are probably not appropriate if the host key change is >> authenticated by GSSAPI. >> >>Second we should say that implementations SHOULD store any host key >>sent via GSSAPI for the duration of the session so it can be used for >>rekeing, even if the key was not stored for long-term use. > > I'm adding the following text to the next version of the draft: > > In traditional SSH deployments, host keys are normally expected > to change infrequently, and there is often no mechanism for validating > host keys not already known to the client. As a result, the use of > a new host key by an already-known host is usually considered an > indication of a possible man-in-the-middle attack, and clients often > present strong warnings and/or abort the connection in such cases. > > By contrast, when GSSAPI-based key exchange is used, host keys > sent via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as > part of the GSSAPI key exchange, even when previously unknown to the > client. Further, in environements in which GSSAPI-based key exchange > is used heavily, it is possible and even likely that host keys will > change much more frequently and/or without advance warning. > > Therefore, when a new key for an already-known host is received > via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue > strong warnings or abort the connection, provided the GSSAPI-based > key exchange succeeds. > > In order to facilitate key re-exchange after the user's GSSAPI > credentials have expired, client implementations SHOULD store host > keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the > session, even when such keys are not stored for long-term use. Sounds good to me. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 18:43:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25379 for ; Thu, 31 Mar 2005 18:43:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DC461523B; Thu, 31 Mar 2005 23:43:10 +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 11CA45175 for ; Thu, 31 Mar 2005 23:43:09 +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 j2VNgxRr026794; Thu, 31 Mar 2005 16:42:59 -0700 (MST) Received: from thunk (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 j2VNgwOp022573; Thu, 31 Mar 2005 18:42:58 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j2VNgwO2000309; Thu, 31 Mar 2005 18:42:58 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j2VNgwKr000308; Thu, 31 Mar 2005 18:42:58 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: draft-ietf-secsh-gss-keyex and null host keys From: Bill Sommerfeld To: Jeffrey Hutzelman Cc: Sam Hartman , ietf-ssh@NetBSD.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1112312576.27244.556.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 31 Mar 2005 18:42:57 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2005-03-31 at 14:51, Jeffrey Hutzelman wrote: > I'm adding the following text to the next version of the draft: > Therefore, when a new key for an already-known host is received > via the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue > strong warnings or abort the connection, provided the GSSAPI-based > key exchange succeeds. I think we need to provide additional guidance about hostkey update acceptance.. one extreme: In general, manually-exchanged-via-trusted-path hostkeys should not be replaced by GSSAPI-authenticated ones; the former may be considered akin to trust anchors. the other: if you learned the hostkey via gssapi, you can learn the new one via gssapi, too.. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Mar 31 22:23:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11649 for ; Thu, 31 Mar 2005 22:23:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C615852FC; Fri, 1 Apr 2005 03:23:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id ECB6C5267 for ; Fri, 1 Apr 2005 03:23:20 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id 84D5B76F85; Thu, 31 Mar 2005 22:22:15 -0500 (EST) To: Bill Sommerfeld Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys References: <1112312576.27244.556.camel@thunk> From: Sam Hartman Date: Thu, 31 Mar 2005 22:22:15 -0500 In-Reply-To: <1112312576.27244.556.camel@thunk> (Bill Sommerfeld's message of "Thu, 31 Mar 2005 18:42:57 -0500") Message-ID: <873bub89lk.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> one extreme: Bill> In general, manually-exchanged-via-trusted-path hostkeys Bill> should not be replaced by GSSAPI-authenticated ones; the Bill> former may be considered akin to trust anchors. I'm not actually sure I believe this is true. In practice the fact that there is no good rekeying mechanism for manual keys suggests that you want to be relatively open in accepting mechanisms to rekey. For example I'd sort of like to see a dialogue asking if I wanted to replace a manual key with a gssapi key if there was one.