From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 1 22:53:14 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11950 for ; Wed, 1 Dec 2004 22:53:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 182FA5309; Thu, 2 Dec 2004 03:53:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from shitei.mindrot.org (shitei.mindrot.org [203.217.30.81]) by mail.netbsd.org (Postfix) with ESMTP id 7DF97518C for ; Thu, 2 Dec 2004 03:53:04 +0000 (UTC) Received: from baragon.mindrot.org (adsl-226-34.swiftdsl.com.au [218.214.226.34]) (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 5AD2727C187; Thu, 2 Dec 2004 14:19:30 +1100 (EST) Received: from mindrot.org (localhost [127.0.0.1]) by baragon.mindrot.org (Postfix) with ESMTP id DF7BC1BADD6; Thu, 2 Dec 2004 14:25:57 +1100 (EST) Message-ID: <41AE8B45.6030207@mindrot.org> Date: Thu, 02 Dec 2004 14:25:57 +1100 From: Damien Miller User-Agent: Mozilla Thunderbird 0.5 (X11/20041003) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Cc: ietf-ssh@NetBSD.org Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> In-Reply-To: <87653o3a78.fsf@luminous.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sam Hartman wrote: > > Hi. A discussion in the IETF 61 secsh meeting re-opened the issue of > how to handle password normalization for passwords received by the > server. The ssh protocol had adopted a significantly different > solution to this problem than the sasl plain mechanism. This concerns > me; I want to either solve the problem of password normalization in a > consistent manner or to understand why the ssh requirements are > different than the sasl requirements. What are the threats that this normalisation is intended to address? I'm wary of any recommendations to substantively change the protocol, especially ones that require implementation of a 91-page RFC (stringprep) + SASLprep in the privileged path of a server. -d From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 1 23:45:56 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15724 for ; Wed, 1 Dec 2004 23:45:56 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 364D75328; Thu, 2 Dec 2004 04:45:52 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 8FA29531F for ; Thu, 2 Dec 2004 04:45:50 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA23451; Wed, 1 Dec 2004 23:17:20 -0500 (EST) From: der Mouse Message-Id: <200412020417.XAA23451@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Wed, 1 Dec 2004 23:10:06 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Normalization of passwords in SASL and SSH In-Reply-To: <41AE8B45.6030207@mindrot.org> References: <87653o3a78.fsf@luminous.mit.edu> <41AE8B45.6030207@mindrot.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> Hi. A discussion in the IETF 61 secsh meeting re-opened the issue >> of how to handle password normalization for passwords received by >> the server. As an implementer, writing code for use on systems where usernames and passwords as handled by the OS are octet sequences rather than character sequences, I think that any such specification is a mistake. If such language survives, I will have to either blow off conformance to that aspect of the spec or simply reject non-ASCII usernames and passwords out of hand, since for non-ASCII strings I have no way, no way whatsoever, to tell whether the octet sequence stored in the OS's database corresponds in any useful way to the character sequence I get on the wire. (The information regarding what, if any, characters those octet sequences are intended to correspond to quite probably is not stored anywhere except human minds.) Similar remarks apply to file names. Not to mention that, as Damien points out, any such normalization, even on systems where usernames and passwords _are_ character sequences, involves a lot of complexity in a rather critical path. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 2 06:29:37 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02419 for ; Thu, 2 Dec 2004 06:29:36 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id BAF7351B2; Thu, 2 Dec 2004 11:29:04 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by mail.netbsd.org (Postfix) with ESMTP id 3935B5173 for ; Thu, 2 Dec 2004 11:29:03 +0000 (UTC) Received: by luminous.mit.edu (Postfix, from userid 1000) id 4913076C38; Thu, 2 Dec 2004 06:29:01 -0500 (EST) To: Damien Miller Cc: ietf-ssh@NetBSD.org Subject: Re: Normalization of passwords in SASL and SSH References: <87653o3a78.fsf@luminous.mit.edu> <41AE8B45.6030207@mindrot.org> From: Sam Hartman Date: Thu, 02 Dec 2004 06:29:01 -0500 In-Reply-To: <41AE8B45.6030207@mindrot.org> (Damien Miller's message of "Thu, 02 Dec 2004 14:25:57 +1100") Message-ID: <871xe9djlu.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Damien" == Damien Miller writes: Damien> Sam Hartman wrote: >> Hi. A discussion in the IETF 61 secsh meeting re-opened the >> issue of how to handle password normalization for passwords >> received by the server. The ssh protocol had adopted a >> significantly different solution to this problem than the sasl >> plain mechanism. This concerns me; I want to either solve the >> problem of password normalization in a consistent manner or to >> understand why the ssh requirements are different than the sasl >> requirements. Damien> What are the threats that this normalisation is intended Damien> to address? This isn't about threats so much as interoperability. From an internationalization standpoint, we desire that if a user enters their password it will work regardless of what OS and client software they used to enter their password. Doing so requires normalization. Note that stringprep is already required by IDN. I suspect that we're going to end up needing implementations of IDN suitable for running in the TCB of a host even if ssh implementations do not end up needing IDN on the server side. Also, the normalization step does not strictly need to run in the privilege domain of the rest of the authenication component. Normalization is an operation on a string, yielding a string, requiring access only to a variety of tables. You want to isolate the normalization performed on behalf of one authentication context from that done on behalf of another context. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 3 07:46:02 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29743 for ; Fri, 3 Dec 2004 07:46:02 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2228D541F; Fri, 3 Dec 2004 12:45:54 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mail.netbsd.org (Postfix) with ESMTP id 27B025179 for ; Fri, 3 Dec 2004 12:45:52 +0000 (UTC) Received: from marketmailer ([69.28.232.110]) by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I850036I9ZX04@VL-MO-MR011.ip.videotron.ca> for ietf-ssh@netbsd.org; Fri, 03 Dec 2004 06:45:37 -0500 (EST) Date: Fri, 03 Dec 2004 06:45:33 -0500 From: TeamDssDepot Subject: Dtv Fta DishNetwork Holiday Specials Join Now To: DirecTv Dishnetwork Testers Message-id: <388-220041253114533809@marketmailer> Organization: TeamDssDepot 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 $$ DssDepot.org $$ Safe Discrete StanaPhone Order Lines: 1-631-925-4143 or 1-631-326-5604 ******************************************************* FREE SHIPPING ON ALL HARDWARE ITEMS NEW FREE-TO-AIR PRODUCT LINE AT WHOLESALE PRICES DIRECTV SUBSCRIPTION SERVICES ******************************************************* NOW TAKING COD ORDERS FOR ALL CANADIANS Say goodbye to all those lengthy television bills! Introducing our new free-to-air product line where we once again make YOUR testing experience a fun and enjoyable adventure!! Did you love programming the old HU Cards because they were just made for the "newbie"? Well if you thought that was easy you've got another thing coming. All our free-to-air products are extremely user friendly and are made for the newbie. Our software engineers have worked day in and day out to develop the extremely easy to use interfaces which are compatible with all computers and no programmers are required! We know there are several dealers out there selling similar products to what we offer, however we assure you that nobody can provide you with the amount of support as we do. We stand behind each and every single item we offer in our e-store, if you are unsatisfied, no problem you can return the product within 30 days for a refund. Now anyone that tells you that free-to-air receivers cannot ever go down is lying to you, we can tell you that re-programming is only required once or twice per year and it is so easy that you will probably start doing it for fun. $$ DssDepot.org $$ Safe Discrete StanaPhone Order Lines: 1-631-925-4143 or 1-631-326-5604 ******************************************************* FREE SHIPPING ON ALL HARDWARE ITEMS NEW FREE-TO-AIR PRODUCT LINE AT WHOLESALE PRICES DIRECTV SUBSCRIPTION SERVICES ******************************************************* NOW TAKING COD ORDERS FOR ALL CANADIANS With Thanks Giving that just passed and Christmas approaching, what better to get one of your friends or a loved one than one of our ultimate receivers? Nobody can say No to FREE TV! :-) Aside from having amazing Free-2-Air products, we also offer a complete Dish Network product line which features Atmega cards, Magic cards, ISO Programmers, Jtags, Magic Locks and tons more. We assure you that no other dealer can compete with our prices, and to put the icing on the cake, we are offering FREE SHIPPING on all Dish Network hardware items for a limited time only. Where else can you purchase an Atmega card for $30 flat if not DssDepot? $$ DssDepot.org $$ Safe Discrete StanaPhone Order Lines: 1-631-925-4143 or 1-631-326-5604 ******************************************************* FREE SHIPPING ON ALL HARDWARE ITEMS NEW FREE-TO-AIR PRODUCT LINE AT WHOLESALE PRICES DIRECTV SUBSCRIPTION SERVICES ******************************************************* NOW TAKING COD ORDERS FOR ALL CANADIANS Are we safe to order from? You bet we are. We gladly accept Visa and Master Cards via our two secure payment processors, one located in St. Kitts and the other in Singapore. Our domain is hosted in China and our telephone services are provided by a secure and discrete company called StanaPhone that provide Voice Over Ip services. To conclude this brief message, we'd like to invite you to visit our e-store today. If you are interested in any products feel free to call us and speak to our helpful sales team, don't be shy, we are here to HELP! Power TV Beyond $$ DssDepot.org $$ From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 3 12:59:40 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09229 for ; Fri, 3 Dec 2004 12:59:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EC96D5469; Fri, 3 Dec 2004 17:59:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.netbsd.org (Postfix) with ESMTP id 032F85252 for ; Fri, 3 Dec 2004 17:59:23 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Dec 2004 11:07:06 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB3Hv9Kf017002 for ; Fri, 3 Dec 2004 09:59:12 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA08420 for ; Fri, 3 Dec 2004 09:40:12 -0800 (PST) Date: Fri, 3 Dec 2004 09:40:12 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: The use of "name-list" in the core IDs. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I would like to make sure that I've made the right changes to the documents with respect to "name-lists", as I havn't gotten any responses back from the ID announcements. Below is the section from [ARCH] that details a "name-list". I made very minor edits from [ARCH]-18 to [ARCH]-19 for this. Below that are the pertinent changes to the other IDs. ========================================================================= 5. Data Type Representations Used in the SSH Protocols ...skip some... name-list A string containing a comma-separated list of names. A name-list is represented as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of zero or more names. A name MUST be non-zero length, and it MUST NOT contain a comma (","). Context may impose additional restrictions on the names; for example, the names in a name-list may have to be valid algorithm identifier (see Section 6 below), or [RFC3066] language tags. The order of the names in a name-list may or may not be significant. Again, this depends on the context where the list is used. Terminating NUL characters are not used; neither for the individual names, nor for the list as a whole. Examples: value representation (hex) ----- -------------------- (), the empty name-list 00 00 00 00 ("zlib") 00 00 00 04 7a 6c 69 62 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 ========================================================================= Immediately below is the changed section in [TRANS]-21. "name-list" replaces "string" in each of the lines below. Other things were modified in this section to reflect the changes from "string" to "name-list". (I have a typo in [TRANS]-21: s/listis/lists/ .) ========================================================================= 7. Key Exchange Key exchange (kex) begins by each side sending name-lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. ...some skipped... 7.1 Algorithm Negotiation Key exchange begins by each side sending the following packet: byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) name-list kex_algorithms name-list server_host_key_algorithms name-list encryption_algorithms_client_to_server name-list encryption_algorithms_server_to_client name-list mac_algorithms_client_to_server name-list mac_algorithms_server_to_client name-list compression_algorithms_client_to_server name-list compression_algorithms_server_to_client name-list languages_client_to_server name-list languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) ========================================================================= Immediately below is the changed section in [AUTH]-24. ========================================================================= 5.1 Responses to Authentication Requests If the server rejects the authentication request, it MUST respond with the following: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success The 'authentications that can continue' is a comma-separated name-list of authentication 'method name' values that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user. Already successfully completed authentications SHOULD NOT be included in the name-list, unless they really should be performed again for some reason. ========================================================================= All of these changes (and more :) can be found here: http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/ Can I get either an "Amen!" for these changes, or some guidance on getting them aligned with reality? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Dec 4 07:15:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23828 for ; Sat, 4 Dec 2004 07:15:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1882454D3; Sat, 4 Dec 2004 12:15:05 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by mail.netbsd.org (Postfix) with ESMTP id F229051A6 for ; Sat, 4 Dec 2004 12:15:01 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by sheffield.cnchost.com id HAA26654; Sat, 4 Dec 2004 07:08:09 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'Chris Lonvick'" , Subject: RE: The use of "name-list" in the core IDs. Date: Sat, 4 Dec 2004 13:08:08 +0100 Message-ID: <000001c4d9f9$ec6ac1c0$0a0a0a0a@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I believe the traditional syntax for name-lists might also be exampled ("", "zlib", "zlib,none"), because the ("zlib", "none") notation is not what actually appears in the protocol. Also I'm not sure how the charset is restricted, but I think it's restricted at least to US-ASCII, if not also the printable subset of it. Otherwise I believe it's fine. > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Chris Lonvick > Sent: Friday, December 03, 2004 18:40 > To: ietf-ssh@NetBSD.org > Subject: The use of "name-list" in the core IDs. > > > Hi, > > I would like to make sure that I've made the right changes to > the documents with respect to "name-lists", as I havn't > gotten any responses back from the ID announcements. Below > is the section from [ARCH] that details a "name-list". I > made very minor edits from [ARCH]-18 to [ARCH]-19 for this. > Below that are the pertinent changes to the other IDs. > > ============================================================== > =========== > 5. Data Type Representations Used in the SSH Protocols > > ...skip some... > > name-list > > A string containing a comma-separated list of names. A > name-list > is represented as a uint32 containing its length > (number of bytes > that follow) followed by a comma-separated list of zero or more > names. A name MUST be non-zero length, and it MUST NOT > contain a > comma (","). Context may impose additional restrictions on the > names; for example, the names in a name-list may have > to be valid > algorithm identifier (see Section 6 below), or > [RFC3066] language > tags. The order of the names in a name-list may or may not be > significant. Again, this depends on the context where > the list is > used. Terminating NUL characters are not used; neither for the > individual names, nor for the list as a whole. > > Examples: > > value representation (hex) > ----- -------------------- > (), the empty name-list 00 00 00 00 > ("zlib") 00 00 00 04 7a 6c 69 62 > ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c > 6e 6f 6e 65 > ============================================================== > =========== > > > Immediately below is the changed section in [TRANS]-21. > "name-list" replaces "string" in each of the lines below. > Other things were modified in this section to reflect the > changes from "string" to "name-list". (I have a typo in > [TRANS]-21: s/listis/lists/ .) > ============================================================== > =========== > 7. Key Exchange > > Key exchange (kex) begins by each side sending name-lists of > supported algorithms. Each side has a preferred algorithm in each > category, and it is assumed that most implementations at any given > time will use the same preferred algorithm. Each side MAY guess > which algorithm the other side is using, and MAY send an > initial key > exchange packet according to the algorithm if appropriate for the > preferred method. > > ...some skipped... > > 7.1 Algorithm Negotiation > > Key exchange begins by each side sending the following packet: > > byte SSH_MSG_KEXINIT > byte[16] cookie (random bytes) > name-list kex_algorithms > name-list server_host_key_algorithms > name-list encryption_algorithms_client_to_server > name-list encryption_algorithms_server_to_client > name-list mac_algorithms_client_to_server > name-list mac_algorithms_server_to_client > name-list compression_algorithms_client_to_server > name-list compression_algorithms_server_to_client > name-list languages_client_to_server > name-list languages_server_to_client > boolean first_kex_packet_follows > uint32 0 (reserved for future extension) > ============================================================== > =========== > > > Immediately below is the changed section in [AUTH]-24. > ============================================================== > =========== > 5.1 Responses to Authentication Requests > > If the server rejects the authentication request, it MUST respond > with the following: > > byte SSH_MSG_USERAUTH_FAILURE > name-list authentications that can continue > boolean partial success > > The 'authentications that can continue' is a comma-separated > name-list of authentication 'method name' values that may > productively continue the authentication dialog. > > It is RECOMMENDED that servers only include those 'method name' > values in the name-list that are actually useful. > However, it is not > illegal to include 'method name' values that cannot be used to > authenticate the user. > > Already successfully completed authentications SHOULD NOT > be included > in the name-list, unless they really should be performed again for > some reason. > ============================================================== > =========== > > > All of these changes (and more :) can be found here: > http://www.employees.org/~lonvick/secsh-wg/2004-nov-29/ > > > Can I get either an "Amen!" for these changes, or some > guidance on getting them aligned with reality? > > Thanks, > Chris > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 9 18:10:35 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25904 for ; Thu, 9 Dec 2004 18:10:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 580D254E6; Thu, 9 Dec 2004 23:10:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.netbsd.org (Postfix) with ESMTP id 379F15483 for ; Thu, 9 Dec 2004 23:10:09 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 09 Dec 2004 15:12:01 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9N90m4004523 for ; Thu, 9 Dec 2004 15:09:00 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA14199 for ; Thu, 9 Dec 2004 15:09:05 -0800 (PST) Date: Thu, 9 Dec 2004 15:09:05 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: New IDs 2004-dec-09 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, I've updated the IDs based upon comments from the past few weeks. http://www.employees.org/~lonvick/secsh-wg/2004-dec-09/ It may take a day or so for the ID Editors to get them into the repository. * A few nits in the definition of name-list in [ARCH]. * Minor changes to the description for naming key algorithms in [NUMBERS] and [TRANS]. ----------NUMBERS---------- 4.10 Key Exchange Method Names The Key Exchange Method Name describes a key-exchange method for the protocol [SSH-TRANS]. Note that for historical reasons, the name "diffie-hellman-group1-sha1" is used for a key exchange method using an Oakley group as defined in [RFC2412]. Subsequently, the Working Group attempted to follow the numbering scheme of group numbers from [RFC3526] with diffie-hellman-group14-sha1 for the name of the second defined name. This is considered an aberration and should not be repeated. Any future specifications of Diffie-Hellman key exchange using Oakley groups defined in [RFC2412] or its successors should be performed with care and a bit of research. ----------[TRANS] is very similar--- * Reverted to the prior version of the protocol version exchange in [TRANS]. * Reverted to "string user name in ISO-10646 UTF-8 encoding" in various places in [AUTH], and added a paragraph on normalizing. ----------[AUTH]---------- 8. Password Authentication Method: password (skip some) From an internationalization standpoint, it is desired that if a user enters their password the authentication process will work regardless of what OS and client software they are using. Doing so requires normalization. Systems supporting non-ASCII passwords SHOULD always normalize passwords and usernames whenever they are added to the database, or compared (with or without hashing) to existing entries in the database. SSH implementations that both store the passwords and compare them SHOULD use [I-D.ietf-sasl-saslprep] for normalization. ---------- Please review and let me know. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 10 16:17:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25384 for ; Fri, 10 Dec 2004 16:17:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 703FD52C6; Fri, 10 Dec 2004 21:17:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 44432516A for ; Fri, 10 Dec 2004 21:17:07 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15447; Fri, 10 Dec 2004 15:30:27 -0500 (EST) Message-Id: <200412102030.PAA15447@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-10.txt Date: Fri, 10 Dec 2004 15:30:27 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : C. Lonvick Filename : draft-ietf-secsh-assignednumbers-10.txt Pages : 21 Date : 2004-12-10 This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the SSH protocol. It is intended only for the initialization of the IANA registries referenced in the documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155750.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 10 16:17:48 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25436 for ; Fri, 10 Dec 2004 16:17:48 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0172954E0; Fri, 10 Dec 2004 21:17:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 8F7E353F3 for ; Fri, 10 Dec 2004 21:17:11 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15372; Fri, 10 Dec 2004 15:29:51 -0500 (EST) Message-Id: <200412102029.PAA15372@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-25.txt Date: Fri, 10 Dec 2004 15:29:51 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-userauth-25.txt Pages : 17 Date : 2004-12-10 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-25.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-25.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-25.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-25.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155728.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 10 16:18:08 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25498 for ; Fri, 10 Dec 2004 16:18:07 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DBD0C540B; Fri, 10 Dec 2004 21:17:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 5BF77523C for ; Fri, 10 Dec 2004 21:17:09 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15466; Fri, 10 Dec 2004 15:30:42 -0500 (EST) Message-Id: <200412102030.PAA15466@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-22.txt Date: Fri, 10 Dec 2004 15:30:41 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-transport-22.txt Pages : 31 Date : 2004-12-10 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-22.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-22.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-22.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155756.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 10 16:18:30 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25583 for ; Fri, 10 Dec 2004 16:18:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 44C535278; Fri, 10 Dec 2004 21:17:31 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 7E6D85401 for ; Fri, 10 Dec 2004 21:17:15 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15385; Fri, 10 Dec 2004 15:29:59 -0500 (EST) Message-Id: <200412102029.PAA15385@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-23.txt Date: Fri, 10 Dec 2004 15:29:59 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : C. Lonvick Filename : draft-ietf-secsh-connect-23.txt Pages : 24 Date : 2004-12-10 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-23.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-23.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-23.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155733.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155733.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 10 16:18:51 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25679 for ; Fri, 10 Dec 2004 16:18:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8A0925401; Fri, 10 Dec 2004 21:17:32 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.netbsd.org (Postfix) with ESMTP id 26BBB5244 for ; Fri, 10 Dec 2004 21:17:18 +0000 (UTC) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15399; Fri, 10 Dec 2004 15:30:08 -0500 (EST) Message-Id: <200412102030.PAA15399@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-20.txt Date: Fri, 10 Dec 2004 15:30:07 -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : C. Lonvick Filename : draft-ietf-secsh-architecture-20.txt Pages : 29 Date : 2004-12-10 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-20.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-20.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-20.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-10155744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-20.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-10155744.I-D@ietf.org> --OtherAccess-- --NextPart-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 13 10:31:45 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19444 for ; Mon, 13 Dec 2004 10:31:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 06040517D; Mon, 13 Dec 2004 15:31:35 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.netbsd.org (Postfix) with ESMTP id 3B9215172 for ; Mon, 13 Dec 2004 15:31:28 +0000 (UTC) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2004 07:30:13 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iBDFRKem007566 for ; Mon, 13 Dec 2004 07:30:10 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA19067 for ; Mon, 13 Dec 2004 07:22:48 -0800 (PST) Date: Mon, 13 Dec 2004 07:22:48 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: New Last Call: 'Tags for Identifying Languages' to BCP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi Folks, This is just FYI as some of you may not be on ietf-announce. The core IDs make use of RFC-3066 language tags and the document described below will probably replace that. Of note in this new document: -------------- 6. Changes from RFC 3066 The main goals for this revision of language tags were the following: 'Compatibility.' All valid RFC 3066 language tags (including those in the IANA registry) remain valid in this specification. Thus there is complete backward compatibility of this specification with existing content. In addition, this document defines language tags in such as way as to ensure future compatibility, and processors based solely on the RFC 3066 ABNF (such as those described in XML Schema version 1.0) will be able to process tags described by this document. ... -------------- Based upon that (and I havn't spent much time looking at the rest of the ID), I am not planning any changes to the core IDs. Thanks, Chris ---------- Forwarded message ---------- Date: Wed, 08 Dec 2004 17:56:15 -0500 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce Subject: New Last Call: 'Tags for Identifying Languages' to BCP The IESG has been considering - 'Tags for Identifying Languages ' as a BCP There have been considerable changes to the document since the initial last call, and the IESG would like the community to consider the changes. In addition, the authors have prepared text describing why this mechanism is needed as a replacement for the existing procedure; it is included below. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-01-05. The file can be obtained via http://www.ietf.org/internet-drafts/draft-phillips-langtags-08.txt Author's discussion of drivers for this work: Reasons for Enhancing RFC 3066 RFC 3066 and its predecessor, RFC 1766, define language tags for use on the Internet. Language tags are necessary for many applications, ranging from cataloging content to computer processing of text. The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats, including HTML, XML, and CLDR, as the best means of identifying languages and language preferences. This specification proposes enhancements to RFC 3066. Because revisions to RFC 3066 therefore have such broad implications, it is important to understand the reasons for modifying the structure of language tags and the design implications of the proposed replacement. Problems This specification, the proposed successor to RFC 3066, addresses a number of issues that implementers of language tags have faced in recent years: * Stability of the underlying ISO standards * Accessibility of the underlying ISO standards for implementers * Ambiguity of the tags defined by these ISO standards * Difficulty with registrations and their acceptance * Identification of script where necessary * Extensibility The stability, accessibility, and ambiguity issues are crucial. Currently, because of changes in underlying ISO standards, a valid RFC 3066 language tag may become invalid (or have its meaning change) at a later date. With much of the world's computing infrastructure dependent on language tags, this is simply unacceptable: it invalidates content that may have an extensive shelf-life. In this specification, once a language tag is valid, it remains valid forever. RFC 3066 Language Tags: A brief survey Tags defined by RFC 3066 take two forms. Most tags are formed using an ISO 639-1 (two-letter) or ISO 639-2 (three letter) language tag, optionally followed by an ISO 3166 country code. Tags formed in this manner are not individually registered and anyone can use such a combination of codes to identify their language preferences or the language of some piece of content. Because this system allows a broad range of tags to be formed by reference to the underlying standards, these tags are referred to as generative in nature. The generative system is very powerful and allows content authors and others to form and use very expressive tags without the need to engage in a long and arduous registration process. Examples of such tags are: * en-US (English as used in the United States) * fr-CA (French as used in Canada) * de-CH (German as used in Switzerland) * ja (Japanese) * ale-CA (Aleut as used in Canada) * ale-BE (Aleut as used in Belgium) While it is possible to generate tags that do not identify any likely real-world content, such as Aleut as used in Belgium, tags of this nature do not represent a serious problem. Consider the case of a database that can identify people by national origin and by hair color. It is not a problem that one could compose a query for blond Mongolians, even though no results would ever be returned. There are problems with the the RFC 3066 definition of generative tags, however. The ISO 639 and ISO 3166 standards are not freely available and evolve over time. For example, ISO 3166 has withdrawn tags in the past and, worse, then reassigned them to a different country altogether. As a result, it is difficult for implementers to obtain a correct list of codes and then ensure interoperability with other implementations of language tags. The other way to form an RFC 3066 tag is via registration with IANA. Tags registered with IANA identify a specific language, dialect or variation. Unlike the generative tags, the registered values cannot be combined with other standard subtags to form additional tags that are more descriptive. Examples of such tags are: * no-nyn (Nynorsk variation of Norwegian, deprecated: use 'nn' instead) * cel-gaulish * i-klingon (deprecated: use 'tlh' instead) * etc. Registration, besides being a long and arduous process, also presents a variety of problems for implementers. Although the tags are freely available, most implementations do not support these tags because they do not fit neatly into the generative system. Special logic is required to handle them, especially when performing language negotiation or fallback. In addition, many of the tags are deprecated because the registration process is less opaque and time-consuming than registering a language with ISO 639 MA/RA has historically been. Eventually ISO 639 does catch up and assign the language a code, resulting in overlapping tag choices. Implementations must also deal with the implications of multiple valid tags identifying what is essentially the same content. But most problematic is the lack of a relationship to the generative mechanism. Since each variation of a tag must be separately registered, language variations with a broad range of valid uses require an enormous number of registrations. For example, there are 8 registrations to deal with minor spelling reforms in the German language and these registrations cover just three countries where German is commonly spoken--and no countries where it is not the major language. Variations in languages with a broader diffusion (such as Chinese) may require 20 or more registrations to gain full coverage, sometimes of important distinctions. Solving the Problems This specification addresses each of these issues with a simple, elegant design that is compatible with existing language tags and implementations. This compatibility exists on several levels. All language tags, both generative and registered, that were valid under RFC 3066 are still valid under this specification. In addition, and very importantly, language tags that are newly defined by this specification are compatible with the ABNF syntax, matching, parsing, and other mechanisms defined by RFC 3066. Thus for an implementation of RFC 3066, all of the new tags defined by this specification are still in the form of valid registered tags, and will simply be dealt with in whatever fashion the implementation used to handle future registrations, those that were added to the registry after the implementation was created. In other words, tags formed under this specification that are unfamiliar to RFC 3066 implementations will be treated by those implementations as if they were registered tags from a future version of the 3066 registry. Subtags and the Registry The largest change in the specification is that it modifies the structure of the language tag registry. Instead of having to obtain lists of codes from five separate external standards (not all of which are easily available), the IANA registry will maintain a comprehensive list of valid subtags that can be used in the generative mechanism in a machine-parseable text format. This registry will continue to track the existing core standards and will start with the current list of valid codes. As future codes are assigned, the IANA registry will be updated to reflect the changes. Having a separate registry allows IANA language tags to resolve ambiguity and stability problems with the underlying standards. Language tags formed today will be guaranteed to maintain their validity and meaning essentially forever, something that is not true today. In addition, switching to a subtag registry changes the nature of registrations themselves. Instead of registering complete tags and therefore potentially having to register a very large number of them (complicating life for implementers and discouraging support for the registry), a single subtag can be generatively combined to form many useful tags. For example, one registered tag today is 'zh-Hans', which represents "Chinese written in the Simplified Chinese script". Only this tag is valid under RFC 3066. Useful tags such as 'zh-Hans-SG' (SG=Signapore) or 'zh-Hans-CN' are not valid. By switching to a registry in which 'Hans' is a registered subtag, any of these valid and useful tags can be formed generatively. In addition, the subtag registry will encourage implementers to support registered items, since the subtags will fit the generative mechanism and exception handling code will no longer be necessary. To prevent the IANA language registry filling up with deprecated entries, rules have also been introduced to curb harmful registrations that should be handled by the various ISO maintenance and registration authorities (such as ISO 639). The new structure and registry allows implementations to determine much more about tags, even in the absence of registry information. This is important because at any given point in time there will be a mixture of implementations that have different snapshots of the registry. The new structure allows these implementations to to interoperate effectively. In particular, the category of all subtags (as language, region, script, etc.) can be determined without reference to the particular version of the registry snapshot by the implementation. This allows for much more robust implementations, and greater compatibility over time. In addition, this specification also makes it possible, for the first time, to effectively test whether an implementation conforms to the specification. The problem with RFC 3066 is that to determine the status of an implementation produced at a given point, one has to reconstruct the historical contents of each of the ISO standards and the historical contents of the registry. This is a time-consuming and error-prone process. The new registry provides a complete, easily parseable file which provides the precise the contents of valid tags for any point in time. Additional Subtag Sources This specification introduces two additional international standards as sources for language tags. ISO 15924 represents script codes. (The example above of 'Hans' is from ISO 15924.) Writing system variations are often crucial to communicate, especially when selecting content using language negotiation. Addition of this standard will allow these distinctions to be formed generatively, rather than via individual registration. UN M.49 represents region and country codes. The UN M.49 standard is used by ISO 3166 to determine what a country is. The UN M.49 codes are used by this specification in two ways. First, if ISO 3166 reassigns a country code formerly associated with one country to another country (as it did in 2001 with the 'CS' code, formerly Czechoslovakia and now assigned to Serbia and Montenegro), then the UN M.49 code can be placed in the registry to preserve stability. Secondly, the UN M.49 standard defines regional codes for areas such as "Central and South America" which can be useful in forming language tags for larger regions. Future-Proofing: Private Use and Extensions Because of the widespread use of language tags, it is potentially disruptive to have periodic revisions of the core specification, despite demonstrated need. This specification addresses this problem by fully specifying the valid syntax of language tags, while providing for future, unforeseen, requirements. One of these mechanisms is the extlang subtags, which allows for future extensions of ISO 639, in particular, ISO 639-3. Private use subtags is another one of these mechanisms. In RFC 3066, any tag that was not registered or wholly made up of generative subtags must be completely tagged as private use. Recipients of such a tag are not allowed to infer any information from such a tag, except by private agreement. Thus if any private-use information needed to be included in the tag, the entire tag had to be private use; making the entire tag uninterpretable to other implementations. This specification allows for private use subtags in a particular, prescribed manner. Consider the IANA registered tag 'sl-nedis', which represents the Natisone dialect of Slovenian. The subtag 'sl' is a valid ISO 639-1 code for Slovenian. Prior to its registration with IANA, if users wished to tag content as being in the Natisone dialect, they had two choices for language tags: 'sl' and 'x-sl-nedis' (or similar). The first tag does not meet the need of distinguishing the text from other varieties of Slovenian, while the second one does not convey the relationship to Slovenian to outside processors (a human might look at the tag and infer Slovenian, but the 'sl' subtag doesn't necessarily represent that language). Under this specification, if a new dialect of Slovenian were needed (let's call it the 'xyzzy' dialect), a tag such as 'sl-x-xyzzy' can be used. In fact, a quite comprehensive amount of information can be communicated: 'sl-Latn-IT-x-xyzzy' would represent Slovenian written using the Latin script as used in Italy with some additional private distinguishing information (which implementations of this specification can match algorithmically). Note that RFC 3066 private use tags are still permitted and have the same information content and treatment as they did previously. The extension mechanism also provides a way for independent RFCs to define extensions to language tags. These extensions have a very constrained, well-defined structure to prevent extensions from interfering with implementations of this specification (or RFC 3066). Matching and Language Negotiation Content tagging is only one of the applications for language tags. The other major applications are querying for for matches and in content negotiation. RFC 3066 defines "language ranges" for use in content negotiation and querying and describes a very simple matching algorithm. This specification maintains compatibility with this language negotiation scheme, while providing additional information on the implementation of language matching. Well-Formed vs. Validating Existing language tag processors already fall into two categories. There are language tag processors that check if language tags have the proper, well-formed, syntax, but which do not validate their content, and there are language tag processors that in addition validate and reject unrecognized tags. Each of these categories is appropriate to different implementations. For example, to process incoming tags that may have been formed under a future registry, an implementation may restrict itself to only checking well-formedness. Another implementation that allows users to generate tags may fully validate. This specification clearly distinguishes these two possible classes of conformance, and provides an explicit, testable definition of each one. Impact of the New Design on Existing Implementations One concern that is crucial to acceptance of the new language tag design is how it works with existing implementations of RFC 3066 and how existing implementations will interact with implementations of the newer language tags. It is important to recognize that all language tags that were valid under the existing RFC 3066 will remain valid, with their meanings intact, under this specification. In fact, this specification stabilizes these meanings so that existing implementations can be continued forward for as long as it necessary. Content, regardless of its format, will remain valid, essentially forever. As content and systems begin to make use of the new language tags by adopting the additional fields defined by this specification, there will be an impact on software and systems that expect only the older tags. The design of this specification was carefully created so that all of the new values that can be assigned fit the pattern for registered language tags under RFC 3066. Thus while existing implementations will not recognize the meaning in the tags, they will be able to process them as if they were unrecognized-but-well-formed registered tags. In addition, although this specification acknowledges the possibility of alternate or advanced matching and negotiation strategies, it maintains the existing matching algorithm (by removing subtags from the right side of a language tag until a match is obtained), simply providing more detail on usage. Summary The authors of this specification have worked for the past year with a wide range of experts in the language tagging community to build consensus on a design for language tags that meets the needs and requirements of the user community. Language tags form a basic building block for natural language support in computer systems and content. The revision proposed in this specification addresses the needs of this community of users with a minimal impact on existing content and implementations, while providing a stable basis for future development, expansion, and improvement. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Dec 23 01:08:13 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24886 for ; Thu, 23 Dec 2004 01:08:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C256A52E9; Thu, 23 Dec 2004 06:08:06 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id BCFE15166 for ; Thu, 23 Dec 2004 06:08:03 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id BAA21429; Thu, 23 Dec 2004 01:08:02 -0500 (EST) From: der Mouse Message-Id: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Thu, 23 Dec 2004 00:10:32 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: latest drafts Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit I just fetched the latest drafts and looked over the diffs from my previous latest set (and in the process discovered that I skipped a set; a new set must have come out while I was busy with other things). Looking at the diffs between architecture-18 and -20, (about line 112) The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH s/J. /J./ surely? Looks to me as though something is mistaking the initial-marking dot for a sentence-ending dot. Somewhere around line 495, identifiers (see Section 6 below), or a list of [RFC3066] language tags. The order of the names in a name-list may, or may not be significant. Again, this depends on the context where the list is used. Terminating null characters MUST NOT be used; neither for I'd rather see "may or may not be" or "may, or may not, be" - but to put in one comma but not the other looks broken in a "half of one and half of the other" sort of way. (Personally I'd prefer the comma-free version, but I'd much rather see the two-comma version than what's there now.) About line 1321: display forwarding in SSH (or other, secure protocols), combined with s/other,/other/ surely? In assignednumbers-10, as diffed against -08: Around line 176, the same "Timo J. [ ]Rinne" issue as above. In sections 4.2 and 4.2.2, the table headings make it appear that the SSH_DISCONNECT_* names *are* the "description" strings appearing in an SSH_MSG_DISCONNECT packet, which I assume is false - if that were true, the "description" would carry no information not already present in the "reason code". Specifically, the (new) first two lines of text in 4.2.2 comes very close to stating that the table shows the strings as they must appear in a DISCONNECT packet. The text around line 425 further implies that the "description" strings are standardized, which I had thought was not the case - and which makes no sense because they then carry no information and might as well be skipped. Similar remarks apply to the like-named fields mentioned in 4.3 (lines 432 ff) and 4.3.2 (lines 445 ff). In 4.5.2, most of the symbolic names are missing TTY_OP_ prefixes. Is this deliberate? In any case, I have to question why PENDIN has an assignment. It is really dynamic tty driver internal state (exposed so, I suspect, a user program can force a reprint by setting it); it is not the sort of state bit that it makes any sense at all to push across the network. I very much like the text in 4.10 about the diffie-hellman-groupN-sha1 name debacle; I think the wording there is an excellent resolution given the mess that discussion turned into here. In connect-23, diffed against -21: The same "Timo J. [ ]Rinne" issue again. The remarks about TTY_OP_ values, above, also apply to the versions appearing here (starting around line 970). In transport-22, diffed against -20: "Timo J. [ ]Rinne" again. In userauth-25, diffed against -23: "Timo J. [ ]Rinne" again. All the same UTF-8 issues I've raised repeatedly, but apparently that is a lost cause; ssh implementations for traditional Unix systems, and others that use octet sequences rather than character sequences for the "version that matters", will just have to reject non-ASCII usernames, passwords, and file names out of hand. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 24 18:01:32 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19189 for ; Fri, 24 Dec 2004 18:01:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E143851CA; Fri, 24 Dec 2004 23:01:25 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (cs2876-92.austin.rr.com [24.28.76.92]) by mail.netbsd.org (Postfix) with ESMTP id A27A95197 for ; Fri, 24 Dec 2004 23:01:23 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 7C768E0063; Fri, 24 Dec 2004 17:37:23 -0500 (EST) To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> From: Sam Hartman Date: Fri, 24 Dec 2004 17:37:23 -0500 In-Reply-To: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Thu, 23 Dec 2004 00:10:32 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "der" == der Mouse writes: der> All the same UTF-8 issues I've raised repeatedly, but der> apparently that is a lost cause; ssh implementations for der> traditional Unix systems, and others that use octet sequences der> rather than character sequences for the "version that der> matters", will just have to reject non-ASCII usernames, der> passwords, and file names out of hand. My requirement as an IESG member is that it be possible to have a properly internationalized ssh. Among other things that means the characters in usernames and passwords need to belong to some character set. IETF character set policy requires one of the character sets we support be UTF8. Personally, I'd be delighted if you could work within this requirement and figure out implementation advice or language that made it possible/easier for people on Unix and other systems where local characters are not tagged with a character set. I believe the documents are acceptable if you don't manage to solve this problem; only accepting ASCII is one way to implement the protocol. I suspect people who find better solutions will have an advantage in certain markets. Naturally, it's Bill/the working group's decision how much time should be spent trying to solve this problem. Bill may well believe the problem has already been discussed to death and decide that it's not worth any more of the WG's time. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Dec 24 19:18:12 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24820 for ; Fri, 24 Dec 2004 19:18:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DC55353BD; Sat, 25 Dec 2004 00:18:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id C1D83538E for ; Sat, 25 Dec 2004 00:18:08 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA11104; Fri, 24 Dec 2004 19:18:07 -0500 (EST) From: der Mouse Message-Id: <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Fri, 24 Dec 2004 17:39:21 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> All the same UTF-8 issues I've raised repeatedly, > My requirement as an IESG member is that it be possible to have a > properly internationalized ssh. Among other things that means the > characters in usernames and passwords need to belong to some > character set. Why? Perhaps this is the fundamental part I'm missing. What does "properly internationalized" mean - or perhaps more precisely, what is there about being "properly internationalized" that demands that usernames, passwords, and filenames consist of character sequences rather than octet sequences? > Personally, I'd be delighted if you could work within this > requirement and figure out implementation advice or language that > made it possible/easier for people on Unix and other systems where > local characters are not tagged with a character set. I doubt that's possible, because the characters, if any, those octet sequences are intended to correspond to are not stored anywhere accessible to ssh (and indeed may not exist - the octet sequences may correspond to characters only coincidentally, by someone insisting on interpreting them as character codes, such as for display). > I believe the documents are acceptable if you don't manage to solve > this problem; only accepting ASCII is one way to implement the > protocol. I find that...well, unacceptable, really. There is no reason except administrative fiat that the various octet strings in question can't be real transparent octet strings, to be interpreted as characters, if at all, by mutual agreement between the entities doing so. For example, I, on a charset-blind system, may name some files with octet sequences that make sense in 8859-1 and others with octet sequences that make sense in KOI-8, relying on other information (stored nowhere but my wetware) to disambiguate which is which. There is no technical reason I couldn't sftp them to another, similarly charset-blind, system; it is purely fiat that would prevent it. Of course, it breaks when trying to sftp to a charset-aware filesystem, unless I choose to use UTF-8 on the charset-blind side. That's unavoidable, no matter what the standard says; interoperability between charset-string filesystems and octet-string filesystems without human help cannot be expected in any case. Similar remarks apply to usernames and passwords, though the examples I've come up with are more contrived. > I suspect people who find better solutions will have an advantage in > certain markets. I think my implementation, being for charset-blind systems, will treat such things as pure octet sequences. I may add an option to disallow non-ASCII (or perhaps just disallow anything that's not well-formed UTF-8), but if so it will be to satisfy protocol conformance pedants, and be documented as such. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Dec 26 08:26:34 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20136 for ; Sun, 26 Dec 2004 08:26:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A39E752A4; Sun, 26 Dec 2004 13:26:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by mail.netbsd.org (Postfix) with ESMTP id 14E60517A for ; Sun, 26 Dec 2004 13:26:25 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id E4B5034393 for ; Mon, 27 Dec 2004 02:04:13 +1300 (NZDT) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30081-20 for ; Mon, 27 Dec 2004 02:04:13 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id CC80A33FE7 for ; Mon, 27 Dec 2004 02:04:13 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C863E37742 for ; Mon, 27 Dec 2004 02:04:13 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CiY4M-0003X6-00 for ; Mon, 27 Dec 2004 02:04:22 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Comment on draft-ietf-secsh-transport-22.txt Message-Id: Date: Mon, 27 Dec 2004 02:04:22 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list I was just checking this again to see whether the signature-format problem had been resolved yet, the incompletely-specified X.509 format has been removed (phew!) but the totally unspecified SPKI format (RFC2693 specifies neither a cert nor signature format, that was in the long-expired draft-ietf-spki- certstructure, so it's not possible to provide either a cert or a "signature blob in format specific encoding") and the incompletely-specified PGP format (RFC2440 specifies a large number of options, signed attributes, packet types, etc etc for signatures) are still present. These should really be removed as well if it's not possible for anyone to implement them. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 27 17:12:50 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09819 for ; Mon, 27 Dec 2004 17:12:50 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8454552CC; Mon, 27 Dec 2004 22:12:45 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from fork.recoil.org (fork.recoil.org [194.70.3.132]) by mail.netbsd.org (Postfix) with SMTP id E015B52AF for ; Mon, 27 Dec 2004 22:12:43 +0000 (UTC) Received: (qmail 11184 invoked by uid 10000); 27 Dec 2004 22:06:03 -0000 Date: Mon, 27 Dec 2004 22:06:03 +0000 From: Anil Madhavapeddy To: ietf-ssh@NetBSD.org Cc: dave@recoil.org Subject: Window size for channels Message-ID: <20041227220603.GA12300@fork.recoil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm currently using http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-23.txt to implement an SSH2 server. I just wanted to confirm that the 'window size' defined per-channel is only affected by the 'data' field of an SSH_MSG_CHANNEL_DATA channel packet, and that no other packets have any effect (including the other fields in the SSH_MSG_CHANNEL_DATA or packet overhead such as padding). Section 5.2 does say that "The maximum amount of data allowed is the current window size. The window size is decremented by the amount of data sent". This implies that only the contents of a data packet apply to window size calculations. But then in Section 5.3, the SSH_MSG_CHANNEL_CLOSE message says: "This message does not consume window space and can be sent even if no window space is available." Why say this if no other messages ever consume window space? It implies that this message is special with respect to window flow control. Do other channel-specific messages do take up window space then? thanks for any comments, -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Dec 27 21:14:21 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27294 for ; Mon, 27 Dec 2004 21:14:20 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B7F6E51A3; Tue, 28 Dec 2004 02:14:14 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by mail.netbsd.org (Postfix) with ESMTP id 0A6835168 for ; Tue, 28 Dec 2004 02:14:12 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA29765; Mon, 27 Dec 2004 21:14:11 -0500 (EST) From: der Mouse Message-Id: <200412280214.VAA29765@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. Date: Mon, 27 Dec 2004 21:11:17 -0500 (EST) To: Anil Madhavapeddy , dave@recoil.org, ietf-ssh@NetBSD.org Subject: Re: Window size for channels In-Reply-To: <20041227220603.GA12300@fork.recoil.org> References: <20041227220603.GA12300@fork.recoil.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I just wanted to confirm that the 'window size' defined per-channel > is only affected by the 'data' field of an SSH_MSG_CHANNEL_DATA > channel packet, and that no other packets have any effect (including > the other fields in the SSH_MSG_CHANNEL_DATA or packet overhead such > as padding). This is not so; of SSH_MSG_CHANNEL_EXTENDED_DATA messages, connect-23 writes Data sent with these messages consumes the same window as ordinary data. > But then in Section 5.3, the SSH_MSG_CHANNEL_CLOSE message says: > "This message does not consume window space and can be sent even if > no window space is available." > Why say this if no other messages ever consume window space? I don't know; I didn't write it - but I speculate it's to avoid confusing people who know that in TCP, the FIN bit - the closest analog to ssh's CLOSE message - _does_ consume sequence number space. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Dec 29 15:11:04 2004 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07031 for ; Wed, 29 Dec 2004 15:11:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D24FC52BD; Wed, 29 Dec 2004 20:10:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mail.netbsd.org (Postfix) with ESMTP id BC19651E6 for ; Wed, 29 Dec 2004 20:10:55 +0000 (UTC) Received: by mail.lysator.liu.se (Postfix, from userid 1646) id AC02E6BE8C; Wed, 29 Dec 2004 21:10:53 +0100 (MET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 9EDCB2A695; Wed, 29 Dec 2004 21:10:49 +0100 (MET) Received: from sellafield.lysator.liu.se (smmsp@localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id iBTKAnbY023308; Wed, 29 Dec 2004 21:10:49 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id iBTKAiP7023305; Wed, 29 Dec 2004 21:10:44 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider" Cc: "'Chris Lonvick'" , Subject: Re: The use of "name-list" in the core IDs. References: <000001c4d9f9$ec6ac1c0$0a0a0a0a@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: 29 Dec 2004 21:10:44 +0100 In-Reply-To: <000001c4d9f9$ec6ac1c0$0a0a0a0a@nucleus> Message-ID: Lines: 46 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 "denis bider" writes: > I believe the traditional syntax for name-lists might also be exampled ("", > "zlib", "zlib,none"), because the ("zlib", "none") notation is not what > actually appears in the protocol. I think it was I who wrote the original version of this text. The point is to make it clear that the three given examples represents lists containing zero, one and two elements, on a somewhat abstract level. In particular, extra clarity is needed for the case of the empty list. To me, the proposed text is clear enough. : Examples: : : value representation (hex) : ----- -------------------- : (), the empty name-list 00 00 00 00 : ("zlib") 00 00 00 04 7a 6c 69 62 : ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 > Also I'm not sure how the charset is restricted, but I think it's > restricted at least to US-ASCII, if not also the printable subset of > it. I think "anything but comma and NUL" is the only appropriate restriction at this place (I would even allow NUL, but I guess using NUL in the elements might be confusing). Context implies additional requirements: For lists of algorithm identifiers, there are restrictions to ascii-only, on the length of the elements, and on the use of the @-character. For lists of language tags, requirements are different (I'm not really familiar with them). I don't think all those details need or should be duplicated in the description of the name-list type. We may want to reuse the same type for new purposes, even ones using non-ascii identifiers in some way. > Otherwise I believe it's fine. To me the proposed text looks fine as is. I won't object if anybody wants to tweak the syntax used in the examples, but I don't think it is needed. Regards, /Niels