From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 13 12:10: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 MAA13153 for ; Mon, 13 Sep 2004 12:10:16 -0400 (EDT) Received: (qmail 10297 invoked by uid 605); 13 Sep 2004 16:10:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10265 invoked from network); 13 Sep 2004 16:10:09 -0000 Received: from sj-iport-4.cisco.com (171.68.10.86) by mail.netbsd.org with SMTP; 13 Sep 2004 16:10:09 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 13 Sep 2004 08:42:42 -0700 X-BrightmailFiltered: true 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 i8DFebwW011593 for ; Mon, 13 Sep 2004 08:40:37 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA04478 for ; Mon, 13 Sep 2004 08:40:37 -0700 (PDT) Date: Mon, 13 Sep 2004 08:40:37 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: query about draft-ietf-secsh-connect-19.txt In-Reply-To: Message-ID: References: <20040813130951.GA27573@quick.recoil.org> 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, Refreshing this discussion: On Fri, 13 Aug 2004 14:09:51 +0100 Anil Madhavapeddy wrote: In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference to: byte SSH_MSG_GLOBAL_REQUEST_SUCCESS uint32 port that was bound on the server which should probably be "SSH_MSG_REQUEST_SUCCESS" The other odd thing about this packet is that it's the only one which doesn't encode the request type in which it's in response to. This form would appear to make more sense: byte SSH_MSG_REQUEST_SUCCESS string "tcpip-forward" uint32 port that was bound on the server As this is the only packet for which the contents of the packet can vary without a "constant field" on which to make the decision of which further packets to inspect. In other cases, e.g. SSH_MSG_CHANNEL_REQUEST, the decision to decode further fields can be taken by lookinng at the first string argument. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk On Thu, 19 Aug 2004, [iso-8859-1] Niels M=F6ller wrote: > Anil Madhavapeddy writes: > > > In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference > > to: > > > > byte SSH_MSG_GLOBAL_REQUEST_SUCCESS > > uint32 port that was bound on the server > > > > which should probably be "SSH_MSG_REQUEST_SUCCESS" > > I think you're right. > > > The other odd thing about this packet is that it's the only one which > > doesn't encode the request type in which it's in response to. > > The *reply* messages in general includes *no* request type identifier: > > byte SSH_MSG_REQUEST_SUCCESS > ..... response specific data > -- > byte SSH_MSG_REQUEST_FAILURE > -- > byte SSH_MSG_CHANNEL_SUCCESS > uint32 recipient_channel > -- > byte SSH_MSG_CHANNEL_FAILURE > uint32 recipient_channel > > To make it possible for the originator of a request to identify to > which request each reply refers to, it is required that replies to > SSH_MSG_GLOBAL_REQUESTS must be sent in the same order as the > corresponding request messages. > > And for channel requests, replies that relate to the same channel must > also be replied to in the right order (channel requests for *distinct* > channels can be replied to out-of-order, at least that's my > understanding of things). > > Regards, > /Niels > On Mon, 23 Aug 2004, Jacob Nevins wrote: > Niels Moller writes: > > To make it possible for the originator of a request to identify to > > which request each reply refers to, it is required that replies to > > SSH_MSG_GLOBAL_REQUESTS must be sent in the same order as the > > corresponding request messages. > > > > And for channel requests, replies that relate to the same channel must > > also be replied to in the right order (channel requests for *distinct* > > channels can be replied to out-of-order, at least that's my > > understanding of things). > > I can't find language spelling out these requirements in connect-19 > after a brief skim through. Perhaps some should be added? (Would current > implementations meet these requirements?) > It appears that some changes need to be made to [connect]. 1) In Section 7.1 s/SSH_MSG_GLOBAL_REQUEST_SUCCESS/SSH_MSG_REQUEST_SUCCESS/ in the spot noted by Anil. 2) Make a decision that [connect] must either a) mandate that replies to channel requests MUST be in order, or b) change the protocol to have the responses identify the channel. I'm betting that this group will opt for (a). If so, could someone please propose some text. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 16 13:19: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 NAA28006 for ; Thu, 16 Sep 2004 13:19:05 -0400 (EDT) Received: (qmail 1930 invoked by uid 605); 16 Sep 2004 17:19:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1921 invoked from network); 16 Sep 2004 17:19:02 -0000 Received: from olly.nbg-hannover.de (62.181.135.97) by mail.netbsd.org with SMTP; 16 Sep 2004 17:19:02 -0000 Received: (from uucp@localhost) by olly.nbg-hannover.de (8.11.7p1+Sun/8.11.7) id i8GGBwX02207 for ; Thu, 16 Sep 2004 18:11:58 +0200 (MEST) Received: from mailscan3.internet.nbg-hannover.de(172.17.10.223) by olly.nbg-hannover.de via csmap (V6.0) id srcAAA_WaWte; Thu, 16 Sep 04 18:11:58 +0200 Received: from esafe8.sn-neu-h.finanzit.sko.de (es-tp2-02.d.sn.finanzit.sko.de [172.22.198.194]) by mailscanner1 (Postfix) with SMTP id 33308A4082 for ; Thu, 16 Sep 2004 18:08:52 +0200 (CEST) Received: from mailscan1.i016.dvg.sko.de ([IP=172.17.10.223]) by eSafe SMTP Relay 1095325651; Thu Sep 16 18:07:34 2004 Received: from notes-spksal.i055.dvg.sko.de (s155ln01.i055.dvg.sko.de [6.55.4.158]) by mailscan1.i016.dvg.sko.de (Postfix) with ESMTP id C4642A4082 for ; Thu, 16 Sep 2004 18:08:51 +0200 (CEST) Message-ID: Date: Thu, 16 Sep 2004 18:06:40 +0200 To: ietf-ssh@NetBSD.org From: Autoreply@Spk-SAL.de Subject: Re: Mail Delivery (failure thomas.gruhlke@spk-sal.de) X-MIMETrack: Serialize by Router on S155LN01/Sparkasse Stade-Altes Land/DE(Release 5.0.11|July 24, 2002) at 16.09.2004 18:06:41 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable Sehr geehrte Kundin, sehr geehrter Kunde, vielen Dank f=FCr Ihre soeben eingegangene E-Mail. Sollte Ihre E-Mail ein= en legitimationspflichtigen Auftrag (z. B. =DCberweisung, Wertpapierauftrag, etc.) enthalten, bitten wir Sie um Verst=E4ndnis, dass wir zu Ihrer eigen= en Sicherheit diesen Auftrag nicht ausf=FChren k=F6nnen, da eine F=E4lschungssicherheit bei E-Mails nicht gew=E4hrleistet werden kann. F=FCr eine Vielzahl von unterschriftspflichtigen Auftr=E4gen k=F6nnen wir= Ihnen entsprechend gesicherte Alternativen anbieten. Wir beraten Sie gerne. Mit freundlichen Gr=FC=DFen Ihre Sparkasse Stade-Altes Land From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 16 22:04:33 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 WAA08485 for ; Thu, 16 Sep 2004 22:04:32 -0400 (EDT) Received: (qmail 28930 invoked by uid 605); 17 Sep 2004 02:04:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28918 invoked from network); 17 Sep 2004 02:04:28 -0000 Received: from geronimo.parthe.isp.9tel.net (62.62.156.21) by mail.netbsd.org with SMTP; 17 Sep 2004 02:04:28 -0000 Received: from angus.celte.isp.9tel.net (angus.celte.isp.9tel.net [212.30.113.118]) by geronimo.parthe.isp.9tel.net (Postfix) with ESMTP id 3A68A1101E9 for ; Fri, 17 Sep 2004 04:04:12 +0200 (CEST) From: To: ietf-ssh@NetBSD.org Date: 17 Sep 2004 04:04:21 +0200 Message-ID: <03aa22104021194ANGUS@angus.celte.isp.9tel.net> Subject: Nondeliverable mail MIME-Version: 1.0 Content-Type: Multipart/mixed; boundary="ANGUSHZXY'l7ju=E" Sender: ietf-ssh-owner@NetBSD.org Precedence: list --ANGUSHZXY'l7ju=E ------Transcript of session follows ------- 4.6060800@sereso.com The user's email name is not found. --ANGUSHZXY'l7ju=E Content-Type: message/rfc822; charset=us-ascii Received: from gaoh.parthe.isp.9tel.net ([62.62.156.24]) by angus.celte.isp.9tel.net with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 17 Sep 2004 04:04:21 +0200 Received: from sereso.com (tiridate.parthe.isp.9tel.net [62.62.156.30]) by gaoh.parthe.isp.9tel.net (Postfix) with ESMTP id 2683C26C00F for <4.6060800@sereso.com>; Fri, 17 Sep 2004 04:03:47 +0200 (CEST) From: ietf-ssh@netbsd.org To: 4.6060800@sereso.com Subject: Server Error (4.6060800@sereso.com) Date: Fri, 17 Sep 2004 10:04:51 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20040917020347.2683C26C00F@gaoh.parthe.isp.9tel.net> Return-Path: ietf-ssh@netbsd.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Message d'alerte virale envoyé par 9Telecom Found virus WORM_NETSKY.P in file msg5477.pif The uncleanable file is deleted. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Mail Delivery Error - This mail contains unicode characters ------------- failed message ------------- C.ß1F0UY_R|!E>kZxS69|w'MGy?oUIGßKsy~s9v1eqä WW-07HdBM.xu+ZäXC&mF'>mävERqg&UerSYUs15)e7A 5x+OöiIzF$)A*YN7htWcßHhq$+BsfLq,E5hX7P0j3('ü&8Tßs:XcN|yPHS4E9m'dk%u5_f.5( Z' The message has been sent as a binary attachment. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Message d'alerte virale envoyé par 9Telecom msg5477.pif is removed from here because it contains a virus. --------------------------------------------------------- ------=_NextPart_000_0016----=_NextPart_000_0016-- --ANGUSHZXY'l7ju=E-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 18 17:37: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 RAA17543 for ; Sat, 18 Sep 2004 17:37:53 -0400 (EDT) Received: (qmail 22892 invoked by uid 605); 18 Sep 2004 21:37:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22883 invoked from network); 18 Sep 2004 21:37:49 -0000 Received: from wellington.concentric.net (HELO wellington.cnchost.com) (207.155.252.14) by mail.netbsd.org with SMTP; 18 Sep 2004 21:37:49 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by wellington.cnchost.com id QAA11890; Sat, 18 Sep 2004 16:27:03 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Chris Lonvick'" , Subject: RE: query about draft-ietf-secsh-connect-19.txt Date: Sat, 18 Sep 2004 22:26:58 +0200 Message-ID: <000201c49dbd$da55c390$6302a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > It appears that some changes need to be made to [connect]. ... > 2) Make a decision that [connect] must either > a) mandate that replies to channel requests MUST be in order, or > b) change the protocol to have the responses identify the channel. > I'm betting that this group will opt for (a). If so, could=20 > someone please propose some text. Beg pardon? Responses do identify the channel. > byte SSH_MSG_CHANNEL_SUCCESS > uint32 recipient_channel > -- > byte SSH_MSG_CHANNEL_FAILURE > uint32 recipient_channel [CONNECT] should mandate that replies to channel requests need not be in = order overall, but must be in order for each channel. Replies to global = requests must be in order overall. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 20 11:27:14 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 LAA12022 for ; Mon, 20 Sep 2004 11:27:13 -0400 (EDT) Received: (qmail 25402 invoked by uid 605); 20 Sep 2004 15:27:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25393 invoked from network); 20 Sep 2004 15:27:11 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 20 Sep 2004 15:27:11 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Sep 2004 08:09:23 +0000 X-BrightmailFiltered: true 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 i8KEvY7Y009019; Mon, 20 Sep 2004 07:57:35 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA11828; Mon, 20 Sep 2004 07:57:34 -0700 (PDT) Date: Mon, 20 Sep 2004 07:57:34 -0700 (PDT) From: Chris Lonvick To: denis bider , ietf-ssh@NetBSD.org Subject: RE: query about draft-ietf-secsh-connect-19.txt In-Reply-To: <000201c49dbd$da55c390$6302a8c0@Nucleus> Message-ID: References: <000201c49dbd$da55c390$6302a8c0@Nucleus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, On Sat, 18 Sep 2004, denis bider wrote: > > It appears that some changes need to be made to [connect]. > ... > > 2) Make a decision that [connect] must either > > a) mandate that replies to channel requests MUST be in order, or > > b) change the protocol to have the responses identify the channel. > > I'm betting that this group will opt for (a). If so, could > > someone please propose some text. > > > Beg pardon? > > Responses do identify the channel. > > > > byte SSH_MSG_CHANNEL_SUCCESS > > uint32 recipient_channel > > -- > > byte SSH_MSG_CHANNEL_FAILURE > > uint32 recipient_channel > > > [CONNECT] should mandate that replies to channel requests need not be in order > overall, but must be in order for each channel. Replies to global requests must > be in order overall. OK. I've added text to the bottom of Section 4 "Global Requests" as follows: In general, the reply messages do not include request type identifiers. To make it possible for the originator of a request to identify to which request each reply refers, it is REQUIRED that replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as the corresponding request messages. For channel requests, replies that relate to the same channel MUST also be replied to in the right order. However, channel requests for distinct channels MAY be replied to out-of-order. Is this acceptable? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 20 12:40:19 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 MAA19071 for ; Mon, 20 Sep 2004 12:40:19 -0400 (EDT) Received: (qmail 14406 invoked by uid 605); 20 Sep 2004 16:40:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14396 invoked from network); 20 Sep 2004 16:40:15 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 Sep 2004 16:40:15 -0000 Received: from [127.0.0.1] ([127.0.0.1] verified) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6642971; Mon, 20 Sep 2004 09:40:13 -0600 Message-ID: <414EFA05.3070203@vandyke.com> Date: Mon, 20 Sep 2004 09:40:53 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040920) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick CC: denis bider , ietf-ssh@NetBSD.org Subject: Re: query about draft-ietf-secsh-connect-19.txt References: <000201c49dbd$da55c390$6302a8c0@Nucleus> 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 Chris Lonvick wrote: > Hi, > > On Sat, 18 Sep 2004, denis bider wrote: > > >>>It appears that some changes need to be made to [connect]. >> >>... >> >>>2) Make a decision that [connect] must either >>> a) mandate that replies to channel requests MUST be in order, or >>> b) change the protocol to have the responses identify the channel. >>>I'm betting that this group will opt for (a). If so, could >>>someone please propose some text. >> >> >>Beg pardon? >> >>Responses do identify the channel. >> >> >> >>> byte SSH_MSG_CHANNEL_SUCCESS >>> uint32 recipient_channel >>>-- >>> byte SSH_MSG_CHANNEL_FAILURE >>> uint32 recipient_channel >> >> >>[CONNECT] should mandate that replies to channel requests need not be in order >>overall, but must be in order for each channel. Replies to global requests must >>be in order overall. > > > > OK. I've added text to the bottom of Section 4 "Global Requests" as > follows: > > In general, the reply messages do not include request type > identifiers. To make it possible for the originator of a request to > identify to which request each reply refers, it is REQUIRED that > replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as > the corresponding request messages. For channel requests, replies > that relate to the same channel MUST also be replied to in the right > order. However, channel requests for distinct channels MAY be > replied to out-of-order. > > > Is this acceptable? This sounds good to me. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 20 15:21: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 PAA03189 for ; Mon, 20 Sep 2004 15:21:09 -0400 (EDT) Received: (qmail 25075 invoked by uid 605); 20 Sep 2004 19:21:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25066 invoked from network); 20 Sep 2004 19:21:07 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 20 Sep 2004 19:21:07 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 90547E4810; Mon, 20 Sep 2004 20:48:07 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id F05C9B67FB; Mon, 20 Sep 2004 20:48:02 +0200 (MEST) 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 i8KIm2ih013300; Mon, 20 Sep 2004 20:48:02 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8KIlv1k013297; Mon, 20 Sep 2004 20:47:57 +0200 (MEST) 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: query about draft-ietf-secsh-connect-19.txt References: <000201c49dbd$da55c390$6302a8c0@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: 20 Sep 2004 20:47:57 +0200 In-Reply-To: Message-ID: Lines: 27 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: > OK. I've added text to the bottom of Section 4 "Global Requests" as > follows: > > In general, the reply messages do not include request type > identifiers. To make it possible for the originator of a request to > identify to which request each reply refers, it is REQUIRED that > replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as > the corresponding request messages. For channel requests, replies > that relate to the same channel MUST also be replied to in the right > order. However, channel requests for distinct channels MAY be > replied to out-of-order. > > > Is this acceptable? It's ok. I think it could be improved slightly by striking the first sentence. (The request type is mostly irrelevant when it comes to disambiguating replies, as one may well have several outstanding requests of the same type; I think mentioning it as a possible alternative will just add more confusion). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 20 15:29:04 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 PAA04337 for ; Mon, 20 Sep 2004 15:29:03 -0400 (EDT) Received: (qmail 28955 invoked by uid 605); 20 Sep 2004 19:29:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28922 invoked from network); 20 Sep 2004 19:29:00 -0000 Received: from fork.recoil.org (194.70.3.132) by mail.netbsd.org with SMTP; 20 Sep 2004 19:29:00 -0000 Received: (qmail 12468 invoked by uid 10000); 20 Sep 2004 19:02:17 -0000 Date: Mon, 20 Sep 2004 20:02:17 +0100 From: Anil Madhavapeddy To: Chris Lonvick Cc: denis bider , ietf-ssh@NetBSD.org Subject: Re: query about draft-ietf-secsh-connect-19.txt Message-ID: <20040920190217.GA24623@fork.recoil.org> References: <000201c49dbd$da55c390$6302a8c0@Nucleus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Sep 20, 2004 at 07:57:34AM -0700, Chris Lonvick wrote: > > In general, the reply messages do not include request type > identifiers. To make it possible for the originator of a request to > identify to which request each reply refers, it is REQUIRED that > replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as > the corresponding request messages. For channel requests, replies > that relate to the same channel MUST also be replied to in the right > order. However, channel requests for distinct channels MAY be > replied to out-of-order. Looks fine to me. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 20 15:39: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 PAA05004 for ; Mon, 20 Sep 2004 15:39:21 -0400 (EDT) Received: (qmail 6525 invoked by uid 605); 20 Sep 2004 19:39:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6516 invoked from network); 20 Sep 2004 19:39:20 -0000 Received: from warspite.concentric.net (HELO warspite.cnchost.com) (207.155.248.9) by mail.netbsd.org with SMTP; 20 Sep 2004 19:39:20 -0000 Received: from Nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by warspite.cnchost.com id OAA26798; Mon, 20 Sep 2004 14:59:08 -0400 (EDT) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Chris Lonvick'" Cc: Subject: RE: query about draft-ietf-secsh-connect-19.txt Date: Mon, 20 Sep 2004 20:59:04 +0200 Message-ID: <002901c49f43$e7c7c230$6302a8c0@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 In-Reply-To: <414EFA05.3070203@vandyke.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > > OK. I've added text to the bottom of Section 4 "Global Requests" as > > follows: > > > > In general, the reply messages do not include request type > > identifiers. To make it possible for the originator of > a request to > > identify to which request each reply refers, it is REQUIRED that > > replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the > same order as > > the corresponding request messages. For channel > requests, replies > > that relate to the same channel MUST also be replied to > in the right > > order. However, channel requests for distinct channels MAY be > > replied to out-of-order. > > > > > > Is this acceptable? > > This sounds good to me. Sounds good to me too. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 23 23:16: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 XAA16641 for ; Thu, 23 Sep 2004 23:16:22 -0400 (EDT) Received: (qmail 20184 invoked by uid 605); 24 Sep 2004 03:16:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20093 invoked from network); 24 Sep 2004 03:16:18 -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; 24 Sep 2004 03:16:18 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Sep 2004 20:18:49 -0700 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 i8O3GFSI017746 for ; Thu, 23 Sep 2004 20:16:16 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id UAA05119 for ; Thu, 23 Sep 2004 20:16:15 -0700 (PDT) Date: Thu, 23 Sep 2004 20:16:15 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Message Numbers and Disconnect Codes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I need to bring this up again. :) In the last go-around, I made the mistake of saying that the Disconnection Codes 'reason code' value was a byte. The document clearly states, however, that it is a uint32. My bad. Since we agreed that the high 16 values (what we said were going to be 239..254) would be reserved for local use, I'd like to suggest that this be retained. This would mean that the values of 0x00000001..0xFFFFFFE9 will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will be reserved for local use. I've also found a couple of more items that need to be listed in [NUMBERS]. Including the Disconnection Codes we have: Disconnection Codes from Section 11 in [TRANS] byte SSH_MSG_DISCONNECT uint32 reason code string description [RFC3629] string language tag [RFC3066] 'reason code' values of 1..15 are assigned Channel Connection Failure from Section 5.1 in [CONNECT] byte SSH_MSG_CHANNEL_OPEN_FAILURE uint32 recipient channel uint32 reason code string additional text string language tag 'reason code' values of 1..4 are assigned Extended Channel Data Transfer from Section 5.2 in [CONNECT] byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient_channel uint32 data_type_code string data 'data_type_code' 1 is assigned Unless anyone has a better plan, I'll suggest that the actual codes follow the same pattern: values 0x00000001..0xFFFFFFE9 are assigned by the IANA values 0xFFFFFFF0..0xFFFFFFFF are locally assigned. I'd also like to suggest that we change the name of 'data_type_code' to 'reason code'. Also for consistency, I'd like to make all of the additional descriptions become 'description' - and remove 'additional text' and 'data'. Are there any objections or comments on these? Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 00:01:10 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 AAA19446 for ; Fri, 24 Sep 2004 00:01:09 -0400 (EDT) Received: (qmail 19402 invoked by uid 605); 24 Sep 2004 04:01:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19393 invoked from network); 24 Sep 2004 04:01:09 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 24 Sep 2004 04:01:09 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6662355; Thu, 23 Sep 2004 22:01:08 -0600 Message-ID: <41539C07.7050809@vandyke.com> Date: Thu, 23 Sep 2004 22:01:11 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick CC: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes 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 Chris Lonvick wrote: > Hi Folks, > > I need to bring this up again. :) In the last go-around, I made the > mistake of saying that the Disconnection Codes 'reason code' value was a > byte. The document clearly states, however, that it is a uint32. My bad. > Since we agreed that the high 16 values (what we said were going to be > 239..254) would be reserved for local use, I'd like to suggest that this > be retained. This would mean that the values of 0x00000001..0xFFFFFFE9 > will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will > be reserved for local use. > > I've also found a couple of more items that need to be listed in > [NUMBERS]. Including the Disconnection Codes we have: > > > Disconnection Codes from Section 11 in [TRANS] > byte SSH_MSG_DISCONNECT > uint32 reason code > string description [RFC3629] > string language tag [RFC3066] > 'reason code' values of 1..15 are assigned > > > Channel Connection Failure from Section 5.1 in [CONNECT] > byte SSH_MSG_CHANNEL_OPEN_FAILURE > uint32 recipient channel > uint32 reason code > string additional text > string language tag > 'reason code' values of 1..4 are assigned > > > Extended Channel Data Transfer from Section 5.2 in [CONNECT] > byte SSH_MSG_CHANNEL_EXTENDED_DATA > uint32 recipient_channel > uint32 data_type_code > string data > 'data_type_code' 1 is assigned > > > Unless anyone has a better plan, I'll suggest that the actual codes follow > the same pattern: > values 0x00000001..0xFFFFFFE9 are assigned by the IANA > values 0xFFFFFFF0..0xFFFFFFFF are locally assigned. > > I'd also like to suggest that we change the name of 'data_type_code' to > 'reason code'. Also for consistency, I'd like to make all of the > additional descriptions become 'description' - and remove 'additional > text' and 'data'. SSH_MSG_CHANNEL_EXTENDED_DATA is dissimilar to the other two... it is used for sending stderr data. The data is not a description of any particular event defined in the protocol, but is whatever arbitrary data is being sent on stderr. data_type_code describes the data as being stderr data, and provides a mechanism for future data types to be used. (Personally, if I had it to do all over again, I'd be tempted to skip the data_type_code...) But regardless, I think changing the name of those two fields would be bad. Indeed, however, 'additional text' should be changed to description, and the same RFC references included on 'description' and on 'language tag' as for disconnect. (That is another differnece for EXTENDED_DATA: the data is __not__ UTF8, and there isn't a language tag.) As for the ranges, with a 32 bit address space, 16 codes seems a bit stingy... I'd be tempted to say if the high bit is set is locally assigned; however, I do not feel strongly about it. (I can imagine needing more the 16 codes; and i can imagine future IETF work needing all 256 code points in an 8 bit space... but, I can't imagine out growing 2 billion codes, nor can I imagine future IETF work needing more than 2 billion codes.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 02:27: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 CAA12642 for ; Fri, 24 Sep 2004 02:27:09 -0400 (EDT) Received: (qmail 3835 invoked by uid 605); 24 Sep 2004 06:27:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3826 invoked from network); 24 Sep 2004 06:27:03 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 24 Sep 2004 06:27:03 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 65F3A1F272B; Fri, 24 Sep 2004 07:58:05 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 009566C007; Fri, 24 Sep 2004 07:58:06 +0200 (MEST) Date: Fri, 24 Sep 2004 07:58:03 +0200 (CEST) From: Martin Forssen Subject: Re: Message Numbers and Disconnect Codes To: galb-list@vandyke.com Cc: clonvick@cisco.com, ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040924055807.009566C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 23 Sep, Joseph Galbraith wrote: > As for the ranges, with a 32 bit address space, 16 codes seems > a bit stingy... I'd be tempted to say if the high bit is set > is locally assigned; however, I do not feel strongly about it. I agree that 16 seems a bit small. But reserving half the space is probably overkill. How about making 0xFF000000-0xFFFFFFFF locally assigned? /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 02:52: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 CAA13795 for ; Fri, 24 Sep 2004 02:52:19 -0400 (EDT) Received: (qmail 20325 invoked by uid 605); 24 Sep 2004 06:52:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20316 invoked from network); 24 Sep 2004 06:52:17 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 06:52:17 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id C15E81DEFD6; Fri, 24 Sep 2004 08:52:15 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id A92201DEFD6; Fri, 24 Sep 2004 08:52:11 +0200 (MEST) 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 i8O6qBih007471; Fri, 24 Sep 2004 08:52:11 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8O6q6DL007468; Fri, 24 Sep 2004 08:52:06 +0200 (MEST) 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: Message Numbers and Disconnect Codes 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: 24 Sep 2004 08:52:05 +0200 In-Reply-To: Message-ID: Lines: 35 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: > Since we agreed that the high 16 values (what we said were going to be > 239..254) would be reserved for local use, I'd like to suggest that this > be retained. This would mean that the values of 0x00000001..0xFFFFFFE9 > will be assigned by the IANA and the values of 0xFFFFFFF0..0xFFFFFFFF will > be reserved for local use. I think it's somewhat silly to reserve only 16 values out of such a large space. MaF's suggestion, that 0xFF000000-0xFFFFFFFF be reserved for local use, sounds more reasonable to me. > I'd also like to suggest that we change the name of 'data_type_code' to > 'reason code'. I don't think that's appropriate, the meaning is quite different. See below. > Also for consistency, I'd like to make all of the > additional descriptions become 'description' - and remove 'additional > text' and 'data'. Changing "additional text" to "description" is fine. Changing "data", in SSH_MSG_CHANNEL_EXTENDED_DATA, is not. Note that while SSH_MSG_DISCONNECT and SSH_MSG_CHANNEL_OPEN_FAILURE are reports various protocol related errors, SSH_MSG_CHANNEL_EXTENDED_DATA is different, it's a segment of a continous stream of data. SSH_MSG_CHANNEL_EXTENDED_DATA is almost like the plain SSH_MSG_CHANNEL_DATA, only difference is that it carries one additional id saying which of potentially many auxillary streams the data belongs to. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 03:17:35 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 DAA15145 for ; Fri, 24 Sep 2004 03:17:34 -0400 (EDT) Received: (qmail 4283 invoked by uid 605); 24 Sep 2004 07:17:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4273 invoked from network); 24 Sep 2004 07:17:32 -0000 Received: from av9-1-sn3.vrr.skanova.net (81.228.9.185) by mail.netbsd.org with SMTP; 24 Sep 2004 07:17:32 -0000 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7E010384F5; Fri, 24 Sep 2004 08:52:11 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6E1223807E; Fri, 24 Sep 2004 08:52:11 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 1725637E4A; Fri, 24 Sep 2004 08:52:11 +0200 (CEST) Message-ID: <4153C494.7000605@streamsec.se> Date: Fri, 24 Sep 2004 08:54:12 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Forssen Cc: galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> In-Reply-To: <20040924055807.009566C007@shala.firedoor.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Martin Forssen wrote: > I agree that 16 seems a bit small. But reserving half the space is > probably overkill. How about making 0xFF000000-0xFFFFFFFF locally > assigned? Please also note that "locally assigned" can (and probably must) be defined. There are at least three levels that have to be accounted for: 1. The SSH library. It might contain custom extensions that need their own error codes, such as key establishment schemes defined in accordance with SSH-ARCH on the name@host form. 2. The application software. The application server might for example implement application specific sub systems that in some circumstances have to send error codes over the SSH transport level. 3. The specific host From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 04:52:13 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 EAA21742 for ; Fri, 24 Sep 2004 04:52:13 -0400 (EDT) Received: (qmail 24120 invoked by uid 605); 24 Sep 2004 08:52:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24111 invoked from network); 24 Sep 2004 08:52:07 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 08:52:07 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 254051E2C63; Fri, 24 Sep 2004 10:52:06 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id C5D3E1E2C5E; Fri, 24 Sep 2004 10:52:03 +0200 (MEST) 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 i8O8q3ih008665; Fri, 24 Sep 2004 10:52:03 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8O8pwZ8008662; Fri, 24 Sep 2004 10:51:58 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: =?iso-8859-1?q?Henrick_Hellstr=F6m?= Cc: Martin Forssen , galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 24 Sep 2004 10:51:56 +0200 In-Reply-To: <4153C494.7000605@streamsec.se> Message-ID: Lines: 51 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 Henrick Hellström writes: > Martin Forssen wrote: > > > I agree that 16 seems a bit small. But reserving half the space is > > probably overkill. How about making 0xFF000000-0xFFFFFFFF locally > > assigned? > > Please also note that "locally assigned" can (and probably must) be > defined. There are at least three levels that have to be accounted for: I think, quite strongly, that such substructure should be out of scope for the core drafts. It would be quite a lot of work to sort the details of that out properly, and I don't see any huge win in doing that work. And it's way too late to introduce entirely new concepts into the specification. Also note that we are primarily concerned with the protocol on the wire; how protocol constants are used or misused inside a host is mostly out of scope. > 1. The SSH library. [...] > 2. The application software. [...] > 3. The specific host My understanding of "locally assigned" numbers is: Use of locally assigned numbers is purely an implementation and configuration issue of the local ssh implementation. The phrase "local ssh implementation" includes *all* software that speaks the ssh protocols, no matter how that body of code is divided into libraries and applications. If you write an ssh library, you are free to reserve some subrange of the locally assigned space for the library's internal use, and leave the rest for use by applications (I don't see how locally defined constants are useful for the library or application, but I imagine you see some use for it). That subdivision will then be a part of your library API. If you want to standardize that subdivision, the right place would be a ssh library API specification. Which would most likely be of informational status rather than standards track. You may of course get into conflicts with other implementation that uses locally assigned numbers differently. But that's the entire point of the locally assigned numbers; to allow for some local uncoordinated experimentation, without interoperability concerns. Whenever you want interoperability on the wire between different implementations, the right thing to do is to allocate a new standard number. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 05:34: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 FAA24121 for ; Fri, 24 Sep 2004 05:34:44 -0400 (EDT) Received: (qmail 18697 invoked by uid 605); 24 Sep 2004 09:34:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18685 invoked from network); 24 Sep 2004 09:34:41 -0000 Received: from av11-1-sn2.hy.skanova.net (81.228.8.183) by mail.netbsd.org with SMTP; 24 Sep 2004 09:34:41 -0000 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id CCB9738232; Fri, 24 Sep 2004 11:34:39 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id B69D53822A; Fri, 24 Sep 2004 11:34:39 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6605737E43; Fri, 24 Sep 2004 11:34:38 +0200 (CEST) Message-ID: <4153EAA8.2080308@streamsec.se> Date: Fri, 24 Sep 2004 11:36:40 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Martin Forssen , galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> 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: > I think, quite strongly, that such substructure should be out of scope > for the core drafts. Fair enough, but I suggest that there at least should be stipulated in the specification that locally assigned disconnect codes MUST NOT be sent by standard protocol features. A situation where Sue sends a local disconnect code 0xFF000000 to Carol, but Sue and Carol do not assign the same meaning to it, should never occur. (Note: A similar problem occurs in e.g. TLS. The cipher suites 0xFF00 to 0xFFFF are application specific, but there is no way for the peers to tell each other if they share the same implementation.) The appropriate way to avoid such situations ought to be to stipulate that locally assigned disconnect codes must only be sent by locally specified protocol features (e.g. keyestablishment@host, subsystem@host etc). This should entail that Sue will only send a specific local disconnect code to Carol, if Carol has already told Sue that she supports the locally specified protocol feature that assigns the code. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 07:11:28 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 HAA00712 for ; Fri, 24 Sep 2004 07:11:28 -0400 (EDT) Received: (qmail 15983 invoked by uid 605); 24 Sep 2004 11:11:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15964 invoked from network); 24 Sep 2004 11:11:22 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 11:11:22 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 67D671C7515; Fri, 24 Sep 2004 13:07:58 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id C2D581DD716; Fri, 24 Sep 2004 13:07:55 +0200 (MEST) 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 i8OB7tih009783; Fri, 24 Sep 2004 13:07:55 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8OB7m5Z009780; Fri, 24 Sep 2004 13:07:48 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: =?iso-8859-1?q?Henrick_Hellstr=F6m?= Cc: Martin Forssen , galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 24 Sep 2004 13:07:45 +0200 In-Reply-To: <4153EAA8.2080308@streamsec.se> Message-ID: Lines: 39 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 Henrick Hellström writes: > Niels Möller wrote: > > I think, quite strongly, that such substructure should be out of scope > > for the core drafts. > > Fair enough, but I suggest that there at least should be stipulated in > the specification that locally assigned disconnect codes MUST NOT be > sent by standard protocol features. Right, locally defined numbers should not appear on the wire unless you have somehow agreed with the receiver what they should mean. One example where that can be used safely on the wire, is if you receive a CHANNEL_OPEN request for some locally defined channel type "foo-channel@lysator.liu.se", then you can safely reply with a CHANNEL_OPEN_FAILURE and any locally defined reason code associated with the specification for that channel type. > The appropriate way to avoid such situations ought to be to stipulate > that locally assigned disconnect codes must only be sent by locally > specified protocol features (e.g. keyestablishment@host, > subsystem@host etc). That is sane advice. But it is also an important part of the idea of the locally assigned numbers, that you are allowed to use these numbers in anyway you please, as long as you know what you're doing, and don't expect interoperability with other standards compliant implementations. The easiest way to sum this up is to say that use of locally defined numbers is *not* standardized in any way, that they can be used only under prior agreement between the involved ssh installations, and that any agreements on how they are to be used are out of scope for the specification. Is there some standard phraseology for this? It's surely not unique for ssh. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 07:49: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 HAA03027 for ; Fri, 24 Sep 2004 07:49:04 -0400 (EDT) Received: (qmail 14572 invoked by uid 605); 24 Sep 2004 11:49:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14553 invoked from network); 24 Sep 2004 11:49:01 -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; 24 Sep 2004 11:49:01 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Sep 2004 04:51:37 -0700 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 i8OBmwSI000425 for ; Fri, 24 Sep 2004 04:48:59 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA09310 for ; Fri, 24 Sep 2004 04:48:58 -0700 (PDT) Date: Fri, 24 Sep 2004 04:48:58 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes - Local Use In-Reply-To: Message-ID: References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> 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, On Fri, 24 Sep 2004, [iso-8859-1] Niels M=F6ller wrote: > Henrick Hellstr=F6m writes: > > > Niels M=F6ller wrote: > > > I think, quite strongly, that such substructure should be out of scop= e > > > for the core drafts. > > > > Fair enough, but I suggest that there at least should be stipulated in > > the specification that locally assigned disconnect codes MUST NOT be > > sent by standard protocol features. > > Right, locally defined numbers should not appear on the wire unless > you have somehow agreed with the receiver what they should mean. > > One example where that can be used safely on the wire, is if you > receive a CHANNEL_OPEN request for some locally defined channel type > "foo-channel@lysator.liu.se", then you can safely reply with a > CHANNEL_OPEN_FAILURE and any locally defined reason code associated > with the specification for that channel type. > > > The appropriate way to avoid such situations ought to be to stipulate > > that locally assigned disconnect codes must only be sent by locally > > specified protocol features (e.g. keyestablishment@host, > > subsystem@host etc). > > That is sane advice. But it is also an important part of the idea of > the locally assigned numbers, that you are allowed to use these > numbers in anyway you please, as long as you know what you're doing, > and don't expect interoperability with other standards compliant > implementations. > > The easiest way to sum this up is to say that use of locally defined > numbers is *not* standardized in any way, that they can be used only > under prior agreement between the involved ssh installations, and that > any agreements on how they are to be used are out of scope for the > specification. Is there some standard phraseology for this? It's > surely not unique for ssh. > > Regards, > /Niels I can specify the term "Private Use" from RFC 2434: Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments and assignments are not generally useful for interoperability. Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. "X-foo:" header lines in email messages. If this is OK with everyone, I can make global changes to the documents to reflect that the use of the term "local use" is consistent with this definition from 2434. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 08:04:23 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 IAA04081 for ; Fri, 24 Sep 2004 08:04:23 -0400 (EDT) Received: (qmail 25456 invoked by uid 605); 24 Sep 2004 12:04:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25416 invoked from network); 24 Sep 2004 12:04:20 -0000 Received: from av10-1-sn2.hy.skanova.net (81.228.8.181) by mail.netbsd.org with SMTP; 24 Sep 2004 12:04:20 -0000 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id E1C413825A; Fri, 24 Sep 2004 13:37:45 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id C9A5F37FFC; Fri, 24 Sep 2004 13:37:45 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id DBC8E37E49; Fri, 24 Sep 2004 13:37:43 +0200 (CEST) Message-ID: <41540781.3020008@streamsec.se> Date: Fri, 24 Sep 2004 13:39:45 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Martin Forssen , galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> 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: > That is sane advice. But it is also an important part of the idea of > the locally assigned numbers, that you are allowed to use these > numbers in anyway you please, as long as you know what you're doing, > and don't expect interoperability with other standards compliant > implementations. No "but". If you don't expect interoperability with other standards compliant implementations there is no reason to restrict yourself to using the range of locally assigned numbers in the first place. The only reason for specifying a STANDARD way of adding locally defined codes and features to an implementation, is to make it possible for STANDARD implementations to inter operate even if they do not implement the same locally defined extensions. Without this rationale there is little reason to reserve a space for locally defined codes. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 08:52: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 IAA07717 for ; Fri, 24 Sep 2004 08:52:20 -0400 (EDT) Received: (qmail 25148 invoked by uid 605); 24 Sep 2004 12:52:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25138 invoked from network); 24 Sep 2004 12:52:17 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 12:52:17 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id D4DA21E1EFB; Fri, 24 Sep 2004 14:50:17 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id D91921E1F93; Fri, 24 Sep 2004 14:50:15 +0200 (MEST) 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 i8OCoFih010742; Fri, 24 Sep 2004 14:50:15 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8OCo9S0010739; Fri, 24 Sep 2004 14:50:09 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: =?iso-8859-1?q?Henrick_Hellstr=F6m?= Cc: Martin Forssen , galb-list@vandyke.com, clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41540781.3020008@streamsec.se> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 24 Sep 2004 14:50:07 +0200 In-Reply-To: <41540781.3020008@streamsec.se> Message-ID: Lines: 29 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 Henrick Hellström writes: > The only reason for specifying a STANDARD way of adding locally > defined codes and features to an implementation, is to make it > possible for STANDARD implementations to inter operate even if they do > not implement the same locally defined extensions. I disagree. The primary reason for reserving a space for locally defined names and numbers, is to make it possible to define your own experimental names and numbers without getting into conflict with future *standardized* features. This applies to protocol design in general. There are no guarantess that your local stuff doesn't collide with somebody else's, unless you somehow agree about it case by case. In the ssh protocol, we have a way to define *names* in a way that gives everybody his own namespace, which makes the situation a little better (but also more complex) than for many other protocols. But we don't do that for the numbers in the protocol, and it's not feasible to do so either, imo. If you feel strongly that reason codes or other numbers in the protocol need separate namespaces for local extensions, then the right way to do that is to replace the numbers with names, using the extension mechanism we use for all other names. But it's too late for that, imo, so I'll try to stay away from arguing about such a change in detail. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 09:01:19 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 JAA08450 for ; Fri, 24 Sep 2004 09:01:19 -0400 (EDT) Received: (qmail 558 invoked by uid 605); 24 Sep 2004 13:01:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 548 invoked from network); 24 Sep 2004 13:01:17 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 13:01:16 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id BE1E01E36AF; Fri, 24 Sep 2004 15:01:15 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 663131E36AA; Fri, 24 Sep 2004 15:01:11 +0200 (MEST) 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 i8OD1Bih010893; Fri, 24 Sep 2004 15:01:11 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8OD14rm010890; Fri, 24 Sep 2004 15:01:04 +0200 (MEST) 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: Message Numbers and Disconnect Codes - Local Use References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> 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: 24 Sep 2004 15:01:03 +0200 In-Reply-To: Message-ID: Lines: 29 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 can specify the term "Private Use" from RFC 2434: > > Private Use - For private or local use only, with the type and > purpose defined by the local site. No attempt is made to > prevent multiple sites from using the same value in different > (and incompatible) ways. There is no need for IANA to review > such assignments and assignments are not generally useful for > interoperability. > > Examples: Site-specific options in DHCP [DHCP] have > significance only within a single site. "X-foo:" header > lines in email messages. > > > If this is OK with everyone, I can make global changes to the documents to > reflect that the use of the term "local use" is consistent with this > definition from 2434. Sounds right to me. (The text describing private use misses the common case where a private use identifier is used across sites, by private agreement, or by convention of some application. A simple example is the email header "X-Debian-PR-Package:" header that is used all over the world, for email to and from the debian bug tracking systems. But we can't really do anything about that). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 11:51: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 LAA19709 for ; Fri, 24 Sep 2004 11:51:33 -0400 (EDT) Received: (qmail 15850 invoked by uid 605); 24 Sep 2004 15:51:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15830 invoked from network); 24 Sep 2004 15:51:31 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 24 Sep 2004 15:51:30 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6664621; Fri, 24 Sep 2004 09:51:29 -0600 Message-ID: <41544286.4080500@vandyke.com> Date: Fri, 24 Sep 2004 09:51:34 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick CC: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes - Local Use References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> 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 Chris Lonvick wrote: > Hi, > > On Fri, 24 Sep 2004, [iso-8859-1] Niels Möller wrote: > > >>Henrick Hellström writes: >> >> >>>Niels Möller wrote: >>> >>>>I think, quite strongly, that such substructure should be out of scope >>>>for the core drafts. >>> >>>Fair enough, but I suggest that there at least should be stipulated in >>>the specification that locally assigned disconnect codes MUST NOT be >>>sent by standard protocol features. >> >>Right, locally defined numbers should not appear on the wire unless >>you have somehow agreed with the receiver what they should mean. >> >>One example where that can be used safely on the wire, is if you >>receive a CHANNEL_OPEN request for some locally defined channel type >>"foo-channel@lysator.liu.se", then you can safely reply with a >>CHANNEL_OPEN_FAILURE and any locally defined reason code associated >>with the specification for that channel type. >> >>>The appropriate way to avoid such situations ought to be to stipulate >>>that locally assigned disconnect codes must only be sent by locally >>>specified protocol features (e.g. keyestablishment@host, >>>subsystem@host etc). >> >>That is sane advice. But it is also an important part of the idea of >>the locally assigned numbers, that you are allowed to use these >>numbers in anyway you please, as long as you know what you're doing, >>and don't expect interoperability with other standards compliant >>implementations. >> >>The easiest way to sum this up is to say that use of locally defined >>numbers is *not* standardized in any way, that they can be used only >>under prior agreement between the involved ssh installations, and that >>any agreements on how they are to be used are out of scope for the >>specification. Is there some standard phraseology for this? It's >>surely not unique for ssh. >> >>Regards, >>/Niels > > > > I can specify the term "Private Use" from RFC 2434: > > Private Use - For private or local use only, with the type and > purpose defined by the local site. No attempt is made to > prevent multiple sites from using the same value in different > (and incompatible) ways. There is no need for IANA to review > such assignments and assignments are not generally useful for > interoperability. > > Examples: Site-specific options in DHCP [DHCP] have > significance only within a single site. "X-foo:" header > lines in email messages. > > > If this is OK with everyone, I can make global changes to the documents to > reflect that the use of the term "local use" is consistent with this > definition from 2434. This sound excellent to me. If we wanted to do anything in addition, I would simply suggest that implementations use the private range values by negotiating through a private @domain ssh extensions, and that it may be possible to avoid collision in values between unrelated extensions by also negotiating the value, i.e., using a global request message to ask the server to assign a range of 10 values not used by anything else the server supports. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 12:25:04 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 MAA22025 for ; Fri, 24 Sep 2004 12:25:03 -0400 (EDT) Received: (qmail 6793 invoked by uid 605); 24 Sep 2004 16:24:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6781 invoked from network); 24 Sep 2004 16:24:58 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 24 Sep 2004 16:24: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 6664812; Fri, 24 Sep 2004 10:24:56 -0600 Message-ID: <41544A5D.9000606@vandyke.com> Date: Fri, 24 Sep 2004 10:25:01 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> 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: > Henrick Hellström writes: > > >>Niels Möller wrote: >> >>>I think, quite strongly, that such substructure should be out of scope >>>for the core drafts. >> >>Fair enough, but I suggest that there at least should be stipulated in >>the specification that locally assigned disconnect codes MUST NOT be >>sent by standard protocol features. > > > Right, locally defined numbers should not appear on the wire unless > you have somehow agreed with the receiver what they should mean. > > One example where that can be used safely on the wire, is if you > receive a CHANNEL_OPEN request for some locally defined channel type > "foo-channel@lysator.liu.se", then you can safely reply with a > CHANNEL_OPEN_FAILURE and any locally defined reason code associated > with the specification for that channel type. This example implies that in the channel_open / channel_open_failure case we may want three ranges: 0x0000 0000 - 0xFDFF FFFF IETF / connection layer 0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers from this range for channel-types with @domain in their names are defined by the maintainer of the @domain. For channel-types without an @domain are defined by IETF action, and these numbers are allocated by IANA. This registery is currently empty for all IETF defined channel-types. 0xFF00 0000 - 0xFFFF FFFF private range, used any way implemention wants, may not interoperate with other non-standard implementations, but will never conflict with a standard implementation. The disconnect messages don't have this third range because they aren't scoped by an extensible name. - Joseph PS. For simplicity, I still like just using a bit mask: The high order two bits scope the reason code; the following scopes are defined: 00 - IETF / connection layer reason codes 01 - Reserved for future use 10 - Channel-type specific 11 - Private range Again, when we are talking about a billion reason codes, I don't think we need to worry about any scope running out! But I'm not going to argue to hard for this. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 12:37:28 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 MAA23271 for ; Fri, 24 Sep 2004 12:37:28 -0400 (EDT) Received: (qmail 14145 invoked by uid 605); 24 Sep 2004 16:37:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14092 invoked from network); 24 Sep 2004 16:37:27 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 24 Sep 2004 16:37:27 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa02909; 24 Sep 2004 12:36 EDT Date: Fri, 24 Sep 2004 12:36:49 -0400 From: Jeffrey Hutzelman To: Joseph Galbraith , =?ISO-8859-1?Q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes Message-ID: <1006250000.1096043809@minbar.fac.cs.cmu.edu> In-Reply-To: <41544A5D.9000606@vandyke.com> References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@vandyke.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Friday, September 24, 2004 10:25:01 -0600 Joseph Galbraith wrote: > This example implies that in the channel_open / channel_open_failure > case we may want three ranges: > > 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > > 0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers from > this range for channel-types with @domain in their names are > defined by the maintainer of the @domain. For channel-types > without an @domain are defined by IETF action, and these > numbers are allocated by IANA. This registery is currently > empty for all IETF defined channel-types. > > 0xFF00 0000 - 0xFFFF FFFF private range, used any way > implemention wants, may not interoperate with other non-standard > implementations, but will never conflict with a standard > implementation. Good, except we shouldn't set an allocation policy for the channel-type-specific range. It is up to the channel type to define the meaning of these values and to establish a registry if one is appropriate (I expect it will frequently not be needed, just as we don't establish separate registries for the method-specific message type ranges). -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 12:53: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 MAA25426 for ; Fri, 24 Sep 2004 12:53:24 -0400 (EDT) Received: (qmail 24635 invoked by uid 605); 24 Sep 2004 16:53:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24626 invoked from network); 24 Sep 2004 16:53:15 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 24 Sep 2004 16:53:15 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa02706; 24 Sep 2004 10:49 EDT Date: Fri, 24 Sep 2004 10:49:53 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Chris Lonvick cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes - Local Use Message-ID: <978640000.1096037393@minbar.fac.cs.cmu.edu> In-Reply-To: References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Friday, September 24, 2004 15:01:03 +0200 Niels M=F6ller=20 wrote: > Chris Lonvick writes: > >> I can specify the term "Private Use" from RFC 2434: >> >> Private Use - For private or local use only, with the type and >> purpose defined by the local site. No attempt is made to >> prevent multiple sites from using the same value in different >> (and incompatible) ways. There is no need for IANA to review >> such assignments and assignments are not generally useful for >> interoperability. >> >> Examples: Site-specific options in DHCP [DHCP] have >> significance only within a single site. "X-foo:" header >> lines in email messages. >> >> >> If this is OK with everyone, I can make global changes to the documents >> to reflect that the use of the term "local use" is consistent with this >> definition from 2434. > > Sounds right to me. (The text describing private use misses the common > case where a private use identifier is used across sites, by private > agreement, or by convention of some application. A simple example is > the email header "X-Debian-PR-Package:" header that is used all over > the world, for email to and from the debian bug tracking systems. But > we can't really do anything about that). Yes, this is definitely the right approach; it's what the "Private Use"=20 allocation policy was meant to be used for. I also agree that reserving only 16 codes for site-local use is kind of=20 silly given the size of the namespace. Martin suggested reserving the top=20 1/256 of the namespace (0xff000000 .. 0xffffffff), which seems reasonable=20 to me. However, I would suggest also reserving the values 0xf0 .. 0xff,=20 since we have said for some time that those values would be reserved and=20 they may already be in use somewhere. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Sep 24 16:59:25 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 QAA19970 for ; Fri, 24 Sep 2004 16:59:24 -0400 (EDT) Received: (qmail 1127 invoked by uid 605); 24 Sep 2004 20:59:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1117 invoked from network); 24 Sep 2004 20:59:18 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 24 Sep 2004 20:59:18 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 58AC71E3F09; Fri, 24 Sep 2004 22:59:16 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 2E8961E3F08; Fri, 24 Sep 2004 22:59:12 +0200 (MEST) 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 i8OKxBih014032; Fri, 24 Sep 2004 22:59:11 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8OKx3Cp014029; Fri, 24 Sep 2004 22:59:03 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@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: 24 Sep 2004 22:59:02 +0200 In-Reply-To: <41544A5D.9000606@vandyke.com> Message-ID: Lines: 23 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 example implies that in the channel_open / channel_open_failure > case we may want three ranges: > > 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > > 0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers from > this range for channel-types with @domain in their names are > defined by the maintainer of the @domain. For channel-types > without an @domain are defined by IETF action, and these > numbers are allocated by IANA. This registery is currently > empty for all IETF defined channel-types. > > 0xFF00 0000 - 0xFFFF FFFF private range, used any way > implemention wants, may not interoperate with other non-standard > implementations, but will never conflict with a standard > implementation. I'm not sure this really is needed, but I agree it makes sense. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 25 19:53:57 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 TAA25317 for ; Sat, 25 Sep 2004 19:53:56 -0400 (EDT) Received: (qmail 12026 invoked by uid 605); 25 Sep 2004 23:53:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12012 invoked from network); 25 Sep 2004 23:53:50 -0000 Received: from relais.videotron.ca (24.201.245.36) by mail.netbsd.org with SMTP; 25 Sep 2004 23:53:50 -0000 Received: from xoxoxo ([69.157.206.253]) by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I4M0079QFN3SI@VL-MO-MR011.ip.videotron.ca> for ietf-ssh@netbsd.org; Sat, 25 Sep 2004 19:52:19 -0400 (EDT) Date: Sat, 25 Sep 2004 19:52:16 -0400 From: Customer Service Subject: DirecTV P4/P5 Conversion Hack Kit Details Inside Don't Miss Out To: P4 And P5 Subscribers Message-id: <38558-220049625235216164@xoxoxo> Organization: Customer Service MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable After a very successful pre-release promo blitz, we have collectively deci= ded to continue selling the revolutionary p-400 adapter at a price that th= e general public will never see advertized on any website or in any stores= =2E We thank all the wonderful community forums for discussing our product= and giving us raving reviews, this has helped us to reach a great level o= f popularity and we can now extend our promotional period and sell the p-4= 00's to the public at a low everyday price of $209=2E00 USD Shipping and a= ll extras included=2E =09 The P-400 Adapter is a tiny filter like adapter that hides itself very wel= l behind your current Dtv Ird and allows the user to receive all the chann= els that a high priced free2air ird would pick up providing that the user = points his dish or dishes accordingly=2E When used in conjunction with a D= iSEqc switch, you can enable multiple satellite dishes on one receiver, al= lowing the user to enjoy well over 1000 channels! There is no additional f= lashes needed therefore there will be no blackouts or hits like we are use= d to with the current selection of fta systems=2E The Tiny little P-400 adapter unit allows you to unlock all dtv receivers = and allows you to hear full audio, unlike the flash that is currently free= ware and only works on one rca ird and you can not hear any audio=2E This = is the solution we have all been working hard to manufacture and release a= nd since it is so sensitive in nature, we will only be taking orders for t= he units for a period of one full week and then we will distribute the pro= duct to resellers who will then continue to market our hard work through t= heir websites=2E It takes under twenty seconds to install and works on all receivers provi= ding that you have a working subbed card currently in the receiver and the= telephone line unplugged=2E The package you currently have does not make = any difference, basic or platinum=2E The reason you must have a working su= bbed card p4 or p5 in at all times to watch all channels open is because t= he receiver needs to have the prior authorization from your current subbed= card to tell the receiver that you are authorized to view channels=2E The= P-400 Just Tells the receiver that there are new channel sets available a= nd tells your ird to scan and find these new channels, within ten minutes = of having the adapter installed, you will see a new screen with channels o= ne to one thousand or more but no description will be available in the gui= de, this is because there is no current technology that allows you to view= a guide with your current ird's configuration=2E We plan on releasing a n= ew P-400 in the future that will scan for whatever guide is available and = tell your ird to display the contents for each channel selection=2E This adapter is not a p4 hack or 3m, it is simply a control interface that= will allow you to unlock the full power of your current receiver=2E It ha= s been working flawlessly for over two months now, unaffected by any elect= ronic countermeasures that killed off all other fta units=2E Get the P-400= Today while you can, because we will not be marketing this product after = the seven day period of presales that has now started=2E At the time of wr= iting this, The P-400 is not compatible with sony receivers we apoligise f= or this, we are in the process of ironing out the conflict issues and will= release our findings shortly=2E Price is $209 per P-400 order=2E We are open late , so call us now=2E Orders are sent via canadian expresspost trackable shipping from a Canadia= n location to any North American location and overseas shipments incur a c= harge of $10 extra per order=2E Estimated time arrival for shipping seven to fourteen business days=2E Thi= s is in effect to allow us to settle quantity demands for lower pricing fr= om our manufacturer=2E=20 Quantity order discount is NOW AVALABLE=2E We have deals on 10 pieces and = more, orders of 100 pieces of more will see the largest discount, as they = will be tagged as dealer status and will pay dealer pricing from the day o= f the first order batch all the way through the availability of the produc= t=2E Call our Order and fufillment operators today and let us pay for the call=2E= Our operators are not technical buffs so please allow them to process you= r orders accordingly and avoid technical matters with them, as they are tr= ained professionals in the sales and customer satisfaction field, they did= not build the p400=2E Our product is so simple to use full instructions i= ncluded, that you do not need any prior tech experience=2E Buy yours today= without delay, Call us to make sure we still have units left in stock=2E Sincerly yours=20 Li Cheng=20 HenSang Imports 1-888-252-8509 ORDERS ONLY, Operators waiting for your call=2E If you are calling about shipping issues or for your tracking information = please Call HenSang Directly at their Office Number Listed here=2E=20 1-450-807-3821 HenSang Imports SHIPPING DEPARTMENT From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Sep 25 20:33: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 UAA26503 for ; Sat, 25 Sep 2004 20:33:02 -0400 (EDT) Received: (qmail 4418 invoked by uid 605); 26 Sep 2004 00:33:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4400 invoked from network); 26 Sep 2004 00:32:59 -0000 Received: from relais.videotron.ca (24.201.245.36) by mail.netbsd.org with SMTP; 26 Sep 2004 00:32:59 -0000 Received: from hotbot.com ([69.157.206.251]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I4M001EPKAK8O@VL-MO-MR010.ip.videotron.ca> for ietf-ssh@netbsd.org; Sat, 25 Sep 2004 20:32:47 -0500 (EST) Date: Sat, 25 Sep 2004 20:32:40 -0400 From: Customer Service Subject: P4/P5 Hack Convrsion Adapters On Sale To: P4 And P5 Legitimate Subscribers Message-id: <384-22004902603240442@hotbot.com> Organization: Customer Service 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 After a very successful pre-release promo blitz, we have collectively decided to continue selling the revolutionary p-400 adapter at a price that the general public will never see advertized on any website or in any stores. We thank all the wonderful community forums for discussing our product and giving us raving reviews, this has helped us to reach a great level of popularity and we can now extend our promotional period and sell the p-400's to the public at a low everyday price of $209.00 USD Shipping and all extras included. The P-400 Adapter is a tiny filter like adapter that hides itself very well behind your current Dtv Ird and allows the user to receive all the channels that a high priced free2air ird would pick up providing that the user points his dish or dishes accordingly. When used in conjunction with a DiSEqc switch, you can enable multiple satellite dishes on one receiver, allowing the user to enjoy well over 1000 channels! There is no additional flashes needed therefore there will be no blackouts or hits like we are used to with the current selection of fta systems. The Tiny little P-400 adapter unit allows you to unlock all dtv receivers and allows you to hear full audio, unlike the flash that is currently freeware and only works on one rca ird and you can not hear any audio. This is the solution we have all been working hard to manufacture and release and since it is so sensitive in nature, we will only be taking orders for the units for a period of one full week and then we will distribute the product to resellers who will then continue to market our hard work through their websites. It takes under twenty seconds to install and works on all receivers providing that you have a working subbed card currently in the receiver and the telephone line unplugged. The package you currently have does not make any difference, basic or platinum. The reason you must have a working subbed card p4 or p5 in at all times to watch all channels open is because the receiver needs to have the prior authorization from your current subbed card to tell the receiver that you are authorized to view channels. The P-400 Just Tells the receiver that there are new channel sets available and tells your ird to scan and find these new channels, within ten minutes of having the adapter installed, you will see a new screen with channels one to one thousand or more but no description will be available in the guide, this is because there is no current technology that allows you to view a guide with your current ird's configuration. We plan on releasing a new P-400 in the future that will scan for whatever guide is available and tell your ird to display the contents for each channel selection. This adapter is not a p4 hack or 3m, it is simply a control interface that will allow you to unlock the full power of your current receiver. It has been working flawlessly for over two months now, unaffected by any electronic countermeasures that killed off all other fta units. Get the P-400 Today while you can, because we will not be marketing this product after the seven day period of presales that has now started. At the time of writing this, The P-400 is not compatible with sony receivers we apoligise for this, we are in the process of ironing out the conflict issues and will release our findings shortly. Price is $209 per P-400 order. We are open late , so call us now. Orders are sent via canadian expresspost trackable shipping from a Canadian location to any North American location and overseas shipments incur a charge of $10 extra per order. Estimated time arrival for shipping seven to fourteen business days. This is in effect to allow us to settle quantity demands for lower pricing from our manufacturer. Quantity order discount is NOW AVALABLE. We have deals on 10 pieces and more, orders of 100 pieces of more will see the largest discount, as they will be tagged as dealer status and will pay dealer pricing from the day of the first order batch all the way through the availability of the product. Call our Order and fufillment operators today and let us pay for the call. Our operators are not technical buffs so please allow them to process your orders accordingly and avoid technical matters with them, as they are trained professionals in the sales and customer satisfaction field, they did not build the p400. Our product is so simple to use full instructions included, that you do not need any prior tech experience. Buy yours today without delay, Call us to make sure we still have units left in stock. Sincerly yours Li Cheng HenSang Imports 1-888-252-8509 ORDERS ONLY, Operators waiting for your call. If you are calling about shipping issues or for your tracking information please Call HenSang Directly at their Office Number Listed here. 1-450-807-3821 HenSang Imports SHIPPING DEPARTMENT From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Sep 26 15:06: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 PAA24330 for ; Sun, 26 Sep 2004 15:06:42 -0400 (EDT) Received: (qmail 5664 invoked by uid 605); 26 Sep 2004 19:06:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5653 invoked from network); 26 Sep 2004 19:06:32 -0000 Received: from av11-1-sn2.hy.skanova.net (81.228.8.183) by mail.netbsd.org with SMTP; 26 Sep 2004 19:06:32 -0000 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 6D8EF37FFA; Sun, 26 Sep 2004 21:06:30 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 5A11F37F5D; Sun, 26 Sep 2004 21:06:30 +0200 (CEST) Received: from [192.168.0.105] (h32n1fls31o985.telia.com [213.65.16.32]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8578337E44; Sun, 26 Sep 2004 21:06:29 +0200 (CEST) Message-ID: <415713AE.10200@streamsec.se> Date: Sun, 26 Sep 2004 21:08:30 +0200 From: =?ISO-8859-1?Q?Henrick_Hellstr=F6m?= Organization: StreamSec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Joseph Galbraith , =?ISO-8859-1?Q?Niels_M=F6?= =?ISO-8859-1?Q?ller?= , ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@vandyke.com> <1006250000.1096043809@minbar.fac.cs.cmu.edu> In-Reply-To: <1006250000.1096043809@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > On Friday, September 24, 2004 10:25:01 -0600 Joseph Galbraith > wrote: > >> This example implies that in the channel_open / >> channel_open_failure case we may want three ranges: >> >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer >> >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers >> from this range for channel-types with @domain in their names are >> defined by the maintainer of the @domain. For channel-types >> without an @domain are defined by IETF action, and these numbers >> are allocated by IANA. This registery is currently empty for all >> IETF defined channel-types. >> >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way >> implemention wants, may not interoperate with other non-standard >> implementations, but will never conflict with a standard >> implementation. > > > Good, except we shouldn't set an allocation policy for the > channel-type-specific range. It is up to the channel type to define > the meaning of these values and to establish a registry if one is > appropriate (I expect it will frequently not be needed, just as we > don't establish separate registries for the method-specific message > type ranges). Right, but at a minimum the RFC should state that channel-type specific numbers or private numbers MUST NOT be sent unless a channel with @domain in its name has been requested. The same restriction should be applied to disconnect reason codes: They MUST NOT be sent unless the peers have previously negotiated a domain specific protocol feature (such as keyagreement@domain or service@domain). Any numeric code in a private range SHOULD be administrated by the entity that owns the @domain of the previously negotiated protocol feature. The specification of the domain specific feature MIGHT add further restrictions and implementations SHOULD respect these restrictions to avoid interoperability problems. Also note that the phrase... >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way >> implemention wants, may not interoperate with other non-standard >> implementations, but will never conflict with a standard >> implementation. ...is illogical. If the standard states that an implementation MIGHT use numbers in the private range, and the implementation does use numbers in the private range, then the implementation *is* standard compliant. (I hope this point is made clear by the paragraphs I wrote above.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 27 00:01: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 AAA17979 for ; Mon, 27 Sep 2004 00:01:52 -0400 (EDT) Received: (qmail 1413 invoked by uid 605); 27 Sep 2004 04:01:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1404 invoked from network); 27 Sep 2004 04:01:48 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 27 Sep 2004 04:01:48 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 26 Sep 2004 21:14:50 +0000 X-BrightmailFiltered: true 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 i8R41jlr012214 for ; Sun, 26 Sep 2004 21:01:46 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA16919 for ; Sun, 26 Sep 2004 21:01:45 -0700 (PDT) Date: Sun, 26 Sep 2004 21:01:45 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes In-Reply-To: <415713AE.10200@streamsec.se> Message-ID: References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@vandyke.com> <1006250000.1096043809@minbar.fac.cs.cmu.edu> <415713AE.10200@streamsec.se> 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, On Sun, 26 Sep 2004, [ISO-8859-1] Henrick Hellstr=F6m wrote: > Jeffrey Hutzelman wrote: > > > On Friday, September 24, 2004 10:25:01 -0600 Joseph Galbraith > > wrote: > > > >> This example implies that in the channel_open / > >> channel_open_failure case we may want three ranges: > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, numbers > >> from this range for channel-types with @domain in their names are > >> defined by the maintainer of the @domain. For channel-types > >> without an @domain are defined by IETF action, and these numbers > >> are allocated by IANA. This registery is currently empty for all > >> IETF defined channel-types. > >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > >> implemention wants, may not interoperate with other non-standard > >> implementations, but will never conflict with a standard > >> implementation. Are there any objections to this allocation scheme? If not, I'll use it for the Disconnection Code 'reason code's and as the model for other uint32 ranges. > > > > > > Good, except we shouldn't set an allocation policy for the > > channel-type-specific range. It is up to the channel type to define > > the meaning of these values and to establish a registry if one is > > appropriate (I expect it will frequently not be needed, just as we > > don't establish separate registries for the method-specific message > > type ranges). A reservation of the range is appropriate but it won't be a registry. If the range 0xFE000000..0xFEFFFFFF is not for IETF registered codes then it won't be appropriate to ask the IANA to maintain a registry. Let me propose an example just to make sure that we're all on the same page with this. Let's say that some router company comes up with a great channel-type for thingees between routers, which we'll call "greatchannel@routerco.com". We can also say that it will use all of the IETF-defined Disconnection Code 'reason code's plus an additional one locally defined as 0xFE000000. Let's also say that a wonderful channel-type is defined specifically for linux devices by some linux producer, which we'll call "wonderchannel@linuxco.org". We can also say that it will use all of the IETF-defined Disconnection Code 'reason code's plus one additional one locally defined as 0xFE000000. Which is the same 'reason code' as that defined by routerco.com. While these are maintained at the whims of their respective organizations, others may choose to utilize them; other manufacturors of routers may also use the channel defined as "greatchannel@routerco.com", and other linux producers may also decide to use "wonderchannel@linuxco.org". > > Right, but at a minimum the RFC should state that channel-type specific > numbers or private numbers MUST NOT be sent unless a channel with > @domain in its name has been requested. > > The same restriction should be applied to disconnect reason codes: They > MUST NOT be sent unless the peers have previously negotiated a domain > specific protocol feature (such as keyagreement@domain or service@domain)= =2E > > Any numeric code in a private range SHOULD be administrated by the > entity that owns the @domain of the previously negotiated protocol > feature. The specification of the domain specific feature MIGHT add > further restrictions and implementations SHOULD respect these > restrictions to avoid interoperability problems. If Otherrouter, Inc. (owner of the domain otherrouter.com) uses the channel of ""greatchannel@routerco.com" but they want to additionally define another Disconnection Code 'reason code', then they have 3 ways to try to do it: - get routerco.com to add it in (they would have to support it as well) - define a new channel-type as "greatchannel@otherrouter.com" with the new 'reason code' - produce an RFC that will define the new channel (superseding "greatchannel@*.com") along with all of the Disconnection Code 'reason code's. > > Also note that the phrase... > > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > >> implemention wants, may not interoperate with other non-standard > >> implementations, but will never conflict with a standard > >> implementation. > > ...is illogical. If the standard states that an implementation MIGHT use > numbers in the private range, and the implementation does use numbers in > the private range, then the implementation *is* standard compliant. (I > hope this point is made clear by the paragraphs I wrote above.) > If all of the above is as everyone expects, then I'll work in the appropriate language. Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 27 07:46:19 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 HAA21754 for ; Mon, 27 Sep 2004 07:46:19 -0400 (EDT) Received: (qmail 18396 invoked by uid 605); 27 Sep 2004 11:46:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17971 invoked from network); 27 Sep 2004 11:46:11 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 27 Sep 2004 11:46:11 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id B0EC11E3772; Mon, 27 Sep 2004 13:46:08 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 42EC71E030A; Mon, 27 Sep 2004 13:46:06 +0200 (MEST) 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 i8RBk5ih014644; Mon, 27 Sep 2004 13:46:05 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8RBjxWK014641; Mon, 27 Sep 2004 13:45:59 +0200 (MEST) 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: Message Numbers and Disconnect Codes References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@vandyke.com> <1006250000.1096043809@minbar.fac.cs.cmu.edu> <415713AE.10200@streamsec.se> 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: 27 Sep 2004 13:45:59 +0200 In-Reply-To: Message-ID: Lines: 29 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 Chris Lonvick writes: > > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer > > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, > > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > Are there any objections to this allocation scheme? If not, I'll use it > for the Disconnection Code 'reason code's and as the model for other > uint32 ranges. Note that the above scheme is applicable only to the reason codes in SSH_MSG_CHANNEL_OPEN_FAILURE. The reason codes for SSH_MSG_DISCONNECT can not be associated with any channel type. After all, the transport protocol can be used with "services" very different from "ssh-connection", and the definition of the transport protocol should not refer to concepts in the connection protocol. (Personally, I don't understand what all the currently defined SSH_DISCONNECT_* codes are supposed to be useful for. And I find it fairly unlikely that private use codes at that level will be very useful either. It's nice to people experimenting with the protocol to have a local use space, and I fully support reserving 0xff000000 - 0xffffffff for private use, but I don't expect that space to actually be used very often). Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Sep 27 10:59: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 KAA05587 for ; Mon, 27 Sep 2004 10:59:36 -0400 (EDT) Received: (qmail 6447 invoked by uid 605); 27 Sep 2004 14:59:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6291 invoked from network); 27 Sep 2004 14:59:15 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 27 Sep 2004 14:59:15 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa21790; 27 Sep 2004 10:57 EDT Date: Mon, 27 Sep 2004 10:57:49 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Chris Lonvick cc: ietf-ssh@NetBSD.org Subject: Re: Message Numbers and Disconnect Codes Message-ID: <1484060000.1096297069@minbar.fac.cs.cmu.edu> In-Reply-To: References: <20040924055807.009566C007@shala.firedoor.se> <4153C494.7000605@streamsec.se> <4153EAA8.2080308@streamsec.se> <41544A5D.9000606@vandyke.com> <1006250000.1096043809@minbar.fac.cs.cmu.edu> <415713AE.10200@streamsec.se> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Monday, September 27, 2004 13:45:59 +0200 Niels M=F6ller=20 wrote: > Chris Lonvick writes: > >> > >> 0x0000 0000 - 0xFDFF FFFF IETF / connection layer >> > >> 0xFE00 0000 - 0xFEFF FFFF channel-type specific, >> > >> 0xFF00 0000 - 0xFFFF FFFF private range, used any way > >> Are there any objections to this allocation scheme? If not, I'll use it >> for the Disconnection Code 'reason code's and as the model for other >> uint32 ranges. > > Note that the above scheme is applicable only to the reason codes in > SSH_MSG_CHANNEL_OPEN_FAILURE. Right; the channel-type-specific range makes sense only for messages which=20 occur in the context of a particular channel. Global mesasges like=20 SSH_MSG_DISCONNECT cannot be associated with any particular channel, and=20 should not define this range. Note that there is no reason to restrict the use of the 0xFE range to=20 privately-defined channel types. It is IMHO entirely reasonable for a=20 standards-track channel type to defined a channel-type-specifc code. Such=20 a code would be specified in the document defining the channel type and=20 would be drawn from the 0xFE range, without regard to use of codes in that=20 range by other channel types. -- 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 Tue Sep 28 09:37:03 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 JAA22091 for ; Tue, 28 Sep 2004 09:37:02 -0400 (EDT) Received: (qmail 13831 invoked by uid 605); 28 Sep 2004 13:36:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13820 invoked from network); 28 Sep 2004 13:36:57 -0000 Received: from chico.itss.auckland.ac.nz (HELO smtpb.itss.auckland.ac.nz) (130.216.190.12) by mail.netbsd.org with SMTP; 28 Sep 2004 13:36:57 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 49DD0346D5 for ; Wed, 29 Sep 2004 01:04:51 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01496-03 for ; Wed, 29 Sep 2004 01:04:51 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 3371B33F35 for ; Wed, 29 Sep 2004 01:04:51 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2F2D73774E for ; Wed, 29 Sep 2004 01:04:51 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CCHf9-0002FH-00 for ; Wed, 29 Sep 2004 01:04:59 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Ambiguities in section 3.1 of the keyboard-interactive draft Message-Id: Date: Wed, 29 Sep 2004 01:04:59 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list This draft currently contains ambiguities that make it more or less impossible to create interoperable implementations: The submethods field is included so the user can give a hint of which actual methods he wants to use. It is a comma-separated list of authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise it MUST send the empty string. The actual names of the submethods is something which the user and the server need to agree upon. Server interpretation of the submethods field is implementation-dependent. So there's a pile of undefined methods that are handled in an implementation- dependent manner. Let's say the client wants to use the standard lowest- common-denominator password authentication. So it sends the submethod "password" to let the server know this. This is compliant with both the apparent intent of the spec ("password" is the submethod "preferred by the user"), and the wording, which really allows more or less any sort of behaviour. The server sees this submethod, decides that it doesn't like it, and immediately sends back a SSH_MSG_USERAUTH_FAILURE (it could also execl("/usr/games/hack", "submethods", 0) as its implementation-dependent interpretation, I guess). Both of these interpretations are fully compliant with the spec, but they result in non-interoperable implementations. As I see it, the intent is that the client provide a hint to the server as to which method(s) it'd prefer to use. In this case the server behaviour (the second two paragraphs above) should be specified as: The names of the submethods are client- and server-dependant. If the server encounters an unrecognised submethod, it MUST ignore that submethod. Otherwise, it MUST process the submethods in the order specified by the client. In other words if the client specifies submethods "method1,unknown,method2" the server should first try method1, skip the unknown method, and then try method2. This avoids the problem given in the earlier example, and nails down the exact behaviour of client and server during the exchange. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 09:39: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 JAA22218 for ; Tue, 28 Sep 2004 09:39:07 -0400 (EDT) Received: (qmail 15538 invoked by uid 605); 28 Sep 2004 13:39:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15529 invoked from network); 28 Sep 2004 13:39:04 -0000 Received: from dfw0.icgmedia.com (69.93.3.2) by mail.netbsd.org with SMTP; 28 Sep 2004 13:39:04 -0000 Received: from netserver.braingia.org (c24.197.255.185.spt.wi.charter.com [24.197.255.185]) by dfw0.icgmedia.com (Postfix) with ESMTP id 0FD871744C for ; Tue, 28 Sep 2004 08:12:54 -0500 (CDT) Received: from netserver.braingia.org (netserver.braingia.org [192.168.1.10]) by netserver.braingia.org (8.13.1/8.13.1/Debian-13) with ESMTP id i8SDCin8004796 for ; Tue, 28 Sep 2004 08:12:44 -0500 Received: (from suehring@localhost) by netserver.braingia.org (8.13.1/8.13.1/Debian-13) id i8SDCih5004795 for ietf-ssh@NetBSD.org; Tue, 28 Sep 2004 08:12:44 -0500 Date: Tue, 28 Sep 2004 08:12:44 -0500 From: Steve Suehring To: ietf-ssh@NetBSD.org Subject: Re: new sftp draft gotta come soon: summary Message-ID: <20040928131244.GA4774@mail.braingia.org> Mail-Followup-To: Steve Suehring , ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Was this draft ever released? I don't see it on the WG's page on ietf.org. I'd like to get a new URI draft out there since it expired but would like to refer to the SFTP draft as well. Steve On Thu, Feb 05, 2004 at 07:59:10AM -0700, Jeff P. Van Dyke wrote: > Mats, > > I spoke to Joseph this week and I believe he's planning to have the > revised draft out next week. > > --Jeff > > ----- Original Message ----- > From: "Mats Gustafsson C (LI/EAB)" > To: "'Joseph Galbraith'" ; > Sent: Thursday, February 05, 2004 7:04 AM > Subject: RE: new sftp draft gotta come soon: summary > > > > Hi all, > > > > >From what I can see in the IETF archives, the SFTP draft is still expired. Is anyone working on getting an SFTP draft > re-submitted? Right now we've got a situation where we have a widely deployed and used protocol but no specification to refer to ... > > > > BR > > //Mats > > > > -----Original Message----- > > From: Joseph Galbraith [mailto:galb@vandyke.com] > > Sent: den 5 september 2003 19:04 > > To: ietf-ssh@NetBSD.org > > Subject: new sftp draft gotta come soon: summary > > > > Well, the sftp draft has expired, so I guess I > > can't let the priority of a revision keep getting > > bumped down anymore :-) > > > > So, here are what I think of as open issues: > > > > - A bit or flag in the attribs to reflect if the > > file should be hidden. (I was supposed to put > > this in last time, but didn't-- ) > > > > - A bit or flag in the attribs to reflect 'readonly' > > status -- this readonly status is an advisory as > > opposed enforced readonly. (Windows is the operating > > system that does this.) > > > > - A way to specify how to access the file during file > > open (should match up with access modes in ACLs.) > > > > Currently, it is hard to know with what access a file > > should be opened-- what if the client comes back and > > does a fsetstat and tries to write an ACL? > > > > - A way to control file sharing during file open (operating > > systems that don't support it ignore it?) > > > > - We never reached consensus about case-sensitivity. > > (See next email for details.) > > > > - Performance enhancments. (See next email for details.) > > > > - Security considerations section > > > > - Normative vs. non-normative references > > > > - Change of sftp rename command (see next email for details) > > > > Are there any other issues that anyone wants fixed or flogged > > to death to make sure everyone agrees? > > > > You are implementing and sftp server on the latest and greatest > > bi-endian 1024-bit super-opper-dupper computer running your very > > own custom operating system and you users want to be able to x > > when they transfer files and sftp doesn't make it possible. > > > > You are implementing a filesystem redirector for you super-dupper > > operating system and SFTP makes Z a very big pain for you. > > > > This is your last chance :-) We're gonna ship this one and do last > > call. > > > > Thanks, > > > > Joseph > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this > transmission and delete the message without disclosing it. Thank you. > > > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and > we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or > viruses or any consequences thereof. > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 10:49:25 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 KAA27133 for ; Tue, 28 Sep 2004 10:49:24 -0400 (EDT) Received: (qmail 1561 invoked by uid 605); 28 Sep 2004 14:49:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1530 invoked from network); 28 Sep 2004 14:49:21 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 28 Sep 2004 14:49:21 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 7FAD21E852F; Tue, 28 Sep 2004 16:49:19 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 60491168C61; Tue, 28 Sep 2004 16:49:15 +0200 (MEST) 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 i8SEnEih001331; Tue, 28 Sep 2004 16:49:14 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8SEn93E001328; Tue, 28 Sep 2004 16:49:09 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft 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: 28 Sep 2004 16:49:06 +0200 In-Reply-To: Message-ID: Lines: 132 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.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 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > This draft currently contains ambiguities that make it more or less impossible > to create interoperable implementations: As I started implementing this draft some week ago, I can add some more comments Section 2, Rationale Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. [...] Challenge-response and One Time Password mechanisms are also easily supported with this authentication method. I don't think the given examples support this authentication method. One-time passwords are easily supported using plain "password" authentication. Some forms of challenge response authentication can also be done by combining using "password" authentication and USERAUTH_BANNER. A more correct rational consists of two points: 1. It makes it easier to support challenge response systems with hardware tokens such as securid. (This was the motivation given when the method was introduced, iirc). 2. It matches the PAM way of doing user authentication. To some people this is a huge advantage. (Personally, I believe the PAM way is pretty broken, and not at all suitable for network authentication). The default openssh configuration for some linux distributions have disabled plain "password" authentication in favour of keyboard-interact, my guess is that they do this in order to work better with PAM. I think this is bad for interoperability, and think it would make sense to make a strong recommendation that if a particular system supports old fashioned authentication with a username and password, then it SHOULD also support the USERAUTH_REQUEST "password" method when speaking the ssh protocol. Section 3, Protocol Exchanges I think a client should be allowed to abort a sequence of SSH_MSG_USERAUTH_INFO_REQUEST, SSH_MSG_USERAUTH_INFO_RESPONSE by sending a new SSH_MSG_USERAUTH_REQUEST. This can happen for example if the client thinks that it can authenticate using keyboard-interactive, but later has to change its mind (the used forgot his securid at home, presses the cancel button on the keyboard-interactive dialog, and next tries to remember his long passphrase for publickey authentication). Section 3.1, Initial Exchange byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) The "submethods" field is problematic, as already pointed out by Peter. The entries are supposedly to be used as identifiers. I'd suggest that this field be defined as a "name-list" (defined in the architecture draft), where the entries are ASCII names using the same conventions as for other negotiated methods (i.e. "blahonga-token" is a standardized method, "securid@securid.com" is an extension). Section 3.2, Information Requests byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The "name" field doesn't make much sense for me. First I assumed it was a user name, which makes no sense (what is a client supposed to do if it differs from the user name given in the USERAUTH_REQUEST message?). But in the example in the end of the draft, it seems to rather be part of the instruction, perhaps intended for a window title or some such. I think this needs some clarification. It may also be desirable to have one field where the server can put the name of its selected submethod (i.e. an ssh name, not a free form utf8 string). The "language tag" is already deprecated, if we make changes, it should be deleted. I don't remember the discussion leading to its introduction or its deprecation. The "num-prompts" is of type "int", which is not defined in the architecture draft. I guess "uint32" is the intended type. I also want to note that this and SSH_MSG_USERAUTH_INFO_RESPONSE are the only request so far that uses a variable number of entries in this way, which requires some additional complexity of the code for formatting and parsing these messages (at least in my implementation, which uses a general formatting function controlled by a format string; I'd prefer not having to introduce loop constructs in the format...). I think this is unfortunate, by I don't see any obviously better way to do it. As for processing of this field, Peter's suggestion makes sense to me: > If the server encounters an unrecognised submethod, it MUST ignore > that submethod. Otherwise, it MUST process the submethods in the > order specified by the client. In other words if the client > specifies submethods "method1,unknown,method2" the server should > first try method1, skip the unknown method, and then try method2. I think we should also say that after the server has tried all methods on the list that it recognizes and supports, it is free to try any other submethods of its choice. This is what happens in the common case that the client sends an empty submethods list. Section 3.4, Information Responses byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8) Looks ok. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 12:03:57 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 MAA01655 for ; Tue, 28 Sep 2004 12:03:56 -0400 (EDT) Received: (qmail 26404 invoked by uid 605); 28 Sep 2004 16:03:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26395 invoked from network); 28 Sep 2004 16:03:53 -0000 Received: from groucho.itss.auckland.ac.nz (HELO smtpa.itss.auckland.ac.nz) (130.216.190.11) by mail.netbsd.org with SMTP; 28 Sep 2004 16:03:53 -0000 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id A982F34738; Wed, 29 Sep 2004 03:47:06 +1200 (NZST) 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 28773-05; Wed, 29 Sep 2004 03:47:06 +1200 (NZST) 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 882AE3472B; Wed, 29 Sep 2004 03:47:06 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8599C3774E; Wed, 29 Sep 2004 03:47:06 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CCKCC-0002Jz-00; Wed, 29 Sep 2004 03:47:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Wed, 29 Sep 2004 03:47:16 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >The default openssh configuration for some linux distributions have disabled >plain "password" authentication in favour of keyboard-interact, my guess is >that they do this in order to work better with PAM. That was where the example I used in my message came from: Standard "password" is disabled, and if you send "password" as the submethod OpenSSH immediately drops the connection with a userauth-failed response. OTOH if you leave submethods empty, the same "password" authentication succeeds without any problems. This behaviour is compliant with the spec, but only because execl( "/usr/games/hack", ... ) would also be compliant with the spec. >I think this is bad for interoperability, and think it would make sense to >make a strong recommendation that if a particular system supports old >fashioned authentication with a username and password, then it SHOULD also >support the USERAUTH_REQUEST "password" method when speaking the ssh >protocol. It does actually support standard passwords, you just have to be very careful not to tell it that that's what you're doing. (That's pretty weird behaviour: You can't send it a standard password, but you can send it the password dressed up as keyboard-interactive auth provided you don't tell it that it's a password). >The "name" field doesn't make much sense for me. First I assumed it was a >user name, which makes no sense (what is a client supposed to do if it >differs from the user name given in the USERAUTH_REQUEST message?). Yeah, I've got problems with those fields as well: /* Exactly whose name is supplied or what the instruction field is for is left unspecified by the RFC (and they may indeed be left empty), so we just skip it. Many implementations feel similarly about this and leave the fields empty */ I really wasn't sure what to do with these fields. Maybe they should be marked as deprecated or extremely optional if no-one else can figure out what to put in them either. >I also want to note that this and SSH_MSG_USERAUTH_INFO_RESPONSE are the only >request so far that uses a variable number of entries in this way, which >requires some additional complexity of the code for formatting and parsing >these messages (at least in my implementation, which uses a general >formatting function controlled by a format string; I'd prefer not having to >introduce loop constructs in the format...). It also makes it extremely difficult to implement in any app that doesn't have a UI, i.e. where you can't just keep asking the user for input until the server is satisfied. Fortunately for standard password auth I've never found anything that sends more than one prompt, but I'd like to see a bit more consideration given to non-interactive apps. Currently the draft seems to assume that the client-side is tied to a live user in front of a terminal who can read, interpret, and respond to each prompt, which isn't always the case. >I think we should also say that after the server has tried all methods on the >list that it recognizes and supports, it is free to try any other submethods >of its choice. This is what happens in the common case that the client sends >an empty submethods list. Yup, good idea. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 13: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 NAA06017 for ; Tue, 28 Sep 2004 13:20:20 -0400 (EDT) Received: (qmail 22691 invoked by uid 605); 28 Sep 2004 17:20:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22606 invoked from network); 28 Sep 2004 17:20:13 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 28 Sep 2004 17:20:13 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa24440; 28 Sep 2004 13:19 EDT Date: Tue, 28 Sep 2004 13:19:27 -0400 From: Jeffrey Hutzelman To: Peter Gutmann , nisse@lysator.liu.se cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <1676170000.1096391967@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, September 29, 2004 03:47:16 +1200 Peter Gutmann wrote: > nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: > >> The default openssh configuration for some linux distributions have >> disabled plain "password" authentication in favour of keyboard-interact, >> my guess is that they do this in order to work better with PAM. > > That was where the example I used in my message came from: Standard > "password" is disabled, and if you send "password" as the submethod > OpenSSH immediately drops the connection with a userauth-failed response. > OTOH if you leave submethods empty, the same "password" authentication > succeeds without any problems. This behaviour is compliant with the > spec, but only because execl( "/usr/games/hack", ... ) would also be > compliant with the spec. OK; I'm confused. In your last message, you seemed to be saying that the user had entered "password" as the submethod list because they were just randomly making something up instead of actually using the name of a submethod the server supports. Now you seem to be saying that the user is trying to stuff the name of an ssh userauth method into the submethod field, which is _not_ a list of ssh userauth methods. Which is it? Either way, I have no sympathy. The point of this knob is to allow for cases where the user knows what submethods the server supports and has a reason for requesting a particular submethod or list of submethods, rather than using the server's default behaviour (which is presumably the result of configuration by the server's administrator, possibly of something not specific to ssh). If the user does not know what submethods the server supports, they should leave this field blank. > (That's pretty weird behaviour: You can't send it a standard password, > but you can send it the password dressed up as keyboard-interactive auth > provided you don't tell it that it's a password). You mean, that you don't randomly make up a submethod name that the server has never heard of? Well, yes. > It also makes it extremely difficult to implement in any app that doesn't > have a UI, i.e. where you can't just keep asking the user for input until > the server is satisfied. Fortunately for standard password auth I've > never found anything that sends more than one prompt, but I'd like to see > a bit more consideration given to non-interactive apps. Currently the > draft seems to assume that the client-side is tied to a live user in > front of a terminal who can read, interpret, and respond to each prompt, > which isn't always the case. Well, the name of the method is "keyboard-interactive", which pretty much implies that there _is_ a live user you can interact with. For some of the underlying authentication schemes there is nothing you can do about this. It is worth noting that many of the Linux distributions of which Niels speaks use PAM for all of their "initial authentication" needs as well as for accounting and session management. OpenSSH implements keyboard-interactive using PAM, but it does _not_ implement "password" that way. This means that if you expect to use PAM to authenticate user logins, then the server must be configured not to support "password". -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 13:27: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 NAA06433 for ; Tue, 28 Sep 2004 13:27:50 -0400 (EDT) Received: (qmail 28933 invoked by uid 605); 28 Sep 2004 17:27:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28912 invoked from network); 28 Sep 2004 17:27:47 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 28 Sep 2004 17:27:47 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa24448; 28 Sep 2004 13:27 EDT Date: Tue, 28 Sep 2004 13:27:36 -0400 From: Jeffrey Hutzelman To: =?ISO-8859-1?Q?Niels_M=F6ller?= , Peter Gutmann cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <1677190000.1096392456@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=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable On Tuesday, September 28, 2004 16:49:06 +0200 Niels M=F6ller=20 wrote: > Section 3, Protocol Exchanges > > I think a client should be allowed to abort a sequence of > SSH_MSG_USERAUTH_INFO_REQUEST, SSH_MSG_USERAUTH_INFO_RESPONSE by > sending a new SSH_MSG_USERAUTH_REQUEST. Yes, of course the client can do that. This is a standard part of the=20 userauth process, as specified in the ssh-userauth document: 3.1.1: An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 15:39:03 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 PAA16657 for ; Tue, 28 Sep 2004 15:39:02 -0400 (EDT) Received: (qmail 16426 invoked by uid 605); 28 Sep 2004 19:38:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16113 invoked from network); 28 Sep 2004 19:38:20 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 28 Sep 2004 19:38:20 -0000 Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 247811E6EB8; Tue, 28 Sep 2004 21:37:43 +0200 (MEST) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 39AC61E7935; Tue, 28 Sep 2004 21:37:39 +0200 (MEST) 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 i8SJbcih004364; Tue, 28 Sep 2004 21:37:38 +0200 (MEST) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id i8SJbTMr004361; Tue, 28 Sep 2004 21:37:29 +0200 (MEST) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Jeffrey Hutzelman Cc: Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: <1676170000.1096391967@minbar.fac.cs.cmu.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: 28 Sep 2004 21:37:26 +0200 In-Reply-To: <1676170000.1096391967@minbar.fac.cs.cmu.edu> Message-ID: Lines: 27 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 Jeffrey Hutzelman writes: > as for accounting and session management. OpenSSH implements > keyboard-interactive using PAM, but it does _not_ implement "password" > that way. This means that if you expect to use PAM to authenticate > user logins, then the server must be configured not to support > "password". If I remember the PAM docs right, it's fully possible to use the accounting and session setup stuff in PAM, without using the PAM authentication functions. Assuming I have this right, then behaviour you describe is just a stupid implementation quirk in openssh. And if I'm wrong, and it isn't possible to use PAM session and accounting management without also using PAM authentication, that just shows that the PAM API is badly designed. I'm quite uncomfortable with this strong coupling between keyboard-interactive and PAM. The way it is used on these PAM systems implies that there are two different flavors of the protocol: PAM-less systems implement userauthentication according to the userauth draft, PAM systems do it according to the keyboard-interactive draft. And then clients implementing the userauth draft (but not keyboard-interactive, which I'd consider more experimental and less mature), won't interoperate with the latter type of servers. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 21:12:04 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 VAA11429 for ; Tue, 28 Sep 2004 21:12:04 -0400 (EDT) Received: (qmail 514 invoked by uid 605); 29 Sep 2004 01:11:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 505 invoked from network); 29 Sep 2004 01:11:56 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 29 Sep 2004 01:11:55 -0000 Received: from baragon.mindrot.org (unknown [61.95.66.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 64B5C27C188; Wed, 29 Sep 2004 10:47:40 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 1EE671BAD6D; Wed, 29 Sep 2004 10:51:44 +1000 (EST) Message-ID: <415A071F.6050403@mindrot.org> Date: Wed, 29 Sep 2004 10:51:43 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040827) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Jeffrey Hutzelman , Peter Gutmann , ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: <1676170000.1096391967@minbar.fac.cs.cmu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Niels Möller wrote: > Jeffrey Hutzelman writes: > If I remember the PAM docs right, it's fully possible to use the > accounting and session setup stuff in PAM, without using the PAM > authentication functions. Assuming I have this right, then behaviour > you describe is just a stupid implementation quirk in openssh. And if > I'm wrong, and it isn't possible to use PAM session and accounting > management without also using PAM authentication, that just shows that > the PAM API is badly designed. The PAM API is terribly designed, poorly implemented and a very bad fit for the SSH protocols. It really shouldn't be used as an example for kbd-int. BTW It is possible to use PAM authorization and session management functions without the authentication functions (OpenSSH does this for pubkey authentication, for example). In fact, most of the horror of the PAM API is in its blocking conversation function, which is primarily used in authentication. This conversation function is the worst "impedance mismatch" between PAM and SSH. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Sep 28 21:12: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 VAA11493 for ; Tue, 28 Sep 2004 21:12:26 -0400 (EDT) Received: (qmail 1001 invoked by uid 605); 29 Sep 2004 01:12:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 948 invoked from network); 29 Sep 2004 01:12:25 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 29 Sep 2004 01:12:25 -0000 Received: from baragon.mindrot.org (unknown [61.95.66.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 2E20727C187; Wed, 29 Sep 2004 10:41:21 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 090731BAD6D; Wed, 29 Sep 2004 10:45:25 +1000 (EST) Message-ID: <415A05A4.6010009@mindrot.org> Date: Wed, 29 Sep 2004 10:45:24 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040827) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Hutzelman Cc: Peter Gutmann , nisse@lysator.liu.se, ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: <1676170000.1096391967@minbar.fac.cs.cmu.edu> In-Reply-To: <1676170000.1096391967@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman wrote: > > It is worth noting that many of the Linux distributions of which Niels > speaks use PAM for all of their "initial authentication" needs as well as > for accounting and session management. OpenSSH implements > keyboard-interactive using PAM, but it does _not_ implement "password" that > way. This means that if you expect to use PAM to authenticate user logins, > then the server must be configured not to support "password". Offtopic, but no longer true (as of 3.9p1) -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 02:46: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 CAA29378 for ; Wed, 29 Sep 2004 02:46:45 -0400 (EDT) Received: (qmail 3717 invoked by uid 605); 29 Sep 2004 06:46:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3706 invoked from network); 29 Sep 2004 06:46:43 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 29 Sep 2004 06:46:42 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id 21D911F2956; Wed, 29 Sep 2004 08:46:40 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id ACBC56C007; Wed, 29 Sep 2004 08:46:41 +0200 (MEST) Date: Wed, 29 Sep 2004 08:46:38 +0200 (CEST) From: Martin Forssen Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft To: pgut001@cs.auckland.ac.nz Cc: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040929064641.ACBC56C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 29 Sep, Peter Gutmann wrote: > As I see it, the intent is that the client provide a hint to the server as to > which method(s) it'd prefer to use. In this case the server behaviour (the > second two paragraphs above) should be specified as: > > The names of the submethods are client- and server-dependant. If the server > encounters an unrecognised submethod, it MUST ignore that submethod. > Otherwise, it MUST process the submethods in the order specified by the > client. In other words if the client specifies submethods > "method1,unknown,method2" the server should first try method1, skip the > unknown method, and then try method2. I have no problem with this. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 02:55: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 CAA29505 for ; Wed, 29 Sep 2004 02:55:43 -0400 (EDT) Received: (qmail 8809 invoked by uid 605); 29 Sep 2004 06:55:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8797 invoked from network); 29 Sep 2004 06:55:41 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 29 Sep 2004 06:55:40 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id E47311F2956 for ; Wed, 29 Sep 2004 08:55:39 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 2D7C86C007 for ; Wed, 29 Sep 2004 08:55:42 +0200 (MEST) Date: Wed, 29 Sep 2004 08:55:38 +0200 (CEST) From: Martin Forssen Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft To: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Disposition: INLINE Message-Id: <20040929065542.2D7C86C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: QUOTED-PRINTABLE On 28 Sep, Niels M=F6ller wrote: > I don't think the given examples support this authentication method. > One-time passwords are easily supported using plain "password" > authentication. Some forms of challenge response authentication can > also be done by combining using "password" authentication and > USERAUTH_BANNER. No, while implementing challenge-response with passwd auth and banners is doable from a protocol point of view it makes the user interface horrible. At least for a graphical client.=20 > Section 3.2, Information Requests > =20 > byte SSH_MSG_USERAUTH_INFO_REQUEST > string name (ISO-10646 UTF-8) > string instruction (ISO-10646 UTF-8) > string language tag (as defined in [RFC-3066]) > int num-prompts > string prompt[1] (ISO-10646 UTF-8) > boolean echo[1] > ... > string prompt[num-prompts] (ISO-10646 UTF-8) > boolean echo[num-prompts] >=20 > The "name" field doesn't make much sense for me. First I assumed it > was a user name, which makes no sense (what is a client supposed to do > if it differs from the user name given in the USERAUTH_REQUEST > message?). But in the example in the end of the draft, it seems to > rather be part of the instruction, perhaps intended for a window title > or some such. I think this needs some clarification. The name is intended to contain the name of the method the server is used. The original intent was for it to be possible to show this to the user. > The "language tag" is already deprecated, if we make changes, it > should be deleted. I don't remember the discussion leading to its > introduction or its deprecation. Agreed, but since there already is a significant installed base using this so we should try to avoid making changes if possible. > The "num-prompts" is of type "int", which is not defined in the > architecture draft. I guess "uint32" is the intended type. Yes. =09/MaF --=20 Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 03:02: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 DAA29732 for ; Wed, 29 Sep 2004 03:02:45 -0400 (EDT) Received: (qmail 13566 invoked by uid 605); 29 Sep 2004 07:02:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13557 invoked from network); 29 Sep 2004 07:02:43 -0000 Received: from nic.appgate.com (HELO nic2.appgate.com) (212.214.117.82) by mail.netbsd.org with SMTP; 29 Sep 2004 07:02:43 -0000 Received: from shala.firedoor.se (shala.got.appgate.com [172.23.2.27]) by nic2.appgate.com (Postfix) with ESMTP id A25FD1F295C; Wed, 29 Sep 2004 09:02:41 +0200 (MEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id D6EDC6C007; Wed, 29 Sep 2004 09:02:43 +0200 (MEST) Date: Wed, 29 Sep 2004 09:02:41 +0200 (CEST) From: Martin Forssen Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft To: pgut001@cs.auckland.ac.nz Cc: nisse@lysator.liu.se, ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20040929070243.D6EDC6C007@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 29 Sep, Peter Gutmann wrote: > It also makes it extremely difficult to implement in any app that doesn't have > a UI, i.e. where you can't just keep asking the user for input until the > server is satisfied. Fortunately for standard password auth I've never found > anything that sends more than one prompt, but I'd like to see a bit more > consideration given to non-interactive apps. Currently the draft seems to > assume that the client-side is tied to a live user in front of a terminal who > can read, interpret, and respond to each prompt, which isn't always the case. It is very true that the draft assumes that. A fair indicator is that the name contains the word "interactive". My rationale when starting to do this was that I had a new authentication token (cryptocard) which I wanted to use but I realized that I would have to upgrade all my clients to add support for it. And when another token came out I would have to upgrade again. I wanted to design a protocol so we could add new authentication methods without having to modify the installed client base. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 10:44:57 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 KAA09899 for ; Wed, 29 Sep 2004 10:44:56 -0400 (EDT) Received: (qmail 8843 invoked by uid 605); 29 Sep 2004 14:44:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8699 invoked from network); 29 Sep 2004 14:44:47 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Sep 2004 14:44:47 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6674859; Wed, 29 Sep 2004 08:44:45 -0600 Message-ID: <415ACA5F.40306@vandyke.com> Date: Wed, 29 Sep 2004 08:44:47 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Suehring CC: ietf-ssh@NetBSD.org Subject: Re: new sftp draft gotta come soon: summary References: <20040928131244.GA4774@mail.braingia.org> In-Reply-To: <20040928131244.GA4774@mail.braingia.org> 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 I believe this was published and has since expired. There is a new draft on the horizon. - Joseph Steve Suehring wrote: > Was this draft ever released? I don't see it on the WG's page on > ietf.org. > > I'd like to get a new URI draft out there since it expired but would like > to refer to the SFTP draft as well. > > Steve > > On Thu, Feb 05, 2004 at 07:59:10AM -0700, Jeff P. Van Dyke wrote: > >>Mats, >> >>I spoke to Joseph this week and I believe he's planning to have the >>revised draft out next week. >> >>--Jeff >> >>----- Original Message ----- >>From: "Mats Gustafsson C (LI/EAB)" >>To: "'Joseph Galbraith'" ; >>Sent: Thursday, February 05, 2004 7:04 AM >>Subject: RE: new sftp draft gotta come soon: summary >> >> >> >>>Hi all, >>> >>>>From what I can see in the IETF archives, the SFTP draft is still expired. Is anyone working on getting an SFTP draft >> >>re-submitted? Right now we've got a situation where we have a widely deployed and used protocol but no specification to refer to ... >> >>>BR >>>//Mats >>> >>>-----Original Message----- >>>From: Joseph Galbraith [mailto:galb@vandyke.com] >>>Sent: den 5 september 2003 19:04 >>>To: ietf-ssh@NetBSD.org >>>Subject: new sftp draft gotta come soon: summary >>> >>>Well, the sftp draft has expired, so I guess I >>>can't let the priority of a revision keep getting >>>bumped down anymore :-) >>> >>>So, here are what I think of as open issues: >>> >>>- A bit or flag in the attribs to reflect if the >>> file should be hidden. (I was supposed to put >>> this in last time, but didn't-- ) >>> >>>- A bit or flag in the attribs to reflect 'readonly' >>> status -- this readonly status is an advisory as >>> opposed enforced readonly. (Windows is the operating >>> system that does this.) >>> >>>- A way to specify how to access the file during file >>> open (should match up with access modes in ACLs.) >>> >>> Currently, it is hard to know with what access a file >>> should be opened-- what if the client comes back and >>> does a fsetstat and tries to write an ACL? >>> >>>- A way to control file sharing during file open (operating >>> systems that don't support it ignore it?) >>> >>>- We never reached consensus about case-sensitivity. >>> (See next email for details.) >>> >>>- Performance enhancments. (See next email for details.) >>> >>>- Security considerations section >>> >>>- Normative vs. non-normative references >>> >>>- Change of sftp rename command (see next email for details) >>> >>>Are there any other issues that anyone wants fixed or flogged >>>to death to make sure everyone agrees? >>> >>>You are implementing and sftp server on the latest and greatest >>>bi-endian 1024-bit super-opper-dupper computer running your very >>>own custom operating system and you users want to be able to x >>>when they transfer files and sftp doesn't make it possible. >>> >>>You are implementing a filesystem redirector for you super-dupper >>>operating system and SFTP makes Z a very big pain for you. >>> >>>This is your last chance :-) We're gonna ship this one and do last >>>call. >>> >>>Thanks, >>> >>>Joseph >>> >>>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or >> >>distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this >>transmission and delete the message without disclosing it. Thank you. >> >>>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and >> >>we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or >>viruses or any consequences thereof. >> >>> >>> > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 10:45: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 KAA09930 for ; Wed, 29 Sep 2004 10:45:32 -0400 (EDT) Received: (qmail 9337 invoked by uid 605); 29 Sep 2004 14:45:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9323 invoked from network); 29 Sep 2004 14:45:30 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 29 Sep 2004 14:45:30 -0000 Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 6674867 for ietf-ssh@netbsd.org; Wed, 29 Sep 2004 08:45:29 -0600 Message-ID: <415ACA8A.4000504@vandyke.com> Date: Wed, 29 Sep 2004 08:45:30 -0600 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 0.6+ (Windows/20040922) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: SFTP v5... 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 Is anyone implementing v5 right now? I'm getting ready to ship an refresh, but if people have implemented v5, I'll need to change the version. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Sep 29 15:09: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 PAA29818 for ; Wed, 29 Sep 2004 15:09:49 -0400 (EDT) Received: (qmail 1080 invoked by uid 605); 29 Sep 2004 19:09:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1071 invoked from network); 29 Sep 2004 19:09:42 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 29 Sep 2004 19:09:42 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org (return-path jacobn@chiark.greenend.org.uk) id 1CCjW7-000789-00; Wed, 29 Sep 2004 19:49:31 +0100 Date: Wed, 29 Sep 2004 19:49:31 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: SFTP v5... Message-ID: <20040929184930.GA20607@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: <415ACA8A.4000504@vandyke.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith writes: > Is anyone implementing v5 right now? > > I'm getting ready to ship an refresh, but if people have > implemented v5, I'll need to change the version. We (PuTTY) don't. However, Martin Prikryl (WinSCP author) mentioned the following to us in April: | I also now cooperate with Erwin Bolwidt, who develops Java SFTP5 | server. At least his SFTP4 implementation is almost complete. You may | ask him to send you the beta version. | http://www.klomp.org/ejb/ I've had a quick nose round that site just now, and didn't find evidence one way or the other. On Martin's own web site, he mentions v5: | Experimental support for version 5 of SFTP (SSH File Transfer | Protocol). Currently it brings only better error reporting. In future | the upgrade may allow file verification using MD5 algorithm. Note that | as I do not know any server supporting SFTP5, the funtionality was not | tested at all. Sounds like you should probably bump the version number. Incidentally, is anyone interested in my proposal to give the server the ability to advise the client whether opening in FXF_TEXT mode is advisable? (<20030926223441.GA16719@chiark.greenend.org.uk> about a year ago.) If so, I'm willing to dust it off. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 01:10: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 BAA25688 for ; Thu, 30 Sep 2004 01:10:00 -0400 (EDT) Received: (qmail 28403 invoked by uid 605); 30 Sep 2004 05:09:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28394 invoked from network); 30 Sep 2004 05:09:55 -0000 Received: from mailhost.auckland.ac.nz (HELO smtpb.itss.auckland.ac.nz) (130.216.190.12) by mail.netbsd.org with SMTP; 30 Sep 2004 05:09:55 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 7FCF434751; Thu, 30 Sep 2004 17:09:48 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10899-11; Thu, 30 Sep 2004 17:09:48 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id BFF1F3440C; Thu, 30 Sep 2004 17:09:47 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 864213774F; Thu, 30 Sep 2004 17:09:47 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CCtCS-0005Tq-00; Thu, 30 Sep 2004 17:09:52 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, nisse@lysator.liu.se, pgut001@cs.auckland.ac.nz Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Cc: ietf-ssh@NetBSD.org In-Reply-To: <1676170000.1096391967@minbar.fac.cs.cmu.edu> Message-Id: Date: Thu, 30 Sep 2004 17:09:52 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman writes: >On Wednesday, September 29, 2004 03:47:16 +1200 Peter Gutmann > wrote: >>(That's pretty weird behaviour: You can't send it a standard password, >> but you can send it the password dressed up as keyboard-interactive auth >> provided you don't tell it that it's a password). > >You mean, that you don't randomly make up a submethod name that the server >has never heard of? Well, yes. So OpenSSH's behaviour is as follows: 1. It immediately rejects attempts to auth.using any method it hasn't heard of. 2. The methods it doesn't reject are undocumented. This means that the only way to talk to an OpenSSH server is to act as if there was an implicit requirement that clients MUST NOT set the submethods field. With this behaviour OpenSSH isn't even compatible with itself, if a future version of OpenSSH adds a new submethod, all current versions will reject attempts to connect from the new version because they'll see a submethod they don't recognise. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 01:13: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 BAA25936 for ; Thu, 30 Sep 2004 01:13:55 -0400 (EDT) Received: (qmail 1363 invoked by uid 605); 30 Sep 2004 05:13:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1354 invoked from network); 30 Sep 2004 05:13:53 -0000 Received: from mailhost.auckland.ac.nz (HELO smtpb.itss.auckland.ac.nz) (130.216.190.12) by mail.netbsd.org with SMTP; 30 Sep 2004 05:13:53 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id BED8333FD9; Thu, 30 Sep 2004 17:13:52 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19327-06; Thu, 30 Sep 2004 17:13:52 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A672E33F3C; Thu, 30 Sep 2004 17:13:52 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9C5683774F; Thu, 30 Sep 2004 17:13:52 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CCtGP-0005U0-00; Thu, 30 Sep 2004 17:13:57 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jhutz@cmu.edu, nisse@lysator.liu.se Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Cc: ietf-ssh@NetBSD.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Thu, 30 Sep 2004 17:13:57 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) writes: >I'm quite uncomfortable with this strong coupling between keyboard- >interactive and PAM. The way it is used on these PAM systems implies that >there are two different flavors of the protocol: PAM-less systems implement >userauthentication according to the userauth draft, PAM systems do it >according to the keyboard-interactive draft. And then clients implementing >the userauth draft (but not keyboard-interactive, which I'd consider more >experimental and less mature), won't interoperate with the latter type of >servers. That's exactly the problem I ran into. There are Linux systems now shipping that have OpenSSH set up to only allow keyboard-interactive auth, but the auth they're tunnelling through keyboard-interactive is standard password auth. Maybe the spec should state that where ambiguities exist (i.e. there are several ways to do the same thing), the simplest method and/or the one in the main RFC drafts should take precedence. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 01:34: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 BAA27587 for ; Thu, 30 Sep 2004 01:34:20 -0400 (EDT) Received: (qmail 15114 invoked by uid 605); 30 Sep 2004 05:34:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15088 invoked from network); 30 Sep 2004 05:34:16 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 30 Sep 2004 05:34:16 -0000 Received: from baragon.mindrot.org (unknown [61.95.66.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id 4B0CB27C187; Thu, 30 Sep 2004 15:30:02 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id 952F91BAD6D; Thu, 30 Sep 2004 15:34:09 +1000 (EST) Message-ID: <415B9AD0.50609@mindrot.org> Date: Thu, 30 Sep 2004 15:34:08 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040827) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: jhutz@cmu.edu, nisse@lysator.liu.se, ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > That's exactly the problem I ran into. There are Linux systems now shipping > that have OpenSSH set up to only allow keyboard-interactive auth, but the auth > they're tunnelling through keyboard-interactive is standard password auth. > Maybe the spec should state that where ambiguities exist (i.e. there are > several ways to do the same thing), the simplest method and/or the one in the > main RFC drafts should take precedence. That is silly. It would require a SSH server implementation to somehow peek into what authentication methods PAM is using so that it could ensure that is isn't inadvertantly offering PAM password authentication in "keyboard-interactive" instead of PAM auth via "password". It is a moot point anyway, PAM doesn't provide any standard API for an application to determine what authentication modules are in use. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 03:24: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 DAA21877 for ; Thu, 30 Sep 2004 03:24:33 -0400 (EDT) Received: (qmail 22545 invoked by uid 605); 30 Sep 2004 07:24:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22526 invoked from network); 30 Sep 2004 07:24:31 -0000 Received: from shitei.mindrot.org (203.217.30.81) by mail.netbsd.org with SMTP; 30 Sep 2004 07:24:30 -0000 Received: from baragon.mindrot.org (unknown [61.95.66.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "baragon.mindrot.org", Issuer "mindrot.org root CA" (verified OK)) by shitei.mindrot.org (Postfix) with ESMTP id B958227C187; Thu, 30 Sep 2004 17:20:17 +1000 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id CAA551BAD6D; Thu, 30 Sep 2004 17:24:18 +1000 (EST) Message-ID: <415BB4A1.1040102@mindrot.org> Date: Thu, 30 Sep 2004 17:24:17 +1000 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20040827) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Jeffrey Hutzelman writes: > >>On Wednesday, September 29, 2004 03:47:16 +1200 Peter Gutmann >> wrote: >> >>>(That's pretty weird behaviour: You can't send it a standard password, >>>but you can send it the password dressed up as keyboard-interactive auth >>>provided you don't tell it that it's a password). >> >>You mean, that you don't randomly make up a submethod name that the server >>has never heard of? Well, yes. > > So OpenSSH's behaviour is as follows: > > 1. It immediately rejects attempts to auth.using any method it hasn't heard > of. This isn't entirely true: you can specify "method1,method2,method3" and sshd will allow authentication using method3 if the method1 and method2 don't exist. I'm not sure what you would have us do: kbdint doesn't seem to provide a way for a server to report supported methods to a client and I don't think it is correct to just ignore what a client has specified and continue with a random method that the server picks. Especially since the protocol isn't required to report exactly what method the server *has* actually picked in the SSH_MSG_USERAUTH_INFO_REQUEST packets. > 2. The methods it doesn't reject are undocumented. Well, they are documented in the source :) -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 11:56:42 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 LAA03145 for ; Thu, 30 Sep 2004 11:56:42 -0400 (EDT) Received: (qmail 9172 invoked by uid 605); 30 Sep 2004 15:56:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9163 invoked from network); 30 Sep 2004 15:56:39 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 30 Sep 2004 15:56:38 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa00429; 30 Sep 2004 11:55 EDT Date: Thu, 30 Sep 2004 11:55:46 -0400 From: Jeffrey Hutzelman To: Damien Miller , Peter Gutmann cc: nisse@lysator.liu.se, ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <2030140000.1096559746@minbar.fac.cs.cmu.edu> In-Reply-To: <415B9AD0.50609@mindrot.org> References: <415B9AD0.50609@mindrot.org> 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 Thursday, September 30, 2004 15:34:08 +1000 Damien Miller wrote: > Peter Gutmann wrote: >> That's exactly the problem I ran into. There are Linux systems now >> shipping that have OpenSSH set up to only allow keyboard-interactive >> auth, but the auth they're tunnelling through keyboard-interactive is >> standard password auth. Maybe the spec should state that where >> ambiguities exist (i.e. there are several ways to do the same thing), >> the simplest method and/or the one in the main RFC drafts should take >> precedence. > > That is silly. It would require a SSH server implementation to somehow > peek into what authentication methods PAM is using so that it could > ensure that is isn't inadvertantly offering PAM password authentication > in "keyboard-interactive" instead of PAM auth via "password". Of course, the administrator knows how PAM is configured, and if the only method they will be using is checking passwords against the UNIX passwd file, then they can configure "password" support. But if they want, say, Kerberos, which is supported by a PAM module, then turning on "password" will DO THE WRONG THING. In this configuration OpenSSH is not "tunneling standard password". It's not "tunneling" anything; keyboard-interactive is not a wrapper around other userauth methods; it is its own method. The "password" method is "the user sends a password up front, which the server either accepts or not". That is not what keyboard-interactive does, and it is not how PAM works -- the model used by both of those is "ask the user a question; get an answer; repeat until you have everything you need". In some cases there is only one question which happens to be "what is your password?", but that is entirely up to the underlying PAM module which is making the determination as to who the user is and whether they should be allowed in. We can argue all we want about whether the model PAM uses is good or bad, but we are not in this working group going to change how PAM works, or the fact that SSH servers have to support it, or the fact that people will want to configure their machines with complex mechanisms that require a challenge, or more than one round trip, or something that is only available to them as a PAM module. We can argue all we want about whether it is a good or bad thing that Linux distributions come with OpenSSH configured to support keyboard-interactive but not password, but we are not in this working group going to change the fact that those vendors use PAM and support mechanisms that fall into one of the aforementioned categories. And, we cannot tell people how they must configure their machines. RFC2119 requirements language is not about assuring that all instances of everything will interoperate. It's about making sure that, given any arbitrary combination of implementations, it is _possible_ to configure them in an interoperable way. In practice, it is often not possible to get both complete interoperability and the features you want. Linux distributors want to support user login via Kerberos or challenge/response tokens or icky try-sending-a-password-to-LDAP-and-see-if-it-works, not to mention whatever other things someone comes up with in the future, and to accomplish that in a clean way they give up interoperability with ssh clients that don't support "password". As an operator of a distributed computing facility where support for our infrastructure including authentication is an absolute requirement, and as someone who is getting tired of porting an ancient 4.2BSD login to every new platform, I support that decision. It will make life a lot easier for me and a lot of other people, at the expense of making life slightly harder for the handful of people who have these machines and want to allow remote password-based (not public-key) ssh connections from clients which don't support keyboard-interactive, by requiring them to change a config file. -- 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 Thu Sep 30 12:04:59 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 MAA04040 for ; Thu, 30 Sep 2004 12:04:58 -0400 (EDT) Received: (qmail 13536 invoked by uid 605); 30 Sep 2004 16:04:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13527 invoked from network); 30 Sep 2004 16:04:58 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 30 Sep 2004 16:04:58 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa00443; 30 Sep 2004 12:04 EDT Date: Thu, 30 Sep 2004 12:04:45 -0400 From: Jeffrey Hutzelman To: Peter Gutmann , nisse@lysator.liu.se cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <2034810000.1096560285@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 Thursday, September 30, 2004 17:09:52 +1200 Peter Gutmann wrote: > Jeffrey Hutzelman writes: >> On Wednesday, September 29, 2004 03:47:16 +1200 Peter Gutmann >> wrote: >>> (That's pretty weird behaviour: You can't send it a standard password, >>> but you can send it the password dressed up as keyboard-interactive >>> auth provided you don't tell it that it's a password). >> >> You mean, that you don't randomly make up a submethod name that the >> server has never heard of? Well, yes. > > So OpenSSH's behaviour is as follows: > > 1. It immediately rejects attempts to auth.using any method it hasn't > heard of. > 2. The methods it doesn't reject are undocumented. I'll agree that's somewhat unfortunate, and I imagine it wouldn't hurt to change. Note that I have nothing to do with OpenSSH, so I can't do anything about it in any case. OTOH, "implementation-defined" does translate to "don't use this unless you know in advance what it will do". The expected behaviour is that clients won't set this field unless the user tells it to, and that users won't do that unless they know what is the correct thing to request. It's not expected that a non-empty value will work with a server whose capabilities you don't know in advance -- doing that would require creating a submethod registry, which moves us beyond the realm of "implementation-defined". That said, from a UI standpoint it seems like it would be useful to have a mechanism by which the server can choose to report what submethods it supports and provide a description for each, so that client can present the user with a set of choices. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 12:13:19 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 MAA04967 for ; Thu, 30 Sep 2004 12:13:19 -0400 (EDT) Received: (qmail 18880 invoked by uid 605); 30 Sep 2004 16:13:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18871 invoked from network); 30 Sep 2004 16:13:19 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 30 Sep 2004 16:13:19 -0000 Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa00463; 30 Sep 2004 12:12 EDT Date: Thu, 30 Sep 2004 12:12:30 -0400 From: Jeffrey Hutzelman To: Damien Miller , Peter Gutmann cc: ietf-ssh@NetBSD.org Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Message-ID: <2036290000.1096560750@minbar.fac.cs.cmu.edu> In-Reply-To: <415BB4A1.1040102@mindrot.org> References: <415BB4A1.1040102@mindrot.org> 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 Thursday, September 30, 2004 17:24:17 +1000 Damien Miller wrote: > I'm not sure what you would have us do: kbdint doesn't seem to provide a > way for a server to report supported methods to a client and I don't > think it is correct to just ignore what a client has specified and > continue with a random method that the server picks. Indeed. Imagine the scenario where a user has a Kerberos password and some kind of challenge/response token. Now, suppose the user comes in to work and leaves the token home. He wants to use Kerberos, so he sends a submethod list containing "kerb5". The server doesn't support "kerb5", because the method is called "krb5". Now, should the server (a) fail the exchange, reporting that it can't support any of the methods the user asked for (b) continue by arbitrarily selecting the method that requires the challenge/response token which the user left at home ? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 12:13:35 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 MAA05023 for ; Thu, 30 Sep 2004 12:13:34 -0400 (EDT) Received: (qmail 19219 invoked by uid 605); 30 Sep 2004 16:13:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19210 invoked from network); 30 Sep 2004 16:13:34 -0000 Received: from groucho.itss.auckland.ac.nz (HELO smtpa.itss.auckland.ac.nz) (130.216.190.11) by mail.netbsd.org with SMTP; 30 Sep 2004 16:13:33 -0000 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 95A783479A; Fri, 1 Oct 2004 04:13:32 +1200 (NZST) 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 21299-16; Fri, 1 Oct 2004 04:13:32 +1200 (NZST) 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 7A0FE34775; Fri, 1 Oct 2004 04:13:30 +1200 (NZST) Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A885D3774F; Fri, 1 Oct 2004 04:13:30 +1200 (NZST) Received: from pgut001 by medusa01 with local (Exim 3.36 #1 (Debian)) id 1CD3Yq-0005r7-00; Fri, 01 Oct 2004 04:13:40 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: maf@appgate.com, pgut001@cs.auckland.ac.nz Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft Cc: ietf-ssh@NetBSD.org, nisse@lysator.liu.se In-Reply-To: <20040929070243.D6EDC6C007@shala.firedoor.se> Message-Id: Date: Fri, 01 Oct 2004 04:13:40 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Martin Forssen writes: >It is very true that the draft assumes that. A fair indicator is that the >name contains the word "interactive". I just assumed that was historical baggage, and because draft-ietf-secsh-auth- everything-imaginable-except-password-and-publickey.txt would be too long for the IETF drafts directory. In any case the proper title is actually "Generic Message Exchange Authentication", which is a more accurate description of how it's being used. >My rationale when starting to do this was that I had a new authentication >token (cryptocard) which I wanted to use but I realized that I would have to >upgrade all my clients to add support for it. And when another token came out >I would have to upgrade again. I wanted to design a protocol so we could add >new authentication methods without having to modify the installed client >base. Fair enough. Since it's now being used as a kitchen-sink authentication mechanism though, it would be good to at least have an implementation- considerations section on non-interactive auth, warning implementors that (for example) unless they absolutely know there'll always be a real user at the other end, they should be careful to avoid creating things that require humans in the loop. SSH is being used in all sorts of embedded devices and whatnot where there's no user to handle arbitrary requests, without appropriate cautions people may be shipping systems that break in this environment when a small amount of forethought could prevent this. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Sep 30 19:32: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 TAA13728 for ; Thu, 30 Sep 2004 19:32:21 -0400 (EDT) Received: (qmail 6213 invoked by uid 605); 30 Sep 2004 23:32:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6204 invoked from network); 30 Sep 2004 23:32:16 -0000 Received: from relais.videotron.ca (24.201.245.36) by mail.netbsd.org with SMTP; 30 Sep 2004 23:32:16 -0000 Received: from xoxoxo ([69.157.206.253]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I4V008JHO0GPV@VL-MO-MR001.ip.videotron.ca> for ietf-ssh@netbsd.org; Thu, 30 Sep 2004 19:31:33 -0400 (EDT) Date: Thu, 30 Sep 2004 19:31:32 -0400 From: Members Only Subject: ::DTV P4/P5 Update Details Inside:: To: P4 And P5 Subscribers Message-id: <38779-220049430233132808@xoxoxo> Organization: Members Only 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 The P400 Universal P4/P5 Adapter All Channel Opener 209$ and rising Package includes 1 Universal IRD P400 Unit and A step by step 4 Page Simple Setup Guide Call us now to order 1-888-252-8508 or 1-888-252-8509 We would like to express our deepest thanks to the Henseng P400 Crew for making it possible for this long wait to happen.Due to the ever so popular High demand for our units weare making it possible for you to take advantage of our specials that are happening right now.Incase you were left out on the last email The P400 is the Ultimate solution in All channels open on Your DirecTv Systems.In plain english the unit will open all your PPV stations open as well as Your favourite channels.The Idea is to have a basic Subscription With DTV and you are all set.There is a step by step guide that any 4 year old child can figure out so please be minimul on your questions,This booklet is included with Purchase The P400 Universal P4/P5 Adapter All Channel Opener 209$ Call us now to order 1-888-252-8508 or 1-888-252-8509 Steps are as Follows 1.Unplug COAXIAL cable from back of your DTV reciever 2.Simply Plug in the back of your NEW P400 Adapter 3.Plug P400 directly in the satellite IN on your recievers backing 4.Make sure that your Telephone wire is UNHOOKED before using. 5.Power on Recievers power and begin watching your favourite channels Remember that we are open Until 12am Western Time Zone For those who are behind on hours.Act now and take full advantage of our The P400 Universal P4/P5 Adapter All Channel Opener and Sales Reps and Staff.Thanks for the testers that made it possible for this to happen. Special Thanks To- Knight_Rider401,UltraDssCrackCrew,Romprotectuur,and last but not least the IRC crew P4ChannelHackerzTeam For making this so Awesome Call us now to order 1-888-252-8508 or 1-888-252-8509 Hensang Imports P400