From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 03:55:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06068 for ; Mon, 1 Nov 2004 03:55:40 -0500 (EST) Received: (qmail 5875 invoked by uid 605); 1 Nov 2004 08:55:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5864 invoked from network); 1 Nov 2004 08:55:33 -0000 Received: from goliath.cnchost.com (207.155.252.47) by mail.netbsd.org with SMTP; 1 Nov 2004 08:55:33 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by goliath.cnchost.com id XAA12509; Sun, 31 Oct 2004 23:05:02 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Cc: "'Joseph Galbraith'" , Subject: RE: SFTP v6? Date: Mon, 1 Nov 2004 05:04:55 +0100 Message-ID: <000101c4bfc7$f45b5580$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Firstly, with regard to the "file-share" method of Joseph's proposal - = if in the end that is the solution picked, I will agree. Secondly, with regard to Niels's message: > Server S, that supports version 3 and version 6 of the protocol. > Client O (old), supporting version 3 and version 4. > Client N (new), supporting only version 6. >=20 > S wants to interoperate with O. Using the traditional version=20 > negotiation will fail (server advertises version 6, O=20 > advertises version 4, which leads to version 4 being=20 > selected, which S doesn't support). Hence S *must* implement=20 > the proposed extension. It always advertises version 3, and=20 > intends to use the proposed extension to negotiate version 6=20 > in the second phase. >=20 > Now N connects to S. If N uses the traditional version=20 > exchange only, communication will fail (N advertises 6, S=20 > advertises 3, which leads to version 3 being selected, which=20 > N doesn't support. So if N wants to interoperate with S, it=20 > too *must* implement the extension. Reading this it seems to me like you're not at all taking into account = that S doesn't "advertise", it responds. Unlike the SSH version string which = is sent by both parties upfront, the server's SFTP version packet is a = response sent to the client. If S prefers version 6 and N advertises 6, it would = be senseless for S to send 3. S can send 6 in response to N's 6, and still = be interoperable at highest version with client X that supports = non-contiguous versions 3 and 6 and implements extended version exchange (i.e. sending = 3 and then negotiating up to version 6). > I don't usually to GUI programming. From my limited=20 > experience, if you have some kind of options dialog or menu,=20 > adding one more checkbox to that dialog is about the same=20 > amount of work as adding one more command line option to a=20 > command line tool. That depends on what your aesthetic criteria are. Certainly if you don't care about how the program looks it can be as simple as you described. = Not so if you're already running out of space and need to rearrange things = just to make room for the new configuration option and then arrange it in a = way that is aesthetically attractive as well as clear and non-confusing to = the operator. Then comes the work of documenting the option; implementing a user = friendly interface guiding the user towards that option when required so that = they will be intuitively led to use it; updating the configuration schema to = work correctly with the new option; interlinking all the various = configuration and program modules that now need to use that option. And still, after all that work has been performed, the user will be confused, will not understand why the connection is not working and will post messages on the forum requiring help from technical support. In the end, if there is no version negotiation scheme allowing support = for non-contiguous versions, it becomes a better solution to implement all = of the version range, rather than having to deal with the consequences of supporting only 2 selected versions but no solid version negotiation = scheme in place. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 04:33:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08501 for ; Mon, 1 Nov 2004 04:33:20 -0500 (EST) Received: (qmail 29164 invoked by uid 605); 1 Nov 2004 09:33:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29154 invoked from network); 1 Nov 2004 09:33:18 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 1 Nov 2004 09:33:17 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DB17A2211B7; Mon, 1 Nov 2004 10:33:15 +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 C8387221C7A; Mon, 1 Nov 2004 10:33:11 +0100 (MET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id iA19XAih002517; Mon, 1 Nov 2004 10:33:11 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA19X3o4002514; Mon, 1 Nov 2004 10:33:03 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 01 Nov 2004 10:32:59 +0100 In-Reply-To: <4182A2B2.5060904@vandyke.com> Message-ID: Lines: 99 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > This is almost the way it works, but not quite. > > V_C = max { version numbers supported by the client } > V_U = highest version supported by server <= V_C > > (V_S doesn't actually exist on the wire.) Thanks for the correction. Let's see if I understand what this implies for interoperability. The failure, for traditional version exchange, seems to be * Client supporting version 3 and 6. * Server supporting version 3 and 4. => V_U = 4 => communication failure. Is this correct? > So I'll make an alternate proposal: [...] > Therefore, I suggest that we change the name of the subsystem > to 'file-share' > > The 'file-share' protocol supports all versions of the 'sftp' > protocol, with the minor exception that version exchange > consists of: > > Server and client both send (without waiting to receive): > > FXP_INIT2 > string version-list > > > version-list is comma separated string of versions, > in order of preference. For example. "6,2,1" I agree this is a clean solution, in line with how the rest of the ssh protocol works. However, let's compare how it will work in practice during the transition period (next few years), with particular focus on our failure case: a client supporting versions 3 and 6, and an old server supporting versions 3 and 4. 1. Client asks SSH server for subsystem "file-share". 2. SSH server replies failure. 3. Client asks for subsystem "sftp". 4. SSH server replies success, and starts the subsystem. 5. Client sends V_C = 3 (servers supporting version 6 are supposed to support "file-share", so there's no point of asking for version 6 at this point). 6. The sftp server selects V_U = 3. 7. Handshaking is finished and sftp version 3 is used for the rest of the session. Do I understand your proposal correctly? Now compare this to the "kludge" that can be used without any changes to the current protocol: 1. Client asks SSH server for subsystem "sftp" 2. SSH server replies success, and starts the subsystem. 3. Client sends V_C = 6. 4. Server replies V_U = 4. 5. Client terminates session, since it doesn't support version 4. 6. Client asks SSH server for subsystem "sftp" 7. SSH server replies success, and starts the subsystem. 8. Client sends V_C = 3. 9. Server replies V_U = 3. 10. Handshaking is finished and sftp version 3 is used for the rest of the session. In this case (which I think is the most central problematic case which we're trying to address) I don't see a big win in introducing "file-share". It makes things only slightly easier for the client, and slightly more complex for the server. And when having this choice, I usually prefer putting the complexity in the client. The reason is that complexity always increases the risk for bugs, and bugs usually have a much worse security impact in the server than in the client. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 10:36:07 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20247 for ; Mon, 1 Nov 2004 10:36:06 -0500 (EST) Received: (qmail 8498 invoked by uid 605); 1 Nov 2004 15:35:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8236 invoked from network); 1 Nov 2004 15:35:45 -0000 Received: from pix-fw.wan.aol.com (HELO wicked.office.aol.com) (152.163.190.1) by mail.netbsd.org with SMTP; 1 Nov 2004 15:35:45 -0000 Received: from [10.2.178.29] (wicked.office.aol.com [10.2.178.29]) by wicked.office.aol.com (8.12.11/8.12.11) with ESMTP id iA1FYmc8016413; Mon, 1 Nov 2004 10:34:48 -0500 Subject: Re: future SFTP version question From: jason bailey To: Joseph Galbraith Cc: denis bider , "'Niels =?ISO-8859-1?Q?M=F6ller=27?=" , ietf-ssh@NetBSD.org In-Reply-To: <4182C125.6030300@vandyke.com> References: <000001c4bdfe$ea976630$6402a8c0@nucleus> <4182C125.6030300@vandyke.com> Content-Type: text/plain Message-Id: <1099323288.15131.26.camel@wicked.office.aol.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 01 Nov 2004 10:34:48 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I'd be more then willing to work with Joseph on the draft. I'm going to take the next couple of days to get familiar with the current documentation and then I'll see what I can add. Jason On Fri, 2004-10-29 at 18:16, Joseph Galbraith wrote: > Well, below is a _very_ rough version of an extension. I'd be > more than happy to have Jason's expertise to help get this > fleshed out where it will work for him (and us.) > > And since non-repudiation has recently whacked me over the head, > I'd agree that I suspect for most of us implementing sftp, it > will probably become non-obscure and not-so-specialized soon, if > it hasn't already. > > (One alternate proposal I had was to put together a AS profile for > running of sftp, AS4... but I think that might be _really_ > heavy weight, and what Jason seems to be saying is we already > have most of what we need anyway.) > > - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 11:39:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00275 for ; Mon, 1 Nov 2004 11:39:01 -0500 (EST) Received: (qmail 20004 invoked by uid 605); 1 Nov 2004 16:39:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19994 invoked from network); 1 Nov 2004 16:38:59 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Nov 2004 16:38:58 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6815294; Mon, 01 Nov 2004 09:38:57 -0700 Message-ID: <418666A0.5020504@vandyke.com> Date: Mon, 01 Nov 2004 09:38:56 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Joseph Galbraith writes: > > >>This is almost the way it works, but not quite. >> >>V_C = max { version numbers supported by the client } >>V_U = highest version supported by server <= V_C >> >>(V_S doesn't actually exist on the wire.) > > > Thanks for the correction. Let's see if I understand what this implies > for interoperability. The failure, for traditional version exchange, > seems to be > > * Client supporting version 3 and 6. > * Server supporting version 3 and 4. > > => V_U = 4 => communication failure. > > Is this correct? Yes, I believe this is the case. [...] > I agree this is a clean solution, in line with how the rest of the ssh > protocol works. However, let's compare how it will work in practice > during the transition period (next few years), with particular focus > on our failure case: a client supporting versions 3 and 6, and an old > server supporting versions 3 and 4. > [...description omitted for brevitty...] > > Do I understand your proposal correctly? Yes, I think you do. > Now compare this to the > "kludge" that can be used without any changes to the current protocol: [...description omitted for brevitty...] I suppose that the kludge isn't that bad. > In this case (which I think is the most central problematic case which > we're trying to address) I don't see a big win in introducing > "file-share". It makes things only slightly easier for the client, and > slightly more complex for the server. > > And when having this choice, I usually prefer putting the complexity > in the client. The reason is that complexity always increases the risk > for bugs, and bugs usually have a much worse security impact in the > server than in the client. In general I agree, I'd rather have complexity in the client than the server, however, in this case, I think the additional complexity in the server is pretty small for 'file-share' and the additional complexity in the client for 'kludge-mode' is significantly higher degree than increased complexity for 'file-share'. In fact, 'kludge-mode' requires the entire channel to go down and be reopened. 'file-share' experiences a failure to start a subsystem, and so requests a different one, but shouldn't require the channel to go down. Put another way, I have a lower layer (connection) that starts an upper layer protocol (sftp). In kludge mode, that upper layer now has to: a. pass back private data to the lower, connection, layer (the server sftp version) and a request the connection layer to restart the sftp layer with the version as a parameter. --or-- b. Emulate the lower layer itself to start a new channel. With file-share, this complexity occurs along a more natural border (at least in my software), because the channel doesn't have to go down. In addition, their are several reasons I feel strongly about the 'file-share' proposal. 1. I believe it is the better version negotiation protocol. 2. It works the way you thought it did :-), with client and server both announcing their versions to the other. As you noted, this is the way many protocols work, and I think it is more intuitive. 3. It is familiar to SSH implementors in it's specific algorithm (choose first item on client list also on servers.) 4. When a version negotiation failure occurs, both sides know why, because they both have the same information. This leads to better error messages and easier trouble shooting for sys admins and tech support. In fact, with the current draft, if the server doesn't support the clients version at all (v2-4 client, v6 only server), the server has to close the connection, there is no way to communicate to the client why it did so. Until we had this discussion, I would have assumed, as a tech support, admin, or implementor, that the server had a bug and crashed, not that there was a version problem. 5. It allows extension of the startup protocol on both sides, not just the server. 6. For a brand new latest-version-only implementation, it reduces complexity. There is one less packet type, one less error condition on each side (the server sent me a client init packet, or visa versa.) So, it reduces burden on new implementations while only adding a little complexity to existing implemenations. This is important because one presumes there will be more implementations after we get to RFC, that don't want / need to be burden with all of our intermediate baggage. 7. It is faster (saves half a round trip.) Even in compatibility mode, when the client has to fall back to 'sftp', it is only one extra round trip, as compared to kludge mode which requires a channel open, subsystem request, sftp-init, and sftp-version, and channel close (5 round trips) before it can fall back to the version that will inter-operate. [Note this is least significant to me, but still a property of the proposal.] In other words, outside of the fact that it solves the version problem we've been discussing, I think it is just plain a better way to go. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 12:11:20 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04880 for ; Mon, 1 Nov 2004 12:11:20 -0500 (EST) Received: (qmail 8099 invoked by uid 605); 1 Nov 2004 17:11:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8090 invoked from network); 1 Nov 2004 17:11:17 -0000 Received: from dsl-217-155-92-105.zen.co.uk (HELO scuzzy.ben.algroup.co.uk) (217.155.92.105) by mail.netbsd.org with SMTP; 1 Nov 2004 17:11:17 -0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id D4B9D107D17; Mon, 1 Nov 2004 16:41:54 +0000 (GMT) Message-ID: <41866756.7070302@algroup.co.uk> Date: Mon, 01 Nov 2004 16:41:58 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: jbailey@aol.net, nisse@lysator.liu.se, ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org, jon@siliconcircus.com Subject: Re: future SFTP version question References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: > > >>Then I think the first thing you have to do is to write up the requirements. >>"Non-repudiation" is a very fuzzy concept to me, and I'll have a hard time >>participating in discussion of details in a non-repudiation mechanism. > > > It's a fuzzy concept to everyone, so much so that after 20-odd years of trying > the X.509 guys gave up and renamed the nonRepudiation flag in certs to > something that actually had a meaning. Calling it a "delivery receipt" would > be better, that's what S/MIME (which is the only major standard to > specifically address this) calls it. In fact you could probably lift a lot of > the S/MIME stuff, since they've looked at it in some detail. Its actually a concept with a perfectly well-defined meaning in law - which is, it is something that is _defined by law_ to be non-repudiable (i.e. you can deny it, but it doesn't get you anywhere). An example is the UK Customs and Excise electronic VAT returns - they are non-repudiable by statute. If anyone cares, this whole debate caused me to write a paper about this (and other things) with a lawyer: http://www.apache-ssl.org/tech-legal.pdf Section 2.7 deals with non-repudiation. Cheers, Ben. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 13:18:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14021 for ; Mon, 1 Nov 2004 13:18:17 -0500 (EST) Received: (qmail 22794 invoked by uid 605); 1 Nov 2004 18:18:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22785 invoked from network); 1 Nov 2004 18:18:16 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Nov 2004 18:18:16 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6815628; Mon, 01 Nov 2004 11:18:15 -0700 Message-ID: <41867DE6.8070407@vandyke.com> Date: Mon, 01 Nov 2004 11:18:14 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Joseph Galbraith writes: > > >>This is almost the way it works, but not quite. >> >>V_C = max { version numbers supported by the client } >>V_U = highest version supported by server <= V_C >> >>(V_S doesn't actually exist on the wire.) > > > Thanks for the correction. Let's see if I understand what this implies > for interoperability. The failure, for traditional version exchange, > seems to be > > * Client supporting version 3 and 6. > * Server supporting version 3 and 4. > > => V_U = 4 => communication failure. > > Is this correct? Let me call out one additional failure-- I mention it in my other message but I think it is worth calling out seperately. It is more a failure to fail gracefully. * Client supporting versions < n * Server supporting versions >= n+1 These two can't interoperate, but the server can't communicate why. The client sees a channel close as the failure mode, which could mean many different things. Today, in fact, a channel close probably means that the server crashed. Or had some other fatal startup bug/failure. Version negotiation failure is probably a small percentage of such cases. (Today anyway-- next year may be different.) I'd like an unambigous failure when the versions are incompatible. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 15:56:54 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00290 for ; Mon, 1 Nov 2004 15:56:54 -0500 (EST) Received: (qmail 12341 invoked by uid 605); 1 Nov 2004 20:56:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12319 invoked from network); 1 Nov 2004 20:56:50 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 1 Nov 2004 20:56:49 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA1KH9ui020119 for ; Mon, 1 Nov 2004 13:17:09 -0700 (MST) 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 iA1KH8kt027646; Mon, 1 Nov 2004 15:17:08 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA1KH8L2019389; Mon, 1 Nov 2004 15:17:08 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iA1KH8xJ019388; Mon, 1 Nov 2004 15:17:08 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: [Fwd: referencing trademarks in RFCs] From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1099340227.18370.57.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 01 Nov 2004 15:17:07 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit As you're no doubt aware, the core drafts had not been reissued for a while. The source of the delay is related to the change to the revised IETF procedures for IPR described in RFC3667 and RFC3668. While some of these issues have been resolved (and thus newer drafts have been released), one important remaining issues is the precise form which should be used to refer to trademarks within the text of an RFC. Text relating to trademarks was specifically removed from the drafts at the request of the IESG. However, RFC3667 now requires that known trademarks must be designated, but is not at all specific about what form this mention should take. The IESG has delegated resolution of this question to the IPR working group, aka ipr-wg@ietf.org. Members of this working group (and any other interested party) are of course welcome to join that list and participate in the subsequent discussion. Discussion of IETF-wide rules relating to trademark are best conducted on that list, not here. Needless to say, I feel your pain. - Bill -----Forwarded Message----- From: Steve Bellovin To: ipr-wg@ietf.org Subject: referencing trademarks in RFCs Date: Mon, 01 Nov 2004 13:59:12 -0500 The issue of trademarks recognition has come up in a working group. The IESG has asked the IPR working group to discuss the issue and formulate a policy. Section 3.3(a)(D) says that contributors grant rights to the IETF to reproduce trademarks, etc. It also says: When reproducing Contributions, the IETF will preserve trademark and service mark identifiers used by the Contributor of the Contribution, including (TM) and (R) where appropriate, and 3.4(e) says that contributors warrant that All trademarks, trade names, service marks and other proprietary names used in the Contribution that are reasonably and personally known to the Contributor are clearly designated as such where reasonable. The question is how trademarks should be designated. Clearly, a (TM) or a (R) is permitted by the RFC. Furthermore, 3.6 says that conditions pertaining to implementors using the trademarked terms should be listed on the IETF IPR page, just as is done for patents. We do have a tradition of not listing specific IPR claims in RFCs, partly because ownership and/or validity of such claims can change over time. On the other hand, some trademark owners want to include a more specific acknowledgment, i.e., "Foobar is a trademark of the Hackers Corporation". It's been done before; see, for example, RFCs 1510, 2160, 3268, 2268, and 2936. Beyond that, simply using a trademarked term within an RFC is, arguably, done solely at the pleasure of the trademark owner; that is quite different from a patent, where a protocol specification does not infringe. Furthermore, trademark owners have a legal duty to protect their trademarks, at risk of losing them. That said, specific ownership statements are not universal. Pulling a (non-random) book off my shelf, I see the statement "Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals." Do we want more boilerplate instead? So -- how should trademarks be denoted? Just a (TM) or (R)? Specific ownership statements? A blanket statement? --Steve Bellovin, http://www.research.att.com/~smb _______________________________________________ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 16:43:54 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07527 for ; Mon, 1 Nov 2004 16:43:54 -0500 (EST) Received: (qmail 18003 invoked by uid 605); 1 Nov 2004 21:43:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17964 invoked from network); 1 Nov 2004 21:43:48 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 1 Nov 2004 21:43:48 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 8672A10B793; Mon, 1 Nov 2004 22:38:13 +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 714C2211BB2; Mon, 1 Nov 2004 22:38:09 +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 iA1Lc8ih012190; Mon, 1 Nov 2004 22:38:08 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA1Lc1KR012187; Mon, 1 Nov 2004 22:38:02 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> <418666A0.5020504@vandyke.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 01 Nov 2004 22:37:58 +0100 In-Reply-To: <418666A0.5020504@vandyke.com> Message-ID: Lines: 76 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > In fact, 'kludge-mode' requires the entire channel to go down and > be reopened. 'file-share' experiences a failure to start a subsystem, > and so requests a different one, but shouldn't require the channel > to go down. At least conceptually, ssh channels are farily lightweight. Ok, a typical implementation with sftp as a separate process will spawn one process for each channel, which wastes some resources, but I'm not sure optimal resource usage is important for the backwards compatibility case. > Put another way, I have a lower layer (connection) that starts an > upper layer protocol (sftp). In kludge mode, that upper layer now > has to: > > a. pass back private data to the lower, connection, layer (the server > sftp version) and a request the connection layer to restart > the sftp layer with the version as a parameter. > > --or-- > > b. Emulate the lower layer itself to start a new channel. I'm not sure if you're thinking about the server or client now, but as far as I can see, the interface is clean in both cases. The sftp client asks the lower layer (ssh connection) for a session channel, and asks it to start the sftp subsystem. And it sometimes does that twice. But it's identical both times, no "private data" involved. Then, the request for a session channel may or may not imply a new ssh connection, but that's an implementation issue. One case that I expect to be common when efficiency matters, is to keep an ssh connection in the background, like the lsh gateway mode, or the corresponding feature in recent openssh. Then *all* sftp sessions channels to the same host will reuse an existing connection, no matter which versions they want to use. > 1. I believe it is the better version negotiation protocol. It's more complete than version negotiation in most protocols. Most protocols seem to work fine without completeness, though. I think the reason we seem to be getting into trouble is the rapid increments to the version number, with corresponding changes that aren't backwards compatible at all. Development of most other internet protocols (including ssh!) pays more attention to backwards compatibility, and bumps the protocol version number very rarely. > 3. It is familiar to SSH implementors in it's specific > algorithm (choose first item on client list also on > servers.) Just some tangential comments: If we go this way, then the "version numbers" need not be numbers at all, they can be arbitrary names, with no ordering attached by the protocol. Then an alternative approach (which I'm not advocating) is to delete version negotiation from the sftp protocol completely, just have different subsystem names, sftp1, sftp3, sftp6, .... The client asks for the subsystem type it wants, in can make multiple requests in any order of its choice. > 4. When a version negotiation failure occurs, both sides > know why, because they both have the same information. > > This leads to better error messages and easier trouble > shooting for sys admins and tech support. I think this is one of the stronger arguments for your proposal. I tend to be somewhat negative to all general protocol changes (as I'm sure you've noticed ;-), but I guess I ought to be less conservative with sftp than with ssh proper. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 17:49:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15532 for ; Mon, 1 Nov 2004 17:49:28 -0500 (EST) Received: (qmail 29945 invoked by uid 605); 1 Nov 2004 22:49:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29935 invoked from network); 1 Nov 2004 22:49:25 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 1 Nov 2004 22:49:25 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6816414; Mon, 01 Nov 2004 15:49:23 -0700 Message-ID: <4186BD72.20007@vandyke.com> Date: Mon, 01 Nov 2004 15:49:22 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> <418666A0.5020504@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Joseph Galbraith writes: > >>In fact, 'kludge-mode' requires the entire channel to go down and >>be reopened. 'file-share' experiences a failure to start a subsystem, >>and so requests a different one, but shouldn't require the channel >>to go down. > > > At least conceptually, ssh channels are farily lightweight. Ok, a > typical implementation with sftp as a separate process will spawn one > process for each channel, which wastes some resources, but I'm not > sure optimal resource usage is important for the backwards compatibility > case. > > >>Put another way, I have a lower layer (connection) that starts an >>upper layer protocol (sftp). In kludge mode, that upper layer now >>has to: >> >> a. pass back private data to the lower, connection, layer (the server >> sftp version) and a request the connection layer to restart >> the sftp layer with the version as a parameter. >> >> --or-- >> >> b. Emulate the lower layer itself to start a new channel. > > > I'm not sure if you're thinking about the server or client now, but as > far as I can see, the interface is clean in both cases. Client... > > The sftp client asks the lower layer (ssh connection) for a session > channel, and asks it to start the sftp subsystem. And it sometimes > does that twice. But it's identical both times, no "private data" > involved. But in order for kludge mode to work, the second time it starts the sftp subsystem, it has to pass down the server version it got from the first attempt. (So that the second time around the client can send the version that will have the server pick the right version.) (In our software, it is all one process, but different objects.) The problem is that kludge mode requires me to either reset an an object (complex) and give that object a way to ask the lower layer to restart it's underlying transport, or to persist some state from the object (the version from the sftp server) and provide a way to restart. 'file-share', at least for my implementation, works the way you are describing, because I don't have to get into the middle of the sftp protocol before finding out it doesn't work. The lower layer starts one, and if it doesn't work, it starts the other. > [...] >>1. I believe it is the better version negotiation protocol. > > It's more complete than version negotiation in most protocols. Most > protocols seem to work fine without completeness, though. > > I think the reason we seem to be getting into trouble is the rapid > increments to the version number, with corresponding changes that > aren't backwards compatible at all. Development of most other internet > protocols (including ssh!) pays more attention to backwards > compatibility, and bumps the protocol version number very rarely. On the other hand, it seems like there were several occasions were we punted on a problem or choose a sub-optimal solution because we had to maintain backwards compatibility. So it does swing both ways. >>3. It is familiar to SSH implementors in it's specific >> algorithm (choose first item on client list also on >> servers.) > > Just some tangential comments: If we go this way, then the "version > numbers" need not be numbers at all, they can be arbitrary names, with > no ordering attached by the protocol. Yes; that had occurred to me. I'm not sure we'd ever take advantage of it, but it is possible. > Then an alternative approach > (which I'm not advocating) is to delete version negotiation from the > sftp protocol completely, just have different subsystem names, sftp1, > sftp3, sftp6, .... The client asks for the subsystem type it wants, in > can make multiple requests in any order of its choice. > >>4. When a version negotiation failure occurs, both sides >> know why, because they both have the same information. >> >> This leads to better error messages and easier trouble >> shooting for sys admins and tech support. > > > I think this is one of the stronger arguments for your proposal. Yes, this is a very significant point. I tried to change the version negotiation back when I first started editing sftp so that the server sent back it's version (V_S rather than V_U)... which at least gives the server something valid to send when version negation fails, but we had to back it out because of backwards compatibility. The other argument that is strong to me is that the new proposal works better than what we have for someone implementing only the latest version. I.e., the protocol we go to RFC with will be simpler, not more complex, because of it. (Even if clients and servers doing backwards compatibility do get a little more complex.) > I tend to be somewhat negative to all general protocol changes (as I'm > sure you've noticed ;-), but I guess I ought to be less conservative > with sftp than with ssh proper. I tend to be quite negative towards protocol changes in SSH proper... however, sftp hasn't gone to last call yet (for good reason...) and so isn't in the same semi-frozen state as the SSH proper. (I hope to get there soon though :-) Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 1 22:10:55 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10987 for ; Mon, 1 Nov 2004 22:10:54 -0500 (EST) Received: (qmail 9627 invoked by uid 605); 2 Nov 2004 03:10:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9616 invoked from network); 2 Nov 2004 03:10:49 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 2 Nov 2004 03:10:49 -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 iA23Am7q005297 for ; Mon, 1 Nov 2004 19:10:48 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA23Akkt009183; Mon, 1 Nov 2004 22:10:47 -0500 (EST) Subject: Agenda Items for Next Week From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1099364962.10695.44.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 01 Nov 2004 22:09:23 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We'll be meeting in DC next week; the current agenda has us on Tuesday afternoon from 14:15 to 15:15 Please send proposed agenda items to me. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 00:47:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28690 for ; Tue, 2 Nov 2004 00:47:07 -0500 (EST) Received: (qmail 6418 invoked by uid 605); 2 Nov 2004 05:47:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6407 invoked from network); 2 Nov 2004 05:47:03 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 2 Nov 2004 05:47:03 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id E8A69222F2B; Tue, 2 Nov 2004 06:46:45 +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 CF6B3222F16; Tue, 2 Nov 2004 06:46: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 iA25kfih016213; Tue, 2 Nov 2004 06:46:41 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA25ka0r016210; Tue, 2 Nov 2004 06:46:36 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> <418666A0.5020504@vandyke.com> <4186BD72.20007@vandyke.com> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 02 Nov 2004 06:46:35 +0100 In-Reply-To: <4186BD72.20007@vandyke.com> Message-ID: Lines: 43 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > Niels Möller wrote: > > The sftp client asks the lower layer (ssh connection) for a session > > channel, and asks it to start the sftp subsystem. And it sometimes > > does that twice. But it's identical both times, no "private data" > > involved. > > But in order for kludge mode to work, the second time > it starts the sftp subsystem, it has to pass down > the server version it got from the first attempt. (So > that the second time around the client can send the > version that will have the server pick the right version.) I'd tend to include the sftp version negotiation in the sftp "layer". The lower layer, connection, provides a way for the upper layer (sftp) to open a channel and request a subsystem. But all data transmission on the channel, including the sftp version exchange, is the upper layer's (i.e. sftp's) job. The lower layer doesn't know *anything* about the protocol used on the channel, not even the version used. From this point of view, I see no problem with the interface. > >>4. When a version negotiation failure occurs, both sides > >> know why, because they both have the same information. > I tried to change the version negotiation back when > I first started editing sftp so that the server sent > back it's version (V_S rather than V_U)... which > at least gives the server something valid to send > when version negation fails, but we had to back > it out because of backwards compatibility. One simple idea: In this failure case, server version 6, client version 4 (say), is there any good reason the server can't send version 6 in its SSH_FXP_VERSION, before disconnecting? That would give the client at least some clue. It could reasonably interprete this response as "This server doesn't seem to support versions below 6", and tell that to the user. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 03:23:29 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25570 for ; Tue, 2 Nov 2004 03:23:29 -0500 (EST) Received: (qmail 829 invoked by uid 605); 2 Nov 2004 08:23:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 819 invoked from network); 2 Nov 2004 08:23:26 -0000 Received: from zeppo.itss.auckland.ac.nz (HELO smtpd.itss.auckland.ac.nz) (130.216.190.14) by mail.netbsd.org with SMTP; 2 Nov 2004 08:23:26 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id EDCA234041; Tue, 2 Nov 2004 21:23:24 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20526-05; Tue, 2 Nov 2004 21:23:24 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id D063D33FFD; Tue, 2 Nov 2004 21:23:23 +1300 (NZDT) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CACBF37748; Tue, 2 Nov 2004 21:23:23 +1300 (NZDT) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1COtww-0008Nk-00; Tue, 02 Nov 2004 21:23:30 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ben@algroup.co.uk, pgut001@cs.auckland.ac.nz Subject: Re: future SFTP version question Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org, jbailey@aol.net, jon@siliconcircus.com, nisse@lysator.liu.se In-Reply-To: <41866756.7070302@algroup.co.uk> Message-Id: Date: Tue, 02 Nov 2004 21:23:30 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Ben Laurie writes: >Its actually a concept with a perfectly well-defined meaning in law - which >is, it is something that is _defined by law_ to be non-repudiable (i.e. you >can deny it, but it doesn't get you anywhere). An example is the UK Customs >and Excise electronic VAT returns - they are non-repudiable by statute. Well, that's the problem, legal nonrepudiation is well-established and well- defined, but technical nonrepudiation isn't. The best advice I've seen (from talking to lawyers) is (1) back everything up with paper documents and written signatures and (2) pray you never become the test case. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 07:12:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11297 for ; Tue, 2 Nov 2004 07:12:02 -0500 (EST) Received: (qmail 9332 invoked by uid 605); 2 Nov 2004 12:11:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9318 invoked from network); 2 Nov 2004 12:11:56 -0000 Received: from dsl-217-155-92-105.zen.co.uk (HELO scuzzy.ben.algroup.co.uk) (217.155.92.105) by mail.netbsd.org with SMTP; 2 Nov 2004 12:11:55 -0000 Received: from [193.133.15.218] (ben-xp2.ben.algroup.co.uk [193.133.15.218]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 53C1E107C42; Tue, 2 Nov 2004 12:11:52 +0000 (GMT) Message-ID: <4187798C.6090607@algroup.co.uk> Date: Tue, 02 Nov 2004 12:11:56 +0000 From: Ben Laurie User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-ssh@denisbider.com, ietf-ssh@NetBSD.org, jbailey@aol.net, jon@siliconcircus.com, nisse@lysator.liu.se Subject: Re: future SFTP version question References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Ben Laurie writes: > > >>Its actually a concept with a perfectly well-defined meaning in law - which >>is, it is something that is _defined by law_ to be non-repudiable (i.e. you >>can deny it, but it doesn't get you anywhere). An example is the UK Customs >>and Excise electronic VAT returns - they are non-repudiable by statute. > > > Well, that's the problem, legal nonrepudiation is well-established and well- > defined, but technical nonrepudiation isn't. The best advice I've seen (from > talking to lawyers) is (1) back everything up with paper documents and written > signatures and (2) pray you never become the test case. Technical nonrepudiation is just a stupid idea, which could be why no-one ever agrees about it. -- ApacheCon! 13-17 November! http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 09:04:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21619 for ; Tue, 2 Nov 2004 09:04:17 -0500 (EST) Received: (qmail 19534 invoked by uid 605); 2 Nov 2004 14:04:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19525 invoked from network); 2 Nov 2004 14:04:15 -0000 Received: from brmea-mail-4.sun.com (192.18.98.36) by mail.netbsd.org with SMTP; 2 Nov 2004 14:04:15 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA2E42NH028169; Tue, 2 Nov 2004 07:04:02 -0700 (MST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA2E40QH026929; Tue, 2 Nov 2004 09:04:00 -0500 (EST) Subject: Re: future SFTP version question From: Bill Sommerfeld To: Peter Gutmann Cc: ben@algroup.co.uk, ietf-ssh@denisbider.com, "ietf-ssh@netbsd.org" , jbailey@aol.net, jon@siliconcircus.com, nisse@lysator.liu.se In-Reply-To: References: Content-Type: text/plain Message-Id: <1099404153.10695.57.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 02 Nov 2004 09:02:34 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tue, 2004-11-02 at 03:23, Peter Gutmann wrote: > Well, that's the problem, legal nonrepudiation is well-established and well- > defined, but technical nonrepudiation isn't. The best advice I've seen (from > talking to lawyers) is (1) back everything up with paper documents and written > signatures and (2) pray you never become the test case. I think I've seen enough on this thread. My take: Reusing keys used for authentication and/or key management within SSH to also sign the receipts seems like a bad idea. Defining a receipt format is out of scope for this WG, in part because it involves too many political and financial layer considerations. A draft explaining how to carry someone else's receipt format as an opaque bag of bits within ssh/sftp might potentially be in scope, if an appropriate one which meets relevant layer-8 and layer-9 requirements exists and can be referenced. - Bill (N. B. since it's been a while since I've seen those T-shirts for sale at an IETF... I'm using the quasi-satirical IETF extension of the ISO reference model to add layer 8 (financial) and layer 9 (political) on top of layer 7 (application). From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 11:23:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06060 for ; Tue, 2 Nov 2004 11:23:36 -0500 (EST) Received: (qmail 13428 invoked by uid 605); 2 Nov 2004 16:23:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13418 invoked from network); 2 Nov 2004 16:23:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 2 Nov 2004 16:23:34 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6818272; Tue, 02 Nov 2004 09:23:32 -0700 Message-ID: <4187B485.7020403@vandyke.com> Date: Tue, 02 Nov 2004 09:23:33 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: SFTP v6? References: <004601c4bcca$1752e220$6402a8c0@nucleus> <4182A2B2.5060904@vandyke.com> <418666A0.5020504@vandyke.com> <4186BD72.20007@vandyke.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Joseph Galbraith writes: >>Niels Möller wrote: > >>>>4. When a version negotiation failure occurs, both sides >>>> know why, because they both have the same information. > >>I tried to change the version negotiation back when >>I first started editing sftp so that the server sent >>back it's version (V_S rather than V_U)... which >>at least gives the server something valid to send >>when version negation fails, but we had to back >>it out because of backwards compatibility. > > One simple idea: In this failure case, server version 6, client > version 4 (say), is there any good reason the server can't send > version 6 in its SSH_FXP_VERSION, before disconnecting? That would > give the client at least some clue. It could reasonably interprete > this response as "This server doesn't seem to support versions below > 6", and tell that to the user. Yes; unfortunately, it is hard to say waht a version 4 client would do with that, since it isn't legal in the protocol v4 protocol... if we'd spec'd it that way for 4 it could work :-) We could make the change for v6... and the implementation would have to decide whether to take the risk that a v4 implemenation would behave better with an invalid version packet or behave better with a silent channel close. I think I'd prefer to solve the whole ball of wax at one go... this is an area where we've been bandaging the protocol for a while for backwards compatibilities sake. I'd like to just bite the bullet and get it over with. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 2 16:26:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14323 for ; Tue, 2 Nov 2004 16:26:26 -0500 (EST) Received: (qmail 27323 invoked by uid 605); 2 Nov 2004 21:26:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27314 invoked from network); 2 Nov 2004 21:26:25 -0000 Received: from glatton.cnchost.com (207.155.248.47) by mail.netbsd.org with SMTP; 2 Nov 2004 21:26:25 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by glatton.cnchost.com id OAA00892; Tue, 2 Nov 2004 14:24:16 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Joseph Galbraith'" , "=?iso-8859-2?Q?'Niels_M=F6ller'?=" Cc: Subject: RE: SFTP v6? Date: Tue, 2 Nov 2004 20:24:11 +0100 Message-ID: <00d801c4c111$89978570$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4187B485.7020403@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > I think I'd prefer to solve the whole ball of wax at > one go... this is an area where we've been bandaging > the protocol for a while for backwards compatibilities > sake. > I'd like to just bite the bullet and get it over with. I support that and I'd like to see whatever real solution in place, just = not the kludge. It seems to me like this has already been discussed enough. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 4 10:04:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27351 for ; Thu, 4 Nov 2004 10:04:21 -0500 (EST) Received: (qmail 17600 invoked by uid 605); 4 Nov 2004 15:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20041104150414.17581.qmail@mail.netbsd.org> Received: (qmail 17570 invoked from network); 4 Nov 2004 15:04:13 -0000 Received: from 201009086134.user.veloxzone.com.br (HELO hotmail.com) (201.9.86.134) by mail.netbsd.org with SMTP; 4 Nov 2004 15:04:11 -0000 From: "Roberto Alves" To: Subject: Divulgação por email Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 15 Jan 2005 12:04:14 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Mala direta por e-mail, E-mails de pessoas e empresas de São Paulo e de quase todos estados do Brasil. Listas emails, e-mail regiões, propaganda email, enviar email anônimo, envio mala direta, estados, campanha, cidade, envio, publicidade e-mails, São Paulo... Visite agora: http://www.promonet.mx.gs As melhores listas de e-mails do Brasil. Dividida por estado, pessoas físicas, empresas, por atividades... Visite agora: http://www.promonet.mx.gs From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 4 11:31:52 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07223 for ; Thu, 4 Nov 2004 11:31:51 -0500 (EST) Received: (qmail 15368 invoked by uid 605); 4 Nov 2004 16:31:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15359 invoked from network); 4 Nov 2004 16:31:48 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 4 Nov 2004 16:31:48 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 117A619E3DE; Thu, 4 Nov 2004 17:31:17 +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 57979202DA3; Thu, 4 Nov 2004 17:31:13 +0100 (MET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id iA4GVCih008663; Thu, 4 Nov 2004 17:31:13 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA4GV6T5008660; Thu, 4 Nov 2004 17:31:06 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: New drafts References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 04 Nov 2004 17:31:05 +0100 In-Reply-To: Message-ID: Lines: 91 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > Just to summarize the discussion, I am planning on the following: > > ===== > For SSH_MSG_CHANNEL_OPEN_FAILURE we will have > > 0x0000 0000 - 0xFDFF FFFF IETF CONSENSUS > 0xFE00 0000 - 0xFEFF FFFF PRIVATE USE - channel-type specific > 0xFF00 0000 - 0xFFFF FFFF PRIVATE USE - (experimental stuff) > > with accompanying notes about > > - The range starting with 0xFE should be used when localized names are > used for opening a channel (e.g. SSH_MSG_CHANNEL_OPEN message with a > 'channel type' of "secure-net-hearts@example.com"). Interoperability is > assumed by a "gentleman's agreement" that IF you accept the localized > channel open type THEN you will understand the failure 'reason code' > values associated with that localized name. Also, the IANA assigned > 'reason code' values are still valid even when opening a channel using a > localized name. I don't think "localized" is the right word for referring to names of the "name@domain" type. What are they called where this naming scheme is introduced? "locally defined"? > Note that the 'plaintext password' value is encoded in ISO-10646 > UTF-8. It is up to the server how it interprets the password and > validates it against the password database. However, if the client > reads the password in some other encoding (e.g., ISO 8859-1 - ISO > Latin1), it MUST convert the password to ISO-10646 UTF-8 before > transmitting, and the server MUST convert the password to the > encoding used on that system for passwords. I strongly prefer that we don't change that. The problem is the server side. If a some unix system uses non-ascii characters in passwords, there really ought to be a configuration somewhere on the system that says what character set that is. Without that, I don't think there's a sane way to get passwords right when more than one character set is used (consider a unix server with latin-1 passwords, and a windows-ce client using utf8). I have one suggestion that may or may not satisfy der Mouse: If a server really has no clue about what character set is used in its password database, it SHOULD default to iso-8859-1. Motivation: If you really need to pass an arbitrary octet string as a password, you can do that by encoding the octet string into utf8. I choose iso-8859-1 primarily because transformation between utf8/unicode and iso-8859-1 is particularly easy. Consider (a slight variation of) the given example: The user's password is the octet string 0x72 0xc3 0xeb. The user likes 8859-7, and thinks about the password as r, capital gamma, lowercase lambda, but the sysadmin and the ssh server have no clue about that. Now, the user sits at an utf8-only system (say, the windows-ce client), and wants to login. Typing r, capital gamma, lowercase lambda won't work (and it wouldn't work if the protocol treated passwords as opaque octet strings either). However, if the server interprets the utf8 it receives as latin 1, the user can login if he types "rÃë". I think that der Mouse's point is that *if* the user is sitting at an iso-8859-7-only device, then this won't work (there's no way to input "rÃë" to the client), while things would work if passwords were octet strings in the protocol. I can think of some kludges, but I see no really good way to avoid the problem. Sure, this way of logging in is obscure and not particularly friendly, but I don't think it is worse than the given example. To really support arbitrary character sets in passwords, different for each user, the ssh server somehow needs to figure out the user's preferred locale before trying to verify the password (say, storing it in /etc/passwd, or in $HOME/.locale, whatever). I'm sorry that doesn't seem very practical, but I really don't see any sane way to support network login, from devices using different character sets, without doing this. Conversion on the client side is easier, since all per-user's locale information should be available in the environment. (Another issue is that servers that use utf8 passwords natively *must* normalize the passwords in one way or the other, since no normalization is required on the wire. Same applies to usernames. But I really *hope* that is obvious for everybody who actually implements utf8 for usernames and/or passwords). Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 4 22:36:58 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12710 for ; Thu, 4 Nov 2004 22:36:58 -0500 (EST) Received: (qmail 16810 invoked by uid 605); 5 Nov 2004 03:36:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16801 invoked from network); 5 Nov 2004 03:36:56 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 5 Nov 2004 03:36:56 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id WAA27750; Thu, 4 Nov 2004 22:36:55 -0500 (EST) From: der Mouse Message-Id: <200411050336.WAA27750@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Thu, 4 Nov 2004 22:13:13 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: New drafts In-Reply-To: References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Note that the 'plaintext password' value is encoded in ISO-10646 >> UTF-8. [...] > I strongly prefer that we don't change that. [...] Me too - as you may have gathered. :-) > I have one suggestion that may or may not satisfy der Mouse: > If a server really has no clue about what character set is used in > its password database, it SHOULD default to iso-8859-1. Better than the proposed silence, but not entirely satisfactory, since it leaves nothing for a server to do for octets in the 0x80-0x9f range (which do not correspond to 8859-1 characters, as I understand 8859-1). > Motivation: If you really need to pass an arbitrary octet string as a > password, you can do that by encoding the octet string into utf8. ...hmm? UTF-8 is a way of encoding 10646 codepoints as an octet stream; it's not clear how you're proposing to get from "an arbitrary octet string" to a string of 10646 codepoints to apply the UTF-8 algorithm to. The closest thing to a sane method I can think of is to zero-pad each octet to 16 bits and treat the resulting numbers as 10646 codepoints. If this is what you're proposing, fine, but I think it should be spelled out explicitly. > The user's password is the octet string 0x72 0xc3 0xeb. The user > likes 8859-7, and thinks about the password as r, capital gamma, > lowercase lambda, but the sysadmin and the ssh server have no clue > about that. > Now, the user sits at an utf8-only system (say, the windows-ce > client), and wants to login. Typing r, capital gamma, lowercase > lambda won't work ([...]). However, if the server interprets the > utf8 it receives as latin 1, the user can login if he types "rÃë". Yes...though if the server interprets received UTF-8 as Latin-1, it's not clear what the server should do with that gamma and lambda, or any other received 10646 not present in Latin-1. > To really support arbitrary character sets in passwords, different > for each user, the ssh server somehow needs to figure out the user's > preferred locale before trying to verify the password [...]. Yes. The difficulty of implementation and ugliness of that are why I think passwords shouldn't be character strings, but octet strings, with character sets brought in only when it's time to type a password. (Or display them, if that's ever done, though I'd hope it wouldn't be.) This would mean that an ssh client system needs a way for the user to enter an arbitrary octet sequence when prompted for a password. I consider that a less serious problem than requiring every Unix derivative supporting ssh to either (a) redesign their password systems so that passwords become character strings or (b) not support password authentication. If it came down to that choice, I'd unhesitatingly pick (b), though more likely I'd implement passwords as arbitrary octet strings and ignore the conformance issue. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 5 11:28:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26052 for ; Fri, 5 Nov 2004 11:28:25 -0500 (EST) Received: (qmail 2007 invoked by uid 605); 5 Nov 2004 16:28:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1993 invoked from network); 5 Nov 2004 16:28:20 -0000 Received: from h-68-167-86-242.nycmny83.covad.net (HELO pm-server.cmi-jobs.net) (68.167.86.242) by mail.netbsd.org with SMTP; 5 Nov 2004 16:28:20 -0000 Received: from paul ([192.168.2.20]) by pm-server.cmi-jobs.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 5 Nov 2004 11:11:16 -0500 Reply-To: "Montse Santacana" From: "Montse Santacana" To: Subject: Configuration Management Opportunities Date: Fri, 5 Nov 2004 11:11:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 05 Nov 2004 16:11:16.0702 (UTC) FILETIME=[1435C7E0:01C4C352] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hello, I want to touch base with you regarding Configuration Management, Inc's (CMI) current career opportunities. Perhaps you or someone that you know might be interested in one of the positions that I am currently trying to fill. We have immediate needs for Base ClearCase Administrators in Herndon or Richmond VA or San Diego CA that are UNIX and Windows Interop. I am also looking for a CMM Process Developer in NYC for a Level 2 customer who will be going to Level 3. We also anticipate a wide variety of openings in the first quarter of 2005 including Rational, Telelogic, Serena, Quest Stat! and Perforce Tool Admin and Release Engineering, as well as Software Process Improvement folks. If you or anyone you know is available or interested in making a change, please feel free to contact me directly or pass along my contact. Thanks, Montse Montse Santacana Staffing Manager Configuration Management Inc. 140 Broad St. Red Bank, NJ 07701 (732)450-1100 Ext 107 montse.santacana@cmi.com www.cmi.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 5 14:58:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11316 for ; Fri, 5 Nov 2004 14:58:49 -0500 (EST) Received: (qmail 29084 invoked by uid 605); 5 Nov 2004 19:58:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29072 invoked from network); 5 Nov 2004 19:58:47 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 5 Nov 2004 19:58:47 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id F32E915DACF; Fri, 5 Nov 2004 20:58:45 +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 E7DA983261; Fri, 5 Nov 2004 20:58: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 iA5Jwfih018521; Fri, 5 Nov 2004 20:58:41 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA5JwaZ3018518; Fri, 5 Nov 2004 20:58:36 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: New drafts References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> <200411050336.WAA27750@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 05 Nov 2004 20:58:36 +0100 In-Reply-To: <200411050336.WAA27750@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,TW_XF autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > > If a server really has no clue about what character set is used in > > its password database, it SHOULD default to iso-8859-1. > > Better than the proposed silence, but not entirely satisfactory, since > it leaves nothing for a server to do for octets in the 0x80-0x9f range > (which do not correspond to 8859-1 characters, as I understand 8859-1). I admit I haven't actually read the iso-8859-1 standard. I was thinking about the 0x80 - 0xff range as defined by the "C1 controls and latin1" page of the unicode book, which defines 0x80-0x9f. > ...hmm? UTF-8 is a way of encoding 10646 codepoints as an octet > stream; it's not clear how you're proposing to get from "an arbitrary > octet string" Under the assumption that the server will convert the utf-8 it receives to iso-8859-1 (including control characters, i.e. the range 0x00 - 0xff of unicode, and equvivalents), for each octet x there exists one (sometimes more than one) sequence of utf-8 octets that server will convert back into the octet x you started with. > I consider that a less serious problem than requiring every Unix > derivative supporting ssh to either (a) redesign their password > systems so that passwords become character strings or (b) not > support password authentication. I'm not sure which alternative you are comparing utf-8 passwords to here. I just want to add that unix systems also have the choice of supporting only ascii-passwords. In practice, I'd expect the majority of unix systems to * use ascii-only passwords, or * use a single eight-bit character set for (almost) all user's passwords, or * use utf-8 passwords. And then we have to pray to $DEITY that passwords are normalized in some consistent way before being passed to crypt(3). About the same applies to user names. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 5 16:36:26 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20502 for ; Fri, 5 Nov 2004 16:36:25 -0500 (EST) Received: (qmail 3245 invoked by uid 605); 5 Nov 2004 21:36:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3234 invoked from network); 5 Nov 2004 21:36:24 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 5 Nov 2004 21:36:23 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6827281; Fri, 05 Nov 2004 14:36:22 -0700 Message-ID: <418BF25B.8050409@vandyke.com> Date: Fri, 05 Nov 2004 14:36:27 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041028) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse CC: ietf-ssh@NetBSD.org Subject: Re: New drafts References: <200410281507.LAA22582@ietf.org> <200410281651.MAA13816@Sparkle.Rodents.Montreal.QC.CA> <200411050336.WAA27750@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200411050336.WAA27750@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > Yes. The difficulty of implementation and ugliness of that are why I > think passwords shouldn't be character strings, but octet strings, with > character sets brought in only when it's time to type a password. (Or > display them, if that's ever done, though I'd hope it wouldn't be.) > > This would mean that an ssh client system needs a way for the user to > enter an arbitrary octet sequence when prompted for a password. I > consider that a less serious problem than requiring every Unix > derivative supporting ssh to either (a) redesign their password systems > so that passwords become character strings or (b) not support password > authentication. If it came down to that choice, I'd unhesitatingly > pick (b), though more likely I'd implement passwords as arbitrary octet > strings and ignore the conformance issue. I would prefer (c), every ssh implementation must either know (from configuration or natively), or guess, the charset in use for the password database on the system. The alternative, is (d), every SSH client on every operating system, talking to every server on any OS guesses what charset is in use for passwords on the server, which it knows nothing about. This sounds like a recipe for disaster to me. And just because a client doesn't explicitly do a translation doesn't mean it isn't guessing... it is just guessing the server is the same as it is.... which might work pretty good in a homogeneous environment, but won't necessarily be so hot in a heterogeneous environment. And I'm sorry, but I don't buy that passwords aren't character strings. Humans generate and enter passwords, and humans work in character strings. (Now I do buy that some, maybe most, OSes aren't aware of the charset property of passwords.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 5 19:42:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05679 for ; Fri, 5 Nov 2004 19:42:35 -0500 (EST) Received: (qmail 15807 invoked by uid 605); 6 Nov 2004 00:42:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15797 invoked from network); 6 Nov 2004 00:42:34 -0000 Received: from warspite.concentric.net (HELO warspite.cnchost.com) (207.155.248.9) by mail.netbsd.org with SMTP; 6 Nov 2004 00:42:34 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by warspite.cnchost.com id SAA17831; Fri, 5 Nov 2004 18:08:23 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: Sending SSH_MSG_GLOBAL_REQUEST as keep-alive to the client Date: Sat, 6 Nov 2004 00:08:20 +0100 Message-ID: <000001c4c38c$588bef20$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi everyone, in our server we have had some problems with detecting broken sessions = from clients in the past - the underlying sockets layer would simply not = report the session being terminated although effectively it was dead - and we didn't want to solve it with an inactivity timeout because for our = purposes that would have to be too long, so my solution was to implement a sort = of ping feature in the server: the server sends an SSH_MSG_GLOBAL_REQUEST = of an arbitrary (locally defined) type, and expects to receive either SUCCESS = or FAILURE from the client. If neither arrives, and no other data either, = the session is deemed to be broken, and is closed. This works fine with all recent clients I have had the chance of = testing. However we have had some reports from customers using older versions of OpenSSH, which seem to bomb out and disconnect when = SSH_MSG_GLOBAL_REQUEST is received. The misbehaving versions I am aware of include 2.9, a prehistoric one but still fairly widely deployed, apparently. I believe that our server's behavior is correct according to the specification. [CONNECT] does not explicitly say that global requests = should be handled by the client gracefully, but it does seem to imply so in its non-biased description of the general nature of the packet (section 4 - Global Requests): it refers to 'originator' and 'recipient' rather than client and server, which supports the view that it should be possible = for servers to also send global requests. Indeed, we also use similar server-side requests for purposes other than broken session detection in = our products. But seeing that clients may exist which cannot handle this message, = might it be prudent to add an explicit note in [CONNECT] stating that clients = should handle unrecognized global requests gracefully? The note could be this (appended to the end of section 4 - Global Requests): Note that, while this document defines only request messages sent by client to server, a server MAY also send global requests to the = client. Such request types may be defined by an external specification, by local convention or may be sent with merely the intention of eliciting a response in order to validate that a session is still active. A = client MUST gracefully handle unrecognized global requests by ignoring them and sending an SSH_MSG_REQUEST_FAILURE response. A similar note should then also be appended to the end of section 5.4 - Channel-Specific Requests. Best regards, denis From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 7 13:22:06 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10278 for ; Sun, 7 Nov 2004 13:22:06 -0500 (EST) Received: (qmail 12303 invoked by uid 0); 7 Nov 2004 18:22:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12294 invoked from network); 7 Nov 2004 18:22:05 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 7 Nov 2004 18:22:05 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2004 10:33:21 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA7ILwom024764 for ; Sun, 7 Nov 2004 10:21:59 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA11935 for ; Sun, 7 Nov 2004 10:22:03 -0800 (PST) Date: Sun, 7 Nov 2004 10:22:03 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Proposed Meeting Discussion Items for the Core IDs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I've asked for a few minutes at the meeting to review the core IDs and to close some of our open tickets. Please look over these slides and come prepared to discuss. Hopefully we can close a bunch of these and open discussion for the rest. http://www.employees.org/~lonvick/secsh-wg/ietf61/secshwg.pdf Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 7 14:07:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13972 for ; Sun, 7 Nov 2004 14:07:31 -0500 (EST) Received: (qmail 14572 invoked by uid 0); 7 Nov 2004 19:07:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14537 invoked from network); 7 Nov 2004 19:07:29 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 7 Nov 2004 19:07:28 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 40BBD223402; Sun, 7 Nov 2004 20:07:27 +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 5D18BBB876; Sun, 7 Nov 2004 20:07:23 +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 iA7J7Nih023849; Sun, 7 Nov 2004 20:07:23 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA7J7IG8023846; Sun, 7 Nov 2004 20:07:18 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Proposed Meeting Discussion Items for the Core IDs References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 07 Nov 2004 20:07:17 +0100 In-Reply-To: Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > Hopefully we can close a bunch of these and open > discussion for the rest. > > http://www.employees.org/~lonvick/secsh-wg/ietf61/secshwg.pdf Some of the issues have already been discussed at some length on the list. Ticket 454: triple-des have too few key bits. I think we had consensus to "grandfather" triple-des, however that's going to be expressed in the spec. I.e. just note that triple-des doesn't quite satisfy the requirements, and allow this exception for historical reasons and backwards compatibility. I don't think it's a good idea to lower the general recommendation on key length from 128 to 96 bits. Ticket 461: "implicit server authentication". This has been discussed on the list, we may even have had some proposed text. Ticket 462: discouraging use of different algorithm for the two directions. This has been discussed at length, I argued that it should be allowed and up to local configuration, I don't remember who else agreed with that. I won't be at the meeting, but I think these three issues have been discussed thoroughly enough on the list already, so I hope you can get something more concrete out of the RL meeting than sending the issues back to the mailinglist for another round. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 7 17:48:36 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07095 for ; Sun, 7 Nov 2004 17:48:35 -0500 (EST) Received: (qmail 12159 invoked by uid 0); 7 Nov 2004 22:48:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12149 invoked from network); 7 Nov 2004 22:48:34 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 7 Nov 2004 22:48:34 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2004 15:01:59 -0800 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA7Mm4nC006114; Sun, 7 Nov 2004 14:48:05 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA13238; Sun, 7 Nov 2004 14:48:31 -0800 (PST) Date: Sun, 7 Nov 2004 14:48:31 -0800 (PST) From: Chris Lonvick To: =?iso-8859-1?q?Niels_M=F6ller?= cc: ietf-ssh@NetBSD.org Subject: Re: Proposed Meeting Discussion Items for the Core IDs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Niels, On Sun, 7 Nov 2004, [iso-8859-1] Niels M=F6ller wrote: > Chris Lonvick writes: > > > Hopefully we can close a bunch of these and open > > discussion for the rest. > > > > http://www.employees.org/~lonvick/secsh-wg/ietf61/secshwg.pdf > > Some of the issues have already been discussed at some length on the > list. Super! I'd prefer to track them down in the archives rather than re-hash things. They must have been discussed before I took over as editor. Does anyone have any pointers to these discussions and resolutions? If not, I'll start digging through the archive but I won't be able to get to it for a few weeks. Thanks, Chris > > Ticket 454: triple-des have too few key bits. I think we had consensus > to "grandfather" triple-des, however that's going to be expressed in > the spec. I.e. just note that triple-des doesn't quite satisfy the > requirements, and allow this exception for historical reasons and > backwards compatibility. I don't think it's a good idea to lower the > general recommendation on key length from 128 to 96 bits. > > Ticket 461: "implicit server authentication". This has been discussed > on the list, we may even have had some proposed text. > > Ticket 462: discouraging use of different algorithm for the two > directions. This has been discussed at length, I argued that it should > be allowed and up to local configuration, I don't remember who else > agreed with that. > > I won't be at the meeting, but I think these three issues have been > discussed thoroughly enough on the list already, so I hope you can get > something more concrete out of the RL meeting than sending the issues > back to the mailinglist for another round. > > Best regards, > /Niels > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 8 05:32:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18943 for ; Mon, 8 Nov 2004 05:32:31 -0500 (EST) Received: (qmail 26067 invoked by uid 0); 8 Nov 2004 10:32:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26057 invoked from network); 8 Nov 2004 10:32:28 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 8 Nov 2004 10:32:28 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id DB8F92296AC; Mon, 8 Nov 2004 11:32:03 +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 863202296F2; Mon, 8 Nov 2004 11:31:59 +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 iA8AVxih023503; Mon, 8 Nov 2004 11:31:59 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iA8AVt2O023500; Mon, 8 Nov 2004 11:31:55 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Proposed Meeting Discussion Items for the Core IDs References: From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 08 Nov 2004 11:31:54 +0100 In-Reply-To: Message-ID: Lines: 227 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) 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.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > On Sun, 7 Nov 2004, [iso-8859-1] Niels Möller wrote: > > > Some of the issues have already been discussed at some length on the > > list. > > Super! I'd prefer to track them down in the archives rather than re-hash > things. They must have been discussed before I took over as editor. > Does anyone have any pointers to these discussions and resolutions? The relevant discussion thread seems to be the "additional core draft nits in need of WG attention.", starting with a message by Bill Sommerfield, Mon, 10 Nov 2003 02:12:10 -0500, almost exactly one year ago. Message-id <200311100712.hAA7CAS4004431@thunk.east.sun.com>. I'm including a selection of messages from back then, to try to summarize the discussion. This is naturally my view of the discussion; I haven't carefully reread *all* of the discussion, and I may have missed some disagreeing voices. The relevant archive files seems to be ftp://ftp.ietf.org/ietf-mail-archive/secsh/2003-11.mail and ftp://ftp.ietf.org/ietf-mail-archive/secsh/2003-12.mail > > Ticket 454: triple-des have too few key bits. I think we had consensus > > to "grandfather" triple-des, however that's going to be expressed in > > the spec. I.e. just note that triple-des doesn't quite satisfy the > > requirements, and allow this exception for historical reasons and > > backwards compatibility. I don't think it's a good idea to lower the > > general recommendation on key length from 128 to 96 bits. From Bill: : From: Bill Sommerfeld : Subject: Re: additional core draft nits in need of WG attention. : To: nisse@lysator.liu.se (Niels Möller) : Cc: ietf-ssh@NetBSD.org, Russ Housley : Date: Tue, 11 Nov 2003 10:31:10 -0500 : Reply-To: sommerfeld@east.sun.com : : > > I see a kernel of consensus building for: : > > - leave recommended limit at 128 bits : > > - explicitly grandfather 3DES : > : > Exactly what does "grandfather" mean here? Change 3DES from REQUIRED : > to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? : : My apologies for using an Americanism here. : : "Grandfathering" something means roughly "keep it is, despite not : (precisely) matching the letter of a newer spec/law/regulations/etc, : because we've always done it that way". : : So, that would be "keep as REQUIRED". : - Bill > > Ticket 461: "implicit server authentication". This has been discussed > > on the list, we may even have had some proposed text. : From: Bill Sommerfeld : Subject: (LAST CALL) Re: Implicit server authentication: Proposed clarification : To: nisse@lysator.liu.se (Niels Möller) : Cc: Joseph Galbraith , : Jeffrey Hutzelman , : Peter Gutmann , housley@vigilsec.com, : ietf-ssh@NetBSD.org : Date: Fri, 19 Dec 2003 13:08:05 -0500 : Reply-To: sommerfeld@east.sun.com : : [Sorry for the delay in dealing with this loose end.] : : Seeing no further followup to this thread, I'm going to suggest a : slight modification to Niels's text: : : He wrote: : All currently defined key exchange methods use explicit server : authentication. : : This is a little vague for my tastes; I'd say : : The key exchange method defined in this documents use explicit server : authentication. : : .. and then have dh-group-exchange and gsskeyex say the same.. : : This makes the change the following: : : Before: : : Server authentication in the key exchange MAY be implicit. After a : key exchange with implicit server authentication, the client MUST : wait for response to its service request message before sending any : further data. : : After: : : A key exchange method uses "explicit server authentication" if the : key exchange messages include a signature or other proof of the : server's authenticity. A key exchange method uses "implicit server : authentication" if, in order to prove its autenticity, the server : also has to prove that it knows the shared secret K, by sending a : message and a corresponding MAC which the client can verify. [1] : : The key exchange method defined by this document uses explicit server : authentication. However, key exchange methods with implicit server : authentication MAY be used with this protocol. After a key exchange : with implicit server authentication, the client MUST wait for : response to its service request message before sending any further : data. : : Please send comments on this proposed change to the WG list by Monday, : January 4th, 2004. : : - Bill (The "[1]" at the end of one of the paragraphs should be deleted). > > Ticket 462: discouraging use of different algorithm for the two > > directions. This has been discussed at length, I argued that it should > > be allowed and up to local configuration, I don't remember who else > > agreed with that. There were quite a lot of discussion about this, and I'm not sure what we reached any concensus. A few relevant messages from the discussion: : From: Bill Sommerfeld : Subject: additional core draft nits in need of WG attention. : To: ietf-ssh@netbsd.org : Cc: Russ Housley : Date: Mon, 10 Nov 2003 02:12:10 -0500 : Reply-To: sommerfeld@east.sun.com : : : transport draft: : : > >5. Section 4. SSH allows the client and server to employ different : > >algorithms for the data that they encrypt. This practice should be : > >discouraged somewhere in the document. It is likely to cause : > >interoperability problems, and it offers no security advantage. : : [this is section 5 in version -17] : : suggested resolution: : : immediately after this text: : : The ciphers in each direction MUST run independently of each other, : and implementations MUST allow independently choosing the algorithm : for each direction (if multiple algorithms are allowed by local : policy. : : insert: : : Note that there is no security advantage to using different : algorithms in each direction; implementations SHOULD use the same : algorithm in both directions when allowed by policy. : [...] : From: Bill Sommerfeld : Subject: Re: additional core draft nits in need of WG attention. : To: pgut001@cs.auckland.ac.nz (Peter Gutmann) : Cc: nisse@lysator.liu.se, ietf-ssh@NetBSD.org : Date: Sat, 15 Nov 2003 10:57:58 -0500 : Reply-To: sommerfeld@east.sun.com : : > >If we really want to get rid of this possibility, the cleanest and least : > >confusing way of doing it would be to define protocol version 2.1 with a : > >changed KEXINIT format, : > : > I don't really know if such a big change is necessary, just : > discouraging the use of asymmetric choices (which shouldn't be hard : > given that nothing (?) does it at the moment, so any attempt to : > implement it will fail to interop) should be enough. No need to : > break things. : : The proposal during the WG session was that we should add text so that : for both algorithms and language tags, the negotiated value SHOULD be : the same in both directions. I'll send a more precise recommended : edit in the next day or two.. : : Note the RFC2119 definition of SHOULD: : : 3. SHOULD This word, or the adjective "RECOMMENDED", mean that : there may exist valid reasons in particular circumstances to ignore : a particular item, but the full implications must be understood and : carefully weighed before choosing a different course. : : Note that this is somewhat stronger than the plain-english meaning of : SHOULD. : : Given the current state of the documents (near approval by the IESG), : I'm extremely reluctant to make a larger change at this point. : : We can revisit this issue when we move beyond Proposed Standard. : : (The process for advancement to Draft Standard requires that we : document that all of the protocol features interoperate. if nobody : has actually implemented asymmetric algorithms, we can strike it at : that point). : : - Bill : : P.S., There are certainly a few obscure applications where it makes : sense to use different algorithms in each direction. One which comes : to mind is the case of a remote sensor/space probe/etc., where the : "uplink" is low data-rate management/control traffic, where strong : integrity protection is required to prevent the probe from being : hijacked, and the "downlink" is a higher-volume, lower-value data : stream, where weak integrity protection may be sufficient. : From: Markus Friedl : Subject: Re: additional core draft nits in need of WG attention. : To: Peter Gutmann : Cc: ietf-ssh@NetBSD.org : Date: Mon, 17 Nov 2003 09:37:16 +0100 : : On Mon, Nov 17, 2003 at 02:06:20PM +1300, Peter Gutmann wrote: : > >In IPsec the algorithms are unidirectional. Why should it be a SHOULD for : > >SSH? : > : > In TLS the algorithms are bidirectional. Why should it not be a SHOULD for : > SSH? : : Why should the SSH spec be changed again and again? It's been like : this for about 7 years. Best regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 8 11:23:39 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26598 for ; Mon, 8 Nov 2004 11:23:38 -0500 (EST) Received: (qmail 4678 invoked by uid 0); 8 Nov 2004 16:23:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4667 invoked from network); 8 Nov 2004 16:23:37 -0000 Received: from dreadnought.cnchost.com (207.155.248.18) by mail.netbsd.org with SMTP; 8 Nov 2004 16:23:37 -0000 Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by dreadnought.cnchost.com id KAA17012; Mon, 8 Nov 2004 10:20:35 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: implicit authentication and waiting for service request response Date: Mon, 8 Nov 2004 16:20:29 +0100 Message-ID: <000001c4c5a6$7c2d19b0$0a0a0a0a@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable I find the below wording still confusing. What's the idea of waiting for the server's response to the service = request? What is it for? If the server has already proven that it knows the = shared secret K by sending a corresponding MAC, which the client has, if I = assume correctly, verified - what gives? Why the "MUST" wait for the response = to the service request? I'm probably lacking background here to understand this, but if I lack = the background after working in SSH for years, this will also be a mystery = to new implementors. I'd like this to be clear and explicit enough at least = for me to understand it. : A key exchange method uses "explicit server authentication" if the : key exchange messages include a signature or other proof of the : server's authenticity. A key exchange method uses "implicit server : authentication" if, in order to prove its autenticity, the server : also has to prove that it knows the shared secret K, by sending a : message and a corresponding MAC which the client can verify. [1] :=20 : The key exchange method defined by this document uses explicit = server=20 : authentication. However, key exchange methods with implicit server : authentication MAY be used with this protocol. After a key = exchange : with implicit server authentication, the client MUST wait for : response to its service request message before sending any further : data. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 8 12:01:09 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01451 for ; Mon, 8 Nov 2004 12:01:09 -0500 (EST) Received: (qmail 2586 invoked by uid 0); 8 Nov 2004 17:01:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2576 invoked from network); 8 Nov 2004 17:01:08 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 8 Nov 2004 17:01:08 -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 iA8H0e7q020017; Mon, 8 Nov 2004 09:00:40 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA8H0ckt000323; Mon, 8 Nov 2004 12:00:39 -0500 (EST) Subject: Re: implicit authentication and waiting for service request response From: Bill Sommerfeld To: denis bider Cc: "ietf-ssh@netbsd.org" In-Reply-To: <000001c4c5a6$7c2d19b0$0a0a0a0a@nucleus> References: <000001c4c5a6$7c2d19b0$0a0a0a0a@nucleus> Content-Type: text/plain Message-Id: <1099933145.13936.279.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 08 Nov 2004 11:59:07 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Mon, 2004-11-08 at 10:20, denis bider wrote: > I'm probably lacking background here to understand this, but if I lack the > background after working in SSH for years, this will also be a mystery to > new implementors. I'd like this to be clear and explicit enough at least for > me to understand it. The server authentication is "implicit" because the client doesn't know whether the server successfully did its part of the key exchange until the client receives a subsequent message from the server, not part of the key exchange, which demonstrates knowledge of K by the server. (Kerberos can be used this way) > : A key exchange method uses "implicit server > : authentication" if, in order to prove its autenticity, the server > : also has to prove that it knows the shared secret K, by sending a > : message and a corresponding MAC which the client can verify. [1] I'd suggest changing "by sending a message" to "by sending a subsequent message" - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 01:19:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03580 for ; Tue, 9 Nov 2004 01:19:26 -0500 (EST) Received: (qmail 26043 invoked by uid 0); 9 Nov 2004 06:19:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26034 invoked from network); 9 Nov 2004 06:19:21 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 9 Nov 2004 06:19:21 -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 iA96JK7q017757 for ; Mon, 8 Nov 2004 22:19:21 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA96JIkt024696; Tue, 9 Nov 2004 01:19:19 -0500 (EST) Subject: secsh: Agenda for Tuesday, 1415-1515 From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Content-Type: text/plain; charset=ASCII Message-Id: <1099981156.2710.4.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 01:19:17 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Send comments to me or the WG as a whole. Secure Shell (secsh) Working Group Tuesday, 9 November 2004, 1415-1515, Monroe West Room IV/agenda bashing/bluesheets 5 minutes notetaker? jabber? WG status 5 minutes Draft status 5 minutes Core draft nits 15 minutes Chris Lonvick filexfer draft 15 minutes padding 15 minutes From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 06:09:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12397 for ; Tue, 9 Nov 2004 06:09:43 -0500 (EST) Received: (qmail 7786 invoked by uid 0); 9 Nov 2004 11:09:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7776 invoked from network); 9 Nov 2004 11:09:43 -0000 Received: from ausmtp01.au.ibm.com (202.81.18.186) by mail.netbsd.org with SMTP; 9 Nov 2004 11:09:36 -0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id iA9AtKrJ049052 for ; Tue, 9 Nov 2004 21:55:23 +1100 Received: from d23m0174.in.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9At6Pn094526 for ; Tue, 9 Nov 2004 21:55:46 +1100 Subject: SSH implementaion - using MSCAPI Vs JCE To: ietf-ssh@NetBSD.org X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: Anandha S Srinivasan Date: Tue, 9 Nov 2004 16:19:00 +0530 X-MIMETrack: Serialize by Router on d23m0174/23/M/IBM(Release 6.0.2CF2HF259 | March 11, 2004) at 09/11/2004 16:22:53 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Hi, We are in the early stages of implementing SSH support for our terminal= emulation product (MS Windows based). I would like to see some informat= ion on whether using JCE Vs MSCAPI interfaces will give any advantage with respect to development of SSH (actually SSH2). Can you throw some light on this? Bye / Tschuess / Arrivederci / Adeus / Adi=F3s, Anand. Int'l Business Machines, Bangalore. "Be yourself, no matter what they say" - From "Englishman in New York" = (The Police)= From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 07:39:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19648 for ; Tue, 9 Nov 2004 07:39:36 -0500 (EST) Received: (qmail 7909 invoked by uid 0); 9 Nov 2004 12:39:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7900 invoked from network); 9 Nov 2004 12:39:33 -0000 Received: from mailhost.auckland.ac.nz (HELO smtpa.itss.auckland.ac.nz) (130.216.190.11) by mail.netbsd.org with SMTP; 9 Nov 2004 12:39:33 -0000 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 03615348BD; Wed, 10 Nov 2004 01:15:30 +1300 (NZDT) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14624-03; Wed, 10 Nov 2004 01:15:29 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id DACA0341E6; Wed, 10 Nov 2004 01:15:29 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 548DD37745; Wed, 10 Nov 2004 01:15:29 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CRUuQ-0002r6-00; Wed, 10 Nov 2004 01:15:38 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: AnandhaSubramanian@in.ibm.com, ietf-ssh@NetBSD.org Subject: Re: SSH implementaion - using MSCAPI Vs JCE In-Reply-To: Message-Id: Date: Wed, 10 Nov 2004 01:15:38 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Anandha S Srinivasan writes: >We are in the early stages of implementing SSH support for our terminal >emulation product (MS Windows based). I would like to see some information on >whether using JCE Vs MSCAPI interfaces will give any advantage with respect to >development of SSH (actually SSH2). I can't see that either would give any advantage, all you'll be using is very low-level stuff like RSA, 3DES, DH (actually I'm not sure how widely DH is supported in deployed CryptoAPI CSPs, that may be a point against it). So it's really a case of do you want to be tied to Microsoft Windows or tied to Java? (It'd probably be easier to just grab OpenSSH, Putty, cryptlib (ahem :-), wodSSH, or some other code base that does SSH for you, rather than building everything yourself from scratch. Adding glue code to call your favourite crypto algorithm library, whether it's JCE or CAPI, is about 0.01% of the total work involved). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 10:57:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12719 for ; Tue, 9 Nov 2004 10:57:47 -0500 (EST) Received: (qmail 16957 invoked by uid 0); 9 Nov 2004 15:57:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16947 invoked from network); 9 Nov 2004 15:57:46 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Nov 2004 15:57:46 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6835163; Tue, 09 Nov 2004 08:57:44 -0700 Message-ID: <4190E903.7090901@vandyke.com> Date: Tue, 09 Nov 2004 08:57:55 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20041011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: AnandhaSubramanian@in.ibm.com, ietf-ssh@NetBSD.org Subject: Re: SSH implementaion - using MSCAPI Vs JCE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: >Anandha S Srinivasan writes: > > > >>We are in the early stages of implementing SSH support for our terminal >>emulation product (MS Windows based). I would like to see some information on >>whether using JCE Vs MSCAPI interfaces will give any advantage with respect to >>development of SSH (actually SSH2). >> >> > >I can't see that either would give any advantage, all you'll be using is very >low-level stuff like RSA, 3DES, DH (actually I'm not sure how widely DH is >supported in deployed CryptoAPI CSPs, that may be a point against it). So >it's really a case of do you want to be tied to Microsoft Windows or tied to >Java? > > I believe last time we looked at it, CAPI didn't expose the DH primitives sufficiently to implement SSH2 on top of them. (I'm a little vague, but I think the problem was that you can't get the raw k out of CAPI, but only a key derived from k by CAPI-- using a different algorithm than that specified by SECSH naturually.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 17:30:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21702 for ; Tue, 9 Nov 2004 17:30:46 -0500 (EST) Received: (qmail 26670 invoked by uid 0); 9 Nov 2004 22:30:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26661 invoked from network); 9 Nov 2004 22:30:44 -0000 Received: from portal.hamachi.org (69.25.196.17) by mail.netbsd.org with SMTP; 9 Nov 2004 22:30:44 -0000 Received: from 127.0.0.1 (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 53DD717951; Tue, 9 Nov 2004 17:01:34 -0500 (EST) Subject: A stable reference to ssh v1 (ticket #453) From: Bill Sommerfeld To: Chris Lonvick Cc: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1100037691.5503.14.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 17:01:32 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Poking around, it looks like a reasonably stable reference is: inside: ftp://ftp.funet.fi/pub/unix/security/login/ssh/ssh-1.2.30.tar.gz ssh-1.2.30/RFC Anyone have a good bibliographic reference format for "file within compressed tarball"? :-) If anyone has a better one, let us know.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 17:54:06 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24204 for ; Tue, 9 Nov 2004 17:54:05 -0500 (EST) Received: (qmail 11260 invoked by uid 0); 9 Nov 2004 22:54:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11251 invoked from network); 9 Nov 2004 22:54:05 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 9 Nov 2004 22:54:05 -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 iA9Ms47q008201; Tue, 9 Nov 2004 14:54:05 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA9MrsQH027583; Tue, 9 Nov 2004 17:53:54 -0500 (EST) Subject: core draft issue resolution From: Bill Sommerfeld To: Chris Lonvick Cc: "ietf-ssh@netbsd.org" Content-Type: text/plain Message-Id: <1100040823.5503.21.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 09 Nov 2004 17:53:43 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Proposed core issue resolutions from today's meeting: If anyone objects to these resolutions, or thinks I mis-summarized the discussion, please speak up. ticket 440, 441, 450: close, edits complete. ticket 453: WG chair to identify stable reference for sshv1 (sent to list recently) ticket 454: explicitly grandfather 3DES Editor to insert text equivalent to: NOTE: There is a known attack on 3-key 3DES involving 2^112 space and 2^56 time; however, for the purposes of this requirement 3DES is considered to be strong enough. ticket 461 (implicit server auth): Editor to dig up clarification from list archives, insert into document. ticket 462: different algs in each direction proposal: allow but discourage; Editor to supply text. ticket 463: login timeout proposal: no change to document rationale: - 10 minutes is shorter than typical SMTP listener idle timeout - user interaction is covered in this timeout (entering passwords, etc.,; as a result there may be accessibility requirements for slow typers..) - implementations will likely have knobs to adjust this ticket 464: utf8: utf8 requires input canonicalization; stringprep of usernames and passwords was previously solved by SASL in draft-ietf-sasl-saslprep-10.txt (in RFC Editor Queue, EDIT state) Rather than reinvent the wheel, just cite it. ticket 465: close. was request for consulting ticket 474: x509: remove x509-related text. joe galbraith to supply followup I-D documenting what they do for x509 ticket 460, 601: no consensus on list. flipped coin, heads for "group2", tails for "group14", came up tails will stick with diffie-hellman-group14-sha1 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 9 21:29:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12371 for ; Tue, 9 Nov 2004 21:29:45 -0500 (EST) Received: (qmail 4676 invoked by uid 0); 10 Nov 2004 02:29:44 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20041110022944.4673.qmail@mail.netbsd.org> Received: (qmail 4666 invoked from network); 10 Nov 2004 02:29:43 -0000 Received: from 201009086180.user.veloxzone.com.br (HELO hotmail.com) (201.9.86.180) by mail.netbsd.org with SMTP; 10 Nov 2004 02:29:42 -0000 From: "Ricardo Costa" To: Subject: Re: Recomendação de Mala direta, email, lista de emails Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 9 Nov 2004 23:29:48 -0300 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit De todos este sites recomendo o Divulgamail. Comprei uma excelente listas de e-mail para divulgação. Pesquisei vários e eles tem o melhor serviço de fato. O endereço é: http://www.gueb.de/dvgamail Muito bom mesmo! Vale a pena conferir. Ricardo Costa >Estou querendo divulgar meu site por email (mala direta virtual), > mas não sei qual o site devo escolher. Alguém tem alguma dica ou recomendação? >Mariana From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 11 10:39:43 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23793 for ; Thu, 11 Nov 2004 10:39:43 -0500 (EST) Received: (qmail 19733 invoked by uid 0); 11 Nov 2004 15:39:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19724 invoked from network); 11 Nov 2004 15:39:38 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 11 Nov 2004 15:39:38 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iABFdYs3020178; Thu, 11 Nov 2004 07:39:34 -0800 (PST) Received: from 192.9.61.12 (punchin-sommerfeld.SFBay.Sun.COM [192.9.61.12]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iABFdWQH006622; Thu, 11 Nov 2004 10:39:33 -0500 (EST) Subject: Secure Shell WG Session Summary From: Bill Sommerfeld To: "ietf-ssh@netbsd.org" Cc: Sam Hartman , Steve Bellovin Content-Type: text/plain Message-Id: <1100187568.2170.21.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 11 Nov 2004 10:39:28 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit We met for an hour on tuesday afternoon. We haven't met in about a year, mostly because the core documents have been delayed by a combination of a busy document editor and a number of process issues connected to the switch from RFC2026 to RFC3667/3668. During discussions it became clear that RFC3667 has a bug in that it does not specify precisely *how* the trademark references it requires should appear in RFCs. The IESG has asked the IPR working group to clarify this question, and we are now waiting for the resolution. We reviewed a short list of relatively minor issues, mostly editorial/clarification; perhaps the most significant is that, at the advice of Sam Hartman (new security AD) we've tentatively decided to reference the SASL stringprep profile (currently in the RFC editor queue) for UTF8-encoded login names and passwords (this is believed to have relatively little or no impact on the deployed base). Once the trademark-reference clarification is resolved we believe the documents should be ready to finally pass the IESG. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Nov 14 21:15:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01166 for ; Sun, 14 Nov 2004 21:15:17 -0500 (EST) Received: (qmail 2656 invoked by uid 0); 15 Nov 2004 02:15:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2647 invoked from network); 15 Nov 2004 02:15:08 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Nov 2004 02:15:08 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa17247; 14 Nov 2004 21:14 EST Date: Sun, 14 Nov 2004 21:13:59 -0500 From: Jeffrey Hutzelman To: "Wachdorf, Daniel R" , "'Ben Lindstrom'" cc: ietf-ssh@NetBSD.org, OpenSSH Devel List Subject: RE: Pending OpenSSH release: contains Kerberos/GSSAPI changes Message-ID: <3721540000.1100484839@minbar.fac.cs.cmu.edu> In-Reply-To: <1478260000.1075517862@minbar.fac.cs.cmu.edu> References: <1478260000.1075517862@minbar.fac.cs.cmu.edu> 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 21:57:42 -0500 Jeffrey Hutzelman wrote: > 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. draft-ietf-secsh-gsskeyex-08.txt did not contain any changes related to fixing this issue. However, I am proposing adding the follosing text to the next version of the draft... In key exchange: The server MUST NOT fail the key exchange on the basis of the values of any of conf_avail, replay_det_state, sequence_state, or anon_state. In user authentication: The server MUST NOT fail user authentication on the basis of the values any of conf_avail, replay_det_state, sequence_state, or mutual_state. -- 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 Sun Nov 14 22:49:01 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06124 for ; Sun, 14 Nov 2004 22:49:01 -0500 (EST) Received: (qmail 29446 invoked by uid 0); 15 Nov 2004 03:48:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29437 invoked from network); 15 Nov 2004 03:48:56 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 15 Nov 2004 03:48:56 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa17199; 14 Nov 2004 20:47 EST Date: Sun, 14 Nov 2004 20:47:57 -0500 From: Jeffrey Hutzelman To: Sam Hartman cc: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gss-keyex and null host keys Message-ID: <3707440000.1100483277@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 Wednesday, July 16, 2003 11:28:05 +0200 Jeffrey Hutzelman wrote: > On Wed, 16 Jul 2003, Sam Hartman wrote: > >> First, I propose that the GSSAPI draft fold in >> draft-weber-secsh-pkalg-none-00. The none key type should be combined >> with the null host key type already in the GSSAPI draft. > >> Second, I believe we should add text to the GSSAPI draft proposing two >> possible ways of handling the host key transmitted by the GSSAPI key >> exchange. > > > I agree that both of these changes would be useful. And yet, I haven't done anything about them. :-( Quite some time ago, I came to some conclusions about "none": - It is probably a good idea to have some mechanism along these lines to allow rekeying in the absence of whatever credentials allowed the original key exchange to happen. - "none" has significantly different semantics from "null", and combining them is not only inappropriate but potentially dangerous. "null" is a host key algorithm which does not claim to provide signing or encryption operations, and which therefore cannot be used with any keyex algorithm which requires such operations. For example, it cannot be used with the mandatory DH-based algorithms, because those require a host key algorithm which supports signing. This algorithm is valuable any time a keyex algorithm like gss-* might be used and no other host key is available. By contrast, "none" is an algorithm which _claims_ to provide both signing and encryption operations, but for which those operations don't actually do anything. That is, the encrypt/decrypt operations are the identity mapping, and the verify-signature operation always succeeds. This algorithm would really be better named "noop". This algorithm is intened to be used only during rekeys, when it can be assumed that confidentiality and integrity are provided by the ssh transport layer. Its use during initial key exchange is prohibited, and with good reason. These algotithms are quite different, and combining them under a single name would be quite a bad idea. Doing so would introduce a single name which must describe one set of behaviours during initial key exchange, and a different set during a rekey. The set of key exchange algorithms that could be used with this host key algorithm would differ depending on the context. It would be easy to screw this up and end up with an insecure result. - Given that "none" and "null" are distinct algorithms and should not be combined, I do not believe that "none" belongs in the GSS document at all. I would like to see this work proceed, and am willing to take up editorship of Joel's document if he is no longer available to work on it. I suspect it can be completed fairly quickly. But I don't think it belongs in the GSS document. I sent mail to Joel about this quite some time ago, but I can't find any indication that I've brought it up on the list previously. Of course I will roll the definition of "none" into the GSS document if that is the consensus of the WG, but I don't believe it is appropriate to do so, and I'd rather get the document finished in something close to its current state. Sam also proposed some text recommending handling for host keys received via the GSS mechanism. I agree these changes are a good idea; assuming there is agreement I will make them in the next rev. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 17 12:58:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25090 for ; Wed, 17 Nov 2004 12:58:50 -0500 (EST) Received: (qmail 26504 invoked by uid 0); 17 Nov 2004 17:58:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26495 invoked from network); 17 Nov 2004 17:58:46 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 17 Nov 2004 17:58:46 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 10:11:54 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAHHwaw0024180; Wed, 17 Nov 2004 09:58:37 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA07467; Wed, 17 Nov 2004 09:58:38 -0800 (PST) Date: Wed, 17 Nov 2004 09:58:38 -0800 (PST) From: Chris Lonvick To: Bill Sommerfeld cc: "ietf-ssh@netbsd.org" Subject: Re: core draft issue resolution In-Reply-To: <1100040823.5503.21.camel@unknown.hamachi.org> Message-ID: References: <1100040823.5503.21.camel@unknown.hamachi.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Tue, 9 Nov 2004, Bill Sommerfeld wrote: > ticket 454: explicitly grandfather 3DES > Editor to insert text equivalent to: > > NOTE: There is a known attack on 3-key 3DES involving > 2^112 space and 2^56 time; however, for the purposes of this > requirement 3DES is considered to be strong enough. Is there a name and reference for that attack? Also, I had thought that the reason for keeping 3DES was that it is the "interoperable" algorithm. As such I was going to use the following text: The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [FIPS-46-3]. Note that this algorithm does not meet the specifications that SSH encryption algorithms must use keys of 196 bits or more. However, this algorithm is still REQUIRED for historical reasons; essentially, all known implementations at the time of this writing support this algorithm, and it is commonly used because it is the fundamental interoperable algorithm. At some future time it is expected that another algorithm, one with better strength, will become so prevalent and ubiquitous that the use of "3des-cbc" will be depricated by another STANDARDS ACTION. Does this work? > > ticket 464: utf8: > utf8 requires input canonicalization; stringprep of usernames > and passwords was previously solved by SASL in > draft-ietf-sasl-saslprep-10.txt (in RFC Editor Queue, EDIT state) > > Rather than reinvent the wheel, just cite it. How about this: Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. This encoding MUST be performed canonically as described in [RFC9999]. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. [RFC9999] is a placeholder for "SASLprep: Stringprep profile for user names and passwords". Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 17 13:06:11 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25700 for ; Wed, 17 Nov 2004 13:06:11 -0500 (EST) Received: (qmail 3542 invoked by uid 0); 17 Nov 2004 18:06:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3533 invoked from network); 17 Nov 2004 18:06:10 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by mail.netbsd.org with SMTP; 17 Nov 2004 18:06:10 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2004 10:19:23 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAHI5x3O014742; Wed, 17 Nov 2004 10:05:59 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA19633; Wed, 17 Nov 2004 10:06:08 -0800 (PST) Date: Wed, 17 Nov 2004 10:06:08 -0800 (PST) From: Chris Lonvick To: denis bider cc: ietf-ssh@NetBSD.org Subject: Re: Sending SSH_MSG_GLOBAL_REQUEST as keep-alive to the client In-Reply-To: <000001c4c38c$588bef20$6402a8c0@nucleus> Message-ID: References: <000001c4c38c$588bef20$6402a8c0@nucleus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I didn't see any responses to this. Does anyone have any objection to this being included? Thanks, Chris On Sat, 6 Nov 2004, denis bider wrote: > Hi everyone, > > in our server we have had some problems with detecting broken sessions from > clients in the past - the underlying sockets layer would simply not report > the session being terminated although effectively it was dead - and we > didn't want to solve it with an inactivity timeout because for our purposes > that would have to be too long, so my solution was to implement a sort of > ping feature in the server: the server sends an SSH_MSG_GLOBAL_REQUEST of an > arbitrary (locally defined) type, and expects to receive either SUCCESS or > FAILURE from the client. If neither arrives, and no other data either, the > session is deemed to be broken, and is closed. > > This works fine with all recent clients I have had the chance of testing. > However we have had some reports from customers using older versions of > OpenSSH, which seem to bomb out and disconnect when SSH_MSG_GLOBAL_REQUEST > is received. The misbehaving versions I am aware of include 2.9, a > prehistoric one but still fairly widely deployed, apparently. > > I believe that our server's behavior is correct according to the > specification. [CONNECT] does not explicitly say that global requests should > be handled by the client gracefully, but it does seem to imply so in its > non-biased description of the general nature of the packet (section 4 - > Global Requests): it refers to 'originator' and 'recipient' rather than > client and server, which supports the view that it should be possible for > servers to also send global requests. Indeed, we also use similar > server-side requests for purposes other than broken session detection in our > products. > > But seeing that clients may exist which cannot handle this message, might it > be prudent to add an explicit note in [CONNECT] stating that clients should > handle unrecognized global requests gracefully? The note could be this > (appended to the end of section 4 - Global Requests): > > Note that, while this document defines only request messages sent > by client to server, a server MAY also send global requests to the client. > Such request types may be defined by an external specification, by > local convention or may be sent with merely the intention of eliciting > a response in order to validate that a session is still active. A client > MUST gracefully handle unrecognized global requests by ignoring > them and sending an SSH_MSG_REQUEST_FAILURE response. > > A similar note should then also be appended to the end of section 5.4 - > Channel-Specific Requests. > > Best regards, > > denis > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 17 15:21:46 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08674 for ; Wed, 17 Nov 2004 15:21:45 -0500 (EST) Received: (qmail 26802 invoked by uid 0); 17 Nov 2004 20:21:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26792 invoked from network); 17 Nov 2004 20:21:43 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 17 Nov 2004 20:21:43 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id CB1D2238076; Wed, 17 Nov 2004 21:21:15 +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 7C819211AC1; Wed, 17 Nov 2004 21:21:07 +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 iAHKL7ih028442; Wed, 17 Nov 2004 21:21:07 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iAHKL1w8028439; Wed, 17 Nov 2004 21:21:01 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: Sending SSH_MSG_GLOBAL_REQUEST as keep-alive to the client References: <000001c4c38c$588bef20$6402a8c0@nucleus> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 17 Nov 2004 21:20:51 +0100 In-Reply-To: Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > I didn't see any responses to this. Does anyone have any objection to > this being included? The proposed text is a little too verbose for my taste, but I agree with its contents. > > Note that, while this document defines only request messages sent > > by client to server, a server MAY also send global requests to the client. > > Such request types may be defined by an external specification, by > > local convention or may be sent with merely the intention of eliciting > > a response in order to validate that a session is still active. A client > > MUST gracefully handle unrecognized global requests by ignoring > > them and sending an SSH_MSG_REQUEST_FAILURE response. An attempt at a more concise description: "Note that both client and server MAY send global requests, and the receiver MUST respond appropriately." This sentence can be added to section "4. Global Requests", either at the end of the section, or at the end of the first paragraph. I think it important to make it clear that both ends may send these requests, if that isn't clear already. But I don't think we really need spend a lot of words to explain why that is useful, or provide motivating but non-standard examples. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 17 16:02:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12972 for ; Wed, 17 Nov 2004 16:02:01 -0500 (EST) Received: (qmail 20449 invoked by uid 0); 17 Nov 2004 21:02:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20440 invoked from network); 17 Nov 2004 21:02:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 17 Nov 2004 21:01:59 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 33D782313D1; Wed, 17 Nov 2004 22:01:54 +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 501DF236A9C; Wed, 17 Nov 2004 22:01:47 +0100 (MET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.8.7) with ESMTP id iAHL1jih028899; Wed, 17 Nov 2004 22:01:45 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iAHL1X2a028895; Wed, 17 Nov 2004 22:01:34 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: Bill Sommerfeld , "ietf-ssh@netbsd.org" Subject: Re: core draft issue resolution References: <1100040823.5503.21.camel@unknown.hamachi.org> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 17 Nov 2004 22:01:25 +0100 In-Reply-To: Message-ID: Lines: 76 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > Is there a name and reference for that attack? Also, I had thought that > the reason for keeping 3DES was that it is the "interoperable" algorithm. Another reason is that 3des is believed to be a strong and robust cipher. DES is probably the most well-analyzed ciphers in the world. > The "3des-cbc" cipher is three-key triple-DES > (encrypt-decrypt-encrypt), where the first 8 bytes of the key are > used for the first encryption, the next 8 bytes for the decryption, > and the following 8 bytes for the final encryption. This requires 24 > bytes of key data (of which 168 bits are actually used). To > implement CBC mode, outer chaining MUST be used (i.e., there is only > one initialization vector). This is a block cipher with 8 byte > blocks. This algorithm is defined in [FIPS-46-3]. Note that this > algorithm does not meet the specifications that SSH encryption > algorithms must use keys of 196 bits or more. However, this ^^^ The actual requirement, from section 6.3 of the transport draft, is "All ciphers SHOULD use keys with an effective key length of 128 bits or more." So 3des has sufficiently many key bits on the surface, the problem is that there's a space/time trade-off that lets one brute force 3des by using a large amount of memory and only a 112 bit keysize. Which is slightly smaller than the 128 bits we say we want. This is pretty old, Schneier summarizes it as "triple encryption, with three independent keys, is as secure as one might naïvely expect double encryption to be". He refers to R.C. Merkle and M. Hellman, "On the Security of Multiple Encryption," Communication of the ACM, v. 24, n. 7, 1981, pp 465-467. And Bill is talking about some other, newer, attack, with 2^112 space and 2^56 time; I'm afraid I'm not familiar with that, and I can't say if that is more or less practical than the old attack. 2^112 in either space or time is pretty hard. > How about this: > > Note that the 'plaintext password' value is encoded in ISO-10646 > UTF-8. This encoding MUST be performed canonically as described in > [RFC9999]. It is up to the server how it interprets the password and > validates it against the password database. However, if the client > reads the password in some other encoding (e.g., ISO 8859-1 - ISO > Latin1), it MUST convert the password to ISO-10646 UTF-8 before > transmitting, and the server MUST convert the password to the > encoding used on that system for passwords. Looks ok to me. The message descriptions should probably be updated as well, e.g, Before: 3.1.1 Authentication Requests All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC2279] string service name in US-ASCII string method name in US-ASCII The rest of the packet is method-specific. After: Change the definition of the second field to string user name in UTF-8, normalized according to RFC9999 > [RFC9999] is a placeholder for "SASLprep: Stringprep profile for user > names and passwords". Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Nov 17 17:33:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26875 for ; Wed, 17 Nov 2004 17:33:30 -0500 (EST) Received: (qmail 14697 invoked by uid 0); 17 Nov 2004 22:33:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14668 invoked from network); 17 Nov 2004 22:33:29 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Nov 2004 22:33:29 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAHMXRVu024127; Wed, 17 Nov 2004 15:33:28 -0700 (MST) 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 iAHMXRJd020589; Wed, 17 Nov 2004 17:33:27 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAHMXRe9016197; Wed, 17 Nov 2004 17:33:27 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iAHMXR05016196; Wed, 17 Nov 2004 17:33:27 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: core draft issue resolution From: Bill Sommerfeld To: Chris Lonvick Cc: "ietf-ssh@netbsd.org" In-Reply-To: References: <1100040823.5503.21.camel@unknown.hamachi.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1100730806.16046.43.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 17 Nov 2004 17:33:26 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wed, 2004-11-17 at 12:58, Chris Lonvick quoted me writing: > > NOTE: There is a known attack on 3-key 3DES involving > > 2^112 space and 2^56 time; however, for the purposes of this > > requirement 3DES is considered to be strong enough. this is a typo. i meant 2^112 time, 2^56 space. sorry for any confusion. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 12:54:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26606 for ; Fri, 19 Nov 2004 12:54:44 -0500 (EST) Received: (qmail 24276 invoked by uid 0); 19 Nov 2004 17:54:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24254 invoked from network); 19 Nov 2004 17:54:41 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by mail.netbsd.org with SMTP; 19 Nov 2004 17:54:41 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 19 Nov 2004 09:30:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAJHPn3O026797 for ; Fri, 19 Nov 2004 09:25:49 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA01173 for ; Fri, 19 Nov 2004 09:25:59 -0800 (PST) Date: Fri, 19 Nov 2004 09:25:59 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: New IDs Submitted 2004-nov-19 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I've submitted a new round of IDs for your review. It may take a few days for them to get posted to the repository. As usual, I've placed them along with the xml and the diffs here: http://www.employees.org/~lonvick/secsh-wg/2004-nov-19/ Move up a directory to see the prior submissions. I moved Section 4.5 from [ARCH]-17 to Section 5.3 of [TRANS]-20. The section started this way: Packet Size and Overhead Some readers will worry about the increase in packet size due to new headers, padding, and Message Authentication Code (MAC). The minimum packet size is in the order of 28 bytes (depending on negotiated algorithms). The increase is negligible for large packets, but very I believe that when the writing of these IDs started, there was some concern about this so it was appropriate to place this into the Architecture document. Now, however, it appears out of place anywhere except when talking about SSHv1 which is covered in [TRANS]. I've also added a "Security Considerations" section to [NUMBERS] and have gotten all of the "Conventions Used in This Document" consistent throughout all documents. These are now consistently passing the idnits checker. The next steps are: - All: REVIEW - Chris to clean up the References (Normative and Informative splits) - Everyone should spend some time reviewing the docs - Chris to align the references in [NUMBERS] - Now would be a good time for document review - Chris to remove "Editors' Notes" where appropriate - We need people to review the documents I think that after we get those things done, we should be ready for IESG review. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 16:04:17 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18595 for ; Fri, 19 Nov 2004 16:04:16 -0500 (EST) Received: (qmail 4737 invoked by uid 0); 19 Nov 2004 21:04:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4672 invoked from network); 19 Nov 2004 21:04:07 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2004 21:04:06 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09620; Fri, 19 Nov 2004 15:18:50 -0500 (EST) Message-Id: <200411192018.PAA09620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-08.txt Date: Fri, 19 Nov 2004 15:18:50 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick Filename : draft-ietf-secsh-assignednumbers-08.txt Pages : 20 Date : 2004-11-19 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153345.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 16:04:31 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18641 for ; Fri, 19 Nov 2004 16:04:31 -0500 (EST) Received: (qmail 4749 invoked by uid 0); 19 Nov 2004 21:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4696 invoked from network); 19 Nov 2004 21:04:08 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2004 21:04:08 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09573; Fri, 19 Nov 2004 15:18:40 -0500 (EST) Message-Id: <200411192018.PAA09573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-21.txt Date: Fri, 19 Nov 2004 15:18:40 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-connect-21.txt Pages : 24 Date : 2004-11-19 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153328.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 16:04:44 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18707 for ; Fri, 19 Nov 2004 16:04:44 -0500 (EST) Received: (qmail 4753 invoked by uid 0); 19 Nov 2004 21:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4703 invoked from network); 19 Nov 2004 21:04:09 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2004 21:04:09 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09588; Fri, 19 Nov 2004 15:18:45 -0500 (EST) Message-Id: <200411192018.PAA09588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-18.txt Date: Fri, 19 Nov 2004 15:18:45 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick Filename : draft-ietf-secsh-architecture-18.txt Pages : 29 Date : 2004-11-19 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-18.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-18.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-18.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-18.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153337.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 16:05:05 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18777 for ; Fri, 19 Nov 2004 16:05:04 -0500 (EST) Received: (qmail 4754 invoked by uid 0); 19 Nov 2004 21:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4689 invoked from network); 19 Nov 2004 21:04:07 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2004 21:04:07 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09556; Fri, 19 Nov 2004 15:18:35 -0500 (EST) Message-Id: <200411192018.PAA09556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-23.txt Date: Fri, 19 Nov 2004 15:18:35 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-userauth-23.txt Pages : 16 Date : 2004-11-19 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-23.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-23.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-23.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153320.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 19 16:05:27 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18946 for ; Fri, 19 Nov 2004 16:05:26 -0500 (EST) Received: (qmail 4758 invoked by uid 0); 19 Nov 2004 21:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4711 invoked from network); 19 Nov 2004 21:04:11 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 19 Nov 2004 21:04:10 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09633; Fri, 19 Nov 2004 15:18:56 -0500 (EST) Message-Id: <200411192018.PAA09633@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-20.txt Date: Fri, 19 Nov 2004 15:18:56 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-transport-20.txt Pages : 31 Date : 2004-11-19 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-19153353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-19153353.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Nov 20 03:18:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00605 for ; Sat, 20 Nov 2004 03:18:50 -0500 (EST) Received: (qmail 22321 invoked by uid 0); 20 Nov 2004 08:18:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22312 invoked from network); 20 Nov 2004 08:18:48 -0000 Received: from sparkle.rodents.montreal.qc.ca (216.46.5.7) by mail.netbsd.org with SMTP; 20 Nov 2004 08:18:48 -0000 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA15689; Sat, 20 Nov 2004 03:18:47 -0500 (EST) From: der Mouse Message-Id: <200411200818.DAA15689@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Sat, 20 Nov 2004 02:47:04 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: new drafts Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I just sucked over the new drafts. On diffing them with the previous versions, I see some things of note. In assignednumbers-08, fourth line of 4.3.4: o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction Surely that should be FE000000. The same error is repeated six lines further down. In connect-21, I see the line to 0x0xFDFFFFFF MUST be done through the IETF CONSENSUS method as s/0x0x/0x/, surely. The description surrounding and following the previous line appears to repeat the "0xFF000000 instead of 0xFE000000" error from above, multiple times. Specifically, these lines range of 0xFF000000 to 0xFFFFFFFF, this range will be split in two o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction the range of 0xFF000000 to 0xFEFFFFFF. Naturally, if the server look to me as though they need fixing (even though the first of them makes sense in isolation, in context, I believe it is wrong). In connect-21 again, just before the beginning of 5.3, I see described in [RFC2434]. As is noted, the actual instructions to the IANA is in [SSH-NUMBERS]. There is a plural/singular clash here between "the...instructions" and "is". In transport-20, near line 515, I find implementations MUST allow the algorithm for each direction to be independently selected for each direction, if multiple algorithms are Isn't the repetition of "each direction" redundant here? It reads a little oddly to me, at least. Later in transport-20, around line 550, I see and the following 8 bytes for the final encryption. This requires 24 bytes of key data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [FIPS-46-3]. Note that this algorithm does not meet the specifications that SSH encryption algorithms should use keys of 128 bits or more. However, this It seems..odd..to me to describe an algorithm and note that it uses 168 bits of key data, then note that this does not meet a spec requiring 128 bits or more - it looks to me as though it meets it with 40 bits to spare. (It may not have 128 bits worth of security, but if that's the issue, it seems to me it should be made clear in the text. As it is, it just looks confused - it certainly does use a key "of 128 bits or more". Around line 870, I see authentication" if, in order to prove its autenticity, the server s/autenticity/authenticity/ surely? Somewhere near line 905, I see text (itself unchanged) which says that supported algorithms "MUST be listed in order of preference", but does not make it explicit whether this is most-preferred-first or least-preferred-first. (The first sentence of the next paragraph helps, but I'd prefer to see this change to something like "...order of preference, from most to least".) In userauth-23, lines 208 and 209 are string user name in UTF-8, normalized according to [I-D.ietf-sasl-saslprep] which, while not excessively problematic in isolation, would look significantly better to me in context if the bracketed I-D reference were indented so its open bracket falls under the u of "user name". Similar remarks apply to lines 454 and 455, and lines 539 and 540. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 22 09:20:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01761 for ; Mon, 22 Nov 2004 09:20:20 -0500 (EST) Received: (qmail 27351 invoked by uid 0); 22 Nov 2004 14:20:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27342 invoked from network); 22 Nov 2004 14:20:16 -0000 Received: from ms006msg.fastweb.it (213.140.2.54) by mail.netbsd.org with SMTP; 22 Nov 2004 14:20:16 -0000 Received: from giorgio (2.244.141.98) by ms006msg.fastweb.it (7.0.036) id 419945D800165E00 for ietf-ssh@netbsd.org; Mon, 22 Nov 2004 14:59:27 +0100 Date: Mon, 22 Nov 2004 14:59:27 +0100 (added by postmaster@fastwebnet.it) Message-ID: <005801c4d09b$91bdcd60$1b02a8c0@giorgio> From: "bbband" To: Subject: Richiesta di autorizzazione. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Ai sensi del Testo Unico sulla Privacy e in conformit=E0 con quanto = disposto dal Garante in materia di spamming, Le chiediamo = l'autorizzazione ad inviarLe materiale informativo riguardante "band per = intrattenimento e serate musicali" From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 23 17:33:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14255 for ; Tue, 23 Nov 2004 17:33:33 -0500 (EST) Received: (qmail 12242 invoked by uid 0); 23 Nov 2004 22:33:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12233 invoked from network); 23 Nov 2004 22:33:32 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 23 Nov 2004 22:33:32 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iANMXVVu022228 for ; Tue, 23 Nov 2004 15:33:31 -0700 (MST) Received: from 129.154.65.204 (dhcp-unyc10-65-204.East.Sun.COM [129.154.65.204]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iANMXU8p002904; Tue, 23 Nov 2004 17:33:31 -0500 (EST) Subject: Draft secsh minutes from IETF61 From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Content-Type: text/plain Message-Id: <1101249195.1781.1370.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 23 Nov 2004 17:33:17 -0500 Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Send comments/corrections/omissions to me. Draft minutes from Secure Shell WG meeting at IETF61. We met for an hour on Tuesday, November 9th, 2004. We haven't met in about a year, mostly because the core documents have been delayed by a combination of a busy document editor and a number of process issues connected to the switch from RFC2026 to RFC3667/3668. During these offline discussions it became clear that RFC3667 has a bug in that it does not specify precisely *how* the trademark references it requires should appear in RFCs. The IESG has asked the IPR working group to clarify this question, and we are now waiting for the resolution. We reviewed a short list of relatively minor issues, mostly editorial/clarification; perhaps the most significant is that, at the advice of Sam Hartman (new security AD) we've tentatively decided to reference the SASL stringprep profile (currently in the RFC editor queue) for UTF8-encoded login names and passwords (this is believed to have relatively little or no impact on the deployed base). The specific issue list and proposed resolutions from the meeting have already been sent to the WG, and are repeated at the end of this document. Once the trademark-reference clarification is resolved we believe the documents should be ready to finally pass the IESG. Core Draft Issue summary: (see https://rt.psg.com, username "ietf", password "ietf" for read-only access; contact WG chair for read-write access). ticket 440, 441, 450: close, edits complete. ticket 453: WG chair to identify stable reference for sshv1 (sent to list recently) ticket 454: explicitly grandfather 3DES Editor to insert text equivalent to: NOTE: There is a known attack on 3-key 3DES involving 2^112 space and 2^56 time; however, for the purposes of this requirement 3DES is considered to be strong enough. ticket 461 (implicit server auth): Editor to dig up clarification from list archives, insert into document. ticket 462: different algs in each direction proposal: allow but discourage; Editor to supply text. ticket 463: login timeout proposal: no change to document rationale: - 10 minutes is shorter than typical SMTP listener idle timeout - user interaction is covered in this timeout (entering passwords, etc.,; as a result there may be accessibility requirements for slow typers..) - implementations will likely have knobs to adjust this ticket 464: utf8: utf8 requires input canonicalization; stringprep of usernames and passwords was previously solved by SASL in draft-ietf-sasl-saslprep-10.txt (in RFC Editor Queue, EDIT state) Rather than reinvent the wheel, just cite it. ticket 465: close. was request for consulting ticket 474: x509: remove x509-related text. joe galbraith to supply followup I-D documenting what they do for x509 ticket 460, 601: no consensus on list. flipped coin, heads for "group2", tails for "group14", came up tails will stick with diffie-hellman-group14-sha1 From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Nov 25 06:19:22 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29828 for ; Thu, 25 Nov 2004 06:19:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 61C7A5264; Thu, 25 Nov 2004 11:19:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mail.netbsd.org (Postfix) with ESMTP id 170B05238 for ; Thu, 25 Nov 2004 11:19:14 +0000 (UTC) Received: from marketmailer ([69.28.232.110]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I7Q001TQFF3FT@VL-MO-MR001.ip.videotron.ca> for ietf-ssh@netbsd.org; Thu, 25 Nov 2004 06:18:47 -0500 (EST) Date: Thu, 25 Nov 2004 06:18:45 -0500 From: TechSatDepot Subject: : Free-2-Air Services SuperHardwareDevices: To: TesterMemberSupport Message-id: <384-2200411425111845321@marketmailer> Organization: TechSatDepot MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7BIT Dear DssDepot Customers And Members Aboard Get All You Need Right Here www.dssdepot.org We wish to thank all of you for your patronage. You have been very selective when deciding on a one stop source for all your testing goodies and chose www.dssdepot.org . We have a great array of new products that we added to the site and many more to come over time, we continue to grow due to our wonderful customers who keep us alive and soaring above the competition, knocking all others out of the water,be sure to check out the NEW Free-2-Air Systems That will most definetely satisy your needs... We do our best to check the market daily and lower our prices whenever we see another site getting close to ours in tag value. The great thing about all of our products is that we are the only site that actually HAND TESTS all orders before they leave our warehouse and on the way to your door.There is no other site that can sell below cost of all others and hand test each and every piece before it is sent to the client, we pride ourselves in doing this and it has earned us a ton of respect within the testing community.From Atmegas-2-Locks-2-Digital Recievers we are sure you will not be dissatisfied. Ordering with us is safe, our site is run completely from China and anything entered into the site, such as private information travels through overseas channels and does not take place on North American grounds. Our fulfillment centers make sure that your packages are shipped discreetly and well protected from potential damage that might occur if otherwise poorly packaged. Take advantage of our live Sales Staff that work very hard in helping you the end customer in choosing what is right for you as we are honoured to help in any way possible. Shop in full confidence with www.dssdepot.org and you can be assured that your shopping experience will be a pleasure and will have you coming back for more. We also encourage you all to join our Private membership area COMING SOON and get support on the fly when you need it, so what are you waiting for, drop by to say hello and do some virtual window shopping and get what your TV needs Today and get your self running again in full confidence... Sales Staff Priority www.dssdepot.org From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Nov 26 08:44:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08900 for ; Fri, 26 Nov 2004 08:44:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A88C35518; Fri, 26 Nov 2004 13:42:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4]) by mail.netbsd.org (Postfix) with ESMTP id DEF955452 for ; Fri, 26 Nov 2004 13:42:23 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by repulse.cnchost.com id IAA21941; Fri, 26 Nov 2004 08:42:21 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: SFTP text open and EBCDIC Date: Fri, 26 Nov 2004 14:42:18 +0100 Message-ID: <001301c4d3bd$c0ae3ae0$0a0a0a0a@nucleus> 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.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit From draft-ietf-secsh-filexfer-06: SSH_FXF_TEXT Indicates that the server should treat the file as text and convert it to the canonical newline convention in use. (See Determining Server Newline Convention. (Section 4.3) Can the client connecting to an EBCDIC server and using this SSH_FXF_TEXT file open flag also expect that the server will translate from ASCII to EBCDIC, and vice versa? If not, why not? If yes - caveats, details? Has this been discussed? denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 11:44:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07560 for ; Mon, 29 Nov 2004 11:44:40 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B6A595406; Mon, 29 Nov 2004 16:44:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id B3B6853B1 for ; Mon, 29 Nov 2004 16:44:08 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id 20F7F76C05; Mon, 29 Nov 2004 11:13:16 -0500 (EST) To: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com Subject: Normalization of passwords in SASL and SSH From: Sam Hartman Date: Mon, 29 Nov 2004 11:13:15 -0500 Message-ID: <87653o3a78.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi. A discussion in the IETF 61 secsh meeting re-opened the issue of how to handle password normalization for passwords received by the server. The ssh protocol had adopted a significantly different solution to this problem than the sasl plain mechanism. This concerns me; I want to either solve the problem of password normalization in a consistent manner or to understand why the ssh requirements are different than the sasl requirements. As a result of that discussion I've been talking to several people about the issue. Now I think I understand things well enough to propose a solution to both working groups. First, I'd like to revisit the motivation behind normalization. There are a variety of semantically equivalent sequences of characters that have multiple representations in Unicode. The simplest example is accented characters where one code point represents the accented character and another series of code points represents the semantically equivalent character plus a combining accent. Other examples exist. Which sequence of code points gets used tends to depend on the input method used to enter the characters. That means that it tends to depend on the OS, application and version of software used. So, telling users to type their password the same way is not a sufficient answer to guarantee that you end up with the same sequence of code points; the user may not have a choice of input methods. The IDN working group developed an architecture called Stringprep which allows protocol-specific profiles of rules for mapping some semantically equivalent strings into the same sequences of code points. It is not perfect; as with any normalization discussion the question of where to draw boundaries between equivalence classes is difficult. The SASL working group developed a profile of Stringprep called Saslprep; this profile is targeted at simple usernames and passwords. Everyone I talked to over the past two weeks believes that if you are going to normalize passwords for ssh or the SASL plain mechanism, Saslprep is a reasonable profile to use. Saslprep has the advantage of already being in the rfc editor queue. We'd like to tell people to normalize passwords all the time. If they actually did that then it would improve interoperability and the user experience. However most systems we use do not store plaintext passwords. Instead, they tend to store some function of the password or to call out to something like PAM or RADIUS to do password authentication. Normalizing a password before you check it but not when new passwords are stored may be very problematic. For example, consider an environment where the input method tends to produce separate base character and accent code points. Without normalization, when passwords containing accents are stored, any computed hash will include both the base character and the accent. However Saslprep will normalize such a string to use a single code point when possible. Thus in such an environment, normalizing only when checking passwords would decrease interoperability because accented characters would never work in passwords. I'm proposing the following approach to address this situation. For both ssh and sasl plain, normalization should be done on the server if at all. Only the server knows what the password store technology in use is. We recommend normalizing when passwords can be normalized both as they are set and as they are compared. In environments where passwords may not be normalized as they are set, implementations may want to try comparing against both the normalized and supplied form of the password. Doing so may improve interoperability because it means there is a password that if successfully set will work when used with any input method. However in many environments such as when a server calls out to PAM or RADIUS, even the server cannot try multiple passwords without incrementing failed password counters or having other similar side effects. Here are some examples of how I see these recommendations working. A sasl plain implementation that manages its own password database would always normalize when setting a password and when checking passwords. A Windows ssh service that managed its own authentication database and provided the only tool for setting passwords would normalize both for setting passwords and for comparing them. An ssh implementation that used a unix password file would not normalize passwords for comparison. This is true even if the ssh implementation sometimes was used to set passwords, because the passwd command could be used independently of the ssh implementation. An ssh implementation that called out to PAM or RADIUS would not normalize passwords. However some of the modules eventually doing the password comparison might well do normalization if appropriate for the password store in question. Does this seem like a reasonable approach to people? If so, we can work on appropriate text. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 11:49:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07952 for ; Mon, 29 Nov 2004 11:49:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EF7A653EE; Mon, 29 Nov 2004 16:49:03 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id B86C853B1 for ; Mon, 29 Nov 2004 16:49:00 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2004 09:52:51 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iATGjqf3019248 for ; Mon, 29 Nov 2004 08:45:53 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17388 for ; Mon, 29 Nov 2004 08:45:52 -0800 (PST) Date: Mon, 29 Nov 2004 08:45:52 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: new drafts In-Reply-To: <200411200818.DAA15689@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200411200818.DAA15689@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I appreciate the review. Comments in-line. On Sat, 20 Nov 2004, der Mouse wrote: > I just sucked over the new drafts. On diffing them with the previous > versions, I see some things of note. > > In assignednumbers-08, fourth line of 4.3.4: > > o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction > > Surely that should be FE000000. The same error is repeated six lines > further down. > > In connect-21, I see the line > > to 0x0xFDFFFFFF MUST be done through the IETF CONSENSUS method as > > s/0x0x/0x/, surely. > > The description surrounding and following the previous line appears to > repeat the "0xFF000000 instead of 0xFE000000" error from above, > multiple times. Specifically, these lines > > range of 0xFF000000 to 0xFFFFFFFF, this range will be split in two > o The range of 0xFF000000 to 0xFEFFFFFF is to be used in conjunction > the range of 0xFF000000 to 0xFEFFFFFF. Naturally, if the server > > look to me as though they need fixing (even though the first of them > makes sense in isolation, in context, I believe it is wrong). OK. (I really liked it a lot better when I was mistakenly using a BYTE rather than a uint32. :) > > In connect-21 again, just before the beginning of 5.3, I see > > described in [RFC2434]. As is noted, the actual instructions to the > IANA is in [SSH-NUMBERS]. > > There is a plural/singular clash here between "the...instructions" and > "is". OK. > > In transport-20, near line 515, I find > > implementations MUST allow the algorithm for each direction to be > independently selected for each direction, if multiple algorithms are > > Isn't the repetition of "each direction" redundant here? It reads a > little oddly to me, at least. OK. > > Later in transport-20, around line 550, I see > > and the following 8 bytes for the final encryption. This requires 24 > bytes of key data (of which 168 bits are actually used). To > implement CBC mode, outer chaining MUST be used (i.e., there is only > one initialization vector). This is a block cipher with 8 byte > blocks. This algorithm is defined in [FIPS-46-3]. Note that this > algorithm does not meet the specifications that SSH encryption > algorithms should use keys of 128 bits or more. However, this > > It seems..odd..to me to describe an algorithm and note that it uses 168 > bits of key data, then note that this does not meet a spec requiring > 128 bits or more - it looks to me as though it meets it with 40 bits to > spare. (It may not have 128 bits worth of security, but if that's the > issue, it seems to me it should be made clear in the text. As it is, > it just looks confused - it certainly does use a key "of 128 bits or > more". I added text and referenced [SCHNEIER]. > > Around line 870, I see > > authentication" if, in order to prove its autenticity, the server > > s/autenticity/authenticity/ surely? Yup. I ran all of the IDs back through a spell checker and corrected a few more that had crept in. > > Somewhere near line 905, I see text (itself unchanged) which says that > supported algorithms "MUST be listed in order of preference", but does > not make it explicit whether this is most-preferred-first or > least-preferred-first. (The first sentence of the next paragraph > helps, but I'd prefer to see this change to something like "...order of > preference, from most to least".) OK. > > In userauth-23, lines 208 and 209 are > > string user name in UTF-8, normalized according to > [I-D.ietf-sasl-saslprep] > > which, while not excessively problematic in isolation, would look > significantly better to me in context if the bracketed I-D reference > were indented so its open bracket falls under the u of "user name". > > Similar remarks apply to lines 454 and 455, and lines 539 and 540. Those will go away when the reference becomes an RFC - which should be soon as it's in the queue. I also aligned all of the references in [NUMBERS] which were out of whack. The group had described "name-list" as the way to comma-separate lists in [ARCH] Section 5. However, "name-list"s were not used in any other document. "string"s were used with additional text saying that they were to be "comma-separated strings". I _BELIEVE_ that I've found all of the appropriate places (in [TRANS] and [USERAUTH]) and have converted them to "name-list"s. I would really appreciate a review of those to make sure that the things I converted really should be "name-list"s rather than "string"s. I modified the "identification string" from the line explanation to the format used throughout the rest of the documents. This is in [TRANS] Section 4.2. Is this acceptable: string "SSH-" string protoversion string "-" string softwareversion string (Space character) only used if 'comments' are used in the identification string string comments CR LF - Optional string Since the protocol being defined in this set of documents is version 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is OPTIONAL. If the 'comments' string is included, a 'space' character (denoted above as SP, "", ASCII 32) MUST separate the 'softwareversion' and 'comments' strings. The identification MUST be terminated by a single Carriage Return and a single Line Feed character (ASCII (denoted above as "", ASCII 13 and 10, respectively). Implementors who wish to maintain compatibility with older, undocumented versions of this protocol, may want to process the identification string without expecting the presence of the carriage return character for reasons described in Section 5 of this document. The null character MUST NOT be sent. The maximum length of the string is 255 characters, including the Carriage Return and Line Feed. The files (.txt, .xml) and the diffs (.html) are all to be found here: http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/ I just submitted new versions which - since the ID Editors are getting really speedy - may appear later today. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 12:43:59 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13473 for ; Mon, 29 Nov 2004 12:43:59 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 69AED537F; Mon, 29 Nov 2004 17:43:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mail.netbsd.org (Postfix) with ESMTP id 776375338 for ; Mon, 29 Nov 2004 17:43:54 +0000 (UTC) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYpHB-000150-00 for ; Mon, 29 Nov 2004 18:25:25 +0100 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 18:25:25 +0100 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 18:25:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-ssh@NetBSD.org From: Simon Josefsson Subject: Re: Normalization of passwords in SASL and SSH Date: Mon, 29 Nov 2004 18:25:13 +0100 Lines: 33 Message-ID: References: <87653o3a78.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:23:041129:gmane.ietf.sasl::Y881FnhiJReaBiKR:00000000000000000000000000000000000000000000004pvA X-Hashcash: 1:23:041129:gmane.ietf.secsh::VibljafZZVF0IQGo:0000000000000000000000000000000000000000000007UOa User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:Psp7NJtLMy7HItKVd6UO/S4mBfU= Cc: ietf-sasl@imc.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sam Hartman writes: > I'm proposing the following approach to address this situation. For > both ssh and sasl plain, normalization should be done on the server if > at all. Only the server knows what the password store technology in > use is. For what it's worth, I support this view. I'd like to add one other advantage, that I feel is a strong argument for this approach. If client-side normalization is deployed based on SASLprep in SSH, upgrading to a new revision of SASLprep will be more difficult. This is because the server may need to know which SASLprep revision is used, to select the hashed password that was prepared using the proper SASLprep version. That could be solved by signaling the SASLprep version in SSH, but I'd prefer to avoid that, if possible. Further, if the revised SASLprep turn out to be backwards incompatible, which doesn't seem unlikely (given the normalization flaw in Unicode 3.2), the server would receive SASLprep(password). Computing SASLprep2(SASLprep(x)) may not in general be equal to SASLprep2(x). Having normalization occur on the server also make it easier to switch from SASLprep to something else in the future. In my opinion, sending SASLprep data over the wire should always be avoided, in favor of sending Unicode code points. I think we should get used to the idea of a SASLprep2, and design protocols that use SASLprep with this in mind. Thanks, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 12:48:33 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13851 for ; Mon, 29 Nov 2004 12:48:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5822853E2; Mon, 29 Nov 2004 17:48:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id CDA6151B5 for ; Mon, 29 Nov 2004 17:48:26 +0000 (UTC) Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 01924FA5A7; Mon, 29 Nov 2004 18:29:32 +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 DB004BDDAF; Mon, 29 Nov 2004 18:29:28 +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 iATHTSih003474; Mon, 29 Nov 2004 18:29:28 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iATHTL9b003471; Mon, 29 Nov 2004 18:29:21 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Sam Hartman Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 29 Nov 2004 18:29:20 +0100 In-Reply-To: <87653o3a78.fsf@luminous.mit.edu> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-lysator_fetto_1.2 (2004-01-11) on fetto.lysator.liu.se X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Sam Hartman writes: > An ssh implementation that used a unix password file would not > normalize passwords for comparison. This is true even if the ssh > implementation sometimes was used to set passwords, because the passwd > command could be used independently of the ssh implementation. I'd like to this description that I think the only sane way to support passwords beyond ascii on unix systems is to use normalization (either to utf8 + normalization, or to some system-wide fixed 8-bit character set. The passwd program, and other programs handling passwords, must be fixed to do the right thing. > Does this seem like a reasonable approach to people? If so, we can > work on appropriate text. If I understand your proposal, as it applies to ssh, you're suggesting that we should 1. Strike the new text on normalization, in effect reverting to what was in older drafts (e.g. draft-ietf-secsh-userauth-18.txt says "Note that the password is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database."). 2. Add some new text saying that we recommend that systems supporting non-ascii passwords always normalize passwords and usernames whenever they are added to the database, or compared (with or without hashing) to existing entries in the database. Am I missing something? To me, (2) seems slightly out of scope for the secsh wg, but I won't object if such a recommendation is added, provided the text can be kept short and to the point. As for (1), I don't care very much either way. Normalizing identifiers in wire formats is generally a good thing to do, but in this case, it doesn't really solve the problems with non-normalized entries in various legacy user databases. I'll also note that what you're proposing now, appeared to be the wg consensus up to quite recently. From the ssh point of view, I think it is very important to keep changes minimal, so that we can get our severly delayed spec published at last. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 15:00:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25001 for ; Mon, 29 Nov 2004 15:00:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C92BF54C5; Mon, 29 Nov 2004 20:00:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from main.gmane.org (main.gmane.org [80.91.229.2]) by mail.netbsd.org (Postfix) with ESMTP id 57C0451C9 for ; Mon, 29 Nov 2004 20:00:35 +0000 (UTC) Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CYrhJ-0004z0-00 for ; Mon, 29 Nov 2004 21:00:33 +0100 Received: from c494102a.s-bi.bostream.se ([217.215.27.65]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 21:00:33 +0100 Received: from jas by c494102a.s-bi.bostream.se with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Nov 2004 21:00:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-ssh@NetBSD.org From: Simon Josefsson Subject: Re: Normalization of passwords in SASL and SSH Date: Mon, 29 Nov 2004 21:00:14 +0100 Lines: 27 Message-ID: References: <87653o3a78.fsf@luminous.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c494102a.s-bi.bostream.se OpenPGP: id=0xB565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:23:041129:gmane.ietf.sasl::Rlsme+5oHJPj5aNv:00000000000000000000000000000000000000000000005xDP X-Hashcash: 1:23:041129:gmane.ietf.secsh::aOJ2dEeJz+VMu35D:000000000000000000000000000000000000000000000DAB0 User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:+/Q8MBUm0nsxW2zrfSe0m/6YJIU= Cc: ietf-sasl@imc.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit nisse@lysator.liu.se (Niels Möller) writes: > 2. Add some new text saying that we recommend that systems supporting > non-ascii passwords always normalize passwords and usernames > whenever they are added to the database, or compared (with or > without hashing) to existing entries in the database. I believe the part about storing normalized strings in databases is a poor recommendation. If the password is stored, then I believe it would be better to store the unprepared string than the prepared string. Otherwise, there is an upgrade problem when SASLprep2 is released. Of course, if the database store a hashed password, then there is no choice, and you have to prepare it before hashing. I would recommend doing normalization when storing strings, to provide early feedback for invalid strings, but store the unprepared string. During validation, you can either prepare the string (using the then-current preparation algorithm), or you could use a prepared copy of the password stored in the database, for efficiency. In the latter case, the database should also remember which algorithm was used to prepare the prepared string (SASLprep, SASLprep2, etc). Thanks, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:08:38 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04793 for ; Mon, 29 Nov 2004 16:08:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 25AF5545A; Mon, 29 Nov 2004 21:08:34 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id D2B6351B5 for ; Mon, 29 Nov 2004 21:08:32 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id A852BE0063; Mon, 29 Nov 2004 15:39:09 -0500 (EST) To: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> From: Sam Hartman Date: Mon, 29 Nov 2004 15:39:09 -0500 In-Reply-To: (Niels =?iso-8859-1?q?M=F6ller's?= message of "29 Nov 2004 18:29:20 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>>> "Niels" == Niels Möller writes: Niels> If I understand your proposal, as it applies to ssh, you're Niels> suggesting that we should Niels> 1. Strike the new text on normalization, in effect Niels> reverting to what was in older drafts Niels> (e.g. draft-ietf-secsh-userauth-18.txt says "Note that the Niels> password is encoded in ISO-10646 UTF-8. It is up to the Niels> server how it interprets the password and validates it Niels> against the password database."). Niels> 2. Add some new text saying that we recommend that systems Niels> supporting non-ascii passwords always normalize passwords Niels> and usernames whenever they are added to the database, or Niels> compared (with or without hashing) to existing entries in Niels> the database. And say that ssh implementations that both store the passwords and compare them SHOULD use saslprep for normalization. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:15:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05581 for ; Mon, 29 Nov 2004 16:15:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D161854A9; Mon, 29 Nov 2004 21:15:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id 6E69551B5 for ; Mon, 29 Nov 2004 21:15:14 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 46E80E0063; Mon, 29 Nov 2004 16:15:26 -0500 (EST) To: Simon Josefsson Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> From: Sam Hartman Date: Mon, 29 Nov 2004 16:15:26 -0500 In-Reply-To: (Simon Josefsson's message of "Mon, 29 Nov 2004 21:00:14 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>>>> "Simon" == Simon Josefsson writes: Simon> nisse@lysator.liu.se (Niels Möller) writes: >> 2. Add some new text saying that we recommend that systems >> supporting non-ascii passwords always normalize passwords and >> usernames whenever they are added to the database, or compared >> (with or without hashing) to existing entries in the database. Simon> I believe the part about storing normalized strings in Simon> databases is a poor recommendation. Simon> If the password is stored, then I believe it would be Simon> better to store the unprepared string than the prepared Simon> string. Otherwise, there is an upgrade problem when Simon> SASLprep2 is released. Note that the sasl working group considered Simon's argument and ended up disagreeing with him. As I recall, Simon was concerned about cases where either bugs in Unicode (which do exist) or explicit changes to saslprep 2 designed to be incompatible would create a situation where saslprep2(foo) was not the same as saslprep1(foo). The stringprep specification has a reasonable versioning model. It is generally true that if applying one version of a stringprep profile to some string succeeds with unassigned code points prohibited, then later versions of the same profile will yield the same result. Simon's concern is that generally true is not the same as always true. The SASL working group did not decide to adopt this interpretation. I don't think a consensus was declared on the reasoning. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:17:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06027 for ; Mon, 29 Nov 2004 16:17:32 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9A4715515; Mon, 29 Nov 2004 21:17:28 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 2312851B5 for ; Mon, 29 Nov 2004 21:17:26 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27142; Mon, 29 Nov 2004 15:17:02 -0500 (EST) Message-Id: <200411292017.PAA27142@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-09.txt Date: Mon, 29 Nov 2004 15:17:01 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick Filename : draft-ietf-secsh-assignednumbers-09.txt Pages : 20 Date : 2004-11-29 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152306.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152306.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:17:43 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06068 for ; Mon, 29 Nov 2004 16:17:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B36D8551C; Mon, 29 Nov 2004 21:17:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 71A4F550F for ; Mon, 29 Nov 2004 21:17:27 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27119; Mon, 29 Nov 2004 15:16:51 -0500 (EST) Message-Id: <200411292016.PAA27119@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-24.txt Date: Mon, 29 Nov 2004 15:16:51 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-userauth-24.txt Pages : 16 Date : 2004-11-29 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-24.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-24.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-24.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152246.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:18:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06112 for ; Mon, 29 Nov 2004 16:18:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E402F54FD; Mon, 29 Nov 2004 21:17:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 9516F54FD for ; Mon, 29 Nov 2004 21:17:32 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27134; Mon, 29 Nov 2004 15:16:57 -0500 (EST) Message-Id: <200411292016.PAA27134@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-22.txt Date: Mon, 29 Nov 2004 15:16:57 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-connect-22.txt Pages : 24 Date : 2004-11-29 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-22.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-22.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-22.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152256.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 16:18:18 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06179 for ; Mon, 29 Nov 2004 16:18:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A7A1B5517; Mon, 29 Nov 2004 21:17:43 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id AB7035510 for ; Mon, 29 Nov 2004 21:17:36 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27153; Mon, 29 Nov 2004 15:17:06 -0500 (EST) Message-Id: <200411292017.PAA27153@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-21.txt Date: Mon, 29 Nov 2004 15:17:05 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-transport-21.txt Pages : 32 Date : 2004-11-29 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-21.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-29152323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152323.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 17:27:16 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20618 for ; Mon, 29 Nov 2004 17:27:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2F635522F; Mon, 29 Nov 2004 22:26:24 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from cz.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by mail.netbsd.org (Postfix) with ESMTP id B0B165185 for ; Mon, 29 Nov 2004 22:26:22 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id A6CBFE0063; Mon, 29 Nov 2004 17:26:33 -0500 (EST) To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> <1101766668.3018.164.camel@thunk> From: Sam Hartman Date: Mon, 29 Nov 2004 17:26:33 -0500 In-Reply-To: <1101766668.3018.164.camel@thunk> (Bill Sommerfeld's message of "Mon, 29 Nov 2004 17:17:49 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Bill" == Bill Sommerfeld writes: Bill> (WG chair hat off. just my questions) Why should these Bill> proposed rules apply only to passwords and not also to login Bill> names? It seems like the core justification for server side Bill> normalization -- that they're often stored in database Bill> maintained by a subsystem not under the control of the ssh Bill> server implementor -- also applies to usernames. SASL believes they should apply to usernames as well. Kerberos has adopted the same position. Bill> Is it ever the case that normalization functions would Bill> change the human-readable representation meaningfully? Bill> Examples? I'd expect a normalization profile for passwords to remove direction markers. I'd expect it to map all forms of white space together. You'd lose the difference between say a 1 em space and u+0x20, which would be visible. I'd say anything outside of these sorts of examples would be a bad idea in a stringprep profile, especially for a security application. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 17:42:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22139 for ; Mon, 29 Nov 2004 17:42:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 758BA51F6; Mon, 29 Nov 2004 22:42:41 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mail.netbsd.org (Postfix) with ESMTP id E1E24516E for ; Mon, 29 Nov 2004 22:42:39 +0000 (UTC) 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 iATMHopv024923; Mon, 29 Nov 2004 14:17:50 -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 iATMHnJd011060; Mon, 29 Nov 2004 17:17:49 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iATMHndZ003594; Mon, 29 Nov 2004 17:17:49 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.1+Sun/8.13.1/Submit) id iATMHnUA003593; Mon, 29 Nov 2004 17:17:49 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Normalization of passwords in SASL and SSH From: Bill Sommerfeld To: Sam Hartman Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com In-Reply-To: <87653o3a78.fsf@luminous.mit.edu> References: <87653o3a78.fsf@luminous.mit.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1101766668.3018.164.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 29 Nov 2004 17:17:49 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit (WG chair hat off. just my questions) Why should these proposed rules apply only to passwords and not also to login names? It seems like the core justification for server side normalization -- that they're often stored in database maintained by a subsystem not under the control of the ssh server implementor -- also applies to usernames. Is it ever the case that normalization functions would change the human-readable representation meaningfully? Examples? If there are multiple available normalization functions it would seem that you might be able to either (a) try several, accept if one matches, and/or (b) "renormalize" already normalized strings using alternate functions, in which case erroneous client-side normalization could well be undone or worked around by the server. - Bill From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 18:50:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27732 for ; Mon, 29 Nov 2004 18:50:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 95CE2529A; Mon, 29 Nov 2004 23:50:22 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from goliath.cnchost.com (goliath.cnchost.com [207.155.252.47]) by mail.netbsd.org (Postfix) with ESMTP id 0C643521E for ; Mon, 29 Nov 2004 23:50:21 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by goliath.cnchost.com id RAA19387; Mon, 29 Nov 2004 17:26:41 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Chris Lonvick'" , Subject: RE: new drafts Date: Mon, 29 Nov 2004 23:26:38 +0100 Message-ID: <000201c4d662$7f06fd00$0a0a0a0a@nucleus> 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.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit This looks very wrong. string = word32 len, byte[len] data There are no word32 components in the version string. The version string is actually not a 'string' as defined in [SSH-ARCH]. Its format doesn't fit in with the rest of the SSH2 protocol in any way, hence the different definition. The below proposal is rather confusing. I think the way it was was fine. Best regards, denis > I modified the "identification string" from the line > explanation to the format used throughout the rest of the > documents. This is in [TRANS] Section 4.2. Is this acceptable: > > string "SSH-" > string protoversion > string "-" > string softwareversion > string (Space character) only used if 'comments' > are used in the identification string > string comments CR LF - Optional > string > > Since the protocol being defined in this set of documents > is version > 2.0, the 'protoversion' MUST be "2.0". The 'comments' string is > OPTIONAL. If the 'comments' string is included, a 'space' > character > (denoted above as SP, "", ASCII 32) MUST separate the > 'softwareversion' and 'comments' strings. The > identification MUST be > terminated by a single Carriage Return and a single Line Feed > character (ASCII (denoted above as "", ASCII 13 and 10, > respectively). Implementors who wish to maintain > compatibility with > older, undocumented versions of this protocol, may want to process > the identification string without expecting the presence of the > carriage return character for reasons described in Section > 5 of this > document. The null character MUST NOT be sent. The maximum length > of the string is 255 characters, including the Carriage Return and > Line Feed. > > > > The files (.txt, .xml) and the diffs (.html) are all to be found here: > http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/ > > I just submitted new versions which - since the ID Editors > are getting really speedy - may appear later today. > > Thanks, > Chris > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Nov 29 19:44:47 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03030 for ; Mon, 29 Nov 2004 19:44:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1F7EB51C4; Tue, 30 Nov 2004 00:44:44 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id DAEB6516E for ; Tue, 30 Nov 2004 00:44:42 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path jacobn@chiark.greenend.org.uk) id 1CYv3m-0006I8-00 for ietf-ssh@netbsd.org; Mon, 29 Nov 2004 23:35:58 +0000 Date: Mon, 29 Nov 2004 23:35:58 +0000 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: new drafts Message-ID: <20041129233558.GA20722@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list (Oops, didn't spot this until after the drafts were published.) Chris Lonvick writes: > I modified the "identification string" from the line explanation to the > format used throughout the rest of the documents. This is in [TRANS] > Section 4.2. Is this acceptable: > > string "SSH-" > string protoversion [...] `string' is defined in the architecture draft as having a uint32 length field prepended, which these components of the version string do not have, so this is wrong. I don't see anything wrong with the text in -20. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 30 01:47:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29361 for ; Tue, 30 Nov 2004 01:47:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 949DB51A4; Tue, 30 Nov 2004 06:47:46 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from pretender.boolean.net (router.boolean.net [198.144.206.49]) by mail.netbsd.org (Postfix) with ESMTP id CFB855187 for ; Tue, 30 Nov 2004 06:47:43 +0000 (UTC) Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.10/8.12.11) with ESMTP id iAU6Q9Zv021305; Tue, 30 Nov 2004 06:26:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.1.2.0.0.20041129221117.02e251c0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 29 Nov 2004 22:26:45 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: Normalization of passwords in SASL and SSH Cc: ietf-ssh@NetBSD.org, ietf-sasl@imc.org, housley@vigilsec.com In-Reply-To: <6.1.2.0.0.20041129202632.02da7f60@127.0.0.1> References: <6.1.2.0.0.20041129202632.02da7f60@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ietf-ssh-owner@NetBSD.org Precedence: list These are the changes (in unified diff form) I propose to make to the sasl-plain I-D to address this concern. Note that change impacts authcids as well as passwords. -- Kurt The presented authentication identity and password strings are not -to be compared directly with stored strings. The server SHALL first -prepare authentication identity and password strings using the -[SASLPrep] profile of the [StringPrep] algorithm. Per Section 7 -of [StringPrep], unassigned code points may appear in prepared -presented (query) strings but are prohibited in stored strings. If -preparation fails or results in an empty string, verification SHALL -fail. If the server stores only the hash of expected string, the -string MUST be prepared before generation of the hash. +to be compared directly with stored strings. The server SHOULD +first prepare authentication identity and password strings using +the [SASLPrep] profile of the [StringPrep] algorithm as detailed +below. When preparing using [SASLprep] or other [StringPrep] based +algorithm, per Section 7 of [StringPrep], unassigned code points +may appear in prepared presented (query) strings but are prohibited +in stored strings. If only the output of a non-invertible function +of expected string is stored, the string MUST be prepared before +input to that function. + +The SASLprep preparation is recommended to improve the likelihood +that comparisons behave in an expected manner. It is not mandatory +to allow the server to employ other preparation algorithms (including +none) as necessary to interoperate with external systems. + +Regardless of the preparation algorithm, if preparation fails or +results in an empty string, verification SHALL fail. At 08:27 PM 11/29/2004, Sam Hartman wrote: >Hi. A discussion in the IETF 61 secsh meeting re-opened the issue of >how to handle password normalization for passwords received by the >server. The ssh protocol had adopted a significantly different >solution to this problem than the sasl plain mechanism. This concerns >me; I want to either solve the problem of password normalization in a >consistent manner or to understand why the ssh requirements are >different than the sasl requirements. > >As a result of that discussion I've been talking to several people >about the issue. Now I think I understand things well enough to >propose a solution to both working groups. > >First, I'd like to revisit the motivation behind normalization. There >are a variety of semantically equivalent sequences of characters that >have multiple representations in Unicode. The simplest example is >accented characters where one code point represents the accented >character and another series of code points represents the >semantically equivalent character plus a combining accent. Other >examples exist. Which sequence of code points gets used tends to >depend on the input method used to enter the characters. That means >that it tends to depend on the OS, application and version of software >used. So, telling users to type their password the same way is not a >sufficient answer to guarantee that you end up with the same sequence >of code points; the user may not have a choice of input methods. > >The IDN working group developed an architecture called Stringprep >which allows protocol-specific profiles of rules for mapping some >semantically equivalent strings into the same sequences of code >points. It is not perfect; as with any normalization discussion the >question of where to draw boundaries between equivalence classes is >difficult. The SASL working group developed a profile of Stringprep >called Saslprep; this profile is targeted at simple usernames and >passwords. Everyone I talked to over the past two weeks believes that >if you are going to normalize passwords for ssh or the SASL plain >mechanism, Saslprep is a reasonable profile to use. Saslprep has the >advantage of already being in the rfc editor queue. > >We'd like to tell people to normalize passwords all the time. If they >actually did that then it would improve interoperability and the user >experience. However most systems we use do not store plaintext >passwords. Instead, they tend to store some function of the password >or to call out to something like PAM or RADIUS to do password >authentication. Normalizing a password before you check it but not >when new passwords are stored may be very problematic. > >For example, consider an environment where the input method tends to >produce separate base character and accent code points. Without >normalization, when passwords containing accents are stored, any >computed hash will include both the base character and the accent. >However Saslprep will normalize such a string to use a single code >point when possible. Thus in such an environment, normalizing only >when checking passwords would decrease interoperability because >accented characters would never work in passwords. > >I'm proposing the following approach to address this situation. For >both ssh and sasl plain, normalization should be done on the server if >at all. Only the server knows what the password store technology in >use is. We recommend normalizing when passwords can be normalized >both as they are set and as they are compared. In environments where >passwords may not be normalized as they are set, implementations may >want to try comparing against both the normalized and supplied form of >the password. Doing so may improve interoperability because it means >there is a password that if successfully set will work when used with >any input method. However in many environments such as when a server >calls out to PAM or RADIUS, even the server cannot try multiple >passwords without incrementing failed password counters or having >other similar side effects. Here are some examples of how I see these >recommendations working. > >A sasl plain implementation that manages its own password database >would always normalize when setting a password and when checking >passwords. > >A Windows ssh service that managed its own authentication database >and provided the only tool for setting passwords would normalize both >for setting passwords and for comparing them. > >An ssh implementation that used a unix password file would not >normalize passwords for comparison. This is true even if the ssh >implementation sometimes was used to set passwords, because the passwd >command could be used independently of the ssh implementation. > >An ssh implementation that called out to PAM or RADIUS would not >normalize passwords. However some of the modules eventually doing the >password comparison might well do normalization if appropriate for the >password store in question. > >Does this seem like a reasonable approach to people? If so, we can >work on appropriate text. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Nov 30 15:11:41 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28993 for ; Tue, 30 Nov 2004 15:11:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5D6C452FF; Tue, 30 Nov 2004 20:11:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 6CA4851AC for ; Tue, 30 Nov 2004 20:11:33 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28957; Tue, 30 Nov 2004 15:11:25 -0500 (EST) Message-Id: <200411302011.PAA28957@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-19.txt Date: Tue, 30 Nov 2004 15:11:25 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick Filename : draft-ietf-secsh-architecture-19.txt Pages : 29 Date : 2004-11-30 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-19.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-19.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-19.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-30111445.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-19.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-30111445.I-D@ietf.org> --OtherAccess-- --NextPart--