From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 03:17:03 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21278 for ; Tue, 1 May 2001 03:17:02 -0400 (EDT) Received: (qmail 23424 invoked by uid 605); 1 May 2001 07:16:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23414 invoked from network); 1 May 2001 07:16:12 -0000 Received: from tnt.isi.edu (128.9.128.128) by mail.netbsd.org with SMTP; 1 May 2001 07:16:12 -0000 Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f417GtP15808; Tue, 1 May 2001 00:16:55 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f417Gt817378; Tue, 1 May 2001 00:16:55 -0700 Message-Id: <200105010716.f417Gt817378@zed.isi.edu> Subject: Re: another trademark application To: sommerfeld@east.sun.com Date: Tue, 1 May 2001 00:16:55 -0700 (PDT) Cc: ietf-ssh@netbsd.org In-Reply-To: <200104272304.f3RN4K914742@thunk.east.sun.com> from "Bill Sommerfeld" at Apr 27, 2001 07:04:19 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Different Class, should not be an issue. % % I'm not quite sure what to think of this.... % % US trademark application serial number 76217635 is for the word mark % "ssh", applied for by % % S.S.H. Medical Limited COMPANY AUSTRALIA % Unit 34, 2 Railway Parade % Lidcomber % New South Wales 2141 % AUSTRALIA % % covering: % % IC 010. US 026 039 044. G & S: MEDICAL AND VETERINARY APPARATUS, % NAMELY SPECULA, SPATULAS, PROCTOSCOPES, ENDSCOPES, COLOSCOPES AND % ANALSCOPES; DISPOSABLE COMPONENTS, PARTS AND ACCESSORIES FOR ALL THE % FOREGOING APPARATUS % % - Bill % -- --bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 03:54:15 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21453 for ; Tue, 1 May 2001 03:54:14 -0400 (EDT) Received: (qmail 29706 invoked by uid 605); 1 May 2001 07:53:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29699 invoked from network); 1 May 2001 07:53:24 -0000 Received: from ns1.crl.go.jp (133.243.3.1) by mail.netbsd.org with SMTP; 1 May 2001 07:53:24 -0000 Received: from crlgw1.crl.go.jp ([133.243.18.250]) by ns1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f417s1J19314; Tue, 1 May 2001 16:54:01 +0900 (JST) Received: from po.crl.go.jp (localhost [127.0.0.1]) by crlgw1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f417s5g22798; Tue, 1 May 2001 16:54:06 +0900 (JST) Received: from holly.crl.go.jp ([133.243.72.218]) by po.crl.go.jp (8.9.3+3.2W/3.7Wpl2-990405) id QAA03078; Tue, 1 May 2001 16:54:00 +0900 (JST) Date: Tue, 1 May 2001 16:54:00 +0900 (JST) From: Tom Holroyd X-Sender: To: cc: Subject: Re: SRP unencumbered license statement In-Reply-To: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, 29 Apr 2001, RJ Atkinson wrote: > At 06:26 27/04/01, Tom Wu wrote: > >For those of you who were following the discussion about the new draft > >and implementation of SRP-based password authentication in OpenSSH, I > >promised to have Stanford issue the IETF an official, explicit, > >statement reiterating the unencumbered royalty-free licensing terms. > >The new statement is now available from the IETF's IPR page. > > Thanks. > > For those who are having trouble finding the URL: > http://www.ietf.org/ietf/IPR/WU-SRP > > Note that there are specific limits to the Stanford grant of rights, > so I'd ask that we try to stay within the "no payment needed" > portion of SRP if SRP is adopted... Stanford University is granting a royalty-free license for RFC 2945 implementations -- and the OpenSSH SRP implementation is of that sort. That is, not only are we free and clear, but the algorithm is safe from future claimjumpers trying to patent it. Not to mention that it provides strong authentication of both client *and* server, even when the host key has changed or is unknown, and it doesn't leak any information to eavesdroppers or MITM. :-) So, SRP is ready to go. Speaking of which, an up-to-date tarball and patch are available: http://members.tripod.com/professor_tom/archives/OpenSSH-2.9p1-srp7.tar.gz http://members.tripod.com/professor_tom/archives/OpenSSH-2.9p1-srp7.patch.gz The patch is vs. the 20010501 CVS, the tarball is self-contained (remember to left-click on those links to download the files from Tripod). See the README.SRP file for more info and installation instructions. Here is the signature of the tarball (OpenSSH-2.9p1-srp7.tar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjruZOIACgkQiGAp74wl3UMoUwCfejrst7al79Ae7IKiqb/mBqbT 8KkAnjqAn06OLSYZYsrP9rsEMTNUu6PO =XcK7 -----END PGP SIGNATURE----- and here is the signature of the patch (OpenSSH-2.9p1-srp7.patch) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjruZmsACgkQiGAp74wl3UM7EQCfca/fV5WVzFCmY3WAyte7apCs pJMAnj02ym/1U1VPtKB7AI31Ovz35J5b =mNHP -----END PGP SIGNATURE----- My GPG public key is available from standard keyservers. Dr. Tom Holroyd "I am, as I said, inspired by the biological phenomena in which chemical forces are used in repetitious fashion to produce all kinds of weird effects (one of which is the author)." -- Richard Feynman, _There's Plenty of Room at the Bottom_ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 07:49:50 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23731 for ; Tue, 1 May 2001 07:49:49 -0400 (EDT) Received: (qmail 18238 invoked by uid 605); 1 May 2001 11:49:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18231 invoked from network); 1 May 2001 11:48:58 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 1 May 2001 11:48:58 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id OAA23099 for ; Tue, 1 May 2001 14:49:40 +0300 (EEST) Received: (qmail 20261 invoked from network); 1 May 2001 11:49:40 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 1 May 2001 11:49:40 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id OAA30043; Tue, 1 May 2001 14:49:39 +0300 (EET DST) X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f From: Mika Kojo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15086.41682.310205.913906@torni.hel.fi.ssh.com> Date: Tue, 1 May 2001 14:49:38 +0300 To: Tom Holroyd Cc: Subject: Re: SRP unencumbered license statement In-Reply-To: References: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom Holroyd writes: > Not to mention that it provides strong authentication of both client *and* > server, even when the host key has changed or is unknown, and it doesn't > leak any information to eavesdroppers or MITM. :-) > > So, SRP is ready to go. The problem with SRP, when compared to some other password-AKE's, is that it doesn't provide a security proof in the standard models. Security proof would guarantee that negligible information leakage occurs when adversary is not capable of solving the decisional Diffie-Hellman problem or some such. If you have such a proof please supply a reference. Best regards, Mika Kojo SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 09:20:18 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26039 for ; Tue, 1 May 2001 09:20:18 -0400 (EDT) Received: (qmail 13464 invoked by uid 605); 1 May 2001 13:19:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13457 invoked from network); 1 May 2001 13:19:29 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 1 May 2001 13:19:29 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 8B70C82674; Tue, 1 May 2001 09:19:41 -0400 (EDT) Message-Id: <5.1.0.14.2.20010501091458.00a25510@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 01 May 2001 09:17:41 -0400 To: Tom Holroyd From: RJ Atkinson Subject: Re: SRP unencumbered license statement Cc: , In-Reply-To: References: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:54 01/05/01, Tom Holroyd wrote: >Stanford University is granting a royalty-free license for RFC 2945 >implementations -- and the OpenSSH SRP implementation is of that sort. >That is, not only are we free and clear, but the algorithm is safe from future claimjumpers trying to patent it. > >Not to mention that it provides strong authentication of both client *and* server, even when the host key has changed or is unknown, >and it doesn't leak any information to eavesdroppers or MITM. :-) The Stanford IPR release to IETF is clear and says that bi-directional authentication mode (SRP-Z) requires a separate licence, and is not free. Only implicit server authentication mode is free. Your statement above appears at variance with the actual words from Stanford. I'd encourage folks to go read the actual words from Stanford, not anyone's interpretations of them. Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 09:35:00 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26652 for ; Tue, 1 May 2001 09:35:00 -0400 (EDT) Received: (qmail 16725 invoked by uid 605); 1 May 2001 13:34:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16710 invoked from network); 1 May 2001 13:34:12 -0000 Received: from watsun.cc.columbia.edu (cu51491@128.59.39.2) by mail.netbsd.org with SMTP; 1 May 2001 13:34:12 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id JAA27998; Tue, 1 May 2001 09:34:37 -0400 (EDT) Date: Tue, 1 May 2001 9:34:34 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: RJ Atkinson Cc: Tom Holroyd , , Subject: Re: SRP unencumbered license statement In-Reply-To: Your message of Tue, 01 May 2001 09:17:41 -0400 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > bi-directional authentication mode (SRP-Z) requires a > separate licence, and is not free. Only implicit server > authentication mode is free. > > Your statement above appears at variance with the actual > words from Stanford. I'd encourage folks to go read the actual > words from Stanford, not anyone's interpretations of them. Implicit server authentication mode is the mode detailed by RFC 2945. It is all that is necessary for our applications. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 14:39:25 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07064 for ; Tue, 1 May 2001 14:39:23 -0400 (EDT) Received: (qmail 25854 invoked by uid 605); 1 May 2001 18:38:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25847 invoked from network); 1 May 2001 18:38:32 -0000 Received: from unknown (HELO anchorage.arcot.com) (206.14.221.34) by mail.netbsd.org with SMTP; 1 May 2001 18:38:32 -0000 Received: from arcot.com (206.14.221.30 [206.14.221.30]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J701CQKY; Tue, 1 May 2001 11:31:52 -0700 Message-ID: <3AEF031B.CD3656BB@arcot.com> Date: Tue, 01 May 2001 11:40:27 -0700 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: RJ Atkinson CC: Tom Holroyd , openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: Re: SRP unencumbered license statement References: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> <5.1.0.14.2.20010501091458.00a25510@10.30.15.2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit RJ Atkinson wrote: > > The Stanford IPR release to IETF is clear and says that > bi-directional authentication mode (SRP-Z) requires a > separate licence, and is not free. Only implicit server > authentication mode is free. Tom H's code does implicit server authentication. It's free and clear. For the record, Niels M's code is also based on implicit server authentication. Tom -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 14:41:53 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07241 for ; Tue, 1 May 2001 14:41:52 -0400 (EDT) Received: (qmail 27013 invoked by uid 605); 1 May 2001 18:41:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27006 invoked from network); 1 May 2001 18:41:03 -0000 Received: from unknown (HELO anchorage.arcot.com) (206.14.221.34) by mail.netbsd.org with SMTP; 1 May 2001 18:41:03 -0000 Received: from arcot.com (206.14.221.30 [206.14.221.30]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J701CQL1; Tue, 1 May 2001 11:34:23 -0700 Message-ID: <3AEF03B5.4774640B@arcot.com> Date: Tue, 01 May 2001 11:43:01 -0700 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mika Kojo CC: Tom Holroyd , ietf-ssh@netbsd.org Subject: Re: SRP unencumbered license statement References: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> <15086.41682.310205.913906@torni.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Mika Kojo wrote: > > Tom Holroyd writes: > > Not to mention that it provides strong authentication of both client *and* > > server, even when the host key has changed or is unknown, and it doesn't > > leak any information to eavesdroppers or MITM. :-) > > > > So, SRP is ready to go. > > The problem with SRP, when compared to some other password-AKE's, is > that it doesn't provide a security proof in the standard > models. Security proof would guarantee that negligible information > leakage occurs when adversary is not capable of solving the decisional > Diffie-Hellman problem or some such. If you have such a proof please > supply a reference. The only other password-based key exchange that has a security proof (in the random oracle model) is PAK, and it's not free to my knowledge. The majority of the secure password protocols (EKE, SPEKE, etc.) fall into the "unproven but unbroken" category. > Best regards, > Mika Kojo > SSH Communications Security Corp Tom -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 16:09:35 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09254 for ; Tue, 1 May 2001 16:09:35 -0400 (EDT) Received: (qmail 16871 invoked by uid 605); 1 May 2001 20:08:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16864 invoked from network); 1 May 2001 20:08:44 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 1 May 2001 20:08:44 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.22) with SMTP id XAA14325 for ; Tue, 1 May 2001 23:09:26 +0300 (EEST) Received: (qmail 9975 invoked from network); 1 May 2001 20:09:26 -0000 Received: from lavuaari.hel.fi.ssh.com (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 1 May 2001 20:09:26 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id XAA20829; Tue, 1 May 2001 23:09:25 +0300 (EET DST) X-Authentication-Warning: torni.hel.fi.ssh.com: mkojo set sender to mkojo@torni.hel.fi.ssh.com using -f From: Mika Kojo MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.6132.736320.903711@torni.hel.fi.ssh.com> Date: Tue, 1 May 2001 23:09:24 +0300 To: Tom Wu Cc: Mika Kojo , Tom Holroyd , ietf-ssh@netbsd.org Subject: Re: SRP unencumbered license statement In-Reply-To: <3AEF03B5.4774640B@arcot.com> References: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> <15086.41682.310205.913906@torni.hel.fi.ssh.com> <3AEF03B5.4774640B@arcot.com> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom Wu writes: > Mika Kojo wrote: > > The problem with SRP, when compared to some other password-AKE's, is > > that it doesn't provide a security proof in the standard > > models. Security proof would guarantee that negligible information > > leakage occurs when adversary is not capable of solving the decisional > > Diffie-Hellman problem or some such. If you have such a proof please > > supply a reference. > > The only other password-based key exchange that has a security proof (in > the random oracle model) is PAK, and it's not free to my knowledge. The > majority of the secure password protocols (EKE, SPEKE, etc.) fall into > the "unproven but unbroken" category. There is also one by Rogaway et al. and a recent one by Katz et al. (and the latter seems to avoid random oracles). Perhaps the point is that provable security could be a factor when selecting new protocols, although not a decisive one (as for example random oracles have been criticized recently). This is not really SRP specific, the SSH2 key exchange scheme does not have a proof of security either. Best regards, Mika Kojo SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 1 21:07:29 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13470 for ; Tue, 1 May 2001 21:07:27 -0400 (EDT) Received: (qmail 4817 invoked by uid 605); 2 May 2001 01:06:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4810 invoked from network); 2 May 2001 01:06:30 -0000 Received: from sgi04-e.std.com (199.172.62.134) by mail.netbsd.org with SMTP; 2 May 2001 01:06:30 -0000 Received: from world.std.com (world-f.std.com [199.172.62.5]) by sgi04-e.std.COM (8.9.3/8.9.3) with ESMTP id VAA641715; Tue, 1 May 2001 21:07:13 -0400 (EDT) Received: from 76wru (24-240-72-13.hsacorp.net [24.240.72.13]) by world.std.com (8.9.3/8.9.3) with SMTP id VAA28516; Tue, 1 May 2001 21:07:12 -0400 (EDT) Message-Id: <3.0.5.32.20010501210836.007eae50@world.std.com> X-Sender: dpj@world.std.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 01 May 2001 21:08:36 -0400 To: Mika Kojo From: David Jablon Subject: SRP and proofs Cc: Tom Wu , Tom Holroyd , ietf-ssh@netbsd.org, David Jablon In-Reply-To: <15087.6132.736320.903711@torni.hel.fi.ssh.com> References: <3AEF03B5.4774640B@arcot.com> <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> <15086.41682.310205.913906@torni.hel.fi.ssh.com> <3AEF03B5.4774640B@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list Mika, To elaborate on your points, I've listed some reasons why one should be careful when considering what "provable" security means in this field. I'll also note that the task of describing the relative security of password methods is one part of the evolving IEEE P1363.2 standard for password-based cryptography. The main purpose of reduction proofs is to define an equivalence class for methods that includes at least one very-well-studied and unbroken method. The goal is to prove that if you break one, then you've broken them all. Some issues with today's proofs are: 1. Proofs in this field are new and complex. 2. Not many people have the tools or skills to verify or evaluate the correctness of such proofs. This is especially true for password-based protocols. Who can say whether any individual proof or proof model is flawless? Proofs are great, but elegant proofs are rare. 3. Proof models vary among researchers. 4. Acceptable assumptions to some people may be seen as a weakness to others. It seems a matter of taste as to how and when to use a random oracle assumption. 5. Even in the absense of a reduction proof, the benefits of using a well-studied and unbroken method may be too great to ignore when the method is compared to known-to-be-broken alternative. Proofs are important to identify the common foundations and common unresolved questions underlying all these methods. They provide a basis to be more confident in a method. But we must acknowledge their limitations. Proofs are just another level in the imperfect art of cryptography. Finally, here are some amendments to the list of published results for password protocol reduction proofs: A 1999 paper by MacKenzie and Swaminathan proved SNAPI secure based on RSA and a random oracle assumption. But as far as I know, a full version of the 2000 Bellare and Rogaway paper was never published. Links to these are at www.IntegritySciences.com/links.html. I also know of one other new paper that is yet to be published. -- David Mika Kojo wrote: >> > The problem with SRP, when compared to some other password-AKE's, is >> > that it doesn't provide a security proof in the standard models. [...] Tom Wu wrote: >> The only other password-based key exchange that has a security proof (in >> the random oracle model) is PAK, and it's not free to my knowledge. The >> majority of the secure password protocols (EKE, SPEKE, etc.) fall into >> the "unproven but unbroken" category. At 11:09 PM 5/1/01 +0300, Mika Kojo wrote: >There is also one by Rogaway et al. and a recent one by Katz et >al. (and the latter seems to avoid random oracles). Perhaps the point >is that provable security could be a factor when selecting new >protocols, although not a decisive one (as for example random oracles >have been criticized recently). > >This is not really SRP specific, the SSH2 key exchange scheme does not >have a proof of security either. --------------------------------------------------- David P. Jablon dpj@world.std.com www.IntegritySciences.com www.Phoenix.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 7 18:21:35 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23466 for ; Mon, 7 May 2001 18:21:34 -0400 (EDT) Received: (qmail 8584 invoked by uid 605); 7 May 2001 22:20:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8577 invoked from network); 7 May 2001 22:20:30 -0000 Received: from node.061-0.ty.link.si (HELO levitator.1div0.com) (213.250.43.61) by mail.netbsd.org with SMTP; 7 May 2001 22:20:30 -0000 Received: from intergalactic ([10.1.1.2]) by levitator.1div0.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id AAA20018 for ; Tue, 8 May 2001 00:58:55 +0200 From: "denis bider" To: Subject: 480x640 - slight error in the published secsh-connect-09.txt? Date: Tue, 8 May 2001 00:22:49 +0200 Message-ID: <002101c0d744$40b14040$0201010a@intergalactic> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit The document referred to in the subject states: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient_channel string "pty-req" boolean want_reply string TERM environment variable value (e.g., vt100) uint32 terminal width, characters (e.g., 80) uint32 terminal height, rows (e.g., 24) uint32 terminal width, pixels (e.g., 480) uint32 terminal height, pixels (e.g., 640) string encoded terminal modes Unless I am mistaken, 640 and then 480 would probably be better. Regards, denis // // denis bider, denis.bider@bitvise.com // http://www.bitvise.com tel.: +386 41 502 746 eFax: +1 240 376 3045 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 10 11:29:35 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00575 for ; Thu, 10 May 2001 11:29:25 -0400 (EDT) Received: (qmail 17926 invoked by uid 605); 10 May 2001 15:28:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17917 invoked from network); 10 May 2001 15:28:16 -0000 Received: from softdnserror (HELO syrinx.oankali.net) (root@209.225.172.154) by mail.netbsd.org with SMTP; 10 May 2001 15:28:16 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.9.3/8.9.3) id LAA08227; Thu, 10 May 2001 11:29:12 -0400 Date: Thu, 10 May 2001 11:29:12 -0400 Message-Id: <200105101529.LAA08227@syrinx.oankali.net> From: "Richard E. Silverman" To: SECSH Discussion List Subject: setting environment variables Sender: ietf-ssh-owner@netbsd.org Precedence: list Some questions regarding setting environment variables via SSH ("Connection" draft, section 4.4). "Environment variables may be passed to the shell/command to be started later." This mentions "shell" and "exec" channel requests, but not "subsystem." Is this deliberate? Do we want to prevent the client from setting environment variables for subsystem execution? I'm not disagreeing, necessarily -- I can see an argument from the abstraction and security point of view, as well as the fact that a subsystem might be implemented as an internal process for which setting environment variables does not make sense. However, if this is the intention, I think it should be made explicit. (Of course, the SSH could be running on an OS which does not have anything like environment variables, so that it wouldn't make sense for program execution either...) Also, the use of the phrase "the shell/command to be started later" is misleading, as it implies that only one such will be started. The connection protocol may start multiple remote shells and/or programs. I assume then that the use of the "env" channel request builds up an environment-variable state on the server, which is used for every program execution? If that's so, we need a way to unset environment variables as well. It is not sufficient to just set an old variable to the null string, since there is a program-visible difference between a variable being unset, and being set to the zero-length string. - Richard From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 11 07:13:03 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03877 for ; Fri, 11 May 2001 07:13:02 -0400 (EDT) Received: (qmail 23616 invoked by uid 605); 11 May 2001 11:11:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23609 invoked from network); 11 May 2001 11:11:57 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 11 May 2001 11:11:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03776; Fri, 11 May 2001 07:12:39 -0400 (EDT) Message-Id: <200105111112.HAA03776@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-dns-key-format-00.txt Date: Fri, 11 May 2001 07:12:39 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Storing SSH Host Keys in DNS Author(s) : W. Griffin Filename : draft-ietf-secsh-dns-key-format-00.txt Pages : 5 Date : 10-May-01 DNS Security Extensions enables the secure distribution of public keys over the Internet. This is a desirable feature for the SSH protocol. This document defines the format for storing SSH host keys in KEY resource records. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-key-format-00.txt 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-dns-key-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dns-key-format-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010510095902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dns-key-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dns-key-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010510095902.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 25 06:13:21 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14145 for ; Fri, 25 May 2001 06:13:21 -0400 (EDT) Received: (qmail 19168 invoked by uid 605); 25 May 2001 10:11:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19153 invoked from network); 25 May 2001 10:11:56 -0000 Received: from mx0.gmx.net (213.165.64.100) by mail.netbsd.org with SMTP; 25 May 2001 10:11:56 -0000 Received: (qmail 24430 invoked by alias); 25 May 2001 10:12:47 -0000 Delivered-To: GMX delivery to claudia%carmendorn@gmx.de Received: (qmail 24423 invoked by uid 0); 25 May 2001 10:12:47 -0000 Date: Fri, 25 May 2001 12:12:46 +0200 (MEST) From: Carmen Dornbach MIME-Version: 1.0 X-Priority: 3 (Normal) X-Authenticated-Sender: #0010896236@gmx.net X-Authenticated-IP: [195.93.64.171] Message-ID: <27440.990785566@www31.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: claudia%CarmenDorn@gmx.de Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Hallo, wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola, Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du willst :o) Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794* Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich .... fg Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir können sie Dir ja am Telefon ins Ohr flüstern ... Also alles ist möglich weil wir auf alles Lust haben und noch so vieles ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794* Lass uns nicht so lange warten .... Bussi bis gleich Deine süssen Girls (* E.p. DM 3,63/min.) -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net -- U2 Konzertreisen inkl. VIP-Package Hier Eventreisen zur U2-Tour bei Getgo.de online buchen! http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX