From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 9 00:27:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07960 for ; Sun, 9 Nov 2003 00:27:25 -0500 (EST) Received: (qmail 6718 invoked by uid 605); 9 Nov 2003 05:27:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6711 invoked from network); 9 Nov 2003 05:27:26 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 9 Nov 2003 05:27:26 -0000 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 hA95RPxA014637 for ; Sat, 8 Nov 2003 21:27:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA95RPIr007845 for ; Sun, 9 Nov 2003 00:27:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hA95RPS4029841 for ; Sun, 9 Nov 2003 00:27:25 -0500 (EST) Message-Id: <200311090527.hA95RPS4029841@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: WG Last Call on draft-ietf-secsh-publickeyfile-04.txt Reply-to: sommerfeld@east.sun.com Date: Sun, 09 Nov 2003 00:27:25 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'd like to start a new WG Last Call on SSH Public Key File Format draft-ietf-secsh-publickeyfile-04.txt .. for publication as an Informational RFC; the Last Call period ends on 11/23/2003. If possible, be sure to review the new Security Considerations section for completeness. Please send comments on this document to this mailing list. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 9 00:36:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08050 for ; Sun, 9 Nov 2003 00:36:18 -0500 (EST) Received: (qmail 11266 invoked by uid 605); 9 Nov 2003 05:36:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11259 invoked from network); 9 Nov 2003 05:36:26 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 9 Nov 2003 05:36:26 -0000 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 hA95aP5u002845 for ; Sat, 8 Nov 2003 22:36:25 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA95aPIr008876 for ; Sun, 9 Nov 2003 00:36:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hA95aPS4029911 for ; Sun, 9 Nov 2003 00:36:25 -0500 (EST) Message-Id: <200311090536.hA95aPS4029911@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: WG Last Call on draft-ietf-secsh-break-01.txt Reply-to: sommerfeld@east.sun.com Date: Sun, 09 Nov 2003 00:36:25 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm starting a two week Working Group Last Call on : Session Channel Break Extension draft-ietf-secsh-break-01.txt for publication as a Proposed Standard. This Last Call period expires on 11/23/2003. Please send comments on this document to this list. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 9 06:35:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26393 for ; Sun, 9 Nov 2003 06:35:13 -0500 (EST) Received: (qmail 25126 invoked by uid 605); 9 Nov 2003 11:35:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25118 invoked from network); 9 Nov 2003 11:35:17 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 9 Nov 2003 11:35:17 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DEBBAA9998; Sun, 9 Nov 2003 12:35:15 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id A441F3377A for ; Sun, 9 Nov 2003 12:35:14 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hA9BZEAj026737 for ; Sun, 9 Nov 2003 12:35:14 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hA9BZ7Eq026733; Sun, 9 Nov 2003 12:35:07 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@NetBSD.org Subject: SSH_MSG_UNIMPLEMENTED Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 09 Nov 2003 12:35:06 +0100 Message-ID: Lines: 58 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,USER_AGENT_GNUS_UA,X_AUTH_WARNING version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I found by accident that my implementation didn't implement sending of SSH_MSG_UNIMPLEMENTED properly. When fixing it, I also came to the conclusion that SSH_MSG_UNIMPLEMENTED is quite suboptimal. The spec says: byte SSH_MSG_UNIMPLEMENTED uint32 packet sequence number of rejected message Except for this usage of the sequence number, sequence numbers are purely a part of the transport protocol. (The bug in my code would cause it to always send zero for the sequence number). 1. An example of what this implies: Say I split the implementation into one process that implements the transport and userauth protocol, and a separate process that implements the connection protocol, and let the first process forward all incoming ssh messages with types >= 80 (connection, channel, and reserved types) to the second process. Then if a message of the unimplemented type 100 (say) is received, this is forwarded to the second process, which must then produce a SSH_MSG_UNIMPLEMENTED message, and to do this, it needs to know the sequence number from the transport. This seems to violate the otherwise nice modularization. One solution is to attached the sequence number to all incoming packets, and include the sequence number also when forwarding messages between processes. 2. And even worse, if I want to *send* a channel-related message of some type that might potentially be unimplemented at the other end. Then it seems tricky to match the resulting SSH_MSG_UNIMPLEMENTED to the right message, because when generating the message, I don't know what sequence number it will get, and then transmitting the message (which is the code where the sequence number is known), I don't know who's interested in SSH_MSG_UNIMPLEMENTED responses. The SSH_MSG_UNIMPLEMENTED message would be more useful if it included the message type, instead of the sequence number. byte SSH_MSG_UNIMPLEMENTED byte type of the rejected message or included both (which would solve 2, but not 1), byte SSH_MSG_UNIMPLEMENTED uint32 packet sequence number of rejected message byte type of the rejected message I don't know if it's too late to do anything about this, and I don't know if anybody is using this feature of the protocol at all. But I hope it's still meaningful to note the problem. Regards, /Niels PS. I'm not been very active on this list for a while, but a month ago I tried to catch up with the last couple of years of messages. What's the current status? I saw several last calls come and go, so what are the remaining obstacles for the core drafts? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 9 07:16:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27143 for ; Sun, 9 Nov 2003 07:16:35 -0500 (EST) Received: (qmail 15535 invoked by uid 605); 9 Nov 2003 12:16:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15527 invoked from network); 9 Nov 2003 12:16:39 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 9 Nov 2003 12:16:39 -0000 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 hA9CGWxA014524; Sun, 9 Nov 2003 04:16:36 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hA9CGVIr004408; Sun, 9 Nov 2003 07:16:32 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hA9CGVS4001010; Sun, 9 Nov 2003 07:16:31 -0500 (EST) Message-Id: <200311091216.hA9CGVS4001010@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) cc: ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_UNIMPLEMENTED In-Reply-To: Your message of "09 Nov 2003 12:35:06 +0100." Reply-to: sommerfeld@east.sun.com Date: Sun, 09 Nov 2003 07:16:31 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > PS. I'm not been very active on this list for a while, but a month ago > I tried to catch up with the last couple of years of messages. > What's the current status? I saw several last calls come and go, > so what are the remaining obstacles for the core drafts? I'll send a more complete status update later today with the specifics, but the short summary is "nothing major, just more nitpicking". - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 9 21:04:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22077 for ; Sun, 9 Nov 2003 21:03:59 -0500 (EST) Received: (qmail 27034 invoked by uid 605); 10 Nov 2003 02:03:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27027 invoked from network); 10 Nov 2003 02:03:58 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 10 Nov 2003 02:03:58 -0000 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 hAA23u5u027064; Sun, 9 Nov 2003 19:03:56 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAA23uIr021203; Sun, 9 Nov 2003 21:03:56 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAA23tS4003309; Sun, 9 Nov 2003 21:03:55 -0500 (EST) Message-Id: <200311100203.hAA23tS4003309@thunk.east.sun.com> From: Bill Sommerfeld To: Yoshi Kohno Cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-newmodes-01.txt: WG Last Call! In-Reply-To: Your message of "Fri, 10 Oct 2003 23:03:44 PDT." <3F879D40.4090403@cs.ucsd.edu> Reply-to: sommerfeld@east.sun.com Date: Sun, 09 Nov 2003 21:03:55 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The revision appears to have resolved the WG chair nits; however, it appears that some sort of formatting glitch occurred. It appears that a number of the "'s" -- cipher's, Protocol's, etc., got mangled into non-ascii characters (it renders in emacs as "a-circumflex", octal 200, octal 231, 's'). We will need to respin the document to correct this, but this is such a minor thing that I feel it's time to start a working group last call *now*. WG Members: please send comments on this document to this mailing list and the author as soon as possible. This WG last call period ends on 11/23/2003. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 01:20:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27373 for ; Mon, 10 Nov 2003 01:20:52 -0500 (EST) Received: (qmail 8105 invoked by uid 605); 10 Nov 2003 06:20:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8097 invoked from network); 10 Nov 2003 06:20:52 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 10 Nov 2003 06:20:52 -0000 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 hAA6Kp5u022058; Sun, 9 Nov 2003 23:20:51 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAA6KoIr007858; Mon, 10 Nov 2003 01:20:50 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAA6KoS4004172; Mon, 10 Nov 2003 01:20:50 -0500 (EST) Message-Id: <200311100620.hAA6KoS4004172@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org cc: Russ Housley , darren.moffat@sun.com Subject: IESG issue with transport draft: version string termination. Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Nov 2003 01:20:50 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list An AD had one comment on the document which caused him to issue a "discuss" vote: > My major comment is on draft-ietf-secsh-transport-16. See comment number 4 > on this document. It says: > > Page 6, first paragraph. The SHOULD NOT conflicts with the MUST > at the bottom of page 4. Suggestion: change the MUST at the bottom > of page 4 to SHOULD. The revised -17 rearranges page breaks somewhat, so I checked a copy of -16. This refers to the text regarding backwards compatibility, and whether a CR/LF is needed or just an LF. The context of the "bottom of page 4" MUST: 3.2 Protocol Version Exchange When the connection has been established, both sides MUST send an identification string of the form "SSH-protoversion- softwareversion comments", followed by carriage return and newline characters (ASCII 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. The context of the "first paragraph of page 6" SHOULD NOT: Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. Proposed resolution: I believe the intent of the document here is pretty clear: you use CR LF to terminate the version string, unless you're doing backwards compatibility, in which case you just send LF. So, we change the first quoted section to start: When the connection has been established, both sides MUST send an identification string of the form "SSH-protoversion- softwareversion comments", followed by a line-terminator. The line terminator is normally two characters: a carriage return followed by a linefeed character (ASCII 13 and 10, respectively). Both sides MUST be able to process ... and change the second quoted section to: Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode the server SHOULD use a line-terminator consisting of a single linefeed (ASCII 10). after the version identification string. I'd like a sanity check on this from implementors. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 01:47:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27756 for ; Mon, 10 Nov 2003 01:47:40 -0500 (EST) Received: (qmail 20108 invoked by uid 605); 10 Nov 2003 06:47:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20101 invoked from network); 10 Nov 2003 06:47:48 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 10 Nov 2003 06:47:48 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAA6llPh027165 for ; Sun, 9 Nov 2003 23:47:47 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAA6llbx025070 for ; Mon, 10 Nov 2003 01:47:47 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAA6llS4004330 for ; Mon, 10 Nov 2003 01:47:47 -0500 (EST) Message-Id: <200311100647.hAA6llS4004330@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: additional IESG issue with transport draft: groups Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Nov 2003 01:47:47 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Russ raised another objection: > We need flexibility in the groups that are used. The way that section > 7 is written, it leads me to believe that only the group included in > section 7.1 can be used. I think we need to allow a future RFC to specify > alternatives. In a private message, Russ suggested this remedy: > -- MUST support parameters in 7.1 > -- SHOULD support parameters defined in other Standards-Track RFCs > -- MAY support any other parameters. However, "SHOULD support parameters defined in other Standards-Track RFC's is a little open-ended for me.. Instead, I'd suggest adding the following text, right before section 7.1 "This document defines one group, diffie-hellman-group1-sha1. Other groups may be defined by other specifications." .. and toss in an informative (i.e., non-blocking) reference to dh-group-exchange as one such example. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 02:12:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07894 for ; Mon, 10 Nov 2003 02:12:03 -0500 (EST) Received: (qmail 5263 invoked by uid 605); 10 Nov 2003 07:12:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5255 invoked from network); 10 Nov 2003 07:12:11 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 10 Nov 2003 07:12:11 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAA7CAPh003566; Mon, 10 Nov 2003 00:12:10 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAA7CAbx027269; Mon, 10 Nov 2003 02:12:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAA7CAS4004431; Mon, 10 Nov 2003 02:12:10 -0500 (EST) Message-Id: <200311100712.hAA7CAS4004431@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org CC: Russ Housley Subject: additional core draft nits in need of WG attention. Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Nov 2003 02:12:10 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list transport draft: > >5. Section 4. SSH allows the client and server to employ different > >algorithms for the data that they encrypt. This practice should be > >discouraged somewhere in the document. It is likely to cause > >interoperability problems, and it offers no security advantage. [this is section 5 in version -17] suggested resolution: immediately after this text: The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy. insert: Note that there is no security advantage to using different algorithms in each direction; implementations SHOULD use the same algorithm in both directions when allowed by policy. > >6. Section 4.3, second paragraph. The document says: "...effective key > >length of 128 bits or more". Yet, Triple-DES is the REQUIRED algorithm, > >and it does not meet this goal. Suggestion: "...effective key length of > >96 bits or more". so, this is a "how do we count the bits" issue. three-key triple-des is under some circumstances vulnerable to a particular attack which takes 2^112 time and 2^112 storage. It is not clear to me whether this particular attack is possible against 3des as used by SSH. Do we: - Lower the recommended limit? (to what? 96 bits? 112 bits?) - Explicitly grandfather triple-des? - Make AES REQUIRED? Others: > >10. Section 5, last paragraph. What is "implicit server > >authentication?" The whole paragraph is unclear. Can someone provide some fill-in text? > >13. Section 6.1. There is only one Oakley group defined, and it has an > >equivalent strength of 80-bit symmetric encryption. There should be > >additional Oakley groups that offer strength commensurate with the other > >recommendations in the document. The document should explicitly reference > >RFC 3526, and make use of group 14 (2048 bits). Any opinions here? "Use dh-group-exchange if you're paranoid". draft-ietf-secsh-userauth-17: > >3. Section 2, last paragraph. Setting the SHOULD for the timeout to 10 > >minutes seems very long. Doesn't it open up some denial-of-service > >attacks. The SHOULD for the timeout ought to be for interoperability. I'm reluctant to change that. First, it's a SHOULD, not a MUST.. also, making it too short may cause issues for the handicapped (consider the combination of slow typing rate and high error rate..) > >4. Section 5, last paragraph on page 9. Saying that UTF-8 is the > >encoding for passwords means that implementations need to check for valid > >UTF-8 encoding. This could lead to unexpected failures. It would be much > >better to say that passwords are arbitrary binary strings with no > >specified encoding. Exact match of the binary strings ought to > >be sufficient. Thoughts? My understanding is that requesting exact match of internationalized input is problematic under some circumstances.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 06:05:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15557 for ; Mon, 10 Nov 2003 06:05:11 -0500 (EST) Received: (qmail 5020 invoked by uid 605); 10 Nov 2003 11:05:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5013 invoked from network); 10 Nov 2003 11:05:16 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 11:05:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E36D7C160; Mon, 10 Nov 2003 12:03:02 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id D7DF3CD62; Mon, 10 Nov 2003 12:02:51 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAB2pCM001266; Mon, 10 Nov 2003 12:02:51 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAB2meU001263; Mon, 10 Nov 2003 12:02:48 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 12:02:48 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I have a few comments, which I'm sending in separate mails. Bill Sommerfeld writes: > transport draft: > > > >5. Section 4. SSH allows the client and server to employ different > > >algorithms for the data that they encrypt. This practice should be > > >discouraged somewhere in the document. It is likely to cause > > >interoperability problems, and it offers no security advantage. I don't buy this at all. As for interoperability problems, it's true that it's a rarely used (and likely not well tested) feature. But that's about all, implementations must keep separate encryption contexts and independent NEWKEY key switching anyway, so that they at the same time must use no encryption on one direction and the new negotiated cipher on the other. And no security advantage? The general assertion that there's no security advantage is false. As always, it's a tradeoff that depends on lots of circumstances. For example, assume that 1. The end nodes have constrained cpu capacity. 2. The intersection of supported ciphers at both ends is { arcfour, des3 } 3. In *one* of the directions, you want to send data at a higher rate than can be encrypted with des3 by the particular nodes. 4. You believe des3 to have better security properties than arcfour. Then the feasible cipher choices are arcfour arcfour (arcfour both ways) arcfour des3 (arcfour for the bulk data only) and the second has a security advantage. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 07:49:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18018 for ; Mon, 10 Nov 2003 07:49:12 -0500 (EST) Received: (qmail 4582 invoked by uid 605); 10 Nov 2003 12:49:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4575 invoked from network); 10 Nov 2003 12:49:16 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by mail.netbsd.org with SMTP; 10 Nov 2003 12:49:16 -0000 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hAACn44q026222 for ; Mon, 10 Nov 2003 13:49:05 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA16106 for ietf-ssh@NetBSD.org; Mon, 10 Nov 2003 12:49:14 GMT Date: Mon, 10 Nov 2003 12:49:13 +0000 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031110124913.D10935@edinburgh.cisco.com> References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com>; from sommerfeld@east.sun.com on Mon, Nov 10, 2003 at 02:12:10AM -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Nov 10, 2003 at 02:12:10AM -0500, Bill Sommerfeld wrote: > > > >6. Section 4.3, second paragraph. The document says: "...effective key > > >length of 128 bits or more". Yet, Triple-DES is the REQUIRED algorithm, > > >and it does not meet this goal. Suggestion: "...effective key length of > > >96 bits or more". > > so, this is a "how do we count the bits" issue. three-key triple-des > is under some circumstances vulnerable to a particular attack which > takes 2^112 time and 2^112 storage. It is not clear to me whether > this particular attack is possible against 3des as used by SSH. > > Do we: > - Lower the recommended limit? (to what? 96 bits? 112 bits?) > - Explicitly grandfather triple-des? > - Make AES REQUIRED? Well my view would be to make AES required, and 3des recommended or optional. However I guess there may be some implementors who'd disagree. Is there any current implementation that _doesn't_ now do AES? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 08:07:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18381 for ; Mon, 10 Nov 2003 08:07:54 -0500 (EST) Received: (qmail 12528 invoked by uid 605); 10 Nov 2003 13:08:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12478 invoked from network); 10 Nov 2003 13:08:03 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 10 Nov 2003 13:08:03 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id hAAD4DAU003762; Mon, 10 Nov 2003 15:04:14 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 335FF2D003; Mon, 10 Nov 2003 14:04:07 +0100 (CET) Date: Mon, 10 Nov 2003 14:04:07 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031110130406.GA18092@folly> References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Nov 10, 2003 at 02:12:10AM -0500, Bill Sommerfeld wrote: > Do we: > - Lower the recommended limit? (to what? 96 bits? 112 bits?) please not. > - Explicitly grandfather triple-des? yes. > - Make AES REQUIRED? yes, i'd prefer this. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 11:30:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28378 for ; Mon, 10 Nov 2003 11:30:29 -0500 (EST) Received: (qmail 3492 invoked by uid 605); 10 Nov 2003 16:30:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3485 invoked from network); 10 Nov 2003 16:30:34 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 16:30:34 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DA271C0E7; Mon, 10 Nov 2003 17:25:04 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 38D44C150; Mon, 10 Nov 2003 17:25:03 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAGP2CM005995; Mon, 10 Nov 2003 17:25:02 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAGOwDC005992; Mon, 10 Nov 2003 17:24:58 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 17:24:58 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > > >6. Section 4.3, second paragraph. The document says: "...effective key > > >length of 128 bits or more". Yet, Triple-DES is the REQUIRED algorithm, > > >and it does not meet this goal. Suggestion: "...effective key length of > > >96 bits or more". > > so, this is a "how do we count the bits" issue. three-key triple-des > is under some circumstances vulnerable to a particular attack which > takes 2^112 time and 2^112 storage. It is not clear to me whether > this particular attack is possible against 3des as used by SSH. Is it out of the question to say "SHOULD have effective key length of 128 or more", and just note somewhere (DES description, or security considerations) that there's a known 2^112 attack on des3? If someone discovers a 2^112 attack (with huge storage requirements) on some other supposedly 128-bit cipher, what would we do? Probably note it in the security considerations, and try to add some better cipher to the list. > Do we: > - Lower the recommended limit? (to what? 96 bits? 112 bits?) > - Explicitly grandfather triple-des? > - Make AES REQUIRED? Making aes required seems fine to me, although I'm not sure how that solves the problem. I don't think we can deprecate des3 at this time, it's too early to say that aes is more secure than des3. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 11:33:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28629 for ; Mon, 10 Nov 2003 11:33:37 -0500 (EST) Received: (qmail 5407 invoked by uid 605); 10 Nov 2003 16:33:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5400 invoked from network); 10 Nov 2003 16:33:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 16:33:45 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 6A5262E8F6; Mon, 10 Nov 2003 17:28:50 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 0A35B2E66D; Mon, 10 Nov 2003 17:28:49 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAGSmCM006058; Mon, 10 Nov 2003 17:28:48 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAGSjNl006055; Mon, 10 Nov 2003 17:28:45 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 17:28:45 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > > >10. Section 5, last paragraph. What is "implicit server > > >authentication?" The whole paragraph is unclear. > > Can someone provide some fill-in text? I think it refers to key exchange methods like the ones used in tls and ssh1, where one party chooses the session key and encrypts it using the other party's public RSA key. Then you must consider the remote end unauthenticated until you have verified that she knows the session key. Do others share this interpretation? (I'd have to think some more about the implications to be alble to write any precise text). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 11:34:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28678 for ; Mon, 10 Nov 2003 11:34:05 -0500 (EST) Received: (qmail 6113 invoked by uid 605); 10 Nov 2003 16:34:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6106 invoked from network); 10 Nov 2003 16:34:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 16:34:14 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id BC4542F564; Mon, 10 Nov 2003 17:31:28 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5B5434F9C; Mon, 10 Nov 2003 17:31:27 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAGVRCM006074; Mon, 10 Nov 2003 17:31:27 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAGVORE006071; Mon, 10 Nov 2003 17:31:24 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 17:31:24 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > > >13. Section 6.1. There is only one Oakley group defined, and it has an > > >equivalent strength of 80-bit symmetric encryption. There should be > > >additional Oakley groups that offer strength commensurate with the other > > >recommendations in the document. The document should explicitly reference > > >RFC 3526, and make use of group 14 (2048 bits). > > Any opinions here? "Use dh-group-exchange if you're paranoid". I'd say we should just add the group. The security concerns addressed are different than for dh-group-exchange, and it's a lot simpler. I think there were at least a few people in the group that argued for this addition already when dh-group-exchange was proposed. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 11:36:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28815 for ; Mon, 10 Nov 2003 11:36:42 -0500 (EST) Received: (qmail 7333 invoked by uid 605); 10 Nov 2003 16:36:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7326 invoked from network); 10 Nov 2003 16:36:51 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 16:36:51 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id D348761F56; Mon, 10 Nov 2003 17:36:50 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5DE9662166; Mon, 10 Nov 2003 17:36:49 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAGanCM006163; Mon, 10 Nov 2003 17:36:49 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAGakp2006160; Mon, 10 Nov 2003 17:36:46 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 17:36:46 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > > >3. Section 2, last paragraph. Setting the SHOULD for the timeout to 10 > > >minutes seems very long. Doesn't it open up some denial-of-service > > >attacks. The SHOULD for the timeout ought to be for interoperability. > > I'm reluctant to change that. First, it's a SHOULD, not a MUST.. > also, making it too short may cause issues for the handicapped > (consider the combination of slow typing rate and high error rate..) I don't think the specification of the timeout is essential at all. There are lots of other non-standardized authentication timeouts out there, with login-program, various kinds of http authentication, etc, and there doesn't seem to be a big problem to leave this to local policy. I don't think the DOS issue is particularly relevant, given that unathenticated users can force the server to perform the cpu-intensive key exchange protocol. It's nice with some guidelines in the spec, and ten minutes sounds reasonable to me. But as far as I'm concernedm it could be degraded to a RECOMMEND or ripped out totally, if that makes anybody happier. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 11:52:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29633 for ; Mon, 10 Nov 2003 11:52:02 -0500 (EST) Received: (qmail 15011 invoked by uid 605); 10 Nov 2003 16:52:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15004 invoked from network); 10 Nov 2003 16:52:09 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 10 Nov 2003 16:52:09 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E6FB766F69; Mon, 10 Nov 2003 17:52:08 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 5F4D866E89; Mon, 10 Nov 2003 17:52:06 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAAGq6CM006493; Mon, 10 Nov 2003 17:52:06 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAAGq3D6006490; Mon, 10 Nov 2003 17:52:03 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 10 Nov 2003 17:52:03 +0100 In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Message-ID: Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit At last, the final comment in this series... Bill Sommerfeld writes: > > >4. Section 5, last paragraph on page 9. Saying that UTF-8 is the > > >encoding for passwords means that implementations need to check for valid > > >UTF-8 encoding. This could lead to unexpected failures. It would be much > > >better to say that passwords are arbitrary binary strings with no > > >specified encoding. Exact match of the binary strings ought to > > >be sufficient. > > Thoughts? My understanding is that requesting exact match of > internationalized input is problematic under some circumstances.. This is confused. For both usernames and passwords, the server have to massage the input into it's native format (unicode normalization form C, or latin-1, or whatever) before further processing. The further processing is then typically lookup in a database (for usernames) and "one-way encryption" for passwords. In both cases, the operation will typically fail if the input is not normalized. Treating usernames and passwords differently makes no sense. Either, we say that both usernames and passowrds are ascii-only (8-bit characters could be allowed, with implementation defined meaning, so that we get a royal mess where users will never know whether or not if 8-bit cahracters will work), or we say that both usernames and passwords are utf8. I've argued earlier that the sender of utf8 strings should be required to normalize them (unicode normalization form C, or nameprep, not sure what's most appropriate). But I didn't get much support for that, and then the server MUST do the right thing when converting the strings to its native format. And if the server does the right thing for usernames, there's no extra cost in doing the same for passwords. The goal of the utf8 use is to be able to support scenarios like this: * Unix server with usernames and passwords encoded in latin-1 in the /etc/passwd file, and running in a latin-1 locale. * Unix client, also in a latin-1 locale. * Windows Pocket PC client, which is a native unicode application and has never heard of latin-1. * The username "Åke Ärlig", which can be encoded in at least 6 different equally correct ways in unicode as well as in proper utf8 without overlong sequences. If this doesn't Just Work, then the protocol is broken. And it seems we are asked to break it. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 10 18:09:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20384 for ; Mon, 10 Nov 2003 18:09:57 -0500 (EST) Received: (qmail 21640 invoked by uid 605); 10 Nov 2003 23:10:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21633 invoked from network); 10 Nov 2003 23:10:06 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 10 Nov 2003 23:10:06 -0000 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 hAANA55u012876; Mon, 10 Nov 2003 16:10:05 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAANA5bx009533; Mon, 10 Nov 2003 18:10:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAANA1S4008123; Mon, 10 Nov 2003 18:10:01 -0500 (EST) Message-Id: <200311102310.hAANA1S4008123@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org cc: Russ Housley Subject: Re: additional core draft nits in need of WG attention. In-Reply-To: Your message of "Mon, 10 Nov 2003 14:04:07 +0100." <20031110130406.GA18092@folly> Reply-to: sommerfeld@east.sun.com Date: Mon, 10 Nov 2003 18:10:01 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [wg chair hat on] I see a kernel of consensus building for: - leave recommended limit at 128 bits - explicitly grandfather 3DES I have not seen opposition to: - add AES as an alternate REQUIRED algorithm. - adding RFC 3526's 2048-bit group 14 as diffie-hellman-group14-sha1 Anyone who disagrees with any of the above these proposals should speak up soon. [now that I re-read this section of transport-17, we have an editing glitch]: The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit MODP Group). It is included below in hexadecimal and decimal. And it then specifies the group 1 modulus.. - BIll From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 05:33:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26281 for ; Tue, 11 Nov 2003 05:33:14 -0500 (EST) Received: (qmail 14790 invoked by uid 605); 11 Nov 2003 10:33:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14779 invoked from network); 11 Nov 2003 10:33:15 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Nov 2003 10:33:15 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E4DA214AF; Tue, 11 Nov 2003 11:26:31 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 8856F147B; Tue, 11 Nov 2003 11:26:30 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hABAQUCM015553; Tue, 11 Nov 2003 11:26:30 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hABAQREr015550; Tue, 11 Nov 2003 11:26:27 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311102310.hAANA1S4008123@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 11 Nov 2003 11:26:26 +0100 In-Reply-To: <200311102310.hAANA1S4008123@thunk.east.sun.com> Message-ID: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > [wg chair hat on] > > I see a kernel of consensus building for: > - leave recommended limit at 128 bits > - explicitly grandfather 3DES Exactly what does "grandfather" mean here? Change 3DES from REQUIRED to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? To me, it makes sense to keep it as RECOMMENDED. > [now that I re-read this section of transport-17, we have an editing > glitch]: > > The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key > exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] > (2048-bit MODP Group). It is included below in hexadecimal and decimal. > > And it then specifies the group 1 modulus.. I guess the name for dh with Oakley group 14 would be "diffie-hellman-group14-sha1". Or should we go for "diffie-hellman-group14-sha256" while we're at it? Unfortunately, there's more than one reasonable choice here. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 07:03:53 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28448 for ; Tue, 11 Nov 2003 07:03:53 -0500 (EST) Received: (qmail 5175 invoked by uid 605); 11 Nov 2003 12:03:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5168 invoked from network); 11 Nov 2003 12:03:50 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 11 Nov 2003 12:03:50 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 9194D5A029; Tue, 11 Nov 2003 13:03:49 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 61E2A59D3A; Tue, 11 Nov 2003 13:03:47 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hABC3kCM016708; Tue, 11 Nov 2003 13:03:46 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hABC3gwd016705; Tue, 11 Nov 2003 13:03:42 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Yoshi Kohno , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-newmodes-01.txt: WG Last Call! References: <200311100203.hAA23tS4003309@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 11 Nov 2003 13:03:42 +0100 In-Reply-To: <200311100203.hAA23tS4003309@thunk.east.sun.com> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > WG Members: please send comments on this document to this mailing list > and the author as soon as possible. Section 5.1, rekeying considerations, third paragraph, says Similarly, the use of random (and unpredictable to an adversary) padding will not prevent information leakage through the underlying MAC [BKN]. I don't think this statement is quite right. The attacker needs MAC:s for identical plaintexts to collide, and uses this to confirm that a guessed plaintext and an actual plaintext match. For fix padding, this happens with probability 1, which implies that a *single* chosen plaintext message is sufficient to confirm one correctly guessed message. With four bytes of random padding, it happens with probability (1/2)^32, which is a significant difference. Reading of the BKN paper seems to confirm that random padding makes the attack considerably less practical. Of course, this doens't mean that it's harmless to reuse the sequence number. Reusing the sequence number makes it possible for an attacker to replay ssh packets (this is also documented in the BKN paper). To me, replay attacks are a more compelling reason to avoid sequence number reuse than the information leak, and I think the newmodes document should mention this class of attacks. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 10:31:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05889 for ; Tue, 11 Nov 2003 10:31:08 -0500 (EST) Received: (qmail 29110 invoked by uid 605); 11 Nov 2003 15:31:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29103 invoked from network); 11 Nov 2003 15:31:15 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Nov 2003 15:31:15 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hABFVBPh010041; Tue, 11 Nov 2003 08:31:11 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hABFVAIr000457; Tue, 11 Nov 2003 10:31:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hABFVAS4011115; Tue, 11 Nov 2003 10:31:10 -0500 (EST) Message-Id: <200311111531.hABFVAS4011115@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. In-Reply-To: Your message of "11 Nov 2003 11:26:26 +0100." Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Nov 2003 10:31:10 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > I see a kernel of consensus building for: > > - leave recommended limit at 128 bits > > - explicitly grandfather 3DES > > Exactly what does "grandfather" mean here? Change 3DES from REQUIRED > to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? My apologies for using an Americanism here. "Grandfathering" something means roughly "keep it is, despite not (precisely) matching the letter of a newer spec/law/regulations/etc, because we've always done it that way". So, that would be "keep as REQUIRED". - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 12:32:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11984 for ; Tue, 11 Nov 2003 12:32:10 -0500 (EST) Received: (qmail 6822 invoked by uid 605); 11 Nov 2003 17:32:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6771 invoked from network); 11 Nov 2003 17:32:08 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 11 Nov 2003 17:32:08 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hABHVxxA028823; Tue, 11 Nov 2003 09:31:59 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hABHVx58010227; Tue, 11 Nov 2003 10:31:59 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hABHRlYY008880; Tue, 11 Nov 2003 11:27:47 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id hABHRkPi008879; Tue, 11 Nov 2003 09:27:46 -0800 (PST) Date: Tue, 11 Nov 2003 09:27:46 -0800 From: Nicolas Williams To: Niels =?unknown-8bit?Q?M=F6ller?= Cc: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031111172743.GA8875@binky.central.sun.com> References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit What Niels said. Passwords should be UTF-8 encoded. No stringprep or profile or even plain Unicode normalization form should be required to be applied by clients when the server processes a password, but for md5-digest type algorithms where the client processes the password, then a stringprep profile MUST be specified. In the case of "password" and "keyboard-interactive" userauth it's clear that the server processes the password so no stringprep profile is needed for the password in "password" userauth or for replies to "keyboard-interactive" userauth prompts. Cheers, Nico On Mon, Nov 10, 2003 at 05:52:03PM +0100, Niels M?ller wrote: > At last, the final comment in this series... > > Bill Sommerfeld writes: > > > > >4. Section 5, last paragraph on page 9. Saying that UTF-8 is the > > > >encoding for passwords means that implementations need to check for valid > > > >UTF-8 encoding. This could lead to unexpected failures. It would be much > > > >better to say that passwords are arbitrary binary strings with no > > > >specified encoding. Exact match of the binary strings ought to > > > >be sufficient. > > > > Thoughts? My understanding is that requesting exact match of > > internationalized input is problematic under some circumstances.. > > This is confused. For both usernames and passwords, the server have to > massage the input into it's native format (unicode normalization form > C, or latin-1, or whatever) before further processing. The further processing > is then typically lookup in a database (for usernames) and "one-way > encryption" for passwords. In both cases, the operation will typically > fail if the input is not normalized. > > Treating usernames and passwords differently makes no sense. Either, > we say that both usernames and passowrds are ascii-only (8-bit > characters could be allowed, with implementation defined meaning, so > that we get a royal mess where users will never know whether or not if > 8-bit cahracters will work), or we say that both usernames and > passwords are utf8. > > I've argued earlier that the sender of utf8 strings should be required > to normalize them (unicode normalization form C, or nameprep, not sure > what's most appropriate). But I didn't get much support for that, and > then the server MUST do the right thing when converting the strings to > its native format. And if the server does the right thing for > usernames, there's no extra cost in doing the same for passwords. > > The goal of the utf8 use is to be able to support scenarios like this: > > * Unix server with usernames and passwords encoded in latin-1 in the > /etc/passwd file, and running in a latin-1 locale. > > * Unix client, also in a latin-1 locale. > > * Windows Pocket PC client, which is a native unicode application > and has never heard of latin-1. > > * The username "Åke Ärlig", which can be encoded in at least 6 > different equally correct ways in unicode as well as in proper > utf8 without overlong sequences. > > If this doesn't Just Work, then the protocol is broken. And it seems > we are asked to break it. > > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 12:40:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12519 for ; Tue, 11 Nov 2003 12:40:23 -0500 (EST) Received: (qmail 11937 invoked by uid 605); 11 Nov 2003 17:40:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11930 invoked from network); 11 Nov 2003 17:40:31 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 11 Nov 2003 17:40:31 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id B26171EB70; Tue, 11 Nov 2003 18:40:23 +0100 (CET) Message-ID: <3FB11F88.2050701@siliconcircus.com> Date: Tue, 11 Nov 2003 18:42:32 +0100 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: =?ISO-8859-1?Q?Niels_M=F6ller?= , sommerfeld@east.sun.com, ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> <20031111172743.GA8875@binky.central.sun.com> In-Reply-To: <20031111172743.GA8875@binky.central.sun.com> 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 Nicolas Williams wrote: > > In the case of "password" and "keyboard-interactive" userauth it's clear > that the server processes the password so no stringprep profile is > needed for the password in "password" userauth or for replies to > "keyboard-interactive" userauth prompts. Does what you're saying here imply that the client should really be required to send a character set string together with the password in those situations (such that the server can then make the appropriate translations), or have I misunderstood? -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 17:30:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25287 for ; Tue, 11 Nov 2003 17:30:56 -0500 (EST) Received: (qmail 22090 invoked by uid 605); 11 Nov 2003 22:30:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22082 invoked from network); 11 Nov 2003 22:30:55 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 11 Nov 2003 22:30:55 -0000 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 hABMUr5u026824; Tue, 11 Nov 2003 15:30:54 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hABMUrIr027321; Tue, 11 Nov 2003 17:30:53 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hABMUrS4013247; Tue, 11 Nov 2003 17:30:53 -0500 (EST) Message-Id: <200311112230.hABMUrS4013247@thunk.east.sun.com> From: Bill Sommerfeld To: Matt Johnston cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. In-Reply-To: Your message of "Wed, 12 Nov 2003 03:08:21 +0800." <20031111190821.GA476779@morwong.ucc.gu.uwa.edu.au> Reply-to: sommerfeld@east.sun.com Date: Tue, 11 Nov 2003 17:30:53 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I'd prefer to see AES as REQUIRED and 3DES put down to RECOMMENDED. Having > two REQUIRED ciphers adds to the size of implementations, and could be an > issue in some small environments. I've seen sufficient opposition to demoting 3DES that the only thing on the table right now is whether we should promote AES. Anyone have data on: - what proportion of the code size of a "minimized" implementation is the actual algorithm code? i.e., are we talking 1% or 10% bloat here? - how widespread is AES support today? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 11 19:32:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00439 for ; Tue, 11 Nov 2003 19:32:06 -0500 (EST) Received: (qmail 18463 invoked by uid 605); 12 Nov 2003 00:32:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18451 invoked from network); 12 Nov 2003 00:32:10 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 12 Nov 2003 00:32:10 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAC0W6xA013118; Tue, 11 Nov 2003 16:32:06 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAC0W52o025184; Tue, 11 Nov 2003 17:32:05 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAC0P6YY009707; Tue, 11 Nov 2003 18:25:06 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id hAC0P5DD009706; Tue, 11 Nov 2003 16:25:05 -0800 (PST) Date: Tue, 11 Nov 2003 16:25:05 -0800 From: Nicolas Williams To: Jon Bright Cc: Niels =?unknown-8bit?Q?M=F6ller?= , sommerfeld@east.sun.com, ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031112002455.GA9700@binky.central.sun.com> References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> <20031111172743.GA8875@binky.central.sun.com> <3FB11F88.2050701@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB11F88.2050701@siliconcircus.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Nov 11, 2003 at 06:42:32PM +0100, Jon Bright wrote: > Nicolas Williams wrote: > > > >In the case of "password" and "keyboard-interactive" userauth it's clear > >that the server processes the password so no stringprep profile is > >needed for the password in "password" userauth or for replies to > >"keyboard-interactive" userauth prompts. > > Does what you're saying here imply that the client should really be > required to send a character set string together with the password in > those situations (such that the server can then make the appropriate > translations), or have I misunderstood? I'm saying that the client send UTF-8 encoded strings to the server for these two cases ("password" and "keyboard-interactive" userauth responses) without applying _any_ string preparation to whatever the UI interfaces produced as responses typed in by the user. E.g., if the UI produces decomposed character sequences for, say, Latin vowels with accents, then that is what the client sends, and if sometimes the UI produces decomposed sequences and sometimes composed characters, then that is what the client sends, and if the UI produces something other than Unicode, then the client will convert to Unicode before sending and will send whatever its converter produces, and if the _server_ needs a particular string preparation for passwords, or if it needs to process only passwords in 8859-1, then the _server_ applies whatever stringprep profiles/charset conversions/whatever that it needs, and then processes the password (e.g., hash it then compare it to some hash). The client cannot know what preparation the server needs for passwords sent to the server. But if the client were doing MD5-Digest authentication (which SSHv2 does not provide for), then the client would have to know what preparations to apply to passwords prior to using them with MD5-Digest. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 01:35:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10404 for ; Wed, 12 Nov 2003 01:35:20 -0500 (EST) Received: (qmail 11845 invoked by uid 605); 12 Nov 2003 06:35:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11837 invoked from network); 12 Nov 2003 06:35:22 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 12 Nov 2003 06:35:22 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 558271F29A7; Wed, 12 Nov 2003 07:35:14 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 492F26CC5F; Wed, 12 Nov 2003 07:35:16 +0100 (MET) Received: from localhost (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id A349931917; Wed, 12 Nov 2003 07:35:11 +0100 (MET) Date: Tue, 11 Nov 2003 22:37:33 -0800 (PST) From: maf@appgate.com Reply-To: maf@appgate.com Subject: Re: additional core draft nits in need of WG attention. To: sommerfeld@east.sun.com Cc: matt@ucc.asn.au, ietf-ssh@NetBSD.org, housley@vigilsec.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20031112063511.A349931917@pelee.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 11 Nov, Bill Sommerfeld wrote: > - what proportion of the code size of a "minimized" implementation is > the actual algorithm code? i.e., are we talking 1% or 10% bloat here? In our smallest java-client, which is used on cellphones etc, the actual AES-code makes up between 1% and 0.5% depending on how you count. The DES and 3DES-code is about twice that big. > - how widespread is AES support today? IMHO it is pretty widespread, at least among modern versions. Unfortunately, as well all know, the installed base may be far behind. For exampel we still get a lot of questions on SSHv1 support:-( /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 02:38:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09639 for ; Wed, 12 Nov 2003 02:38:01 -0500 (EST) Received: (qmail 8889 invoked by uid 605); 12 Nov 2003 07:37:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8882 invoked from network); 12 Nov 2003 07:37:59 -0000 Received: from asclepius.uwa.edu.au (130.95.128.56) by mail.netbsd.org with SMTP; 12 Nov 2003 07:37:59 -0000 Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id E0D85367601 for ; Wed, 12 Nov 2003 15:37:57 +0800 (WST) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.uwa.edu.au (Postfix) with ESMTP id D79A336777C for ; Wed, 12 Nov 2003 15:37:57 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 38D0AFF4A; Wed, 12 Nov 2003 15:37:57 +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 4E3FFFF45; Wed, 12 Nov 2003 15:37:54 +0800 (WST) Received: by morwong.ucc.gu.uwa.edu.au (8.9.3/1.1.29.3/07Oct02-0318AM) id PAA0000482590; Wed, 12 Nov 2003 15:37:52 +0800 (WST) Date: Wed, 12 Nov 2003 15:37:50 +0800 From: Matt Johnston To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031112073750.GA481419@morwong.ucc.gu.uwa.edu.au> Mail-Followup-To: Bill Sommerfeld , ietf-ssh@NetBSD.org, Russ Housley References: <20031111190821.GA476779@morwong.ucc.gu.uwa.edu.au> <200311112230.hABMUrS4013247@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311112230.hABMUrS4013247@thunk.east.sun.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mooneye.ucc.gu.uwa.edu.au X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Nov 11, 2003 at 05:30:53PM -0500, Bill Sommerfeld wrote: > > Anyone have data on: > > - what proportion of the code size of a "minimized" implementation is > the actual algorithm code? i.e., are we talking 1% or 10% bloat here? Looking at a x86 dynamically linked binary for Dropbear (SSH2 server), the size is ~110kB with 3DES and AES compiled in (plus rsa, dss, dh-group1, sha1). Removing 3DES drops the size by ~5kB, removing AES drops it by ~15kB, although the AES implementation is quite large. So the size difference could be in the order of 5%, at least for this implementation. I guess the size decrease from removing 3DES isn't actually that significant. Matt From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 04:14:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11813 for ; Wed, 12 Nov 2003 04:14:11 -0500 (EST) Received: (qmail 10342 invoked by uid 605); 12 Nov 2003 09:14:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10333 invoked from network); 12 Nov 2003 09:14:14 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 12 Nov 2003 09:14:14 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 1AJr4h-0008De-00; Wed, 12 Nov 2003 09:14:07 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <200311112230.hABMUrS4013247@thunk.east.sun.com> Subject: Re: additional core draft nits in need of WG attention. Message-Id: Date: Wed, 12 Nov 2003 09:14:07 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: > Anyone have data on: [...] > - how widespread is AES support today? It's difficult to imagine how this data might show up except in the form of a bunch of implementors each shouting `I do / do not support AES' [delete as appropriate]. On which basis: PuTTY supports AES. Cheers, Simon -- Simon Tatham "That all men should be brothers is a dream of people who have no brothers." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 04:16:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11853 for ; Wed, 12 Nov 2003 04:16:52 -0500 (EST) Received: (qmail 11455 invoked by uid 605); 12 Nov 2003 09:17:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11445 invoked from network); 12 Nov 2003 09:17:00 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 12 Nov 2003 09:17:00 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 95E551EB70; Wed, 12 Nov 2003 10:16:56 +0100 (CET) Message-ID: <3FB1FB14.3000805@siliconcircus.com> Date: Wed, 12 Nov 2003 10:19:16 +0100 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Tatham Cc: ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: In-Reply-To: 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 Simon Tatham wrote: > It's difficult to imagine how this data might show up except in the > form of a bunch of implementors each shouting `I do / do not support > AES' [delete as appropriate]. > > On which basis: PuTTY supports AES. PenguiNet also supports AES (and has done so in all SSH2-capable versions). If implementors shout at me about whether they support AES, rather than everyone sending in a mail to the list, I'll be happy to correlate the answers and send a summary tomorrow at about this time. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 08:51:42 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17425 for ; Wed, 12 Nov 2003 08:51:41 -0500 (EST) Received: (qmail 26207 invoked by uid 605); 12 Nov 2003 13:51:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26200 invoked from network); 12 Nov 2003 13:51:43 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 12 Nov 2003 13:51:43 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 2B859835F1; Wed, 12 Nov 2003 14:51:42 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id CA1D09EF52; Wed, 12 Nov 2003 14:51:39 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hACDpdCM001321; Wed, 12 Nov 2003 14:51:39 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hACDpZPX001318; Wed, 12 Nov 2003 14:51:35 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Matt Johnston , ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. References: <200311112230.hABMUrS4013247@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 12 Nov 2003 14:51:35 +0100 In-Reply-To: <200311112230.hABMUrS4013247@thunk.east.sun.com> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > - what proportion of the code size of a "minimized" implementation is > the actual algorithm code? i.e., are we talking 1% or 10% bloat here? In my implementation, des is about 8K code. Aes is about 2.5K code and 9K tables, which iirc can easily be cut to about 3K of tables if memory usage is more important than speed, so below I'll count aes as 5.5K total code and data. All this measured on x86. The stripped lsh client binary is 340K (excluding bignum library and libz and other libraries which are linked dynamically). So here, the ciphers are 2.4% (des), or 1.6% (small aes) of the bulk. So let's guess that a minimized implementation would be cut down to somewhere between 100K-200K (I think it's difficult to get below 100K, anybody that has tried?). Then the bloat factor for each cipher is somewhere between 3% and 8%. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 12 14:30:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03052 for ; Wed, 12 Nov 2003 14:30:53 -0500 (EST) Received: (qmail 26026 invoked by uid 605); 12 Nov 2003 19:30:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26019 invoked from network); 12 Nov 2003 19:30:54 -0000 Received: from user-10cm0rc.cable.mindspring.com (HELO localhost.localdomain) (64.203.3.108) by mail.netbsd.org with SMTP; 12 Nov 2003 19:30:54 -0000 Received: from cs.ucsd.edu (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hACJUVwu017464 for ; Wed, 12 Nov 2003 11:30:32 -0800 Message-ID: <3FB28A57.8030605@cs.ucsd.edu> Date: Wed, 12 Nov 2003 11:30:31 -0800 From: Yoshi Kohno User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-newmodes-01.txt: WG Last Call! References: <200311100203.hAA23tS4003309@thunk.east.sun.com> In-Reply-To: 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 > Of course, this doens't mean that it's harmless to reuse the sequence > number. Reusing the sequence number makes it possible for an attacker > to replay ssh packets (this is also documented in the BKN paper). > > To me, replay attacks are a more compelling reason to avoid sequence > number reuse than the information leak, and I think the newmodes > document should mention this class of attacks. > Thank you for pointing this out. Yes, we seem to have failed to mention this in the current version of the Internet-Draft. We will fix this in the next version. Yoshi From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 13 10:41:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03505 for ; Thu, 13 Nov 2003 10:41:39 -0500 (EST) Received: (qmail 21190 invoked by uid 605); 13 Nov 2003 15:41:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21183 invoked from network); 13 Nov 2003 15:41:41 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 13 Nov 2003 15:41:41 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 649E91EB70; Thu, 13 Nov 2003 16:41:33 +0100 (CET) Message-ID: <3FB3A6AD.6070005@siliconcircus.com> Date: Thu, 13 Nov 2003 16:43:41 +0100 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon Bright Cc: ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <3FB1FB14.3000805@siliconcircus.com> In-Reply-To: <3FB1FB14.3000805@siliconcircus.com> 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 Jon Bright wrote: > If implementors shout at me about whether they support AES, rather than > everyone sending in a mail to the list, I'll be happy to correlate the > answers and send a summary tomorrow at about this time. So, further to this - I doubt this list is anything like complete, but the following implementations all support AES. Nobody mailed to say they didn't: PuTTY Dropbear MindTerm AppGate All current Vandyke versions PenguiNet Peter Gutman didn't mail to say whether his implementation supports AES or not (since his policy is to support as little as possible, I guess he'd be the most likely candidate for non-support, hence the special mention). Matt Johnston (DropBear) mentioned he might try and hunt down an SSH2 implementation that didn't support AES. He's not mailed to say he found anything, but that could just mean he hasn't had time yet. Either way, it seems like making AES required won't cause problems for anyone. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 13 12:55:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10811 for ; Thu, 13 Nov 2003 12:55:21 -0500 (EST) Received: (qmail 4704 invoked by uid 605); 13 Nov 2003 17:55:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4697 invoked from network); 13 Nov 2003 17:55:28 -0000 Received: from asclepius.uwa.edu.au (130.95.128.56) by mail.netbsd.org with SMTP; 13 Nov 2003 17:55:28 -0000 Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id B76A2367ED9 for ; Fri, 14 Nov 2003 01:55:22 +0800 (WST) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.uwa.edu.au (Postfix) with ESMTP id B1072367ED4 for ; Fri, 14 Nov 2003 01:55:22 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id E9648FF5D; Fri, 14 Nov 2003 01:55:21 +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 341C4FF59; Fri, 14 Nov 2003 01:55:18 +0800 (WST) Received: by morwong.ucc.gu.uwa.edu.au (8.9.3/1.1.29.3/07Oct02-0318AM) id BAA0000488598; Fri, 14 Nov 2003 01:55:16 +0800 (WST) Date: Fri, 14 Nov 2003 01:55:15 +0800 From: Matt Johnston To: Jon Bright Cc: ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031113175515.GH481419@morwong.ucc.gu.uwa.edu.au> Mail-Followup-To: Jon Bright , ietf-ssh@netbsd.org References: <3FB1FB14.3000805@siliconcircus.com> <3FB3A6AD.6070005@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB3A6AD.6070005@siliconcircus.com> User-Agent: Mutt/1.4i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mooneye.ucc.gu.uwa.edu.au X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.60 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Nov 13, 2003 at 04:43:41PM +0100, Jon Bright wrote: > Matt Johnston (DropBear) mentioned he might try and hunt down an SSH2 > implementation that didn't support AES. He's not mailed to say he found > anything, but that could just mean he hasn't had time yet. Mocha Telnet for Palm OS appears to only support 3DES with SSH2. http://www.mochasoft.dk/palm.html#palmtelnet A Cisco router with version "Cisco-1.25" appears to advertise 3DES only as well. Those are the only two I found. Cheers, Matt From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 13 13:53:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12610 for ; Thu, 13 Nov 2003 13:53:08 -0500 (EST) Received: (qmail 7094 invoked by uid 605); 13 Nov 2003 18:53:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7087 invoked from network); 13 Nov 2003 18:53:15 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 13 Nov 2003 18:53:15 -0000 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 hADIrE5u019699; Thu, 13 Nov 2003 11:53:14 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hADIrDIr028256; Thu, 13 Nov 2003 13:53:13 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hADIrDS4023157; Thu, 13 Nov 2003 13:53:13 -0500 (EST) Message-Id: <200311131853.hADIrDS4023157@thunk.east.sun.com> From: Bill Sommerfeld To: Russ Housley , "Steven M. Bellovin" cc: ietf-ssh@NetBSD.org Subject: Re: WG Session Summary In-Reply-To: Your message of "Mon, 10 Nov 2003 11:54:54 EST." <5.2.0.9.2.20031110115446.043e7508@mail.binhost.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 13 Nov 2003 13:53:13 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Secure Shell (secsh) WG Session summary: We met for one hour on Tuesday afternoon. Document status: One document, draft-ietf-secsh-dns-05.txt has emerged from IESG review and is now in the RFC editor queue. (a first for this group); it also got a DNS RR type code assigned by IANA. The core protocol drafts were returned from the IESG with a number of minor comments; we are in the process of resolving the technical issues and will respin once these are resolved. One other draft (draft-ietf-secsh-auth-kbdinteract-05.txt) was also returned from the IESG with comments. The Diffie-Hellman Group Exchange negotiation draft has just been passed to the IESG. Three other drafts are in WG Last Call (break, newmodes, and publickeyfile). "newmodes" is probably the most interesting as it suggests several new cryptographic modes which fix minor cryptoraphic defects in the ssh transport mode. A new draft on SSH/SCP/SFTP URI formats was recently submitted and is almost ready for review by the URI doctors. proposed issue resolutions: - transport draft needs to move 3DES, AES references to normative - group sizes: preliminary discussions suggest that it will take some time to nail down new grops; we will instead put a note in the security considerations section mentioning that group 1 is somewhat small, and additional groups will be specified in subsequent documents. - confusing/conflicting text with regards to version string line termination: proposed text sent to WG list; needs review. - 3des effective strength: in security considerations section, mention that there is a known but not practical 2^112 time 2^112 space attack which makes 3des slightly weaker than the 2^128 bit effective strength threshold; existing deployments and lack of experience with newer ciphers make demoting 3des imprudent at this time. - move AES to REQUIRED? there does not seem to be any objection to this. - asymmetric algorithms change document to say that the symmetric algorithms used SHOULD be the same in each direction but there may be environments where it makes sense to decouple them. Nicolas Williams pointed out that this also applies to language negotiation. - default login timeouts: leave them alone; they're just defaults. - internationalization of passwords. something like the proposed text from the AD was considered and rejected several years ago; leave it alone. - confusing/conflicting test with respect to "implicit server authentication" jhutz will propose replacement text soon. near-term action items: - all document authors should contact the WG chair to arrange for write access to the issue tracker. - wg chair to send summary the proposed resolution of core draft issues to the WG list for discussion/consensus call. - jhutz will provide clarifying text relating to "implicit server authentication" in the transport draft. - once resolved, document editor will re-spin core drafts - wg chair will close out WGLC on break, publickeyfile, and newmodes and request publication when appropriate. - jhutz will respin the gsskeyex draft to include additional DH groups besides oakley group 1 (as well as redo the security considerations section) - wg chair will do WGLC on gsskeyex once respun From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 13 14:50:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15214 for ; Thu, 13 Nov 2003 14:50:56 -0500 (EST) Received: (qmail 6537 invoked by uid 605); 13 Nov 2003 19:50:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6529 invoked from network); 13 Nov 2003 19:50:58 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 13 Nov 2003 19:50:58 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2003 20:48:32 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hADJokBp029720; Thu, 13 Nov 2003 20:50:46 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA19317; Thu, 13 Nov 2003 19:50:55 GMT Date: Thu, 13 Nov 2003 19:50:55 +0000 From: Derek Fawcus To: Jon Bright , ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031113195054.W650@edinburgh.cisco.com> References: <3FB1FB14.3000805@siliconcircus.com> <3FB3A6AD.6070005@siliconcircus.com> <20031113175515.GH481419@morwong.ucc.gu.uwa.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20031113175515.GH481419@morwong.ucc.gu.uwa.edu.au>; from matt@ucc.asn.au on Fri, Nov 14, 2003 at 01:55:15AM +0800 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Nov 14, 2003 at 01:55:15AM +0800, Matt Johnston wrote: > > A Cisco router with version "Cisco-1.25" appears to advertise 3DES only as > well. I guess it may depend upon version. I thought that all versions including SSHv2 (as opposed to SSHv1) also supported AES. However I can't give an authoritive answer without checking. Certainly my home router (with a 12.3T snapshot) which signs itself as 'SSH-1.99-Cisco-1.25', advertises aes128-cbc, aes192-cbc, aes256-cbc. Mind given that it only offers 'ssh-rsa' and not 'ssh-dsa' it can't claim complete checkbox compiance to the drafts. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 01:18:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15378 for ; Sat, 15 Nov 2003 01:18:28 -0500 (EST) Received: (qmail 8046 invoked by uid 605); 15 Nov 2003 06:18:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7985 invoked from network); 15 Nov 2003 06:18:31 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 15 Nov 2003 06:18:31 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 00D3B63C18; Sat, 15 Nov 2003 19:18:30 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAF6IrV08457; Sat, 15 Nov 2003 19:18:53 +1300 Date: Sat, 15 Nov 2003 19:18:53 +1300 Message-Id: <200311150618.hAF6IrV08457@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, sommerfeld@east.sun.com Subject: Re: additional core draft nits in need of WG attention. Cc: housley@vigilsec.com, ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >And no security advantage? The general assertion that there's no security >advantage is false. As always, it's a tradeoff that depends on lots of >circumstances. That's basically just creating an artificial reason to justify it, rather than any real supporting argument. How many cases of this have you actually run into so far? How does the user determine what to use in which direction? How do they ensure that nothing sensitive gets sent over the less-secure channel? How do they configure the software to do this? For that matter, do they even know that this capability exists? >1. The end nodes have constrained cpu capacity. In that case why would you want a lightweight cipher in only one direction rather than both? >I don't buy this at all. As for interoperability problems, it's true that >it's a rarely used (and likely not well tested) feature. It's not just rarely used, does anything use it? I seem to remember at one point screwing up the handshake code during testing so it somehow reported two different algorithm choices, and getting back an error from whatever server I was bouncing messages off at the time saying that the incoming cipher choice didn't match the outgoing one, which doesn't inspire confidence. In the constrained-CPU case, cryptlib is used in one of the (if not the) most constrained implementations I know of (16-bit embedded CPU at around 10MHz, it takes 15s just to do a 512-bit private-key op), and using asymmetric algorithm choices was never even considered because of the danger of interop problems once it was deployed. I did talk about it with people looking at another embedded use, but it was ruled out pretty much instantly (the phrase "lightning rod for every implementation bug in every SSH implementation ever created" came up during the discussion). Any low-power CPU implementation is probably going to be some embedded system, for which firmware updates will be problematic. If you're going to include a feature that's a lightning rod for implementation quirks, the last place you want to put it is in a device where it's either impossible or at least very difficult to change the code to work around the quirks. So I don't buy the argument that this is worth supporting, and in the few situations where it might hypothetically be useful it's downright dangerous. I agree with the original poster that its use should be discouraged. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 01:22:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15454 for ; Sat, 15 Nov 2003 01:22:27 -0500 (EST) Received: (qmail 10642 invoked by uid 605); 15 Nov 2003 06:22:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10634 invoked from network); 15 Nov 2003 06:22:34 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 15 Nov 2003 06:22:34 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id ADE0363C18; Sat, 15 Nov 2003 19:22:33 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAF6Mxk08475; Sat, 15 Nov 2003 19:22:59 +1300 Date: Sat, 15 Nov 2003 19:22:59 +1300 Message-Id: <200311150622.hAF6Mxk08475@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, sommerfeld@east.sun.com Subject: Re: additional core draft nits in need of WG attention. Cc: housley@vigilsec.com, ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >Bill Sommerfeld writes: >> > >10. Section 5, last paragraph. What is "implicit server >> > >authentication?" The whole paragraph is unclear. >> >> Can someone provide some fill-in text? > >I think it refers to key exchange methods like the ones used in tls >and ssh1, where one party chooses the session key and encrypts it >using the other party's public RSA key. Then you must consider the >remote end unauthenticated until you have verified that she knows the >session key. Here's my tongue-in-cheek interpretation from a code comment: /* [...] The spec says that after a key exchange with implicit server authentication, the client must wait for the server to send a service- accept packet before continuing, however it never explains what implicit (and, by extension, explicit) server authentication actually is. We therefore define it to be "Something completely different from what we're doing here", which means that we can send the two packets together without having to wait for the server */ I read through the surrounding text and tried to figure out what the point of this requirement was, couldn't really find any, and so came up with the above interpretation, which works nicely :-). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 02:12:45 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19153 for ; Sat, 15 Nov 2003 02:12:45 -0500 (EST) Received: (qmail 5773 invoked by uid 605); 15 Nov 2003 07:11:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5763 invoked from network); 15 Nov 2003 07:11:24 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 15 Nov 2003 07:11:24 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 34BFC63C18 for ; Sat, 15 Nov 2003 20:11:20 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAF7Bj208612 for ietf-ssh@NetBSD.org; Sat, 15 Nov 2003 20:11:45 +1300 Date: Sat, 15 Nov 2003 20:11:45 +1300 Message-Id: <200311150711.hAF7Bj208612@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Comments on DH-GEX draft Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've been meaning to send these in for awhile, seeing the latest draft (which adds the changed-format request message) finally motivated me to type up the comments I had. There are two main problem areas, the first is the new-format message (I'll call it new-gex here) using { min, preferred, max } rather than the original { preferred } format (I'll call it gex). This looks like it's been bolted on recently without updating the rest of the text, which still describes the behaviour for gex. In fact I couldn't actually find a server that would accept the new-gex format, only the old gex one (they just rejected requests with the new-gex message). As it stands now, the new-gex doesn't actually serve any purpose, and in fact the overall mechanism is somewhat confused. The text says: The server can constantly compute new groups in the back-ground. However it can't really do this because the group size is chosen by the client! In order to be able to usefully do this, it would have to maintain and constantly update a smorgasbord of group sizes to handle any request the client might decide to make. In order to avoid this problem the text says: The server should return the smallest group it knows that is larger than the size the client requested. If the server does not know a group that is larger than the client request, then it SHOULD return the largest group it knows. This avoids the need to maintain a whole array of possible key sizes to match any eventuality, but also means the server can more or less completely ignore what the client requests. Depending on how silly you want to get, you could either always return the default built-in DH key, or generate some outrageously large key which is guaranteed to always be larger than what the client asks for and return that, both of which are fully compliant with the spec. In any case, the new-gex format is at best completely redundant and at worst misleading, since the message format implies some sort of choice while the text says the server can do anything it feels like: Servers and clients SHOULD support groups with a modulus length of k bits, where 1024 <= k <= 8192. The recommended values for min and max are 1024 and 8192 respectively. which is synonymous with "you can use any (safe) key size you feel like". The problem here is that the server is the one to make the choice, but the client is supposed to somehow know what appropriate requests to match the choice should be. For example if the client really needs to use a 1Kbit key for performance reasons and all the server has is a 2Kbit key, the client would be better off choosing the built-in default DH key rather than asking for a 1K gex key and getting back a 2K one. The negotiation is being done the wrong way round. The fix is simple: Instead of saying: "diffie-hellman-group-exchange-sha1" the server says: "diffie-hellman-group-exchange--sha1,diffie-hellman-group- exchange--sha1,diffie-hellman-group1-sha1" and the client can then choose what it wants. Standard/permitted sizes would be "1024", "2048", and "4096" (and "8192" if you really want to get silly, from the Skip code an 8K key took two days of CPU time on the fastest Alpha server they had available, so I doubt many of these would be generated in the background by servers), in practice it's expected that N would never exceed 1 or 2. If there's a need to be backwards-compatible with existing implementations, you could add a "diffie-hellman-group-exchange-sha1" after the initial entries and accept the current hit-or-miss semantics for that entry. For example if the server does a background keygen of 1K and 2K keys it could advertise: "diffie-hellman-group-exchange-1024-sha1,diffie-hellman-group- exchange-2048-sha1,diffie-hellman-group1-sha1" If it only generates 2K keys: "diffie-hellman-group-exchange-2048-sha1,diffie-hellman-group1-sha1" and the client, seeing this, can decide whether it wants a slow 2Kbit key or a faster (but perhaps not as secure) 1K bit built-in key. If the server has just used its 2K ephemeral key and needs time to generate a new one: "diffie-hellman-group-exchange-1024-sha1,diffie-hellman-group1-sha1" and the client can decide whether it wants to use a 1K key or wait for a new 2K one to be generated. So that was the first problem. The second one is the way the key is communicated, which is by sending the raw key components rather than by using the standard SSH key format: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data This is problematic because it assumes that the only key type that will ever be used is a DH key, and that a DH key is only made up of p and g components. The spec warns about the use of safe primes, but by the use of a nonstandard key format rules out any means of communicating the safe-prime information to the server. For example if you generate DLP keys using the DSA kosheriser (or any format that provides more than the PKCS #3 p and g) you can communicate the verification parameters to the client, and they can check things without having to blindly trust the server. So if the server wants to send raw PKCS #3 keys it would use: string "ssh-dh" mpint p mpint g If it was using verifiable DLP keys it would send: string "ssh-dss" mpint p mpint q mpint g mpint y and if you really wanted to go to extremes you could send: string "ssh-dss-verifiable" mpint p mpint q mpint g mpint j -- Subgroup factor satisfying p = jq + 1 [...] validationParms -- For kosheriser seed generation mpint y Implementations know that the built-in DH value is safe because of its origins, with the inclusion of verification parameters it's possible for clients to check this for any new keys handed out by the server, but with only raw key components they have to blindly trust the server to use appropriate keys. At a minimum, it should at least use the standard SSH format for public keys, rather than just sending raw key components across. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 05:40:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03636 for ; Sat, 15 Nov 2003 05:40:58 -0500 (EST) Received: (qmail 26095 invoked by uid 605); 15 Nov 2003 10:41:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26088 invoked from network); 15 Nov 2003 10:41:02 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Nov 2003 10:41:02 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 9A24AB3BE4; Sat, 15 Nov 2003 11:41:00 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 361CEB22F5; Sat, 15 Nov 2003 11:40:58 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAFAevCM018744; Sat, 15 Nov 2003 11:40:58 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAFAerKt018741; Sat, 15 Nov 2003 11:40:53 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: sommerfeld@east.sun.com, housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <200311150618.hAF6IrV08457@cs.auckland.ac.nz> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 15 Nov 2003 11:40:53 +0100 In-Reply-To: <200311150618.hAF6IrV08457@cs.auckland.ac.nz> Message-ID: Lines: 93 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: > > >And no security advantage? The general assertion that there's no security > >advantage is false. As always, it's a tradeoff that depends on lots of > >circumstances. > > That's basically just creating an artificial reason to justify it, rather than > any real supporting argument. One counter example should be enough to falsify a general assertion. So some better arguments than the genereral assertion are needed for discouraging the feature. Thanks for providing some. > >1. The end nodes have constrained cpu capacity. > > In that case why would you want a lightweight cipher in only one direction > rather than both? Because one believes that the heavier cipher is more secure, and one can afford to use it in the low datarate direction. > >I don't buy this at all. As for interoperability problems, it's true that > >it's a rarely used (and likely not well tested) feature. > > It's not just rarely used, does anything use it? [...] Now we're talking. This looks like a valid argument for removing the feature. > and using asymmetric algorithm choices was never even considered > because of the danger of interop problems once it was deployed. Out of curiosity, which ciphers did you support at all? With only one or both of aes and des3 to choose from, assymetric choices doesn't make much sense. If we strike out the second MUST in : The ciphers in each direction MUST run independently of each other, : and implementations MUST allow independently choosing the algorithm : for each direction (if multiple algorithms are allowed by local : policy). and an implementation chooses to not implement that, exactly what does that mean? Will the implementation do algorithm selection as defined in the spec, and then disconnect of it ends up with assymmetric choices? Or will it enforce that the *input* to the selection processing is symmetric, i.e. that in the KEXINIT message, encryption_algorithms_client_to_server == encryption_algorithms_server_to_client mac_algorithms_client_to_server == mac_algorithms_server_to_client (I think that's a better way of doing it). Then, what about compression? To me, it makes sense to be able to choose compression in only one direction, should that possibility be discouraged as well? The details must be spelled out. If we really want to get rid of this possibility, the cleanest and least confusing way of doing it would be to define protocol version 2.1 with a changed KEXINIT format, byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms string mac_algorithms string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) but we have to get the 2.0 spec published first (and there are a bunch of other details that should be fixed when we bump the version number). I'm always confused when a spec allows flexibility which, for good or bad and perhaps undocumented reasons, noone implements. (Last time I was fooled in this way by an RFC was RFC1035 and the DNS QDCOUNT. Noone supports QDCOUNT != 1, and there seems to be some reasonable arguments for that. But since it's still allowed by the spec, it's something that has been an annoying surprise to everyone that has written a DNS client the last 15 years). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 06:24:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04457 for ; Sat, 15 Nov 2003 06:24:20 -0500 (EST) Received: (qmail 15545 invoked by uid 605); 15 Nov 2003 11:24:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15538 invoked from network); 15 Nov 2003 11:24:29 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 15 Nov 2003 11:24:29 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 13C5563C1C; Sun, 16 Nov 2003 00:24:28 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAFBOsp10319; Sun, 16 Nov 2003 00:24:54 +1300 Date: Sun, 16 Nov 2003 00:24:54 +1300 Message-Id: <200311151124.hAFBOsp10319@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se Subject: Re: additional core draft nits in need of WG attention. Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >Out of curiosity, which ciphers did you support at all? With only one or both >of aes and des3 to choose from, assymetric choices doesn't make much sense. { "whatever the user has enabled" union "3des, aes, blowfish, cast, idea" } alongside any custom algorithms the user (meaning the person who built the code) has added. For example the user may have disabled IDEA due to patent concerns, so cryptlib wouldn't advertise that as available, or may have enabled some other algorithm of their choice which isn't one of the built-in defaults. Out of the box though it's the above five, that's all of the mainstream ciphers covered. (Hmm, I just saw RC4 buried down under Serpent there, I could switch that on as well now that I've noticed it's in the list :-). >Or will it enforce that the *input* to the selection processing is symmetric, >i.e. that in the KEXINIT message, > > encryption_algorithms_client_to_server > == encryption_algorithms_server_to_client > > mac_algorithms_client_to_server > == mac_algorithms_server_to_client That's what I do, and from the error message I got when I accidentally didn't do it, at least one other implementation does that too. >If we really want to get rid of this possibility, the cleanest and least >confusing way of doing it would be to define protocol version 2.1 with a >changed KEXINIT format, I don't really know if such a big change is necessary, just discouraging the use of asymmetric choices (which shouldn't be hard given that nothing (?) does it at the moment, so any attempt to implement it will fail to interop) should be enough. No need to break things. >I'm always confused when a spec allows flexibility which, for good or bad and >perhaps undocumented reasons, noone implements. I guess I've been polluted by too long with PKIX RFCs, there are so many MUSTs in there that you need to ignore in order to get things to work it's scary. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 10:58:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11373 for ; Sat, 15 Nov 2003 10:58:05 -0500 (EST) Received: (qmail 3904 invoked by uid 605); 15 Nov 2003 15:58:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3897 invoked from network); 15 Nov 2003 15:58:09 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Nov 2003 15:58:09 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAFFw2Ph006517; Sat, 15 Nov 2003 08:58:03 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAFFw2Ir019984; Sat, 15 Nov 2003 10:58:02 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAFFvwS4001883; Sat, 15 Nov 2003 10:58:02 -0500 (EST) Message-Id: <200311151558.hAFFvwS4001883@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: nisse@lysator.liu.se, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. In-Reply-To: Your message of "Sun, 16 Nov 2003 00:24:54 +1300." <200311151124.hAFBOsp10319@cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Sat, 15 Nov 2003 10:57:58 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > >If we really want to get rid of this possibility, the cleanest and least > >confusing way of doing it would be to define protocol version 2.1 with a > >changed KEXINIT format, > > I don't really know if such a big change is necessary, just > discouraging the use of asymmetric choices (which shouldn't be hard > given that nothing (?) does it at the moment, so any attempt to > implement it will fail to interop) should be enough. No need to > break things. The proposal during the WG session was that we should add text so that for both algorithms and language tags, the negotiated value SHOULD be the same in both directions. I'll send a more precise recommended edit in the next day or two.. Note the RFC2119 definition of SHOULD: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Note that this is somewhat stronger than the plain-english meaning of SHOULD. Given the current state of the documents (near approval by the IESG), I'm extremely reluctant to make a larger change at this point. We can revisit this issue when we move beyond Proposed Standard. (The process for advancement to Draft Standard requires that we document that all of the protocol features interoperate. if nobody has actually implemented asymmetric algorithms, we can strike it at that point). - Bill P.S., There are certainly a few obscure applications where it makes sense to use different algorithms in each direction. One which comes to mind is the case of a remote sensor/space probe/etc., where the "uplink" is low data-rate management/control traffic, where strong integrity protection is required to prevent the probe from being hijacked, and the "downlink" is a higher-volume, lower-value data stream, where weak integrity protection may be sufficient. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:13:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11680 for ; Sat, 15 Nov 2003 11:13:04 -0500 (EST) Received: (qmail 11210 invoked by uid 605); 15 Nov 2003 16:13:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11203 invoked from network); 15 Nov 2003 16:13:12 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 15 Nov 2003 16:13:12 -0000 Received: from localhost.arcor.net (dsl-082-082-054-103.arcor-ip.net [82.82.54.103]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 9BB75168B6F; Sat, 15 Nov 2003 17:13:10 +0100 (CET) Received: by localhost.arcor.net (Postfix, from userid 31451) id A8DD42D003; Sat, 15 Nov 2003 17:13:06 +0100 (CET) Date: Sat, 15 Nov 2003 17:13:06 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Peter Gutmann , sommerfeld@east.sun.com, housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031115161306.GA18731@folly> References: <200311150618.hAF6IrV08457@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit On Sat, Nov 15, 2003 at 11:40:53AM +0100, Niels Möller wrote: > The details must be spelled out. If we really want to get rid of this > possibility, the cleanest and least confusing way of doing it would be > to define protocol version 2.1 with a changed KEXINIT format, i don't think it makes sense to switch to a new protocol version because of this minor issue. it makes only sense if you don't have to care about interoperability. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:14:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11710 for ; Sat, 15 Nov 2003 11:14:16 -0500 (EST) Received: (qmail 8449 invoked by uid 605); 15 Nov 2003 16:07:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8419 invoked from network); 15 Nov 2003 16:07:46 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 15 Nov 2003 16:07:46 -0000 Received: from localhost.arcor.net (dsl-082-082-054-103.arcor-ip.net [82.82.54.103]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 69DC8150783; Sat, 15 Nov 2003 17:07:45 +0100 (CET) Received: by localhost.arcor.net (Postfix, from userid 31451) id 470812D003; Sat, 15 Nov 2003 17:07:41 +0100 (CET) Date: Sat, 15 Nov 2003 17:07:40 +0100 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: Comments on DH-GEX draft Message-ID: <20031115160740.GA5706@folly> References: <200311150711.hAF7Bj208612@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311150711.hAF7Bj208612@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Nov 15, 2003 at 08:11:45PM +1300, Peter Gutmann wrote: > There are two main problem areas, the first is the new-format message (I'll > call it new-gex here) using { min, preferred, max } rather than the original > { preferred } format (I'll call it gex). This looks like it's been bolted on this has been changed to make sure the server does not return a group that is too large for the client. some implementations had problems before this change. > recently without updating the rest of the text, which still describes the > behaviour for gex. In fact I couldn't actually find a server that would > accept the new-gex format, only the old gex one (they just rejected requests > with the new-gex message). funny, only very very old openssh implementations lack support for 'new-gex' From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:17:42 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11810 for ; Sat, 15 Nov 2003 11:17:41 -0500 (EST) Received: (qmail 13531 invoked by uid 605); 15 Nov 2003 16:17:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13524 invoked from network); 15 Nov 2003 16:17:50 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 15 Nov 2003 16:17:50 -0000 Received: from localhost.arcor.net (dsl-082-082-054-103.arcor-ip.net [82.82.54.103]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 2B20B168BB5; Sat, 15 Nov 2003 17:17:49 +0100 (CET) Received: by localhost.arcor.net (Postfix, from userid 31451) id 312402D003; Sat, 15 Nov 2003 17:17:45 +0100 (CET) Date: Sat, 15 Nov 2003 17:17:45 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org, Russ Housley Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031115161745.GB18731@folly> References: <200311100712.hAA7CAS4004431@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311100712.hAA7CAS4004431@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Nov 10, 2003 at 02:12:10AM -0500, Bill Sommerfeld wrote: > immediately after this text: > > The ciphers in each direction MUST run independently of each other, > and implementations MUST allow independently choosing the algorithm > for each direction (if multiple algorithms are allowed by local > policy. > > insert: > > Note that there is no security advantage to using different > algorithms in each direction; implementations SHOULD use the same > algorithm in both directions when allowed by policy. In IPsec the algorithms are unidirectional. Why should it be a SHOULD for SSH? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:27:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11986 for ; Sat, 15 Nov 2003 11:27:10 -0500 (EST) Received: (qmail 17831 invoked by uid 605); 15 Nov 2003 16:27:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17824 invoked from network); 15 Nov 2003 16:27:19 -0000 Received: from mail-in-02.arcor-online.net (151.189.21.42) by mail.netbsd.org with SMTP; 15 Nov 2003 16:27:19 -0000 Received: from localhost.arcor.net (dsl-082-082-054-103.arcor-ip.net [82.82.54.103]) by mail-in-02.arcor-online.net (Postfix) with ESMTP id 00CCE168D08; Sat, 15 Nov 2003 17:27:18 +0100 (CET) Received: by localhost.arcor.net (Postfix, from userid 31451) id DCA0B2D003; Sat, 15 Nov 2003 17:27:13 +0100 (CET) Date: Sat, 15 Nov 2003 17:27:13 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Peter Gutmann , nisse@lysator.liu.se, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031115162713.GA18330@folly> References: <200311151124.hAFBOsp10319@cs.auckland.ac.nz> <200311151558.hAFFvwS4001883@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311151558.hAFFvwS4001883@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Nov 15, 2003 at 10:57:58AM -0500, Bill Sommerfeld wrote: > Note that this is somewhat stronger than the plain-english meaning of > SHOULD. > > Given the current state of the documents (near approval by the IESG), > I'm extremely reluctant to make a larger change at this point. I don't like the idea of changing anything at this point. The documents have been around for years and if this issue is was important then someone whould have complained before. (I even think that allowing asymmetric algorithms leeds to better implementations, because they have to be more careful.) > We can revisit this issue when we move beyond Proposed Standard. > > (The process for advancement to Draft Standard requires that we > document that all of the protocol features interoperate. if nobody > has actually implemented asymmetric algorithms, we can strike it at > that point). OpenSSH might support this. > P.S., There are certainly a few obscure applications where it makes > sense to use different algorithms in each direction. One which comes > to mind is the case of a remote sensor/space probe/etc., where the > "uplink" is low data-rate management/control traffic, where strong > integrity protection is required to prevent the probe from being > hijacked, and the "downlink" is a higher-volume, lower-value data > stream, where weak integrity protection may be sufficient. Well, you could also send the request, rekey with different algorithms, send the reply, rekey again, ... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:37:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12289 for ; Sat, 15 Nov 2003 11:37:14 -0500 (EST) Received: (qmail 23152 invoked by uid 605); 15 Nov 2003 16:37:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23145 invoked from network); 15 Nov 2003 16:37:23 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Nov 2003 16:37:23 -0000 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 hAFGbDUP005003; Sat, 15 Nov 2003 08:37:13 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAFGbDbx015232; Sat, 15 Nov 2003 11:37:13 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAFGbCS4002056; Sat, 15 Nov 2003 11:37:13 -0500 (EST) Message-Id: <200311151637.hAFGbCS4002056@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: ietf-ssh@NetBSD.org Subject: WG chair comments on late comments In-Reply-To: Your message of "Sat, 15 Nov 2003 20:11:45 +1300." <200311150711.hAF7Bj208612@cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Sat, 15 Nov 2003 11:37:12 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I've been meaning to send these in for awhile, seeing the latest draft (which > adds the changed-format request message) finally motivated me to type up the > comments I had. A note on timeliness. It does nobody any good when WG participants keep their thoughts to themselves. Unfortunately, these comments are no longer particularly timely. This document has been a working group item for several years. The most recent version was published in July, 2003 On July 24th of this year, I sent a message saying, in part: This message marks the start of a two week WORKING GROUP LAST CALL on Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol draft-ietf-secsh-dh-group-exchange-04.txt prior to review by the IETF and IESG for publication as a Proposed Standard. Please send comments to ietf-ssh@netbsd.org by August 8th, 2003. While clearing the backlog of email prior to the past week's IETF meeting, I realized that I had dropped the ball here -- the WG last call had timed out and that I hadn't forwarded the document on to the IESG; I passed it up on November 9th and it's now in the AD's hands.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:45:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12448 for ; Sat, 15 Nov 2003 11:45:02 -0500 (EST) Received: (qmail 27706 invoked by uid 605); 15 Nov 2003 16:45:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27699 invoked from network); 15 Nov 2003 16:45:12 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Nov 2003 16:45:12 -0000 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 hAFGjAUP006018; Sat, 15 Nov 2003 08:45:10 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAFGj9Ir025336; Sat, 15 Nov 2003 11:45:09 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAFGj9S4002099; Sat, 15 Nov 2003 11:45:09 -0500 (EST) Message-Id: <200311151645.hAFGj9S4002099@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: ietf-ssh@NetBSD.org Subject: Re: Comments on DH-GEX draft In-Reply-To: Your message of "Sat, 15 Nov 2003 20:11:45 +1300." <200311150711.hAF7Bj208612@cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Sat, 15 Nov 2003 11:45:09 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > In any case, the new-gex format is at best completely redundant and at > worst misleading, since the message format implies some sort of choice while > the text says the server can do anything it feels like: > > Servers and clients SHOULD support groups with a modulus > length of k bits, where 1024 <= k <= 8192. The recommended > values for min and max are 1024 and 8192 respectively. > > which is synonymous with "you can use any (safe) key size you feel > like". No, this is a recommendation on implementation capability, not a recommendation to ignore the client's min and max values. Page 3 says: 1. C sends "min || n || max" to S, indicating the minimal accept- able group size, the preferred size of the group and the maxi- mal group size in bits the client will accept. 2. S finds a group that best matches the client's request, and sends "p || g" to C. Would you like a clarification here? The group selected MUST be within the bounds preferred by the client; if no such group is available, the server should fail this key exchange, allowing a fallback to a secondary key exchange. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:52:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12711 for ; Sat, 15 Nov 2003 11:52:39 -0500 (EST) Received: (qmail 2702 invoked by uid 605); 15 Nov 2003 16:52:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2669 invoked from network); 15 Nov 2003 16:52:47 -0000 Received: from stout.hampshire.edu (192.33.12.80) by mail.netbsd.org with SMTP; 15 Nov 2003 16:52:47 -0000 Received: from dhcpbg22.hampshire.edu (dhcpbg22.hampshire.edu [172.20.27.22]) by stout.hampshire.edu (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAFGqh0o006648 for ; Sat, 15 Nov 2003 11:52:43 -0500 Subject: Re: additional core draft nits in need of WG attention. From: Paul Swartz To: Ietf-SSH In-Reply-To: <20031115162713.GA18330@folly> References: <200311151124.hAFBOsp10319@cs.auckland.ac.nz> <200311151558.hAFFvwS4001883@thunk.east.sun.com> <20031115162713.GA18330@folly> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-InDtCTN0axTz5+SRQeUs" Message-Id: <1068915000.14856.5.camel@petra> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 15 Nov 2003 11:50:00 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --=-InDtCTN0axTz5+SRQeUs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2003-11-15 at 11:27, Markus Friedl wrote: > On Sat, Nov 15, 2003 at 10:57:58AM -0500, Bill Sommerfeld wrote: > > (The process for advancement to Draft Standard requires that we > > document that all of the protocol features interoperate. if nobody > > has actually implemented asymmetric algorithms, we can strike it at > > that point). >=20 > OpenSSH might support this. I know Conch does support this. > > P.S., There are certainly a few obscure applications where it makes > > sense to use different algorithms in each direction. One which comes > > to mind is the case of a remote sensor/space probe/etc., where the > > "uplink" is low data-rate management/control traffic, where strong > > integrity protection is required to prevent the probe from being > > hijacked, and the "downlink" is a higher-volume, lower-value data > > stream, where weak integrity protection may be sufficient. >=20 > Well, you could also send the request, rekey with different > algorithms, send the reply, rekey again, ... ...because renegotiating keys is more efficient than using assymetric ciphers... -p --=20 Paul Swartz (o_ z3p at twistedmatrix dot com //\ http://www.twistedmatrix.com/users/z3p.twistd/ V_/_ AIM: Z3Penguin --=-InDtCTN0axTz5+SRQeUs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/tlk30Lhe9RiJonARAqsyAJ0XLZoAtnwIPF9i9U5R1YS5nsvpKQCdH34H j/8Y66jdt7MUMsfkN6GafIM= =F48v -----END PGP SIGNATURE----- --=-InDtCTN0axTz5+SRQeUs-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 15 11:55:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12749 for ; Sat, 15 Nov 2003 11:55:05 -0500 (EST) Received: (qmail 4108 invoked by uid 605); 15 Nov 2003 16:55:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4100 invoked from network); 15 Nov 2003 16:55:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 15 Nov 2003 16:55:14 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 230EC23985; Sat, 15 Nov 2003 17:55:13 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B45CC1B677; Sat, 15 Nov 2003 17:55:10 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAFGtACM026003; Sat, 15 Nov 2003 17:55:10 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAFGt4sW025998; Sat, 15 Nov 2003 17:55:04 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 15 Nov 2003 17:55:03 +0100 In-Reply-To: <200311151558.hAFFvwS4001883@thunk.east.sun.com> Message-ID: Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > The proposal during the WG session was that we should add text so that > for both algorithms and language tags, Why language tags? I think assymmetric choices make a lot of sense: For example, sending Swedish messages from server to client (because that's the user's native and preferred language, but default language or English (because these messags will end up in the server log, and the sysadm doesn't read Swedish, or because the client doesn't implement any localization for messages it sends to the server). And furthermore, implementations that want to take the easy way can just send an empty language list and ignore whatever is received, so they gain no simplicity by the ban on assymmetric language lists. And what about compression? Should support for assymetric choices for compression be required? > the negotiated value SHOULD be the same in both directions. I think it's a lot better to say that the lists in the KEXINIT message, i.e. the *input* to the negotiation, SHOULD be the same for both directions. It makes no sense to say that implementations MUST go to the trouble[1] of performing independent algorithm selection for both directions, and then say that they are allowed, and even recommended, to sometimes refuse to use the result. The point of discouraging assymetric choices should be to make things simpler for the implementations. I'm still uneasy about this issue. I believe it is a *minor* trouble to implement assymetric choices. But since I have to admit that I don't implement any way for the user to configure assymmetric choices, and therefore haven't tested it at all, I can agree that it's not an essential feature. I think I'd prefer to keep the feature, and perhaps add some text that allows implementations to refuse to accept KEXINIT messages with assymetric algorithm lists for encryption and authentication. Something like The ciphers in each direction MUST run independently of each other, and implementations SHOULD/MAY allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). Implementations MAY choose to not support independent algorithm choices for the two directions. In this case it MUST check that encryption_algorithms_client_to_server == encryption_algorithms_server_to_client in all received SSH_MSG_KEXINIT messages. If the lists differ, the implementation MUST send a SSH_MSG_DISCONNECT message with reason code SSH_DISCONNECT_KEY_EXCHANGE_FAIL and a proper explanation. Implementations SHOULD send SSH_MSG_KEXINIT messages with encryption_algorithms_client_to_server == encryption_algorithms_server_to_client unless they have been explicitly configured to behave differently. and similarly for authentication methods, but *not* for language tags or compression algorithms. The essence of this is to (i) make support for assymmetric choices an optional feature, (ii) to specify how the protocol should work if the feature is not implemented, and finally, (iii) say that implementations shouldn't use the feature unless there's a good reason to use it, for example "the user said so". /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 16 05:25:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24691 for ; Sun, 16 Nov 2003 05:25:56 -0500 (EST) Received: (qmail 3364 invoked by uid 605); 16 Nov 2003 10:26:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3356 invoked from network); 16 Nov 2003 10:26:03 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 16 Nov 2003 10:26:03 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 6A55D1F29B9; Sun, 16 Nov 2003 11:25:55 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id CDA206CE2B; Sun, 16 Nov 2003 11:25:57 +0100 (MET) Date: Sun, 16 Nov 2003 10:48:48 +0100 (CET) From: maf@appgate.com Reply-To: maf@appgate.com Subject: Re: additional core draft nits in need of WG attention. To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20031116102557.CDA206CE2B@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 15 Nov, Bill Sommerfeld wrote: > (The process for advancement to Draft Standard requires that we > document that all of the protocol features interoperate. if nobody > has actually implemented asymmetric algorithms, we can strike it at > that point). Actually now that I think about it MindTerm does support asymmetric algorithms. I just tested it againt OpenSSH and it seems to work. I used different encryption algorithms, hash-algorithms and one direction used compression while the other did not. But I have no strong feelings on how we should treat this feature in the drafts. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 16 17:48:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09635 for ; Sun, 16 Nov 2003 17:48:49 -0500 (EST) Received: (qmail 5608 invoked by uid 605); 16 Nov 2003 22:48:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5601 invoked from network); 16 Nov 2003 22:48:52 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Nov 2003 22:48:52 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAGMmlPh017295; Sun, 16 Nov 2003 15:48:48 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAGMmlIr022231; Sun, 16 Nov 2003 17:48:47 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAGMmlS4008424; Sun, 16 Nov 2003 17:48:47 -0500 (EST) Message-Id: <200311162248.hAGMmlS4008424@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Salowey" Cc: ietf-ssh@NetBSD.org Subject: Re: FW: SCP/SFTP/SSH URI Format Draft Update In-Reply-To: Your message of "Tue, 11 Nov 2003 12:36:04 PST." <004b01c3a893$6dd23f20$88878182@amer.cisco.com> Reply-to: sommerfeld@sun.com Date: Sun, 16 Nov 2003 17:48:47 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [oops, you just sent in the draft. murphy's law in action..] [WG chair hat off] Nit: The URIs for SFTP and SCP are hierarcical URIs where each component I think you mean "hierarchical". Content: The fingerprint MAY be used to validate the authenticity of the host key if the URL was obtained from an authenticated source with its integrity protected. awkward wording. how about: The fingerprint MAY be used to validate the authenticity of the host key if the URL was obtained from a trusted source. Yes, "trusted" is overloaded. The text as written would disallow an embedded system from using the fingerprint part of a URI if it was, for example, burned into a boot image.. This one I'm taking issue with: There MUST be only one fingerprint parameter per host-key-alg for a given URL. I'm sure there's a good reason for this restriction, but I don't see it offhand. Seems like having multiple fingerprints would allow for graceful host-key rollover... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 16 20:05:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13776 for ; Sun, 16 Nov 2003 20:05:34 -0500 (EST) Received: (qmail 13872 invoked by uid 605); 17 Nov 2003 01:05:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13862 invoked from network); 17 Nov 2003 01:05:36 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 17 Nov 2003 01:05:36 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 48E3C63C18; Mon, 17 Nov 2003 14:05:35 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAH16KZ27434; Mon, 17 Nov 2003 14:06:20 +1300 Date: Mon, 17 Nov 2003 14:06:20 +1300 Message-Id: <200311170106.hAH16KZ27434@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus@openbsd.org Subject: Re: additional core draft nits in need of WG attention. Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list >In IPsec the algorithms are unidirectional. Why should it be a SHOULD for >SSH? In TLS the algorithms are bidirectional. Why should it not be a SHOULD for SSH? Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 01:57:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20593 for ; Mon, 17 Nov 2003 01:57:49 -0500 (EST) Received: (qmail 17585 invoked by uid 605); 17 Nov 2003 06:57:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17577 invoked from network); 17 Nov 2003 06:57:53 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Nov 2003 06:57:53 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hAH6vhUP010352; Sun, 16 Nov 2003 22:57:43 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAH6vg2o023147; Sun, 16 Nov 2003 23:57:43 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAH6rRYY013640; Mon, 17 Nov 2003 00:53:27 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id hAH6rQAK013639; Sun, 16 Nov 2003 22:53:26 -0800 (PST) Date: Sun, 16 Nov 2003 22:53:26 -0800 From: Nicolas Williams To: Niels =?unknown-8bit?Q?M=F6ller?= Cc: sommerfeld@east.sun.com, Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031117065323.GA13609@binky.central.sun.com> References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Nov 15, 2003 at 05:55:03PM +0100, Niels M?ller wrote: > Bill Sommerfeld writes: > > > The proposal during the WG session was that we should add text so that > > for both algorithms and language tags, > > Why language tags? I think assymmetric choices make a lot of sense: > For example, sending Swedish messages from server to client (because > that's the user's native and preferred language, but default language > or English (because these messags will end up in the server log, and > the sysadm doesn't read Swedish, or because the client doesn't > implement any localization for messages it sends to the server). Neither list of lang tags has anything to do with with logs on the server. The lists supposedly represent the languages that the client and server can have the user "speak at" the server and the languages that the client and server can "speak at" the user - the latter refers to L10N of server messages for the user and the former refers to, to what? to the language that the user is willing to answer prompts in??. (Logs just don't enter into this.) Now, why would I want to have the server localize messages for me in one language but accept, from me, answers to [yes/no, ...] prompts in some other language?? Is there an assumption that servers may have incomplete L10N support for certain languages? If so, still, why a second list of language tags? Or is there an assumption that users could be really tricky and prefer one language for reading and another for typing? Now, we humans do weird things, so I suppose this could be, but I'd like to see some examples. On Solaris, in any case, there isn't much we can do with this language assymetry, though one can play some games. E.g., client2server langs -> LC_CTYPE setting and server2client langs -> LC_MESSAGES setting. But really, is this worth it? > And furthermore, implementations that want to take the easy way can > just send an empty language list and ignore whatever is received, so > they gain no simplicity by the ban on assymmetric language lists. Some implementors don't have a choice and have to implement what G11N features the protocols provide due to regulations, internal or otherwise. Such implementors will gain something from at least a clarification on what the hell assymetric langtag negotiation really means. [...] > > the negotiated value SHOULD be the same in both directions. > > I think it's a lot better to say that the lists in the KEXINIT > message, i.e. the *input* to the negotiation, SHOULD be the same for > both directions. I agree with this. But if we find no theoretical use for assymetric langtag negotiation that we wish to support I would consent to deprecating one of the two langatg list fields. > It makes no sense to say that implementations MUST go to the > trouble[1] of performing independent algorithm selection for both > directions, and then say that they are allowed, and even recommended, > to sometimes refuse to use the result. The point of discouraging > assymetric choices should be to make things simpler for the > implementations. For langtag negotiation it may make sense to ignore the negotiation for one of the directions. See above. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 03:41:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05442 for ; Mon, 17 Nov 2003 03:41:15 -0500 (EST) Received: (qmail 13961 invoked by uid 605); 17 Nov 2003 08:41:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13954 invoked from network); 17 Nov 2003 08:41:14 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 17 Nov 2003 08:41:14 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id hAH8bLAU024807; Mon, 17 Nov 2003 10:37:22 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 142F02D003; Mon, 17 Nov 2003 09:37:17 +0100 (CET) Date: Mon, 17 Nov 2003 09:37:16 +0100 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <20031117083716.GA8430@folly> References: <200311170106.hAH16KZ27434@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311170106.hAH16KZ27434@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Nov 17, 2003 at 02:06:20PM +1300, Peter Gutmann wrote: > >In IPsec the algorithms are unidirectional. Why should it be a SHOULD for > >SSH? > > In TLS the algorithms are bidirectional. Why should it not be a SHOULD for > SSH? Why should the SSH spec be changed again and again? It's been like this for about 7 years. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 11:14:53 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18574 for ; Mon, 17 Nov 2003 11:14:52 -0500 (EST) Received: (qmail 18613 invoked by uid 605); 17 Nov 2003 16:14:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18606 invoked from network); 17 Nov 2003 16:14:51 -0000 Received: from h-62.96.220.212.host.de.colt.net (HELO exchange1.infoscreen.net) (62.96.220.212) by mail.netbsd.org with SMTP; 17 Nov 2003 16:14:51 -0000 Received: by EXCHANGE1 with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 17:13:51 +0100 Message-ID: From: Anetsberger To: "'ietf-ssh@netbsd.org'" Subject: sftp-server Date: Mon, 17 Nov 2003 17:13:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I'm trying to configure sshd to change the root-directory of ftp-users to their homedirectory. Is there anybody who can tell me how to do this? Stephan From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 13:21:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26920 for ; Mon, 17 Nov 2003 13:21:15 -0500 (EST) Received: (qmail 6996 invoked by uid 605); 17 Nov 2003 18:21:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6988 invoked from network); 17 Nov 2003 18:21:11 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Nov 2003 18:21:11 -0000 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 hAHIL15u004469; Mon, 17 Nov 2003 11:21:01 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAHIL0Ir001018; Mon, 17 Nov 2003 13:21:00 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAHIL0S4012211; Mon, 17 Nov 2003 13:21:00 -0500 (EST) Message-Id: <200311171821.hAHIL0S4012211@thunk.east.sun.com> From: Bill Sommerfeld To: Anetsberger cc: "'ietf-ssh@netbsd.org'" Subject: Re: sftp-server In-Reply-To: Your message of "Mon, 17 Nov 2003 17:13:46 +0100." Reply-to: sommerfeld@east.sun.com Date: Mon, 17 Nov 2003 13:21:00 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I'm trying to configure sshd to change the root-directory of > ftp-users to their homedirectory. Is there anybody who can tell me > how to do this? You've reached the IETF Secure Shell working group, which exists to standardize the ssh *protocol*. There are many different sshd's out there. Please contact the vendor/supplier/author of your particular sshd for support.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 14:00:31 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28441 for ; Mon, 17 Nov 2003 14:00:30 -0500 (EST) Received: (qmail 1173 invoked by uid 605); 17 Nov 2003 19:00:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1164 invoked from network); 17 Nov 2003 19:00:36 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 17 Nov 2003 19:00:36 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Nov 2003 11:08:27 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAHJ0LAt022879; Mon, 17 Nov 2003 11:00:22 -0800 (PST) Received: from jsaloweyw2k01 ([171.71.192.142]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 Nov 2003 11:05:26 -0800 From: "Joseph Salowey" To: Cc: Subject: RE: FW: SCP/SFTP/SSH URI Format Draft Update Date: Mon, 17 Nov 2003 11:00:20 -0800 Message-ID: <002d01c3ad3d$0cab2960$8ec047ab@amer.cisco.com> 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.4024 Importance: Normal In-Reply-To: <200311162248.hAGMmlS4008424@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 17 Nov 2003 19:05:27.0028 (UTC) FILETIME=[C2DB7B40:01C3AD3D] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > [oops, you just sent in the draft. murphy's law in action..] > > [WG chair hat off] > > Nit: > > The URIs for SFTP and SCP are hierarcical URIs where each > component > > I think you mean "hierarchical". > > Content: > > The fingerprint MAY be used to validate the > authenticity of the host key if the URL was obtained from an > authenticated source with its integrity protected. > > awkward wording. how about: > > The fingerprint MAY be used to validate the authenticity of the > host key if the URL was obtained from a trusted source. > > Yes, "trusted" is overloaded. The text as written would > disallow an embedded system from using the fingerprint part > of a URI if it was, for example, burned into a boot image.. > [Joe] OK, makes sense. > This one I'm taking issue with: > > There MUST be only one fingerprint parameter per host-key-alg for a > given URL. > > I'm sure there's a good reason for this restriction, but I > don't see it offhand. Seems like having multiple > fingerprints would allow for graceful host-key rollover... > [Joe] I'm not sure we had a good reason to limit it. At least I can't think of one now. Unless someone has an objection I think we can allow this. > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 16:07:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04755 for ; Mon, 17 Nov 2003 16:06:59 -0500 (EST) Received: (qmail 27069 invoked by uid 605); 17 Nov 2003 21:07:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27062 invoked from network); 17 Nov 2003 21:07:07 -0000 Received: from hcl-mtl.gw.mcgill.ca (HELO fs1.montreal.hcl.com) (132.216.79.2) by mail.netbsd.org with SMTP; 17 Nov 2003 21:07:07 -0000 Received: from mtlglenltp2 (mtlglen-ltp2.montreal.hcl.com [10.4.1.175]) by fs1.montreal.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WH01Y43S; Mon, 17 Nov 2003 16:06:45 -0500 From: "Glen Matthews" To: Subject: Clarification regarding x-authentication Date: Mon, 17 Nov 2003 16:10:15 -0500 Organization: Hummingbird Message-ID: <011b01c3ad4f$3280a860$af01040a@mtlglenltp2> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, this is a request for a clarification. I'm looking at section 4.3.1 in the connection protocol - the comment regarding Requesting X11 Forwarding is that: "It is recommended that the authentication cookie that is sent be a fake, random cookie, and that the cookie is checked and replaced by the real cookie when a connection request is received." who should check? The ssh client or the server? And should the ssh client delve into the first x11 protocol packet for the cookie? I see where it is, but is that how the authentication should be carried out? Glen Matthews Hummingbird From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 16:42:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07154 for ; Mon, 17 Nov 2003 16:42:38 -0500 (EST) Received: (qmail 19727 invoked by uid 605); 17 Nov 2003 21:42:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19720 invoked from network); 17 Nov 2003 21:42:46 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 17 Nov 2003 21:42:46 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 1F2724DDB; Mon, 17 Nov 2003 22:42:45 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 8B8171677; Mon, 17 Nov 2003 22:42:43 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAHLghCM026414; Mon, 17 Nov 2003 22:42:43 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAHLgZ8O026410; Mon, 17 Nov 2003 22:42:35 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "Glen Matthews" Cc: Subject: Re: Clarification regarding x-authentication References: <011b01c3ad4f$3280a860$af01040a@mtlglenltp2> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 17 Nov 2003 22:42:34 +0100 In-Reply-To: <011b01c3ad4f$3280a860$af01040a@mtlglenltp2> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit "Glen Matthews" writes: > who should check? The ssh client or the server? 1. If the ssh client creates the fake cookie and includes it in the "x11-req" message, then the ssh client should dig into received X11 data and check that received cookies are correct. There are at least two other ways of doing it: 2. Sending the real cookie. Then neither the client nor the server need to look into the X11 datastream, as the real X server will check the cookie. 3. Sending an empty cookie in the "x11-req" message. Let the server create a fake cookie. For each X11 connection, the server digs into the x11 datastream to check and remove the cookie. The client will also dig into the X11 connection to insert the real cookie before connecting to the real X server. All ssh implementations I know of do (1). (2) is discouraged, for security reasons: One should never reveal the real cookie to remote machines. I think (3) is in some ways cleaner: ssh server and client have already authenticated each other, so the X11 authentication on the wire is redundant. But (3) has some drawbacks: * both server and client must dig into the X11 protocol. * since it's not specified what a server should do if it receives an empty cookie in the "x11-req", the client can't know if the server implementation will behave as described above, and generate a suitable random cookie that X clients must use. So the user is safer if the client implements (1). In more general terms, letting the server do the authentication is in a way making an (X11) client responsible for X11 server security, which is not good practice. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 18:47:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14278 for ; Mon, 17 Nov 2003 18:47:29 -0500 (EST) Received: (qmail 8871 invoked by uid 605); 17 Nov 2003 23:47:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8864 invoked from network); 17 Nov 2003 23:47:34 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 17 Nov 2003 23:47:34 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa23586; 17 Nov 2003 18:46 EST Date: Mon, 17 Nov 2003 18:46:51 -0500 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , sommerfeld@east.sun.com cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <42590000.1069112811@minbar.fac.cs.cmu.edu> In-Reply-To: References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> X-Mailer: Mulberry/3.0.3 (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 Saturday, November 15, 2003 17:55:03 +0100 Niels M=F6ller=20 wrote: > Bill Sommerfeld writes: >> the negotiated value SHOULD be the same in both directions. > > I think it's a lot better to say that the lists in the KEXINIT > message, i.e. the *input* to the negotiation, SHOULD be the same for > both directions. Actually, that was my interpretation of what was said during the working=20 group meeting. It seems to me that requiring or recommending that the=20 foo_client_to_server and foo_server_to_client fields of the KEXINIT message = contain the same list is the only sane way to describe this requirement. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 20:55:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18166 for ; Mon, 17 Nov 2003 20:55:28 -0500 (EST) Received: (qmail 15074 invoked by uid 605); 18 Nov 2003 01:55:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15067 invoked from network); 18 Nov 2003 01:55:35 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 18 Nov 2003 01:55:35 -0000 Received: from mindrot.org (120.195.20.10.dhcp.netstarnetworks.com [10.20.195.120] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id hAI1vwm21959; Tue, 18 Nov 2003 12:57:59 +1100 Message-ID: <3FB97BD8.1030905@mindrot.org> Date: Tue, 18 Nov 2003 12:54:32 +1100 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jeffrey Hutzelman CC: =?ISO-8859-1?Q?Niels_M=F6ller?= , sommerfeld@east.sun.com, Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> <42590000.1069112811@minbar.fac.cs.cmu.edu> In-Reply-To: <42590000.1069112811@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Jeffrey Hutzelman wrote: > On Saturday, November 15, 2003 17:55:03 +0100 Niels Möller > wrote: > > >>Bill Sommerfeld writes: > > >>>the negotiated value SHOULD be the same in both directions. >> >>I think it's a lot better to say that the lists in the KEXINIT >>message, i.e. the *input* to the negotiation, SHOULD be the same for >>both directions. > > > Actually, that was my interpretation of what was said during the working > group meeting. It seems to me that requiring or recommending that the > foo_client_to_server and foo_server_to_client fields of the KEXINIT message > contain the same list is the only sane way to describe this requirement. I don't agree. It is reasonable for a server to be willing to accept compressed data, but refuse to send it (decompression being generally less CPU intensive than compression). I.e. comp_c_to_s "zlib, none", comp_s_to_c "none" Likewise a server may be happy to encrypt data to clients with a less secure, but faster cipher whilst requiring that clients send their information (especially the auth transactions) with a stronger, slower cipher. An extreme case would be the use of the "none" cipher in the s->c direction (though OpenSSH doesn't support "none"). Bidirectional algorithms have been in the spec for years (without complaint) and are supported by a number of implementations. Why is it that these objections are always raised at the 11th hour? I don't think the draft should be changed. Implementors who don't like the idea of bidirectional algorithms are free to disallow them in their implementation. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 21:10:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18481 for ; Mon, 17 Nov 2003 21:10:23 -0500 (EST) Received: (qmail 23319 invoked by uid 605); 18 Nov 2003 02:10:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23311 invoked from network); 18 Nov 2003 02:10:30 -0000 Received: from test2.braingia.org (HELO netserver.braingia.org) (65.169.213.77) by mail.netbsd.org with SMTP; 18 Nov 2003 02:10:30 -0000 Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10]) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAI2AGkY005807 for ; Mon, 17 Nov 2003 20:10:17 -0600 Received: (from suehring@localhost) by netserver.braingia.org (8.12.3/8.12.3/Debian-6.6) id hAI2AB6n005784 for ietf-ssh@netbsd.org; Mon, 17 Nov 2003 20:10:11 -0600 Date: Mon, 17 Nov 2003 20:10:11 -0600 From: Steve Suehring To: ietf-ssh@NetBSD.org Subject: Re: FW: SCP/SFTP/SSH URI Format Draft Update Message-ID: <20031118021011.GA2665@mail.braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@netbsd.org References: <200311162248.hAGMmlS4008424@thunk.east.sun.com> <002d01c3ad3d$0cab2960$8ec047ab@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002d01c3ad3d$0cab2960$8ec047ab@amer.cisco.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Nov 17, 2003 at 11:00:20AM -0800, Joseph Salowey wrote: > > I'm sure there's a good reason for this restriction, but I > > don't see it offhand. Seems like having multiple > > fingerprints would allow for graceful host-key rollover... > > > [Joe] I'm not sure we had a good reason to limit it. At least I can't > think of one now. Unless someone has an objection I think we can allow > this. I've been racking my brain on this because I really thought there was a reason for the limitation. I can't find it in the archives so maybe I didn't share that thought. In any event, it seems as though the consensus is definitely for multiple fingerprints. Steve From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 21:17:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18672 for ; Mon, 17 Nov 2003 21:17:06 -0500 (EST) Received: (qmail 27805 invoked by uid 605); 18 Nov 2003 02:17:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27793 invoked from network); 18 Nov 2003 02:17:14 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 18 Nov 2003 02:17:14 -0000 Received: from mindrot.org (120.195.20.10.dhcp.netstarnetworks.com [10.20.195.120] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id hAI2KJm27812; Tue, 18 Nov 2003 13:20:19 +1100 Message-ID: <3FB98114.1010403@mindrot.org> Date: Tue, 18 Nov 2003 13:16:52 +1100 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: ietf-ssh@NetBSD.org CC: Jeffrey Hutzelman , =?ISO-8859-1?Q?Niels_M=F6ller?= , sommerfeld@east.sun.com, Peter Gutmann Subject: Re: additional core draft nits in need of WG attention. References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> <42590000.1069112811@minbar.fac.cs.cmu.edu> <3FB97BD8.1030905@mindrot.org> In-Reply-To: <3FB97BD8.1030905@mindrot.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > Bidirectional algorithms have been in the spec for years (without s/Bidirectional/assymetric/ if there is any ambuiguity. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 21:29:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18921 for ; Mon, 17 Nov 2003 21:29:12 -0500 (EST) Received: (qmail 4205 invoked by uid 605); 18 Nov 2003 02:29:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4198 invoked from network); 18 Nov 2003 02:29:21 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 18 Nov 2003 02:29:21 -0000 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 hAI2T5UP021020; Mon, 17 Nov 2003 18:29:06 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAI2T5Ir023196; Mon, 17 Nov 2003 21:29:05 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAI2T5S4015812; Mon, 17 Nov 2003 21:29:05 -0500 (EST) Message-Id: <200311180229.hAI2T5S4015812@thunk.east.sun.com> From: Bill Sommerfeld To: Damien Miller cc: ietf-ssh@NetBSD.org, Jeffrey Hutzelman , =?ISO-8859-1?Q?Niels_M=F6ller?= , Peter Gutmann Subject: Re: additional core draft nits in need of WG attention. In-Reply-To: Your message of "Tue, 18 Nov 2003 13:16:52 +1100." <3FB98114.1010403@mindrot.org> Reply-to: sommerfeld@east.sun.com Date: Mon, 17 Nov 2003 21:29:05 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > Bidirectional algorithms have been in the spec for years (without > > s/Bidirectional/assymetric/ if there is any ambuiguity. well, I've seen "assymetric algorithms" used to refer to public key algorithms... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 17 22:22:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20663 for ; Mon, 17 Nov 2003 22:22:41 -0500 (EST) Received: (qmail 6624 invoked by uid 605); 18 Nov 2003 03:22:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6617 invoked from network); 18 Nov 2003 03:22:48 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 18 Nov 2003 03:22:48 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 275E463C18; Tue, 18 Nov 2003 16:22:47 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAI3Nim03304; Tue, 18 Nov 2003 16:23:44 +1300 Date: Tue, 18 Nov 2003 16:23:44 +1300 Message-Id: <200311180323.hAI3Nim03304@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Comments on DH-GEX draft Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >Page 3 says: > > 1. C sends "min || n || max" to S, indicating the minimal accept- > able group size, the preferred size of the group and the maxi- > mal group size in bits the client will accept. > > 2. S finds a group that best matches the client's request, and > sends "p || g" to C. > >Would you like a clarification here? > > The group selected MUST be within the bounds preferred by the > client; if no such group is available, the server should > fail this key exchange, allowing a fallback to a secondary key > exchange. It would help. The problem is that at the moment the text has: > 1. C sends "min || n || max" to S, and: > The recommended > values for min and max are 1024 and 8192 respectively. which is the combination that I interpreted to mean "you can use any key size you feel like". In addition on the server side: > 2. S finds a group that best matches the client's request, the "best match" rules given in the text that follows the extract again allow the server to choose anything it feels like: > The server should return the smallest group it knows that is larger > than the size the client requested. If the server does not know a > group that is larger than the client request, then it SHOULD return > the largest group it knows. If the clarification is included, the matching text would need to be changed as well. As I mentioned in my original message, it looks like there are two lots of text there, one that applies to { min, n, max } and another that applies to { n }, which makes it rather confusing. Well, not necessarily confusing, but it allows an implementation to do almost anything and still claim to be compliant. Perhaps splitting it into two parts, one for when the client sends { n } and the other when it sends { min, n, max } would disambiguate it. (I realise it's too late now, but the real problem is that the client is expected to guess at a parameter that only the server knows, with the solution being that the server advise the client what to do in advance. Want me to throw together a one-page informational draft documenting the "xxx-1024-xxx,xxx-2048-xxx"-style algorithm options?). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 18 05:13:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12747 for ; Tue, 18 Nov 2003 05:13:20 -0500 (EST) Received: (qmail 2071 invoked by uid 605); 18 Nov 2003 10:13:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2064 invoked from network); 18 Nov 2003 10:13:24 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 18 Nov 2003 10:13:24 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 6A2001020C; Tue, 18 Nov 2003 11:13:22 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id B174C1616; Tue, 18 Nov 2003 11:13:19 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAIADJCM010896; Tue, 18 Nov 2003 11:13:19 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAIADDgd010891; Tue, 18 Nov 2003 11:13:13 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Jeffrey Hutzelman , sommerfeld@east.sun.com, Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <200311151558.hAFFvwS4001883@thunk.east.sun.com> <42590000.1069112811@minbar.fac.cs.cmu.edu> <3FB97BD8.1030905@mindrot.org> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 18 Nov 2003 11:13:13 +0100 In-Reply-To: <3FB97BD8.1030905@mindrot.org> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA, X_AUTH_WARNING autolearn=ham version=2.55-lysator_tokaimura_1.1 X-Spam-Checker-Version: SpamAssassin 2.55-lysator_tokaimura_1.1 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Damien Miller writes: > Implementors who don't like the idea of bidirectional algorithms are > free to disallow them in their implementation. I don't think this is correct. The only way an implementation can disallow assymetric choices of encryption algorithms, and at the same time be compliant to the current draft, is by never ever advertising algorithm lists with more than a single element. *If* you really want to allow implementations to drop support for assymetric algoririthm choices, then you need to change the spec. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 18 14:44:47 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09525 for ; Tue, 18 Nov 2003 14:44:46 -0500 (EST) Received: (qmail 23001 invoked by uid 605); 18 Nov 2003 19:44:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22994 invoked from network); 18 Nov 2003 19:44:50 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 18 Nov 2003 19:44:50 -0000 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 hAIJie5u027534; Tue, 18 Nov 2003 12:44:41 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAIJiebx013128; Tue, 18 Nov 2003 14:44:40 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAIJidS4019939; Tue, 18 Nov 2003 14:44:39 -0500 (EST) Message-Id: <200311181944.hAIJidS4019939@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: ietf-ssh@NetBSD.org Subject: Re: Comments on DH-GEX draft In-Reply-To: Your message of "Tue, 18 Nov 2003 16:23:44 +1300." <200311180323.hAI3Nim03304@cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Tue, 18 Nov 2003 14:44:39 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > (I realise it's too late now, but the real problem is that the client is > expected to guess at a parameter that only the server knows, with the > solution being that the server advise the client what to do in advance. Want > me to throw together a one-page informational draft documenting the > "xxx-1024-xxx,xxx-2048-xxx"-style algorithm options?). What sort of client-side policy do you have in mind other than "pick a group at least as large as X and less than Y"? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 18 15:05:51 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10702 for ; Tue, 18 Nov 2003 15:05:50 -0500 (EST) Received: (qmail 6354 invoked by uid 605); 18 Nov 2003 20:05:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6346 invoked from network); 18 Nov 2003 20:05:57 -0000 Received: from citi.umich.edu (141.211.133.111) by mail.netbsd.org with SMTP; 18 Nov 2003 20:05:57 -0000 Received: by citi.umich.edu (Postfix, from userid 104123) id 64BF3209A2; Tue, 18 Nov 2003 15:05:57 -0500 (EST) Date: Tue, 18 Nov 2003 15:05:57 -0500 From: Niels Provos To: Bill Sommerfeld Cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Comments on DH-GEX draft Message-ID: <20031118200557.GK25246@citi.citi.umich.edu> Mail-Followup-To: Bill Sommerfeld , Peter Gutmann , ietf-ssh@NetBSD.org References: <200311180323.hAI3Nim03304@cs.auckland.ac.nz> <200311181944.hAIJidS4019939@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311181944.hAIJidS4019939@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Nov 18, 2003 at 02:44:39PM -0500, Bill Sommerfeld wrote: > What sort of client-side policy do you have in mind other than "pick a > group at least as large as X and less than Y"? It seems that the issue might be the common misconception of an untrusted server. In the case of SSH, the server is fully trusted by the client. Niels. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 18 15:10:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11578 for ; Tue, 18 Nov 2003 15:10:14 -0500 (EST) Received: (qmail 9532 invoked by uid 605); 18 Nov 2003 20:10:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9525 invoked from network); 18 Nov 2003 20:10:21 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 18 Nov 2003 20:10:21 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11556; Tue, 18 Nov 2003 15:10:08 -0500 (EST) Message-Id: <200311182010.PAA11556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-01.txt Date: Tue, 18 Nov 2003 15:10:08 -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 : SCP/SFTP/SSH URI Format Author(s) : S. Suehring, J. Salowey Filename : draft-ietf-secsh-scp-sftp-ssh-uri-01.txt Pages : 7 Date : 2003-11-18 This document describes the Uniform Resource Identifiers used to locate resources for the SCP, SFTP, and SSH protocols. The document describes the generic syntax involved in URI definitions as well as specific definitions for each protocol. These specific definitions may include user credentials such as username and password and also may include other parameters such as fingerprint. In addition, security considerations and examples are also provided within this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-scp-sftp-ssh-uri-01.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-scp-sftp-ssh-uri-01.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: <2003-11-18124418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-scp-sftp-ssh-uri-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-scp-sftp-ssh-uri-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-18124418.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 19 23:42:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03252 for ; Wed, 19 Nov 2003 23:42:04 -0500 (EST) Received: (qmail 6686 invoked by uid 605); 20 Nov 2003 04:42:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6679 invoked from network); 20 Nov 2003 04:42:09 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 20 Nov 2003 04:42:09 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 56F7B63C2D; Thu, 20 Nov 2003 17:42:07 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAK4hQQ17806; Thu, 20 Nov 2003 17:43:26 +1300 Date: Thu, 20 Nov 2003 17:43:26 +1300 Message-Id: <200311200443.hAK4hQQ17806@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jon@siliconcircus.com Subject: Re: additional core draft nits in need of WG attention. Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jon Bright writes: >Peter Gutman didn't mail to say whether his implementation supports AES or >not (since his policy is to support as little as possible, Whatever gave you that impression? I support anything that (a) makes sense (for example supporting telnet options in a non-interactive, non-telnet app isn't very useful) and (b) isn't a potential security problem. In the case of AES I support it in the client (as a second choice after 3DES), but it's currently commented out in the server because the client gets to choose the algorithm, so even if the server advertises AES as its least-preferred choice the client always latches onto that (by specifying it as its most-preferred one) and the server has to use AES anyway. Once it passes the five-year test (five years from publication/release without serious weaknesses discovered) I'll uncomment it, and people who always want to use AES can always uncomment it themselves. Apart from that I do the stuff I described in an earlier message: { "whatever the user has enabled" union "3des, blowfish, cast, idea, rc4" } alongside any custom algorithms the user (meaning the person who built the code) has added. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 20 03:00:53 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA22988 for ; Thu, 20 Nov 2003 03:00:51 -0500 (EST) Received: (qmail 20267 invoked by uid 605); 20 Nov 2003 08:00:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20260 invoked from network); 20 Nov 2003 08:00:57 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 20 Nov 2003 08:00:57 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id DABDD63C19; Thu, 20 Nov 2003 21:00:55 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAK82HV18532; Thu, 20 Nov 2003 21:02:17 +1300 Date: Thu, 20 Nov 2003 21:02:17 +1300 Message-Id: <200311200802.hAK82HV18532@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Comments on DH-GEX draft Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >> (I realise it's too late now, but the real problem is that the client is >> expected to guess at a parameter that only the server knows, with the >> solution being that the server advise the client what to do in advance. Want >> me to throw together a one-page informational draft documenting the >> "xxx-1024-xxx,xxx-2048-xxx"-style algorithm options?). > >What sort of client-side policy do you have in mind other than "pick a group >at least as large as X and less than Y"? D'you mean in relation to the client seeing "xxx-1024-xxx,xxx-2048-xxx" from the server? The server's saying: I can definitely guarantee to provide you with keys of size X, Y, or Z. I cannot guarantee to provide you with a key of some other size if you ask for it. In other words it's "If you choose not to go with the server's recommendation then the server will give you the closest match based on the DH-GEX rules, which may not yield the key type you're after". It's fully backwards- compatible with the existing way of doing things, all the server is doing is allowing the client to make an informed decision, rather than requiring it to take pot-shots at an appropriate key size and either drop the connection and restart the handshake or have to make do with whatever it gets back. If there's no objections to this I can crank out a draft, it's only half a page of text (exluding boilerplate) and a handful of lines of code to change to implement it. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 20 13:45:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17981 for ; Thu, 20 Nov 2003 13:45:36 -0500 (EST) Received: (qmail 6553 invoked by uid 605); 20 Nov 2003 18:45:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6544 invoked from network); 20 Nov 2003 18:45:38 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 20 Nov 2003 18:45:38 -0000 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 hAKIjTxA011126; Thu, 20 Nov 2003 10:45:30 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAKIjTbx021821; Thu, 20 Nov 2003 13:45:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAKIjTS4007809; Thu, 20 Nov 2003 13:45:29 -0500 (EST) Message-Id: <200311201845.hAKIjTS4007809@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: ietf-ssh@NetBSD.org Subject: Re: Comments on DH-GEX draft In-Reply-To: Your message of "Thu, 20 Nov 2003 21:02:17 +1300." <200311200802.hAK82HV18532@cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Thu, 20 Nov 2003 13:45:29 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > D'you mean in relation to the client seeing "xxx-1024-xxx,xxx-2048-xxx" from > the server? No. What sort of client-side policy do you have in mind for which a lower and upper bound on group side is not sufficient? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 21 12:02:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22368 for ; Fri, 21 Nov 2003 12:02:28 -0500 (EST) Received: (qmail 16782 invoked by uid 605); 21 Nov 2003 17:02:31 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031121170231.16781.qmail@mail.netbsd.org> Received: (qmail 16762 invoked from network); 21 Nov 2003 17:02:28 -0000 Received: from unknown (HELO yahoo.com) (219.232.176.107) by mail.netbsd.org with SMTP; 21 Nov 2003 17:02:28 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Sat, 22 Nov 2003 01:02:29 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 21 12:03:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22403 for ; Fri, 21 Nov 2003 12:03:17 -0500 (EST) Received: (qmail 17542 invoked by uid 605); 21 Nov 2003 17:03:23 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031121170323.17541.qmail@mail.netbsd.org> Received: (qmail 17527 invoked from network); 21 Nov 2003 17:03:20 -0000 Received: from unknown (HELO hotmail.com) (219.232.176.107) by mail.netbsd.org with SMTP; 21 Nov 2003 17:03:20 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Sat, 22 Nov 2003 01:03:22 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 21 12:55:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24599 for ; Fri, 21 Nov 2003 12:55:14 -0500 (EST) Received: (qmail 19740 invoked by uid 605); 21 Nov 2003 17:55:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19733 invoked from network); 21 Nov 2003 17:55:20 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Nov 2003 17:55:20 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa31195; 21 Nov 2003 12:54 EST Date: Fri, 21 Nov 2003 12:54:42 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , nisse@lysator.liu.se, sommerfeld@east.sun.com cc: housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <665280000.1069437282@minbar.fac.cs.cmu.edu> In-Reply-To: <200311150622.hAF6Mxk08475@cs.auckland.ac.nz> References: <200311150622.hAF6Mxk08475@cs.auckland.ac.nz> 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 Saturday, November 15, 2003 19:22:59 +1300 Peter Gutmann wrote: > nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >> Bill Sommerfeld writes: >>> > > 10. Section 5, last paragraph. What is "implicit server >>> > > authentication?" The whole paragraph is unclear. >>> >>> Can someone provide some fill-in text? >> >> I think it refers to key exchange methods like the ones used in tls >> and ssh1, where one party chooses the session key and encrypts it >> using the other party's public RSA key. Then you must consider the >> remote end unauthenticated until you have verified that she knows the >> session key. > > Here's my tongue-in-cheek interpretation from a code comment: > > /* [...] > > The spec says that after a key exchange with implicit server > authentication, the client must wait for the server to send a service- > accept packet before continuing, however it never explains what > implicit (and, by extension, explicit) server authentication actually > is. We therefore define it to be "Something completely different from > what we're doing here", which means that we can send the two packets > together without having to wait for the server */ > > I read through the surrounding text and tried to figure out what the > point of this requirement was, couldn't really find any, and so came up > with the above interpretation, which works nicely :-). In an effort to come up with some clarifying text, I did some research on this, which seems to confirm what Niels said. Thanks to our friends at www.watersprings.org, I was able to look at the old versions of the draft. Back in 1997, the REQUIRED (and only) key exchange algorithm was double-encrypting-sha, and the paragraph in question looked like this: > One should note that server authentication in the double-encrypting key > exchange is implicit, and the client doesn't really know the identity of > the server until it receives a message from the server using the correct > MAC and encryption. This means that an attacker could fool the client > into using no encryption (if the client is willing to accept no > encryption), and the client might in some cases send sensitive data, > such as a password, before it notices that the server isn't responding > properly. For this reason, it is recommended that clients should not > accept "none" encryption unless explicitly requested by the user. > Alternatively, they should wait for the server's response to the service > request before sending anything else. In the next version (-02), the "Alternatively, they should" got changed to a MUST, but the language describing the circumstances under which this was required got gutted, largely because the required keyex had been changed to diffie-hellman (a precursor of diffie-hellman-group1-sha1), which no longer had the problem. Based on this, it seems clear that "implicit server authentication" in this context means authentication where the server's identity is proved only by its later ability to encrypt valid messages. This doesn't apply to the current diffie-hellman-group1-sha1 keyex, in which the server signs the exchange hash, and thus proves its identity and binds it to the algorithm negotiation and key exchange just completed. It seems clear that waiting until you received the first encrypted message from the server was desirable at the time with double-encrypting-sha, but it actually left a number of problems unsolved. The modern protocol is better in this respect, and any acceptable keyex protocol is ultimately going to have to tie the server's identity to the algorithm negotiation and key exchange. It also seems clear that the requirement was intended to ensure that the client know certain things about the server before proceeding, and NOT to allow servers to assume any particular behaviour. I'd be extremely surprised to find any interoperability problems caused by a failure of a client to correctly obey this requirement. Since the requirement is unlikely to have any effect on interoperability, and its original security purpose is no longer relevant, I propose dropping the requirement (and the paragraph under discussion) entirely. It may be desirable to introduce security considerations text indicating that to be secure, a key exchange algorithm MUST bind the server's identity to version and algorithm negotiation and to the key exchange itself. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 21 21:14:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16200 for ; Fri, 21 Nov 2003 21:14:05 -0500 (EST) Received: (qmail 2230 invoked by uid 605); 22 Nov 2003 02:14:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2217 invoked from network); 22 Nov 2003 02:14:03 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 22 Nov 2003 02:14:03 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 3EE7E63C22; Sat, 22 Nov 2003 15:14:02 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hAM2Ffd28812; Sat, 22 Nov 2003 15:15:41 +1300 Date: Sat, 22 Nov 2003 15:15:41 +1300 Message-Id: <200311220215.hAM2Ffd28812@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz, sommerfeld@east.sun.com Subject: Re: additional core draft nits in need of WG attention. Cc: housley@vigilsec.com, ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman writes: >Based on this, it seems clear that "implicit server authentication" in this >context means authentication where the server's identity is proved only by >its later ability to encrypt valid messages. This doesn't apply to the >current diffie-hellman-group1-sha1 keyex, in which the server signs the >exchange hash, and thus proves its identity and binds it to the algorithm >negotiation and key exchange just completed. Not necessarily. My less tongue-in-cheek guess at the meaning of the text was that the "implicit" stuff was intended to make the first post-handshake message (service or global request or whatever the client happened to send there) play the same role as the Finished message in SSL, where the client and server do a mutual proof-of-possession of encryption and MAC keys via a pipeline-stalling message that prevents any further (sensitive) data from being exchanged until the PoP has concluded (the SSL Finished also authenticates the handshake messages). The signed exchange hash merely proves to the client that the server knows the master secret, but not necessarily that the client and server share encryption and MAC keys. Without this mutual PoP, the client could end up sending passwords to the server using an incorrect (and potentially weak) key if it's messed up something and derived the key incorrectly. Because there's no rationale included in the spec, I don't know if the need for mutual PoP was an SSH design requirement or not. If not then the current wording would be fine. If it is, then it'd have to be changed to make the PoP step explicit (which I guess would affect existing implementations). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 21 22:50:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17906 for ; Fri, 21 Nov 2003 22:50:29 -0500 (EST) Received: (qmail 29333 invoked by uid 605); 22 Nov 2003 03:50:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29326 invoked from network); 22 Nov 2003 03:50:38 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 22 Nov 2003 03:50:38 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa02534; 21 Nov 2003 22:50 EST Date: Fri, 21 Nov 2003 22:50:17 -0500 From: Jeffrey Hutzelman To: Peter Gutmann , nisse@lysator.liu.se, sommerfeld@east.sun.com cc: housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. Message-ID: <727240000.1069473017@minbar.fac.cs.cmu.edu> In-Reply-To: <200311220215.hAM2Ffd28812@cs.auckland.ac.nz> References: <200311220215.hAM2Ffd28812@cs.auckland.ac.nz> 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 Saturday, November 22, 2003 15:15:41 +1300 Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >> Based on this, it seems clear that "implicit server authentication" in >> this context means authentication where the server's identity is proved >> only by its later ability to encrypt valid messages. This doesn't apply >> to the current diffie-hellman-group1-sha1 keyex, in which the server >> signs the exchange hash, and thus proves its identity and binds it to >> the algorithm negotiation and key exchange just completed. > > Not necessarily. My less tongue-in-cheek guess at the meaning of the > text was that the "implicit" stuff was intended to make the first > post-handshake message (service or global request or whatever the client > happened to send there) play the same role as the Finished message in > SSL, where the client and server do a mutual proof-of-possession of > encryption and MAC keys via a pipeline-stalling message that prevents any > further (sensitive) data from being exchanged until the PoP has concluded > (the SSL Finished also authenticates the handshake messages). The signed > exchange hash merely proves to the client that the server knows the > master secret, but not necessarily that the client and server share > encryption and MAC keys. Without this mutual PoP, the client could end > up sending passwords to the server using an incorrect (and potentially > weak) key if it's messed up something and derived the key incorrectly. > > Because there's no rationale included in the spec, I don't know if the > need for mutual PoP was an SSH design requirement or not. If not then > the current wording would be fine. If it is, then it'd have to be > changed to make the PoP step explicit (which I guess would affect > existing implementations). At this point in the SSH protocol, we really only care about the server proving things to the client. The client gets a chance to prove its identity, and authenticate the algorithm negotiation and key exchange, during user authentication, which happens only after key exchange is complete. If proof of possession of the derived keys was a design goal, the protocol as it exists today already does not meet the goal, since there is obviously _some_ case in which the requirement is not meant to apply (otherwise it wouldn't be conditional!). I would think that if this was a goal, it would have been called out by an explicit pipeline-stall, in the form of a pair of messages which behave like SSH_NEWKEYS (before you can proceed, you MUST both send your message and receive your peer's). Finally, note that in diffie-hellman-group1-sha1, the version and algorithm negotation as well as the key exchange itself (together, the equivalent of the TLS handshake) are authenticated by the signature at the end of the key exchange. I believe it is clear from the original text and from the nature of the change that the requirement at that time WAS intended to apply to double-encrypting-sha1, and WAS NOT intended to apply to diffie-hellman. I believe we can make any decision we want about how clients have to behave wrt this requirement, and it won't affect interoperability with existing servers or have any implementation effect on servers -- there is no way a server can observe whether the client waited, so I can't see any way for a client's behaviour in this regard to affect interoperability. That said, I don't think there is any good security reason to require this behaviour with any well-behaved mechanism, and doing so will certainly render some mechanisms noncompliant, apparently including yours. It may be easy to fix, but what is the justification for making people do so? -- Jeff PS: In researching this, I had reason to go over section 5.3, which defines the various encryption algorithms. It contains the following text, which I believe may be inconsistent with RFC2026: > RC4 is a registered trademark of RSA Data Security Inc. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 23 23:29:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10936 for ; Sun, 23 Nov 2003 23:29:12 -0500 (EST) Received: (qmail 27030 invoked by uid 605); 24 Nov 2003 04:29:16 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031124042916.27029.qmail@mail.netbsd.org> Received: (qmail 27022 invoked from network); 24 Nov 2003 04:29:14 -0000 Received: from unknown (HELO 21cn.com) (219.232.176.93) by mail.netbsd.org with SMTP; 24 Nov 2003 04:29:14 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Mon, 24 Nov 2003 12:29:20 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 23 23:29:45 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10962 for ; Sun, 23 Nov 2003 23:29:44 -0500 (EST) Received: (qmail 27694 invoked by uid 605); 24 Nov 2003 04:29:47 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031124042947.27693.qmail@mail.netbsd.org> Received: (qmail 27687 invoked from network); 24 Nov 2003 04:29:45 -0000 Received: from unknown (HELO tom.com) (219.232.176.93) by mail.netbsd.org with SMTP; 24 Nov 2003 04:29:45 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Mon, 24 Nov 2003 12:29:51 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 24 10:59:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14022 for ; Mon, 24 Nov 2003 10:59:26 -0500 (EST) Received: (qmail 16716 invoked by uid 605); 24 Nov 2003 15:59:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16709 invoked from network); 24 Nov 2003 15:59:29 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 24 Nov 2003 15:59:29 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 2515056; Mon, 24 Nov 2003 08:59:27 -0700 Message-ID: <3FC22B09.4020604@vandyke.com> Date: Mon, 24 Nov 2003 09:00:09 -0700 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031119 Thunderbird/0.4a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Peter Gutmann , nisse@lysator.liu.se, sommerfeld@east.sun.com, housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Re: additional core draft nits in need of WG attention. References: <200311220215.hAM2Ffd28812@cs.auckland.ac.nz> <727240000.1069473017@minbar.fac.cs.cmu.edu> In-Reply-To: <727240000.1069473017@minbar.fac.cs.cmu.edu> 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 > If proof of possession of the derived keys was a design goal, the > protocol as it exists today already does not meet the goal, since there > is obviously _some_ case in which the requirement is not meant to apply > (otherwise it wouldn't be conditional!). I would think that if this was > a goal, it would have been called out by an explicit pipeline-stall, in > the form of a pair of messages which behave like SSH_NEWKEYS (before you > can proceed, you MUST both send your message and receive your peer's). > Finally, note that in diffie-hellman-group1-sha1, the version and > algorithm negotation as well as the key exchange itself (together, the > equivalent of the TLS handshake) are authenticated by the signature at > the end of the key exchange. Note that in practice, we do have proof of possession, since in order to do anything, the client must successfully send a service request and the server must successfully respond. (There really isn't much that is useful that you can do with the transport layer alone.) The only case where you could run into trouble is if the client assumes it's service request was going to succeed and sent the first userauth packet at the same time. I would claim that doing this would violate at least the spirit of the protocol if not the letter. And if someone ever introduced a different service (which could easily be done in an extension draft or even using a proprietary @dns.domain extension) such a client would fail to interoperate or to fail in a gracefully manner. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 24 13:38:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20470 for ; Mon, 24 Nov 2003 13:38:20 -0500 (EST) Received: (qmail 12579 invoked by uid 605); 24 Nov 2003 18:38:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12571 invoked from network); 24 Nov 2003 18:38:20 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Nov 2003 18:38:20 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id A4190B6AE6; Mon, 24 Nov 2003 19:38:18 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 6B805B6C1C; Mon, 24 Nov 2003 19:38:15 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAOIcFCM006390; Mon, 24 Nov 2003 19:38:15 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAOIc5Nw006386; Mon, 24 Nov 2003 19:38:05 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: Jeffrey Hutzelman , Peter Gutmann , sommerfeld@east.sun.com, housley@vigilsec.com, ietf-ssh@NetBSD.org Subject: Implicit server authentication: Proposed clarification References: <200311220215.hAM2Ffd28812@cs.auckland.ac.nz> <727240000.1069473017@minbar.fac.cs.cmu.edu> <3FC22B09.4020604@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 24 Nov 2003 19:38:05 +0100 In-Reply-To: <3FC22B09.4020604@vandyke.com> Message-ID: Lines: 100 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60-lysator_fetto_1.1 (1.212-2003-09-23-exp) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > The only case where you could run into trouble is if the > client assumes it's service request was going to succeed > and sent the first userauth packet at the same time. I think clients are supposed to be able to do exactly that. Peter complained earlier about the chattyness of the userauth protocol, but it doesn't have to be chatty. The client can send a password or public userauth key + signature immediately after the SERVICE_REQUEST packet, perhaps in the same IP packet. That way, one can connect and login using a fairly small number of roundtrips, which I believe was one of the original design goals. > And if someone ever introduced a different service (which could > easily be done in an extension draft or even using a proprietary > @dns.domain extension) such a client would fail to interoperate or > to fail in a gracefully manner. Sorry, that's not how the protocol is specified. Section 9 in the transport draft says clearly If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect. A client will not get a second chance if the service request fails, because then the server MUST disconnect. [2] And I also think it's appropriate for a client to expect that if it sends a service request and a userauth request immediately after each other, and the server rejects the service request, then the userauth request will be ignored with no interesting side effects on the server. And that's why the "implicit server authentication" is dangerous, if ever implemented: If you end up in a situation where you share your session key with the attacker, but not with the server, then you can end up sending your password in a packet the attacker can read, and discover too late that you don't share a session key with the server. I think the simplest resolution of this issue is to keep the current text, "Note that after a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data.", and clarify the definition of "implicit server authentication". So I propose the following change to the final paragraph of section 6, Key Exchange: Before: Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. After: A key exchange method uses "explicit server authentication" if the keyexchange messages include a signature or other proof of the server's authenticity. A key exchange method uses "implicit server authentication" if, in order to prove its autenticity, the server also has to prove that it knows the shared secret K, by sending a message and a corresponding MAC which the client can verify. [1] All currently defined key exchange methods use explicit server authentication. However, key exchange methods with implicit server authentication MAY be used with this protocol. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. I don't feel to strongly about this issue, and the proposal to just delete all text about implicit server authentication. But I don't think we really should start to strike out features from the protocol at this stage. So I hope the above clarification is good enough, or if not, that somebody else is willing to improve it shortly. Then we can put this issue at rest. [1] It seems like the server being able to decrypt and verify the client's SERVICE_REQUEST message might also be important. Perhaps one could end up with server and client sharing keys properly in the server->client direction, but not client->server. But I don't think this can happen, due to the way session keys are derived (section 6.2). A proof of knowledge of K should be sufficient for the client to establish the server's autenticity. If this verification succeeds, and the client still does not have the right keys for the client->server direction, then that's a serious security hole, but it's a hole somewhere in the keyexchange and session key generation, and I think it's fair to say that it's not server authentication in particular that is broken. [2] If you want to try several new fancy services, I think a more interoperable way to do that is to first ask for the userauth service, and then try several userauth requests with the "none" method and varying service names. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 24 17:11:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06164 for ; Mon, 24 Nov 2003 17:10:59 -0500 (EST) Received: (qmail 29154 invoked by uid 605); 24 Nov 2003 22:09:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29139 invoked from network); 24 Nov 2003 22:09:51 -0000 Received: from portal.hamachi.org (140.239.227.17) by mail.netbsd.org with SMTP; 24 Nov 2003 22:09:51 -0000 Received: from unknown.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 828041794D for ; Mon, 24 Nov 2003 17:09:48 -0500 (EST) Received: from unknown.hamachi.org (sommerfeld@localhost) by unknown.hamachi.org (8.12.5+Sun/8.8.8) with ESMTP id hAOGPSfZ010513 for ; Mon, 24 Nov 2003 11:25:28 -0500 (EST) Message-Id: <200311241625.hAOGPSfZ010513@unknown.hamachi.org> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: sftp message lost in the spam filter.. Reply-To: sommerfeld@NetBSD.org Date: Mon, 24 Nov 2003 11:25:28 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This got shuffled aside because of a malformed "To:" line.. sorry for the delay in forwarding this to the right place.. - Bill ------- Forwarded Message Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC213@lespaul.process.com> From: Richard Whalen To: Cc: ietf-ssh@NetBSD.org Subject: RE: Case sensitivity on sftp servers Date: Mon, 8 Sep 2003 08:36:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Dan O'Reilly [mailto:dano@process.com] > Sent: Sunday, September 07, 2003 10:43 PM > To: Martin Pool > Cc: ietf-ssh@NetBSD.org > Subject: Re: Case sensitivity on sftp servers > > > At 08:20 PM 9/7/2003, Martin Pool wrote: > >So with case sensitivity on > > > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > > > >in a directory containing "readme" ought to fail with > >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > > > OPEN("README", READ|CASE_SENSITIVE) > > > >in a directory containing "readme" ought to fail with NO_SUCH_FILE > >even on a case-insensitive filesystem? > > No, it wouldn't necessarily do so on VMS, which supports > multiple versions > of files. What Dan should have said was that it would not fail on VMS because on VMS ODS-2 volumes UPPERCASE is used to store filenames and they are case-insensitive, so "README", "readme", "ReadMe" (and lots of other variants) will all open the same file. VMS ODS-5 volumes are CASE_PRESERVITIVE, but not CASE_SENSITIVE. On VMS, it's the user's (process) decision as to whether or not files are treated in a case sensitive manner. - ---------------------- Richard Whalen Process Software ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 24 18:52:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11807 for ; Mon, 24 Nov 2003 18:52:28 -0500 (EST) Received: (qmail 2488 invoked by uid 605); 24 Nov 2003 23:52:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2481 invoked from network); 24 Nov 2003 23:52:38 -0000 Received: from sngrel4.hp.com (192.6.86.110) by mail.netbsd.org with SMTP; 24 Nov 2003 23:52:38 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel4.hp.com (Postfix) with SMTP id 2FCB811E for ; Tue, 25 Nov 2003 07:52:32 +0800 (SST) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 10:52:31 +1100 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XAB7K7AL; Tue, 25 Nov 2003 10:52:31 +1100 Received: from 16.176.65.49 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 10:52:31 +1100 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 1AOQTs-0001ha-00; Tue, 25 Nov 2003 10:51:00 +1100 Date: Tue, 25 Nov 2003 10:51:00 +1100 From: Martin Pool To: ietf-ssh@NetBSD.org Cc: Martin Pool Subject: Re: sftp message lost in the spam filter.. Message-ID: <20031124235010.GA6454@hp.com> References: <200311241625.hAOGPSfZ010513@unknown.hamachi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311241625.hAOGPSfZ010513@unknown.hamachi.org> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 24 Nov 2003, Bill Sommerfeld wrote: > From: Richard Whalen > Cc: ietf-ssh@NetBSD.org > Subject: RE: Case sensitivity on sftp servers > Date: Mon, 8 Sep 2003 08:36:42 -0400 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Content-Type: text/plain; > charset="iso-8859-1" > > > From: Dan O'Reilly [mailto:dano@process.com] > > Sent: Sunday, September 07, 2003 10:43 PM > > To: Martin Pool > > Cc: ietf-ssh@NetBSD.org > > Subject: Re: Case sensitivity on sftp servers > > > > > > At 08:20 PM 9/7/2003, Martin Pool wrote: > > >So with case sensitivity on > > > > > > OPEN("README", WRITE|CREAT|EXCL|CASE_INSENSITIVE) > > > > > >in a directory containing "readme" ought to fail with > > >FILE_ALREADY_EXISTS even on a case-sensitive filesystem, and > > > > > > OPEN("README", READ|CASE_SENSITIVE) > > > > > >in a directory containing "readme" ought to fail with NO_SUCH_FILE > > >even on a case-insensitive filesystem? > > > > No, it wouldn't necessarily do so on VMS, which supports > > multiple versions > > of files. > > What Dan should have said was that it would not fail on VMS because on VMS > ODS-2 volumes UPPERCASE is used to store filenames and they are > case-insensitive, so "README", "readme", "ReadMe" (and lots of other > variants) will all open the same file. > > VMS ODS-5 volumes are CASE_PRESERVITIVE, but not CASE_SENSITIVE. On VMS, > it's the user's (process) decision as to whether or not files are treated in > a case sensitive manner. This is moot because we seemed to decide that CASE_SENSITIVE and CASE_INSENSITIVE OPEN flags are not a good solution. (Of course it's good to have the message for completeness.) There seemed to be agreement on Joseph's proposal[0] of allowing the case-sensitivity of a particular directory to be discovered by reading its 'flags' attribute and looking at the SSH_FILEXFER_ATTR_FLAGS_CASE_INSENSITIVE bit. It makes good sense to treat case sensitivity as a read-only directory attribute because few servers will be able to choose what sensitivity they want. Case sensitivity is usually determined either by the filesystem or the OS, not for each individual filesystem operation. It also make sense for it to be a per-directory attribute because a single server may have both case-sensitive and case-insensitive volumes. Will that SSH_FILEXFER_ATTR_FLAGS proposal go into the standard? -- Martin linux.conf.au -- Adelaide, January 2004 [0] message 3F5CE482.5070500@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 24 19:20:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13155 for ; Mon, 24 Nov 2003 19:20:40 -0500 (EST) Received: (qmail 18523 invoked by uid 605); 25 Nov 2003 00:20:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18510 invoked from network); 25 Nov 2003 00:20:50 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 25 Nov 2003 00:20:50 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id 0104B3EC for ; Tue, 25 Nov 2003 08:20:49 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 11:20:40 +1100 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XAB7K8FM; Tue, 25 Nov 2003 11:20:40 +1100 Received: from 16.176.65.49 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 11:20:40 +1100 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 1AOQv8-0001mT-00; Tue, 25 Nov 2003 11:19:10 +1100 Date: Tue, 25 Nov 2003 11:19:10 +1100 From: Martin Pool To: Joseph Galbraith Cc: Derek Fawcus , ietf-ssh@NetBSD.org Subject: Re: A proposal for OPEN Message-ID: <20031125001909.GC6454@hp.com> References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> <3F5DF1B8.8010303@vandyke.com> <20030925021539.N7665@edinburgh.cisco.com> <3F73293B.3040704@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F73293B.3040704@vandyke.com> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 25 Sep 2003, Joseph Galbraith wrote: > I've heard these terms before, but I'm not sure I've had them > clearly defined for me before. Let me see if I'm anyplace close > on what they mean :-) > > Mandatory Lock > ============== > Once I am granted a mandatory lock, I own it until > I release it. Others trying to access the file in > a way that conflicts with my lock will receive an > error. > > Advisory Lock > ============= > Once I am granted an advisory lock, I own it until > either I release it or the server notifies me that > it is breaking my lock. Others trying to access the > file in a way that conflicts with my lock will result > in the server breaking my lock. This is closer to what is called an "opportunistic lock/oplock" in CIFS, or "reservation" in NFS4. Adding oplocks implies that the server must be able to initiate notifications to the client, and to discover and recover from network partitions or hung clients. It's quite complex. -- Martin linux.conf.au -- Adelaide, January 2004 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 25 11:51:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26670 for ; Tue, 25 Nov 2003 11:51:03 -0500 (EST) Received: (qmail 21859 invoked by uid 605); 25 Nov 2003 16:51:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21852 invoked from network); 25 Nov 2003 16:51:10 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 25 Nov 2003 16:51:10 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hAPGokxA012362; Tue, 25 Nov 2003 08:50:46 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id hAPGofo4029126; Tue, 25 Nov 2003 09:50:42 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id hAPGkKYY019237; Tue, 25 Nov 2003 10:46:20 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id hAPGkJ56019236; Tue, 25 Nov 2003 08:46:19 -0800 (PST) Date: Tue, 25 Nov 2003 08:46:19 -0800 From: Nicolas Williams To: Martin Pool Cc: Joseph Galbraith , Derek Fawcus , ietf-ssh@NetBSD.org Subject: Re: A proposal for OPEN Message-ID: <20031125164616.GA19228@binky.central.sun.com> References: <3F5D12CA.7030908@vandyke.com> <751432704.1063078896@mariner.pc.cs.cmu.edu> <3F5DF1B8.8010303@vandyke.com> <20030925021539.N7665@edinburgh.cisco.com> <3F73293B.3040704@vandyke.com> <20031125001909.GC6454@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031125001909.GC6454@hp.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Nov 25, 2003 at 11:19:10AM +1100, Martin Pool wrote: > This is closer to what is called an "opportunistic lock/oplock" in > CIFS, or "reservation" in NFS4. > > Adding oplocks implies that the server must be able to initiate > notifications to the client, and to discover and recover from network > partitions or hung clients. It's quite complex. It sure is. SFTP is not a remote filesystem protocol - oplocks/ delegations do not belong in sftp. OTOH, an optional OPEN option for requesting a guarantee that the file transferred won't be modified during the transfer might be nice. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 25 18:28:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17790 for ; Tue, 25 Nov 2003 18:28:41 -0500 (EST) Received: (qmail 1863 invoked by uid 605); 25 Nov 2003 23:28:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1851 invoked from network); 25 Nov 2003 23:28:42 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 25 Nov 2003 23:28:42 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1AOmbp-0007Jl-00; Tue, 25 Nov 2003 23:28:41 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org From: Ben Harris Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-01.txt In-Reply-To: <200311182010.PAA11556@ietf.org> References: <200311182010.PAA11556@ietf.org> Organization: Linux Unlimited Message-Id: Date: Tue, 25 Nov 2003 23:28:41 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200311182010.PAA11556@ietf.org> you write: >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 : SCP/SFTP/SSH URI Format > Author(s) : S. Suehring, J. Salowey > Filename : draft-ietf-secsh-scp-sftp-ssh-uri-01.txt A few comments: Reference 5 should be updated to draft-hoffman-rfc1738bis-01.txt. There's no reference for either the SFTP or SCP protocol definitions. The specification of SCP and SFTP URIs don't specify what to do with each of the hierarchical sections of an SCP or SFTP URI. The reference to rfc1738bis is insufficient, since that specifies that clients execute a "CWD" command for each component except the last, and neither SCP nor SFTP has such a command. The definition of "lineend" is poor, since '\r' and '\n' are C-isms, and in particular some C compilers treat '\n' as ASCII CR and '\r' as ASCII LF. This should probably just refer to the relevant part of the SFTP spec (which isn't referenced, so I can't find it). I believe that '\' isn't a permitted character in a URI, so specifying its use is silly. Perhaps the semantics of asking for an SFTP directory listing should be stated. There should be a quick sentence describing what each example means. The last example seems particularly odd, in that it's an SFTP URI with no filename. -- Ben Harris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 25 20:06:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20360 for ; Tue, 25 Nov 2003 20:06:34 -0500 (EST) Received: (qmail 5715 invoked by uid 605); 26 Nov 2003 01:06:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5706 invoked from network); 26 Nov 2003 01:06:39 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 26 Nov 2003 01:06:39 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 1AOo8b-0006Uf-00; Wed, 26 Nov 2003 01:06:37 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-01.txt In-Reply-To: <200311182010.PAA11556@ietf.org> References: <200311182010.PAA11556@ietf.org> Organization: Linux Unlimited Message-Id: Date: Wed, 26 Nov 2003 01:06:37 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <200311182010.PAA11556@ietf.org> you write: >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 : SCP/SFTP/SSH URI Format > Author(s) : S. Suehring, J. Salowey > Filename : draft-ietf-secsh-scp-sftp-ssh-uri-01.txt > Pages : 7 > Date : 2003-11-18 Another comment: The "conn-parameters" in the draft aren't allowed for by the server-based authority syntax described in section 3.2.2 of RFC 2396. I'd suggest souping up userinfo instead, since its internal syntax is left up to the scheme. -- Ben Harris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 26 00:23:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25678 for ; Wed, 26 Nov 2003 00:23:16 -0500 (EST) Received: (qmail 14632 invoked by uid 605); 26 Nov 2003 03:52:12 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031126035212.14631.qmail@mail.netbsd.org> Received: (qmail 14625 invoked from network); 26 Nov 2003 03:52:10 -0000 Received: from unknown (HELO tom.com) (219.232.176.111) by mail.netbsd.org with SMTP; 26 Nov 2003 03:52:10 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Wed, 26 Nov 2003 11:52:11 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 26 00:39:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26094 for ; Wed, 26 Nov 2003 00:39:16 -0500 (EST) Received: (qmail 15317 invoked by uid 605); 26 Nov 2003 03:52:49 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031126035249.15316.qmail@mail.netbsd.org> Received: (qmail 15310 invoked from network); 26 Nov 2003 03:52:47 -0000 Received: from unknown (HELO alibaba.com) (219.232.176.111) by mail.netbsd.org with SMTP; 26 Nov 2003 03:52:47 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Wed, 26 Nov 2003 11:52:48 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 27 10:53:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11171 for ; Thu, 27 Nov 2003 10:53:15 -0500 (EST) Received: (qmail 28574 invoked by uid 605); 27 Nov 2003 15:53:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28567 invoked from network); 27 Nov 2003 15:53:19 -0000 Received: from csmail.cs.auckland.ac.nz (HELO smtp.cs.auckland.ac.nz) (130.216.33.150) by mail.netbsd.org with SMTP; 27 Nov 2003 15:53:19 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 6E52863C4B; Fri, 28 Nov 2003 04:53:17 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hARFtvf08847; Fri, 28 Nov 2003 04:55:57 +1300 Date: Fri, 28 Nov 2003 04:55:57 +1300 Message-Id: <200311271555.hARFtvf08847@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: galb-list@vandyke.com, nisse@lysator.liu.se Subject: Re: Implicit server authentication: Proposed clarification Cc: housley@vigilsec.com, ietf-ssh@NetBSD.org, jhutz@cmu.edu, pgut001@cs.auckland.ac.nz, sommerfeld@east.sun.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >Peter complained earlier about the chattyness of the userauth protocol, but >it doesn't have to be chatty. The client can send a password or public >userauth key + signature immediately after the SERVICE_REQUEST packet, >perhaps in the same IP packet. That way, one can connect and login using a >fairly small number of roundtrips, which I believe was one of the original >design goals. That was my concern, you can save 1RTT by bundling the service request with the userauth, so you've already sent the password before you get a reply to the service request confirming the correct crypto/MAC keys. >So I propose the following change to the final paragraph of section 6, Key >Exchange: Looks good, it'll clear up the ambiguity in the current text. One small comment, it may be worth adding a note to the effect that "Clients concerned about potential exposure of sensitive data MAY choose to wait until they receive and verify the service-request response from the server to verify that client and server share the same encryption and MAC keys before sending further messages", not so much because it's a critical security item but to let readers know that the issue has been considered during the protocol design process and isn't regarded as a serious problem. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 29 20:28:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04625 for ; Sat, 29 Nov 2003 20:28:05 -0500 (EST) Received: (qmail 17164 invoked by uid 605); 30 Nov 2003 01:28:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17148 invoked from network); 30 Nov 2003 01:28:05 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 30 Nov 2003 01:28:05 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id UAA03199; Sat, 29 Nov 2003 20:28:04 -0500 (EST) From: der Mouse Message-Id: <200311300128.UAA03199@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. Date: Sat, 29 Nov 2003 05:40:25 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Problems with draft Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I find a few minor problems with the drafts. As far as I know I'm using the latest drafts (transport-17, dh-group-exchange-04, architecture-15). I've been digging into ssh, trying to actually understand it rather than just using it. To this end, I've been experimenting against a machine I set up for the purpose, writing bits of code and seeing how they work (or don't). One of the things this has involved is trying to code based on nothing but the drafts; I've used existing code only to figure out where the problem lies when my code turns out to not interoperate. In transport-17, section 6.2 writes of a "shared secret K", treating it as an opaque blob which is passed as part of a HASH argument. But section 7 writes of K as a large integer. It's not entirely clear how the one is converted into the other; looking at existing code, I find that the kex code treates it as a large integer (which will need fixing if-and-when key exchange methods that produce a K that's not conceptually a large integer, though that's an implementation matter rather than a spec matter), but when serializing it for hashing it uses the same code it uses for "mpint" serialization. I would like to see the draft clearly state exactly how the large integer K of section 7 is converted into the opaque blob K of section 6.2. The description of H's computation seems to imply that this should be done as the code does it, but it's not clearly stated. Also, section 7 writes The hash H is computed as the HASH hash of the concatenation of the following: [...] string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT [...] It is not clear whether these are compressed or uncompressed; while this doesn't matter for the first key exchange, it matters for re-exchange, and I'd like to see the draft state it clearly. transport-17 section 5.6 says The "ssh-rsa" key format has the following specific encoding: [...] Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. I have been unable to find any description of a signature algorithm for RSA in Schneier, and I have found no reference anywhere to explain what [PKCS1] is supposed to refer to - I assume this is as described in RFC2437? In dh-group-exchange-04, there's a typo: SSH_MSG_KEY_DH_GEX_REQUEST is used once where SSH_MSG_KEX_DH_GEX_REQUEST is (from the rest of the draft) clearly intended. (I wouldn't even have noticed this except that I cut-and-pasted fragments of the draft into my code.) /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 04:07:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26116 for ; Sun, 30 Nov 2003 04:07:34 -0500 (EST) Received: (qmail 26331 invoked by uid 605); 30 Nov 2003 09:07:42 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031130090742.26330.qmail@mail.netbsd.org> Received: (qmail 26241 invoked from network); 30 Nov 2003 09:07:33 -0000 Received: from unknown (HELO hotmail.com) (219.232.176.61) by mail.netbsd.org with SMTP; 30 Nov 2003 09:07:33 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Sun, 30 Nov 2003 17:07:45 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 04:08:02 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26152 for ; Sun, 30 Nov 2003 04:08:01 -0500 (EST) Received: (qmail 26945 invoked by uid 605); 30 Nov 2003 09:08:11 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20031130090811.26944.qmail@mail.netbsd.org> Received: (qmail 26938 invoked from network); 30 Nov 2003 09:08:09 -0000 Received: from unknown (HELO 126.com) (219.232.176.61) by mail.netbsd.org with SMTP; 30 Nov 2003 09:08:09 -0000 From: "cendd" Subject: Re: place internet call from your telephone line To: ietf-ssh@NetBSD.org Content-Type: multipart/mixed; boundary="=_NextPart_2rfkindysadvnqw3nerasdf";charset="GB2312" MIME-Version: 1.0 Reply-To: cendd@163.com Date: Sun, 30 Nov 2003 17:08:21 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.00.2615.200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain Content-Transfer-Encoding: 7bit Place internet call from your telephone line with low rate of $0.039/minute!? Detail here: http://www.wotec88.com --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: application/octet-stream; name="Yapjack connect.JPG" Content-Disposition: attachment; filename="Yapjack connect.JPG" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABEAa4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD309aT IzjvWddO8N5Md8h3R7o0DHBI7AdOf8ayNR1FtPbTol3JcXIZju6jcQefpxTEdRSbl3bcjPpmuT1L VpYvC11qMQkItLlopBIWYSRLLsLD1yvzZ/pWmsIGq3EKPtW4skMKjorKzBmHv8yfkKrldri5tTZY EqQOuKwZdWayFipLPLdllJY8bhgY9uvauG0f4upqF8mhQ2oXVXlaBXnf92rgnqByent9as3tzcjw Tc3N5MWu9H1F1nlQkbfm5b8mU0raDvqdlBriSWd/M8xRrOcwShkA2twAR7cgioL7V4tKvrqO/v4Y Va1jktvNcjc/zhhjuOE496ozRXNxbX+nJAGt7jS1uI7kJ8zzcglj3bhCO/FR2tzpWsWmjanfT6fJ Hb2zLci4IZgx244PfKn/ACab02EtTX0hk1fTLW/TBmjiYRHPAY8c/l+tN8I3tze6az3RbzVcqQRg jGOP51zMXiqx0zRNQhsRMZRK8lmAvyjuoPI4yOfrWh4e8Tf2pq0rw2Bs4ZOqddzd2OO5/pUjO4HW nUxTnBp9IYUUUjMqLuYgAdyaTaSuwForPk1NR/qk3D1NZlvr8txpyX0pjt42XfljwFzwckDqMH8a 8irnmEpuybl6L/hjeOHqSV0jo6K5uPxHFIyKl7Gxfdt4A+71zxwevX0PpVq21xZywjeKYLjdsPqA R+YINRHP8K3aSkvVf5Njlhasd0bVFVoL2KY4ztb0NWa9ajXp1489KV0YNNaMKKKK1EFFFFABRRRQ AUVUl1SxgcpJdRBh1Xdk06DULS6bbDcRu390Nz+VVyytewuZbXLNFFFSMKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6jHvtJGC7mQb1HuORXI+JrTz/EOkXr MPKkhZPbOQf6127DOQe9eGfFHxFBpd41hp9+8moZCNDGWPkqR69AccYHI9qaEdnJ4g8MWTa2L3xT pjWeoxKFiS5Ejxny9jcDOAeMD61hQ+N9J0LwH4X8UX0U99cW8cljH9nkAPOFYsD2/dp9Mj1ryA+H IHgf7VqsccxUsUjiMqhsZwWBxmqUeiWaorXV1KzkD5FwoHqB1obuCViTUfFhvfFV1r9vbraXE1yb iLHzGJgcqQfXPOfWtHVPiHr/AIlsza6zqQlhVgVRVWNSc9wAN39Kyv7M0bpuucjjh/8A61SW9pYW rF7eVGZuCLiHeMemeMUhmnCXaJJJdRgQRQbkD/MB8pIQDOSTx7AkinjVbUkJPGpcH70Y4I45xXOX kcvnGSG2h8pVAVYmOMgdSDyfwrNS+l3P8+Q/3wDjPsfagDrrjXtU8P3cb6fqDsj/ADhSwO3jv/nt XXeG/jRq8MgiurWO8UYLHGCB3JI6V5F5s1xKqKCzvhFUDJJJxitXw3b317qwsdNVJHZsTOD8oTPJ ye1AH1R4L8bW3jCw+0Jay2kgcoEkIIkAH3kP8S9efaurrybwmi2PjHRNNhIEVvZFCoIxwr8/jXrN NgFY988j3bRbiQCNqj6f/XrYrOvrSR5TLGARgZA65/zivGzyjVq4W1LWzu0uxpSaUtTLlQyROisU LKQGHb3rNXSp/sdtbvcQkWrRtFtiIGV9RuOeMfQ81o3Mht7aaXy2do0LbFHLYGcD3rFGrzGGFo7u 1lMzqrSiM+XASMncQ3OTgAZByevIFfDwU+h61CNVx9zYmk0CORUPnbZTOZppFXBfKlSo5+UYOPw9 eauabY/YLYRtIJJMKGcJtBCgKMDJxwPzz61jf2vfo1kjyLIkszIpjQeZMmCqyY6Ku7Bz34PTirPh xpLizFw9/PNIzMZYm2lUYnpnbkEDHGfwFaTjPl956G9anXVJuctP+C/Ly/I3K2bGVpbYFuSDjNZc NvJO2EXj17CtmCEQRBB26n1r3eHaFZVXV2hb7zx6zVrdSSiiivrzmCsbWtUktmW1tiBMw3M5Gdg/ xqnretSrctZ2jlAnEkg659B6VmW8eWLEksxySxyTXVTo296RhOr9mJMsckrbpJJHY92c1ZH23yvs 4uH+zt94E/MPYH0NTQRZA4q8lvkVUp2JjEyDahFwqgD0FVJoOQ3IYchh1FdDJb4FZ08VOM7ilA0d D1Brq3aGZgZoSAT/AHlPQ/ofyrWrgrmMA5HB9a0tE1mZLiO1uXMkUhwrMclT2GfSoqUL3lEqFW3u yOrooorlOgKKKKACiiigAooooAKKKKACiiigBk0scELzSuEjRSzMegA6msddZ1G+jD6Xo7tGRlJr 6b7Ojj1AAd/zUfWo/Gkk6+F7mG2iWW4uWS2iRm2hmdgoBPYc1zmp+JPGEOmSG40Ky0qDAjlu5L0N 5O4hcqoHzEZyPpWkY3REpWZ0U15qyMRNq+h2b/8APJ4Xlx/wLzUz+QpIrvVZDiPXdCuH7Ilq6Z/H zm/lWJo3hh7fT7TUNPhWV5J5JJIb5uJIW3bMkqWB5RufQin6v4bnurO9vryyt1aII0NtaAMMKcvn 5QSSM8D0puMb2Fd2ub7anq9mC17ooliH/LTT5/OIHqUZUP4LuNalpdQX1pDdW0iyQTIHR16MD0rg tL13xZHbSQaVpFnq9hBI0UE/23y5Cg+5vDDqQQc+hrofBi6nHpV1DqunrZTpeTOsaSb1KyHzflbu AZCvp8uO1KUbK41LU6KiiisywooooAKKKKAKGs3cdho1/dys6xw27yMYzhsBSfl9/T3r4/u4JYbm W5MksLy9WWU7nPevr7W7Eano15ZMxUTxMm4DOOOtfPOv+CprS98tlLru2h2Uj88UAecE3BRsXc30 MhqPfOiHfIWHselerWXwxurqFZY7vTwDjBT5/wBcUXfww1UD5PsFyPQpgj+VAHlOSY/MDsMDO1lH 86YjSOhZpI4gPUEg/jiu21PwVf2UTmbS50Kr9+EnZ/Wuek0ltp23AWTptkXaB+OSPzxQBlNdXFuF kZGKdnU5B/EVSluPOk3KoDtw2e9XZ7Ke2nIYGOQ9OeWH9ageNCcyRkPnqvy//WoAmtJVtZEYBJrm ZSqIqn92T8oOT/EOoxntXrPhbR18H6FLLdlJJS2+R4+c9AqjNcJ4K0i1uNQfUbmVglmVZEbnc+eO fyr0bVI5tRvrLTl4jZRM/fGTgD69/wAaAOh8DWV7Jr0niL7O8yksyRIw3FSCoHPHAI79q9K/ti9/ 6AV9/wB9R/8AxVJ4e0xNM0u3iUchBnj2rYoAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+Krg tL8QeI7T4632ia9qscVpeW+/TLKKDzIpoV3lSH3AxyjaxYsCGww4Ajqn8K/HPiXxH4kSHWb6C5td R0qTU4oktlj+ylbpoPLUjllwM5bJ6c8EsAeiyajcS/f8P3p/4FH/APFVAZpT00HUB9Hj/wDiq4H4 qeOfEvhzxI8OjX0Fta6dpUepyxPbLJ9qLXSweWxPKrg5yuD155BWx4/+J0ujeOdE0DTL6C1hh1C3 XWppgg2xyEEIN5+7s3M7gYXKfMCSK5quDw9Z3qQTfoUpSWzOxYM0qyt4fv2kQEKxaLIz6HdVhLqV DkeHr4n3eM/+zVyWs/Ey78Oussmlyakl9caoYYUmSI20diuwjJHzhmjeQk8qHIAfaAbGmfEwa94c 8V3aaXd6fPpFl9sjBmjZpIZIGlhcHDKrlRkqQwXIzu5AiGXYSDvGmvuG6k3uzrBq94BgaDegezR/ /FUv9sXv/QCvv++o/wD4quCvvi+NBtdMN1o13eRS6FaatcXC3Ee9FllSI7l2oGI3ZyuMkgbVGWX1 SuxKxBkf2xe/9AK+/wC+o/8A4qvKrX4keIdD+I2p+HE0a71ix87zI4I8NcWoZQxXI+UgEnAJ6Hr2 r2ys7S9D0/RzcvZ26rLdTNPPKRl5HY5JJ/QDsBQBxMcr3B86SJ4XkYu0b43KSehx3rndf1/W7HX4 7LSvLdjNahYXUfvA0c7ume27ygAe1dxrOkzWdzJcRIz27sXyoyUJ659qqQQW0kyzvBG0oIIkK/MC AQDn2DN+Zr1OZSjdHDytOzOY07xDrGsjT7yz1ia2tr3WmshF9li3JFsVsHcpIcHIPWkXxdryaBrO onVLjz7RLjykKWvlsVbauF/1mcc8jHHpXd2tvaR7dltCu2UzjCDiQ9X/AN4+tPTRdDE73H9kWPnP ne/kjc2euT3zWTnHqvwRag+jOBl8XeLbfXBp0a3Erx3UbG2voYknmi8mSRkBj+XnZ8p6568VRtfG mqaxfxtDfyrZyJJIhhS3U7RMVXd5uOi9hzxXq0sVq10Ls28RuRjEu35hwQOfoT+dYt7omi3AAm0q yk25I3Qg4ycn8zyaIyi3tYJRdtzmbCTUm8TapZ3OrSXVtZJDsVoY13+Ym7JKgHg9K2IcefH/AL4I x35/nUs6RRs7xxorMAGYDBIAwM/Sr2g6ZJd3aXLqRbxncCf4z2x7Vq5JRuzNRblZG22rXiuyjQ71 gDgENHz/AOPUn9sXv/QCvv8AvqP/AOKrXoryzvMj+2L3/oBX3/fUf/xVH9sXv/QCvv8AvqP/AOKr XooAyP7Yvf8AoBX3/fUf/wAVR/bF7/0Ar7/vqP8A+KrXooAyP7Yvf+gFff8AfUf/AMVR/bF7/wBA K+/76j/+KrXooAyP7Yvf+gFff99R/wDxVH9sXv8A0Ar7/vqP/wCKrXooAxZtSu7iF4X0K+CupUkP GOv/AAKvLvAPxO8RT6zdeHrvRb3WYbO4aBb63ALoobaPNP3Tx3Bz9ete0TRiaF4iSA6lSR1GaqaT o9hoWnRWGm2yW9vGMBVHX3J7n3NAE93Z2+oWj211EJInxlT2PUEHsQe9crd+HrG/12300i5uYrYL cXL3Vw823n5EG4nBYjJ9hjvXY1zNjqun2Gt64l3dwwSNcocSMASPLXB/nVwTd7EyfczPEl6sHiq6 h/tjWrXGhyyeRa2++FcE/vFP/PUdh7DnnmPwhffaNfgi/tvWbz/iTQv5V5b7I2yf9YT/AM9D3H6m rmpSaff6tLexeMpbSN7F7QW0MyhFds4lH+2M8fSk0h7DTNRjup/Gct9Gtklr5E8y7S6nmX/eP+TW 1lyWtr/XkZXfNe5esNFh03xXKyW37qaNp4ZkYr5ZyA8bAcMuX3KDnBLY6CukrAuddsbnUtJisr+O VmuiJEhkySvlSdQOo3bT9cVv1hK/U1jboFFFFSUFFFFABRRRQA1upqjeaTZ3yFZogc1ePWkpiOAn +Ha20rz6deXEEhOco+PzqjdHxRpKhQkF2v8AflQ7vzUj+Vem0140kGHUEe4oA8oTxlNbjZqOlTKT wxhO4Y+hqC9uPB2u4+07baQnAfyzG348Y/OvUZ9F025z51ojZ65zWdP4K0CfG6xX/vpv8aAPGtX8 F6XOjjTtUivIWGRbGVS49wP8MVwt54XigfYPtKvnAEgz09uK+jpPhr4dcnFmF9MSNx+tZ178LNLl jVYhKoU5AEzYH60hnjXh/RY7W8g8+crFJMvmHoFH978K9J+H2mSavfSapcr8xbgADAAAwK0ofhXb Y2yNIVPYyNj+ddzoui2ui2Yt7aPaB15zQBpoAuAOg4p9NHWnUAc3Z+A/Dlh4xuvFNvp0aapcJhn/ AIVY53uq9A7A4Y98f7Tbo7D4deEdL/tX7DokEH9qxPBd7Gcbo3zuRef3anPRNo4HoMdRRQBy9/8A Drwjqn9lfbtEgn/sqJILTeznbGmNqNz+8UY6PuHJ9TmxrHgbwtr94l5qmg2NzdLKkxmaIB3ZRhQ7 DBdcYG1sqcDI4roKKAOfu/BPh2+tdOtrnT98Om2ktlaL50g8uGSLynXIbnKDGTkjqDnmi08E+HbG 11G2ttP2Q6laRWV2vnSHzIY4vKRcluMIcZGCepOea6CigDl734d+FdQgWG60rzI10+PTAPtEoxbR usiJw3ZlU56nHJxWxaaJp1jrGo6tbW+y+1Lyvtcu9j5nlrtTgnAwDjgDPetCigAooooAa6CSNkb7 rAg1xFzaTaXcmKUfJ/A/Zh/jXc0140lUrIiup7MMitaVXk9DOpDmOOhuSxAjVpH/ALqDJqzHdhlB ByDXTRQQwDEUSIP9lQKpXWi2ty5kAaKQ8lozjP1HStfbRb1RHs5JaMxnufwplrC+o3ggUkRrzK69 h6fU1ojw4N3z3khXuAgB/OtW1tILKHyoECr1PqT6k96JVYpe7uCpyb1KsWhafEwcwmRh3lYt+h4/ StEAAYHSiiuZyct2bKKWwUUUUhhRRRQAUUUUAFFFFABWHbeMNAvPEEmhQalG+oI8kfl7GCs8YUyI rkbGdQ6llUkjuBg1uV5/Z/Di8i+IFv4ovPEH2z7Nd3c8MUlqfMWOZSqw+aZD+7jySoCgAs/A3cAG pZ/EvwfqFhdXtnrUdxFa2/2qdYoZGkji3lC5jC78Ajnj5QQxwGBOxZeI9I1LVJNOsL6O6uI7eO5f yAXRY35QmQDYCw5C5yRyBjmuD0X4Wp4WthJLNPrsKaJLo8ljBCsDzpLctKzBmlAXAcjG4dMg5wK1 PhZ4MvvCmgyT61JHJrV8kKz7OkUUUYjhi4O0lVBywHJJ5bAYgG5N448NW2vXGh3GrwQ6lb4MsMoZ No8ppt24jG0IpJbOBwCQSAYLfxx4SvtHv9YXUYBaWKI9y88LxuiuoaM7HUMQ4YbSAd2cLk1F/wAI PDJq3jG7uL6RoPE1vFbyRRxhWgVIWiJDEkEkNnoMe9cuvwp/s34b614flu5NSlvUhRG07TrW1kAj YFM5K+YQ2SxeTJGQMEkkA6iw8eeDtT062v7S/jltbrUF0yF/ssg3XLDKpgpkZB6nj3qvF460i/1j wrbaVbR3tj4h+1+XeYMfl+QuT8jLk5ORzjGM81yej/DLxFfeEnh1LV/7N1c+JX12O5a2jlfcF2qX jV/LVifnwrMo4HPOOg8P/DL+wv8AhDv+Jv5//CN/bf8Al22/aPtGf9s7NuffPtQBs2Xjjwldrfy2 mowOLC3kupnWFxmFGZXkjO396gZGG5NwyMdxnT0LxHpHiaye80a+jvLdHCNIgIAYor45A52uuR2O QcEEDg9L+Et5aS6nPf8Aib7fdX+iT6Q9y9mRK/mNuEsjGVjIyjCjp8qqMjFegaFpn9ieHtM0nzvO +w2kVt5u3bv2IF3YycZxnGTQBzdv8UfC+q6NrV7oWoR6jPpVlJeSWxV4WdUUnjeoOMgAkA4yM9Rm xo3xF8Oar4Vl119StII7S3ilv4xLv+ys6KwQkDLHLbRgcsCoG4EDh/APwm1Oy8MXZ17UJLfULzR7 jSIrURxstlFJI7kllY+YSzBxyMbiOeMbEfwgh/sHX9Kn1mR01ay0+1EiW4UwtaRqqvgsdwZlBK8c ZGe9AHSJ8RfCMmh2utDW4Bpt1diyjnZXAWY5O1wRmPgE5bAxg5wQakuvH3he00ax1aTVo2s79He2 aGN5WkVFLOdiKWAQA7iQNuMNg1z9p8Lmg0uwgn16S4vIvEa+ILu5a1VRcSjOUVAwCAjHOTg54wQB nz/BkSeE/Dmkxa7Gt3ob3BjuJ9NjnilWZizBoXJGR8uCScYJxkjAB6hBPDdW8VxbyxzQSoHjkjYM rqRkEEcEEc5qSq9hZpp+nW1lEcx28SRKdipkKAB8qAKOnRQAOwAqxQAYowPSiigAwPSjA9KKKADA 9KMD0oooAMD0owPSiigAwPSjA9KKKADFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z --=_NextPart_2rfkindysadvnqw3nerasdf-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 05:07:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26923 for ; Sun, 30 Nov 2003 05:07:11 -0500 (EST) Received: (qmail 27316 invoked by uid 605); 30 Nov 2003 10:07:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27309 invoked from network); 30 Nov 2003 10:07:22 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 30 Nov 2003 10:07:22 -0000 Received: from localhost.arcor.net (dsl-213-023-026-249.arcor-ip.net [213.23.26.249]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id B94ED3203BC; Sun, 30 Nov 2003 11:07:20 +0100 (CET) Received: by localhost.arcor.net (Postfix, from userid 31451) id BE4912D003; Sun, 30 Nov 2003 11:07:14 +0100 (CET) Date: Sun, 30 Nov 2003 11:07:14 +0100 From: Markus Friedl To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Problems with draft Message-ID: <20031130100714.GA29376@folly> References: <200311300128.UAA03199@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200311300128.UAA03199@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Nov 29, 2003 at 05:40:25AM -0500, der Mouse wrote: > In transport-17, section 6.2 writes of a "shared secret K", treating it > as an opaque blob which is passed as part of a HASH argument. But > section 7 writes of K as a large integer. It's not entirely clear how > the one is converted into the other; looking at existing code, I find > that the kex code treates it as a large integer (which will need fixing from the draft (section 6.2) ... o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ASCII 65). ... So I don't think the core drafts need to changed at this point. > if-and-when key exchange methods that produce a K that's not > conceptually a large integer, though that's an implementation matter > rather than a spec matter), but when serializing it for hashing it uses > the same code it uses for "mpint" serialization. I would like to see > the draft clearly state exactly how the large integer K of section 7 is > converted into the opaque blob K of section 6.2. The description of > H's computation seems to imply that this should be done as the code > does it, but it's not clearly stated. > > Also, section 7 writes > > The hash H is computed as the HASH hash of the concatenation of the > following: > [...] > string I_C, the payload of the client's SSH_MSG_KEXINIT > string I_S, the payload of the server's SSH_MSG_KEXINIT > [...] > > It is not clear whether these are compressed or uncompressed; while > this doesn't matter for the first key exchange, it matters for > re-exchange, and I'd like to see the draft state it clearly. It refers to the payload after the transport layer transformations, i.e. after decryption and decompression, with padding removed. Again, I don't think a change in the core drafts is necessary. > transport-17 section 5.6 says > > The "ssh-rsa" key format has the following specific encoding: > [...] > Signing and verifying using this key format is done according to > [SCHNEIER] and [PKCS1] using the SHA-1 hash. > > I have been unable to find any description of a signature algorithm for > RSA in Schneier, and I have found no reference anywhere to explain what > [PKCS1] is supposed to refer to - I assume this is as described in > RFC2437? Yes, it seems the reference is missing. AFAIK it refers to section 8.2 from RFC 3447. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 12:34:44 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05577 for ; Sun, 30 Nov 2003 12:34:43 -0500 (EST) Received: (qmail 6168 invoked by uid 605); 30 Nov 2003 17:34:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6154 invoked from network); 30 Nov 2003 17:34:48 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 30 Nov 2003 17:34:48 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA21890; Sun, 30 Nov 2003 12:34:47 -0500 (EST) From: der Mouse Message-Id: <200311301734.MAA21890@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. Date: Sun, 30 Nov 2003 12:26:28 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Problems with draft In-Reply-To: <20031130100714.GA29376@folly> References: <200311300128.UAA03199@Sparkle.Rodents.Montreal.QC.CA> <20031130100714.GA29376@folly> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> In transport-17, section 6.2 writes of a "shared secret K", treating >> it as an opaque blob which is passed as part of a HASH argument. >> But section 7 writes of K as a large integer. It's not entirely >> clear how the one is converted into the other; > o Initial IV client to server: HASH(K || H || "A" || session_id) > (Here K is encoded as mpint and "A" as byte and session_id as raw > data."A" means the single character A, ASCII 65). > So I don't think the core drafts need to changed at this point. Thanks. I must have missed that. >> Also, section 7 writes >> The hash H is computed as the HASH hash of [...] >> string I_C, the payload of the client's SSH_MSG_KEXINIT >> string I_S, the payload of the server's SSH_MSG_KEXINIT >> It is not clear whether these are compressed or uncompressed; > It refers to the payload after the transport layer transformations, > i.e. after decryption and decompression, with padding removed. > Again, I don't think a change in the core drafts is necessary. Perhaps. I think I disagree, though; I don't see how someone implementing from scratch is supposed to know, from the drafts, that I_C and I_S are the decompressed forms. (Decrypted makes sense, on reflection, since if a block cipher is in use, then before decryption the beginning of the payload is generally mixed with the length values.) I still think less ambiguity on each point would be good. This is, after all, supposed to be a standard, so clarity is a Good Thing. Is there some high overhead associated with changing the drafts or something? /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 14:11:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08909 for ; Sun, 30 Nov 2003 14:11:11 -0500 (EST) Received: (qmail 22147 invoked by uid 605); 30 Nov 2003 19:11:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22140 invoked from network); 30 Nov 2003 19:11:12 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Nov 2003 19:11:12 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 21FFDB9A18; Sun, 30 Nov 2003 20:11:11 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 48ED1B9A51; Sun, 30 Nov 2003 20:11:08 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id hAUJB7CM026239; Sun, 30 Nov 2003 20:11:07 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id hAUJB3IG026236; Sun, 30 Nov 2003 20:11:03 +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: Problems with draft References: <200311300128.UAA03199@Sparkle.Rodents.Montreal.QC.CA> <20031130100714.GA29376@folly> <200311301734.MAA21890@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 30 Nov 2003 20:11:02 +0100 In-Reply-To: <200311301734.MAA21890@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60-lysator_fetto_1.1 (1.212-2003-09-23-exp) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > >> Also, section 7 writes > >> The hash H is computed as the HASH hash of [...] > >> string I_C, the payload of the client's SSH_MSG_KEXINIT > >> string I_S, the payload of the server's SSH_MSG_KEXINIT > >> It is not clear whether these are compressed or uncompressed; > > It refers to the payload after the transport layer transformations, > > i.e. after decryption and decompression, with padding removed. > > Again, I don't think a change in the core drafts is necessary. > > Perhaps. I think I disagree, though; I don't see how someone > implementing from scratch is supposed to know, from the drafts, that > I_C and I_S are the decompressed forms. Except for section 4, which describes the transport-level mangling of compression, padding and encryption, all mention of "payload" in the specs refer to the uncompressed, unencrypted, unpadded payloads. It may be a little unfortunate that both section 4 and section 6 of the transport spec use the word "payload" for different things, but I don't think it's a big problem. > I still think less ambiguity on each point would be good. This is, > after all, supposed to be a standard, so clarity is a Good Thing. And conciseness is also important; if every detail that someone might ever misunderstand should be explained full, a spec can easily get too large to be readable. > Is there some high overhead associated with changing the drafts or > something? We've been trying to get this stuff to be published as a proper standard for ages, and every little change somebody asks for delays it even further. That said, it's of course a good thing to get feedback on the draft. If you really think this needs additional clarification, please write the text you want and the wg should consider it. I'd recommend rewording section 4 so that it doesn't use the word "payload" to refer to a string that sometimes contain the payload in compressed form. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 17:43:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15197 for ; Sun, 30 Nov 2003 17:43:04 -0500 (EST) Received: (qmail 13707 invoked by uid 605); 30 Nov 2003 22:43:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13698 invoked from network); 30 Nov 2003 22:43:11 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 30 Nov 2003 22:43:11 -0000 Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA22730; Sun, 30 Nov 2003 17:43:10 -0500 (EST) From: der Mouse Message-Id: <200311302243.RAA22730@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. Date: Sun, 30 Nov 2003 17:18:03 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Problems with draft In-Reply-To: References: <200311300128.UAA03199@Sparkle.Rodents.Montreal.QC.CA> <20031130100714.GA29376@folly> <200311301734.MAA21890@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>> string I_C, the payload of the client's SSH_MSG_KEXINIT >>>> string I_S, the payload of the server's SSH_MSG_KEXINIT >>>> It is not clear whether these are compressed or uncompressed; >>> [uncompressed] >>> Again, I don't think a change in the core drafts is necessary. >> Perhaps. I think I disagree, though; I don't see how someone >> implementing from scratch is supposed to know, from the drafts, that >> I_C and I_S are the decompressed forms. > Except for section 4, which describes the transport-level mangling of > compression, padding and encryption, all mention of "payload" in the > specs refer to the uncompressed, unencrypted, unpadded payloads. Good - but how can one tell that? Indeed, I would be tempted to read section 5's (not 4's - section 4 is "Connection Setup") byte[n1] payload; n1 = packet_length - padding_length - 1 [...] payload The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression MUST be "none". as being the _definition_ of "payload" for the rest of the draft, by which interpretation "payload" would be unencrypted but compressed. >> I still think less ambiguity on each point would be good. This is, >> after all, supposed to be a standard, so clarity is a Good Thing. > And conciseness is also important; True enough. > If you really think this needs additional clarification, please write > the text you want and the wg should consider it. I'd recommend > rewording section 4 so that it doesn't use the word "payload" to > refer to a string that sometimes contain the payload in compressed > form. Here's a patch against transport-17. In the interests of keeping the diff small, I made no attempt to re-fill paragraphs or move page breaks; I assume the draft was generated from a master file in some other format, and presumably the changes need to be made to that other format and the distributed draft file regenerated. --- transport-17.txt Wed Nov 26 21:04:37 2003 +++ new-transport-17.txt Sun Nov 30 17:35:37 2003 @@ -265,7 +265,7 @@ uint32 packet_length byte padding_length - byte[n1] payload; n1 = packet_length - padding_length - 1 + byte[n1] compressed-payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length @@ -285,14 +285,15 @@ padding_length Length of padding (bytes). - payload + compressed-payload The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression - MUST be "none". + MUST be "none". (When "payload" is used without adjective + elsewhere, it refers to the uncompressed form.) random padding Arbitrary-length padding, such that the total length of - (packet_length || padding_length || payload || padding) is a + (packet_length || padding_length || compressed-payload || padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding @@ -305,7 +306,7 @@ Note that length of the concatenation of packet length, padding - length, payload, and padding MUST be a multiple of the cipher block + length, compressed-payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field is also encrypted, and processing it requires special care when sending @@ -318,9 +319,9 @@ 5.1 Maximum Packet Length - All implementations MUST be able to process packets with uncompressed + All implementations MUST be able to process packets with (uncompressed) payload length of 32768 bytes or less and total packet size of 35000 - bytes or less (including length, padding length, payload, padding, + bytes or less (including length, padding length, compressed-payload, padding, and MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger than uncompressed size. Implementations SHOULD support longer packets, where they might be needed, e.g. if an implementation wants @@ -362,7 +363,7 @@ current block is not a stored block, one or more empty blocks are added after the current block to ensure that there are at least 8 bits counting from the start of the end-of-block code of the current - block to the end of the packet payload. + block to the end of the (compressed) packet payload. Additional methods may be defined as specified in [SSH-ARCH]. @@ -370,7 +371,7 @@ An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding - length, payload and padding fields of each packet MUST be encrypted + length, compressed-payload and padding fields of each packet MUST be encrypted with the given algorithm. The encrypted data in all packets sent in one direction SHOULD be @@ -491,7 +492,7 @@ mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length - fields, payload and padding), and sequence_number is an implicit + fields, compressed-payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It /~\ 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 19:46:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18722 for ; Sun, 30 Nov 2003 19:46:16 -0500 (EST) Received: (qmail 4404 invoked by uid 605); 1 Dec 2003 00:46:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4397 invoked from network); 1 Dec 2003 00:46:25 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 1 Dec 2003 00:46:25 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA23635; Sun, 30 Nov 2003 19:46:24 -0500 (EST) From: der Mouse Message-Id: <200312010046.TAA23635@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. Date: Sun, 30 Nov 2003 19:37:56 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Another minor note re drafts Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Something else odd that I notice in the drafts is that newmodes-01 contains some non-ASCII characters in an apparently gratuitous and rather odd way. Specifically, it contains the octet sequence 0x82 0xc7 0xd6 in a number of places where I would expect an apostrophe (') to appear, and there are no apostrophes at all present. My first thought was that this was because someone used an unusual character as an apostrophe (like the acute accent ´ that far too often gets misused as an apostrophe) and it got UTF-8 encoded, but that sequence is not a valid UTF-8 encoding as I read RFC 2279, so I have no idea what it is. Whatever it is, I think it would be a good idea to fix 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 ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 30 20:08:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19190 for ; Sun, 30 Nov 2003 20:08:58 -0500 (EST) Received: (qmail 18191 invoked by uid 605); 1 Dec 2003 01:09:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18184 invoked from network); 1 Dec 2003 01:09:08 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 1 Dec 2003 01:09:08 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 2B3C834004; Mon, 1 Dec 2003 14:09:03 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hB11CSl02084; Mon, 1 Dec 2003 14:12:28 +1300 Date: Mon, 1 Dec 2003 14:12:28 +1300 Message-Id: <200312010112.hB11CSl02084@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, mouse@Rodents.Montreal.QC.CA Subject: Re: Another minor note re drafts Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: >Something else odd that I notice in the drafts is that newmodes-01 contains >some non-ASCII characters in an apparently gratuitous and rather odd way. >Specifically, it contains the octet sequence 0x82 0xc7 0xd6 in a number of >places where I would expect an apostrophe (') to appear, and there are no >apostrophes at all present. I'd guess that's MS Word 'smart' quotes. I've seen them in Usenet postings and RFC drafts written using Word. Peter.