From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 00:22:13 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15724 for ; Mon, 2 Apr 2001 00:22:11 -0400 (EDT) Received: (qmail 9093 invoked by uid 605); 2 Apr 2001 04:22:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9082 invoked from network); 2 Apr 2001 04:21:55 -0000 Received: from ns1.crl.go.jp (133.243.3.1) by mail.netbsd.org with SMTP; 2 Apr 2001 04:21:55 -0000 Received: from crlgw1.crl.go.jp (crlgw1.crl.go.jp [133.243.18.250]) by ns1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f324Lrv13403 for ; Mon, 2 Apr 2001 13:21:53 +0900 (JST) Received: from po.crl.go.jp (localhost [127.0.0.1]) by crlgw1.crl.go.jp (8.9.3+3.2W/3.7W) with ESMTP id NAA14026 for ; Mon, 2 Apr 2001 13:21:53 +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 NAA05388 for ; Mon, 2 Apr 2001 13:21:52 +0900 (JST) Date: Mon, 2 Apr 2001 13:21:52 +0900 (JST) From: Tom Holroyd X-Sender: To: Subject: SRP in OpenSSH draft protocol spec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list A beta-test version of the following protocol specification is currently available (see http://members.tripod.com/professor_tom/archives/index.html). SRP (Secure Remote Passwords, RFC2945) is a Diffie-Hellman style zero-knowledge exchange which provides strong authentication of both client and server. This protocol differs from the (recently expired) draft describing the LSH implementation in that SRP is used as an authentication mechanism within SSH2, rather than as a key exchange. The session id resulting from the normal SSH2 key exchange is also incorporated into the exchange hashes, providing protection against active host-spoofing attacks, even in the case where the client does not know the server's host key. Also, this protocol provides better security than ordinary password authentication because of the zero-knowledge properties of SRP. It is hoped that the above-mentioned implementation will eventually be incorporated into the official OpenSSH sources. Comments are welcome. (I've never written one of these before and I simply copied an existing format -- I've left the Status and other boilerplate sections mostly blank for now; I'm just documenting the implementation. Please let me know what's required here.) INTERNET-DRAFT T. Holroyd draft-tomh-secsh-srp-00.txt T. Wu Expires in September 2001 N. Moeller 20 March 2001 Using the SRP protocol as an authorization method in Secure Shell Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Copyright Notice Copyright (C) The Internet Society (2000). Abstract This memo describes an experimental method for authentication in the Secure Shell protocol, version 2 [SSH-ARCH]. The main virtue of the use of the SRP protocol [SRP] as an authentication method in the "ssh-userauth"-service [SSH-USERAUTH] is its ability to provide strong authentication in both directions, without using any client state apart from the user-entered passphrase. That is, SRP authenticates the server in addition to the user, and can also authenticate the server host key. It is useful in situations where no authentic host key is known. Conventions and notations Some of the conventions used in this document are taken from [SSH- USERAUTH], others are from [SRP]. C is the client, S is the server; q is a large safe prime, g is a primitive root. The ^ operator is the exponentiation operation, and the mod operator is the integer remainder operation. Most implementations perform the exponentiation and remainder in a single stage to avoid generating unwieldy intermediate results. The | symbol indicates string concatenation. HASH is a hash function (currently SHA1), n is the user's name (used for looking up salt and verifier in the server's database), p is a passphrase, and s is a random salt string 80 bits long. x is constructed from the strings n, p and s as HASH(s | HASH(n | ":" | p)), and the verifier v is computed as g^x mod q. S keeps a database containing entries of the form , indexed by n. Numerical ranges such as e in (1, q-1) are non-inclusive, i.e. 1 < e < q-1. Protocol description 1. C sends n to S. 2. S uses n to find v, s, q, and g in its database. S sends q, g, and s to C. 3. C renerates a random number a with ALEN bits (lg(q) < a) and computes e = g^a mod q. C sends e to S. 4. S generates a random number b with ALEN bits (lg(q) < b) and computes f = v + g^b mod q. S selects u as the integer corresponding to the first 32 bits of HASH(f). If f or u happen to be zero, S must try another b. S sends f to C, and then computes the shared secret K = (e * v^u)^b mod q. 5. C gets the passphrase p from the user and computes x = HASH(s | HASH(n | ":" | p)) and v = g^x mod q. C also computes u in the same way as S. Finally, C computes the shared secret K = (f - v) ^ (a + u * x) mod q. C must check that q is a safe prime and that g is a primitive root, ideally by looking these values up in a well known table. The random exponents a and b have ALEN bits, or lg(q) bits if lg(q) < ALEN. ALEN should be at least 256, but either side may use a longer value (at the expense of speed). Each party must check that e and f are in the range (1, q-1). If not, the key exchange fails. At this point C and S have a shared secret K. They must now prove that they know the same value. Even if we're primarily interested in authenticating the server, the user must prove knowledge of the key *first*. (Otherwise, the server leaks information about the verifier). To do this, the client sends m1 = HMAC(K, H) to the server, where H is the "exchange hash" defined below. After verifying the MAC, the server responds by sending m2 = HMAC(K, e | m1 | H) to the client. The purpose of this final message exchange is twofold: (i) to prove knowledge of the shared secret key K, completing the SRP protocol, and (ii) to use the shared key K to authenticate the session id, which is part of the exchange hash and which is itself a hash of the server host key and other data. The latter is needed in order to protect against attacks on the algorithm negotiation that happens before the SRP exchange, as well as version rollback attacks. Protocol messages The name of the method, when listed in the SSH2_MSG_USERAUTH_REQUEST message, is "srp-gex-sha1". First, the client sends: byte SSH2_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding [RFC-2279]) string service name (in US-ASCII) string "srp-gex-sha1" The server responds with byte SSH2_MSG_USERAUTH_SRP_REPLY mpint q mpint g string s The client MUST verify that q is a safe prime (i.e., that q is prime, and that (q - 1) / 2 is also prime), and that g is a primitive root of the multiplicative group formed by q (i.e., that for all x in [1, q-1], there exists a y such that g^y mod q = x). If q is not safe, or g is not primitive, the client MUST abort authentication. The client then sends byte SSH2_MSG_USERAUTH_SRP_VALUE mpint e The server MUST abort if e is not in the range (1, q-1). The server responds with byte SSH2_MSG_USERAUTH_SRP_VALUE mpint f The server MUST NOT send this message until after it has received and checked the the client's SSH2_MSG_USERAUTH_SRP_VALUE message. Both sides compute u as the first 32 bits of HASH(f). The server MUST NOT send an f such that u == 0, and f MUST be in the range (1, q-1). The client MUST abort if u is 0 or f is outside the range (1, q-1). At this point, both sides calculate K. The client obtains a passphrase from the user, and calculates x, v, and K. The server MUST abort if e * v^u == 1 or -1 (mod q). Both sides now compute the exchange hash H, as the HASH of the concatenation of the following data: string session_id, calculated during the initial key exchange (see [SSH-TRANS] for more information) byte SSH2_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding [RFC-2279]) string service name (in US-ASCII) string "srp-gex-sha1" string s, the salt mpint q, the prime sent by the server mpint g, the primitive root sent by the server mpint e, exchange value sent by the client mpint f, exchange value sent by the server The client computes m1 = HMAC(K, H), and sends it to the server, to prove that it knows the shared key. It sends byte SSH2_MSG_USERAUTH_SRP_PROOF string m1 The server verifies that m1 is correct using its own K. If they don't match, the server MUST NOT send any proof back to the client, but MAY continue without disconnecting in order to allow retries. Finally, the server computes m2 = HMAC(K, H2), where H2 is the HASH of: mpint e string m1 string H and sends to the client either: byte SSH2_MSG_USERAUTH_SRP_PROOF boolean 0 in the case that the client's proof was rejected, or: byte SSH2_MSG_USERAUTH_SRP_PROOF boolean 1 string m2 in the case that the client's proof was accepted. If m2 was not sent, the client is not authenticated and MAY retry after receiving the SSH2_MSG_USERAUTH_FAILURE message that the server MUST send. If m2 was sent, the client verifies that m2 is correct, and if so, the server is authenticated. Note that according to the SSH2 protocol [SSH-USERAUTH], it is the server that either rejects the authentication request by sending SSH2_MSG_USERAUTH_FAILURE, or accepts it by sending SSH2_MSG_USERAUTH_SUCCESS. If the m2 value sent by the server does not match the value computed by the client, the client MUST abort if it receives a SSH2_MSG_USERAUTH_SUCCESS message, since the authenticity of the server is in doubt. Message numbers The following message numbers have been defined in this protocol: /* 60-79 User authentication method specific (numbers can be * reused for different authentication methods) */ #define SSH2_MSG_USERAUTH_SRP_REPLY 60 #define SSH2_MSG_USERAUTH_SRP_VALUE 61 #define SSH2_MSG_USERAUTH_SRP_PROOF 62 Security Considerations This entire draft discusses an authentication and key exchange system that provides strong authentication, protects passphrases, and exchanges keys across an untrusted network. Most of this section is taken from [SRP], which also provides more details. Knowledge of the verifier enables an attacker to mount an offline search (also known as a "dictionary attack") on the user's passphrase, as well as to impersonate the server. So the verifier should be kept secret. The entry can be created on the user's machine and transferred to the server over a secure channel, or it could be created on the server. The former approach has the advantage that the cleartext passphrase is not even temporarily known by the server. SRP has been designed not only to counter the threat of casual passphrase-sniffing, but also to prevent a determined attacker equipped with a dictionary of passphrases from guessing at passphrases using captured network traffic. The SRP protocol itself also resists active network attacks, and implementations can use the securely exchanged keys to protect the session against hijacking and provide confidentiality. Although SRP may be used as an initial authentication and key- exchange method (e.g. instead of the diffie-hellman-group1-sha1 method required by SSH-TRANS), using SRP as an authentication method in Secure Shell has the following advantages: 1) the username is not transmitted in the clear; 2) the server is authenticated to the client, preventing server spoofing; and 3) since the session id is incorporated into the exchange hashes, it (and implicitly the host key it was generated from) is authenticated along with the server. As some of the best known algorithms for computing discrete logarithms use extensive precomputations, it is desirable not to depend on a single fixed group. However, care must be taken whenever a client starts to use a new group. An attacker that knows how to compute discrete logarithms in the multiplicative group of a particular prime, and can convince the client to use that group (by spoofing the server, for example), can obtain the random value a from e, and mount a dictionary attack on m1. While dictionary attacks may often be successful due to weak passphrases or simple passwords, this one depends on the ability to compute discrete logs in a safe-prime group, which is currently theoretically difficult, and requires expensive modular exponentiation and multiplication for each test passphrase. In addition, this is not a passive attack, although most of the calculations can be carried out off-line. SRP authentication of the host key protects against a man-in-the- middle attack, where a client is tricked into connecting to a fake server, who would then capture the user's password, along with session data. SRP also has the added advantage of permitting the host to store passphrases in a form that is not directly useful to an attacker. Even if the host's passphrase verifier database were publicly revealed, the attacker would still need an expensive dictionary search to obtain any passphrases. The exponential computation required to validate a guess in this case is much more time-consuming than the hash currently used by most UNIX systems. Hosts are still advised, though, to try their best to keep their passphrase verifier files secure. Author's Address Dr. Tom Holroyd Kansai Advanced Research Center 588-2 Iwaoka, Iwaoka-cho, Nishi-ku Kobe-shi, Hyogo 651-2492 JAPAN EMail: tomh@po.crl.go.jp Thomas Wu Arcot Systems 3200 Patrick Henry Blvd. Santa Clara, CA 95054 EMail: tom@arcot.com References [SRP] T. Wu, "The SRP Authentication and Key Exchange System", Internet Draft, RFC 2945 [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet Draft, draft-ietf-secsh-architecture-08.txt [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet Draft, draft-ietf-secsh-transport-10.txt [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-10.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 15:23:29 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26712 for ; Mon, 2 Apr 2001 15:23:24 -0400 (EDT) Received: (qmail 5830 invoked by uid 605); 2 Apr 2001 19:23:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5823 invoked from network); 2 Apr 2001 19:23:19 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 19:23:19 -0000 Received: from mosquito.inet.org (unknown [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 29AF78266E; Mon, 2 Apr 2001 15:22:47 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 15:21:42 -0400 To: Tom Holroyd From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 00:21 02/04/01, Tom Holroyd wrote: >SRP (Secure Remote Passwords, RFC2945) is a Diffie-Hellman style >zero-knowledge exchange which provides strong authentication of both >client and server. Does anyone know of any patents pending or patents granted that cover SRP ? My possibly incorrect understanding is that SRP is patented or patent-pending. Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 15:56:43 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27888 for ; Mon, 2 Apr 2001 15:56:42 -0400 (EDT) Received: (qmail 13241 invoked by uid 605); 2 Apr 2001 19:56:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13223 invoked from network); 2 Apr 2001 19:56:37 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 2 Apr 2001 19:56:37 -0000 Received: from arcot.com (dynamic52.pm05.mv.best.com [209.24.241.52]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HVF1; Mon, 2 Apr 2001 12:49:51 -0700 Message-ID: <3AC8DB27.EBA103D4@arcot.com> Date: Mon, 02 Apr 2001 13:03:51 -0700 From: Tom Wu Organization: Arcot Systems, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: RJ Atkinson CC: Tom Holroyd , ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@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: > > At 00:21 02/04/01, Tom Holroyd wrote: > > >SRP (Secure Remote Passwords, RFC2945) is a Diffie-Hellman style > >zero-knowledge exchange which provides strong authentication of both > >client and server. > > Does anyone know of any patents pending or patents > granted that cover SRP ? My possibly incorrect understanding > is that SRP is patented or patent-pending. RFC2945-style SRP authentication, which is what OpenSSH is using, is royalty-free for commercial and non-commercial use worldwide. See http://www.ietf.org/ietf/IPR/WU-SRP for more information. > Ran > rja@inet.org Tom -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 16:33:03 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29555 for ; Mon, 2 Apr 2001 16:32:58 -0400 (EDT) Received: (qmail 21440 invoked by uid 605); 2 Apr 2001 20:32:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21433 invoked from network); 2 Apr 2001 20:32:52 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 2 Apr 2001 20:32:52 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 69CBC82F52E; Mon, 2 Apr 2001 22:32:50 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id WAA05394; Mon, 2 Apr 2001 22:32:49 +0200 (MET DST) To: RJ Atkinson Cc: Tom Holroyd , Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 02 Apr 2001 22:32:49 +0200 In-Reply-To: RJ Atkinson's message of "Mon, 02 Apr 2001 15:21:42 -0400" Message-ID: Lines: 49 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit RJ Atkinson writes: > Does anyone know of any patents pending or patents > granted that cover SRP ? My possibly incorrect understanding > is that SRP is patented or patent-pending. It's patented by Stanford, and the basic variant (that described in the SRP rfc) is licensed freely. See http://www.ietf.org/ietf/IPR/WU-SRP: : Received December 22, 2000 : From: Thomas Wu : : The SRP Authentication and Key Exchange System, as specified in : RFC 2945, is available royalty-free worldwide for commercial and : non-commercial use. : : Extended variants of SRP, such as those based on SRP-Z, may require : a license, which Stanford will grant on a non-exclusive basis, under : reasonable and non-discriminatory terms. : : For questions about SRP, please contact me or visit : http://otl.stanford.edu/ : : Tom Wu : tjw@CS.Stanford.EDU I've discussed this some more with Tom Wu. I'm not sure it would be appropriate to quote it all here, but the main point seem to be that SRP is patented, but licensed freely. Thus, the SRP case is not much different from CAST-128 and CAST-256, patented by Entrust, or for that matter DES, which I believe was patented (by IBM?) and then freely licensed after it became a US government standard. Tom Wu wrote: "Stanford's primary intention is to keep the strong password field open, by making a well-tested, well-standardized method available for free. It simply wouldn't make sense for us to change our minds about licensing, because it would undermine a great deal of work, time, and effort that we've already put in; that's why it won't happen." I'm by no means a patent expert, but I feel that SRP is free enough for use in free software, and that ought to be free enough for anybody. It would be good if someone more official at stanford could back up Tom's statement, though. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 17:12:51 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01437 for ; Mon, 2 Apr 2001 17:12:50 -0400 (EDT) Received: (qmail 214 invoked by uid 605); 2 Apr 2001 21:12:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 206 invoked from network); 2 Apr 2001 21:12:46 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 21:12:46 -0000 Received: from mosquito.inet.org (unknown [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id A919C8266E; Mon, 2 Apr 2001 17:12:14 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 17:11:10 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC8DB27.EBA103D4@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 16:03 02/04/01, Tom Wu wrote: >RJ Atkinson wrote: >> Does anyone know of any patents pending or patents >> granted that cover SRP ? My possibly incorrect understanding >> is that SRP is patented or patent-pending. > >RFC2945-style SRP authentication, which is what OpenSSH is using, is >royalty-free for commercial and non-commercial use worldwide. See > > http://www.ietf.org/ietf/IPR/WU-SRP > >for more information. > >Tom IMHO, it would be more clear, hence more helpful, if there were a published RFC along the lines of the content at the URL above. Several such examples exist in the current RFC archives. In particular, it would be good if the patent holder of record formally granted a royalty-free licence in such an RFC. Tom's email is absolutely helpful, but is not likely to be sufficient for any commercial firm's patent counsel. Note that I'm speaking as an individual IETF person, not for my employer. Thanks, Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 18:42:20 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03165 for ; Mon, 2 Apr 2001 18:42:19 -0400 (EDT) Received: (qmail 13006 invoked by uid 605); 2 Apr 2001 22:42:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12999 invoked from network); 2 Apr 2001 22:42:15 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 2 Apr 2001 22:42:15 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HVQM; Mon, 2 Apr 2001 15:35:24 -0700 Message-ID: <3AC9006E.A7D58DBC@arcot.com> Date: Mon, 02 Apr 2001 15:42:54 -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: Niels =?iso-8859-1?Q?M=F6ller?= CC: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit "Niels Möller" wrote: > > I've discussed this some more with Tom Wu. I'm not sure it would be > appropriate to quote it all here, but the main point seem to be that > SRP is patented, but licensed freely. Thus, the SRP case is not much > different from CAST-128 and CAST-256, patented by Entrust, or for that > matter DES, which I believe was patented (by IBM?) and then freely > licensed after it became a US government standard. Or, for that matter, PSS, DSA, SHA-1, etc. The more I investigated this, the more I found it to be the norm rather than the exception. > I'm by no means a patent expert, but I feel that SRP is free enough > for use in free software, and that ought to be free enough for > anybody. > > It would be good if someone more official at stanford could back up > Tom's statement, though. If you ask the Stanford OTL, they will of course confirm the IETF licensing statement. It may take you a few weeks (they're busy folks), and you'll have to wade through some legalese, but you'll get it. In the meantime, you have a clear statement from the inventor of the royalty-free license. > /Niels -- 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 Mon Apr 2 18:48:29 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03225 for ; Mon, 2 Apr 2001 18:48:28 -0400 (EDT) Received: (qmail 14669 invoked by uid 605); 2 Apr 2001 22:48:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14662 invoked from network); 2 Apr 2001 22:48:25 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 2 Apr 2001 22:48:25 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HVQY; Mon, 2 Apr 2001 15:41:39 -0700 Message-ID: <3AC901E8.C17EAD2C@arcot.com> Date: Mon, 02 Apr 2001 15:49:12 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@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: > > IMHO, it would be more clear, hence more helpful, > if there were a published RFC along the lines of the content > at the URL above. Several such examples exist in the current > RFC archives. In particular, it would be good if the patent Can you point to any specific examples that you feel are representative of what you are looking for? Do you feel that the current IPR mechanism does not address your concerns adequately? > holder of record formally granted a royalty-free licence > in such an RFC. Tom's email is absolutely helpful, but is > not likely to be sufficient for any commercial firm's patent > counsel. There is a link to the Stanford OTL, where any firm's lawyers can contact Stanford's lawyers to get the appropriate legal assurances. IANAL, I deal with the technical/cryptographic aspects of SRP and leave the legal issues to them. It's free, that's the important part as far as I'm concerned. 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 Mon Apr 2 19:04:34 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03401 for ; Mon, 2 Apr 2001 19:04:34 -0400 (EDT) Received: (qmail 17786 invoked by uid 605); 2 Apr 2001 23:04:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17778 invoked from network); 2 Apr 2001 23:04:28 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 23:04:28 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id C16B68266E; Mon, 2 Apr 2001 19:03:55 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402190126.009f3880@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 19:02:49 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC9006E.A7D58DBC@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 18:42 02/04/01, Tom Wu wrote: >Or, for that matter, PSS, DSA, SHA-1, etc. The more I investigated >this, the more I found it to be the norm rather than the exception. I believe DSA and SHA-1 were placed in the public domain. >If you ask the Stanford OTL, they will of course confirm the IETF >licensing statement. It may take you a few weeks (they're busy folks), >and you'll have to wade through some legalese, but you'll get it. In >the meantime, you have a clear statement from the inventor of the >royalty-free license. Unfortunately, clear statement of the patent holder is what matters in court, not clear statement of the inventor. Any chance you could work a suitable text through the Stanford OTL and get it published as an RFC (as others have done in the past) ? Thanks, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 19:13:57 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03615 for ; Mon, 2 Apr 2001 19:13:56 -0400 (EDT) Received: (qmail 18743 invoked by uid 605); 2 Apr 2001 23:13:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18736 invoked from network); 2 Apr 2001 23:13:47 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 23:13:47 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 8584D8266E; Mon, 2 Apr 2001 19:13:09 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 19:12:01 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC901E8.C17EAD2C@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 18:49 02/04/01, Tom Wu wrote: >RJ Atkinson wrote: >> >> IMHO, it would be more clear, hence more helpful, >> if there were a published RFC along the lines of the content >> at the URL above. Several such examples exist in the current >> RFC archives. In particular, it would be good if the patent > >Can you point to any specific examples that you feel are representative of what you are looking for? Examples: RFC-1822 RFC-1988 (Other examples might exist; these just appeared quickly when I searched rfc-index.txt) Obviously the language in the RFC should be wordsmith'd by the patent holder's counsel to reflect which rights (and limitations, if any) the patent holder is willing to grant. In the IETF context, there ought not be a requirement for folks to individually and separately contact the patent holder to obtain a licence -- instead some form of general licence should be granted, IMHO. RFC-1790 & RFC-2339 might also be of interest, though their scope is broader and a bit different than the previous examples. >Do you feel that the current IPR mechanism >does not address your concerns adequately? Yes. There is no formal statement from the holder of the patent(s) [pending ?] about the licence terms, so my concerns are quite substantially not yet addressed. >There is a link to the Stanford OTL, where any firm's lawyers can >contact Stanford's lawyers to get the appropriate legal assurances. >IANAL, I deal with the technical/cryptographic aspects of SRP and leave the legal issues to them. It's free, that's the important >part as far as I'm concerned. The rest of us don't have a statement formally from the patent holder indicating that SRP is free. That is a substantial legal problem lots of places. While I believe you, what matters is whether a court would take such on trust (and a court would not). Thanks, Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 19:32:57 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04098 for ; Mon, 2 Apr 2001 19:32:57 -0400 (EDT) Received: (qmail 20312 invoked by uid 605); 2 Apr 2001 23:32:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20305 invoked from network); 2 Apr 2001 23:32:51 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 2 Apr 2001 23:32:51 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HV4H; Mon, 2 Apr 2001 16:26:05 -0700 Message-ID: <3AC90C53.712F00C7@arcot.com> Date: Mon, 02 Apr 2001 16:33:39 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@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: > > a substantial legal problem lots of places. While I believe > you, what matters is whether a court would take such on > trust (and a court would not). Do you have the same concerns with CAST: http://www.ietf.org/ietf/IPR/CAST-128-entrust http://www.ietf.org/rfc/rfc2144.txt If so, your contention should be with RFC2026. We should take the rest of this discussion offline until a resolution is reached. > Thanks, > > Ran > rja@inet.org 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 Mon Apr 2 19:52:58 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04384 for ; Mon, 2 Apr 2001 19:52:57 -0400 (EDT) Received: (qmail 23946 invoked by uid 605); 2 Apr 2001 23:52:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23938 invoked from network); 2 Apr 2001 23:52:51 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 23:52:51 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id D37C18266F; Mon, 2 Apr 2001 19:52:13 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402193521.00a01ba0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 19:51:07 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC90C53.712F00C7@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 19:33 02/04/01, Tom Wu wrote: >Do you have the same concerns with CAST: > >http://www.ietf.org/ietf/IPR/CAST-128-entrust >http://www.ietf.org/rfc/rfc2144.txt > >If so, your contention should be with RFC2026. Not at all. RFC-2026 describes the outer limits that process rules permit, not IETF day to day practices. In particular, you have noted that Stanford holds the patent on SRP, so you aren't the patent holder yourself. Entrust is in fact the patent holder for CAST. For the record, I object to the IETF SSH WG including any technology in its specifications that is patented and for which a royalty-free, hassle-free, authorised licence statement from the patent holder has not been published in an RFC or is available from the IETF Secretariat. If each user needs to negotiate with the patent holder, then it is not acceptable. Yours, Ran rja@inet.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 19:59:49 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04463 for ; Mon, 2 Apr 2001 19:59:49 -0400 (EDT) Received: (qmail 26068 invoked by uid 605); 2 Apr 2001 23:59:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26061 invoked from network); 2 Apr 2001 23:59:42 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 2 Apr 2001 23:59:42 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 353038266E for ; Mon, 2 Apr 2001 19:59:07 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402195718.00a0b7f0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 19:58:00 -0400 To: ietf-ssh@netbsd.org From: RJ Atkinson Subject: Fwd: Re: SRP in OpenSSH draft protocol spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list This should have been sent to the IETF SSH list as well. Forwarded FYI. Ran >Date: Mon, 02 Apr 2001 16:39:02 -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 >To: RJ Atkinson >Subject: Re: SRP in OpenSSH draft protocol spec > >RJ Atkinson wrote: >> >> Examples: >> RFC-1822 >> RFC-1988 >> (Other examples might exist; these just appeared >> quickly when I searched rfc-index.txt) >> >> Obviously the language in the RFC should be wordsmith'd >> by the patent holder's counsel to reflect which rights >> (and limitations, if any) the patent holder is willing >> to grant. In the IETF context, there ought not be a >> requirement for folks to individually and separately contact >> the patent holder to obtain a licence -- instead some form >> of general licence should be granted, IMHO. >> >> RFC-1790 & RFC-2339 might also be of interest, >> though their scope is broader and a bit different than >> the previous examples. > >Thanks for the references. Clearly, though, not all companies choose to >go through the trouble of the RFC process just for a license statement. >How do you feel about the other agreements listed in the IETF's IPR >section, which do not have a corresponding RFC? > >> The rest of us don't have a statement formally from >> the patent holder indicating that SRP is free. That is >> a substantial legal problem lots of places. While I believe >> you, what matters is whether a court would take such on >> trust (and a court would not). > >Have you contacted Stanford OTL, http://otl.stanford.edu/, for >confirmation? > >> Thanks, >> >> Ran >> rja@inet.org > >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 Mon Apr 2 20:04:21 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04559 for ; Mon, 2 Apr 2001 20:04:20 -0400 (EDT) Received: (qmail 27596 invoked by uid 605); 3 Apr 2001 00:04:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27589 invoked from network); 3 Apr 2001 00:04:14 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 3 Apr 2001 00:04:14 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 3E88F8266E for ; Mon, 2 Apr 2001 20:03:42 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402200158.00a0e470@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 20:02:36 -0400 To: ietf-ssh@netbsd.org From: RJ Atkinson Subject: Fwd: Re: SRP in OpenSSH draft protocol spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list This should also have been copied to the IETF SSH list. Forwarded now. Sorry for overlooking the absence on the CC line. Ran >Date: Mon, 02 Apr 2001 19:56:49 -0400 >To: Tom Wu >From: RJ Atkinson >Subject: Re: SRP in OpenSSH draft protocol spec >Cc: RJ Atkinson > >At 19:39 02/04/01, Tom Wu wrote: > >>How do you feel about the other agreements listed in the IETF's >>IPR section, which do not have a corresponding RFC? > > Uncomfortable, on average. Note that RFC-2026 >is NOT a shield from this concern because it defines the >outer limits of what the IETF is permitted to agree to, >rather than the day-to-day practices of the IETF. On >at least some occasions, IETF WGs have declined to permit >a patented technology into the specification despite an >online statement in the IPR section. > > Publishing an Informational RFC isn't hard and need >only be done once to clarify things. Publishing standards-track >RFCs is rather harder than Informational, I admit. > >>> The rest of us don't have a statement formally from >>> the patent holder indicating that SRP is free. That is >>> a substantial legal problem lots of places. While I believe >>> you, what matters is whether a court would take such on >>> trust (and a court would not). >> >>Have you contacted Stanford OTL, http://otl.stanford.edu/, >>for confirmation? > > An important point is that one needs to have confidence >in the patent licence status without each of us having to >contact the patent holder. > > Stanford OTL has not responded yet to my enquiry, >purely as an aside. > >Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 20:07:41 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04640 for ; Mon, 2 Apr 2001 20:07:40 -0400 (EDT) Received: (qmail 28599 invoked by uid 605); 3 Apr 2001 00:07:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28592 invoked from network); 3 Apr 2001 00:07:35 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 3 Apr 2001 00:07:35 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HVW8; Mon, 2 Apr 2001 17:00:49 -0700 Message-ID: <3AC91477.EFF29EE1@arcot.com> Date: Mon, 02 Apr 2001 17:08:23 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> <5.0.2.1.2.20010402193521.00a01ba0@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: > > At 19:33 02/04/01, Tom Wu wrote: > >Do you have the same concerns with CAST: > > > >http://www.ietf.org/ietf/IPR/CAST-128-entrust > >http://www.ietf.org/rfc/rfc2144.txt > > > >If so, your contention should be with RFC2026. > > Not at all. RFC-2026 describes the outer limits > that process rules permit, not IETF day to day practices. > > In particular, you have noted that Stanford holds > the patent on SRP, so you aren't the patent holder yourself. > Entrust is in fact the patent holder for CAST. But the IPR statement is not from Entrust, it is from the inventor, Carlisle Adams. 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 Mon Apr 2 20:43:57 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04975 for ; Mon, 2 Apr 2001 20:43:57 -0400 (EDT) Received: (qmail 5240 invoked by uid 605); 3 Apr 2001 00:43:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5233 invoked from network); 3 Apr 2001 00:43:50 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 3 Apr 2001 00:43:50 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HVYW; Mon, 2 Apr 2001 17:37:02 -0700 Message-ID: <3AC91CF4.D596A309@arcot.com> Date: Mon, 02 Apr 2001 17:44:36 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@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: > > to grant. In the IETF context, there ought not be a > requirement for folks to individually and separately contact > the patent holder to obtain a licence -- instead some form > of general licence should be granted, IMHO. Just so that others reading this don't get the wrong impression, the free license for SRP is granted to all, *without* requiring a written agreement with Stanford. While people are welcome to contact Stanford OTL to have their questions answered, they do *not* need to negotiate with them in order to use SRP on a royalty-free basis. In the interest of saving time in the future, I will have Stanford OTL send the IETF secretariat an additional statement to this effect. 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 Mon Apr 2 21:00:59 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05210 for ; Mon, 2 Apr 2001 21:00:54 -0400 (EDT) Received: (qmail 13022 invoked by uid 605); 3 Apr 2001 01:00:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13014 invoked from network); 3 Apr 2001 01:00:46 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 3 Apr 2001 01:00:46 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 656898266E; Mon, 2 Apr 2001 21:00:13 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402205815.009f5b40@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 20:59:07 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC91477.EFF29EE1@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> <5.0.2.1.2.20010402193521.00a01ba0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 20:08 02/04/01, Tom Wu wrote: >> In particular, you have noted that Stanford holds >> the patent on SRP, so you aren't the patent holder yourself. >> Entrust is in fact the patent holder for CAST. > >But the IPR statement is not from Entrust, it is from the inventor, >Carlisle Adams. Using an Entrust email address and having represented himself as authorised to speak for Entrust officially at an IETF meeting...so not the same. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 21:02:46 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05510 for ; Mon, 2 Apr 2001 21:02:45 -0400 (EDT) Received: (qmail 13730 invoked by uid 605); 3 Apr 2001 01:02:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13721 invoked from network); 3 Apr 2001 01:02:39 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 3 Apr 2001 01:02:39 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 034B48266E; Mon, 2 Apr 2001 21:02:06 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402205926.009fc4f0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 21:00:59 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC91CF4.D596A309@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 20:44 02/04/01, Tom Wu wrote: >RJ Atkinson wrote: >> >> to grant. In the IETF context, there ought not be a >> requirement for folks to individually and separately contact >> the patent holder to obtain a licence -- instead some form >> of general licence should be granted, IMHO. > >Just so that others reading this don't get the wrong impression, the >free license for SRP is granted to all, *without* requiring a written >agreement with Stanford. While people are welcome to contact Stanford >OTL to have their questions answered, they do *not* need to negotiate >with them in order to use SRP on a royalty-free basis. > >In the interest of saving time in the future, I will have Stanford OTL send the IETF secretariat an additional statement to this effect. Thanks, that would help a lot. In particular, having Stanford give the IETF Secretariat a specific licence statement with clear inclusions/limitations/exclusions would help a great deal. Publishing an RFC would not be substantially more work and would be even better, as existing practice shows. :-) Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 21:31:20 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05821 for ; Mon, 2 Apr 2001 21:31:20 -0400 (EDT) Received: (qmail 22094 invoked by uid 605); 3 Apr 2001 01:31:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22087 invoked from network); 3 Apr 2001 01:31:14 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 3 Apr 2001 01:31:14 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HV6V; Mon, 2 Apr 2001 18:24:28 -0700 Message-ID: <3AC92812.4DB3A7F0@arcot.com> Date: Mon, 02 Apr 2001 18:32:02 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> <5.0.2.1.2.20010402193521.00a01ba0@10.30.15.2> <5.0.2.1.2.20010402205815.009f5b40@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: > > At 20:08 02/04/01, Tom Wu wrote: > > >> In particular, you have noted that Stanford holds > >> the patent on SRP, so you aren't the patent holder yourself. > >> Entrust is in fact the patent holder for CAST. > > > >But the IPR statement is not from Entrust, it is from the inventor, > >Carlisle Adams. > > Using an Entrust email address and having represented > himself as authorised to speak for Entrust officially at > an IETF meeting...so not the same. But it is precisely the same. There's still no legally-binding document to cite in court, which is presumably what you're objecting to, just a clear statement from the inventor on behalf of the organization he did the work for. I suppose you didn't notice that the SRP IPR notice was received from Stanford, either. Why the double-standard? > Ran 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 Mon Apr 2 21:59:22 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07071 for ; Mon, 2 Apr 2001 21:59:22 -0400 (EDT) Received: (qmail 27712 invoked by uid 605); 3 Apr 2001 01:58:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27370 invoked from network); 3 Apr 2001 01:58:24 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 3 Apr 2001 01:58:24 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 028058266E; Mon, 2 Apr 2001 21:57:51 -0400 (EDT) Message-Id: <5.0.2.1.2.20010402215359.009edd40@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 21:56:45 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP in OpenSSH draft protocol spec Cc: ietf-ssh@netbsd.org In-Reply-To: <3AC92812.4DB3A7F0@arcot.com> References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> <5.0.2.1.2.20010402193521.00a01ba0@10.30.15.2> <5.0.2.1.2.20010402205815.009f5b40@10.30.15.2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list At 21:32 02/04/01, Tom Wu wrote: >But it is precisely the same. There's still no legally-binding document >to cite in court, which is presumably what you're objecting to, just a >clear statement from the inventor on behalf of the organization he did >the work for. ...which I noted earlier I was not comfortable with most of the IPR statements online at IETF. >I suppose you didn't notice that the SRP IPR notice was received from >Stanford, either. Why the double-standard? No double standard. I really want an RFC from everyone, which folks who've been around for a while have seen from me in other WGs in the past (e.g. in IPsec). Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 2 22:43:03 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08722 for ; Mon, 2 Apr 2001 22:43:02 -0400 (EDT) Received: (qmail 3715 invoked by uid 605); 3 Apr 2001 02:42:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3708 invoked from network); 3 Apr 2001 02:42:57 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 3 Apr 2001 02:42:57 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HMQ4HV0N; Mon, 2 Apr 2001 19:36:06 -0700 Message-ID: <3AC938DB.B30093F0@arcot.com> Date: Mon, 02 Apr 2001 19:43:39 -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: ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec References: <5.0.2.1.2.20010402152055.009fd760@10.30.15.2> <5.0.2.1.2.20010402170813.00a4e5a0@10.30.15.2> <5.0.2.1.2.20010402190255.009ffec0@10.30.15.2> <5.0.2.1.2.20010402193521.00a01ba0@10.30.15.2> <5.0.2.1.2.20010402205815.009f5b40@10.30.15.2> <5.0.2.1.2.20010402215359.009edd40@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: > > At 21:32 02/04/01, Tom Wu wrote: > > >But it is precisely the same. There's still no legally-binding document > >to cite in court, which is presumably what you're objecting to, just a > >clear statement from the inventor on behalf of the organization he did > >the work for. > > ...which I noted earlier I was not comfortable with > most of the IPR statements online at IETF. > > >I suppose you didn't notice that the SRP IPR notice was received from > >Stanford, either. Why the double-standard? > > No double standard. I really want an RFC from > everyone, which folks who've been around for a while have > seen from me in other WGs in the past (e.g. in IPsec). Understood. As I have indicated in a different posting, I am willing to work with Stanford and the IETF to ensure that IPR concerns are dealt with properly. But I also want to understand the nature of those concerns, in light of the fact that there seems to be considerable disagreement as to what it means to be "free", and that indeed, many of the things that are commonly thought to be free don't seem to be free enough for some, especially in the crypto community. In any case, this issue will go away with Stanford's statement to the secretariat, and we can go back to the hard work of getting the strong password authentication code tested and polished for general use. > Ran 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 Apr 3 14:32:05 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12130 for ; Tue, 3 Apr 2001 14:32:04 -0400 (EDT) Received: (qmail 15325 invoked by uid 605); 3 Apr 2001 18:31:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15318 invoked from network); 3 Apr 2001 18:31:57 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 3 Apr 2001 18:31:57 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19975; Tue, 3 Apr 2001 11:31:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05228; Tue, 3 Apr 2001 14:31:53 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f33IVj906113; Tue, 3 Apr 2001 14:31:45 -0400 (EDT) Message-Id: <200104031831.f33IVj906113@thunk.east.sun.com> From: Bill Sommerfeld To: RJ Atkinson cc: Tom Wu , ietf-ssh@netbsd.org Subject: Re: SRP in OpenSSH draft protocol spec In-reply-to: Your message of "Mon, 02 Apr 2001 21:56:45 EDT." <5.0.2.1.2.20010402215359.009edd40@10.30.15.2> Reply-to: sommerfeld@east.sun.com Date: Tue, 03 Apr 2001 14:31:45 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ok, I think this issue has been adequately covered here. . To summarize briefly: The IETF process requires prompt public disclosure of any IPR issues connected to a technology. This appears to have happened. The WG then gets to decide (by the usual rough consensus) whether the IPR presents an obstacle to adoption of the technology as a standard. So, in order to get adoption by the WG, the IPR owner needs to convince the members of the WG that any IPR issues will not be an obstacle to implementation/deployment/... otherwise, the path of least resistance is to find another technology which is less encumbered or unencumbered. Note that there is at least one non-patented technology which is a possible alternative to SRP; see draft-perlman-strong-cred-00.txt. (affiliation disclaimer: Radia Perlman and I both work for Sun, though we are in completely different divisions of the company). Anyhow, it appears that the existing IPR statement from Tom Wu is not sufficient for (at least) Ran, but one from the Stanford OTL might be.. Let's wait and see what the revised IPR statement from Stanford says. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 3 15:11:51 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13753 for ; Tue, 3 Apr 2001 15:11:50 -0400 (EDT) Received: (qmail 25126 invoked by uid 605); 3 Apr 2001 19:11:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25119 invoked from network); 3 Apr 2001 19:11:42 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 3 Apr 2001 19:11:42 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21774 for ; Tue, 3 Apr 2001 12:11:41 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12609 for ; Tue, 3 Apr 2001 15:11:40 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f33JBW906174 for ; Tue, 3 Apr 2001 15:11:32 -0400 (EDT) Message-Id: <200104031911.f33JBW906174@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: draft minutes from meeting at ietf50.. Reply-to: sommerfeld@east.sun.com Date: Tue, 03 Apr 2001 15:11:32 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Please send comments/corrections to me and/or the list. Thanks. - Bill Minutes of the IETF Secure Shell (secsh) working group Monday March 19, 2001 Minutes from notes taken by Ken Hornstein Working Group chair: Bill Sommerfeld We started with two announcements from folks organizing interoperability events -- Darrin Moffat announced that SSH will be one of the technologies tested at the next Connectathon; see www.connectathon.org for more details. Rodney Thayer announced that he would be organizing interop tests for SSH in conjunction with an OpenPGP interop event. Niels Provos has been doing surveys of random internet addresses looking for what versions of SSH are out there; he has found a gradual increase in the number of v2-capable and v2-only servers over time, with a significant acceleration since February of this year. Tatu Ylonen pointed out that there are at least 5 million licensed copies of clients with v2 support out there. We then moved on to discussion of the technical issues raised during the last-call of the core documents. Most issues were uncontroversial and did not receive much discussion; some of the issues open before the meeting appear to have been resolved. Notably: - language tags should be included on all messages, even if apparently redundant (it's simpler that way); the document should be clarified to indicate this. - subsystems and clean channels There appears to be consensus on the following: - a server MUST provide a clean channel to subsystems (i.e., no crud inserted/deleted/etc. at the beginning or middle) - exactly how a server cooperates with a subsystem to implement this is a local issue. - exactly what protocol a subsystem uses is up to the subsystem. There is less clear consensus on whether or not to recommend anything on this subject to subsystem protocol designers. Two new security issues were raised on the list by Niels Provos shortly before the meeting and were briefly discussed at the meeting. Both issues can be corrected without wire protocol changes. First, another SSH security advisory has been issued relating to some traffic-analysis issues (in short, an eavesdropper can determine the length of the user's password, and use this to both select targets of opportunity and also reduce the work factor with certain hashed password schemes if they also have a hash of the password). See http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt for details. Niels will be supplying suggested text for the documents. Niels also pointed out that the document does not provide recommendations for appropriate exponent sizes for use with the Diffie-Hellman exchange; the general rule of thumb is that the exponent should be roughly twice the size of the desired key. Niels also volunteered to supply suggested text for the document. Several additional work items were suggested during last-call: 1) Server key fingerprints. There was a very short draft by Markus Friedl sent to the list after the deadline. There is one outstanding issue -- the choice of hash function (MD5 vs SHA1). There are strong arguments for both -- MD5 is what the installed base uses; however, SSHv2 only requires implementations to have SHA1 for the wire protocol. 2) Port forwarding of anonymous ports The consensus of those present was that this would better be handled as a new request lest it cause interop problems with existing applications. 3) Improve error messages from port forwarding There were no objections to this happening; someone in favor of this should supply specific text. 4) UDP forwarding (new channel type) Seems like a reasonable idea; proponents should supply a draft. (due to lack of implementation experience, let's keep this separate for now). Extension Drafts 1) File Transfer This has been talked about a fair bit on the list. One question was asked about UTF8 and filenames; Tatu pointed out that filenames are binary currently; it's hard to deal with different character sets properly (they can be negotiated later) and this shouldn't hold up the draft. 2) Public key file format A suggestion was made that the document should contain an example or two. Consensus of those present is that (aside from this) it's essentially done and should be last-called. 3) DH Group Exchange - (a new WG item) The purpose is to avoid precomputation group attacks against DH exchange; solution is to avoid too many people from using the same group. Concern was brought up that you may open yourself up to other attacks by group exchange; there was also a question of lower and upper bounds on group size since some clients may not implement support for unbounded modulus size (a lower bound and upper bound on group size may be enough). 4) Keyboard-interactive. Assertion was made that there were no problems with the protocol. Last call time? 5) GSSAPI There is now a unified GSSAPI key exchange draft (from all of the previous GSSAPI drafts). Jeff Hutzelman put up a slide: The unified draft is for key exchange only. Biggest change is that everything is now shuffled around to deal better with all mechanisms; handling of mechanism names is now clearer. There's now a paragraph describing how NOT to use channel bindings. Jeff is inclined to out-and-out prohibit it. Simon Wilkinson implemented it, found some problems, and gave feedback to the authors, which is rolled into the new draft. One open issue is what happens when credentials expire? With the current draft, the renegotiatiation fails and you get booted out. Is that correct? Jeff points out that a) right now we're using GSS for server-to-client authentication, and b) this is really annoying in practice. One possible resolution is to rekey using the "traditional" SSH key exchange mechanism since the server has already been authenticated. - SSH host keys in DNS DNS with DNSSEC appears to have the potential to be a great key distribution system. The main purpose of the current draft is to get a protocol number from IANA for SSH keys; a second document is needed to give guidance on how/when to use/trust keys found in DNS. Wes is implementing this in a version of OpenSSH. Consensus is that the encoding document is not controversial, and is "worthy of a last call". - Niels Moeller's SRP draft (expired) Is it appropriate to make this a WG item? Will bring this to the list. Protocol Naming Discussion. The working group has received a request from Tatu Ylonen to rename the protocol. There was an extended discussion of the name for the working group's protocol which was led/moderated by Jeff Schiller, security AD. The discussion started with Tatu repeating his request; an extended discussion followed. While the sentiment was by no means unanimous, there was clear evidence that there is substantial opposition to renaming the protocol at this time, outweighing any interest in favor of renaming. This evidence comes both from pre-meeting comments on the list and to the WG chair, comments at the meeting itself, and a non-binding straw poll conducted at the end of the meeting. Therefore, the working group will not act on Tatu's request; the documents will proceed under their existing names. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 3 15:33:39 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14581 for ; Tue, 3 Apr 2001 15:33:38 -0400 (EDT) Received: (qmail 28156 invoked by uid 605); 3 Apr 2001 19:33:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28148 invoked from network); 3 Apr 2001 19:33:33 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 3 Apr 2001 19:33:33 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09110 for ; Tue, 3 Apr 2001 12:33:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA27083 for ; Tue, 3 Apr 2001 12:33:46 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta6+Sun/8.12.0.Beta6) with SMTP id f33JXVWI235312 for ; Tue, 3 Apr 2001 12:33:31 -0700 (PDT) Message-Id: <200104031933.f33JXVWI235312@jurassic.eng.sun.com> Date: Tue, 3 Apr 2001 12:33:30 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: SRP in OpenSSH draft protocol spec To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LpAm7GkoippMAQY5AJnJ0A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_35 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >Note that there is at least one non-patented technology which is a >possible alternative to SRP; see draft-perlman-strong-cred-00.txt. >(affiliation disclaimer: Radia Perlman and I both work for Sun, though >we are in completely different divisions of the company). One additional data point is that the perlman draft is currently being considered as one possibility for the SACRED WG. The perlman draft was explicitly written because of IRP issues. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 3 19:53:09 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20549 for ; Tue, 3 Apr 2001 19:53:08 -0400 (EDT) Received: (qmail 1326 invoked by uid 605); 3 Apr 2001 23:53:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1319 invoked from network); 3 Apr 2001 23:53:02 -0000 Received: from muedi6-212-144-216-051.arcor-ip.net (HELO folly.informatik.uni-erlangen.de) (@212.144.216.51) by mail.netbsd.org with SMTP; 3 Apr 2001 23:53:02 -0000 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 7358EFA5; Wed, 4 Apr 2001 01:52:43 +0200 (CEST) Date: Wed, 4 Apr 2001 01:52:43 +0200 From: Markus Friedl To: ietf-ssh@netbsd.org Subject: Key Re-Exchange Message-ID: <20010404015243.B30762@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list hi, I have some questions regarding the 'Key Re-Exchange' (aka rekeying): is it true that no application data may be sent during key re-exchange? how is this 'during key re-exchange' defined? i think that that the re-exchange starts when a KEXINIT message has been both sent _and_ received. so, if you initiate the re-exchange, you have to wait for the KEXINIT from the peer, but since there might be some more packets one the wire i might get these messages before i get the KEXINIT. the problem here is that i cannot tell whether my KEXINIT message did already arrive at the peer or whether the peer just ignores the KEXINIT message and just keeps sending applications messages. am i missing something? what are other implementations doing? i think that the paragraph about the re-exchange should to be extended in the current transport-draft. -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 4 04:39:04 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11261 for ; Wed, 4 Apr 2001 04:39:03 -0400 (EDT) Received: (qmail 11936 invoked by uid 605); 4 Apr 2001 08:38:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11928 invoked from network); 4 Apr 2001 08:38:55 -0000 Received: from mindterm.appgate.com (HELO mail.mindbright.se) (postfix@193.12.107.237) by mail.netbsd.org with SMTP; 4 Apr 2001 08:38:55 -0000 Received: by mail.mindbright.se (Postfix, from userid 1001) id ADA891FF07; Wed, 4 Apr 2001 10:53:09 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id A6CB21F106; Wed, 4 Apr 2001 10:53:09 +0200 (MEST) Date: Wed, 4 Apr 2001 10:53:09 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Key Re-Exchange In-Reply-To: <20010404015243.B30762@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, I agree that the draft might improve on clarity here. On Wed, 4 Apr 2001, Markus Friedl wrote: > is it true that no application data may be sent during key re-exchange? > > how is this 'during key re-exchange' defined? > > so, if you initiate the re-exchange, you have to wait for the KEXINIT > from the peer, but since there might be some more packets one the > wire i might get these messages before i get the KEXINIT. > > the problem here is that i cannot tell whether my KEXINIT message > did already arrive at the peer or whether the peer just ignores the > KEXINIT message and just keeps sending applications messages. > transport-draft says: ... Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. ... This message is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. ... Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. ... More application data may be sent after the SSH_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the Secure Shell transport layer. ... This seems to imply that no other messages than the KEX messages should be sent during the re-exchange (the state is not explicitly defined though, or rather the definition is spread across several paragraphs). > i think that the paragraph about the re-exchange should to be extended > in the current transport-draft. En exact definition of the state "key exchange" (valid for both "initial" key exchange and later re-exchange) could be given in a short paragraph like: ... The transport layer enters key exchange state as soon as a KEXINIT message is received. When this message is received, a party MUST respond with its own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT already was a reply. During key exchange the only valid messages, both for reception and transmission, are the KEX packets (range 30-49) and SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE. Any other messages SHOULD be considered a fatal protocol error. The key exchange state ends by each side sending an SSH_MSG_NEWKEYS message. ... This should probably go somewhere into paragraph 5.1. "Algorithm Negotiation". And be explicitly referred in the paragraph 7 "Key Re-Exchange". > what are other implementations doing? We disable and flush the transmitter queue directly when a KEXINIT is received and then send a KEXINIT directly (if it was not a "reply" to our own KEXINIT). The transmitter is re-enabled directly after the NEWKEYS has been sent. It is the exact same code for "initial" key exchange as for re-exchange (minus the session id). This seems to work well with SSH Inc's implementation (which is the only one we have tried it with). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 4 05:41:33 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12160 for ; Wed, 4 Apr 2001 05:41:32 -0400 (EDT) Received: (qmail 22075 invoked by uid 605); 4 Apr 2001 09:41:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22068 invoked from network); 4 Apr 2001 09:41:27 -0000 Received: from mindterm.appgate.com (HELO mail.mindbright.se) (postfix@193.12.107.237) by mail.netbsd.org with SMTP; 4 Apr 2001 09:41:27 -0000 Received: by mail.mindbright.se (Postfix, from userid 1001) id 0F8C51FF07; Wed, 4 Apr 2001 11:55:41 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by mail.mindbright.se (Postfix) with ESMTP id 091971F106; Wed, 4 Apr 2001 11:55:41 +0200 (MEST) Date: Wed, 4 Apr 2001 11:55:40 +0200 (MEST) From: Mats Andersson X-Sender: mats@mindterm.appgate.com To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Key Re-Exchange In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Ouch, On Wed, 4 Apr 2001, Mats Andersson wrote: > I agree that the draft might improve on clarity here. Shouldn't have said that when beeing ambigious myself! :-) > ... > The transport layer enters key exchange state as soon as a KEXINIT message > is received. When this message is received, a party MUST respond with its > own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT > already was a reply. During key exchange the only valid messages, both for > reception and transmission, are the KEX packets (range 30-49) and > SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE. Any other messages > SHOULD be considered a fatal protocol error. The key exchange state ends > by each side sending an SSH_MSG_NEWKEYS message. > ... Should be something like: The transport layer receiver enters key exchange state when it has received a KEXINIT. Symmetrically the transmitter enter key exchange state when it has sent a KEXINIT message. When a KEXINIT message has been received, a party MUST send a KEXINIT message if its transmitter isn't already in key exchange state. During key exchange the only valid messages, both for reception and transmission, are the KEX packets (range 30-49) and SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE. Any other messages SHOULD be considered a fatal protocol error. The key exchange state in the transmitter ends when a SSH_MSG_NEWKEYS is sent. Symmetrically the key exchange state ends in the receiver when the SSH_MSG_NEWKEYS is received. (incidentally, this is how I described our implementation though I'm better at writing code than definitions of what it does :-). Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 4 05:46:33 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12184 for ; Wed, 4 Apr 2001 05:46:32 -0400 (EDT) Received: (qmail 24670 invoked by uid 605); 4 Apr 2001 09:46:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24662 invoked from network); 4 Apr 2001 09:46:29 -0000 Received: from ixion.tartarus.org (195.153.205.133) by mail.netbsd.org with SMTP; 4 Apr 2001 09:46:29 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 14kjrl-0005cf-00; Wed, 04 Apr 2001 10:46:17 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <20010404015243.B30762@folly> Subject: Re: Key Re-Exchange Message-Id: Date: Wed, 04 Apr 2001 10:46:17 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl wrote: > the problem here is that i cannot tell whether my KEXINIT message > did already arrive at the peer or whether the peer just ignores the > KEXINIT message and just keeps sending applications messages. Well, if _you_ stop sending application messages after sending your own KEXINIT, then the peer can only ignore it for a limited time, because you won't be sending WINDOW_ADJUST messages. So any data the peer is still trying to transmit to you will eventually dry up as the windows all go down to zero, and then the peer will _have_ to pay attention to KEXINIT because it's the only thing left it can usefully do. It seems to me that should be sufficient. - Send KEXINIT. - Process incoming non-KEXINIT messages. If any of them require replies, such as WINDOW_ADJUST, queue the reply messages unencrypted to be sent after the re-exchange. - When the peer sends KEXINIT, do the key exchange. - After you send NEWKEYS, encrypt and send your reply messages. Does that make sense? Have I missed something? Cheers, Simon -- Simon Tatham "I'm going to pull his head off. Ear by ear." - a games teacher From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 4 05:50:43 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12240 for ; Wed, 4 Apr 2001 05:50:43 -0400 (EDT) Received: (qmail 27573 invoked by uid 605); 4 Apr 2001 09:50:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27503 invoked from network); 4 Apr 2001 09:50:35 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 4 Apr 2001 09:50:35 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id B835082F52C; Wed, 4 Apr 2001 11:50:33 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA12565; Wed, 4 Apr 2001 11:50:33 +0200 (MET DST) To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Key Re-Exchange References: <20010404015243.B30762@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 04 Apr 2001 11:50:32 +0200 In-Reply-To: Markus Friedl's message of "Wed, 4 Apr 2001 01:52:43 +0200" Message-ID: Lines: 86 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl writes: > I have some questions regarding the 'Key Re-Exchange' (aka rekeying): > > is it true that no application data may be sent during key re-exchange? I'd say not true (see below). > how is this 'during key re-exchange' defined? > > i think that that the re-exchange starts when a KEXINIT message has > been both sent _and_ received. That sounds like the only reasonable definition. And the exchange ends with the SSH_MSG_NEWKEYS message (which doesn't happen at the same time for both directions). > the problem here is that i cannot tell whether my KEXINIT message > did already arrive at the peer or whether the peer just ignores the > KEXINIT message and just keeps sending applications messages. I think you must process the application messages as normal. The peer should eventually respond to the KEXINIT. If it doesn't within some resonable time (say between your key reexchange interval and a tenth of that), you may consider it a protocol error and disconnect. > what are other implementations doing? lsh currently never *initiates* re-exchange, but besides from that there are four states: /* A KEX_INIT msg can be accepted. This is true, most of the time. */ #define KEX_STATE_INIT 0 In this state, we may or have not sent an KEXINIT ourselves. Packets other than KEXINIT are processed normally. On reception of KEXINIT, we enter KEX_STATE_IGNORE or KEX_STATE_IN_PROGRESS. /* Ignore next packet */ #define KEX_STATE_IGNORE 1 Special case to ignore a bad guess from the peer. Obviously, an application data packet doesn't make sense in this state. /* Key exchange is in progress. Neither KEX_INIT or NEWKEYS messages * can be received */ #define KEX_STATE_IN_PROGRESS 2 In this state, application packets are processed normally. I believe lsh also expects the peer to accept application data in this state. I also think this is reasonable thing to do: it should be easy to handle for an implementation, and if application data isn't allowed, the connection will appear to the user to freeze. Key re-exchange should be transparent to the user. /* Key exchange is finished. A NEWKEYS message should be received, and * nothing else. */ #define KEX_STATE_NEWKEYS 3 Currently, lsh only accepts NEWKEYS and DISCONNECT in this state. It ought to also accept IGNORE and DEBUG as well. The code in question is in connection_handle_packet in http://www.lysator.liu.se/~nisse/lsh/src/connection.c. > i think that the paragraph about the re-exchange should to be extended > in the current transport-draft. Sounds like a good idea. I also believe application data should be allowed during most of the key exchange. More precisely, at all times except 1. Between a KEXINIT message and any guessed packed. 2. Between the final keyexchange message and NEWKEYS. For the initial keyexchange, application data MUST not be sent before NEWKEYS, but that is just because they wouldn't be properly encrypted; from a pure protocol point of view, application data should be allowed even then. Finally, I don't think "application data" is a good term to use. It sounds like SSL speak. The spec should say which messages, or ranges of messages, that are allowed or disallowed at any time. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 4 06:01:41 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12571 for ; Wed, 4 Apr 2001 06:01:40 -0400 (EDT) Received: (qmail 904 invoked by uid 605); 4 Apr 2001 10:01:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 805 invoked from network); 4 Apr 2001 10:00:57 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 4 Apr 2001 10:00:57 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA29449; Wed, 4 Apr 2001 12:00:54 +0200 (MET DST) Date: Wed, 4 Apr 2001 12:00:54 +0200 From: Markus Friedl To: ietf-ssh@netbsd.org Cc: Mats Andersson Subject: Re: Key Re-Exchange Message-ID: <20010404120054.B28718@faui02.informatik.uni-erlangen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from mats@mindbright.se on Wed, Apr 04, 2001 at 11:55:40AM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list I think that the draft should point out that a sender MUST NOT send non-KEX messages after he _sent_ a KEXINIT message. he has to delay all non-KEX messages until he has sent the NEWKEYS message. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 5 03:46:58 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24841 for ; Thu, 5 Apr 2001 03:46:57 -0400 (EDT) Received: (qmail 22603 invoked by uid 605); 5 Apr 2001 07:46:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22596 invoked from network); 5 Apr 2001 07:46:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Apr 2001 07:46:49 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 2F4EC82F52E; Thu, 5 Apr 2001 09:46:47 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id JAA18419; Thu, 5 Apr 2001 09:46:46 +0200 (MET DST) To: Markus Friedl Cc: ietf-ssh@netbsd.org Subject: Re: Key Re-Exchange References: <20010404015243.B30762@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 05 Apr 2001 09:46:46 +0200 In-Reply-To: nisse@lysator.liu.se's message of "04 Apr 2001 11:50:32 +0200" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I wrote: > I also believe application data should be allowed during most of the > key exchange. More precisely, at all times except > > 1. Between a KEXINIT message and any guessed packed. > 2. Between the final keyexchange message and NEWKEYS. I have thought some more about this, and (2) is not quite consistent with the way I'd like things to work. The reason I want application data to be allowed is that I want an implementation to be able to process events immediately when they happen. For example, if I have some buffered data for some forwarded socket, and then I happen to write some of it, I want to be able to send a WINDOW_ADJUST message right away. If messages like this can't be sent during key (re)exchange, I need some extra packet queue besides my output buffer that contains raw encrypted data, and to the user, the connection will appear to freeze completely during the key exchange. The restriction (1) causes no problem; if any guessed packet is to be sent, it is known by the time the kexinit is sent, so it can be pushed into the output buffer right away. The restriction (2) works fine for the part sending the final keyexchange message (for dh exchange, that's the server sending a KEXDH_REPLY), at this time, session keys are known and NEWKEYS can be sent right away. But it doesn't work for the client, whose last keyexchange packet is KEXDH_INIT. When this is sent, session keys are not yet known, so it doesn't make much senss to send NEWKEYS. Instead the client must wait for the KEXDH_REPLY, and during that time, to satisfy (2), any packets resulting from events on channels must be put on hold. This doesn't feel quite right. Is there any reason we can't relax (2), and in general allow interleaving of keyexchange packets and other packets? /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 5 06:41:16 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26620 for ; Thu, 5 Apr 2001 06:41:15 -0400 (EDT) Received: (qmail 29009 invoked by uid 605); 5 Apr 2001 10:41:11 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20010405104111.29008.qmail@mail.netbsd.org> Received: (qmail 28999 invoked from network); 5 Apr 2001 10:41:10 -0000 Received: from plmta00.chello.pl (213.46.248.62) by mail.netbsd.org with SMTP; 5 Apr 2001 10:41:10 -0000 Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:02:36 -0100 From: "Rita de Groot" To: Subject: huidziekte Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 11:00:07 +0200 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 5 15:03:09 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11265 for ; Thu, 5 Apr 2001 15:03:08 -0400 (EDT) Received: (qmail 11438 invoked by uid 605); 5 Apr 2001 19:03:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11431 invoked from network); 5 Apr 2001 19:03:02 -0000 Received: from mariner.rem.cs.cmu.edu (128.2.81.22) by mail.netbsd.org with SMTP; 5 Apr 2001 19:03:02 -0000 Received: from MARINER.REM.CS.CMU.EDU by mariner.rem.cs.cmu.edu id aa02863; 5 Apr 2001 15:02 EDT Date: Thu, 5 Apr 2001 15:02:15 -0400 (EDT) From: Jeffrey Hutzelman X-Sender: jhutz@mariner.rem.cs.cmu.edu To: Bill Sommerfeld cc: ietf-ssh@netbsd.org Subject: Re: draft minutes from meeting at ietf50.. In-Reply-To: <200104031911.f33JBW906174@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 3 Apr 2001, Bill Sommerfeld wrote: > 5) GSSAPI > > There is now a unified GSSAPI key exchange draft (from all of the > previous GSSAPI drafts). > > Jeff Hutzelman put up a slide: > > The unified draft is for key exchange only. True. However, I talked with one of the authors of the user auth draft later in the week, and the next version will combine both key exchange and user auth in a single document. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 5 15:07:24 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11360 for ; Thu, 5 Apr 2001 15:07:23 -0400 (EDT) Received: (qmail 12700 invoked by uid 605); 5 Apr 2001 19:07:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12693 invoked from network); 5 Apr 2001 19:07:19 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 5 Apr 2001 19:07:19 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15715; Thu, 5 Apr 2001 12:07:17 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.166]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id MAA05153; Thu, 5 Apr 2001 12:07:33 -0700 (PDT) Received: from Eng.Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with ESMTP id f35J7BCp694319; Thu, 5 Apr 2001 12:07:12 -0700 (PDT) Message-ID: <3ACCC25E.93D6DA5D@Eng.Sun.COM> Date: Thu, 05 Apr 2001 12:07:10 -0700 From: Darren J Moffat Organization: Sun Microsystems Inc - Solaris Security Technologies Group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Hutzelman CC: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: draft minutes from meeting at ietf50.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > > 5) GSSAPI > > The unified draft is for key exchange only. > > True. However, I talked with one of the authors of the user auth draft > later in the week, and the next version will combine both key exchange and > user auth in a single document. Thats great news since I'm more interested in GSSAPI for user authentication. Ta. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 11 17:52:01 2001 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04023 for ; Wed, 11 Apr 2001 17:52:00 -0400 (EDT) Received: (qmail 29331 invoked by uid 605); 11 Apr 2001 21:51:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29324 invoked from network); 11 Apr 2001 21:51:51 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 11 Apr 2001 21:51:51 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26377 for ; Wed, 11 Apr 2001 14:51:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA04508 for ; Wed, 11 Apr 2001 14:51:57 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3BLpeB2263903; Wed, 11 Apr 2001 14:51:41 -0700 (PDT) Message-Id: <200104112151.f3BLpeB2263903@jurassic.eng.sun.com> Date: Wed, 11 Apr 2001 14:51:33 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: Using PAM an the SSH Protocol To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Qz8thiUg7ZKakIOHMXN5ig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_35 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list Some of you may have noticed that SSH Communications Security has announced support for PAM (Pluggable Authentication Modules) in its latest Windows platform clients and support for PAM first appeared in their 2.4.0 product. OpenSSH also has support for PAM in the portable release. PAM was originally developed by Sun Microsystems Inc (details at: http://sun.com/solaris/pam) as a means of abstracting out of programs like login and telnetd the user interaction required to authenticate the user, decide (based on access control policies) if they should access the system at this time and then setup their local credentials. At the present time there are (at least) two different methods of using PAM in the currently available SSH protocol implementations. In the SSH Communications Security implementation the client and server must agree to use the authentication method "pam-1@ssh.com" otherwise no PAM code is run. In the OpenSSH implementation PAM is used to authenticate the user if Keyboard Interactive is used (I'm talking about v2 protocol support, I know it is slightly different in v1). Regardless of wither or not Keyboard Interactive authentiation is run the PAM functions that deal with account management (pam_acct_mgmt) and setting of credentials (pam_setcred) are always run. What does this mean ? If I have a client connecting to an SSH Communications Security server that does not understand (or chooses not to send) "pam-1@ssh.com" as an authentication mechanism then the PAM functionality for pam_acct_mgmt will not get run. pam_acct_mgmt is responsible for makeing decisions on wither this user (who is authenticated, either by pam_authenticate or by other means) is actually allowed to access the system via this service at this time. Compare this with the OpenSSH implmentation where pam_acct_mgmt will always be run so the access restrictions will be correctly enforced. So isn't this an implmenation issue ? Tatu and I had a short discussion on this today and decided that at the present time we are not sure, there may be protocol issues, it might be that keyboard interactive can't solves them all, it might be limitations in PAM, or something else. One thing I am positive about is that if a particular server for the SSH protocol wants PAM to be used there should be no means for the client to by pass the access controls regardless of which SSH protocol authentication is used. Put another way PAM as a framework should not be visible to clients; it was only ever intended to be a server side implementation framework not a network protocol or an authentication mechanism in its own right (pam-1@ssh.com make it an auth mech). Why am I bringing this up on ietf-ssh ? I want to gather people who are interesting in helping solve this problem possible out comes are that there are defiencies in the core SSH protocol, Keyboard Interactive isn't enough to solve all PAM issues, PAM doesn't fit well with protocols like SSH (if it is the later then my goal would be to come up with some best practices on how it can be used and what limitations there are), or may be it is an implmenation issue - but it is important because at the moment there are interop problems that have potential security vulnerabilities in the view of system admins. If the WG chair believes that this is not an appropriate discussion for this list then I will arrange to take this offline once the interested parties have been identified. Thanks for your time. Resources: Sun Microsystems Inc Web Pages on PAM: http://sun.com/solaris/pam Open Group Single Sign-On Service (XSSO) - Plugable Authentication: http://www.opengroup.org/pubs/catalog/p702.htm -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Apr 17 03:11:47 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03994 for ; Tue, 17 Apr 2001 03:11:46 -0400 (EDT) Received: (qmail 1888 invoked by uid 605); 17 Apr 2001 07:11:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1881 invoked from network); 17 Apr 2001 07:11:26 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 17 Apr 2001 07:11:26 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 1DCDF3BD0A; Tue, 17 Apr 2001 09:11:38 +0200 (MET DST) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 803996C007; Tue, 17 Apr 2001 09:19:03 +0200 (CEST) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id 7CF15317B8; Tue, 17 Apr 2001 09:11:33 +0200 (MEST) Date: Tue, 17 Apr 2001 09:11:58 +0200 (MEST) From: Martin Forssen Subject: Re: Using PAM an the SSH Protocol To: Darren.Moffat@eng.sun.com Cc: ietf-ssh@netbsd.org In-Reply-To: <200104112151.f3BLpeB2263903@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20010417071133.7CF15317B8@pelee.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 11 Apr, Darren Moffat wrote: > I want to gather people who are interesting in helping solve this > problem possible out comes are that there are defiencies in the core > SSH protocol, Keyboard Interactive isn't enough to solve all PAM > issues, PAM doesn't fit well with protocols like SSH (if it is the > later then my goal would be to come up with some best practices on how > it can be used and what limitations there are), or may be it is an > implmenation issue - but it is important because at the moment there > are interop problems that have potential security vulnerabilities in > the view of system admins. I am definitely interested in discussing this. I did look into this issue while I was working with keyboard-interactive and I can try to recollect my thoughts on the issue from that time. /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 18 18:58:55 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19287 for ; Wed, 18 Apr 2001 18:58:54 -0400 (EDT) Received: (qmail 16605 invoked by uid 605); 18 Apr 2001 22:58:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16598 invoked from network); 18 Apr 2001 22:58:29 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 18 Apr 2001 22:58:29 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11267 for ; Wed, 18 Apr 2001 15:58:45 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11656 for ; Wed, 18 Apr 2001 18:58:44 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f3IMwU915088 for ; Wed, 18 Apr 2001 18:58:30 -0400 (EDT) Message-Id: <200104182258.f3IMwU915088@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: New draft editor. In-reply-to: Your message of "Mon, 02 Apr 2001 15:50:12 PDT." <200104022250.f32MoCWI973027@jurassic.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 18 Apr 2001 18:58:30 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list I'm pleased to announce that Darren Moffat will be taking over as editor of the four core SSH drafts. He's promised to have new revisions out soon (especially now that I've identified him publically :-) ). Please send comments, suggested revisions, etc., on the documents to the working group list as a whole. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 20 15:07:00 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16512 for ; Fri, 20 Apr 2001 15:06:58 -0400 (EDT) Received: (qmail 6006 invoked by uid 605); 20 Apr 2001 19:06:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5999 invoked from network); 20 Apr 2001 19:06:27 -0000 Received: from citi.umich.edu (141.211.92.141) by mail.netbsd.org with SMTP; 20 Apr 2001 19:06:27 -0000 Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id 5B114207C1; Fri, 20 Apr 2001 15:06:47 -0400 (EDT) Subject: Re: draft minutes from meeting at ietf50.. From: Niels Provos In-Reply-To: Bill Sommerfeld, Tue, 03 Apr 2001 15:11:32 EDT To: sommerfeld@east.sun.com Cc: ietf-ssh@netbsd.org Date: Fri, 20 Apr 2001 15:06:47 -0400 Message-Id: <20010420190647.5B114207C1@citi.umich.edu> Sender: ietf-ssh-owner@netbsd.org Precedence: list I suggest that the following paragraphs be included in the transport draft. They contain recommendations for the size of private exponent in the DH key exchange, and mention security problems related to traffic analysis. Greetings, Niels. Implementation Notes: To increase the speed of the key exchange, both client and server may reduce the size of their private exponents. It should be at least twice as long as the key material that is generated from the shared secret. For more details see the paper by van Oorschot and Wiener [A]. [A] P. C. van Oorschot and M. J. Wiener, On Diffie-Hellman key agreement with short exponents, In Advances in Cryptology - EUROCRYPT'96, LNCS 1070, Springer-Verlag, 1996, pp.332-343. An adversary can listen to SSH network traffic to determine the length of authentication passwords typed during login and interactive shell sessions [B]. Using packet timing analysis, it is also possible to infer the probability of letter combinations in the typed passwords [C]. SSH servers and clients MAY send SSH_MSG_IGNORE messages to mitigate the impact of traffic analysis. [B] OpenWall Security Advisory, Passive Analysis of SSH (Secure Shell) Traffic, http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt [C] Dawn Song, David Wagner and Xuqing Tian, Keystroke Analysis and SSH Timing Attacks, 10th USENIX Security Symposium, August 2001 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Apr 21 06:23:12 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09082 for ; Sat, 21 Apr 2001 06:23:11 -0400 (EDT) Received: (qmail 18975 invoked by uid 605); 21 Apr 2001 10:22:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18968 invoked from network); 21 Apr 2001 10:22:45 -0000 Received: from ns1.crl.go.jp (133.243.3.1) by mail.netbsd.org with SMTP; 21 Apr 2001 10:22:45 -0000 Received: from crlgw1.crl.go.jp (crlgw1.crl.go.jp [133.243.18.250]) by ns1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f3LAMut21089; Sat, 21 Apr 2001 19:22:56 +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 f3LAMtI01291; Sat, 21 Apr 2001 19:22:55 +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 PAA08177; Sat, 21 Apr 2001 15:50:10 +0900 (JST) Date: Sat, 21 Apr 2001 15:50:10 +0900 (JST) From: Tom Holroyd X-Sender: To: Niels Provos cc: , Subject: Re: draft minutes from meeting at ietf50.. In-Reply-To: <20010420190647.5B114207C1@citi.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, 20 Apr 2001, Niels Provos wrote: > An adversary can listen to SSH network traffic to determine the length > of authentication passwords typed during login and interactive shell > sessions [B]. Of course SRP authentication fixes that... The SRP shared secret can also be used to trigger a key-reexchange, which makes shorter DH parameters less of a problem. Tom Wu tells me that Stanford should be issuing the all-clear on SRP any day now... Dr. Tom From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Apr 21 11:28:44 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10935 for ; Sat, 21 Apr 2001 11:28:40 -0400 (EDT) Received: (qmail 8933 invoked by uid 605); 21 Apr 2001 15:28:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8883 invoked from network); 21 Apr 2001 15:28:06 -0000 Received: from muedi6-212-144-216-041.arcor-ip.net (HELO folly.informatik.uni-erlangen.de) (@212.144.216.41) by mail.netbsd.org with SMTP; 21 Apr 2001 15:28:06 -0000 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 7631E5541; Sat, 21 Apr 2001 17:02:16 +0200 (CEST) Date: Sat, 21 Apr 2001 17:02:16 +0200 From: Markus Friedl To: Tom Holroyd Cc: Niels Provos , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: draft minutes from meeting at ietf50.. Message-ID: <20010421170216.A30811@folly> References: <20010420190647.5B114207C1@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tomh@po.crl.go.jp on Sat, Apr 21, 2001 at 03:50:10PM +0900 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, Apr 21, 2001 at 03:50:10PM +0900, Tom Holroyd wrote: > On Fri, 20 Apr 2001, Niels Provos wrote: > > > An adversary can listen to SSH network traffic to determine the length > > of authentication passwords typed during login and interactive shell > > sessions [B]. > > Of course SRP authentication fixes that... The SRP shared secret can also > be used to trigger a key-reexchange, which makes shorter DH parameters > less of a problem. i don't see how SRP makes traffic analysis harder. could you please provide details. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Apr 22 20:54:42 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14429 for ; Sun, 22 Apr 2001 20:54:41 -0400 (EDT) Received: (qmail 20494 invoked by uid 605); 23 Apr 2001 00:54:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20487 invoked from network); 23 Apr 2001 00:54:11 -0000 Received: from ns1.crl.go.jp (133.243.3.1) by mail.netbsd.org with SMTP; 23 Apr 2001 00:54:11 -0000 Received: from crlgw1.crl.go.jp (crlgw1.crl.go.jp [133.243.18.250]) by ns1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f3N0sLt18267; Mon, 23 Apr 2001 09:54:21 +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 f3N0sLG01676; Mon, 23 Apr 2001 09:54:21 +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 JAA19650; Mon, 23 Apr 2001 09:54:19 +0900 (JST) Date: Mon, 23 Apr 2001 09:54:19 +0900 (JST) From: Tom Holroyd X-Sender: To: Markus Friedl cc: Niels Provos , , Subject: Re: draft minutes from meeting at ietf50.. In-Reply-To: <20010421170216.A30811@folly> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, 21 Apr 2001, Markus Friedl wrote: > On Sat, Apr 21, 2001 at 03:50:10PM +0900, Tom Holroyd wrote: > > On Fri, 20 Apr 2001, Niels Provos wrote: > > > > > An adversary can listen to SSH network traffic to determine the length > > > of authentication passwords typed during login and interactive shell > > > sessions [B]. > > > > Of course SRP authentication fixes that... The SRP shared secret can also > > be used to trigger a key-reexchange, which makes shorter DH parameters > > less of a problem. > > i don't see how SRP makes traffic analysis harder. > > could you please provide details. The SRP password is never sent over the network, only some random bignums of known length, and some hashes, also of known length. So even if you can observe traffic you can't get the length of the password/phrase. OTOH, if you ssh to host A, and then from host A ssh to host B, your password will be sent over the (encrypted) link from your client to A, so that may leak password length information. That can be fixed by running ssh from your client and either connecting directly to B, or if that's not possible, forwarding the connection through A (instead of running ssh on A). 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 Sun Apr 22 23:02:32 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16864 for ; Sun, 22 Apr 2001 23:02:31 -0400 (EDT) Received: (qmail 2475 invoked by uid 605); 23 Apr 2001 03:02:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2463 invoked from network); 23 Apr 2001 03:01:59 -0000 Received: from fw.hel.fi.ssh.com (193.64.193.124) by mail.netbsd.org with SMTP; 23 Apr 2001 03:01:59 -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 GAA06406 for ; Mon, 23 Apr 2001 06:02:23 +0300 (EEST) Received: (qmail 26851 invoked from network); 23 Apr 2001 03:02:23 -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 ; 23 Apr 2001 03:02:23 -0000 Received: (from mkojo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id GAA09379; Mon, 23 Apr 2001 06:02:22 +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: <15075.39742.414468.167663@torni.hel.fi.ssh.com> Date: Mon, 23 Apr 2001 06:02:22 +0300 To: Tom Holroyd Cc: Markus Friedl , Niels Provos , , Subject: Re: draft minutes from meeting at ietf50.. In-Reply-To: References: <20010421170216.A30811@folly> X-Mailer: VM 6.88 under Emacs 20.7.2 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom, I suppose that the question should be Q: How could the leakage of information in interactive sessions be made negligible? If such an improvement exists then (interesting) traffic analysis becomes impossible as a consequence. My answer would currently be: there is no such (practical) improvement. The only robust improvement that I know would require non-negligible increase in traffic. Naturally this suggests that the problem is not the protocol. Infact, SRP is not a protocol fix---it fixes only those applications(*) that are aware of this feature. Similar effect would be obtained by having a specific password packet that holds the password in its entirety, rather than sending it in pieces. (*) I consider everything above the transportation layer as an "application" of the protocol. Sorry for abuse of terminology. As you suggest it is possible by careful use and implementation of the applications to make sure that important information is not leaked. Mika Kojo SSH Communications Security Corp Tom Holroyd writes: > On Sat, 21 Apr 2001, Markus Friedl wrote: > > > On Sat, Apr 21, 2001 at 03:50:10PM +0900, Tom Holroyd wrote: > > > On Fri, 20 Apr 2001, Niels Provos wrote: > > > > > > > An adversary can listen to SSH network traffic to determine the length > > > > of authentication passwords typed during login and interactive shell > > > > sessions [B]. > > > > > > Of course SRP authentication fixes that... The SRP shared secret can also > > > be used to trigger a key-reexchange, which makes shorter DH parameters > > > less of a problem. > > > > i don't see how SRP makes traffic analysis harder. > > > > could you please provide details. > > The SRP password is never sent over the network, only some random bignums > of known length, and some hashes, also of known length. So even if you > can observe traffic you can't get the length of the password/phrase. > > OTOH, if you ssh to host A, and then from host A ssh to host B, your > password will be sent over the (encrypted) link from your client to A, so > that may leak password length information. That can be fixed by running > ssh from your client and either connecting directly to B, or if that's not > possible, forwarding the connection through A (instead of running ssh on > A). > > 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 Mon Apr 23 02:31:46 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02123 for ; Mon, 23 Apr 2001 02:31:46 -0400 (EDT) Received: (qmail 22195 invoked by uid 605); 23 Apr 2001 06:31:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22188 invoked from network); 23 Apr 2001 06:31:14 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 23 Apr 2001 06:31:14 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id IAA24699; Mon, 23 Apr 2001 08:31:28 +0200 (MET DST) Date: Mon, 23 Apr 2001 08:31:28 +0200 From: Markus Friedl To: Tom Holroyd Cc: Niels Provos , sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: draft minutes from meeting at ietf50.. Message-ID: <20010423083128.C6914@faui02.informatik.uni-erlangen.de> References: <20010421170216.A30811@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from tomh@po.crl.go.jp on Mon, Apr 23, 2001 at 09:54:19AM +0900 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Apr 23, 2001 at 09:54:19AM +0900, Tom Holroyd wrote: > On Sat, 21 Apr 2001, Markus Friedl wrote: > > > On Sat, Apr 21, 2001 at 03:50:10PM +0900, Tom Holroyd wrote: > > > On Fri, 20 Apr 2001, Niels Provos wrote: > > > > > > > An adversary can listen to SSH network traffic to determine the length > > > > of authentication passwords typed during login and interactive shell > > > > sessions [B]. > > > > > > Of course SRP authentication fixes that... The SRP shared secret can also > > > be used to trigger a key-reexchange, which makes shorter DH parameters > > > less of a problem. > > > > i don't see how SRP makes traffic analysis harder. > > > > could you please provide details. > > The SRP password is never sent over the network, only some random bignums > of known length, and some hashes, also of known length. So even if you > can observe traffic you can't get the length of the password/phrase. this does not fork for 'interactive shell sessions', e.g. if i login in and type 'su'. the authentication used in the ssh connection is not relevant. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 23 03:22:17 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02305 for ; Mon, 23 Apr 2001 03:22:16 -0400 (EDT) Received: (qmail 4183 invoked by uid 605); 23 Apr 2001 07:21:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4176 invoked from network); 23 Apr 2001 07:21:44 -0000 Received: from ns1.crl.go.jp (133.243.3.1) by mail.netbsd.org with SMTP; 23 Apr 2001 07:21:44 -0000 Received: from crlgw1.crl.go.jp (crlgw1.crl.go.jp [133.243.18.250]) by ns1.crl.go.jp (8.11.3+3.4W/3.7W) with ESMTP id f3N7M9t12929 for ; Mon, 23 Apr 2001 16:22:09 +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 f3N7M9Y18169 for ; Mon, 23 Apr 2001 16:22:09 +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 QAA00170 for ; Mon, 23 Apr 2001 16:22:08 +0900 (JST) Date: Mon, 23 Apr 2001 16:22:08 +0900 (JST) From: Tom Holroyd X-Sender: To: Subject: Re: draft minutes from meeting at ietf50.. In-Reply-To: <20010423083128.C6914@faui02.informatik.uni-erlangen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 23 Apr 2001, Markus Friedl wrote: > this does not fork for 'interactive shell sessions', e.g. if i > login in and type 'su'. the authentication used in the ssh connection > is not relevant. True (I believe I mentioned that in the part of my post you didn't quote). So, a) don't do that, use ssh -l root, or b) is there any way to re-write "su" so that it connects back to the ssh client machine to request authentication? Can su be rewritten to use the ssh-agent? Do the ssh protocols allow "sideband" control channels that could be opened from the remote end? I like a), plus setting "su" to fail for network users. But some of b) has interesting possibilities. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 23 05:29:18 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02858 for ; Mon, 23 Apr 2001 05:29:17 -0400 (EDT) Received: (qmail 17622 invoked by uid 605); 23 Apr 2001 09:28:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17609 invoked from network); 23 Apr 2001 09:28:44 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 23 Apr 2001 09:28:44 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6423B82F479; Mon, 23 Apr 2001 11:29:08 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA20055; Mon, 23 Apr 2001 11:29:07 +0200 (MET DST) To: Tom Holroyd Cc: Subject: Re: draft minutes from meeting at ietf50.. References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 23 Apr 2001 11:29:07 +0200 In-Reply-To: Tom Holroyd's message of "Mon, 23 Apr 2001 16:22:08 +0900 (JST)" Message-ID: Lines: 10 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Tom Holroyd writes: > So, a) don't do that, use ssh -l root, It is quite common policy to not allow people to log in as root directly from the network, but rather *require* that they first log in as an ordinary user and then su. I don't know all the pros and cons of that policy, but I don't think it is going away soon. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 23 14:08:26 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08942 for ; Mon, 23 Apr 2001 14:08:24 -0400 (EDT) Received: (qmail 1233 invoked by uid 605); 23 Apr 2001 18:07:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1224 invoked from network); 23 Apr 2001 18:07:49 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 23 Apr 2001 18:07:49 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25063 for ; Mon, 23 Apr 2001 11:08:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA23686 for ; Mon, 23 Apr 2001 11:08:24 -0700 (PDT) Received: from quirm (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.0.Beta7+Sun/8.12.0.Beta7) with SMTP id f3NI82B2536199 for ; Mon, 23 Apr 2001 11:08:05 -0700 (PDT) Message-Id: <200104231808.f3NI82B2536199@jurassic.eng.sun.com> Date: Mon, 23 Apr 2001 11:07:05 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: draft minutes from meeting at ietf50.. To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: m0QMi57h9S1DiCDEQH5HTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list I thought the vulnerabitliy was about the users login password when using password access rather than publickey, where did su come into it ? Maybe I'm missing something here but how can any guessing be done about password length when running the su across the encrypted link ? Surely this is no different to running ls -l and given the link is encrypted there should be no way for an attacker to know what it is I'm actually doing. >> So, a) don't do that, use ssh -l root, > >It is quite common policy to not allow people to log in as root >directly from the network, but rather *require* that they first log in >as an ordinary user and then su. I don't know all the pros and cons of >that policy, but I don't think it is going away soon. ** OFF TOPIC DISCUSSION ** Not only is it common policy many operating systems make it the default for telnet/rlogind. The idea being you don't want the root password going across the wire, but since the link isn't encrypted it goes across the wire when you use su anyway. It also slighly reduces the risk if the root password is compromised and no user password has been, but only slightly. It is a good policy in systems that have an audit id, like Solaris, AIX, SCO (and I'm sure others as well), since forcing the login as the user first means the audit trail will be properly setup to say which real user was doing stuff as root. Addressing Tom's point about rewriting su, it could be done but then it wouldn't be su anymore! For systems that have PAM this could be done using PAM modules for su but that really has nothing to do with the SSH protocol. If this WG is going to find a solution to the problem then it needs to be an SSH protocol fix or implementation suggestion. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 23 17:34:15 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13269 for ; Mon, 23 Apr 2001 17:34:13 -0400 (EDT) Received: (qmail 13522 invoked by uid 605); 23 Apr 2001 21:33:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13514 invoked from network); 23 Apr 2001 21:33:39 -0000 Received: from faui02.informatik.uni-erlangen.de (msfriedl@131.188.30.102) by mail.netbsd.org with SMTP; 23 Apr 2001 21:33:39 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id XAA11075; Mon, 23 Apr 2001 23:34:02 +0200 (MET DST) Date: Mon, 23 Apr 2001 23:34:02 +0200 From: Markus Friedl To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: draft minutes from meeting at ietf50.. Message-ID: <20010423233401.A10864@faui02.informatik.uni-erlangen.de> References: <200104231808.f3NI82B2536199@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <200104231808.f3NI82B2536199@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Mon, Apr 23, 2001 at 11:07:05AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Apr 23, 2001 at 11:07:05AM -0700, Darren Moffat wrote: > I thought the vulnerabitliy was about the users login password when > using password access rather than publickey, where did su come into it ? this is what http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt is about. just try it with OpenSSH-2.3, for example. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Apr 25 05:53:19 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09920 for ; Wed, 25 Apr 2001 05:53:18 -0400 (EDT) Received: (qmail 13244 invoked by uid 605); 25 Apr 2001 09:52:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13235 invoked from network); 25 Apr 2001 09:52:39 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 25 Apr 2001 09:52:39 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6B39E82F525 for ; Wed, 25 Apr 2001 11:53:09 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id LAA04966; Wed, 25 Apr 2001 11:53:09 +0200 (MET DST) To: ietf-ssh@netbsd.org Subject: The algorithm name "" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 25 Apr 2001 11:53:08 +0200 Message-ID: Lines: 75 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I've had some reports on interoperation problems with the latest lsh client and a server presenting itself as "SSH-1.99-2.0.13 (non-commercial)". The server sends a USERAUTH_FAILURE message DEBUG: Received USERAUTH_FAILURE (size 25 = 0x19) 00000000: 33000000137075626c69636b65792c70 3....publickey,p 00000010: 617373776f72642c00 assword,. Looking at the packet, the "authentications that can continue" string is "publickey,password,". Note the trailing comma. lsh parses this as a list with three elements "publickey", "password", "". And it considers empty algorithm names as a protocol error and disconnects. Am I being overly pedantic, or should empty algorithm names be treated as errors? As far as I can see, the only limits the architecture spec sets is a maximum size, and a limits on the characters that can be used. On the other hand, I really hope that the algorithm name "" will never be defined by this wg, so it is highly unreasonable to send it. Another question is how to interpret the list "" (which makes sense for instance in the languages_client_to_server list). Is that an empty list, or a list containing a single empty string?Ruling out empty strings resolves that ambiguity, making sure that "" can only be interpreted as an empty list. I'd like to edit the architecture draft as follows, Current text: 5. Algorithm Naming The SSH protocols refer to particular hash, encryption, integrity, compression, and key exchange algorithms or protocols by names. There are some standard algorithms that all implementations MUST support. There are also algorithms that are defined in the protocol specification but are OPTIONAL. Furthermore, it is expected that some organizations will want to use their own algorithms. In this protocol, all algorithm identifiers MUST be printable US-ASCII strings no longer than 64 characters. Names MUST be case-sensitive. Proposal: Replace the last paragraph with In this protocol, all algorithm identifiers MUST be printable US-ASCII non-empty strings no longer than 64 characters. Names MUST be case-sensitive. It may also be a good idea to specify the format for comma-separated lists once, in the architecture document. Proposal, to be added to section 4, "Data Type Representations Used in the SSH Protocols" in the architecture document: name-list A string containing a comma separated list of names. A name list is stored as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of zero or more names. A name MUST be non-empty, and it MUST NOT contain a comma (','). Context may impose additional restrictions on the names, for example, the names in a list may have to be valid algorithm identifier (see Algorithm Naming below), or [RFC-1766] language tags. The order of the names in a list may or may not be significant, also depending on the context where the list is is used. Terminating NUL characters are not used, neither for the individual names, nor for the list as a whole. Examples: value representation (hex) --------------------------------------- (), the empty list 00 00 00 00 ("zlib") 00 00 00 04 7a 6c 69 62 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Apr 26 07:22:49 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28359 for ; Thu, 26 Apr 2001 07:22:49 -0400 (EDT) Received: (qmail 28208 invoked by uid 605); 26 Apr 2001 11:22:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28201 invoked from network); 26 Apr 2001 11:22:08 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 26 Apr 2001 11:22:08 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28299; Thu, 26 Apr 2001 07:22:24 -0400 (EDT) Message-Id: <200104261122.HAA28299@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-dh-group-exchange-01.txt Date: Thu, 26 Apr 2001 07:22:20 -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 : Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol Author(s) : M. Friedl, N. Provos, W. Simpson Filename : draft-ietf-secsh-dh-group-exchange-01.txt Pages : 8 Date : 25-Apr-01 This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-01.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-dh-group-exchange-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010425143107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dh-group-exchange-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010425143107.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 27 06:25:13 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20659 for ; Fri, 27 Apr 2001 06:25:12 -0400 (EDT) Received: (qmail 10228 invoked by uid 605); 27 Apr 2001 10:24:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10219 invoked from network); 27 Apr 2001 10:24:31 -0000 Received: from unknown (HELO anchorage.arcot.com) (209.247.197.162) by mail.netbsd.org with SMTP; 27 Apr 2001 10:24:31 -0000 Received: from arcot.com (209.247.197.126 [209.247.197.126]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JPN5CG1M; Fri, 27 Apr 2001 03:17:48 -0700 Message-ID: <3AE94947.D2549545@arcot.com> Date: Fri, 27 Apr 2001 03:26:15 -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: ietf-ssh@netbsd.org, openssh-unix-dev@mindrot.org Subject: SRP unencumbered license statement available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit 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. Tom From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 27 15:17:37 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11931 for ; Fri, 27 Apr 2001 15:17:35 -0400 (EDT) Received: (qmail 11874 invoked by uid 605); 27 Apr 2001 19:16:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11867 invoked from network); 27 Apr 2001 19:16:54 -0000 Received: from 216-174-224-194.atgi.net (HELO interceptor.mahinetworks.com) (216.174.224.194) by mail.netbsd.org with SMTP; 27 Apr 2001 19:16:54 -0000 Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Fri, 27 Apr 2001 12:21:58 -0700 (Pacific Daylight Time) Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id <2XMKA0L9>; Fri, 27 Apr 2001 12:18:34 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9C024E6@main.mahinetworks.com> From: Charles Chen To: "'ietf-ssh@netbsd.org'" Subject: Does SSH run over NAT?? Date: Fri, 27 Apr 2001 12:18:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I have a question with regard to SSH. Assume that we have a gateway which does network address and port translation (NAT). The gateway works for telnet. Is there any problem if we run SSH on top of a telnet session in this case? Charles From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Apr 27 19:04:46 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18806 for ; Fri, 27 Apr 2001 19:04:45 -0400 (EDT) Received: (qmail 14541 invoked by uid 605); 27 Apr 2001 23:04:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14534 invoked from network); 27 Apr 2001 23:04:02 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 27 Apr 2001 23:04:02 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27003 for ; Fri, 27 Apr 2001 16:04:37 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10774 for ; Fri, 27 Apr 2001 19:04:36 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f3RN4K914742 for ; Fri, 27 Apr 2001 19:04:20 -0400 (EDT) Message-Id: <200104272304.f3RN4K914742@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: another trademark application Reply-to: sommerfeld@east.sun.com Date: Fri, 27 Apr 2001 19:04:19 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list 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 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Apr 29 17:22:26 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11722 for ; Sun, 29 Apr 2001 17:22:25 -0400 (EDT) Received: (qmail 28755 invoked by uid 605); 29 Apr 2001 21:21:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28743 invoked from network); 29 Apr 2001 21:21:39 -0000 Received: from 209-9-249-62.sdsl.cais.net (HELO gnat.inet.org) (209.9.249.62) by mail.netbsd.org with SMTP; 29 Apr 2001 21:21:39 -0000 Received: from mosquito.inet.org (mosquito [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 63AF88266E; Sun, 29 Apr 2001 17:21:43 -0400 (EDT) Message-Id: <5.1.0.14.2.20010429171757.009f37f0@10.30.15.2> X-Sender: rja@10.30.15.2 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 29 Apr 2001 17:19:48 -0400 To: Tom Wu From: RJ Atkinson Subject: Re: SRP unencumbered license statement available Cc: ietf-ssh@netbsd.org In-Reply-To: <3AE94947.D2549545@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@netbsd.org Precedence: list 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... Cheers, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Apr 30 09:17:30 2001 Received: from mail.netbsd.org ([155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08907 for ; Mon, 30 Apr 2001 09:17:25 -0400 (EDT) Received: (qmail 15754 invoked by uid 605); 30 Apr 2001 13:16:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15742 invoked from network); 30 Apr 2001 13:16:38 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 30 Apr 2001 13:16:38 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 8B24F82F559; Mon, 30 Apr 2001 15:17:12 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id PAA15067; Mon, 30 Apr 2001 15:17:12 +0200 (MET DST) To: Charles Chen Cc: "'ietf-ssh@netbsd.org'" Subject: Re: Does SSH run over NAT?? References: <9D6D37E97A57D411BB7C00508BAE29C9C024E6@main.mahinetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: nisse@lysator.liu.se (Niels Möller) Date: 30 Apr 2001 15:17:12 +0200 In-Reply-To: Charles Chen's message of "Fri, 27 Apr 2001 12:18:30 -0700" Message-ID: Lines: 15 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Charles Chen writes: > I have a question with regard to SSH. > Assume that we have a gateway which does > network address and port translation (NAT). > The gateway works for telnet. Is there any > problem if we run SSH on top of a telnet session > in this case? It should work fine, I'm doing it right now. (Of course there are lots of ways to shoot oneself or others in the feet when using NAT, but SSH shouldn't be harder than telnet or http). /Niels