From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 5 15:12:30 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 PAA24171 for ; Thu, 5 Jul 2001 15:12:29 -0400 (EDT) Received: (qmail 15870 invoked by uid 605); 5 Jul 2001 19:09:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15859 invoked from network); 5 Jul 2001 19:09:53 -0000 Received: from mail.vandyke.com (204.134.9.1) by mail.netbsd.org with SMTP; 5 Jul 2001 19:09:53 -0000 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 168 for ; Thu, 5 Jul 2001 13:16:07 -0600 Message-ID: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: Subject: x.509 signature clarification? Date: Thu, 5 Jul 2001 13:09:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit We've been looking at x.509 certificates, as specified in the draft and as implemented by SSH Communications in their 3.0 release, and have come to the conclusion that the draft is underspecified. From the transport draft 4.6 (pg. 11): > The "x509v3-sign-rsa" method indicates that the certificates, the public > key, and the resulting signature are in X.509v3 compatible DER-encoded > format. The formats used in X.509v3 is described in [RFC-2459]. This > method indicates that the key (or one of the keys in the certificate) is > an RSA-key. Looking at RFC 2459, it appears that it describes the profile for x.509 certificates, but doesn't really specify anything about signature encoding. I think this reference can be dropped. For x.509 certificates using rsa keys, SSH Communications 3.0 appears to be using PKCS #1 with MD5. I'm not sure what they are doing for DSS signatures. There appears to be two areas where the draft needs clarification: 1. Which digest algorithm should be used? (Given that we use SHA1 for ssh-rsa keys, this would seem the natural choice.) 2. What should the format of the signature be? I'm tempted to suggest that the signature is in PKCS #7 format, though this seems to be a bit of an overkill... it would however, address both the above problems, because the digest algorithm would be specified as part of the PKCS #7 packet. We might consider specifying a PKCS #7 signature, with an "external signature" and no included certificates or CRL information. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 5 15:49:37 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 PAA25263 for ; Thu, 5 Jul 2001 15:49:36 -0400 (EDT) Received: (qmail 29018 invoked by uid 605); 5 Jul 2001 19:47:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29011 invoked from network); 5 Jul 2001 19:47:15 -0000 Received: from mort-subite.cs.stevens-tech.edu (155.246.89.33) by mail.netbsd.org with SMTP; 5 Jul 2001 19:47:15 -0000 Received: by mort-subite.cs.stevens-tech.edu (Postfix, from userid 3330) id 42BA218B0; Thu, 5 Jul 2001 15:50:15 -0400 (EDT) Date: Thu, 5 Jul 2001 15:50:15 -0400 From: Thor Simon To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Subject: Re: x.509 signature clarification? Message-ID: <20010705155015.C7316@cs.stevens-tech.edu> References: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Thu, Jul 05, 2001 at 01:09:39PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jul 05, 2001 at 01:09:39PM -0600, Joseph Galbraith wrote: > > I'm tempted to suggest that the signature is in PKCS #7 > format, though this seems to be a bit of an overkill... > it would however, address both the above problems, because > the digest algorithm would be specified as part of the PKCS #7 > packet. We might consider specifying a PKCS #7 signature, > with an "external signature" and no included certificates > or CRL information. Actually, I think that if we were to go with PKCS #7 (which might not really be such a bad idea) we'd want to fill out the certificate as fully as possible, including CRL information. Look what's happened to people who've failed to do so (e.g. VeriSign, who ended up in the unenviable position of having issued bogus certificates but being unable to revoke them!). Certainly we should not specify that the CRL field is *not* to be filled in. Thor From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jul 6 15:38:50 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 PAA17293 for ; Fri, 6 Jul 2001 15:38:49 -0400 (EDT) Received: (qmail 15313 invoked by uid 605); 6 Jul 2001 19:36:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15306 invoked from network); 6 Jul 2001 19:36:25 -0000 Received: from mail.vandyke.com (204.134.9.1) by mail.netbsd.org with SMTP; 6 Jul 2001 19:36:25 -0000 Received: from merlin ([127.0.0.1]) by mail.vandyke.com (Netscape Messaging Server 3.62) with SMTP id 383; Fri, 6 Jul 2001 13:42:43 -0600 Message-ID: <01d101c10652$e93d7b10$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Thor Simon" Cc: References: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com> <20010705155015.C7316@cs.stevens-tech.edu> Subject: Re: x.509 signature clarification? Date: Fri, 6 Jul 2001 13:36:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > On Thu, Jul 05, 2001 at 01:09:39PM -0600, Joseph Galbraith wrote: > > > > I'm tempted to suggest that the signature is in PKCS #7 > > format, though this seems to be a bit of an overkill... > > it would however, address both the above problems, because > > the digest algorithm would be specified as part of the PKCS #7 > > packet. We might consider specifying a PKCS #7 signature, > > with an "external signature" and no included certificates > > or CRL information. > > Actually, I think that if we were to go with PKCS #7 (which might > not really be such a bad idea) we'd want to fill out the certificate > as fully as possible, including CRL information. Look what's happened > to people who've failed to do so (e.g. VeriSign, who ended up in the > unenviable position of having issued bogus certificates but being unable > to revoke them!). > > Certainly we should not specify that the CRL field is *not* to be > filled in. Hmm... the certificate itself has already been communicated via the SSH protocol, which is why I wrote what I did. But, on the other hand, it might be nice to be able to include other certificates from the chain in the signature. I think that CRLs in a PKCS #7 signature are "hotlist" items intended as one method of propagating revocations and to allow the verifier to update it's certificate database. They clearly can't be used to validate the Certificate in use, since if I'm an attacker using a compromised certificate, I'm certainly not going to tell you it's been revoked! On the other hand, it seems much cleaner to accept PKCS #7 entirely, rather then try to specify PKCS #7 minus this feature and that feature. So, I think you're right, if we decide to go with PKCS #7, we shouldn't restrict what fields can be used. I original thought that I PKCS #7 had a lot of information that was not applicable to SSH applications or was redundant... but, on further thought, (and having actually implemented a decoder / encoder now), it seems that most of the information is useful to us in the SSH context. So perhaps PKCS #7 isn't an overkill. Would implementers find it overly burdensome to implement PKCS #7? Or are most people using crypto libraries that would already do this for them? For myself, my crypto library produces PKCS #7, so it would actually be more convenient for me... otherwise, I have to decode the PKCS #7 packet on the signing side and build a PKCS #7 packet on the verifying side. Joseph Galbraith galb-list@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Jul 7 03:27:40 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 DAA16257 for ; Sat, 7 Jul 2001 03:27:39 -0400 (EDT) Received: (qmail 25507 invoked by uid 605); 7 Jul 2001 07:23:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25500 invoked from network); 7 Jul 2001 07:23:39 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 7 Jul 2001 07:23: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 8F37882F530; Sat, 7 Jul 2001 09:26:40 +0200 (MET DST) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.0/8.8.7) id JAA03434; Sat, 7 Jul 2001 09:26:40 +0200 (MET DST) To: "Joseph Galbraith" Cc: Subject: Re: x.509 signature clarification? References: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.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: 07 Jul 2001 09:26:39 +0200 In-Reply-To: "Joseph Galbraith"'s message of "Thu, 5 Jul 2001 13:09:39 -0600" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit "Joseph Galbraith" writes: > Looking at RFC 2459, it appears that it describes the profile > for x.509 certificates, but doesn't really specify anything about > signature encoding. I think this reference can be dropped. > > For x.509 certificates using rsa keys, SSH Communications 3.0 > appears to be using PKCS #1 with MD5. I'm not sure what they > are doing for DSS signatures. I think it would make sense to use the same signature encoding as for ssh-rsa. > I'm tempted to suggest that the signature is in PKCS #7 > format, though this seems to be a bit of an overkill... Do you think there's something wrong with the encoding used for ssh-rsa and ssh-dss? If not, I think it is a bad idea to add complexity by adding yet another encoding for the same thing. I don't have any plans to support x.509 at all in the foreseeable future, but if I did, I would want a single function for doing x.509: I'd pass a the ssh "key-blob" and a "resource accessed" id (typically username or hostname) to the x.509 code, and get back the public key, or NULL if certificate and local configuration did not imply access rights. From then on, I'd like to be able to treat it as a vanilla rsa/dss key and forget about x.509. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Jul 7 12:08:35 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 MAA19623 for ; Sat, 7 Jul 2001 12:08:34 -0400 (EDT) Received: (qmail 5042 invoked by uid 605); 7 Jul 2001 16:06:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5035 invoked from network); 7 Jul 2001 16:06:10 -0000 Received: from nbgdi5-145-253-151-224.arcor-ip.net (HELO folly.informatik.uni-erlangen.de) (postfix@145.253.151.224) by mail.netbsd.org with SMTP; 7 Jul 2001 16:06:10 -0000 Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 41CCC4505; Sat, 7 Jul 2001 17:41:53 +0200 (CEST) Date: Sat, 7 Jul 2001 17:41:52 +0200 From: Markus Friedl To: ietf-ssh@netbsd.org Cc: Joseph Galbraith Subject: Re: x.509 signature clarification? Message-ID: <20010707174152.A1723@folly> References: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003d01c10586$0a3d2360$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Thu, Jul 05, 2001 at 01:09:39PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jul 05, 2001 at 01:09:39PM -0600, Joseph Galbraith wrote: > For x.509 certificates using rsa keys, SSH Communications 3.0 > appears to be using PKCS #1 with MD5. I'm not sure what they > are doing for DSS signatures. > > There appears to be two areas where the draft needs clarification: > > 1. Which digest algorithm should be used? (Given that we use > SHA1 for ssh-rsa keys, this would seem the natural choice.) yes, i think there is no reason to switch back to MD5, so this is probably an implementation bug. Older software from F-secure uses MD5 for "ssh-rsa", too. > 2. What should the format of the signature be? > > I'm tempted to suggest that the signature is in PKCS #7 > format, though this seems to be a bit of an overkill... i don't see why we cannot use the current "ssh-rsa" encoding: transfer a x509 certificate in addition to "ssh-rsa" encoded signature? since "x509v3-sign-rsa" is not specified in detail, it should be dropped from the draft and replaced by something like "x509v5-ssh-rsa" meaning: public key is transfered in "x509v3" format and the current "ssh-rsa" is used for encoding for signatures. i think all the confusion is due to the fact that a single identifier is used for specifying to encoding of keys, certificates and signatures. i don't see why the current signature formats cannot be used together with x509 certificates. -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jul 20 16:32:35 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 QAA09464 for ; Fri, 20 Jul 2001 16:32:33 -0400 (EDT) Received: (qmail 7053 invoked by uid 605); 20 Jul 2001 20:29:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7046 invoked from network); 20 Jul 2001 20:29:47 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 20 Jul 2001 20:29:47 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25415 for ; Fri, 20 Jul 2001 13:33:18 -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 QAA25587 for ; Fri, 20 Jul 2001 16:33:17 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6KKWhS11705 for ; Fri, 20 Jul 2001 16:32:44 -0400 (EDT) Message-Id: <200107202032.f6KKWhS11705@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: agenda items for secsh meeting at 51st IETF meeting in London Reply-to: sommerfeld@east.sun.com Date: Fri, 20 Jul 2001 16:32:43 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list We will be meeting in the tuesday morning session: 0900-1130 Morning Sessions Palace Suite/Buckingham APP opes Open Pluggable Edge Services WG Cadogan/Berkeley IRTF smug Secure Multicast Group Hilton Rooms 1-6 OPS eos Evolution of SNMP WG * King's Suite/Balmoral 2 * OPS ngtrans Next Generation Transition WG Windsor Suite SEC secsh Secure Shell WG Belgrave/Clarence SUB-IP gsmp General Switch Management Protocol WG Palace Suite/Blenheim TSV ips IP Storage WG King's Suite/Sandringham 1 TSV sip Session Initiation Protocol WG Send proposed agenda items to me. I am promised that we will have drafts to discuss.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jul 23 16:28:43 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 QAA21522 for ; Mon, 23 Jul 2001 16:28:42 -0400 (EDT) Received: (qmail 4755 invoked by uid 605); 23 Jul 2001 20:24:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4669 invoked from network); 23 Jul 2001 20:24:27 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 23 Jul 2001 20:24:27 -0000 Received: from minbar.fac.cs.cmu.edu by minbar.fac.cs.cmu.edu id aa11710; 23 Jul 2001 16:27 EDT Date: Mon, 23 Jul 2001 16:27:37 -0400 (EDT) From: Jeffrey Hutzelman X-Sender: jhutz@minbar.fac.cs.cmu.edu To: ietf-ssh@netbsd.org Subject: Re: GSSAPI authentication In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 21 Jun 2001, Jeffrey Hutzelman wrote: > Joe Galbraith is one of the authors of the user auth draft mentioned > above, and he indicated he might have some time to work on the changes > involved in the merger. I've sent him a brief description of what I had > in mind, as well as information about a couple of protocol changes we > discussed at the WG meeting in Minneapolis (particularly, signing the host > key during key exchange so that sessions don't have to die when the GSSAPI > creds used for the initial key exchange expire). > > My goal is to get another version of this draft out soon enough that we > can take into account comments from implementors and this list, and get > any corrections out before the London IETF meeting. Well, I didn't do quite as well as I would have liked. I submitted the combined user auth and key exchange draft before the 20-Jul-2001 deadline, as a new version of draft-ietf-secsh-gsskeyex. The new version includes the protocol changes I mentioned above, plus a couple of minor but incompatible changes to the key exchange to make things a bit cleaner. Unfortunately, I didn't get a chance to invite comment from the list before publishing the new version. I'm sure this won't be the last version of this draft, so I'll be looking forward to hearing comments both on the list and at the WG meeting in London. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jul 30 18:23:57 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 SAA00077 for ; Mon, 30 Jul 2001 18:23:56 -0400 (EDT) Received: (qmail 13067 invoked by uid 605); 30 Jul 2001 22:20:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13060 invoked from network); 30 Jul 2001 22:20:49 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 30 Jul 2001 22:20:49 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12167 for ; Mon, 30 Jul 2001 16:24:39 -0600 (MDT) 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 SAA06971 for ; Mon, 30 Jul 2001 18:24:39 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6UMO3S23940 for ; Mon, 30 Jul 2001 18:24:03 -0400 (EDT) Message-Id: <200107302224.f6UMO3S23940@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: drafts appear to have been published; please review. Reply-to: sommerfeld@east.sun.com Date: Mon, 30 Jul 2001 18:24:03 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list i haven't yet seen a draft announcement go out, but it looks like the core drafts have been published. My understanding is that the transport-layer draft missed the publication deadline by a couple minutes, but the other three made it. I'm going to look into putting the document which should have been published up on another site for now since they four should be a matched set. I'm not going to start a formal last-call just yet, but expect one shortly after this IETF meeting. Folks should review the three revised drafts: draft-ietf-secsh-architecture-09.txt draft-ietf-secsh-connect-11.txt draft-ietf-secsh-userauth-11.txt as if I had issued a last call on them. Please send any issues with the documents to the working group list; hopefully we can reach closure on these (finally?) and move on... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jul 30 19:36:54 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 TAA02846 for ; Mon, 30 Jul 2001 19:36:44 -0400 (EDT) Received: (qmail 27626 invoked by uid 605); 30 Jul 2001 23:33:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27595 invoked from network); 30 Jul 2001 23:32:50 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 30 Jul 2001 23:32:50 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24783 for ; Mon, 30 Jul 2001 17:36:40 -0600 (MDT) 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 QAA10161 for ; Mon, 30 Jul 2001 16:38:37 -0700 (PDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.81.60]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with SMTP id f6UNaeS295110; Mon, 30 Jul 2001 16:36:40 -0700 (PDT) Message-Id: <200107302336.f6UNaeS295110@jurassic.eng.sun.com> Date: Mon, 30 Jul 2001 16:35:26 -0700 (PDT) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: drafts appear to have been published; please review. To: ietf-ssh@netbsd.org, sommerfeld@east.sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Grist_of_Bees_958_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_41 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list --Grist_of_Bees_958_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: us+IWxEXbxGImqhCyXT9ug== >i haven't yet seen a draft announcement go out, but it looks like the >core drafts have been published. > >My understanding is that the transport-layer draft missed the >publication deadline by a couple minutes, but the other three made it. > >I'm going to look into putting the document which should have been >published up on another site for now since they four should be a >matched set. Since it isn't too large I've attached it below for now. -- Darren J Moffat --Grist_of_Bees_958_000 Content-Type: TEXT/plain; name="draft-ietf-secsh-transport-11.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-ietf-secsh-transport-11.txt Content-MD5: hcpOFJz4JRzSwHdo1+IUsA== Network Working Group T. Ylonen Internet-Draft T. Kivinen Expires: January 18, 2002 SSH Communications Security Corp M. Saarinen University of Jyvaskyla T. Rinne S. Lehtinen SSH Communications Security Corp July 20, 2001 SSH Transport Layer Protocol draft-ietf-secsh-transport-11.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a Ylonen, et. al. Expires January 18, 2002 [Page 1] Internet-Draft SSH Transport Layer Protocol July 2001 basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Connection Setup . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Use over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Protocol Version Exchange . . . . . . . . . . . . . . . . . . 4 3.3 Compatibility With Old SSH Versions . . . . . . . . . . . . . 5 3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . . 5 3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . . 6 4. Binary Packet Protocol . . . . . . . . . . . . . . . . . . . . 6 4.1 Maximum Packet Length . . . . . . . . . . . . . . . . . . . . 7 4.2 Compression . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 11 4.6 Public Key Algorithms . . . . . . . . . . . . . . . . . . . . 11 5. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Algorithm Negotiation . . . . . . . . . . . . . . . . . . . . 14 5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 17 5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 18 6. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 18 6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 20 7. Key Re-Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 8. Service Request . . . . . . . . . . . . . . . . . . . . . . . 21 9. Additional Messages . . . . . . . . . . . . . . . . . . . . . 22 9.1 Disconnection Message . . . . . . . . . . . . . . . . . . . . 22 9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 23 9.3 Debug Message . . . . . . . . . . . . . . . . . . . . . . . . 23 9.4 Reserved Messages . . . . . . . . . . . . . . . . . . . . . . 24 10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 25 13. Additional Information . . . . . . . . . . . . . . . . . . . . 25 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 Ylonen, et. al. Expires January 18, 2002 [Page 2] Internet-Draft SSH Transport Layer Protocol July 2001 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 28 Ylonen, et. al. Expires January 18, 2002 [Page 3] Internet-Draft SSH Transport Layer Protocol July 2001 1. Introduction The SSH transport layer is a secure low level transport protocol. It provides strong encryption, cryptographic host authentication, and integrity protection. Authentication in this protocol level is host-based; this protocol does not perform user authentication. A higher level protocol for user authentication can be designed on top of this protocol. The protocol has been designed to be simple, flexible, to allow parameter negotiation, and to minimize the number of round-trips. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. It is expected that in most environments, only 2 round-trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The worst case is 3 round-trips. 2. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119] The used data types and terminology are specified in the architecture document [SSH-ARCH] The architecture document also discusses the algorithm naming conventions that MUST be used with the SSH protocols. 3. Connection Setup SSH works over any 8-bit clean, binary-transparent transport. The underlying transport SHOULD protect against transmission errors as such errors cause the SSH connection to terminate. The client initiates the connection. 3.1 Use over TCP/IP When used over TCP/IP, the server normally listens for connections on port 22. This port number has been registered with the IANA, and has been officially assigned for SSH. 3.2 Protocol Version Exchange When the connection has been established, both sides MUST send an Ylonen, et. al. Expires January 18, 2002 [Page 4] Internet-Draft SSH Transport Layer Protocol July 2001 identification string of the form "SSH-protoversion- softwareversion comments", followed by carriage return and newline characters (ASCII 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. The part of the identification string preceding carriage return and newline is used in the Diffie-Hellman key exchange (see Section Section 6). The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; if they are displayed, control character filtering discussed in [SSH-ARCH] SHOULD be used. The primary use of this feature is to allow TCP- wrappers to display an error message before disconnecting. Version strings MUST consist of printable US-ASCII characters, not including whitespaces or a minus sign (-). The version string is primarily used to trigger compatibility extensions and to indicate the capabilities of an implementation. The comment string should contain additional information that might be useful in solving user problems. The protocol version described in this document is 2.0. Key exchange will begin immediately after sending this identifier. All packets following the identification string SHALL use the binary packet protocol, to be described below. 3.3 Compatibility With Old SSH Versions During the transition period, it is important to be able to work in a way that is compatible with the installed SSH clients and servers that use an older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with SSH versions 1.x. 3.4 Old Client, New Server Server implementations MAY support a configurable "compatibility" flag that enables compatibility with old versions. When this flag is on, the server SHOULD identify its protocol version as "1.99". Ylonen, et. al. Expires January 18, 2002 [Page 5] Internet-Draft SSH Transport Layer Protocol July 2001 Clients using protocol 2.0 MUST be able to identify this as identical to "2.0". In this mode the server SHOULD NOT send the carriage return character (ASCII 13) after the version identification string. In the compatibility mode the server SHOULD NOT send any further data after its initialization string until it has received an identification string from the client. The server can then determine whether the client is using an old protocol, and can revert to the old protocol if required. In the compatibility mode, the server MUST NOT send additional data before the version string. When compatibility with old clients is not needed, the server MAY send its initial key exchange data immediately after the identification string. 3.5 New Client, Old Server Since the new client MAY immediately send additional data after its identification string (before receiving server's identification), the old protocol may already have been corrupted when the client learns that the server is old. When this happens, the client SHOULD close the connection to the server, and reconnect using the old protocol. 4. Binary Packet Protocol Each packet is in the following format: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length packet_length The length of the packet (bytes), not including MAC or the packet_length field itself. padding_length Length of padding (bytes). payload The useful contents of the packet. If compression has been negotiated, this field is compressed. Initially, compression MUST be "none". Padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. Ylonen, et. al. Expires January 18, 2002 [Page 6] Internet-Draft SSH Transport Layer Protocol July 2001 MAC Message authentication code. If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm MUST be "none". Note that length of the concatenation of packet length, padding length, payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field is also encrypted, and processing it requires special care when sending or receiving packets. The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus MAC); implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet. 4.1 Maximum Packet Length All implementations MUST be able to process packets with uncompressed payload length of 32768 bytes or less and total packet size of 35000 bytes or less (including length, padding length, payload, padding, and MAC.). The maximum of 35000 bytes is an arbitrary chosen value larger than uncompressed size. Implementations SHOULD support longer packets, where they might be needed, e.g. if an implementation wants to send a very large number of certificates. Such packets MAY be sent if the version string indicates that the other party is able to process them. However, implementations SHOULD check that the packet length is reasonable for the implementation to avoid denial-of-service and/or buffer overflow attacks. 4.2 Compression If compression has been negotiated, the payload field (and only it) will be compressed using the negotiated algorithm. The length field and MAC will be computed from the compressed payload. Encryption will be done after compression. Compression MAY be stateful, depending on the method. Compression MUST be independent for each direction, and implementations MUST allow independently choosing the algorithm for each direction. The following compression methods are currently defined: none REQUIRED no compression zlib OPTIONAL ZLIB (LZ77) compression The "zlib" compression is described in [RFC1950] and in [RFC1951]. Ylonen, et. al. Expires January 18, 2002 [Page 7] Internet-Draft SSH Transport Layer Protocol July 2001 The compression context is initialized after each key exchange, and is passed from one packet to the next with only a partial flush being performed at the end of each packet. A partial flush means that all data will be output, but the next packet will continue using compression tables from the end of the previous packet. Additional methods may be defined as specified in . 4.3 Encryption An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload and padding fields of each packet MUST be encrypted with the given algorithm. The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. All ciphers SHOULD use keys with an effective key length of 128 bits or more. The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). The following ciphers are currently defined: 3des-cbc REQUIRED three-key 3DES in CBC mode blowfish-cbc RECOMMENDED Blowfish in CBC mode twofish256-cbc OPTIONAL Twofish in CBC mode, with 256-bit key twofish-cbc OPTIONAL alias for "twofish256-cbc" (this is being retained for historical reasons) twofish192-cbc OPTIONAL Twofish with 192-bit key twofish128-cbc RECOMMENDED Twofish with 128-bit key aes256-cbc OPTIONAL AES (Rijndael) in CBC mode, with 256-bit key aes192-cbc OPTIONAL AES with 192-bit key aes128-cbc RECOMMENDED AES with 128-bit key serpent256-cbc OPTIONAL Serpent in CBC mode, with 256-bit key serpent192-cbc OPTIONAL Serpent with 192-bit key serpent128-cbc OPTIONAL Serpent with 128-bit key arcfour OPTIONAL the ARCFOUR stream cipher idea-cbc OPTIONAL IDEA in CBC mode Ylonen, et. al. Expires January 18, 2002 [Page 8] Internet-Draft SSH Transport Layer Protocol July 2001 cast128-cbc OPTIONAL CAST-128 in CBC mode none OPTIONAL no encryption; NOT RECOMMENDED The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [SCHNEIER] The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys [SCHNEIER]. This is a block cipher with 8 byte blocks. The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described [TWOFISH]. This is a block cipher with 16 byte blocks. The "twofish192-cbc" cipher. Same as above but with 192-bit key. The "twofish128-cbc" cipher. Same as above but with 128-bit key. The "aes256-cbc" cipher is AES (Advanced Encryption Standard), formerly Rijndael, in CBC mode. This version uses 256-bit key. The "aes192-cbc" cipher. Same as above but with 192-bit key. The "aes128-cbc" cipher. Same as above but with 128-bit key. The "serpent256-cbc" cipher in CBC mode, with 256-bit key as described in the Serpent AES submission. The "serpent192-cbc" cipher. Same as above but with 192-bit key. The "serpent128-cbc" cipher. Same as above but with 128-bit key. The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [SCHNEIER]. RC4 is a registered trademark of RSA Data Security Inc. Arcfour (and RC4) has problems with weak keys, and should be used with caution. The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. IDEA is patented by Ascom AG. The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC2144]. Ylonen, et. al. Expires January 18, 2002 [Page 9] Internet-Draft SSH Transport Layer Protocol July 2001 The "none" algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is not recommended. Some functionality (e.g. password authentication) may be disabled for security reasons if this cipher is chosen. Additional methods may be defined as specified in . 4.4 Data Integrity Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet. The message authentication algorithm and key are negotiated during key exchange. Initially, no MAC will be in effect, and its length MUST be zero. After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence number itself is not included in the packet sent over the wire. The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for both directions. The MAC bytes resulting from the MAC algorithm MUST be transmitted without encryption as the last part of the packet. The number of MAC bytes depends on the algorithm chosen. Ylonen, et. al. Expires January 18, 2002 [Page 10] Internet-Draft SSH Transport Layer Protocol July 2001 The following MAC algorithms are currently defined: hmac-sha1 REQUIRED HMAC-SHA1 (digest length = key length = 20) hmac-sha1-96 RECOMMENDED first 96 bits of HMAC-SHA1 (digest length = 12, key length = 20) hmac-md5 OPTIONAL HMAC-MD5 (digest length = key length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (digest length = 12, key length = 16) none OPTIONAL no MAC; NOT RECOMMENDED The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use only the first n bits of the resulting value. The hash algorithms are described in [SCHNEIER]. Additional methods may be defined as specified in . 4.5 Key Exchange Methods The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. Only one REQUIRED key exchange method has been defined: diffie-hellman-group1-sha1 REQUIRED This method is described later in this document. Additional methods may be defined as specified in . 4.6 Public Key Algorithms This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). There are several aspects that define a public key type: o Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. o Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. Ylonen, et. al. Expires January 18, 2002 [Page 11] Internet-Draft SSH Transport Layer Protocol July 2001 o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats. The following public key and/or certificate formats are currently defined: ssh-dss REQUIRED sign Simple DSS ssh-rsa RECOMMENDED sign Simple RSA x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) spki-sign-rsa OPTIONAL sign SPKI certificates (RSA key) spki-sign-dss OPTIONAL sign SPKI certificates (DSS key) pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) Additional key types may be defined as specified in . The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q mpint g mpint y Here the p, q, g, and y parameters form the signature key blob. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [SCHNEIER]. The resulting signature is encoded as follows: string "ssh-dss" string dss_signature_blob Ylonen, et. al. Expires January 18, 2002 [Page 12] Internet-Draft SSH Transport Layer Protocol July 2001 dss_signature_blob is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n Here the e and n parameters form the signature key blob. Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). The "x509v3-sign-rsa" method indicates that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER-encoded format. The formats used in X.509v3 is described in [RFC2459]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "x509v3-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. The "spki-sign-rsa" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [RFC2693]. This method indicates that the key (or one of the keys in the certificate) is an RSA- key. The "spki-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. The "pgp-sign-rsa" method indicates the certificates, the public key, and the signature are in OpenPGP compatible binary format ([RFC2440]). This method indicates that the key is an RSA-key. The "pgp-sign-dss". As above, but indicates that the key is a DSS-key. Ylonen, et. al. Expires January 18, 2002 [Page 13] Internet-Draft SSH Transport Layer Protocol July 2001 5. Key Exchange Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. Guess is considered wrong, if: o the kex algorithm and/or the host key algorithm is guessed wrong (server and client have different preferred algorithm), or o if any of the other algorithms cannot be agreed upon (the procedure is defined below in Section Section 5.1). Otherwise, the guess is considered to be right and the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 5.1 Algorithm Negotiation Key exchange begins by each side sending the following packet: byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client Ylonen, et. al. Expires January 18, 2002 [Page 14] Internet-Draft SSH Transport Layer Protocol July 2001 boolean first_kex_packet_follows uint32 0 (reserved for future extension) Each of the algorithm strings MUST be a comma-separated list of algorithm names (see ''Algorithm Naming'' in ). Each supported (allowed) algorithm MUST be listed in order of preference. The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. cookie The cookie MUST be a random value generated by the sender. Its purpose is to make it impossible for either side to fully determine the keys and the session identifier. kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST be used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: + the server also supports the algorithm, + if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and + if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. + If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. server_host_key_algorithms List of the algorithms supported for the server host key. The server lists the algorithms for which it has host keys; the client lists the algorithms that it is willing to accept. (There MAY be multiple host keys for a host, possibly with different algorithms.) Some host keys may not support both signatures and encryption (this can be determined from the algorithm), and thus not all host keys are valid for all key exchange methods. Algorithm selection depends on whether the chosen key Ylonen, et. al. Expires January 18, 2002 [Page 15] Internet-Draft SSH Transport Layer Protocol July 2001 exchange algorithm requires a signature or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. encryption_algorithms Lists the acceptable symmetric encryption algorithms in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section Section 4.3. mac_algorithms Lists the acceptable MAC algorithms in order of preference. The chosen MAC algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The MAC algorithm names are listed in Section Figure 1. compression_algorithms Lists the acceptable compression algorithms in order of preference. The chosen compression algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The compression algorithm names are listed in Section Section 4.2. languages This is a comma-separated list of language tags in order of preference [RFC1766]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. first_kex_packet_follows Indicates whether a guessed key exchange packet follows. If a guessed packet will be sent, this MUST be TRUE. If no guessed packet will be sent, this MUST be FALSE. After receiving the SSH_MSG_KEXINIT packet from the other side, each party will know whether their guess was right. Ylonen, et. al. Expires January 18, 2002 [Page 16] Internet-Draft SSH Transport Layer Protocol July 2001 If the other party's guess was wrong, and this field was TRUE, the next packet MUST be silently ignored, and both sides MUST then act as determined by the negotiated key exchange method. If the guess was right, key exchange MUST continue using the guessed packet. After the KEXINIT packet exchange, the key exchange algorithm is run. It may involve several packet exchanges, as specified by the key exchange method. 5.2 Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the , which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re-exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. Encryption keys MUST be computed as HASH of a known value and K as follows: o Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ASCII 65). o Initial IV server to client: HASH(K || H || "B" || session_id) o Encryption key client to server: HASH(K || H || "C" || session_id) o Encryption key server to client: HASH(K || H || "D" || session_id) o Integrity key client to server: HASH(K || H || "E" || session_id) o Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) SHOULD be used for algorithms with variable-length keys. For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. If the key length in longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is Ylonen, et. al. Expires January 18, 2002 [Page 17] Internet-Draft SSH Transport Layer Protocol July 2001 available; the key is taken from the beginning of this value. In other words: K1 = HASH(K || H || X || session_id) (X is e.g. "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... This process will lose entropy if the amount of entropy in K is larger than the internal state size of HASH. 5.3 Taking Keys Into Use Key exchange ends by each side sending an SSH_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. When this message is received, the new keys and algorithms MUST be taken into use for receiving. This message is the only valid message after key exchange, in addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE messages. The purpose of this message is to ensure that a party is able to respond with a disconnect message that the other party can understand if something goes wrong with the key exchange. Implementations MUST NOT accept any other messages after key exchange before receiving SSH_MSG_NEWKEYS. byte SSH_MSG_NEWKEYS 6. Diffie-Hellman Key Exchange The Diffie-Hellman key exchange provides a shared secret that can not be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. In the following description (C is the client, S is the server; p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S S's KEXINIT message which have been exchanged before this part begins): Ylonen, et. al. Expires January 18, 2002 [Page 18] Internet-Draft SSH Transport Layer Protocol July 2001 1. C generates a random number x (1 < x < q) and computes e = g^x mod p. C sends "e" to S. 2. S generates a random number y (0 < y < q) and computes f = g^y mod p. S receives "e". It computes K = e^y mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these elements are encoded according to their types; see below), and signature s on H with its private host key. S sends "K_S || f || s" to C. The signing operation may involve a second hashing operation. 3. C verifies that K_S really is the host key for S (e.g. using certificates or a local database). C is also allowed to accept the key without verification; however, doing so will render the protocol insecure against active attacks (but may be desirable for practical reasons in the short term in many environments). C then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K), and verifies the signature s on H. Either side MUST NOT send or accept e or f values that are not in the range [1, p-1]. If this condition is violated, the key exchange fails. This is implemented with the following messages. The hash algorithm for computing the exchange hash is defined by the method name, and is called HASH. The public key algorithm for signing is negotiated with the KEXINIT messages. First, the client sends the following: byte SSH_MSG_KEXDH_INIT mpint e The server responds with the following: byte SSH_MSG_KEXDH_REPLY string server public host key and certificates (K_S) mpint f string signature of H The hash H is computed as the HASH hash of the concatenation of the following: string V_C, the client's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT Ylonen, et. al. Expires January 18, 2002 [Page 19] Internet-Draft SSH Transport Layer Protocol July 2001 string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret This value is called the exchange hash, and it is used to authenticate the key exchange. The exchange hash SHOULD be kept secret. The signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, "ssh-dss" specifies SHA-1 hashing; in that case, the data is first hashed with HASH to compute H, and H is then hashed with SHA-1 as part of the signing operation. 6.1 diffie-hellman-group1-sha1 The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key exchange with SHA-1 as HASH, and the following group: The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi + 129093 ). Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF. In decimal, this value is: 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194 467627007. The generator used with this prime is g = 2. The group order q is (p - 1) / 2. This group was taken from the ISAKMP/Oakley specification, and was originally generated by Richard Schroeppel at the University of Arizona. Properties of this prime are described in [Orm96]. Ylonen, et. al. Expires January 18, 2002 [Page 20] Internet-Draft SSH Transport Layer Protocol July 2001 7. Key Re-Exchange Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when not already doing a key exchange (as described in Section Section 5.1). 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. Either party MAY initiate the re-exchange, but roles MUST NOT be changed (i.e., the server remains the server, and the client remains the client). Key re-exchange is performed using whatever encryption was in effect when the exchange was started. Encryption, compression, and MAC methods are not changed before a new SSH_MSG_NEWKEYS is sent after the key exchange (as in the initial key exchange). Re- exchange is processed identically to the initial key exchange, except for the session identifier that will remain unchanged. It is permissible to change some or all of the algorithms during the re-exchange. Host keys can also change. All keys and initialization vectors are recomputed after the exchange. Compression and encryption contexts are reset. It is recommended that the keys are changed after each gigabyte of transmitted data or after each hour of connection time, whichever comes sooner. However, since the re-exchange is a public key operation, it requires a fair amount of processing power and should not be performed too often. 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 SSH transport layer. 8. Service Request After the key exchange, the client requests a service. The service is identified by a name. The format of names and procedures for defining new names are defined in . Currently, the following names have been reserved: ssh-userauth ssh-connection Similar local naming policy is applied to the service names, as is applied to the algorithm names; a local service should use the "servicename@domain" syntax. byte SSH_MSG_SERVICE_REQUEST string service name Ylonen, et. al. Expires January 18, 2002 [Page 21] Internet-Draft SSH Transport Layer Protocol July 2001 If the server rejects the service request, it SHOULD send an appropriate SSH_MSG_DISCONNECT message and MUST disconnect. When the service starts, it may have access to the session identifier generated during the key exchange. If the server supports the service (and permits the client to use it), it MUST respond with the following: byte SSH_MSG_SERVICE_ACCEPT string service name Message numbers used by services should be in the area reserved for them (see Section Section 10). The transport level will continue to process its own messages. Note that after a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 9. Additional Messages Either party may send any of the following messages at any time. 9.1 Disconnection Message byte SSH_MSG_DISCONNECT uint32 reason code string description [RFC2279] string language tag [RFC1766] This message causes immediate termination of the connection. All implementations MUST be able to process this message; they SHOULD be able to send this message. The sender MUST NOT send or receive any data after this message, and the recipient MUST NOT accept any data after receiving this message. The description field gives a more specific explanation in a human-readable form. The error code gives the reason in a more machine-readable format (suitable for localization), and can have the following values: #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 #define SSH_DISCONNECT_PROTOCOL_ERROR 2 #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED 3 #define SSH_DISCONNECT_RESERVED 4 #define SSH_DISCONNECT_MAC_ERROR 5 #define SSH_DISCONNECT_COMPRESSION_ERROR 6 Ylonen, et. al. Expires January 18, 2002 [Page 22] Internet-Draft SSH Transport Layer Protocol July 2001 #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE 7 #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 #define SSH_DISCONNECT_CONNECTION_LOST 10 #define SSH_DISCONNECT_BY_APPLICATION 11 #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS 12 #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER 13 #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 #define SSH_DISCONNECT_ILLEGAL_USER_NAME 15 If the description string is displayed, control character filtering discussed in should be used to avoid attacks by sending terminal control characters. 9.2 Ignored Data Message byte SSH_MSG_IGNORE string data All implementations MUST understand (and ignore) this message at any time (after receiving the protocol version). No implementation is required to send them. This message can be used as an additional protection measure against advanced traffic analysis techniques. 9.3 Debug Message byte SSH_MSG_DEBUG boolean always_display string message [RFC2279] string language tag [RFC1766] All implementations MUST understand this message, but they are allowed to ignore it. This message is used to pass the other side information that may help debugging. If always_display is TRUE, the message SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless debugging information has been explicitly requested by the user. The message doesn't need to contain a newline. It is, however, allowed to consist of multiple lines separated by CRLF (Carriage Return - Line Feed) pairs. If the message string is displayed, terminal control character filtering discussed in should be used to avoid attacks by sending terminal control characters. Ylonen, et. al. Expires January 18, 2002 [Page 23] Internet-Draft SSH Transport Layer Protocol July 2001 9.4 Reserved Messages An implementation MUST respond to all unrecognized messages with an SSH_MSG_UNIMPLEMENTED message in the order in which the messages were received. Such messages MUST be otherwise ignored. Later protocol versions may define other meanings for these message types. byte SSH_MSG_UNIMPLEMENTED uint32 packet sequence number of rejected message 10. Summary of Message Numbers The following message numbers have been defined in this protocol: #define SSH_MSG_DISCONNECT 1 #define SSH_MSG_IGNORE 2 #define SSH_MSG_UNIMPLEMENTED 3 #define SSH_MSG_DEBUG 4 #define SSH_MSG_SERVICE_REQUEST 5 #define SSH_MSG_SERVICE_ACCEPT 6 #define SSH_MSG_KEXINIT 20 #define SSH_MSG_NEWKEYS 21 /* Numbers 30-49 used for kex packets. Different kex methods may reuse message numbers in this range. */ #define SSH_MSG_KEXDH_INIT 30 #define SSH_MSG_KEXDH_REPLY 31 11. Security Considerations This protocol provides a secure encrypted channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. It is expected that this protocol will sometimes be used without insisting on reliable association between the server host key and the server host name. Such use is inherently insecure, but may be necessary in non-security critical environments, and still provides protection against passive attacks. However, implementors of protocols running on top of this protocol should keep this possibility in mind. Ylonen, et. al. Expires January 18, 2002 [Page 24] Internet-Draft SSH Transport Layer Protocol July 2001 This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. 12. Trademark Issues As of this writing, SSH Communications Security Oy claims ssh as its trademark. As with all IPR claims the IETF takes no position regarding the validity or scope of this trademark claim. 13. Additional Information The current document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh- charter.html References [FIPS-186] Federal Information Processing Standards Publication, ., "FIPS PUB 186, Digital Signature Standard", May 1994. [Orm96] Orman, H., "The Okaley Key Determination Protcol version1, TR97-92", 1996. [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, Nov 1987. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. Ylonen, et. al. Expires January 18, 2002 [Page 25] Internet-Draft SSH Transport Layer Protocol July 2001 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997. [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", 1996. [TWOFISH] Schneier, B., "The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition", March 1999. [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf-architecture-09.txt, July 2001. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-11.txt, July 2001. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-11.txt, July 2001. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft- ietf-connect-11.txt, July 2001. Ylonen, et. al. Expires January 18, 2002 [Page 26] Internet-Draft SSH Transport Layer Protocol July 2001 Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: kivinen@ssh.com Markku-Juhani O. Saarinen University of Jyvaskyla Timo J. Rinne SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: tri@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen, et. al. Expires January 18, 2002 [Page 27] Internet-Draft SSH Transport Layer Protocol July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen, et. al. Expires January 18, 2002 [Page 28] --Grist_of_Bees_958_000-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 31 16:39:28 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 QAA19846 for ; Tue, 31 Jul 2001 16:39:28 -0400 (EDT) Received: (qmail 8002 invoked by uid 605); 31 Jul 2001 20:34:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7995 invoked from network); 31 Jul 2001 20:34:57 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 31 Jul 2001 20:34:57 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26504; Tue, 31 Jul 2001 13:38:44 -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 QAA10348; Tue, 31 Jul 2001 16:38:41 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f6VKc5J07115; Tue, 31 Jul 2001 16:38:05 -0400 (EDT) Message-Id: <200107312038.f6VKc5J07115@thunk.east.sun.com> From: Bill Sommerfeld To: agenda@ietf.org Cc: ietf-ssh@netbsd.org Subject: Secure Shell agenda for IETF51 Reply-to: sommerfeld@east.sun.com Date: Tue, 31 Jul 2001 16:38:05 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Secure Shell Working Group (secsh) Tuesday, August 7 at 0930-1200 ================================ CHAIR: Bill Sommerfeld AGENDA: initialization vector/agenda bashing 5 minutes status of working group 10 minutes core secsh protocol - changes in latest drafts 5 minutes - open issues with core drafts 45 minutes SSH Protocol Architecture draft-ietf-secsh-architecture-09.txt SSH Connection Protocol draft-ietf-secsh-connect-11.txt SSH Authentication Protocol draft-ietf-secsh-userauth-11.txt SSH Transport Layer Protocol From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 31 20:06:15 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 UAA06873 for ; Tue, 31 Jul 2001 20:06:14 -0400 (EDT) Received: (qmail 27814 invoked by uid 605); 1 Aug 2001 00:03:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27807 invoked from network); 1 Aug 2001 00:03:12 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Aug 2001 00:03:12 -0000 Received: from [192.168.0.38] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.4) with SMTP id 134368; Tue, 31 Jul 2001 18:05:59 -0600 Message-ID: <017601c11a1d$d5578120$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: , References: <200107302224.f6UMO3S23940@thunk.east.sun.com> Subject: Re: drafts appear to have been published; please review. Date: Tue, 31 Jul 2001 18:06:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hmm... the drafts appear to have changed in a way that totally confuses my diff tool... is anyone else having a bad time with this or is my diff tool just complete drain bamaged? Can someone summarize changes for me and give me a hint as to where to look. - Joseph ----- Original Message ----- From: "Bill Sommerfeld" To: Sent: Monday, July 30, 2001 4:24 PM Subject: drafts appear to have been published; please review. > i haven't yet seen a draft announcement go out, but it looks like the > core drafts have been published. > > My understanding is that the transport-layer draft missed the > publication deadline by a couple minutes, but the other three made it. > > I'm going to look into putting the document which should have been > published up on another site for now since they four should be a > matched set. > > I'm not going to start a formal last-call just yet, but expect one > shortly after this IETF meeting. > > Folks should review the three revised drafts: > > draft-ietf-secsh-architecture-09.txt > draft-ietf-secsh-connect-11.txt > draft-ietf-secsh-userauth-11.txt > > as if I had issued a last call on them. > > Please send any issues with the documents to the working group list; > hopefully we can reach closure on these (finally?) and move on... > > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 31 22:24:16 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 WAA16412 for ; Tue, 31 Jul 2001 22:24:14 -0400 (EDT) Received: (qmail 11693 invoked by uid 605); 1 Aug 2001 02:21:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11686 invoked from network); 1 Aug 2001 02:21:14 -0000 Received: from noc.untraceable.net (166.84.189.65) by mail.netbsd.org with SMTP; 1 Aug 2001 02:21:14 -0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.12.0.Beta16/8.12.0.Beta16/bonk!) with ESMTP id f712P64N027837; Tue, 31 Jul 2001 22:25:07 -0400 (EDT) Received: (from andrew@localhost) by noc.untraceable.net (8.12.0.Beta16/8.12.0.Beta16) id f712P6tl027836; Tue, 31 Jul 2001 22:25:06 -0400 (EDT) Date: Tue, 31 Jul 2001 22:25:06 -0400 From: Andrew Brown To: Joseph Galbraith Cc: sommerfeld@east.sun.com, ietf-ssh@netbsd.org Subject: Re: drafts appear to have been published; please review. Message-ID: <20010731222506.A27676@noc.untraceable.net> Reply-To: Andrew Brown References: <200107302224.f6UMO3S23940@thunk.east.sun.com> <017601c11a1d$d5578120$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <017601c11a1d$d5578120$2800a8c0@test.vandyke.com>; from galb-list@vandyke.com on Tue, Jul 31, 2001 at 06:06:37PM -0600 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: ietf-ssh-owner@netbsd.org Precedence: list >Hmm... the drafts appear to have changed in a way >that totally confuses my diff tool... is anyone >else having a bad time with this or is my diff >tool just complete drain bamaged? it looks to me like they were regenerated with the left margin moved in about six spaces. this makes almost all the lines different even though the content may not have changed (there are spaces at the beginning of them now), and also makes them longer (fewer words per line translates to more lines). diff -w reports smaller sets of changes. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."