From owner-ietf-ssh@clinet.fi Thu Aug 3 10:25:31 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18870 for ; Thu, 3 Aug 2000 10:25:30 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA29792 for ietf-ssh-outgoing; Thu, 3 Aug 2000 15:23:49 +0300 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA29781 for ; Thu, 3 Aug 2000 15:23:45 +0300 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10451 for ; Thu, 3 Aug 2000 05:23:44 -0700 (PDT) Received: from hobo150.eng.sun.com (hobo150.Eng.Sun.COM [129.146.31.150]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA27113 for ; Thu, 3 Aug 2000 05:23:42 -0700 (PDT) Date: Wed, 02 Aug 2000 13:35:04 -0400 From: Chris Newman To: ietf-ssh@clinet.fi Subject: UTF-8 reference needs to be updated Message-ID: <679978.3174212104@localhost> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Quick note for the draft revision: The UTF-8 reference: [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. Should be updated to: [RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", January 1998. - Chris From owner-ietf-ssh@clinet.fi Tue Aug 8 12:09:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16349 for ; Tue, 8 Aug 2000 12:09:09 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA25911 for ietf-ssh-outgoing; Tue, 8 Aug 2000 17:08:17 +0300 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA25905 for ; Tue, 8 Aug 2000 17:08:15 +0300 Received: from viper ([192.168.0.16]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 82; Tue, 8 Aug 2000 08:21:50 -0600 Message-ID: <000901c00142$10e64690$1000a8c0@viper> From: "Jeff P. Van Dyke" To: Subject: Is the user name always UTF-8? Date: Tue, 8 Aug 2000 08:07:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit During the working group meeting last week in Pittsburgh, I asked why, in the "Password Authentication Method", the password was encoded in UTF-8, but the "user name" was not. It was explained why the user name could not be encoded in UTF-8. Now, it is possible, that my question was misunderstood or that I misunderstood the answer, but in any event... When I returned to the office, I discussed this one of engineers and he pointed out that it is encoded UTF-8. After reviewing the draft, http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-07.txt I found six uses (see below) of "user name". Only the first one mentions that it is encoded in UTF-8. If the "user name" should not be encoded in UTF-8, the first one should be corrected. If they all should be encoded in UTF-8, I think the documentation would be clearer if each one of them read: string user name (in ISO-10646 UTF-8 encoding) Jeff P. Van Dyke jpv@vandyke.com --- 2.1. Authentication Requests ... byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding) 4. Public Key Authentication Method: publickey ... byte SSH_MSG_USERAUTH_REQUEST string user name ... byte SSH_MSG_USERAUTH_REQUEST string user name 5. Password Authentication Method: password ... byte SSH_MSG_USERAUTH_REQUEST string user name string service string "password" boolean FALSE string plaintext password (ISO-10646 UTF-8) ... byte SSH_MSG_USERAUTH_REQUEST string user name 6. Host-Based Authentication: hostbased ... byte SSH_MSG_USERAUTH_REQUEST string user name From owner-ietf-ssh@clinet.fi Thu Aug 10 17:56:09 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14736 for ; Thu, 10 Aug 2000 17:56:08 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id WAA07746 for ietf-ssh-outgoing; Thu, 10 Aug 2000 22:54:37 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id WAA07743 for ; Thu, 10 Aug 2000 22:54:36 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id WAA23221 for ; Thu, 10 Aug 2000 22:54:35 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id WAA12188 for ietf-ssh@clinet.fi; Thu, 10 Aug 2000 22:54:35 +0300 (EET DST) Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA06643; Wed, 9 Aug 2000 16:55:11 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 9 Aug 2000 16:55:11 +0300 (EET DST) From: Tero Kivinen To: "Jeff P. Van Dyke" Cc: Subject: Is the user name always UTF-8? In-Reply-To: <000901c00142$10e64690$1000a8c0@viper> References: <000901c00142$10e64690$1000a8c0@viper> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14737.24826.39101.760521@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 7 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id QAA24000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit Jeff P. Van Dyke writes: > If the "user name" should not be encoded in UTF-8, the > first one should be corrected. > > If they all should be encoded in UTF-8, I think the > documentation would be clearer if each one of them > read: I think we should encode all of them in UTF-8 ISO-10646. We might need to add some text saying about the canonicalization process, i.e the server is assumed to do canonicalization to any format it is using internally. Client can send it out in any format it likes. I.e if clinet sends either "Ylnen" or "Ylonen" the server should convert them to the format it is using internally (lets say it is using iso latin 1, so it should convert both of those to "Ylцnen". We don't have that much problem there than they have in the idn wg, because usernames are case sensitive, i.e we don't need to specify how to lowercase them... -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ssh@clinet.fi Thu Aug 10 19:52:21 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16665 for ; Thu, 10 Aug 2000 19:52:20 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA15830 for ietf-ssh-outgoing; Fri, 11 Aug 2000 01:11:13 +0300 Received: from inner.net (avarice.inner.net [199.33.248.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA15816 for ; Fri, 11 Aug 2000 01:11:10 +0300 Received: from mosquito ([216.52.8.30]) by inner.net (8.7.6/8.9.3) with ESMTP id WAA11776; Thu, 10 Aug 2000 22:10:35 GMT Message-Id: <4.2.0.58.20000810180105.00997890@avarice.inner.net> X-Sender: rja@avarice.inner.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 10 Aug 2000 18:06:18 -0400 To: Tero Kivinen From: RJ Atkinson Subject: Re: Is the user name always UTF-8? Cc: In-Reply-To: <14737.24826.39101.760521@hutcs.cs.hut.fi> References: <000901c00142$10e64690$1000a8c0@viper> <000901c00142$10e64690$1000a8c0@viper> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit At 09:55 09/08/00 , Tero Kivinen wrote: >Jeff P. Van Dyke writes: > > If the "user name" should not be encoded in UTF-8, the > > first one should be corrected. > > > > If they all should be encoded in UTF-8, I think the > > documentation would be clearer if each one of them > > read: > >I think we should encode all of them in UTF-8 ISO-10646. We might need >to add some text saying about the canonicalization process, i.e the >server is assumed to do canonicalization to any format it is using >internally. Client can send it out in any format it likes. I.e if >clinet sends either "Ylnen" or "Yloletter>nen" the server should convert them to the format it is using >internally (lets say it is using iso latin 1, so it should convert >both of those to "Ylцnen". SSH would still need some form of canonicalisation rules for on the wire purposes, however. Or am I missing something obvious ? There is likely some UNICODE Tech Report that could be used for canonicalisation and cited in the applicable SSH RFCs. My guess is that the Application ADs have real opinions about internationalisation and canonicalisation. It might be easier to seek advice now rather than have RFCs derail during IESG review later on, IMHO. Ran rja@inet.org From owner-ietf-ssh@clinet.fi Fri Aug 11 01:18:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25071 for ; Fri, 11 Aug 2000 01:18:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA30477 for ietf-ssh-outgoing; Fri, 11 Aug 2000 06:33:29 +0300 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id GAA30474 for ; Fri, 11 Aug 2000 06:33:27 +0300 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 486 for ; Thu, 10 Aug 2000 21:47:19 -0600 Message-ID: <000001c00345$23c1bce0$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: Subject: Adding ssh-rsa to the transport draft... Date: Thu, 10 Aug 2000 21:34:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit During the working group meeting in Pittburgh, I believe it was decided that ssh-rsa would be added as a public key algorithm to the next rev of the transport draft. http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-07.txt Currently, the transport draft has the following text for ssh-dss: --- The "ssh-dss" key format has the following specific encoding: uint32 length string "ssh-dss" mpint p mpint q mpint g mpint y Here the "p", "q", "g", and "y" parameters form the signature key blob. Signing and verifying using this key format are done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [Schneier]. The resulting signature is encoded as: uint32 length string "ssh-dss" string dss_signature_blob dss_signature_blob is encoded as string containing "r" followed by "s" (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). --- What is the current practice for encoding an ssh-rsa key? Will text describing this be included in the next rev of the transport draft? Thank you. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Aug 11 06:09:23 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08140 for ; Fri, 11 Aug 2000 06:09:22 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA01135 for ietf-ssh-outgoing; Fri, 11 Aug 2000 11:12:46 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA01124 for ; Fri, 11 Aug 2000 11:12:44 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id E0BCB2400E81; Fri, 11 Aug 2000 10:12:42 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id KAA11555; Fri, 11 Aug 2000 10:12:42 +0200 (MET DST) To: Tero Kivinen Cc: "Jeff P. Van Dyke" , Subject: Re: Is the user name always UTF-8? References: <000901c00142$10e64690$1000a8c0@viper> <14737.24826.39101.760521@hutcs.cs.hut.fi> From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Aug 2000 10:12:42 +0200 In-Reply-To: Tero Kivinen's message of "Wed, 9 Aug 2000 16:55:11 +0300 (EET DST)" Message-ID: Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > Jeff P. Van Dyke writes: > > If the "user name" should not be encoded in UTF-8, the > > first one should be corrected. > > > > If they all should be encoded in UTF-8, I think the > > documentation would be clearer if each one of them > > read: The draft-ietf-secsh-architecture-05.txt document says some more about user names: : The client and server user names are inherently constrained by what the : server is prepared to accept. They might, however, occasionally be : displayed in logs, reports, etc. They MUST be encoded using ISO 10646 : UTF-8, but other encodings may be required in some cases. ! Straight bit-wise binary comparison is RECOMMENDED. > I think we should encode all of them in UTF-8 ISO-10646. We might need > to add some text saying about the canonicalization process, I agree, and I think the sentence marked with ! above should be changed. And the "but other encodings may be required in some cases." should be deleted, unless someone can provide a really good reason for it. > We don't have that much problem there than they have in the idn wg, > because usernames are case sensitive, i.e we don't need to specify > how to lowercase them... Is anybody here updated on the idn wg? /Niels From owner-ietf-ssh@clinet.fi Fri Aug 11 07:05:06 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09152 for ; Fri, 11 Aug 2000 07:05:05 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA11782 for ietf-ssh-outgoing; Fri, 11 Aug 2000 12:08:01 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA11775 for ; Fri, 11 Aug 2000 12:07:57 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2CA812400E81; Fri, 11 Aug 2000 11:07:56 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA11967; Fri, 11 Aug 2000 11:07:55 +0200 (MET DST) To: RJ Atkinson Cc: Tero Kivinen , Subject: Re: Is the user name always UTF-8? References: <000901c00142$10e64690$1000a8c0@viper> <000901c00142$10e64690$1000a8c0@viper> <4.2.0.58.20000810180105.00997890@avarice.inner.net> From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Aug 2000 11:07:55 +0200 In-Reply-To: RJ Atkinson's message of "Thu, 10 Aug 2000 18:06:18 -0400" Message-ID: Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk RJ Atkinson writes: > SSH would still need some form of canonicalisation rules for > on the wire purposes, however. Or am I missing something obvious ? You could push canonicalisation to the recieving side, i.e. specify that the reciever is required to handle all variants. If the reciever implements this by canonicalization of received names, canonicalization must be done *after* signature verification, but that's quite obvious and should not be a problem. At least I don't see that non-canonical strings on the wire causes any fundamental problems, as long as the recievers do the right thing. > There is likely some UNICODE Tech Report that could be used for > canonicalisation and cited in the applicable SSH RFCs. My guess is > that the Application ADs have real opinions about internationalisation > and canonicalisation. It might be easier to seek advice now > rather than have RFCs derail during IESG review later on, IMHO. I have the unicode-3.0 book in front of me. The problem is that there are several ways to "canonicalize" unicode strings: * Are short or long representations of characters like "ц" preferred? * What to do with compatibility characters? (I'd think it's best to map them to non-compatibility characters as well, i.e. using the compatibility-equality rather than canonical-equality). * What to do with hangul syllables. Compose or decompose? So the details must be spelled out, somewhere. And then there's utf-8, but it should be straight forward to say that an implementation must always use the shortest utf-8 sequence representing a unicode character (that's the usual way to use utf-8, I guess, but utf-8 decoders in other contexts may be more forgiving). Of course, it would be a good thing to use the same rules in other protocols that have the same problem. An "IETF unicode and canonicaliztion guidelines" rfc would be great... /Niels From owner-ietf-ssh@clinet.fi Fri Aug 11 07:28:11 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09756 for ; Fri, 11 Aug 2000 07:28:09 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA16404 for ietf-ssh-outgoing; Fri, 11 Aug 2000 12:34:01 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA16394 for ; Fri, 11 Aug 2000 12:33:55 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id MAA08160; Fri, 11 Aug 2000 12:31:12 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14739.51168.149684.175513@asgard.tky.hut.fi> Date: Fri, 11 Aug 2000 12:31:12 +0300 (EEST) To: "Jeff P. Van Dyke" Cc: Subject: Adding ssh-rsa to the transport draft... In-Reply-To: <000001c00345$23c1bce0$0201a8c0@vandyke.com> References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Jeff P. Van Dyke, on August 10. 2000, wrote: : What is the current practice for encoding an ssh-rsa key? I will have this modification to the draft peer reviewed today, and I will send it to the list after that. Sound OK? : Will text describing this be included in the next rev of : the transport draft? Yes. -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Fri Aug 11 10:03:39 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16857 for ; Fri, 11 Aug 2000 10:03:38 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA11093 for ietf-ssh-outgoing; Fri, 11 Aug 2000 14:50:28 +0300 Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA11085 for ; Fri, 11 Aug 2000 14:50:26 +0300 Received: from viper2 ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 677; Fri, 11 Aug 2000 06:04:15 -0600 Message-ID: <004c01c0038a$8fbaad40$0201a8c0@vandyke.com> From: "Jeff P. Van Dyke" To: "Sami Lehtinen" Cc: References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> <14739.51168.149684.175513@asgard.tky.hut.fi> Subject: Re: Adding ssh-rsa to the transport draft... Date: Fri, 11 Aug 2000 05:46:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit > Jeff P. Van Dyke, on August 10. 2000, wrote: > : What is the current practice for encoding an ssh-rsa key? > > I will have this modification to the draft peer reviewed today, and I > will send it to the list after that. Sound OK? Excellent. thanks. Jeff P. Van Dyke jpv@vandyke.com From owner-ietf-ssh@clinet.fi Fri Aug 11 13:30:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27137 for ; Fri, 11 Aug 2000 13:30:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id SAA07398 for ietf-ssh-outgoing; Fri, 11 Aug 2000 18:47:57 +0300 Received: from folly.informatik.uni-erlangen.de (muedi6-212-144-216-089.arcor-ip.net [212.144.216.89]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id SAA07389 for ; Fri, 11 Aug 2000 18:47:55 +0300 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 8EFE31245; Fri, 11 Aug 2000 17:47:22 +0200 (CEST) Date: Fri, 11 Aug 2000 17:47:22 +0200 From: Markus Friedl To: "Jeff P. Van Dyke" Cc: ietf-ssh@clinet.fi, niels@openbsd.org Subject: Re: Adding ssh-rsa to the transport draft... Message-ID: <20000811174722.A5759@folly.informatik.uni-erlangen.de> References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> <20000811132956.A23394@folly.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000811132956.A23394@folly.informatik.uni-erlangen.de>; from markus on Fri, Aug 11, 2000 at 01:29:56PM +0200 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On Fri, Aug 11, 2000 at 01:29:56PM +0200, Markus Friedl wrote: > i tried to send this before but it did not appear on the list: > > A RSA Key and Signature Encoding for the SSH Protocol here's a draft for "ssh-rsa" http://wwwcip.informatik.uni-erlangen.de/~msfriedl/ssh/ssh-rsa.txt comments? From owner-ietf-ssh@clinet.fi Mon Aug 14 09:42:34 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07844 for ; Mon, 14 Aug 2000 09:42:33 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA17660 for ietf-ssh-outgoing; Mon, 14 Aug 2000 14:51:59 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA17650 for ; Mon, 14 Aug 2000 14:51:58 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id OAA23278 for ; Mon, 14 Aug 2000 14:51:57 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id OAA05506 for ietf-ssh@clinet.fi; Mon, 14 Aug 2000 14:51:57 +0300 (EET DST) Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA04878; Fri, 11 Aug 2000 16:41:29 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 11 Aug 2000 16:41:28 +0300 (EET DST) From: Tero Kivinen To: nisse@lysator.liu.se (Niels Mцller) Cc: RJ Atkinson , Subject: Re: Is the user name always UTF-8? In-Reply-To: References: <000901c00142$10e64690$1000a8c0@viper> <4.2.0.58.20000810180105.00997890@avarice.inner.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14740.265.502774.332298@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 6 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id QAA29368 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit Niels Mцller writes: > You could push canonicalisation to the recieving side, i.e. specify > that the reciever is required to handle all variants. If the reciever > implements this by canonicalization of received names, > canonicalization must be done *after* signature verification, but > that's quite obvious and should not be a problem. The username is only a string of characters from the client point of view. The server is the only one that tries to compare it to something it has in its internal database (password file etc). > At least I don't see that non-canonical strings on the wire causes any > fundamental problems, as long as the recievers do the right thing. Correct. > > There is likely some UNICODE Tech Report that could be used for > > canonicalisation and cited in the applicable SSH RFCs. My guess is > > that the Application ADs have real opinions about internationalisation > > and canonicalisation. It might be easier to seek advice now > > rather than have RFCs derail during IESG review later on, IMHO. > > I have the unicode-3.0 book in front of me. The problem is that there > are several ways to "canonicalize" unicode strings: > > * Are short or long representations of characters like "ц" preferred? > > * What to do with compatibility characters? (I'd think it's best to > map them to non-compatibility characters as well, i.e. using the > compatibility-equality rather than canonical-equality). > > * What to do with hangul syllables. Compose or decompose? > > So the details must be spelled out, somewhere. I don't think so. The canonicalization problem is really an internal issue for the server. If the server stores the usernames in the password file as a Iso-latin1 strings, it needs to take the UTF-8 encoded unicode username and convert it to iso-latin1, and if there is no way to convert it to iso-latin1 then it just rejects the authentication request... So it is internal implementation issue, and there is no need to say anything about it in the draft. > And then there's utf-8, but it should be straight forward to say that > an implementation must always use the shortest utf-8 sequence > representing a unicode character (that's the usual way to use utf-8, I > guess, but utf-8 decoders in other contexts may be more forgiving). That doesn't affect the protocol either at all. Everything that is signed, hashed etc in the protocol are done in the same octect string representation they had on the wire and thats it. After that it is servers duty to do whatever it likes to convert that username to the format it is internally using. Of course we might want to add that kind of text just to remove one possible place which might cause interoperability problems. -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ssh@clinet.fi Mon Aug 14 09:42:39 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07855 for ; Mon, 14 Aug 2000 09:42:38 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA17372 for ietf-ssh-outgoing; Mon, 14 Aug 2000 14:50:34 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA17337 for ; Mon, 14 Aug 2000 14:50:20 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id OAA23117 for ; Mon, 14 Aug 2000 14:50:20 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id OAA31425 for ietf-ssh@clinet.fi; Mon, 14 Aug 2000 14:50:19 +0300 (EET DST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 378F81244; Fri, 11 Aug 2000 13:29:57 +0200 (CEST) Date: Fri, 11 Aug 2000 13:29:56 +0200 From: Markus Friedl To: "Jeff P. Van Dyke" Cc: ietf-ssh@clinet.fi, niels@openbsd.org Subject: Re: Adding ssh-rsa to the transport draft... Message-ID: <20000811132956.A23394@folly.informatik.uni-erlangen.de> References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <000001c00345$23c1bce0$0201a8c0@vandyke.com>; from jpv@vandyke.com on Thu, Aug 10, 2000 at 09:34:48PM -0600 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk i tried to send this before but it did not appear on the list: Network Working Group Markus Friedl INTERNET-DRAFT The OpenBSD Project Expires in six months July 2000 A RSA Key and Signature Encoding for the SSH Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Please direct comments to one of the authors (for the authors contact information, see the end of this document). Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The SSH Transport Layer Protocol [SSH-TRANS] defines several encodings for Public Key Algorithms. However, it fails to provide a specifications for the widely used RSA algorithm. This document specifies both how RSA keys and RSA signatures are encoded. The Encoding The name for this public key encoding method is "ssh-rsa". The encoding for RSA keys and signatures is similar to the "ssh-dss" key format defined in the SSH Transport Layer Protocol document [SSH- TRANS]. The used data types are specified in the SSH Protocol Architecture document [SSH-ARCH]. Friedl [Page 1] INTERNET-DRAFT July 2000 The "ssh-rsa" key format has the following specific encoding: uint32 length string "ssh-rsa" mpint e mpint n The parameters "e" and "n" are the public key for the RSA algorithm. They are used to verify signatures created by the corresponding private key. The PKCS#1 standard [RFC 2437] describes signature and verification operations for RSA. Signing and verifying using the "ssh-rsa" key format are done according to the RSASSA-PKCS1-v1_5 scheme defined in [RFC 2437] using the SHA-1 hash. The SHA-1 hash is recommended in [RFC 2437]. The resulting signature is encoded as: uint32 length string "ssh-rsa" string "RSASSA-PKCS1-v1_5" string rsa_signature_blob rsa_signature_blob is an octet string of length k, where k is the length in octets of the modulus n. The encoding for the rsa_signature_blob is defined in [RFC 2437]. Discussion [RFC 2437] defines PKCS#1 v2.0. The first draft for PKCS#1 v2.1 defines an additional 'signature scheme with appendix' called RSASSA-PSS and notes: Two signature schemes with appendix are specified in this document: RSASSA-PKCS1-v1_5 and RSASSA-PSS. Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is recommended for eventual adoption in new applications. RSASSA-PKCS1-v1_5 is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to RSASSA-PSS is encouraged. RSASSA-PSS employs an encoding method based on Bellare and Rogawayas Probabilistic Signature scheme. Once PKCS#1 v2.1 is published signatures may be encoded as: Friedl [Page 2] INTERNET-DRAFT July 2000 uint32 length string "ssh-rsa" string "RSASSA-PSS" string rsa_signature_blob Security Considerations Security considerations are discussed in this memo. References [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft, draft-ietf-secsh-transport-07.txt [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet Draft, draft-ietf-secsh-architecture-05.txt [RFC 2437] B. Kaliski, J. Staddon, PKCS #1: RSA Cryptography Specifications Version 2.0. Author's Address: Markus Friedl markus@openbsd.org The OpenBSD Project Munich, Germany Friedl [Page 3] On Thu, Aug 10, 2000 at 09:34:48PM -0600, Jeff P. Van Dyke wrote: > During the working group meeting in Pittburgh, I believe > it was decided that ssh-rsa would be added as a public > key algorithm to the next rev of the transport draft. > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-07.txt > > Currently, the transport draft has the following text > for ssh-dss: > > --- > The "ssh-dss" key format has the following specific encoding: > > uint32 length > string "ssh-dss" > mpint p > mpint q > mpint g > mpint y > > Here the "p", "q", "g", and "y" parameters form the signature key blob. > > Signing and verifying using this key format are done according to the > Digital Signature Standard [FIPS-186] using the SHA-1 hash. A > description can also be found in [Schneier]. > > The resulting signature is encoded as: > > uint32 length > string "ssh-dss" > string dss_signature_blob > > dss_signature_blob is encoded as string containing "r" followed by "s" > (which are 160 bits long integers, without lengths or padding, unsigned > and in network byte order). > --- > > What is the current practice for encoding an ssh-rsa key? > > Will text describing this be included in the next rev of > the transport draft? > > Thank you. > > Jeff P. Van Dyke > jpv@vandyke.com > > > From owner-ietf-ssh@clinet.fi Mon Aug 14 10:10:56 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09107 for ; Mon, 14 Aug 2000 10:10:55 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA19508 for ietf-ssh-outgoing; Mon, 14 Aug 2000 15:01:16 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA19499 for ; Mon, 14 Aug 2000 15:01:14 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id PAA24214 for ; Mon, 14 Aug 2000 15:01:14 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id PAA01743 for ietf-ssh@clinet.fi; Mon, 14 Aug 2000 15:01:13 +0300 (EET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA14690; Fri, 11 Aug 2000 16:46:49 +0200 (MET DST) To: Tero Kivinen Cc: RJ Atkinson , Subject: Re: Is the user name always UTF-8? References: <000901c00142$10e64690$1000a8c0@viper> <4.2.0.58.20000810180105.00997890@avarice.inner.net> <14740.265.502774.332298@hutcs.cs.hut.fi> From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Aug 2000 16:46:48 +0200 In-Reply-To: Tero Kivinen's message of "Fri, 11 Aug 2000 16:41:28 +0300 (EET DST)" Message-ID: Lines: 79 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > I don't think so. The canonicalization problem is really an internal > issue for the server. If the server stores the usernames in the > password file as a Iso-latin1 strings, it needs to take the UTF-8 > encoded unicode username and convert it to iso-latin1, and if there is > no way to convert it to iso-latin1 then it just rejects the > authentication request... Ok, this approach makes sense (btw, it's the way lsh works, except that its conversion from utf8 to latin1 is broken). > So it is internal implementation issue, and there is no need to say > anything about it in the draft. The architecture draft says about user names: : They MUST be encoded using ISO 10646 UTF-8, but other encodings may : be required in some cases. It is up to the server to decide how to : map user names to accepted user names. Straight bit-wise binary : comparison is RECOMMENDED. It's the last sentence that makes canonicalization an important issue. The current spec can be interpreted as allowing the client to send non-canonical usernames, *and* also allowing the server to perform straight bit-wise comparisons when looking up user names. Which is broken. We have to require more work on one of the sides, i.e. either (i) Require clients to send canonical strings only, so that the server can use plain bit-wise comparison, or (ii) Allow clients to use any unicode representation they like, and require that the server treat all equivalent variants in the same way. Either approach is fine with me, but the spec has to specify one or the other. If we go with (i), the canonicalization rules has to be spelled out in detail. With (ii), most of those details are irrelevant, but I still think it is a good idea to specify if servers are expected to apply canonical equivalence or compatibility equivalence. I'll make a conrete proposal: Replace "Straight bit-wise binary comparison is RECOMMENDED." with "A server (or in general, any receiver of an utf-8 string) SHOULD respect unicode character equivalence". Please note that this affects also systems where only plain ascii. user names are suported! Greping UNIDATA2.TXT, there are at least 69 "strange" characters that are _canonically_ equivalent to ascii sequences. There are also 68 compatibility characters (tagged as in the file), and even more if equivalences tagged as , , etc are counted. I'll not give the whole list, but I few examples for those of you that are not familiar with unicode: 0132;LATIN CAPITAL LIGATURE IJ;Lu;0;L; 0049 004A;;;;N;LATIN CAPITAL LETTER I J;;;0133; 01F3;LATIN SMALL LETTER DZ;Ll;0;L; 0064 007A;;;;N;;;01F1;;01F2 037E;GREEK QUESTION MARK;Po;0;L;003B;;;;N;;Erotimatiko;;; 203C;DOUBLE EXCLAMATION MARK;Po;0;ON; 0021 ;;;;N;;;;; 20A8;RUPEE SIGN;Lt;0;ET; 0052 0073;;;;N;;;;; 2116;NUMERO SIGN;Lt;0;ON; 004E 006F;;;;N;NUMERO;;;; 212A;KELVIN SIGN;Lu;0;ON;004B;;;;N;DEGREES KELVIN;;;; 2160;ROMAN NUMERAL ONE;No;0;L; 0049;;;1;N;;;;2170; Of these examples, 037E and 212A are _canonically_ equvalent to ascii characters, and the latter is a character that may well occur in a user name or password. /Niels From owner-ietf-ssh@clinet.fi Tue Aug 15 20:38:32 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01471 for ; Tue, 15 Aug 2000 20:38:31 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id BAA24415 for ietf-ssh-outgoing; Wed, 16 Aug 2000 01:57:52 +0300 Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.29.146]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id BAA24412 for ; Wed, 16 Aug 2000 01:57:50 +0300 Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.3/8.9.3) id BAA11746; Wed, 16 Aug 2000 01:54:54 +0300 From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14745.51774.331706.61875@asgard.tky.hut.fi> Date: Wed, 16 Aug 2000 01:54:54 +0300 (EEST) To: Markus Friedl Cc: "Jeff P. Van Dyke" , ietf-ssh@clinet.fi, niels@openbsd.org, sjl@ssh.com, ylo@ssh.com, tri@ssh.com Subject: Re: Adding ssh-rsa to the transport draft... In-Reply-To: <20000811132956.A23394@folly.informatik.uni-erlangen.de> References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> <20000811132956.A23394@folly.informatik.uni-erlangen.de> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit Your proposal: Markus Friedl, on August 11. 2000, wrote: : The "ssh-rsa" key format has the following specific encoding: : : uint32 length : string "ssh-rsa" : mpint e : mpint n : [SNIP] : uint32 length : string "ssh-rsa" : string "RSASSA-PKCS1-v1_5" : string rsa_signature_blob [SNIP] : uint32 length : string "ssh-rsa" : string "RSASSA-PSS" : string rsa_signature_blob Our proposal (excerpt from draft (not yet submitted)): --snip-- The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n Here the "e" and "n" parameters form the signature key blob. Signing and verifying using this key format is done according to [Schneier] and [PKCS1] using the SHA-1 hash. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing "t1" (which is an integer, without lengths or padding, unsigned and in network byte order). --snap-- In my, and Tatu's (among others), opinion, the extra field specifying the signature scheme should not be put to the draft, as it would be inconsistent with the "ssh-dss" method, and with the overall spirit in declaring these key formattings and signature formats. If, at some point in the future, the "RSASSA-PSS" method is standardized and we (as a community) want to start using it in SSH 2 protocol, we can describe a format "ssh-rsa-v2" or something to that effect, which doesn't pollute the draft. (this would apply to "ssh-dss" as well, of course) Regards, -- [sjl@ssh.com -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Corp http://www.ssh.com/] From owner-ietf-ssh@clinet.fi Thu Aug 17 07:18:37 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23581 for ; Thu, 17 Aug 2000 07:18:36 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA02543 for ietf-ssh-outgoing; Thu, 17 Aug 2000 12:36:32 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA02536 for ; Thu, 17 Aug 2000 12:36:30 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id MAA24927 for ; Thu, 17 Aug 2000 12:36:30 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id MAA13646 for ietf-ssh@clinet.fi; Thu, 17 Aug 2000 12:36:29 +0300 (EET DST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 378F81244; Fri, 11 Aug 2000 13:29:57 +0200 (CEST) Date: Fri, 11 Aug 2000 13:29:56 +0200 From: Markus Friedl To: "Jeff P. Van Dyke" Cc: ietf-ssh@clinet.fi, niels@openbsd.org Subject: Re: Adding ssh-rsa to the transport draft... Message-ID: <20000811132956.A23394@folly.informatik.uni-erlangen.de> References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <000001c00345$23c1bce0$0201a8c0@vandyke.com>; from jpv@vandyke.com on Thu, Aug 10, 2000 at 09:34:48PM -0600 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk i tried to send this before but it did not appear on the list: Network Working Group Markus Friedl INTERNET-DRAFT The OpenBSD Project Expires in six months July 2000 A RSA Key and Signature Encoding for the SSH Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Please direct comments to one of the authors (for the authors contact information, see the end of this document). Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts draft documents are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract The SSH Transport Layer Protocol [SSH-TRANS] defines several encodings for Public Key Algorithms. However, it fails to provide a specifications for the widely used RSA algorithm. This document specifies both how RSA keys and RSA signatures are encoded. The Encoding The name for this public key encoding method is "ssh-rsa". The encoding for RSA keys and signatures is similar to the "ssh-dss" key format defined in the SSH Transport Layer Protocol document [SSH- TRANS]. The used data types are specified in the SSH Protocol Architecture document [SSH-ARCH]. Friedl [Page 1] INTERNET-DRAFT July 2000 The "ssh-rsa" key format has the following specific encoding: uint32 length string "ssh-rsa" mpint e mpint n The parameters "e" and "n" are the public key for the RSA algorithm. They are used to verify signatures created by the corresponding private key. The PKCS#1 standard [RFC 2437] describes signature and verification operations for RSA. Signing and verifying using the "ssh-rsa" key format are done according to the RSASSA-PKCS1-v1_5 scheme defined in [RFC 2437] using the SHA-1 hash. The SHA-1 hash is recommended in [RFC 2437]. The resulting signature is encoded as: uint32 length string "ssh-rsa" string "RSASSA-PKCS1-v1_5" string rsa_signature_blob rsa_signature_blob is an octet string of length k, where k is the length in octets of the modulus n. The encoding for the rsa_signature_blob is defined in [RFC 2437]. Discussion [RFC 2437] defines PKCS#1 v2.0. The first draft for PKCS#1 v2.1 defines an additional 'signature scheme with appendix' called RSASSA-PSS and notes: Two signature schemes with appendix are specified in this document: RSASSA-PKCS1-v1_5 and RSASSA-PSS. Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is recommended for eventual adoption in new applications. RSASSA-PKCS1-v1_5 is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to RSASSA-PSS is encouraged. RSASSA-PSS employs an encoding method based on Bellare and Rogawayas Probabilistic Signature scheme. Once PKCS#1 v2.1 is published signatures may be encoded as: Friedl [Page 2] INTERNET-DRAFT July 2000 uint32 length string "ssh-rsa" string "RSASSA-PSS" string rsa_signature_blob Security Considerations Security considerations are discussed in this memo. References [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft, draft-ietf-secsh-transport-07.txt [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet Draft, draft-ietf-secsh-architecture-05.txt [RFC 2437] B. Kaliski, J. Staddon, PKCS #1: RSA Cryptography Specifications Version 2.0. Author's Address: Markus Friedl markus@openbsd.org The OpenBSD Project Munich, Germany Friedl [Page 3] On Thu, Aug 10, 2000 at 09:34:48PM -0600, Jeff P. Van Dyke wrote: > During the working group meeting in Pittburgh, I believe > it was decided that ssh-rsa would be added as a public > key algorithm to the next rev of the transport draft. > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-07.txt > > Currently, the transport draft has the following text > for ssh-dss: > > --- > The "ssh-dss" key format has the following specific encoding: > > uint32 length > string "ssh-dss" > mpint p > mpint q > mpint g > mpint y > > Here the "p", "q", "g", and "y" parameters form the signature key blob. > > Signing and verifying using this key format are done according to the > Digital Signature Standard [FIPS-186] using the SHA-1 hash. A > description can also be found in [Schneier]. > > The resulting signature is encoded as: > > uint32 length > string "ssh-dss" > string dss_signature_blob > > dss_signature_blob is encoded as string containing "r" followed by "s" > (which are 160 bits long integers, without lengths or padding, unsigned > and in network byte order). > --- > > What is the current practice for encoding an ssh-rsa key? > > Will text describing this be included in the next rev of > the transport draft? > > Thank you. > > Jeff P. Van Dyke > jpv@vandyke.com > > > From owner-ietf-ssh@clinet.fi Thu Aug 17 07:22:50 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23654 for ; Thu, 17 Aug 2000 07:22:50 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA02900 for ietf-ssh-outgoing; Thu, 17 Aug 2000 12:38:28 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA02864 for ; Thu, 17 Aug 2000 12:38:21 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id MAA25081 for ; Thu, 17 Aug 2000 12:38:20 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id MAA12838 for ietf-ssh@clinet.fi; Thu, 17 Aug 2000 12:38:20 +0300 (EET DST) Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA04878; Fri, 11 Aug 2000 16:41:29 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 11 Aug 2000 16:41:28 +0300 (EET DST) From: Tero Kivinen To: nisse@lysator.liu.se (Niels Mцller) Cc: RJ Atkinson , Subject: Re: Is the user name always UTF-8? In-Reply-To: References: <000901c00142$10e64690$1000a8c0@viper> <4.2.0.58.20000810180105.00997890@avarice.inner.net> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14740.265.502774.332298@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 7 min X-Total-Time: 6 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id QAA29368 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit Niels Mцller writes: > You could push canonicalisation to the recieving side, i.e. specify > that the reciever is required to handle all variants. If the reciever > implements this by canonicalization of received names, > canonicalization must be done *after* signature verification, but > that's quite obvious and should not be a problem. The username is only a string of characters from the client point of view. The server is the only one that tries to compare it to something it has in its internal database (password file etc). > At least I don't see that non-canonical strings on the wire causes any > fundamental problems, as long as the recievers do the right thing. Correct. > > There is likely some UNICODE Tech Report that could be used for > > canonicalisation and cited in the applicable SSH RFCs. My guess is > > that the Application ADs have real opinions about internationalisation > > and canonicalisation. It might be easier to seek advice now > > rather than have RFCs derail during IESG review later on, IMHO. > > I have the unicode-3.0 book in front of me. The problem is that there > are several ways to "canonicalize" unicode strings: > > * Are short or long representations of characters like "ц" preferred? > > * What to do with compatibility characters? (I'd think it's best to > map them to non-compatibility characters as well, i.e. using the > compatibility-equality rather than canonical-equality). > > * What to do with hangul syllables. Compose or decompose? > > So the details must be spelled out, somewhere. I don't think so. The canonicalization problem is really an internal issue for the server. If the server stores the usernames in the password file as a Iso-latin1 strings, it needs to take the UTF-8 encoded unicode username and convert it to iso-latin1, and if there is no way to convert it to iso-latin1 then it just rejects the authentication request... So it is internal implementation issue, and there is no need to say anything about it in the draft. > And then there's utf-8, but it should be straight forward to say that > an implementation must always use the shortest utf-8 sequence > representing a unicode character (that's the usual way to use utf-8, I > guess, but utf-8 decoders in other contexts may be more forgiving). That doesn't affect the protocol either at all. Everything that is signed, hashed etc in the protocol are done in the same octect string representation they had on the wire and thats it. After that it is servers duty to do whatever it likes to convert that username to the format it is internally using. Of course we might want to add that kind of text just to remove one possible place which might cause interoperability problems. -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ssh@clinet.fi Thu Aug 17 07:29:26 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23758 for ; Thu, 17 Aug 2000 07:29:25 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA04708 for ietf-ssh-outgoing; Thu, 17 Aug 2000 12:47:40 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA04702 for ; Thu, 17 Aug 2000 12:47:39 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id MAA25446 for ; Thu, 17 Aug 2000 12:47:39 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id MAA14201 for ietf-ssh@clinet.fi; Thu, 17 Aug 2000 12:47:38 +0300 (EET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA14690; Fri, 11 Aug 2000 16:46:49 +0200 (MET DST) To: Tero Kivinen Cc: RJ Atkinson , Subject: Re: Is the user name always UTF-8? References: <000901c00142$10e64690$1000a8c0@viper> <4.2.0.58.20000810180105.00997890@avarice.inner.net> <14740.265.502774.332298@hutcs.cs.hut.fi> From: nisse@lysator.liu.se (Niels Mцller) Date: 11 Aug 2000 16:46:48 +0200 In-Reply-To: Tero Kivinen's message of "Fri, 11 Aug 2000 16:41:28 +0300 (EET DST)" Message-ID: Lines: 79 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Tero Kivinen writes: > I don't think so. The canonicalization problem is really an internal > issue for the server. If the server stores the usernames in the > password file as a Iso-latin1 strings, it needs to take the UTF-8 > encoded unicode username and convert it to iso-latin1, and if there is > no way to convert it to iso-latin1 then it just rejects the > authentication request... Ok, this approach makes sense (btw, it's the way lsh works, except that its conversion from utf8 to latin1 is broken). > So it is internal implementation issue, and there is no need to say > anything about it in the draft. The architecture draft says about user names: : They MUST be encoded using ISO 10646 UTF-8, but other encodings may : be required in some cases. It is up to the server to decide how to : map user names to accepted user names. Straight bit-wise binary : comparison is RECOMMENDED. It's the last sentence that makes canonicalization an important issue. The current spec can be interpreted as allowing the client to send non-canonical usernames, *and* also allowing the server to perform straight bit-wise comparisons when looking up user names. Which is broken. We have to require more work on one of the sides, i.e. either (i) Require clients to send canonical strings only, so that the server can use plain bit-wise comparison, or (ii) Allow clients to use any unicode representation they like, and require that the server treat all equivalent variants in the same way. Either approach is fine with me, but the spec has to specify one or the other. If we go with (i), the canonicalization rules has to be spelled out in detail. With (ii), most of those details are irrelevant, but I still think it is a good idea to specify if servers are expected to apply canonical equivalence or compatibility equivalence. I'll make a conrete proposal: Replace "Straight bit-wise binary comparison is RECOMMENDED." with "A server (or in general, any receiver of an utf-8 string) SHOULD respect unicode character equivalence". Please note that this affects also systems where only plain ascii. user names are suported! Greping UNIDATA2.TXT, there are at least 69 "strange" characters that are _canonically_ equivalent to ascii sequences. There are also 68 compatibility characters (tagged as in the file), and even more if equivalences tagged as , , etc are counted. I'll not give the whole list, but I few examples for those of you that are not familiar with unicode: 0132;LATIN CAPITAL LIGATURE IJ;Lu;0;L; 0049 004A;;;;N;LATIN CAPITAL LETTER I J;;;0133; 01F3;LATIN SMALL LETTER DZ;Ll;0;L; 0064 007A;;;;N;;;01F1;;01F2 037E;GREEK QUESTION MARK;Po;0;L;003B;;;;N;;Erotimatiko;;; 203C;DOUBLE EXCLAMATION MARK;Po;0;ON; 0021 ;;;;N;;;;; 20A8;RUPEE SIGN;Lt;0;ET; 0052 0073;;;;N;;;;; 2116;NUMERO SIGN;Lt;0;ON; 004E 006F;;;;N;NUMERO;;;; 212A;KELVIN SIGN;Lu;0;ON;004B;;;;N;DEGREES KELVIN;;;; 2160;ROMAN NUMERAL ONE;No;0;L; 0049;;;1;N;;;;2170; Of these examples, 037E and 212A are _canonically_ equvalent to ascii characters, and the latter is a character that may well occur in a user name or password. /Niels From owner-ietf-ssh@clinet.fi Thu Aug 17 07:31:43 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23878 for ; Thu, 17 Aug 2000 07:31:42 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id MAA01514 for ietf-ssh-outgoing; Thu, 17 Aug 2000 12:31:00 +0300 Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id MAA01506 for ; Thu, 17 Aug 2000 12:30:57 +0300 Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id MAA24710 for ; Thu, 17 Aug 2000 12:30:56 +0300 (EEST) Received: (from sshlist@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id MAA26366 for ietf-ssh@clinet.fi; Thu, 17 Aug 2000 12:30:56 +0300 (EET DST) Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.9.3/8.9.3) id QAA06643; Wed, 9 Aug 2000 16:55:11 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 9 Aug 2000 16:55:11 +0300 (EET DST) From: Tero Kivinen To: "Jeff P. Van Dyke" Cc: Subject: Is the user name always UTF-8? In-Reply-To: <000901c00142$10e64690$1000a8c0@viper> References: <000901c00142$10e64690$1000a8c0@viper> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14737.24826.39101.760521@hutcs.cs.hut.fi> Organization: Helsinki University of Technology X-Edit-Time: 5 min X-Total-Time: 7 min Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.clinet.fi id QAA24000 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 8bit Jeff P. Van Dyke writes: > If the "user name" should not be encoded in UTF-8, the > first one should be corrected. > > If they all should be encoded in UTF-8, I think the > documentation would be clearer if each one of them > read: I think we should encode all of them in UTF-8 ISO-10646. We might need to add some text saying about the canonicalization process, i.e the server is assumed to do canonicalization to any format it is using internally. Client can send it out in any format it likes. I.e if clinet sends either "Ylnen" or "Ylonen" the server should convert them to the format it is using internally (lets say it is using iso latin 1, so it should convert both of those to "Ylцnen". We don't have that much problem there than they have in the idn wg, because usernames are case sensitive, i.e we don't need to specify how to lowercase them... -- kivinen@iki.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ssh@clinet.fi Tue Aug 22 01:22:28 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17659 for ; Tue, 22 Aug 2000 01:22:26 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id GAA21910 for ietf-ssh-outgoing; Tue, 22 Aug 2000 06:21:35 +0300 Received: from VisibilityFX (mid-tgn-nen-vty36.as.wcom.net [216.192.69.36]) by mail.clinet.fi (8.9.3/8.9.3) with SMTP id GAA21884 for ; Tue, 22 Aug 2000 06:21:17 +0300 Date: Tue, 22 Aug 2000 06:21:17 +0300 From: Political Affairs Resource Kit To: Message-Id: <419.436759.97303808rauch@visibilityfx.com> Subject: Free, Interactive Refugees of the World Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit The Public Affairs Resource Center of VisibilityFX (www.visibilityfx.com/PARK) introduces the Refugees of the World Screensaver. This quick loading screensaver features a stunning animated digital image of the world with statistical data on refugees around the world. It also includes an interactive test center to test your knowledge about refugee issues. This screensaver is the first and only Refugee screensaver and its yours, free! Simply fill out the form at (www.visibilityfx.com/PARK) and you will immediately be taken to the download area. As a kick off to its new Interactive web site VisibilityFX (www.visibilityFX.com) welcomes you to download the screensaver and while your at our site take a look around and observe the various services VisibilityFX can provide your organization. The site is very appealing, uses the latest technology, and features a wild Flash intro. Again, enjoy the screensaver and we hope to hear from you soon. This is a targeted mailing of VisibilityFX. If you have received this mailing in error or would like to be removed from the mailing list please send an email to remove@visibilityfx.com VisibilityFX 2230 George C. Marshall Drive 729 Falls Church, VA 22043 From owner-ietf-ssh@clinet.fi Tue Aug 22 12:33:21 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10279 for ; Tue, 22 Aug 2000 12:33:20 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA08639 for ietf-ssh-outgoing; Tue, 22 Aug 2000 17:36:50 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA08630 for ; Tue, 22 Aug 2000 17:36:45 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 01DF324012D1; Tue, 22 Aug 2000 16:36:44 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id QAA10631; Tue, 22 Aug 2000 16:36:43 +0200 (MET DST) To: Sami Lehtinen Cc: Markus Friedl , "Jeff P. Van Dyke" , ietf-ssh@clinet.fi, niels@openbsd.org, sjl@ssh.com, ylo@ssh.com, tri@ssh.com Subject: Re: Adding ssh-rsa to the transport draft... References: <000001c00345$23c1bce0$0201a8c0@vandyke.com> <20000811132956.A23394@folly.informatik.uni-erlangen.de> <14745.51774.331706.61875@asgard.tky.hut.fi> From: nisse@lysator.liu.se (Niels Mцller) Date: 22 Aug 2000 16:36:43 +0200 In-Reply-To: Sami Lehtinen's message of "Wed, 16 Aug 2000 01:54:54 +0300 (EEST)" Message-ID: Lines: 74 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Sami Lehtinen writes: > Your proposal: > > Markus Friedl, on August 11. 2000, wrote: > : The "ssh-rsa" key format has the following specific encoding: > : > : uint32 length > : string "ssh-rsa" > : mpint e > : mpint n I think the length field is redundant and should be deleted (just as for ssh-dss). Likewise for the signature encodings. > Our proposal (excerpt from draft (not yet submitted)): > --snip-- > The "ssh-rsa" key format has the following specific encoding: > > string "ssh-rsa" > mpint e > mpint n > > Here the "e" and "n" parameters form the signature key > blob. I also prefer this simpler format. > Signing and verifying using this key format is done according to > [Schneier] and [PKCS1] using the SHA-1 hash. > > The resulting signature is encoded as follows: > > string "ssh-rsa" > string rsa_signature_blob > > rsa_signature_blob is encoded as a string containing "t1" > (which is an integer, without lengths or padding, unsigned and in > network byte order). This is not clear enough. What is t1? I have read PKCS#1.5 (aka RFC 2437) a few times, and I have actually implemented it before, but I find the document a lot messier and harder to understand than the secsh drafts. The way I interpret this, you first build a DER-encoded DigestInfo containing the sha1 OBJECT IDENTIFIER and the hash of the data to be signed (this usually implies double hashing, just like for ssh-dss, right?). This is converted to an integer and padded (as described in RFC 2437, section 9.2.1), and raised to the secret exponent. As the signature blob is simply the encoding of an integer, I think it would be better to encode it as a bignum, for consistency with the secsh-architecture document. I.e. I would propose the following encoding of signatures: string "ssh-rsa" bignum rsa_signature_blob > In my, and Tatu's (among others), opinion, the extra field specifying > the signature scheme should not be put to the draft, as it would be > inconsistent with the "ssh-dss" method, and with the overall spirit in > declaring these key formattings and signature formats. I agree. One identifier to identify and algorithm and algorithm variant should be enough (it's possible to use the same key pair for several variants; in lsh the same key can be used for both both "spki" and "ssh-dss"). As for name of the algorithm, I think "rsa-pkcs1" or "rsa-pkcs1-sha1" would be more descriptive than "ssh-rsa", even if we only use the pkcs#1 signature mechanism and not its encodings of keys. /Niels From owner-ietf-ssh@clinet.fi Wed Aug 23 00:01:59 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22423 for ; Wed, 23 Aug 2000 00:01:59 -0400 (EDT) From: owner-ietf-ssh@clinet.fi Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id DAA23312 for ietf-ssh-outgoing; Wed, 23 Aug 2000 03:42:08 +0300 Received: from smtp.clinet.fi (smtp.clinet.fi [194.100.0.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id DAA23307; Wed, 23 Aug 2000 03:42:07 +0300 Received: from unknown ([212.45.12.107]) by smtp.clinet.fi (8.9.3/8.9.3) with SMTP id DAA00231; Wed, 23 Aug 2000 03:37:20 +0300 (EEST) Message-Id: <200008230037.DAA00231@smtp.clinet.fi> Subject: Корпоративный сайт и электронный магазин за 2 дня Date: Ср, 23 авг 2000 01:06:06 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk http://www.bsns.ru Визуальный web-инструмент по быстрому созданию сложных web-сайтов и электронных магазинов для пользователей без специальных знаний Удобный административный интерфейс позволяет быстро создавать структуру, web-страницы и витрины-прайсы электронных магазинов Новая технология экономит средства и время. Никто вам не сможет создать на заказ такую мощную систему. (за пару дней) Это готовое решение. Если вы хотите: 1. Быстро создать сайт для компании со всеми необходимыми функциями за несколько дней Web-страницы Гостевые книги Доски объявлений Формы запросов Форумы Новости Голосования 2. Иметь подробную статистику посещений с рейтингом каждой страницы для каждого посетителя 3. Возможность оптовой и розничной торговли (электронный магазин) Системы учета скидок Работа с двумя валютами Выписка любых документов (счета и квитанции к оплате и договора) Учет налогов Любое число способов доставки 4. Вы хотите снизить издержки на содержание сайта и электронного магазина в пять и более раз 5. Вы не хотите знать никаких технических тонкостей. 6. Получить полный контроль над содержанием сайта 7. Оперативность в обновлении информации Вам поможет Интернет Бизнес конструктор. Уникальный инструмент с визуальным web-интерфейсом Для пользователей без специальных знаний. С управлением сложного сайта и магазина справится даже школьник. Моментальное построение структуры и страниц без знания программирования. При ценах равных стоимости разработки статичных небольших сайтов с нашей системой вы получите в десять раз больше воможностей н оперативности не зависимо от размеров сайта. Подробная информация на сайте http://www.bsns.ru Возможен бартер, в том чиcле на рекламу From owner-ietf-ssh@clinet.fi Fri Aug 25 08:36:07 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18738 for ; Fri, 25 Aug 2000 08:36:06 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id NAA04179 for ietf-ssh-outgoing; Fri, 25 Aug 2000 13:28:15 +0300 Received: from fw.ipc.com (firewall-user@psimail.ipc.com [38.162.88.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id NAA04163 for ; Fri, 25 Aug 2000 13:28:11 +0300 Received: by fw.ipc.com; id GAA05731; Fri, 25 Aug 2000 06:28:10 -0400 (EDT) Received: from lonukmsx1ipc.ipc.com(159.63.61.7) by fw.ipc.com via smap (4.1) id xma005702; Fri, 25 Aug 00 06:27:52 -0400 Received: by lonukmsx1ipc.ipc.com with Internet Mail Service (5.5.2448.0) id <33D0FCNA>; Fri, 25 Aug 2000 11:28:48 +0100 Message-ID: <195C7A568E93D311AE700008C7B989318CBF59@lonukmsx1ipc.ipc.com> From: "Igwe, Harrison" To: ietf-ssh@clinet.fi Date: Fri, 25 Aug 2000 11:28:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, I have been trying to use ssh for remote connections . My questions are 1 Can I run ssh2 client on windows 95 connecting to unix server running ssh2 2 When I try connecting to the unix server it comes up with the error The host is unknown. Does anyone know how to solve that ? Cheers Harrison Igwe Harrison_Igwe@IXnet.com From owner-ietf-ssh@clinet.fi Fri Aug 25 09:47:25 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20516 for ; Fri, 25 Aug 2000 09:47:24 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA25709 for ietf-ssh-outgoing; Fri, 25 Aug 2000 15:05:57 +0300 Received: from sp2n17-t.missouri.edu (sp2n17-t.missouri.edu [128.206.2.27]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA25697 for ; Fri, 25 Aug 2000 15:05:54 +0300 Received: from tortoise15 (Mizzou-AS-228019.missouri.edu [128.206.228.19]) by sp2n17-t.missouri.edu (8.9.0/8.9.0) with SMTP id HAA41226; Fri, 25 Aug 2000 07:05:17 -0500 Message-ID: <004901c00e8c$edaea570$13e4ce80@tortoise15> From: "Calvin Bebermeyer" To: "Igwe, Harrison" , References: <195C7A568E93D311AE700008C7B989318CBF59@lonukmsx1ipc.ipc.com> Subject: Re: Date: Fri, 25 Aug 2000 07:06:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Transfer-Encoding: 7bit You should be able to use Win9X. :) That message seems to indicate that your key(s) did not generate on the Win95 box. Which ssh2 are you using on your Win95 machine? Calvin Bebermeyer 2000-2001 MU-ACM Program Chair calvinb@acm.org ----- Original Message ----- From: "Igwe, Harrison" To: Sent: Friday, August 25, 2000 5:28 AM > Hi, > I have been trying to use ssh for remote connections . > My questions are > 1 Can I run ssh2 client on windows 95 connecting to unix server > running ssh2 > 2 When I try connecting to the unix server it comes up with the error > The host is unknown. > > Does anyone know how to solve that ? > > Cheers > > Harrison Igwe > Harrison_Igwe@IXnet.com From owner-ietf-ssh@clinet.fi Fri Aug 25 10:03:29 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20841 for ; Fri, 25 Aug 2000 10:03:28 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA29609 for ietf-ssh-outgoing; Fri, 25 Aug 2000 15:25:23 +0300 Received: from fw.ipc.com (firewall-user@psimail.ipc.com [38.162.88.2]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA29596 for ; Fri, 25 Aug 2000 15:25:19 +0300 Received: by fw.ipc.com; id IAA24172; Fri, 25 Aug 2000 08:25:13 -0400 (EDT) Received: from lonukmsx1ipc.ipc.com(159.63.61.7) by fw.ipc.com via smap (4.1) id xma024027; Fri, 25 Aug 00 08:24:46 -0400 Received: by lonukmsx1ipc.ipc.com with Internet Mail Service (5.5.2448.0) id <33D0FCRL>; Fri, 25 Aug 2000 13:25:41 +0100 Message-ID: <195C7A568E93D311AE700008C7B989318CC0BE@lonukmsx1ipc.ipc.com> From: "Igwe, Harrison" To: "Igwe, Harrison" , ietf-ssh@clinet.fi, Calvin Bebermeyer Subject: RE: SShs Date: Fri, 25 Aug 2000 13:25:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi Calvin, Thanks for your reply. What am running on the Win95 is SSH Secure Shell 2.2.0 (Build 123). This is just an executable I installed and would not know if the keys were generated . Cheers, Harrison. > ---------- > From: Calvin Bebermeyer[SMTP:calvinb@acm.org] > Sent: 25 August 2000 13:06 > To: Igwe, Harrison; ietf-ssh@clinet.fi > Subject: Re: > > You should be able to use Win9X. :) > > That message seems to indicate that your key(s) did not generate on > the Win95 box. > > Which ssh2 are you using on your Win95 machine? > > Calvin Bebermeyer > 2000-2001 MU-ACM Program Chair > calvinb@acm.org > ----- Original Message ----- > From: "Igwe, Harrison" > To: > Sent: Friday, August 25, 2000 5:28 AM > > > > Hi, > > I have been trying to use ssh for remote connections . > > My questions are > > 1 Can I run ssh2 client on windows 95 connecting to unix server > > running ssh2 > > 2 When I try connecting to the unix server it comes up with the > error > > The host is unknown. > > > > Does anyone know how to solve that ? > > > > Cheers > > > > Harrison Igwe > > Harrison_Igwe@IXnet.com > From owner-ietf-ssh@clinet.fi Fri Aug 25 10:41:31 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21587 for ; Fri, 25 Aug 2000 10:41:30 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id PAA03530 for ietf-ssh-outgoing; Fri, 25 Aug 2000 15:59:16 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id PAA03516 for ; Fri, 25 Aug 2000 15:59:12 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 0227624012DF; Fri, 25 Aug 2000 14:59:08 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id OAA13052; Fri, 25 Aug 2000 14:59:08 +0200 (MET DST) To: "Igwe, Harrison" Cc: ietf-ssh@clinet.fi Subject: Re: none References: <195C7A568E93D311AE700008C7B989318CBF59@lonukmsx1ipc.ipc.com> From: nisse@lysator.liu.se (Niels Mцller) Date: 25 Aug 2000 14:59:08 +0200 In-Reply-To: "Igwe, Harrison"'s message of "Fri, 25 Aug 2000 11:28:44 +0100" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk "Igwe, Harrison" writes: > I have been trying to use ssh for remote connections . > My questions are > 1 Can I run ssh2 client on windows 95 connecting to unix server > running ssh2 I think you can, even if I have never done that. I'm assuming you mean that you have sshd2 (i.e. the daemon) running on the unix server. > 2 When I try connecting to the unix server it comes up with the error > The host is unknown. You should probably mail the support line/mailing list for your particular ssh2 client, or use the comp.security.ssh newsgroup. This mailing list is for discussions about the ssh2 protocol internals. Regards, /Niels From owner-ietf-ssh@clinet.fi Fri Aug 25 11:52:00 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23160 for ; Fri, 25 Aug 2000 11:51:59 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id RAA12548 for ietf-ssh-outgoing; Fri, 25 Aug 2000 17:08:03 +0300 Received: from umc-mail01.missouri.edu (umc-mail01.missouri.edu [128.206.10.216]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id RAA12544 for ; Fri, 25 Aug 2000 17:08:01 +0300 Received: from sp2n23-t.missouri.edu (sp2n23.missouri.edu [128.206.2.84]) by umc-mail01.missouri.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RL5N3VXX; Fri, 25 Aug 2000 09:07:59 -0500 Date: Fri, 25 Aug 2000 09:07:40 -0500 (CDT) From: Calvin Bebermeyer X-Sender: cwbb73@sp2n23-t.missouri.edu Reply-To: cwbb73@mizzou.edu To: nisse@lysator.liu.se cc: ietf-ssh@clinet.fi Subject: Re: none In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk On 25 Aug 2000 nisse@lysator.liu.se wrote: > "Igwe, Harrison" writes: > > > I have been trying to use ssh for remote connections . > > My questions are > > 1 Can I run ssh2 client on windows 95 connecting to unix server > > running ssh2 > > I think you can, even if I have never done that. I'm assuming you mean > that you have sshd2 (i.e. the daemon) running on the unix server. > > > 2 When I try connecting to the unix server it comes up with the error > > The host is unknown. > > You should probably mail the support line/mailing list for your > particular ssh2 client, or use the comp.security.ssh newsgroup. This > mailing list is for discussions about the ssh2 protocol internals. > > Regards, > /Niels > quite true about the list directions. I did not notice which list was used ... until now. Sorry :) Calvin Bebermeyer 2000-2001 MU-ACM Program Chair calvinb@acm.org From owner-ietf-ssh@clinet.fi Sun Aug 27 03:54:48 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05955 for ; Sun, 27 Aug 2000 03:54:47 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id JAA21045 for ietf-ssh-outgoing; Sun, 27 Aug 2000 09:14:11 +0300 Received: from smtp.clinet.fi (smtp.clinet.fi [194.100.0.12]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id JAA21042 for ; Sun, 27 Aug 2000 09:14:10 +0300 Received: from 6x435fy1.Brmark1.com (Brmark1.com [209.61.156.91] (may be forged)) by smtp.clinet.fi (8.9.3/8.9.3) with SMTP id JAA50263 for ; Sun, 27 Aug 2000 09:08:42 +0300 (EEST) Date: Sun, 27 Aug 2000 16:28:37 -0600 From: Luxury.Oceavview@unbtl.msn.com X-Mailer: Luxury Oceavview@msn.com Message-Id: To: Luxury@smtp.clinet.fi, Oceavview@tetn.msn.com Subject: Here's your free Florida tickets thanks. -wpey MIME-Version: 1.0 X-Encoding: MIME Content-Type: multipart/alternative; boundary="----=_NextPart_0873186162620" Reply-To: Luxury.Oceavview@msn.com Sender: owner-ietf-ssh@clinet.fi Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_0873186162620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_0873186162620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Click Here for more information


Click Here for more information

------=_NextPart_0873186162620-- From owner-ietf-ssh@clinet.fi Mon Aug 28 07:00:13 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02778 for ; Mon, 28 Aug 2000 07:00:12 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id LAA22498 for ietf-ssh-outgoing; Mon, 28 Aug 2000 11:44:15 +0300 Received: from blaze.cs.jhu.edu (root@blaze.cs.jhu.edu [128.220.13.50]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id LAA22451 for ; Mon, 28 Aug 2000 11:44:01 +0300 Received: from masters1.cs.jhu.edu.cs.yp (masters1.cs.jhu.edu [128.220.223.217]) by blaze.cs.jhu.edu (8.9.3/8.9.3) with SMTP id EAA17714 for ; Mon, 28 Aug 2000 04:43:59 -0400 (EDT) Received: from localhost by masters1.cs.jhu.edu.cs.yp (SMI-8.6/SMI-SVR4) id EAA22879; Mon, 28 Aug 2000 04:43:02 -0400 Date: Mon, 28 Aug 2000 04:43:02 -0400 (EDT) From: Stefan Mangard To: ietf-ssh@clinet.fi Subject: SSH and DNSSEC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Hi, I have been working an a DNSSEC implementation for SSH. A description of the project as it is till now can be found at http://www.cs.jhu.edu/~smang/sshproject.html Since I read on your web site that it is a goal of the ssh working group to utilize infrastructures such as DNSSEC, I wanted to ask if there has already been done anything similar by your group. Greetings, Stefan Mangard From owner-ietf-ssh@clinet.fi Mon Aug 28 09:26:18 2000 Received: from mail.clinet.fi (mail.clinet.fi [194.100.0.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07930 for ; Mon, 28 Aug 2000 09:26:17 -0400 (EDT) Received: (from majordom@localhost) by mail.clinet.fi (8.9.3/8.9.3) id OAA26344 for ietf-ssh-outgoing; Mon, 28 Aug 2000 14:19:27 +0300 Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.clinet.fi (8.9.3/8.9.3) with ESMTP id OAA26259 for ; Mon, 28 Aug 2000 14:19:09 +0300 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id C50C024012CE; Mon, 28 Aug 2000 13:19:07 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id NAA13825; Mon, 28 Aug 2000 13:19:07 +0200 (MET DST) To: Stefan Mangard Cc: ietf-ssh@clinet.fi Subject: Re: SSH and DNSSEC References: From: nisse@lysator.liu.se (Niels Mцller) Date: 28 Aug 2000 13:19:07 +0200 In-Reply-To: Stefan Mangard's message of "Mon, 28 Aug 2000 04:43:02 -0400 (EDT)" Message-ID: Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Stefan Mangard writes: > I have been working an a DNSSEC implementation for SSH. A description of > the project as it is till now can be found at > http://www.cs.jhu.edu/~smang/sshproject.html I don't know of any similar projects. But distributing host keys via DNSSEC sounds like a good thing. Even if I'm not as familiar with DNSSEC as I'd wish. What resolver are you using, and how is is the verification work divided between the resolver library and your openssh client? /Niels