From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 9 13:00:36 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18816 for ; Fri, 9 Jan 2004 13:00:31 -0500 (EST) Received: (qmail 19569 invoked by uid 605); 9 Jan 2004 18:00:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19562 invoked from network); 9 Jan 2004 18:00:19 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 9 Jan 2004 18:00:19 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09I0I0H023057 for ; Fri, 9 Jan 2004 10:00:18 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i09I0IjM028645 for ; Fri, 9 Jan 2004 13:00:18 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i09I0He7006391 for ; Fri, 9 Jan 2004 13:00:17 -0500 (EST) Message-Id: <200401091800.i09I0He7006391@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: IETF in Seoul. Reply-to: sommerfeld@east.sun.com Date: Fri, 09 Jan 2004 13:00:17 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The next IETF meeting will be in Seoul, South Korea. History over the past couple years has shown this working group tends to have fairly sparse attendance at non-north-american IETF's. I'll be in Seoul, but before I request a meeting slot I'd like to hear from active WG participants to get a sense as to whether we'll have critical mass for any of our work areas.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 9 15:41:18 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13358 for ; Fri, 9 Jan 2004 15:41:17 -0500 (EST) Received: (qmail 5817 invoked by uid 605); 9 Jan 2004 20:41:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5809 invoked from network); 9 Jan 2004 20:41:13 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 9 Jan 2004 20:41:13 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 76BF2CC8B4; Fri, 9 Jan 2004 21:41:11 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 84742CC8A8; Fri, 9 Jan 2004 21:41:08 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i09Kf8CM000089; Fri, 9 Jan 2004 21:41:08 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i09Kf3VO000085; Fri, 9 Jan 2004 21:41:03 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: ietf-ssh@NetBSD.org Subject: Re: IETF in Seoul. References: <200401091800.i09I0He7006391@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 09 Jan 2004 21:41:01 +0100 In-Reply-To: <200401091800.i09I0He7006391@thunk.east.sun.com> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.61-lysator_fetto_1.1 (1.212.2.1-2003-12-09-exp) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.61-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > History over the past couple years has shown this working group tends > to have fairly sparse attendance at non-north-american IETF's. Hmm, why is the statistics so bad for Europe? There are quite a few ssh developers living over here, as far as I know. (I've only ever been to one ietf meeting, in Oslo a few years ago, but it turned out there was no secsh meeting that time. Oslo is just some five hours by train from home). > I'll be in Seoul, but before I request a meeting slot I'd like to hear > from active WG participants to get a sense as to whether we'll have > critical mass for any of our work areas.. I won't be there. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 9 16:06:45 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15513 for ; Fri, 9 Jan 2004 16:06:44 -0500 (EST) Received: (qmail 20053 invoked by uid 605); 9 Jan 2004 21:06:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20046 invoked from network); 9 Jan 2004 21:06:42 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 9 Jan 2004 21:06:42 -0000 Received: by mail.siliconcircus.com (Postfix, from userid 1022) id 0DB00436D2; Fri, 9 Jan 2004 22:07:25 +0100 (CET) Received: from siliconcircus.com (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 619DF43441; Fri, 9 Jan 2004 22:07:20 +0100 (CET) Message-ID: <3FFF17E3.3020204@siliconcircus.com> Date: Fri, 09 Jan 2004 22:06:43 +0100 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030813 Thunderbird/0.2a X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org Subject: Re: IETF in Seoul. References: <200401091800.i09I0He7006391@thunk.east.sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on drno.siliconcircus.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.61 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Bill Sommerfeld writes: > >> History over the past couple years has shown this working group >> tends to have fairly sparse attendance at non-north-american >> IETF's. > > Hmm, why is the statistics so bad for Europe? There are quite a few > ssh developers living over here, as far as I know. (I've only ever > been to one ietf meeting, in Oslo a few years ago, but it turned out > there was no secsh meeting that time. Oslo is just some five hours by > train from home). Now that I've started taking a slightly more active part in this WG, I'd certainly be happy to go to any IETF within reasonable travelling distance (which for me means within about 1000km of Dortmund, Germany), *but* it's difficult to justify the $500 outlay for the registration fee. Adding intercontinental airfare and hotel costs to that makes it even less possible. A quick estimate shows attending the IETF in Seoul would cost 1533EUR before hotel costs, probably 2000EUR including hotel, probably 2500EUR by the time incidentals are added. For (e.g.) Sun, this is a drop in the ocean - for us, unless there's some benefit of attendance I'm unaware of, the cost/benefit doesn't work out. I'd guess this applies to a lot of people who don't have large corporate employers/sponsors. >> I'll be in Seoul, but before I request a meeting slot I'd like to >> hear from active WG participants to get a sense as to whether we'll >> have critical mass for any of our work areas.. I won't be there :-) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 10 11:03:58 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09399 for ; Sat, 10 Jan 2004 11:03:57 -0500 (EST) Received: (qmail 8660 invoked by uid 605); 10 Jan 2004 16:03:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8653 invoked from network); 10 Jan 2004 16:03:52 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 10 Jan 2004 16:03:52 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa15252; 10 Jan 2004 11:03 EST Date: Sat, 10 Jan 2004 11:03:41 -0500 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: IETF in Seoul. Message-ID: <757630000.1073750621@mariner.pc.cs.cmu.edu> In-Reply-To: <3FFF17E3.3020204@siliconcircus.com> References: <200401091800.i09I0He7006391@thunk.east.sun.com> <3FFF17E3.3020204@siliconcircus.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, January 09, 2004 22:06:43 +0100 Jon Bright wrote: > *but* it's difficult to justify the $500 outlay for the registration I wouldn't expect that to change anytime soon. The fee changes depending on how much the conference venue costs, but that's only a little on the high side. And remember, the IETF is losing money... > I won't be there :-) I will From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 15 11:56:26 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14507 for ; Thu, 15 Jan 2004 11:56:25 -0500 (EST) Received: (qmail 20990 invoked by uid 605); 15 Jan 2004 16:56:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20983 invoked from network); 15 Jan 2004 16:56:20 -0000 Received: from asgard.ietf.org (132.151.6.40) by mail.netbsd.org with SMTP; 15 Jan 2004 16:56:20 -0000 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AhAme-0007SQ-M6; Thu, 15 Jan 2004 11:55:52 -0500 X-test-idtracker: no To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: The IESG Subject: Last Call: 'Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Thu, 15 Jan 2004 11:55:52 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The IESG has received a request from the Secure Shell WG to consider the following document: - 'Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-01-29. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 16 11:18:04 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19907 for ; Fri, 16 Jan 2004 11:18:03 -0500 (EST) Received: (qmail 22241 invoked by uid 605); 16 Jan 2004 16:17:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22234 invoked from network); 16 Jan 2004 16:17:56 -0000 Received: from mail.montreal.hcl.com (HELO fs1.montreal.hcl.com) (198.168.185.55) by mail.netbsd.org with SMTP; 16 Jan 2004 16:17:56 -0000 Received: from mtlglenltp2 (mtlglen-ltp2.montreal.hcl.com [10.4.1.184]) by fs1.montreal.hcl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C66WJC8Y; Fri, 16 Jan 2004 11:17:54 -0500 From: "Glen Matthews" To: Subject: Certificate authentication Date: Fri, 16 Jan 2004 11:16:41 -0500 Organization: Hummingbird Message-ID: <004c01c3dc4c$206e7180$b801040a@mtlglenltp2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, sorry for the dumb question (if it is dumb) but I can't see any drafts dealing with certificate authentication in ssh. ssh.com seems to support this, and I see a patch for openssh by Roumen Petrov - but is there any position from the wg on this? Glen Matthews From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 16 12:32:19 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22334 for ; Fri, 16 Jan 2004 12:32:18 -0500 (EST) Received: (qmail 11193 invoked by uid 605); 16 Jan 2004 17:32:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11186 invoked from network); 16 Jan 2004 17:32:13 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Jan 2004 17:32:13 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0GHWA0H024441; Fri, 16 Jan 2004 09:32:11 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i0GHW97H025618; Fri, 16 Jan 2004 12:32:10 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i0GHW9e7019384; Fri, 16 Jan 2004 12:32:09 -0500 (EST) Message-Id: <200401161732.i0GHW9e7019384@thunk.east.sun.com> From: Bill Sommerfeld To: "Glen Matthews" cc: ietf-ssh@NetBSD.org Subject: Re: Certificate authentication In-Reply-To: Your message of "Fri, 16 Jan 2004 11:16:41 EST." <004c01c3dc4c$206e7180$b801040a@mtlglenltp2> Reply-to: sommerfeld@east.sun.com Date: Fri, 16 Jan 2004 12:32:09 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > sorry for the dumb question (if it is dumb) but I can't see any drafts > dealing with certificate authentication in ssh. ssh.com seems to support > this, and I see a patch for openssh by Roumen Petrov - but is there any > position from the wg on this? the position of the WG chair is that he'd very much like to find someone willing to write a document on the topic. everyone who has stepped forward to do this hasn't delivered yet. "Please send text." - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 16 20:57:55 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09611 for ; Fri, 16 Jan 2004 20:57:54 -0500 (EST) Received: (qmail 14906 invoked by uid 605); 17 Jan 2004 01:57:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14895 invoked from network); 17 Jan 2004 01:57:48 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 17 Jan 2004 01:57:48 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id DF73234061; Sat, 17 Jan 2004 14:57:36 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0H1vi402152; Sat, 17 Jan 2004 14:57:44 +1300 Date: Sat, 17 Jan 2004 14:57:44 +1300 Message-Id: <200401170157.i0H1vi402152@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication Sender: ietf-ssh-owner@NetBSD.org Precedence: list "Glen Matthews" sorry for the dumb question (if it is dumb) but I can't see any drafts >dealing with certificate authentication in ssh. ssh.com seems to support >this, and I see a patch for openssh by Roumen Petrov - but is there any >position from the wg on this? I looked at this a while back and the group consensus is that no two people can agree on how to handle it :-). I went through the list archives collecting all the comments on this, it starts around July'01 with: For x.509 certificates using rsa keys, SSH Communications 3.0 appears to be using PKCS #1 with MD5. That doesn't describe the format, merely what's inside the RSA bignum... and the debate then fizzled out again. There's another post from August '01: I would suggest we include the following text in section documenting "x509v3-sign-rsa": The "x509v3-sign-rsa" key format has the following specific encoding: string "x509v3-sign-rsa" byte[n] x.509v3 compatible der encoded certificate data The resulting signature is encoded as follows: string "x509v3-sign-rsa" string rsa_signature_blob Variants to this go in the other x.509 sections as appropriate. In addition, I would suggest that we note that signatures made with x509v3- sign-rsa keys MUST use the SHA-1 hash, and be done using PKCS1. but then later he says: So, we decided to change x.509v3 certificates to use pkcs7 signatures, because otherwise, there is no way to know what hashing algorithm was used. There are currently two such algorithms defined: x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) The "x509v3-*" key format has the following generic encoding: string "x509v3-*" string x.509v3 compatible der encoded certificate data The resulting signature is encoded as follows: string "pkcs7" string PKCS-7 signature, DER encoded The "x509v3-sign-rsa" 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. which never appeard in the RFC. There's a followup in Jan'02 asking why it's not present yet, and several other ones indicating that no two people can agree on how to do this, including the [editorial comment deleted] suggestion to use: The certificate formats based on ssh-rsa extend the public key format to include certificate data: string "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp" mpint e mpint n string certificate which practically guarantees that one or more implementations will use the e and n from outside the cert (particularly ones only pretending to do X.509), completely voiding the purpose of having the cert in the first place. Even ssh.com don't seem to know what to do: moreover, implementations supporting x509 (e.g. ssh.com) currently send string "DER-encoded cert" without even sending the key type. Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data so, i'm confused by the draft and the implementations. Markus Friedl then comments that: This is obviously wrong, Bill Sommerfeld finally sums it up with: i do not want to hold up the core drafts waiting for folks to figure out how to use x.509 with ssh. and Damien Miller followed up with the observation that: The current spec is too vague to implement. There were further comments more recently which indicated that interest in doing X.509 with SSH was sufficiently low that no-one cared too much about this issue anyway. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 16 21:01:47 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09675 for ; Fri, 16 Jan 2004 21:01:46 -0500 (EST) Received: (qmail 17209 invoked by uid 605); 17 Jan 2004 02:01:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17202 invoked from network); 17 Jan 2004 02:01:41 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 17 Jan 2004 02:01:41 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 63B2334061; Sat, 17 Jan 2004 15:01:31 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0H21fh02178; Sat, 17 Jan 2004 15:01:41 +1300 Date: Sat, 17 Jan 2004 15:01:41 +1300 Message-Id: <200401170201.i0H21fh02178@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Certificate authentication Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >the position of the WG chair is that he'd very much like to find someone >willing to write a document on the topic. everyone who has stepped forward >to do this hasn't delivered yet. > >"Please send text." Two questions: 1. What sort of text do you need here? Just something to define the format for the cert and the signature? That should be simple enough, however... 2. Does anyone really care about this? As my previous post indicated, interest in this seems pretty much nonexistant, is it worth doing a draft that no-one cares about? To use the tree-in-a-forest analogy, if I send in a draft and no-one implements it... Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 17 03:35:20 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01676 for ; Sat, 17 Jan 2004 03:35:20 -0500 (EST) Received: (qmail 13060 invoked by uid 605); 17 Jan 2004 08:35:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13050 invoked from network); 17 Jan 2004 08:35:15 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 17 Jan 2004 08:35:15 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2004 09:35:59 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0H8Yr8r017276 for ; Sat, 17 Jan 2004 09:34:53 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id IAA14499 for ietf-ssh@NetBSD.org; Sat, 17 Jan 2004 08:35:12 GMT Date: Sat, 17 Jan 2004 08:35:12 +0000 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: Certificate authentication Message-ID: <20040117083512.A12113@edinburgh.cisco.com> References: <200401170201.i0H21fh02178@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200401170201.i0H21fh02178@cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Sat, Jan 17, 2004 at 03:01:41PM +1300 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Jan 17, 2004 at 03:01:41PM +1300, Peter Gutmann wrote: > Bill Sommerfeld writes: > > >the position of the WG chair is that he'd very much like to find someone > >willing to write a document on the topic. everyone who has stepped forward > >to do this hasn't delivered yet. > > > >"Please send text." > > Two questions: > > 1. What sort of text do you need here? Just something to define the format > for the cert and the signature? That should be simple enough, however... > > 2. Does anyone really care about this? As my previous post indicated, > interest in this seems pretty much nonexistant, is it worth doing a draft > that no-one cares about? To use the tree-in-a-forest analogy, if I send in > a draft and no-one implements it... Well I'm actually for the simple approach at the moment: rip all text referring to certificates from the current draft. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 17 03:54:21 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01972 for ; Sat, 17 Jan 2004 03:54:20 -0500 (EST) Received: (qmail 22172 invoked by uid 605); 17 Jan 2004 08:54:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22165 invoked from network); 17 Jan 2004 08:54:16 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 17 Jan 2004 08:54:16 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4222534005; Sat, 17 Jan 2004 21:54:01 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0H8sCu03909; Sat, 17 Jan 2004 21:54:12 +1300 Date: Sat, 17 Jan 2004 21:54:12 +1300 Message-Id: <200401170854.i0H8sCu03909@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dfawcus@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication Sender: ietf-ssh-owner@NetBSD.org Precedence: list Derek Fawcus writes: >Well I'm actually for the simple approach at the moment: > rip all text referring to certificates from the current draft. I could live with that. That seems to be the de facto profile for certs at the moment anyway. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 17 04:21:24 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02400 for ; Sat, 17 Jan 2004 04:21:24 -0500 (EST) Received: (qmail 4429 invoked by uid 605); 17 Jan 2004 09:21:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4422 invoked from network); 17 Jan 2004 09:21:23 -0000 Received: from ams-iport-1.cisco.com (144.254.74.5) by mail.netbsd.org with SMTP; 17 Jan 2004 09:21:23 -0000 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2004 10:22:07 +0100 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id i0H9L1gn023720 for ; Sat, 17 Jan 2004 10:21:02 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA15558 for ietf-ssh@NetBSD.org; Sat, 17 Jan 2004 09:21:21 GMT Date: Sat, 17 Jan 2004 09:21:21 +0000 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: Certificate authentication Message-ID: <20040117092121.B12113@edinburgh.cisco.com> References: <200401170854.i0H8sCu03909@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200401170854.i0H8sCu03909@cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Sat, Jan 17, 2004 at 09:54:12PM +1300 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Jan 17, 2004 at 09:54:12PM +1300, Peter Gutmann wrote: > Derek Fawcus writes: > > >Well I'm actually for the simple approach at the moment: > > rip all text referring to certificates from the current draft. > > I could live with that. That seems to be the de facto profile for certs at > the moment anyway. Yeah. Then if we (WG) ever get our act together wrt certificates, we can produce a new draft specific to cert. use... DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 17 05:09:47 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03368 for ; Sat, 17 Jan 2004 05:09:46 -0500 (EST) Received: (qmail 28453 invoked by uid 605); 17 Jan 2004 10:09:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28446 invoked from network); 17 Jan 2004 10:09:40 -0000 Received: from topper.inf.ed.ac.uk (129.215.32.40) by mail.netbsd.org with SMTP; 17 Jan 2004 10:09:40 -0000 Received: from slim.inf.ed.ac.uk (slim.inf.ed.ac.uk [129.215.32.5]) by topper.inf.ed.ac.uk (8.11.6/8.11.6) with ESMTP id i0HA9dL26342 for ; Sat, 17 Jan 2004 10:09:39 GMT Received: from slim.inf.ed.ac.uk (localhost [127.0.0.1]) by slim.inf.ed.ac.uk (8.12.8/8.12.8) with ESMTP id i0HA9dkl028817 for ; Sat, 17 Jan 2004 10:09:39 GMT Received: from localhost (sxw@localhost) by slim.inf.ed.ac.uk (8.12.8/8.12.8/Submit) with ESMTP id i0HA9dMt028812 for ; Sat, 17 Jan 2004 10:09:39 GMT X-Authentication-Warning: slim.inf.ed.ac.uk: sxw owned process doing -bs Date: Sat, 17 Jan 2004 10:09:38 +0000 (GMT) From: sxw@dcs.ed.ac.uk X-X-Sender: sxw@slim.inf.ed.ac.uk To: ietf-ssh@NetBSD.org Subject: Re: Certificate authentication In-Reply-To: <20040117092121.B12113@edinburgh.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, 17 Jan 2004, Derek Fawcus wrote: > Yeah. Then if we (WG) ever get our act together wrt certificates, we can > produce a new draft specific to cert. use... There are lots of people in the Grid community using SSH with certificates using the GSI GSSAPI interface. This route has the advantage that it doesn't need any further specification ... Simon. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 17 18:16:31 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19172 for ; Sat, 17 Jan 2004 18:16:20 -0500 (EST) Received: (qmail 1217 invoked by uid 605); 17 Jan 2004 17:49:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1201 invoked from network); 17 Jan 2004 17:49:26 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 17 Jan 2004 17:49:26 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id A2D02BEE14; Sat, 17 Jan 2004 18:49:24 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id C92188F6F0; Sat, 17 Jan 2004 18:49:21 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i0HHnLCM014178; Sat, 17 Jan 2004 18:49:21 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i0HHnFta014175; Sat, 17 Jan 2004 18:49:15 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication References: <200401170201.i0H21fh02178@cs.auckland.ac.nz> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 17 Jan 2004 18:49:15 +0100 In-Reply-To: <200401170201.i0H21fh02178@cs.auckland.ac.nz> Message-ID: Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.61-lysator_fetto_1.1 (1.212.2.1-2003-12-09-exp) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.61-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > 2. Does anyone really care about this? As my previous post indicated, > interest in this seems pretty much nonexistant, is it worth doing a draft > that no-one cares about? To use the tree-in-a-forest analogy, if I send in > a draft and no-one implements it... Personally, I don't care much about x.509, it seems too complex and broken to ever do any reasonable security with. I'd like to do spki certificates, but at the moment it's not a high priority either. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 18 04:02:01 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13901 for ; Sun, 18 Jan 2004 04:02:00 -0500 (EST) Received: (qmail 28232 invoked by uid 605); 18 Jan 2004 09:01:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28225 invoked from network); 18 Jan 2004 09:01:53 -0000 Received: from smtp.cs.auckland.ac.nz (130.216.33.151) by mail.netbsd.org with SMTP; 18 Jan 2004 09:01:53 -0000 Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CFEC134032; Sun, 18 Jan 2004 22:01:36 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0I91nn14492; Sun, 18 Jan 2004 22:01:49 +1300 Date: Sun, 18 Jan 2004 22:01:49 +1300 Message-Id: <200401180901.i0I91nn14492@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: Certificate authentication Cc: ietf-ssh@NetBSD.org, sommerfeld@east.sun.com Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) writes: >I'd like to do spki certificates, but at the moment it's not a high priority >either. Speaking of SPKI, it's not just X.509 that has the issue with being underspecified, both SPKI and PGP have the same problem. Instead of removing these portions entirely, how about adding a note to say that the identifiers for X.509/SPKI/PGP are reserved for possible future standardisation? That way if in the future someone decides they want to get some mechanism standardised, the identifiers are already defined. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 18 06:47:52 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17718 for ; Sun, 18 Jan 2004 06:47:52 -0500 (EST) Received: (qmail 22555 invoked by uid 605); 18 Jan 2004 11:47:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22548 invoked from network); 18 Jan 2004 11:47:45 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 18 Jan 2004 11:47:45 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 5E8DEAC320; Sun, 18 Jan 2004 12:47:44 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 06E9AAD7BE; Sun, 18 Jan 2004 12:47:41 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id i0IBleCM024976; Sun, 18 Jan 2004 12:47:40 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i0IBlV2f024973; Sun, 18 Jan 2004 12:47:31 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@NetBSD.org, sommerfeld@east.sun.com Subject: Re: Certificate authentication References: <200401180901.i0I91nn14492@cs.auckland.ac.nz> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 18 Jan 2004 12:47:30 +0100 In-Reply-To: <200401180901.i0I91nn14492@cs.auckland.ac.nz> Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.61-lysator_fetto_1.1 (1.212.2.1-2003-12-09-exp) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.61-lysator_fetto_1.1 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Speaking of SPKI, it's not just X.509 that has the issue with being > underspecified, both SPKI and PGP have the same problem. Instead of removing > these portions entirely, how about adding a note to say that the identifiers > for X.509/SPKI/PGP are reserved for possible future standardisation? Makes sense to me. As for spki, the only spki-ish I do yet is in the representation of the "known-hosts" database, where I use acl:s of the form (acl (entry (subject (public-key (rsa-pkcs1-sha1 (n |AMxUKL4vuu8WvsMpkc/ bt6ZcdJ7UJxCwaDVOEg pd0ZMEhWZK2bEUwtH06 TimrUDbNa/wSxaFbdta FRcCF1XrxkMAfi39Gfu cPasFQEDbv2FABRwT06 gc3uMGCv4ElqkDi6I+6 zoWZNMbQEulEqnHyncz HUVoHrmeedD+oEsxB37 9|) (e "#")))) (tag (ssh-hostkey org.gnu.savannah)))) Note the reversed domain name, that is to make it possible to use acls/certificates with (tag (ssh-hostkey (* prefix org.gnu.))) to represent the capability of representing any machine under gnu.org. /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 18 21:07:40 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11883 for ; Sun, 18 Jan 2004 21:07:39 -0500 (EST) Received: (qmail 4172 invoked by uid 605); 19 Jan 2004 02:07:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4160 invoked from network); 19 Jan 2004 02:07:29 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 19 Jan 2004 02:07:29 -0000 Received: from mindrot.org (89.195.20.10.dhcp.netstarnetworks.com [10.20.195.89] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id i0J29NJ20603; Mon, 19 Jan 2004 13:09:28 +1100 Message-ID: <400B3BB3.80602@mindrot.org> Date: Mon, 19 Jan 2004 13:06:43 +1100 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication References: <200401170157.i0H1vi402152@cs.auckland.ac.nz> In-Reply-To: <200401170157.i0H1vi402152@cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > which never appeard in the RFC. There's a followup in Jan'02 asking why it's > not present yet, and several other ones indicating that no two people can > agree on how to do this, including the [editorial comment deleted] suggestion > to use: > > The certificate formats based on ssh-rsa extend the public key > format to include certificate data: > > string "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp" > mpint e > mpint n > string certificate IIRC it was I that suggested this encoding and then promptly retracted it after a good night's sleep. I had hoped that this bit of embassasment would lay undisturbed in the list archives. Anyway: - I think that the certificate hostkeys or userauth should be specified in separate drafts. - I'd prefer that no more changes be made to the current drafts so as not to (yet again) delay them. - If changes absolutely have to be made, then I would prefer the current wording around certificate encoding to be converted to references to external specifications. - I don't think that the current wording should just be deleted, as at least one implementation (ssh.com, and possibly people who are using patched OpenSSH) does use host-key certificates with the specified encoding name. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 19 03:11:13 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05259 for ; Mon, 19 Jan 2004 03:11:12 -0500 (EST) Received: (qmail 14583 invoked by uid 605); 19 Jan 2004 08:11:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14571 invoked from network); 19 Jan 2004 08:11:10 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 19 Jan 2004 08:11:10 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 191341F2A36 for ; Mon, 19 Jan 2004 09:11:08 +0100 (MET) Received: from askja.got.appgate.com (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 8D9546CEC1 for ; Mon, 19 Jan 2004 09:11:10 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by askja.got.appgate.com (Postfix) with ESMTP id AA7FC2F6AD for ; Mon, 19 Jan 2004 09:10:40 +0100 (MET) Received: from askja.got.appgate.com ([127.0.0.1]) by localhost (askja.got.appgate.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15911-02-9 for ; Mon, 19 Jan 2004 09:10:40 +0100 (MET) Received: from localhost (pelee.got.appgate.com [172.23.2.10]) by askja.got.appgate.com (Postfix) with ESMTP id B36432F6B2 for ; Mon, 19 Jan 2004 09:10:39 +0100 (MET) Date: Mon, 19 Jan 2004 08:50:35 +0100 (CET) From: maf@appgate.com Subject: Re: Certificate authentication To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040119081039.B36432F6B2@askja.got.appgate.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 19 Jan, Damien Miller wrote: > IIRC it was I that suggested this encoding and then promptly retracted > it after a good night's sleep. I had hoped that this bit of embassasment > would lay undisturbed in the list archives. Anyway: Isn't the internet wonderful:-) > - I think that the certificate hostkeys or userauth should be specified > in separate drafts. I have no problems with this. > - I'd prefer that no more changes be made to the current drafts so as > not to (yet again) delay them. Agreed. > - I don't think that the current wording should just be deleted, as at > least one implementation (ssh.com, and possibly people who are using > patched OpenSSH) does use host-key certificates with the specified > encoding name. We have implemented certificate support both for authentication and hostkeys in the AppGate software. But since the drafts were unclear we have used private names (i.e. @appgate.com) for them. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 21 16:29:27 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09772 for ; Wed, 21 Jan 2004 16:29:27 -0500 (EST) Received: (qmail 26193 invoked by uid 605); 21 Jan 2004 21:29:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26186 invoked from network); 21 Jan 2004 21:29:21 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 21 Jan 2004 21:29:21 -0000 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0LLTL0H028672 for ; Wed, 21 Jan 2004 13:29:21 -0800 (PST) Received: from eng.sun.com (ocean.SFBay.Sun.COM [129.146.85.132]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i0LLTKIP360191; Wed, 21 Jan 2004 13:29:20 -0800 (PST) Message-ID: <400EEEC2.9030304@eng.sun.com> Date: Wed, 21 Jan 2004 13:27:30 -0800 From: hooshang User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.6b) Gecko/20031206 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Connectathon 2004 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Guys, Get ready for Connectathon 2004! The 18th annual interoperability testing event for engineers only will be held Feb. 19-26, 2004 in San Jose, California. For the past 3 years, Connectathon booth space has sold out! Get your registration forms and fees in early and take advantage of registration discounts available through December 19th. Connectathon, sponsored by Sun Microsystems, Inc., hosts over 40 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over RDMA NFSv4 replication and migration Kerberos IPv6 IPsec Mobile IPv6 Secure Shell Based on demand, in addition we are considering to offer: LDAP NDMP CIFS iSCSI If you are interested in testing any of the above 4 protocols, please send a note to Cthon@sun.com and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars and speakers addressing various topics. The registration deadline is February 6, 2004. But don't wait that long! And Early Bird Discount on booth fees is available to those who register and pay by December 19, 2003. For the past 3 years, Connectathon has sold out of booth space. Please get your registration materials in quickly to avoid disappointment. Go to http://www.connectathon.org to download all forms and information. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 18th annual Connectathon event! Audrey Van Belleghem Connectathon Manager From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 27 01:12:11 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08357 for ; Tue, 27 Jan 2004 01:12:11 -0500 (EST) Received: (qmail 20688 invoked by uid 605); 27 Jan 2004 06:12:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20674 invoked from network); 27 Jan 2004 06:12:00 -0000 Received: from satva.skalasoft.com (212.36.10.173) by mail.netbsd.org with SMTP; 27 Jan 2004 06:12:00 -0000 Received: (qmail 9829 invoked from network); 27 Jan 2004 06:16:43 -0000 Received: from satva.int.skalasoft.com (HELO roumenpetrov.info) (192.168.0.100) by satva.int.skalasoft.com with SMTP; 27 Jan 2004 06:16:43 -0000 Message-ID: <40160126.5030002@roumenpetrov.info> Date: Tue, 27 Jan 2004 08:11:50 +0200 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: bg, ru, de, en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication References: <200401170157.i0H1vi402152@cs.auckland.ac.nz> In-Reply-To: <200401170157.i0H1vi402152@cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > "Glen Matthews" [SNIP] > > moreover, implementations supporting x509 (e.g. ssh.com) currently send > > string "DER-encoded cert" In [SSH-USERAUTH] section 3.3 definition is public key blob. X.509 equivalent is exactly "DER-encoded cert". Wenn a packet contain X.509 certificates and we would like to compute signature we MUST use ASN.1 DER encoding. > > without even sending the key type. > > Certificates and public keys are encoded as follows: > > string certificate or public key format identifier > byte[n] key/certificate data > Might definition in [SSH-TRANS] is confusing. Where is public key blob ? Is "public key blob" == string(format identifier)+byte[n](key data) or might "public key blob" == byte[n](key data) ? Of course we know that "public key blob"[SSH-USERAUTH] == "key format"[SSH-TRANS] > so, i'm confused by the draft and the implementations. In case of X.509 certificates "key format" should be ASN.1 DER encoded only, i.e. without format identifier since X.509 cert. contain all necessary information. > > [SNIP] > About signatures: this is the true/real question. In case of x509v3-sign-rsa we can use MD5 or SHA-1 hash. In my implementation we can select preffered rsa hash. Client and server accept authentication packets with both hashes. Since SHA-1 is preferred in [PKIXPROF] might is good [SSH-TRANS] document to contain lines: After 31 December 2004 all SSH implementation MUST use SHA-1 hash to compute x509v3-sign-rsa resulting signature. Until that date, conforming SSH may be assumed MD5 and SHA-1 hash based resulting signature as different. What sort of signature to use in case of x509v3-sign-dss: same as described in [SSH-TRANS] for "ssh-dss" or to use ASN.1 encoding for dsa-sig(r,s) as is defined in [PKIXALGS] and as is in some SecSH implementations ? References: [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport-17.txt, Oct 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth-18.txt, Oct 2003. [PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation Lists (CRL) Profile", RFC 3279, April 2002. Roumen From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 27 01:12:59 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08385 for ; Tue, 27 Jan 2004 01:12:58 -0500 (EST) Received: (qmail 21362 invoked by uid 605); 27 Jan 2004 06:12:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21355 invoked from network); 27 Jan 2004 06:12:55 -0000 Received: from satva.skalasoft.com (212.36.10.173) by mail.netbsd.org with SMTP; 27 Jan 2004 06:12:55 -0000 Received: (qmail 9868 invoked from network); 27 Jan 2004 06:17:44 -0000 Received: from satva.int.skalasoft.com (HELO roumenpetrov.info) (192.168.0.100) by satva.int.skalasoft.com with SMTP; 27 Jan 2004 06:17:44 -0000 Message-ID: <40160163.20500@roumenpetrov.info> Date: Tue, 27 Jan 2004 08:12:51 +0200 From: Roumen Petrov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: bg, ru, de, en-us, en MIME-Version: 1.0 To: Damien Miller CC: Peter Gutmann , glen@montreal.hcl.com, ietf-ssh@NetBSD.org Subject: Re: Certificate authentication References: <200401170157.i0H1vi402152@cs.auckland.ac.nz> <400B3BB3.80602@mindrot.org> In-Reply-To: <400B3BB3.80602@mindrot.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Damien Miller wrote: > [SNIP] > - I think that the certificate hostkeys or userauth should be specified > in separate drafts. > [SNIP] [SSH-USERAUTH] document should be changed too. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 28 16:43:46 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01594 for ; Wed, 28 Jan 2004 16:43:44 -0500 (EST) Received: (qmail 26140 invoked by uid 605); 28 Jan 2004 21:43:39 -0000 Delivered-To: ietf-ssh@netbsd.org Date: 28 Jan 2004 21:43:39 -0000 Received: (qmail 26133 invoked from network); 28 Jan 2004 21:43:38 -0000 Received: from unknown (HELO bpmsite.com) (220.184.152.171) by mail.netbsd.org with SMTP; 28 Jan 2004 21:43:38 -0000 Received: from ([127.0.0.1]) with MailEnable ESMTP; Thu, 29 Jan 2004 05:48:09 +0800 Message-ID: <446196.1075326315455.JavaMail.Developer@mail.cpterson.com> From: "Christine A. Peterson" To: ietf-ssh@NetBSD.org Subject: openssh.com ranked # 15 in Google for web based project management software Cc: djm@openbsd.org Cc: openssh@openssh.com Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi there! Sorry for an e-mail out of the blue, but I just did a search for the term web based project management software on Google and found openssh.com ranked 15. Since I publish a related website about Computers - Software (it's strictly informational, so I'm definitely NOT a competitor of yours), I'd like to link to your site. My site is one of the best resources for info in our category. Because of this great info, I get a pretty decent amount of visitors...so if I link to you, your site should get some nice traffic as well. I think you'll see that my site is pretty clean and high quality. I consider my site a good product, and I only request to link to other quality sites. I would ask that you also link to my site in exchange. So you know, I've already linked to you and will keep it there for a few days until I hear from you. If you're interested in swapping links for good, please reply back so I can get you all of the pertinent information. Thanks! Christine A. Peterson RAC IM: 312297. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 29 19:10:56 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02320 for ; Thu, 29 Jan 2004 19:10:56 -0500 (EST) Received: (qmail 19188 invoked by uid 605); 30 Jan 2004 00:10:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19180 invoked from network); 30 Jan 2004 00:10:53 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 30 Jan 2004 00:10:53 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id i0U0Anjb051252 for ; Thu, 29 Jan 2004 17:10:51 -0700 (MST) Message-ID: <00b701c3e6c5$85349f30$6464a8c0@nm.vandyke.com> From: "Brent McClure" To: References: <200401170157.i0H1vi402152@cs.auckland.ac.nz> <400B3BB3.80602@mindrot.org> <40160163.20500@roumenpetrov.info> Subject: clarification of "compulsory" attributes in publickey subsystem Date: Thu, 29 Jan 2004 17:10:49 -0700 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on kaimen.swcp.com X-Spam-Status: No, hits=0.0 required=10.0 tests=none autolearn=no version=2.61 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Could I get some clarification about the "compulsory" flag in the publickey subsystem draft? http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickey-subsystem-00.txt The draft talks about how a client can send a "listattributes" request and the server will respond with zero or more of these responses: string "attribute" string attribute name boolean compulsory Here is the draft's description of compulsory: The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. What was the rationale for the compulsory flag? I want to make sure I understand what we're supposed to do with this flag. thanks, Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 11:41:52 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26179 for ; Fri, 30 Jan 2004 11:41:51 -0500 (EST) Received: (qmail 1800 invoked by uid 605); 30 Jan 2004 16:41:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1616 invoked from network); 30 Jan 2004 16:41:40 -0000 Received: from mm01snlnto.sandia.gov (HELO MM01SNLNTO.son.sandia.gov) (132.175.109.20) by mail.netbsd.org with SMTP; 30 Jan 2004 16:41:40 -0000 Received: from 132.175.109.4 by mm02snlnto.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 09:41:29 -0600 Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0UGfTOM000735; Fri, 30 Jan 2004 09:41:29 -0700 (MST) Received: by es01snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 09:41:29 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Darren Tucker'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se cc: "OpenSSH Devel List" , ietf-ssh@NetBSD.org Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 09:41:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C0456B3291561-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Darren, I have been doing some testing and I noticed a problem with the server implementation of GSSAPI authentication within the open ssh snapshot (openssh-SNAP-20040124.tar.gz). The draft (draft-ietf-secsh-gsskeyex-07) states: Since the user authentication process by its nature authenticates only the client, the setting of the mutual_req_flag is not needed for this process. This flag SHOULD be set to "false". The client sets this to true, not really a problem. Our modified f-secure client does the same thing. However, if GSS_C_MUTUAL_FLAG is not set, then the open ssh server rejects the connection. The following line of code (from gss-serv.c): /* Now, if we're complete and we have the right flags, then * we flag the user as also having been authenticated */ if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { if (ssh_gssapi_getclient(ctx, &gssapi_client)) fatal("Couldn't convert client name"); } This requires the client to set GSS_C_MUTUAL, which conflicts with the draft. -dan -----Original Message----- From: Darren Tucker [mailto:dtucker@zip.com.au] Sent: Wednesday, January 21, 2004 6:46 PM To: kerberos@mit.edu; krbdev@mit.edu; heimdal-discuss@sics.se Cc: OpenSSH Devel List Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes (I hope this message is appropriate for these lists. If not, please tell me and I won't do it again.) Hi All. There will be a new release of OpenSSH in a couple of weeks. This release contains Kerberos and GSSAPI related changes that we would like to get some feedback about (and hopefully address any issues with) before the release. I encourage anyone with an interest in Kerberos/GSSAPI support in OpenSSH to try a snapshot [1] and send feedback. Changes in OpenBSD's OpenSSH and -Portable: - markus@cvs.openbsd.org 2003/11/17 11:06:07 replace "gssapi" with "gssapi-with-mic"; from Simon Wilkinson; test + ok jakob. - jakob@cvs.openbsd.org 2003/12/23 16:12:10 implement KerberosGetAFSToken server option. ok markus@, beck@ - markus@cvs.openbsd.org 2003/11/02 11:01:03 remove support for SSH_BUG_GSSAPI_BER; simon at sxw.org.uk Changes in -Portable only - (dtucker) Only enable KerberosGetAFSToken if Heimdal's libkafs is found. with jakob@ - (dtucker) [configure.ac] Use krb5-config where available for Kerberos/GSSAPI detection, libs and includes. ok djm@ Additionally, as a side effect of the last change, the test for libkafs is now independant of the Heimdal test, so should a version that works with MIT Kerberos be available it will be used. All but the last are in the 20040122 snapshot, and the last will be in 20040123 and up. Please follow-up to the OpenSSH devel list (cc: the Kerberos lists if you consider it appropriate). [1] ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ or one of the mirrors listed at http://openssh.com/portable.html#mirrors -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 16:44:52 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21139 for ; Fri, 30 Jan 2004 16:44:51 -0500 (EST) Received: (qmail 7032 invoked by uid 605); 30 Jan 2004 21:44:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7025 invoked from network); 30 Jan 2004 21:44:47 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 30 Jan 2004 21:44:47 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01464; 30 Jan 2004 16:43 EST Date: Fri, 30 Jan 2004 16:43:51 -0500 From: Jeffrey Hutzelman To: "Wachdorf, Daniel R" , "'Darren Tucker'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se cc: OpenSSH Devel List , ietf-ssh@NetBSD.org Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Message-ID: <1448470000.1075499031@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" wrote: > The client sets this to true, not really a problem. Our modified f-secure > client does the same thing. However, if GSS_C_MUTUAL_FLAG is not set, > then the open ssh server rejects the connection. The following line of > code (from gss-serv.c): > > /* Now, if we're complete and we have the right flags, then > * we flag the user as also having been authenticated > */ > > if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && > (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == > GSS_S_COMPLETE)) { > if (ssh_gssapi_getclient(ctx, &gssapi_client)) > fatal("Couldn't convert client name"); > } > > > This requires the client to set GSS_C_MUTUAL, which conflicts with the > draft. Indeed, it does. The server is not supposed to check the state of the mutual_flag of a context accepted for gssapi-with-mic user auth. I know the draft is not entirely clear on this point; would it help if there were text indicating the server MUST NOT do this? Also, I've not actually read this code, other than what's quoted above, but I hope that's not the only place that flags are checked. I'm assuming the openssh code actually implements -07 and 'gssapi-with-mic'. In the new method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether GSS_C_INTEG_FLAG is set. The server is REQUIRED to fail the authentication if the client sends the wrong message; this means the value of GSS_C_INTEG_FLAG must be tested. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 16:52:25 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29970 for ; Fri, 30 Jan 2004 16:52:24 -0500 (EST) Received: (qmail 12765 invoked by uid 605); 30 Jan 2004 21:52:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12758 invoked from network); 30 Jan 2004 21:52:23 -0000 Received: from mm02snlnto.sandia.gov (HELO mm02snlnto.son.sandia.gov) (132.175.109.21) by mail.netbsd.org with SMTP; 30 Jan 2004 21:52:23 -0000 Received: from 132.175.109.4 by MM01SNLNTO.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 14:52:14 -0600 Received: from es08snlnt.sandia.gov (es08snlnt.sandia.gov [134.253.130.11]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0ULqDOM023046; Fri, 30 Jan 2004 14:52:13 -0700 (MST) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 14:52:13 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Jeffrey Hutzelman'" , "Wachdorf, Daniel R" , "'Darren Tucker'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se cc: "OpenSSH Devel List" , ietf-ssh@NetBSD.org Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 14:52:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C040D87442276-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit No, there is another place in the code where GSS_C_INTEG_FLAG is checked. It then either verifies the MIC or processes an EXCHANGE_COMPLETE message. -dan -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] Sent: Friday, January 30, 2004 2:44 PM To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos@mit.edu; krbdev@mit.edu; heimdal-discuss@sics.se Cc: OpenSSH Devel List; ietf-ssh@NetBSD.org Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" wrote: > The client sets this to true, not really a problem. Our modified f-secure > client does the same thing. However, if GSS_C_MUTUAL_FLAG is not set, > then the open ssh server rejects the connection. The following line of > code (from gss-serv.c): > > /* Now, if we're complete and we have the right flags, then > * we flag the user as also having been authenticated > */ > > if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && > (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == > GSS_S_COMPLETE)) { > if (ssh_gssapi_getclient(ctx, &gssapi_client)) > fatal("Couldn't convert client name"); > } > > > This requires the client to set GSS_C_MUTUAL, which conflicts with the > draft. Indeed, it does. The server is not supposed to check the state of the mutual_flag of a context accepted for gssapi-with-mic user auth. I know the draft is not entirely clear on this point; would it help if there were text indicating the server MUST NOT do this? Also, I've not actually read this code, other than what's quoted above, but I hope that's not the only place that flags are checked. I'm assuming the openssh code actually implements -07 and 'gssapi-with-mic'. In the new method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether GSS_C_INTEG_FLAG is set. The server is REQUIRED to fail the authentication if the client sends the wrong message; this means the value of GSS_C_INTEG_FLAG must be tested. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 17:47:38 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05121 for ; Fri, 30 Jan 2004 17:47:38 -0500 (EST) Received: (qmail 11838 invoked by uid 605); 30 Jan 2004 22:47:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11823 invoked from network); 30 Jan 2004 22:47:26 -0000 Received: from btoso-host213.dsl.visi.com (HELO etoh.eviladmin.org) (209.98.236.213) by mail.netbsd.org with SMTP; 30 Jan 2004 22:47:26 -0000 Received: from etoh.eviladmin.org (localhost.eviladmin.org [IPv6:::1]) by etoh.eviladmin.org (8.12.6/8.12.6) with ESMTP id i0UMm7Ki028820; Fri, 30 Jan 2004 16:48:28 -0600 (CST) Received: from localhost (mouring@localhost) by etoh.eviladmin.org (8.12.6/8.12.6/Submit) with ESMTP id i0UMkfXb003408; Fri, 30 Jan 2004 16:47:02 -0600 (CST) Date: Fri, 30 Jan 2004 16:46:41 -0600 (CST) From: Ben Lindstrom To: "Wachdorf, Daniel R" cc: "'Jeffrey Hutzelman'" , , , , , OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list I need someone to look at this and get back to us ASAP in regards to if this will break GSSAPI-WITH-MIC. If this does break something. GET US A PATCH NOW or live with broke GSSAPI-WITH-MIC support for 6 months. If it is just a "clean up" thing that can be handled after 3.9 release. Fine, but I don't want to listen to 6 months of whining if it is. - Ben On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > No, there is another place in the code where GSS_C_INTEG_FLAG is checked. > It then either verifies the MIC or processes an EXCHANGE_COMPLETE message. > > -dan > > > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, January 30, 2004 2:44 PM > To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos@mit.edu; krbdev@mit.edu; > heimdal-discuss@sics.se > Cc: OpenSSH Devel List; ietf-ssh@NetBSD.org > Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes > > On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" > wrote: > > > The client sets this to true, not really a problem. Our modified f-secure > > client does the same thing. However, if GSS_C_MUTUAL_FLAG is not set, > > then the open ssh server rejects the connection. The following line of > > code (from gss-serv.c): > > > > /* Now, if we're complete and we have the right flags, then > > * we flag the user as also having been authenticated > > */ > > > > if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && > > (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == > > GSS_S_COMPLETE)) { > > if (ssh_gssapi_getclient(ctx, &gssapi_client)) > > fatal("Couldn't convert client name"); > > } > > > > > > This requires the client to set GSS_C_MUTUAL, which conflicts with the > > draft. > > Indeed, it does. The server is not supposed to check the state of the > mutual_flag of a context accepted for gssapi-with-mic user auth. I know > the draft is not entirely clear on this point; would it help if there were > text indicating the server MUST NOT do this? > > > Also, I've not actually read this code, other than what's quoted above, but > I hope that's not the only place that flags are checked. I'm assuming the > openssh code actually implements -07 and 'gssapi-with-mic'. In the new > method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether > GSS_C_INTEG_FLAG is set. The server is REQUIRED to fail the authentication > if the client sends the wrong message; this means the value of > GSS_C_INTEG_FLAG must be tested. > > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 17:53:31 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11964 for ; Fri, 30 Jan 2004 17:53:31 -0500 (EST) Received: (qmail 15417 invoked by uid 605); 30 Jan 2004 22:53:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15410 invoked from network); 30 Jan 2004 22:53:30 -0000 Received: from mm01snlnto.sandia.gov (HELO MM01SNLNTO.son.sandia.gov) (132.175.109.20) by mail.netbsd.org with SMTP; 30 Jan 2004 22:53:30 -0000 Received: from 132.175.109.4 by MM01SNLNTO.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 15:53:23 -0600 Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0UMrNOM026781; Fri, 30 Jan 2004 15:53:23 -0700 (MST) Received: by es01snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 15:53:22 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Ben Lindstrom'" , "Wachdorf, Daniel R" cc: "'Jeffrey Hutzelman'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se, ietf-ssh@NetBSD.org, "OpenSSH Devel List" Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 15:53:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C043FE9448869-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ben, This will break GSSAPI_WITH_MIC if clients don't do GSS_C_MUTUAL as outlined by the standard. Ie - follow the standard and it wont work. So I guess that means it's broke. I can get a patch to you, what version of the source should I patch, a nightly snapshot? -dan -----Original Message----- From: Ben Lindstrom [mailto:mouring@etoh.eviladmin.org] Sent: Friday, January 30, 2004 3:47 PM To: Wachdorf, Daniel R Cc: 'Jeffrey Hutzelman'; kerberos@mit.edu; krbdev@mit.edu; heimdal-discuss@sics.se; ietf-ssh@NetBSD.org; OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes I need someone to look at this and get back to us ASAP in regards to if this will break GSSAPI-WITH-MIC. If this does break something. GET US A PATCH NOW or live with broke GSSAPI-WITH-MIC support for 6 months. If it is just a "clean up" thing that can be handled after 3.9 release. Fine, but I don't want to listen to 6 months of whining if it is. - Ben On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > No, there is another place in the code where GSS_C_INTEG_FLAG is checked. > It then either verifies the MIC or processes an EXCHANGE_COMPLETE message. > > -dan > > > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, January 30, 2004 2:44 PM > To: Wachdorf, Daniel R; 'Darren Tucker'; kerberos@mit.edu; krbdev@mit.edu; > heimdal-discuss@sics.se > Cc: OpenSSH Devel List; ietf-ssh@NetBSD.org > Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes > > On Friday, January 30, 2004 09:41:26 -0700 "Wachdorf, Daniel R" > wrote: > > > The client sets this to true, not really a problem. Our modified f-secure > > client does the same thing. However, if GSS_C_MUTUAL_FLAG is not set, > > then the open ssh server rejects the connection. The following line of > > code (from gss-serv.c): > > > > /* Now, if we're complete and we have the right flags, then > > * we flag the user as also having been authenticated > > */ > > > > if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && > > (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == > > GSS_S_COMPLETE)) { > > if (ssh_gssapi_getclient(ctx, &gssapi_client)) > > fatal("Couldn't convert client name"); > > } > > > > > > This requires the client to set GSS_C_MUTUAL, which conflicts with the > > draft. > > Indeed, it does. The server is not supposed to check the state of the > mutual_flag of a context accepted for gssapi-with-mic user auth. I know > the draft is not entirely clear on this point; would it help if there were > text indicating the server MUST NOT do this? > > > Also, I've not actually read this code, other than what's quoted above, but > I hope that's not the only place that flags are checked. I'm assuming the > openssh code actually implements -07 and 'gssapi-with-mic'. In the new > method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether > GSS_C_INTEG_FLAG is set. The server is REQUIRED to fail the authentication > if the client sends the wrong message; this means the value of > GSS_C_INTEG_FLAG must be tested. > > > -- Jeffrey T. Hutzelman (N3NHS) > Sr. Research Systems Programmer > School of Computer Science - Research Computing Facility > Carnegie Mellon University - Pittsburgh, PA > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 17:53:43 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12215 for ; Fri, 30 Jan 2004 17:53:42 -0500 (EST) Received: (qmail 15755 invoked by uid 605); 30 Jan 2004 22:53:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15746 invoked from network); 30 Jan 2004 22:53:41 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 30 Jan 2004 22:53:41 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i0UMrIgP024415; Fri, 30 Jan 2004 15:53:18 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i0UMrImU026020; Fri, 30 Jan 2004 15:53:19 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i0UMmRhf019710; Fri, 30 Jan 2004 16:48:27 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i0UMmP1w019709; Fri, 30 Jan 2004 16:48:25 -0600 (CST) Date: Fri, 30 Jan 2004 16:48:25 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Wachdorf, Daniel R" , "'Darren Tucker'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se, ietf-ssh@NetBSD.org, OpenSSH Devel List Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes Message-ID: <20040130224824.GL18744@binky.central.sun.com> Mail-Followup-To: Jeffrey Hutzelman , "Wachdorf, Daniel R" , 'Darren Tucker' , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se, ietf-ssh@NetBSD.org, OpenSSH Devel List References: <1448470000.1075499031@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448470000.1075499031@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Fri, Jan 30, 2004 at 04:43:51PM -0500, Jeffrey Hutzelman wrote: > Indeed, it does. The server is not supposed to check the state of the > mutual_flag of a context accepted for gssapi-with-mic user auth. I know > the draft is not entirely clear on this point; would it help if there were > text indicating the server MUST NOT do this? For completeness' sake, yes. The client (SHOULD NOT | MAY) set GSS_C_MUTUAL for gssapi-with-mic, but the server MUST ignore the state of the GSS_C_MUTUAL flag for gssapi-with-mic. > Also, I've not actually read this code, other than what's quoted above, but > I hope that's not the only place that flags are checked. I'm assuming the > openssh code actually implements -07 and 'gssapi-with-mic'. In the new > method, the client's final message is either SSM_MSG_USERAUTH_GSSAPI_MIC or > SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, depending entirely on whether > GSS_C_INTEG_FLAG is set. The server is REQUIRED to fail the authentication > if the client sends the wrong message; this means the value of > GSS_C_INTEG_FLAG must be tested. Right. Further, the text should say that the server MAY always reject SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE since there's no generic interface for determining whether a context doesn't have the GSS_C_INTEG flag set because the client left it off or because the mechanism doesn't support GSS_C_INTEG. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 17:55:12 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14144 for ; Fri, 30 Jan 2004 17:55:12 -0500 (EST) Received: (qmail 16844 invoked by uid 605); 30 Jan 2004 22:55:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16836 invoked from network); 30 Jan 2004 22:55:12 -0000 Received: from konishi-polis.mit.edu (18.18.3.10) by mail.netbsd.org with SMTP; 30 Jan 2004 22:55:12 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 5F7F615159C; Fri, 30 Jan 2004 17:54:27 -0500 (EST) To: Ben Lindstrom Cc: "Wachdorf, Daniel R" , "'Jeffrey Hutzelman'" , krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, heimdal-discuss@sics.se, OpenSSH Devel List Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes References: From: Sam Hartman Date: Fri, 30 Jan 2004 17:54:27 -0500 In-Reply-To: (Ben Lindstrom's message of "Fri, 30 Jan 2004 16:46:41 -0600 (CST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Ben" == Ben Lindstrom writes: Ben> I need someone to look at this and get back to us ASAP in Ben> regards to if this will break GSSAPI-WITH-MIC. It may make some conforming clients break but does not create a security problem. Some client implementers may choose to introduce an extra round trip (which is what setting the mutual required flag does) in order to interoperate with OpenSsh if the code is released in the current state. Really, that's probably OK if it happens. I'd class this as a minor conformance issue, but not a huge deal. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 17:59:35 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18737 for ; Fri, 30 Jan 2004 17:59:34 -0500 (EST) Received: (qmail 19887 invoked by uid 605); 30 Jan 2004 22:59:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19880 invoked from network); 30 Jan 2004 22:59:34 -0000 Received: from mm01snlnto.sandia.gov (HELO MM01SNLNTO.son.sandia.gov) (132.175.109.20) by mail.netbsd.org with SMTP; 30 Jan 2004 22:59:34 -0000 Received: from 132.175.109.4 by MM01SNLNTO.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 15:59:24 -0600 Received: from ES01SNLNT.sandia.gov (es01snlnt.sandia.gov [134.253.130.4]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0UMxOON027089; Fri, 30 Jan 2004 15:59:24 -0700 (MST) Received: by es01snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 15:59:23 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Sam Hartman'" , "Ben Lindstrom" cc: "Wachdorf, Daniel R" , "'Jeffrey Hutzelman'" , krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, heimdal-discuss@sics.se, "OpenSSH Devel List" Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 15:59:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C043E46449482-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Well, It could be a problem. If someone has implemented a client and doesn't do mutual auth (as the standard says they should), they could be broken. The fix is easy. Just remove: (*flags & GSS_C_MUTUAL_FLAG) && (*flags & GSS_C_INTEG_FLAG)) from the if statement. I have already tested this out, it works fine. I will make a diff if someone tells me what to base if off of. -----Original Message----- From: Sam Hartman [mailto:hartmans@mit.edu] Sent: Friday, January 30, 2004 3:54 PM To: Ben Lindstrom Cc: Wachdorf, Daniel R; 'Jeffrey Hutzelman'; krbdev@mit.edu; ietf-ssh@NetBSD.org; kerberos@mit.edu; heimdal-discuss@sics.se; OpenSSH Devel List Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes >>>>> "Ben" == Ben Lindstrom writes: Ben> I need someone to look at this and get back to us ASAP in Ben> regards to if this will break GSSAPI-WITH-MIC. It may make some conforming clients break but does not create a security problem. Some client implementers may choose to introduce an extra round trip (which is what setting the mutual required flag does) in order to interoperate with OpenSsh if the code is released in the current state. Really, that's probably OK if it happens. I'd class this as a minor conformance issue, but not a huge deal. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 18:12:11 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00943 for ; Fri, 30 Jan 2004 18:12:11 -0500 (EST) Received: (qmail 25915 invoked by uid 605); 30 Jan 2004 23:12:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25579 invoked from network); 30 Jan 2004 23:12:01 -0000 Received: from btoso-host213.dsl.visi.com (HELO etoh.eviladmin.org) (209.98.236.213) by mail.netbsd.org with SMTP; 30 Jan 2004 23:12:01 -0000 Received: from etoh.eviladmin.org (localhost.eviladmin.org [IPv6:::1]) by etoh.eviladmin.org (8.12.6/8.12.6) with ESMTP id i0UNChKi022700; Fri, 30 Jan 2004 17:13:03 -0600 (CST) Received: from localhost (mouring@localhost) by etoh.eviladmin.org (8.12.6/8.12.6/Submit) with ESMTP id i0UNBCGl008353; Fri, 30 Jan 2004 17:11:32 -0600 (CST) Date: Fri, 30 Jan 2004 17:11:12 -0600 (CST) From: Ben Lindstrom To: "Wachdorf, Daniel R" cc: "'Sam Hartman'" , "'Jeffrey Hutzelman'" , , , , , OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes 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 Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > Well, > > It could be a problem. If someone has implemented a client and doesn't do ^^^^^^^^^^ > mutual auth (as the standard says they should), they could be broken. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This right here is the key to me. If someone is not following the RFC. Then I say let them complaint to their vendor. Again I ask.. As the code stands are *WE* in RFC compliance? If not we need it fixed. As for what to base it off of. Pick a recent snapshot. Not as if the GSSAPI-WITH-MIC code has drasticly changed in the last few days. - Ben From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 18:25:49 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11647 for ; Fri, 30 Jan 2004 18:25:48 -0500 (EST) Received: (qmail 2345 invoked by uid 605); 30 Jan 2004 23:25:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2338 invoked from network); 30 Jan 2004 23:25:44 -0000 Received: from mm01snlnto.sandia.gov (HELO MM01SNLNTO.son.sandia.gov) (132.175.109.20) by mail.netbsd.org with SMTP; 30 Jan 2004 23:25:44 -0000 Received: from 132.175.109.4 by MM01SNLNTO.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 16:25:36 -0600 Received: from es08snlnt.sandia.gov (es08snlnt.sandia.gov [134.253.130.11]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0UNPaOM028431; Fri, 30 Jan 2004 16:25:36 -0700 (MST) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 16:25:35 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Ben Lindstrom'" , "Wachdorf, Daniel R" cc: "'Sam Hartman'" , "'Jeffrey Hutzelman'" , krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, heimdal-discuss@sics.se, "OpenSSH Devel List" Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 16:25:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C04387A452133-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit No. 1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used. The current open ssh server requires that it be used. 2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity. Servers can then choose to disallow it. As far as I can tell from the code, any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set cannot connect. I can't test this because Kerberos-gssapi uses integrity. -dan -----Original Message----- From: Ben Lindstrom [mailto:mouring@etoh.eviladmin.org] Sent: Friday, January 30, 2004 4:11 PM To: Wachdorf, Daniel R Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev@mit.edu; ietf-ssh@NetBSD.org; kerberos@mit.edu; heimdal-discuss@sics.se; OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > Well, > > It could be a problem. If someone has implemented a client and doesn't do ^^^^^^^^^^ > mutual auth (as the standard says they should), they could be broken. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This right here is the key to me. If someone is not following the RFC. Then I say let them complaint to their vendor. Again I ask.. As the code stands are *WE* in RFC compliance? If not we need it fixed. As for what to base it off of. Pick a recent snapshot. Not as if the GSSAPI-WITH-MIC code has drasticly changed in the last few days. - Ben From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 18:57:50 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12696 for ; Fri, 30 Jan 2004 18:57:49 -0500 (EST) Received: (qmail 17325 invoked by uid 605); 30 Jan 2004 23:57:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17318 invoked from network); 30 Jan 2004 23:57:42 -0000 Received: from mm01snlnto.sandia.gov (HELO MM01SNLNTO.son.sandia.gov) (132.175.109.20) by mail.netbsd.org with SMTP; 30 Jan 2004 23:57:42 -0000 Received: from 132.175.109.4 by mm02snlnto.son.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.3)); Fri, 30 Jan 2004 16:57:31 -0600 Received: from es08snlnt.sandia.gov (es08snlnt.sandia.gov [134.253.130.11]) by mailgate2.sandia.gov (8.12.10/8.12.10) with ESMTP id i0UNvVOM029643; Fri, 30 Jan 2004 16:57:31 -0700 (MST) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Fri, 30 Jan 2004 16:57:30 -0700 Message-ID: From: "Wachdorf, Daniel R" To: "'Ben Lindstrom'" , "Wachdorf, Daniel R" cc: "'Sam Hartman'" , "'Jeffrey Hutzelman'" , krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, heimdal-discuss@sics.se, "OpenSSH Devel List" Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Date: Fri, 30 Jan 2004 16:57:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 6C0430E1323036-01-01 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C3E78C.AC2A5900" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C3E78C.AC2A5900 Content-Type: text/plain Content-Transfer-Encoding: 7bit Here is a patch. it was based of the 2004-12-24 snapshot (I had trouble getting todays to compile). *** ../openssh/gss-serv.c Mon Nov 17 04:18:22 2003 --- gss-serv.c Fri Jan 30 16:35:24 2004 *************** *** 117,124 **** * we flag the user as also having been authenticated */ ! if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && ! (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { if (ssh_gssapi_getclient(ctx, &gssapi_client)) fatal("Couldn't convert client name"); } --- 117,123 ---- * we flag the user as also having been authenticated */ ! if(ctx->major == GSS_S_COMPLETE) { if (ssh_gssapi_getclient(ctx, &gssapi_client)) fatal("Couldn't convert client name"); } -dan -----Original Message----- From: Ben Lindstrom [mailto:mouring@etoh.eviladmin.org] Sent: Friday, January 30, 2004 4:11 PM To: Wachdorf, Daniel R Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev@mit.edu; ietf-ssh@NetBSD.org; kerberos@mit.edu; heimdal-discuss@sics.se; OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > Well, > > It could be a problem. If someone has implemented a client and doesn't do ^^^^^^^^^^ > mutual auth (as the standard says they should), they could be broken. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This right here is the key to me. If someone is not following the RFC. Then I say let them complaint to their vendor. Again I ask.. As the code stands are *WE* in RFC compliance? If not we need it fixed. As for what to base it off of. Pick a recent snapshot. Not as if the GSSAPI-WITH-MIC code has drasticly changed in the last few days. - Ben ------_=_NextPart_000_01C3E78C.AC2A5900 Content-Type: application/octet-stream; name=gss-patch-snap-20040124.diff Content-Disposition: attachment; filename=gss-patch-snap-20040124.diff Content-Transfer-Encoding: quoted-printable *** ../openssh/gss-serv.c Mon Nov 17 04:18:22 2003=0A= --- gss-serv.c Fri Jan 30 16:35:24 2004=0A= ***************=0A= *** 117,124 ****=0A= * we flag the user as also having been authenticated=0A= */=0A= =0A= ! if (((flags =3D=3D NULL) || ((*flags & GSS_C_MUTUAL_FLAG) &&=0A= ! (*flags & GSS_C_INTEG_FLAG))) && (ctx->major =3D=3D = GSS_S_COMPLETE)) {=0A= if (ssh_gssapi_getclient(ctx, &gssapi_client))=0A= fatal("Couldn't convert client name");=0A= }=0A= --- 117,123 ----=0A= * we flag the user as also having been authenticated=0A= */=0A= =0A= ! if(ctx->major =3D=3D GSS_S_COMPLETE) {=0A= if (ssh_gssapi_getclient(ctx, &gssapi_client))=0A= fatal("Couldn't convert client name");=0A= }=0A= ------_=_NextPart_000_01C3E78C.AC2A5900-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 19:42:40 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04327 for ; Fri, 30 Jan 2004 19:42:39 -0500 (EST) Received: (qmail 11306 invoked by uid 605); 31 Jan 2004 00:42:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11299 invoked from network); 31 Jan 2004 00:42:39 -0000 Received: from liszt-12.ednet.co.uk (212.20.226.36) by mail.netbsd.org with SMTP; 31 Jan 2004 00:42:39 -0000 Received: from sxw.org.uk (sxw-adsl.ednet.co.uk [212.20.248.63]) by liszt-12.ednet.co.uk (Postfix) with ESMTP id 2D4BC1BE85E; Sat, 31 Jan 2004 00:42:33 +0000 (GMT) Message-ID: <401AF9F8.2090806@sxw.org.uk> Date: Sat, 31 Jan 2004 00:42:32 +0000 From: Simon Wilkinson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wachdorf, Daniel R" Cc: ietf-ssh@NetBSD.org, kerberos@mit.edu, "'Sam Hartman'" , heimdal-discuss@sics.se, OpenSSH Devel List Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Daniel, My personal belief is that its too late in this release cycle to make this change. As the author of the GSSAPI code in OpenSSH, I completely accept your comments - we're not (currently) RFC compliant. However, I'm aware of a number of vendors who have successfully performed interop testing against the current code base. Given the extremely short timelines to release, I'd rather delay a change of this nature until we have more time to evaluate and test it. Cheers, Simon. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 21:59:06 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20377 for ; Fri, 30 Jan 2004 21:59:05 -0500 (EST) Received: (qmail 24704 invoked by uid 605); 31 Jan 2004 02:59:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24697 invoked from network); 31 Jan 2004 02:59:04 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 31 Jan 2004 02:59:04 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01707; 30 Jan 2004 21:57 EST Date: Fri, 30 Jan 2004 21:57:42 -0500 From: Jeffrey Hutzelman To: "Wachdorf, Daniel R" , "'Ben Lindstrom'" cc: krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, "'Sam Hartman'" , heimdal-discuss@sics.se, OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Message-ID: <1478260000.1075517862@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, January 30, 2004 16:25:34 -0700 "Wachdorf, Daniel R" wrote: > No. > > 1 - RFC states GSS_C_MUTUAL_FLAG SHOULD not be used. The current open ssh > server requires that it be used. > > 2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity. > Servers can then choose to disallow it. As far as I can tell from the > code, any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set > cannot connect. I can't test this because Kerberos-gssapi uses integrity. > > -dan > > -----Original Message----- > From: Ben Lindstrom [mailto:mouring@etoh.eviladmin.org] > Sent: Friday, January 30, 2004 4:11 PM > To: Wachdorf, Daniel R > Cc: 'Sam Hartman'; 'Jeffrey Hutzelman'; krbdev@mit.edu; > ietf-ssh@NetBSD.org; kerberos@mit.edu; heimdal-discuss@sics.se; OpenSSH > Devel List > Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes > > > > On Fri, 30 Jan 2004, Wachdorf, Daniel R wrote: > >> Well, >> >> It could be a problem. If someone has implemented a client and doesn't do > ^^^^^^^^^^ >> mutual auth (as the standard says they should), they could be broken. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This right here is the key to me. If someone is not following the RFC. > Then I say let them complaint to their vendor. > > Again I ask.. As the code stands are *WE* in RFC compliance? If not we > need it fixed. > > As for what to base it off of. Pick a recent snapshot. Not as if the > GSSAPI-WITH-MIC code has drasticly changed in the last few days. For some reason, I'm not seeing Ben's messages. Perhaps the mail path from him to me is just really long. In any case... The spec says clients SHOULD set mutual_req to "false", which means not requesting mutual authentication. I know of no mechanisms which will do mutual auth (and produce a context with mutual_flag set) if the client sets mutual_req to "false". What this means is that a compliant client is _likely_ not to work with the openssh server as it stands. It is possible to be compatible with openssh and still be compliant (SHOULD means approximately "do this unless you have a good reason not to"); however, not all compliant clients will be compatible with openssh. Note that the openssh client is an example of a client that interoperates with the openssh server (AFAIK) and is compliant (at least, with respect to this issue). The spec does not specifically prohibit openssh's current behaviour, but it is likely to cause interop problems. IMHO, the fact that this is not specified more clearly is an oversight -- the spec does not provide enough information to write interoperable clients and servers. Thank you both for finding this; I'll be addressing the issue in the next version. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 30 22:10:04 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20851 for ; Fri, 30 Jan 2004 22:10:03 -0500 (EST) Received: (qmail 29949 invoked by uid 605); 31 Jan 2004 03:10:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29937 invoked from network); 31 Jan 2004 03:10:03 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 31 Jan 2004 03:10:03 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa01721; 30 Jan 2004 22:08 EST Date: Fri, 30 Jan 2004 22:08:42 -0500 From: Jeffrey Hutzelman To: "Wachdorf, Daniel R" , "'Ben Lindstrom'" cc: krbdev@mit.edu, ietf-ssh@NetBSD.org, kerberos@mit.edu, "'Sam Hartman'" , heimdal-discuss@sics.se, OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Message-ID: <1478790000.1075518522@minbar.fac.cs.cmu.edu> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit (Just to pick nits... Note that this is not yet an RFC. Hopefully that will change sometime in the next few months, but at the moment it's still an internet-draft.) On Friday, January 30, 2004 16:25:34 -0700 "Wachdorf, Daniel R" wrote: > 2 - RFC also allow for gss mechanisms that don't have GSSAPI integrity. > Servers can then choose to disallow it. As far as I can tell from the > code, any client which doesn't (or cant) have the GSS_C_INTEG_FLAG set > cannot connect. I can't test this because Kerberos-gssapi uses integrity. This is legitimate behaviour. See the last paragraph of section 3.6, at the top of page 15: It is a site policy descision for the server whether or not to permit authentication using GSSAPI mechanisms and/or contexts which do not support per-message integrity protection. The server MAY fail the otherwise valid gssapi-with-mic authentication if per-message integrity protection is not supported. Note the use of the word "MAY", which means "do whatever you want". We actually expect that most server operators will want to accept gssapi-with-mic only in cases where integrity is supported, There was a fairly length discussion of this issue on the ietf-ssh list last October or so. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 31 12:13:41 2004 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28060 for ; Sat, 31 Jan 2004 12:13:40 -0500 (EST) Received: (qmail 8737 invoked by uid 605); 31 Jan 2004 17:13:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8727 invoked from network); 31 Jan 2004 17:13:36 -0000 Received: from luminous.mit.edu (18.101.1.61) by mail.netbsd.org with SMTP; 31 Jan 2004 17:13:36 -0000 Received: by luminous.mit.edu (Postfix, from userid 1000) id 4E45B76650; Sat, 31 Jan 2004 12:12:53 -0500 (EST) To: Jeffrey Hutzelman Cc: "Wachdorf, Daniel R" , "'Darren Tucker'" , kerberos@mit.edu, krbdev@mit.edu, heimdal-discuss@sics.se, ietf-ssh@NetBSD.org, OpenSSH Devel List Subject: Re: Pending OpenSSH release: contains Kerberos/GSSAPI changes References: <1448470000.1075499031@minbar.fac.cs.cmu.edu> <20040130224824.GL18744@binky.central.sun.com> From: Sam Hartman Date: Sat, 31 Jan 2004 12:12:53 -0500 In-Reply-To: <20040130224824.GL18744@binky.central.sun.com> (Nicolas Williams's message of "Fri, 30 Jan 2004 16:48:25 -0600") Message-ID: <87ptd0m48a.fsf@luminous.mit.edu> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'd prefer client MAY mutual auth rather than client SHOULD NOT mutual auth. If the server does not implement gss-keyex then a sufficiently clever client can get some of the benefits of gss-keyex in some situations by requesting mutual.