From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 3 21:07:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16494 for ; Mon, 3 Jan 2005 21:07:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9DBCE51E1; Tue, 4 Jan 2005 02:07:22 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) by mail.netbsd.org (Postfix) with ESMTP id 14C0C515B for ; Tue, 4 Jan 2005 02:07:20 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 0BFB3E0063; Mon, 3 Jan 2005 20:39:00 -0500 (EST) To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> From: Sam Hartman Date: Mon, 03 Jan 2005 20:39:00 -0500 In-Reply-To: <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Fri, 24 Dec 2004 17:39:21 -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: >>> 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. der> Why? Perhaps this is the fundamental part I'm missing. What der> does "properly internationalized" mean - or perhaps more der> precisely, what is there about being "properly der> internationalized" that demands that usernames, passwords, der> and filenames consist of character sequences rather than der> octet sequences? I'd appreciate replies off-list as I believe we are outside of the scope of this working group. Humans use our software. They typically enter characters using an input method for items such as usernames, passwords and filenames. One input method that is relatively common is a keyboard that maps keycodes to characters. This method tends to be mostly OK even if you assume it produces octets not charactares. Other input methods produce different octet sequences for semantically similar content. I gave an example of combining accents vs single characters in the message introducing this thread. So, the set of octets produced depends not so much on what the user does, what keys they press, or even what is displayed on their screen; it depends on implementation details of the input method the user's OS happens to use. The user does not typically have enough control (and almost certainly has insufficient knowledge) to end up with the other octet sequences that are the same semantic content. So, if we treat passwords as octet-strings then whether the user can type their username or password will depend on what input method they are using. They may not even have control over this. We, the IETF, e have decided for the most part that interoperability requires that things work independent of what input method is used. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 4 00:50:35 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27802 for ; Tue, 4 Jan 2005 00:50:34 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3424252C8; Tue, 4 Jan 2005 05:50:29 +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 AC83D52C6 for ; Tue, 4 Jan 2005 05:50:26 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA01364; Tue, 4 Jan 2005 00:50:25 -0500 (EST) From: der Mouse Message-Id: <200501040550.AAA01364@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 4 Jan 2005 00:23:55 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> 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? > I'd appreciate replies off-list as I believe we are outside of the > scope of this working group. In general, perhaps, but insofar as it bears on implementing ssh, I am inclined to disagree - which is why I'm replying on-list anyway. > [...] > We, the IETF, e have decided for the most part that interoperability > requires that things work independent of what input method is used. As I see it, this amounts to "the IETF position is that humans think of these things as character strings, so we demand that they be handled as character strings by the protocol". What is the IETF position, then, on how someone such as me should handle the situation I'm faced with: writing software specified from this point of view (ssh, in my case) for systems on which these entities are _not_ character strings (a fairly traditional Unix variant, NetBSD in my case)? I'm faced with an encoding-agnostic filesystem interface and implementation, wherein filename components are sequences of octets not including 0x00 and 0x2f, independent of any characters; I'm faced with password hashing routines that work with octet strings, not character strings; etc. Are such systems beyond the pale for the IETF, and I can do anything I want, with a suggestion that I try to stay within something like the spirit of the spec? Is it simply not possible to implement ssh (or anything else specified with similar normalization rules) on such a system within the spec without converting all the affected code (filename, username, and password handling in ssh's case) to the character-string paradigm? Am I required to reject attempted non-ASCII strings in these places for no reason other than an inability to know what the user intended the character set - if any - to be? (For that matter, what grounds are there for assuming that octets in the ASCII range are intended to correspond to ASCII characters, rather than, say, KOI-7?) Or what? Given how common such systems are, it seems a bit odd that the IETF would take a position so apparently incompatible with them. As an implementer I find the situation rather confusing; there's obviously something I don't understand going on, and I'd like to know what the IETF's idea of the right thing for me to do here is. /~\ 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 Tue Jan 4 02:47:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20653 for ; Tue, 4 Jan 2005 02:47:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 395A15219; Tue, 4 Jan 2005 07:47:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by mail.netbsd.org (Postfix) with ESMTP id 5690151DE for ; Tue, 4 Jan 2005 07:47:00 +0000 (UTC) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j047dLe7008062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 4 Jan 2005 02:39:22 -0500 (EST) Message-ID: <41DA48A6.5070306@columbia.edu> Date: Tue, 04 Jan 2005 02:41:26 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040201090305050303090804" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms040201090305050303090804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit der Mouse wrote: > As I see it, this amounts to "the IETF position is that humans think of > these things as character strings, so we demand that they be handled as > character strings by the protocol". Absolutely not. The IETF position is that if I am attempting to login to machine H via SSH, I should be able to do so by knowing the necessary bits: username, password, etc. The requirement is that no matter what user interface I use to enter these bits, I should be able to successfully authenticate. Now if I happen to be in front of a keyboard based interface which is Unicode aware and happens to generate "SMALL LETTER u WITH DIAERESIS" as two code points represented as two 32-bit values or 8 octets instead of the non-Unicode aware system which uses a single code point represented as a single byte, I have a problem. I type exactly the same thing on both keyboards and get extremely different octet strings. Are you telling me that once I configure a login to work from one particular platform and user interface configuration that I should be locked into that choice exclusive of all the other system types and user input methods which are available? I would find it hard to believe that anyone could decide that this is desireable. > What is the IETF position, then, on how someone such as me should > handle the situation I'm faced with: writing software specified from > this point of view (ssh, in my case) for systems on which these > entities are _not_ character strings (a fairly traditional Unix > variant, NetBSD in my case)? I'm faced with an encoding-agnostic > filesystem interface and implementation, wherein filename components > are sequences of octets not including 0x00 and 0x2f, independent of any > characters; I'm faced with password hashing routines that work with > octet strings, not character strings; etc. As an AFS developer I am very sympathetic to the situation. Unfortunately. there are no true raw octet strings. Octet sequences are created within a context and without knowing the context it is not possible to properly manipulate the octets. At the present time AFS does not support a notion of storing character-set context information. This causes severe problems for users who want to access the names associated with directories and files from heterogeneous systems. File names created from most Unix user interfaces in Western Europe will produce strings using Latin-1 code points. Those from Eastern Europe will use Latin-2. Linux systems may store unnormalized UTF-8. Windows systems will store one of the many IBM/MS DOS OEM code pages. A name created on one system not only will be displayed to users of another system something which is incorrect but the name may be something which is completely unparsable. At the moment the only safe set of strings that can be used are those restricted to US-ASCII. This is because US-ASCII is the only common set of values which will be properly interpretted without additional context information which is not available. In the the long run we are going to need to fix AFS to do one of two things: (1) store context information associating the character set used to create each name AND provide the means necessary for file servers to be able to translate names from one character set to all the other possible sets. (2) provide support for a normalized character set which is inclusive of all characters which users may be able to enter. Having worked on the character set translation capabilities of C-Kermit I can tell you that storing context information and providing translation is lossy and imperfect. UNICODE solves the problem in a much nicer and heterogeneous manner. It is by no means perfect but biting the bullet and supporting it makes the end user experience oh so much nicer. In the coming year I will be adding UNICODE support to AFS. I expect that all file systems will have to provide support for it in the years to come. Operating systems which do not provide support for character set processing will find a smaller and smaller percentage of users. > Are such systems beyond the pale for the IETF, and I can do anything I > want, with a suggestion that I try to stay within something like the > spirit of the spec? Is it simply not possible to implement ssh (or > anything else specified with similar normalization rules) on such a > system within the spec without converting all the affected code > (filename, username, and password handling in ssh's case) to the > character-string paradigm? Am I required to reject attempted non-ASCII > strings in these places for no reason other than an inability to know > what the user intended the character set - if any - to be? (For that > matter, what grounds are there for assuming that octets in the ASCII > range are intended to correspond to ASCII characters, rather than, say, > KOI-7?) You have to draw the line somewhere if you are going to make progress at improving cross platform user experience. Systems without support for character-set processing are useful only when all of the systems they share information with are used in exactly the same context. In a distributed heterogeneous environment such as the Internet, this assumption cannot be made. If a system wants to assume that all of its local input is in KOI-7 and an SSH implementation wants to be able to support that, then the implementation must provide for character set translation from KOI-7 to UNICODE. If you need such translation tables, they are available from the UNICODE consortium and are implemented within a wide number of open source packages. > Or what? > > Given how common such systems are, it seems a bit odd that the IETF > would take a position so apparently incompatible with them. As an > implementer I find the situation rather confusing; there's obviously > something I don't understand going on, and I'd like to know what the > IETF's idea of the right thing for me to do here is. You do what Kermit has done since 1981. When moving information between systems you convert from the local character set to a network neutral form and then the receiver converts its local form. Before the advent of UNICODE Kermit was forced rely on the user to choose an intermediary character-set which would be inclusive of all characters used and be understood by both systems. When this was not possible, substitution rules and best guesses forced the data stream to become lossy. With the availability of UNICODE the available set of characters which can be sent without loss has been greatly enhanced. Normalization rules are used to prevent multiple representations of a common input form from preventing interoperability. While this has a negative impact on the ability to display strings to the end user after use; it enhances the ability to provide for cross platform comparison and computation. Jeffrey Altman --------------ms040201090305050303090804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMTA0MDc0MTI2WjAjBgkqhkiG9w0BCQQxFgQU+vLpWF6k7Z2lbBo98L1kTs6pZM4w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAuoA3lsCAVr2WEnP+6y90iBW6PPxxgiCQLK0H/BkW 9hgggFEFxXTag2TywTjWMcuuOC+Gz/2H+a4YLYB9Ys6dd2Hd1AzzUkyw49UQXSe87/i3V93j wf7iJmWW0XCy8meAwdXGYXcVOc7u86mHdeYkHP32zm891t5uD1GAgBvd5qXBILIksQdHj4Um 0oIRZfznpSJiTSvZ0zOddl6jj8cTsOkHCeW92egs28yTWGmTWG9lU3kcNbpmudE2lAfdtTSn 6Rm6kjL2hfO3fXJzO9f3u746rEH/v654xyoRNrUJMJtDsWr+DVjwuKqUnWD6KZhI2T1xPurT taGDa//fmsoOLAAAAAAAAA== --------------ms040201090305050303090804-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 4 07:45:24 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07299 for ; Tue, 4 Jan 2005 07:45:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E5C8252F1; Tue, 4 Jan 2005 12:45:15 +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 C4CE65171 for ; Tue, 4 Jan 2005 12:45:13 +0000 (UTC) Received: by mail.lysator.liu.se (Postfix, from userid 1646) id 38F182498E9; Tue, 4 Jan 2005 13:45:12 +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 EA8502498F3; Tue, 4 Jan 2005 13:45:07 +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 j04Cj7bY021252; Tue, 4 Jan 2005 13:45:07 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j04Cj2mL021249; Tue, 4 Jan 2005 13:45:02 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 04 Jan 2005 13:45:01 +0100 In-Reply-To: <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 61 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 der Mouse writes: > I'm faced with an encoding-agnostic > filesystem interface and implementation, wherein filename components > are sequences of octets not including 0x00 and 0x2f, independent of any > characters; Please leave the file system issues out of it for now. What's of primary importantance are the core drafts, and those deal with usernames and passwords in utf8 form, *not* file names. The issues for filenames, e.g. in sftp, are slightly different, and not relevant to the core drafts. > I'm faced with password hashing routines that work with > octet strings, not character strings; etc. > Am I required to reject attempted non-ASCII > strings in these places for no reason other than an inability to know > what the user intended the character set - if any - to be? (For that > matter, what grounds are there for assuming that octets in the ASCII > range are intended to correspond to ASCII characters, rather than, say, > KOI-7?) I'm assuming you're talking about the server implementation now (client side is comparatively trivial; convert input to utf8 based on the current $LC_CTYPE). On the server side, problem is that at login time, you don't know the user's $LC_CTYPE. My recommendation is as follows: 1. Chose one default encoding (be that plain ascii, or latin1, or koi-7, or normalized utf-8, depending on your context and preference). 2. Provide an option for the sysadmin to say that on his or her particular system, some other character set is used for user names and passwords. Then convert the usernames and passwords you get on the wire to the selected encoding. That's almost solves the problem, and it's no big deal. Optionally, to support systems where different users use different character sets for their usernames and/or passwords, use some per user configuration or kludgery to figure out the user's character set. I'll be happy to discuss these implementation issues (my implementation doesn't get non-ascii quite right yet either), but we should probably do that off-list. > Given how common such systems are, it seems a bit odd that the IETF > would take a position so apparently incompatible with them. Do you have some numbers to back that up? I've seen quite some number of unix systems, but as far as I can recall, I've *never* seen one where usernames and passwords used non-ascii characters. (I *have* seen plenty of non-ascii filenames, but as I said, that's a different issue, and irrelevant to the core drafts). I live in latin1-land, not asia, though. Best regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 4 11:56:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25961 for ; Tue, 4 Jan 2005 11:56:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C4F1D51EB; Tue, 4 Jan 2005 16:56:22 +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 B08C45171 for ; Tue, 4 Jan 2005 16:56:19 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA03796; Tue, 4 Jan 2005 11:56:18 -0500 (EST) From: der Mouse Message-Id: <200501041656.LAA03796@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 4 Jan 2005 11:14:07 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: <41DA48A6.5070306@columbia.edu> References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DA48A6.5070306@columbia.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> As I see it, this amounts to "the IETF position is that humans think >> of these things as character strings, so we demand that they be >> handled as character strings by the protocol". > Absolutely not. The IETF position is that if I am attempting to > login to machine H via SSH, I should be able to do so by knowing the > necessary bits: username, password, etc. But which is (say) the username? The character string g e-acute r a r d, or the octet string 0x67 0xe9 0x72 0x61 0x72 0x64? A human is more likely to think of it as the former; the reality to the computer is more likely to be the latter. (At least assuming an encoding-agnostic user database such is at issue here.) So does "entering the username" mean typing g e-acute r a r d (for any of the various ways of typing those characters), or does it mean typing whatever is necessary to generate 0x67 0xe9 0x72 0x61 0x72 0x64? (Note that either or both may be impossible to do under reasonably plausible circumstances.) The stated IETF position on interoperability makes no sense unless it's based on the former of those two positions, which is why I phrased my gloss on it the way I did. > Are you telling me that once I configure a login to work from one > particular platform and user interface configuration that I should be > locked into that choice exclusive of all the other system types and > user input methods which are available? No; even if you go with the octet-string model, you are locked in only to system types and input methods that permit you to generate that octet string. Very much the way, in fact, that the character-string model locks you into the ability to generate the desired character string. It's just a question of which lock you prefer to be in. > In the the long run we are going to need to fix AFS to do one of two > things: > (1) store context information associating the character set [...] > (2) provide support for a normalized character set [...] Only if AFS is (or becomes) philosophically committed to considering file names to be character strings. (While this may not be a wrong choice, it is still a choice, and you seem to be arguing from a position that is unaware of that.) Character strings make a lot of sense from some points of view, yes - and that's true not only of filenames but of other things, such as usernames. Character strings are a better match to the way most people think of them, if nothing else. But they bring a whole passel of problems with them, some of which we're discussing here. The biggest problem is perhaps the one that got me writing to the list about this: a large body of existing code that takes the octet-string point of view and what the best way is to impedance-match it to a spec that takes the character-string point of view. > You have to draw the line somewhere if you are going to make progress > at improving cross platform user experience. I guess what I don't quite see is how rendering ssh unimplementable (or implementable only crippledly, such as by restricting everything to ASCII) on traditional Unix systems is going to improve anything. Honestly, what I expect it to do is to create two imcompatible dialects of ssh, one taking the character-string point of view and the other taking the octet-string point of view, with humans rqeuired to deal with the mismatch whenever they meet. (There may be a third dialect that imposes willy-nilly some guessed character set on the octet-string environment....) > Systems without support for character-set processing are useful only > when all of the systems they share information with are used in > exactly the same context. I think that's too strong. Rather, I would say, they allow mismatches to show through in some form, usually in the form of text in one character set being displayed in another and coming through as nonsense. This is not to say that they're _not_ useful in the face of such things, just _less_ useful, or at least less transparently useful. The corresponding upside, of course, is a simpler implementation and more flexibility. >> [...] I'd like to know what the IETF's idea of the right thing for >> me to do here is. > You do what Kermit has done since 1981. When moving information > between systems you convert from the local character set to a network > neutral form But this step cannot be done when I'm sending, because all I have is an octet string. I don't know what character set it's in; strictly speaking, I don't even know whether it _is_ in a character set, though for usernames and passwords it is extremely likely that it is, at least in someone's mind (and for filenames it's reasonably likely). > and then the receiver converts its local form. And this is equally impossible, for similar reasons. /~\ 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 Tue Jan 4 12:13:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27211 for ; Tue, 4 Jan 2005 12:13:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0D6C55215; Tue, 4 Jan 2005 17:13: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 069975171 for ; Tue, 4 Jan 2005 17:13:07 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA03861; Tue, 4 Jan 2005 12:13:07 -0500 (EST) From: der Mouse Message-Id: <200501041713.MAA03861@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 4 Jan 2005 11:56:36 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Please leave the file system issues out of it for now. Okay. The fundamental issues are the same anyway, as I see them. >> Am I required to reject attempted non-ASCII strings in these places >> for no reason other than an inability to know what the user intended >> the character set - if any - to be? > I'm assuming you're talking about the server implementation now > (client side is comparatively trivial; convert input to utf8 based on > the current $LC_CTYPE). Hm? I have no LC_CTYPE in my environment and have got by fine without it for years. The only places I've been able to think of that anything knows that I'm using 8859-1 (which is what I use by default) are: - The font I use to display text; - The Content-Type: header my MUA is configured to default to; - $LESSCHARDEF (and that just knows which characters are printable, basically; it couldn't tell you 8859-1 vs 8859-2); - The mapping table between what I might loosely call compose sequences and octet values my text editor uses; - The display substitutes my text editor uses when displaying non-ASCII text on an ASCII-only display; - The non-ASCII keycodes I've chosen to xmodmap onto real keys on my keyboard in my X startup scripts; - My own mind. I don't know what I should set LC_CTYPE to to indicate 8859-1. I don't even know where to look to find that out - I don't use non-ASCII for much beyond inter-human communication (eg email). >> Given how common such systems are, it seems a bit odd that the IETF >> would take a position so apparently incompatible with them. > Do you have some numbers to back that up? I've seen quite some > number of unix systems, but as far as I can recall, I've *never* seen > one where usernames and passwords used non-ascii characters. Come to think of it, I've never seen one where they were actually used (or where I knew they were used, at least - for example, I have known very few passwords besides my own). I don't know how many I've seen where they would work if attempted. I don't even recall hearing of anyone attempting it, either, regardless of the outcome; I'll have to ask the more internationalized of my friends. /~\ 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 Tue Jan 4 12:21:11 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27846 for ; Tue, 4 Jan 2005 12:21:11 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E9C415212; Tue, 4 Jan 2005 17:21:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from cz.mit.edu (STRATTON-FOUR-FORTY-TWO.MIT.EDU [18.187.6.187]) by mail.netbsd.org (Postfix) with ESMTP id 78CB65171 for ; Tue, 4 Jan 2005 17:21:06 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 7CCF6E0075; Tue, 4 Jan 2005 12:22:11 -0500 (EST) To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> From: Sam Hartman Date: Tue, 04 Jan 2005 12:22:11 -0500 In-Reply-To: <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Tue, 4 Jan 2005 00:23:55 -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: >>> 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? >> I'd appreciate replies off-list as I believe we are outside of >> the scope of this working group. der> In general, perhaps, but insofar as it bears on implementing der> ssh, I am inclined to disagree - which is why I'm replying der> on-list anyway. *sigh* Teach me to try and explain something. der> What is the IETF position, then, on how someone such as me der> should handle the situation I'm faced with: writing software der> specified from this point of view (ssh, in my case) for der> systems on which these entities are _not_ character strings der> (a fairly traditional Unix variant, NetBSD in my case)? I'm der> faced with an encoding-agnostic filesystem interface and der> implementation, wherein filename components are sequences of der> octets not including 0x00 and 0x2f, independent of any der> characters; I'm faced with password hashing routines that der> work with octet strings, not character strings; etc. I think this is all mostly an open issue. IN practice what unix server implementers seem to do is to treat the username and password as octet-strings. Neils has proposed ways of doing significantly better than that. I do think there is significant room here for implementers to decide what works best, write it up and publish it. Based on timing it would probably work better as an informational RFC than as input to the core drafts. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 4 13:30:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05318 for ; Tue, 4 Jan 2005 13:30:30 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EA7245236; Tue, 4 Jan 2005 18:30:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id B9F2B5171 for ; Tue, 4 Jan 2005 18:30:19 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7014412 for ietf-ssh@netbsd.org; Tue, 04 Jan 2005 10:30:18 -0700 Message-ID: <41DAD2AB.3060608@vandyke.com> Date: Tue, 04 Jan 2005 10:30:19 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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: > der Mouse writes: > >>I'm faced with password hashing routines that work with >>octet strings, not character strings; etc. > >>Am I required to reject attempted non-ASCII >>strings in these places for no reason other than an inability to know >>what the user intended the character set - if any - to be? (For that >>matter, what grounds are there for assuming that octets in the ASCII >>range are intended to correspond to ASCII characters, rather than, say, >>KOI-7?) > > I'm assuming you're talking about the server implementation now > (client side is comparatively trivial; convert input to utf8 based on > the current $LC_CTYPE). On the server side, problem is that at login > time, you don't know the user's $LC_CTYPE. My recommendation is as > follows: > > 1. Chose one default encoding (be that plain ascii, or latin1, or > koi-7, or normalized utf-8, depending on your context and > preference). > > 2. Provide an option for the sysadmin to say that on his or her > particular system, some other character set is used for user names > and passwords. > > Then convert the usernames and passwords you get on the wire to the > selected encoding. That's almost solves the problem, and it's no big > deal. Precisely. By doing this you increase interoperatability from only those systems that use the same character sets (i.e., only koi-7 system interoperate with each other) to interoperating in with all clients, as long as the same character set is used on the server for passwords. If this is too restrictive (i.e., different users on the same server use different character sets for their passwords), do this: > Optionally, to support systems where different users use different > character sets for their usernames and/or passwords, use some per user > configuration or kludgery to figure out the user's character set. For example, a non-script dot-file in the users home directory that you can read to get such useful information as $LC_TYPE, preferred umask, etc. (Things you'd really like to know, but don't want to run a user script to find out.) >>Given how common such systems are, it seems a bit odd that the IETF >>would take a position so apparently incompatible with them. > > Do you have some numbers to back that up? I've seen quite some number > of unix systems, but as far as I can recall, I've *never* seen one > where usernames and passwords used non-ascii characters. (I *have* > seen plenty of non-ascii filenames, but as I said, that's a different > issue, and irrelevant to the core drafts). I live in latin1-land, not > asia, though. I will say that windows can and does use non-ascii usernames and passwords, and it is not an uncommon operating system, though it is not the most common of server platforms. - Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 4 13:42:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06461 for ; Tue, 4 Jan 2005 13:42:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3C8875247; Tue, 4 Jan 2005 18:42:16 +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 31157521B for ; Tue, 4 Jan 2005 18:42:14 +0000 (UTC) Received: by mail.lysator.liu.se (Postfix, from userid 1646) id B105E23DC97; Tue, 4 Jan 2005 19:42:12 +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 6293F2488E1; Tue, 4 Jan 2005 19:41:51 +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 j04IfobY028327; Tue, 4 Jan 2005 19:41:50 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j04Ifk3B028324; Tue, 4 Jan 2005 19:41:46 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <200501041713.MAA03861@Sparkle.Rodents.Montreal.QC.CA> From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 04 Jan 2005 19:41:45 +0100 In-Reply-To: <200501041713.MAA03861@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 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.4 required=5.0 tests=AWL,J_CHICKENPOX_13 autolearn=no version=2.63-lysator_fetto_1.2 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > Hm? I have no LC_CTYPE in my environment and have got by fine without > it for years. The only places I've been able to think of that anything > knows that I'm using 8859-1 (which is what I use by default) are: It's basically needed whenever information is transferred to and from remote systems, using protocols that are charset aware. E.g. if you use a text web-browser to access pages written in utf-8, your browser will do a better job displaying the content if it knows if your terminal is configured to use latin1, utf8 or koi8r. I think the primary reason I started setting LC_CTYPE many years ago was that GNU ls uses the standard C locale system and isprint() to figure out which characters in filenames are printable, and which should be displayed specially. Don't know how BSD ls behaves in this respect. $ touch räksmörgås $ ls räksmörgås $ LC_CTYPE='' ls r?ksm?rg?s > - The Content-Type: header my MUA is configured to default to; > - $LESSCHARDEF (and that just knows which characters are printable, > basically; it couldn't tell you 8859-1 vs 8859-2); These are application specific configurations. I think it's preferable to use a single configuration mechanism, namely LC_CTYPE. > I don't know what I should set LC_CTYPE to to indicate 8859-1. If you're saying C locales are broken, I'll agree that they're broken in several different ways. That's why I wrote "comparatively trivial", not "trivial"... IMO, it *ought* to work to simply set LC_CTYPE to "iso-8859-1" if that's what you're using, and LC_PAPER to "a4" if you want that. But the current state of affairs seems to be that the simple way doesn't work, one has to figure out a corresponding geographic region. E.g. I use LC_CTYPE=sv_SE, and that seems to work for me. If I ever wanted, say, "b5" as the default paper size, I have no idea which region, if any, that choice would correspond to. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 5 13:25:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27943 for ; Wed, 5 Jan 2005 13:25:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8636D534B; Wed, 5 Jan 2005 18:25:02 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.netbsd.org (Postfix) with ESMTP id 3981A51BA for ; Wed, 5 Jan 2005 18:25:01 +0000 (UTC) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 9F8C7CD4 for ; Wed, 5 Jan 2005 12:21:09 -0600 (CST) Received: from lassie.tcpip.zko.hp.com (unknown [16.116.92.100]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with SMTP id 3914A2418 for ; Wed, 5 Jan 2005 13:21:09 -0500 (EST) Date: Wed, 5 Jan 2005 13:15:27 -0500 (EST) Message-Id: <05010513152721_32A07085@ucx.lkg.dec.com> From: Sheldon.Bishov@hp.com (Sheldon Bishov) To: IETF-SSH@NetBSD.org Subject: Checking for ssh implementation that uses SSH_MSG_USERAUTH_PASSWD_CHANGEREQ X-VMS-To: IETF-SSH@NETBSD.ORG X-VMS-Cc: BISHOV X-VMS-True-From: bishov@ucx.lkg.dec.com (Sheldon Bishov) Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm working to get a client to handle the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message for password change on UNIX server, and am checking for implementations that support this mechanism. Have tested a few UNIX implementations, so far none use that message, instead run passwd in a shell context. Am starting to check secsh mail archive also. Thanks in advance. Sheldon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 5 15:01:48 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06013 for ; Wed, 5 Jan 2005 15:01:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6C54F535C; Wed, 5 Jan 2005 20:01:44 +0000 (UTC) X-Original-To: IETF-SSH@netbsd.org Delivered-To: IETF-SSH@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id D571A517D for ; Wed, 5 Jan 2005 20:01:42 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7022352; Wed, 05 Jan 2005 13:01:41 -0700 Message-ID: <41DC47A7.2070807@vandyke.com> Date: Wed, 05 Jan 2005 13:01:43 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sheldon Bishov Cc: IETF-SSH@NetBSD.org Subject: Re: Checking for ssh implementation that uses SSH_MSG_USERAUTH_PASSWD_CHANGEREQ References: <05010513152721_32A07085@ucx.lkg.dec.com> In-Reply-To: <05010513152721_32A07085@ucx.lkg.dec.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sheldon Bishov wrote: > I'm working to get a client to handle the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > message for password change on UNIX server, and am checking for > implementations that support this mechanism. Have tested a few UNIX > implementations, so far none use that message, instead run passwd in a shell > context. Am starting to check secsh mail archive also. I'm a little unclear what you are looking for... If you are looking for a client that handles the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, then both our unix clients and our windows clients do. (www.vandyke.com) There is no excuse for a client not handling this message; and I would consider a client that can't correctly handle this message out-of-spec. I'm surprised if you aren't finding clients that support it. If you are looking for unix servers that generate this message, and do the password change, that is a different story. I'm not sure you will find one. The mechanism for changing a users password varies wildly from one unix system to another, and isn't always programattically exposed. Our windows servers _do_ generate the message as appropraite, but I don't believe our unix servers do. (So if you were looking for something to test a client you are developing against, the our windows servers might or might not be an option for you-- if you are developing a client and need a server to do interop testing with, contact me privately, off-list.) Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 5 16:38:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21499 for ; Wed, 5 Jan 2005 16:38:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 98E03536E; Wed, 5 Jan 2005 21:38:00 +0000 (UTC) X-Original-To: IETF-SSH@NetBSD.org Delivered-To: IETF-SSH@NetBSD.org Received: from mail.iinet.net.au (mail-02.iinet.net.au [203.59.3.34]) by mail.netbsd.org (Postfix) with SMTP id 854E5517D for ; Wed, 5 Jan 2005 21:37:58 +0000 (UTC) Received: (qmail 9076 invoked from network); 5 Jan 2005 21:31:17 -0000 Received: from unknown (HELO dodgynet.dyndns.org) (203.206.246.110) by mail.iinet.net.au with SMTP; 5 Jan 2005 21:31:16 -0000 Received: from [127.0.0.1] (gate.dodgy.net.au [192.168.32.1]) by dodgynet.dyndns.org (8.12.8/8.12.8) with ESMTP id j05LVEgR025225; Thu, 6 Jan 2005 08:31:15 +1100 Message-ID: <41DC5C8F.6080609@zip.com.au> Date: Thu, 06 Jan 2005 08:30:55 +1100 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sheldon Bishov Cc: IETF-SSH@NetBSD.org Subject: Re: Checking for ssh implementation that uses SSH_MSG_USERAUTH_PASSWD_CHANGEREQ References: <05010513152721_32A07085@ucx.lkg.dec.com> In-Reply-To: <05010513152721_32A07085@ucx.lkg.dec.com> 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 Sheldon Bishov wrote: > I'm working to get a client to handle the SSH_MSG_USERAUTH_PASSWD_CHANGEREQ > message for password change on UNIX server, and am checking for > implementations that support this mechanism. Have tested a few UNIX > implementations, so far none use that message, instead run passwd in a shell > context. Am starting to check secsh mail archive also. I did patches for OpenSSH that did this. The patch (against OpenSSH 3.5p1) is still available at the link below. It should work on AIX and platforms using /etc/shadow, but I would not recommend using it in production. I gave up on PASSWD_CHANGEREQ after this patch. As Joseph pointed out, the interface to change a password varies wildly from system to system (and rebuilding /etc/shadow like it does seems like a nasty thing to do). The real killer, however, was that to use this for real you would also have to support every system's password complexity rules too (eg /etc/default/passwd on Solaris) and those vary even more. http://www.zip.com.au/~dtucker/openssh/openssh-3.5p1-passexpire8.patch -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 6 18:25:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05682 for ; Thu, 6 Jan 2005 18:25:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5E89D53EC; Thu, 6 Jan 2005 23:24:23 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from virgo.cus.cam.ac.uk (virgo.cus.cam.ac.uk [131.111.8.20]) by mail.netbsd.org (Postfix) with ESMTP id 4259851FD for ; Thu, 6 Jan 2005 23:24:20 +0000 (UTC) Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.43) id 1Cmgg2-0003CT-S9 for ietf-ssh@netbsd.org; Thu, 06 Jan 2005 23:04:22 +0000 Date: Thu, 6 Jan 2005 23:04:22 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: RSA-based key exchange Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've just had posted an Internet-Draft, draft-harris-ssh-rsa-kex-00.txt, which describes an RSA-based key-exchange method for SSH, which has advantages if you're dealing with particularly slow clients. I'd appreciate hearing the WG's opinion on this draft and the protocol it specifies. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 6 18:34:33 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06250 for ; Thu, 6 Jan 2005 18:34:33 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id ED51753EA; Thu, 6 Jan 2005 23:34:29 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from virgo.cus.cam.ac.uk (virgo.cus.cam.ac.uk [131.111.8.20]) by mail.netbsd.org (Postfix) with ESMTP id A153151FD for ; Thu, 6 Jan 2005 23:34:28 +0000 (UTC) Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.43) id 1Cmh9A-0003OY-0l for ietf-ssh@netbsd.org; Thu, 06 Jan 2005 23:34:28 +0000 Date: Thu, 6 Jan 2005 23:34:27 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Minor references problems in transport-22 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list While working on draft-harris-ssh-rsa-kex, I found a few problems in the core drafts. Here are the ones from draft-ietf-secsh-transport-22.txt: It states, regarding ssh-rsa keys: Signing and verifying using this key format is done according to [SCHNEIER] and [RFC3447] using the SHA-1 hash. I haven't got a copy of Schneier here, but I do know that RFC 3447 specifies two RSA signature schemes, RSASSA-PSS and RSASSA-PKCS1-v1_5. The latter seems to be the scheme that SSH uses, and it should probably be specified explicitly: Signing and verifying using this key format is done according to [SCHNEIER] and [RFC3447] using the RSASSA-PKCS1-v1_5 scheme and the SHA-1 hash. On the subject of SHA-1, transport-22 only refers to [SCHNEIER] for its definition, and then only in the context of HMAC. It might be better to reference the NIST document that defines it: [FIPS-180-2] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS PUB 180-2, August 2002. Similarly, for MD5 a reference to RFC 1312 might be appropriate. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 6 18:55:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07386 for ; Thu, 6 Jan 2005 18:55:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 59DF653F1; Thu, 6 Jan 2005 23:55:12 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from virgo.cus.cam.ac.uk (virgo.cus.cam.ac.uk [131.111.8.20]) by mail.netbsd.org (Postfix) with ESMTP id 6658D53C8 for ; Thu, 6 Jan 2005 23:55:10 +0000 (UTC) Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.43) id 1CmhTB-0003U7-Ls for ietf-ssh@netbsd.org; Thu, 06 Jan 2005 23:55:09 +0000 Date: Thu, 6 Jan 2005 23:55:09 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: KEX-specific and USERAUTH-specific message numbers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list Another possible problem I noticed while writing rsa-kex: draft-ietf-secsh-assignednumbers-10.txt says: Requests for assignments of new message numbers in the range of 1 to 127 MUST be done through the STANDARDS ACTION method as described in [RFC2434]. This seems slightly wrong to me, in that message numbers in the ranges 30-49 and 60-79 are effectively assigned by whoever owns the KEX or USERAUTH method in use, not by IANA (thought of course some KEX and USERAUTH names are assigned by IANA. I'd suggest the following text: Requests for assignments of new message numbers in the range of 1 to 29, 50 to 59, and 80 to 127 MUST be done through the STANDARDS ACTION method as described in [RFC2434]. The meanings of message numbers in the range of 30 to 49 are specific to the key exchange method in use, and their meaning will be specified by the definition of that method. The meanings of message numbers in the range of 60 to 79 are specific to the user authentication method in use, and their meaning will be specified by the definition of that method. I don't think the "Initial Assignments" table for message numbers should mention SSH_MSG_KEXDH_INIT, SSH_MSG_KEXDH_REPLY, or SSH_MSG_USERAUTH_PK_OK, since those fall into the ranges not managed by IANA. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 10 13:29:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11524 for ; Mon, 10 Jan 2005 13:29:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6B7C45205; Mon, 10 Jan 2005 18:28:56 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id D65A651CA for ; Mon, 10 Jan 2005 18:28:54 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 53003342F4 for ; Tue, 11 Jan 2005 07:00:33 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00572-15 for ; Tue, 11 Jan 2005 07:00:33 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 3B2A133FCA for ; Tue, 11 Jan 2005 07:00:33 +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 35BBD37743 for ; Tue, 11 Jan 2005 07:00:33 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Co3qD-00087F-00 for ; Tue, 11 Jan 2005 07:00:33 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org Subject: Any contacts for an F-Secure client bug Message-Id: Date: Tue, 11 Jan 2005 07:00:33 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Is there anyone on here that I can talk to about getting an F-Secure client software bug fixed? The F-Secure people want me to get a support contract with them in order to report a bug in their product, which I'm somewhat reluctant to do. Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 11 14:28:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18439 for ; Tue, 11 Jan 2005 14:28:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EAE605232; Tue, 11 Jan 2005 19:28:07 +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 CF2F05179 for ; Tue, 11 Jan 2005 19:28:05 +0000 (UTC) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 Jan 2005 12:40:10 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j0BJS3jw017619 for ; Tue, 11 Jan 2005 11:28:04 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA11934 for ; Tue, 11 Jan 2005 11:28:03 -0800 (PST) Date: Tue, 11 Jan 2005 11:28:03 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Open Issues from Recent Comments In-Reply-To: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, We've received some coments recently. I'll summarize them and note what I intend to do with them in the core IDs. I'd appreciate feedback. 1) Double spaces after the period after an initial in a name. Issue: xml2rfc has started double spacing between the end of a sentence and the start of the next. I saw that problem with "etc." used at the end of a sentence. Proposed Resolution: I'm not sure what I can do about this but I'll play around and see. 2) Use of commas in "..may, or may not be.." Issue: English grammar. Proposed Resolution: My Scribner Handbook of English (after cleaning off all of the dust) says that it's OK to have "..may or may not.." without commas. I'll clean those up. 3) Use of commas in "..display forwarding in SSH (or other, secure protocols), combined with.." Issue: English grammar. Proposed Resolution: I'll make the change to "display forwarding in SSH (or other secure protocols), combined with..". 4) SSH_DISCONNECT_* descriptions Issue: (From the note by der Mouse) In sections 4.2 and 4.2.2 of [NUMBERS]-10, 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. Proposed Resolution: Can I get some feedback on this? I was under the assumption that the "descriptions" are the standardized text to send in the "description" field. I too felt that was a bit redundant but figured that it was setting the precendence for the descriptions associated with local namespaces. What's the right thing to do here? 5) Opcode Arguments in [NUMBERS]-10 and [CONNECT]-23 Issue: TTY_OP_END is listed with the prefix of "TTY_OP_" but none of the others include that prefix. Proposed Resolution: I need some feedback on this as well. Do the opcode arguments all get the prefix of "TTY_OP_"? 6) PENDIN opcode Issue: Why does PENDIN have an assignment. It is really a dynamic tty driver internal state. It may not be the sort of state bit that it makes any sense at all to push across the network. Proposed Resolution: I need someone to verify that. 7) SPKI Issue: (From note by Peter Gutmann) The incompletely-specified X.509 format has been removed 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. Proposed Resolution: I'll remove SPKI where appropriate unless anyone has a better proposal. 8) UTF8 Issue: The Editor is not sure what to do with all of the emails flying back and forth. Proposed Resolution: Unless we get some consensus on proposed text, I'm not going to make any modifications to the IDs. 9) KEX Message Numbers Issue: (From note by Ben Harris) Requests for assignments of new message numbers in the range of 1 to 127 MUST be done through the STANDARDS ACTION method as described in [RFC2434]. This seems slightly wrong to me, in that message numbers in the ranges 30-49 and 60-79 are effectively assigned by whoever owns the KEX or USERAUTH method in use, not by IANA (thought of course some KEX and USERAUTH names are assigned by IANA. Proposed Resolution: This sounds right to me. Unless someone objects, I'll integrate the wording proposed by Ben into [NUMBERS] and duplicate it in [USERAUTH]. Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 11 16:01:15 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28759 for ; Tue, 11 Jan 2005 16:01:14 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 18E735341; Tue, 11 Jan 2005 21:01:09 +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 1C5AA5179 for ; Tue, 11 Jan 2005 21:01:06 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA00573; Tue, 11 Jan 2005 16:01:06 -0500 (EST) From: der Mouse Message-Id: <200501112101.QAA00573@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 11 Jan 2005 15:51:50 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > We've received some coments recently. I'll summarize them and note > what I intend to do with them in the core IDs. I'd appreciate > feedback. You asked for it, so I'll give it. :-) > 1) Double spaces after the period after an initial in a name. > Issue: xml2rfc has started double spacing between the end of a > sentence and the start of the next. There's nothing wrong with that, surely? The space after the punctuation ending a sentence normally *should* be wider than an inter-word space, and in a monospaced font a double space is, I thought, the canonical way to do it. (The spacing ratio in well-typeset text is reasonably close to 2:1....) What the correct way to mark certain dot-space combinations as not ending sentences is for xml2rfc I don't know. But it does seem to me that if xml2rfc is producing problems, maybe the right fix is to stop using it and switch to something better behaved? Is there any reason XML (which I assume is involved from the xml2rfc name) needs to be involved? > 6) PENDIN opcode > Issue: Why does PENDIN have an assignment. It is really a dynamic > tty driver internal state. It may not be the sort of state bit that > it makes any sense at all to push across the network. > Proposed Resolution: I need someone to verify that. Surely all the verification it takes is to grep for PENDIN in your favourite open-source kernel's tty code and look at how it's used. For the rest of the points listed, I'm happy with the resolution given (well, except for the UTF-8 issue, and that I'm at least content with, pending some kind of consensus on what the right thing for encoding-agnostic systems is to do and what that means the core drafts should say). And, Chris...thank you for all your unstinting work taking care of the drafts. It's a mostly thankless job, one that is noticed only when done badly, and I for one appreciate your dedication to it. /~\ 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 Tue Jan 11 19:08:43 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18558 for ; Tue, 11 Jan 2005 19:08:42 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E089253CB; Wed, 12 Jan 2005 00:08:33 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mail.netbsd.org (Postfix) with ESMTP id 8A1985389 for ; Wed, 12 Jan 2005 00:08:31 +0000 (UTC) Received: from gwyn.kn-bremen.de (uucp@gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.12.9/8.12.9/Debian-5) with ESMTP id j0C03fO4002123 for ; Wed, 12 Jan 2005 01:03:41 +0100 Received: (from uucp@localhost) by gwyn.kn-bremen.de (8.12.9/8.12.8/Debian-1) with UUCP id j0C03fQC002121 for ietf-ssh@NetBSD.org; Wed, 12 Jan 2005 01:03:41 +0100 Received: (from ms@localhost) by lucien.oneiros.kn-bremen.de (8.9.3/8.9.3) id XAA30268 for ietf-ssh@NetBSD.org; Tue, 11 Jan 2005 23:16:17 +0100 X-Authentication-Warning: lucien.oneiros.kn-bremen.de: ms set sender to martin@oneiros.de using -f Date: Tue, 11 Jan 2005 23:16:17 +0100 From: Martin =?iso-8859-1?Q?Schr=F6der?= To: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments Message-ID: <20050111221617.GB29422@lucien.kn-bremen.de> Mail-Followup-To: ietf-ssh@NetBSD.org References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501112101.QAA00573@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501112101.QAA00573@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.4.2i X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 2005-01-11 15:51:50 -0500, der Mouse wrote: > There's nothing wrong with that, surely? The space after the > punctuation ending a sentence normally *should* be wider than an > inter-word space, and in a monospaced font a double space is, I > thought, the canonical way to do it. (The spacing ratio in > well-typeset text is reasonably close to 2:1....) That depends on your local context (e.g. in the USA the inter-sentence space is larger while in europe it's mostly the same; in TeX it's \nonfrenchspacing vs. \frenchspacing). Best regards Martin -- http://www.tm.oneiros.de From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 11 21:47:31 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29153 for ; Tue, 11 Jan 2005 21:47:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 16381537A; Wed, 12 Jan 2005 02:47:25 +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 7D99652DE for ; Wed, 12 Jan 2005 02:47:23 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id VAA02123; Tue, 11 Jan 2005 21:47:22 -0500 (EST) From: der Mouse Message-Id: <200501120247.VAA02123@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 11 Jan 2005 21:45:23 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments In-Reply-To: <20050111221617.GB29422@lucien.kn-bremen.de> References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501112101.QAA00573@Sparkle.Rodents.Montreal.QC.CA> <20050111221617.GB29422@lucien.kn-bremen.de> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> The space after the punctuation ending a sentence normally *should* >> be wider than an inter-word space, [...] > That depends on your local context (e.g. in the USA the > inter-sentence space is larger while in europe it's mostly the same; > in TeX it's \nonfrenchspacing vs. \frenchspacing). I thought that was correlated more with language than with location; is that a mistaken impression? /~\ 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 Jan 12 02:52:41 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19669 for ; Wed, 12 Jan 2005 02:52:41 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 320735345; Wed, 12 Jan 2005 07:52:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.siliconcircus.com (goldfinger.siliconcircus.com [62.141.33.103]) by mail.netbsd.org (Postfix) with ESMTP id D7BDE5250 for ; Wed, 12 Jan 2005 07:52:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 479E44336A; Wed, 12 Jan 2005 08:30:13 +0100 (CET) Message-ID: <41E4D328.3030000@siliconcircus.com> Date: Wed, 12 Jan 2005 08:35:04 +0100 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org, clonvick@cisco.com Subject: Re: Open Issues from Recent Comments References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501112101.QAA00573@Sparkle.Rodents.Montreal.QC.CA> <20050111221617.GB29422@lucien.kn-bremen.de> <200501120247.VAA02123@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200501120247.VAA02123@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit der Mouse wrote: > > I thought that was correlated more with language than with location; is > that a mistaken impression? I'm English, living in Germany. British English does use longer inter-sentence spacing. German doesn't. I'm also of the opinion that this is language-specific, not locale-specific. Regarding xml2rfc - I believe this is (nowadays) the standard tool for producing drafts. Certainly, converting the core drafts to a different format at this stage would doubtless be significant effort. I note from http://xml.resource.org that they're now recommending that one submit both text and XML versions, so I think a different tool is probably excluded. The two spaces issue seems to be controlled by the two_spaces procedure in xml2rfc.tcl. They have a check there for abbreviations, which seems to use the regexps *[A-Z][A-Z] and *[A-Z][a-z][a-z] to detect an abbreviation. It *seems* like this should pick up initials in names and not add a space. But maybe my primitive understanding of TCL isn't sufficient. I think one could probably disable the whole insert-two-spaces behaviour by changing the content of the two_spaces function to be just "return $glop" (I only think this, I haven't tested). Not what one really wants, but maybe a quick and easy for the time being. Contact with the xml2rfc people will probably produce a better answer, but may take longer.. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 12 12:10:46 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29347 for ; Wed, 12 Jan 2005 12:10:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0845A519B; Wed, 12 Jan 2005 17:10:36 +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 C0FEB5177 for ; Wed, 12 Jan 2005 17:10:33 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id DE00E3804C; Wed, 12 Jan 2005 18:10:31 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 29511-01-85; Wed, 12 Jan 2005 18:10:20 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 1A32242051; Wed, 12 Jan 2005 18:10:20 +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 j0CHAJbY022499; Wed, 12 Jan 2005 18:10:19 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0CHACNr022496; Wed, 12 Jan 2005 18:10:12 +0100 (MET) 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: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@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: 12 Jan 2005 18:10:11 +0100 In-Reply-To: <41DAD2AB.3060608@vandyke.com> Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > >>Given how common such systems are, it seems a bit odd that the IETF > >>would take a position so apparently incompatible with them. > > Do you have some numbers to back that up? I've seen quite some number > > of unix systems, but as far as I can recall, I've *never* seen one > > where usernames and passwords used non-ascii characters. (I *have* > > seen plenty of non-ascii filenames, but as I said, that's a different > > issue, and irrelevant to the core drafts). I live in latin1-land, not > > asia, though. The problem under discussion was systems, in particular unix servers, where the particular character set used for non-ascii usernames and passwords is tricky to determine, *and* non-ascii characters are actually used. My current belief is that such systems are very rare, so I'd like to know if I'm wrong. > I will say that windows can and does use non-ascii usernames and > passwords, and it is not an uncommon operating system, though it > is not the most common of server platforms. I'm under the impression that those windows systems all use utf-8, not different character sets on different systems or for different users. Then, they don't matter, because they don't have a problem. Right? Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 12 13:30:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03815 for ; Wed, 12 Jan 2005 13:30:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 8DA9953E1; Wed, 12 Jan 2005 18:30:49 +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 89D545177 for ; Wed, 12 Jan 2005 18:30:46 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 6C6EE24C304; Wed, 12 Jan 2005 19:30:45 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 06030-01-89; Wed, 12 Jan 2005 19:30:38 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id D4CAC249E86; Wed, 12 Jan 2005 19:30:37 +0100 (MET) Received: from sellafield.lysator.liu.se (localhost [127.0.0.1]) by sellafield.lysator.liu.se (8.12.10/8.12.8) with ESMTP id j0CIUbbY023902; Wed, 12 Jan 2005 19:30:37 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0CIUVCB023899; Wed, 12 Jan 2005 19:30:31 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 12 Jan 2005 19:30:31 +0100 In-Reply-To: Message-ID: Lines: 142 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > 4) SSH_DISCONNECT_* descriptions ... > Proposed Resolution: Can I get some feedback on this? I was under the > assumption that the "descriptions" are the standardized text to send in > the "description" field. I too felt that was a bit redundant but figured > that it was setting the precendence for the descriptions associated with > local namespaces. What's the right thing to do here? The description is an arbitrary human readably strings describing the reason for the disconnection in some more detail. The text in will usually end up on the users terminal or in the servers log file (perhaps only when running in verbose mode). I think the text in draft-ietf-secsh-transport-22.txt is ok, it's just the table header that must be changed, to something like Reason code Symbolic name 1 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT Or actually, the table is duplicated in NUMBERS, section 4.2.2, so perhaps it could be deleted all together. It would be desirable with a table describing under what circumstances each value should be used, but perhaps we can live without that. Most, but not all, of the symbolic names are self-explanatory. > 5) Opcode Arguments in [NUMBERS]-10 and [CONNECT]-23 > Issue: TTY_OP_END is listed with the prefix of "TTY_OP_" but none of the > others include that prefix. > Proposed Resolution: I need some feedback on this as well. Do the opcode > arguments all get the prefix of "TTY_OP_"? It really doesn't matter. The wire protocol only needs the opcodes, not the symbolic names. Implementations will use their own prefixes or other namespace mangling when defining these constants, but that doesn't matter for interoperability. So I'd say no change is needed. It's fine to have the "meta opcode" TTY_OP_END stick out in the list. > 6) PENDIN opcode > Issue: Why does PENDIN have an assignment. It is really a dynamic tty > driver internal state. It may not be the sort of state bit that it makes > any sense at all to push across the network. > Proposed Resolution: I need someone to verify that. It's not entirely clear to me in which way it is an "internal state bit". It's documented as PENDIN If PENDIN is set, any input that has not yet been read is reprinted when the next character arrives as input. Is the difference that it is reset automatically by the tty driver after the requested action is completed? Compare for example to NOFLSH If NOFLSH is set, the normal flush of the input and output queues associated with the INTR, QUIT, and SUSP characters will not be done. which is not an "internal state bit". > 7) SPKI > Proposed Resolution: I'll remove SPKI where appropriate unless anyone has > a better proposal. It's unfortunate that an RFC on the spki format doesn't exist (the latest and outdated draft is at http://theworld.com/~cme/spki.txt). I agree we'll have to remove spki from the ssh spec. > 8) UTF8 > Issue: The Editor is not sure what to do with all of the emails flying > back and forth. > Proposed Resolution: Unless we get some consensus on proposed text, I'm > not going to make any modifications to the IDs. The way I see it, the recent discussion has made clear that the benefit of requiring usernames and passwords to be normalized when sent as utf8 on the wire, is very questionable. The current text (draft-ietf-secsh-userauth-25.txt) is ok with me, and also pretty vague. It's seems somewhat immature for this wg to make recommendations on particular normalization conventions, so perhaps the sentence "SSH implementations that both store the passwords and compare them SHOULD use [I-D.ietf-sasl-saslprep] for normalization." should be deleted or changed to a "MAY". But I think an even better solution is to delete the entire paragraph (the only place where the userauth document speaks about normalization). Instead, tweak the architecture document as follows: Before: The client and server user names are inherently constrained by what the server is prepared to accept. They might, however, occasionally be displayed in logs, reports, etc. They MUST be encoded using ISO 10646 UTF-8, but other encodings may be required in some cases. It is up to the server to decide how to map user names to accepted user names. Straight bit-wise binary comparison is RECOMMENDED. The last sentence looks very wrong; it will surely break interoperability between systems with different input methods (IIRC, that sentence was added at the request of the IESG, but it's still wrong). The "in some cases"-part also looks wrong to me, and the "displayed in logs" doesn't seem very relevant; that's not the main issue. Proposed new text: User names and passwords are inherently constrained by what the server is prepared to accept. They MUST be encoded using ISO 10646 UTF-8. No normalization is required on the wire; it's the server's responsibility to apply any normalization steps needed before accessing the user and password database. For example, systems that use latin-1 for user names and passwords MUST make sure that the character set conversion treats different but equivalent representations of accented characters in the same way, and systems that use UTF-8 for user names and passwords should apply appropriate normalization, e.g. using [I-D. ietf-sasl-saslprep]. Normalization on the receiver side ensures that when a user enters a username and password, the authentication process will work regardless of the operation system, client software and input method used on the sending side. I intentionally wrote "should apply normalization" rather than "SHOULD apply normalization" in the last-but-one sentence, because it's a recommendation that must be applied consistently to all programs that access the user database. It doesn't make sense as a hard requirement on the ssh server implementation in isolation. > 9) KEX Message Numbers > Proposed Resolution: This sounds right to me. Unless someone objects, > I'll integrate the wording proposed by Ben into [NUMBERS] and duplicate it > in [USERAUTH]. That's a little cumbersome, but I think it's the right thing to do. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 00:39:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22687 for ; Thu, 13 Jan 2005 00:39:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4CA1C528D; Thu, 13 Jan 2005 05:38:55 +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 DEF0351C3 for ; Thu, 13 Jan 2005 05:38:52 +0000 (UTC) Received: from localhost (localhost [[UNIX: localhost]]) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA01187; Thu, 13 Jan 2005 00:38:51 -0500 (EST) From: der Mouse Message-Id: <200501130538.AAA01187@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 13 Jan 2005 00:21:48 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >> 6) PENDIN opcode >> Issue: Why does PENDIN have an assignment. It is really a dynamic >> tty driver internal state. It may not be the sort of state bit that >> it makes any sense at all to push across the network. >> Proposed Resolution: I need someone to verify that. > It's not entirely clear to me in which way it is an "internal state > bit". It's documented as > PENDIN If PENDIN is set, any input that has not yet been read is > reprinted when the next character arrives as input. Documented where? I just had a look through the manpages I have at most ready hand (NetBSD/sparc 1.4T) and the only documentation I find on it is in termios(4) and reads PENDIN /* XXX retype pending input (state) */ The string "PENDIN" occurs in only two of the drafts I have at hand, assignednumbers-10 and connect-23. Both document it the same way: 62 PENDIN Retype pending input. > Is the difference that it is reset automatically by the tty driver > after the requested action is completed? Not only that, it is *set and* reset by the tty driver when appropriate, at least in the kernel code I looked at - it really is exposing the internal state bit the tty driver uses, not just allowing userland to request retyping. Since it controls retyping of input received but still buffered in the kernel, it makes no sense to push it across the network, since there is no way to push that unread input with it. Indeed, I'm not sure why it is exposed to userland at all. Providing a way for userland to request retyping of pending input is not unreasonable, but making it a state bit like this is a bizarre way of doing that. But that's not an issue for us. > Compare for example to > NOFLSH If NOFLSH is set, the normal flush of the input and output > queues associated with the INTR, QUIT, and SUSP characters > will not be done. > which is not an "internal state bit". ...and which is never changed except by userland (or by wholesale resetting of tty state to whatever the kernel's idea of a clean tty state is, upon something like revoke() or last close). > The way I see it, the recent discussion has made clear that the > benefit of requiring usernames and passwords to be normalized when > sent as utf8 on the wire, is very questionable. I see the value of specifying the charset on the wire at all as questionable, since it demands that they be character strings; an encoding-agnostic system has no way to convert its octet strings to character strings. As long as these things are specified as character strings on the wire, I can't see anything sensible for an encoding-agnostic OS to do, regardless of what encoding is chosen, regardless of normalization (if applicable to the encoding), regardless of almost everything else in this area. > I intentionally wrote "should apply normalization" rather than > "SHOULD apply normalization" in the last-but-one sentence, because > it's a recommendation that must be applied consistently to all > programs that access the user database. *Exactly*. It seems my choices as an implementer are to give up trying to conform to the spec, or rework the entire OS and all third-party software to use a character-string paradigm instead of the encoding-agnostic octet-string paradigm it currently uses. Is that really what we want? /~\ 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 Jan 13 00:58:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23948 for ; Thu, 13 Jan 2005 00:58:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C050A52D5; Thu, 13 Jan 2005 05:57:57 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by mail.netbsd.org (Postfix) with ESMTP id 7430D51C3 for ; Thu, 13 Jan 2005 05:57:55 +0000 (UTC) Received: from [192.168.1.10] (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j0D5oF1E009139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jan 2005 00:50:25 -0500 (EST) Message-ID: <41E60CA0.5030006@columbia.edu> Date: Thu, 13 Jan 2005 00:52:32 -0500 From: Jeffrey Altman Organization: Not Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: Joseph Galbraith , ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070404000005060408040203" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.206.20 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms070404000005060408040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Niels Möller wrote: > I'm under the impression that those windows systems all use utf-8, not > different character sets on different systems or for different users. > Then, they don't matter, because they don't have a problem. Right? > > Regards, > /Niels Windows uses Unicode; a code page they call "ANSI" (who knows why it has nothing at all to do with the organization) which is a variation on one of the ISO Latin character sets; and a code page they call "OEM" which comes from IBM's DOS. Which character set is used depends on the API which is being called. Jeffrey Altman --------------ms070404000005060408040203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4 WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2 +nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9 WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02 lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r 1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0 eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1 MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M 3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDUwMTEzMDU1MjMyWjAjBgkqhkiG9w0BCQQxFgQUTmomiFHjfgmAhn+4ZK/1u151YWIw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAEctOqn4R8ZvernKul3kHwPFYHFbXfKDEI+l03N6Y Ag4IPnkl04jgyXO48/pyHtcGZWzGuREbSo5aORT/QhR5xSTo2NGnV/qjafLpVaYP+OViuhYm shWiS5tQIeXsW3BSTvSdhgpIXhDuJF570DEcfPniAK1xFdQ9OAYj5yZRNMosDbod+Xwm8wKz o6VYBZdOqb62bdFqBdKiQmp84I3YZfOQwYY9TY23WanUk5HdeW+fCBY/CsH9ZK3CJfLy89RD 2UOhdaKc/Nn7JlgNuYDVwQXNihRqzKEyqaRUA7ZNhrTLiGJQ0J/b5aosudPIRuuSejGObpJf 02IGgNLwrYmC0wAAAAAAAA== --------------ms070404000005060408040203-- From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 06:19:53 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27703 for ; Thu, 13 Jan 2005 06:19:52 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C6FED5410; Thu, 13 Jan 2005 11:19:41 +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 6ACCB53DB for ; Thu, 13 Jan 2005 11:19:32 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 1191967ED6; Thu, 13 Jan 2005 12:19:31 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 02925-01-50; Thu, 13 Jan 2005 12:19:24 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 1A7691105D7; Thu, 13 Jan 2005 12:19:24 +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 j0DBJNbY011980; Thu, 13 Jan 2005 12:19:23 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0DBJIrP011977; Thu, 13 Jan 2005 12:19:18 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501130538.AAA01187@Sparkle.Rodents.Montreal.QC.CA> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (=?iso-8859-1?q?Niels_M=F6ller?=) Date: 13 Jan 2005 12:19:18 +0100 In-Reply-To: <200501130538.AAA01187@Sparkle.Rodents.Montreal.QC.CA> Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: > > It's not entirely clear to me in which way it is an "internal state > > bit". It's documented as > > > PENDIN If PENDIN is set, any input that has not yet been read is > > reprinted when the next character arrives as input. > > Documented where? Sorry, I should have given an reference. This description is copied from http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?termios. A search for "PENDIN" and "termios" turns up the man pages for a few different systems. The linux man page is even more cryptic, PENDIN all characters in the input queue are reprinted when the next character is read. (bash handles typeahead this way.) [About utf8 passwords and usernames:] > *Exactly*. It seems my choices as an implementer are to give up trying > to conform to the spec, or rework the entire OS and all third-party > software to use a character-string paradigm instead of the > encoding-agnostic octet-string paradigm it currently uses. I've outlined a simple way to solve the problem for the common cases. I agree it's not 100% satisfactory, but from my experience, I think you are exagerating the implementation trouble. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 10:16:30 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17720 for ; Thu, 13 Jan 2005 10:16:29 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DE1775472; Thu, 13 Jan 2005 15:16:24 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by mail.netbsd.org (Postfix) with ESMTP id 7A76A518A for ; Thu, 13 Jan 2005 15:16:23 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id JAA27370; Thu, 13 Jan 2005 09:39:33 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "=?iso-8859-2?Q?'=22Niels_M=F6ller=22'?=" , "'Joseph Galbraith'" Cc: Subject: RE: UTF8 Date: Thu, 13 Jan 2005 15:39:27 +0100 Message-ID: <004701c4f97d$b053d9d0$d7b7fea9@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > I'm under the impression that those windows systems all use=20 > utf-8, not different character sets on different systems or=20 > for different users. Then, they don't matter, because they=20 > don't have a problem. Right? Windows is a dual-mode platform. Windows NT/2000/XP/2003 natively use 16-bit Unicode, but the vast = majority of system APIs also come in so-called ANSI versions, which convert = between internal Unicode representation and, on the application side, whatever = code page is currently selected by the user or for the system. These code = pages are usually 8-bit but, as used in Asia in particular, they also include multi-byte character sets (MBCS) with variable-length code sequences. Windows 98/Me, a number of installations of which still persist, are natively 8-bit and use internally whatever code page is configured for = the machine. Many system calls have a Unicode counterpart which translates = the strings to and from the internal 'ANSI' representation, but the = windowing subsystem (the graphical user interface) is totally ANSI and, on these platforms, has no support for Unicode. All versions of Windows from 98 and up provide a system character set conversion API function which supports conversion to and from UTF-8. But = the internally used character set depends on the platform (16-bit Unicode = for NT platforms, or an 8-bit or variable-bit code page in Windows 9x/Me). From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 11:39:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23962 for ; Thu, 13 Jan 2005 11:39:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id DD21754E8; Thu, 13 Jan 2005 16:39:13 +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 CF0EE54B7 for ; Thu, 13 Jan 2005 16:39:07 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id BF056250573; Thu, 13 Jan 2005 17:39:06 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 00618-01-9; Thu, 13 Jan 2005 17:38:53 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id 3599424F599; Thu, 13 Jan 2005 17:38:53 +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 j0DGcqbY018180; Thu, 13 Jan 2005 17:38:52 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0DGckaC018177; Thu, 13 Jan 2005 17:38:46 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: "denis bider" Cc: "'Joseph Galbraith'" , Subject: Re: UTF8 References: <004701c4f97d$b053d9d0$d7b7fea9@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: 13 Jan 2005 17:38:45 +0100 In-Reply-To: <004701c4f97d$b053d9d0$d7b7fea9@nucleus> Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit "denis bider" writes: > > I'm under the impression that those windows systems all use > > utf-8, not different character sets on different systems or > > for different users. Then, they don't matter, because they > > don't have a problem. Right? > > Windows is a dual-mode platform. But it still sounds like it doesn't have the problem der Mouse is having with unix systems. > Windows NT/2000/XP/2003 natively use 16-bit Unicode, but the vast majority > of system APIs also come in so-called ANSI versions, Then the ssh implementation (client or server) can stick to the unicode api:s, and pass only unicode to the system (optionally with normalization, if appropriate). > Windows 98/Me, a number of installations of which still persist, are > natively 8-bit and use internally whatever code page is configured for the > machine. As long as this code page configuration is system wide, and available to applications, there should also be no problem. The ssh implementation only has to convert to and from utf8 (on the wire) and the system charset, whichever that is. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 14:08:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04358 for ; Thu, 13 Jan 2005 14:08:05 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A422B51C7; Thu, 13 Jan 2005 19:08:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id B4C775192 for ; Thu, 13 Jan 2005 19:07:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7041447; Thu, 13 Jan 2005 12:07:58 -0700 Message-ID: <41E6C711.4050506@vandyke.com> Date: Thu, 13 Jan 2005 12:08:01 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Niels_M=F6ller?= Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> 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 >>I will say that windows can and does use non-ascii usernames and >>passwords, and it is not an uncommon operating system, though it >>is not the most common of server platforms. > > > I'm under the impression that those windows systems all use utf-8, not > different character sets on different systems or for different users. > Then, they don't matter, because they don't have a problem. Right? True with the current drafts. However, if we changed the drafts to send passwords as 'octets' instead of 'utf-8', it would be a problem. In fact, in such a scenario, I would either have to assume that all clients are using 'utf-8' (BAD) or that all clients are using the same thread locale as the windows operating system, for example, for a japanese install of windows, SJIS. In fact, geez, the problem seems fairly familiar! It is the same problem that 'octet' systems face now... except, instead trying to guess what 'charset' the client is using, they are trying to guess what 'charset' their password database is using. So, we have two possible scenarios here: a. We put utf-8 on the wire. A 'octet' server must guess what charset the password database is using (or what charset the user was using last time they ran 'passwd') b. We put 'octets' on the wire. A server that stores username / passwords in a know charset must now guess what charset the client is using. I suppose if we really want to solve this problem, we do the following, we could introduce a new set of authentication messages where the client sends BOTH the UTF-8 and the raw data entered by the user. Then the server can pick which to use. The client knows the users LC_TYPE, and can therefore safely translate to UTF-8. I don't think we should do this, but if we want to do anything in the space, I think this is what we have to do. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 13 15:26:05 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12047 for ; Thu, 13 Jan 2005 15:26:04 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D2AEB5203; Thu, 13 Jan 2005 20:26:01 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 89C75516E for ; Thu, 13 Jan 2005 20:25:59 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7041640; Thu, 13 Jan 2005 13:25:58 -0700 Message-ID: <41E6D958.2040801@vandyke.com> Date: Thu, 13 Jan 2005 13:26:00 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501130538.AAA01187@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200501130538.AAA01187@Sparkle.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit >>The way I see it, the recent discussion has made clear that the >>benefit of requiring usernames and passwords to be normalized when >>sent as utf8 on the wire, is very questionable. > > I see the value of specifying the charset on the wire at all as > questionable, since it demands that they be character strings; an > encoding-agnostic system has no way to convert its octet strings to > character strings. > > As long as these things are specified as character strings on the wire, > I can't see anything sensible for an encoding-agnostic OS to do, > regardless of what encoding is chosen, regardless of normalization (if > applicable to the encoding), regardless of almost everything else in > this area. I will argue strenuously against removing the UTF-8 for user names and passwords. There is a way for 'octet' systems to handle UTF-8. It has been discussed here previously. I believe that in my implementation for 'octet' systems, I can hit very very close to 100% of all cases by allowing the user to specify what charset his password is in in a user specific dot file that I can read before authentication. (And I believe I can probably get 'good-enough' just by allowing the admin to specify the charset of the passwd database.) If we remove the requirement, I simply CAN NOT get 100% in my windows servers. My server would have to guess the charset of the client. This isn't actually something that an admin can reasonably configure. I could allow the each user to configure the server for the charset of their client, but I can easily imagine that lots of users use more than one client, and some subset of those might use clients with different charsets. (Imagine a user working in a foreign office that uses one charset when they connect from the office machine, but a different charset when they connect from their personal machine.) So given that I think it is possible for an implementation on an 'octet' machine to get 100% functionality using utf-8, and impossible for a 'charset' machine to get 100% functionality using octets, I think we ought to leave the draft alone. If people find that completely unacceptable, I think we have no choice but to introduce "publickey2", "password2", etc., that require the client to send both the UTF-8 and the 'octet' form of the username and password. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 14 08:23:28 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13269 for ; Fri, 14 Jan 2005 08:23:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 9951054B2; Fri, 14 Jan 2005 13:23:18 +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 950F1515B for ; Fri, 14 Jan 2005 13:23:16 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id D07761D5AA1; Fri, 14 Jan 2005 14:23:14 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 32447-01-6; Fri, 14 Jan 2005 14:23:09 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id D415C2505E5; Fri, 14 Jan 2005 14:23:08 +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 j0EDN8bY009804; Fri, 14 Jan 2005 14:23:08 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0EDN3Ig009801; Fri, 14 Jan 2005 14:23:03 +0100 (MET) 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: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> <41E6C711.4050506@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: 14 Jan 2005 14:23:02 +0100 In-Reply-To: <41E6C711.4050506@vandyke.com> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Joseph Galbraith writes: > I suppose if we really want to solve this problem, we do the following, > we could introduce a new set of authentication messages where the > client sends BOTH the UTF-8 and the raw data entered by the user. > Then the server can pick which to use. The client knows the users > LC_TYPE, and can therefore safely translate to UTF-8. The proposal is mostly equivalent to having the client tell the server what the client's local character set is, which might help servers with no clue about the user's preferred character set. Such a message from the client to the server would mean "Hey! I don't think you have any clue what character set is used for my account. But I know that I prefer koi8r, so please convert the data I provide into koi8r before you try to look me up in your user database." Except that if we also send the octets, no actual conversion is needed on the server side. I think Joseph's idea is pretty good. I don't want to add it to the core drafts, but interested parties could surely write up a separate draft to experiment with. It would also be possible to configure a client running on utf8 to work with an "agnostic" server with koi8r (say) accounts, by having the *client* convert the utf8 input into koi8r, and then putting it into the "octets" field. This of course requires that the user is able to explicitly configure the client to assume that the server is actually using koi8r. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 14 17:34:54 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02353 for ; Fri, 14 Jan 2005 17:34:54 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id A963B53FB; Fri, 14 Jan 2005 22:34:51 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from hotmail.com (201009086171.user.veloxzone.com.br [201.9.86.171]) by mail.netbsd.org (Postfix) with SMTP id 5ED3652D8 for ; Fri, 14 Jan 2005 22:34:47 +0000 (UTC) From: "Lucia Gomes" To: Subject: listagem de e-mails Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 14 Jan 2005 19:34:50 -0300 Content-Transfer-Encoding: 8bit Message-Id: <20050114223447.5ED3652D8@mail.netbsd.org> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Mais Emails, venda online de listas de email, fazemos mala direta e propaganda de sua empresa ou negócio para milhões de emails. Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milhões de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.estacion.de/maladireta Temos listas de email Mala Direta, Mala-Direta, Cadastro de Emails, Lista de Emails, Mailing List, Milhões de Emails, Programas de Envio de Email, Email Bombers, Extratores de Email, Listas Segmentadas de Email, Emails Segmentados, Emails em Massa, E-mails http://www.estacion.de/maladireta From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 15 17:01:44 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06266 for ; Sat, 15 Jan 2005 17:01:43 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3FF2851D3; Sat, 15 Jan 2005 22:01:37 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from cz.mit.edu (unknown [IPv6:3ffe:1ce1:0:bb:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id AD41A516A for ; Sat, 15 Jan 2005 22:01:35 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 11B3DE0063; Sat, 15 Jan 2005 17:02:45 -0500 (EST) To: Joseph Galbraith Cc: der Mouse , ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200501130538.AAA01187@Sparkle.Rodents.Montreal.QC.CA> <41E6D958.2040801@vandyke.com> From: Sam Hartman Date: Sat, 15 Jan 2005 17:02:45 -0500 In-Reply-To: <41E6D958.2040801@vandyke.com> (Joseph Galbraith's message of "Thu, 13 Jan 2005 13:26:00 -0700") 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 >>>>> "Joseph" == Joseph Galbraith writes: >>> The way I see it, the recent discussion has made clear that >>> the benefit of requiring usernames and passwords to be >>> normalized when sent as utf8 on the wire, is very >>> questionable. >> I see the value of specifying the charset on the wire at all as >> questionable, since it demands that they be character strings; >> an encoding-agnostic system has no way to convert its octet >> strings to character strings. As long as these things are >> specified as character strings on the wire, I can't see >> anything sensible for an encoding-agnostic OS to do, regardless >> of what encoding is chosen, regardless of normalization (if >> applicable to the encoding), regardless of almost everything >> else in this area. Joseph> I will argue strenuously against removing the UTF-8 for Joseph> user names and passwords. I will block the drafts at the IESG if UTF8 is not sent. I'll respond to the idea of new messages shortly. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 15 17:15:03 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06884 for ; Sat, 15 Jan 2005 17:15:02 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5B80952AB; Sat, 15 Jan 2005 22:14:58 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from cz.mit.edu (unknown [IPv6:3ffe:1ce1:0:bb:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 6021651CB for ; Sat, 15 Jan 2005 22:14:56 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 9F9E6E0063; Sat, 15 Jan 2005 17:16:11 -0500 (EST) To: Joseph Galbraith Cc: =?iso-8859-1?q?Niels_M=F6ller?= , ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> <41E6C711.4050506@vandyke.com> From: Sam Hartman Date: Sat, 15 Jan 2005 17:16:11 -0500 In-Reply-To: <41E6C711.4050506@vandyke.com> (Joseph Galbraith's message of "Thu, 13 Jan 2005 12:08:01 -0700") 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 >>>>> "Joseph" == Joseph Galbraith writes: Joseph> I suppose if we really want to solve this problem, we do Joseph> the following, we could introduce a new set of Joseph> authentication messages where the client sends BOTH the Joseph> UTF-8 and the raw data entered by the user. Then the Joseph> server can pick which to use. The client knows the users Joseph> LC_TYPE, and can therefore safely translate to UTF-8. Joseph> I don't think we should do this, but if we want to do Joseph> anything in the space, I think this is what we have to do. Speaking as an individual, I would not support delaying the core drafts for this change. Speaking as an AD, I'm concerned about this proposal but perhaps not sufficiently concerned to file a discuss. We discussed a similar proposal for Kerberos over in krb-wg and realized that we had significant problems deciding what to do if the two strings were not transforms of each other. In some sense, the client is being given an opportunity to try two usernames and passwords. Are servers required to try both strings or just the one that is most convenient to the server. The obvious answer is that the server tries the most convenient string. But what happens when a client that doesn't really know what its character set is talks to a unicode server? Again we find ourselves back in a situation where at least one party needs to know what character set it speaks. I'd like to draw the working group's attention to RFC 2277, the IETF's character set policy. Quoting section 3.1 of that document: 3.1. What charset to use All protocols MUST identify, for all character data, which charset is in use. You would need to present a strong argument to the IESG why that doesn't apply to you. And as I said above, I'm concerned about the security implications of sending two versions of the same string. So if the working group decides to follow this approach, here is what you must do. First, you must describe RFC 2277 concerns and explain why the charset policy does not apply or why you are violating a MUST from that policy. Second, you must explore the security implications of your proposal and include them in the document you submit. The IESG will evaluate the proposal; I know my evaluation will focus on these two issues. It's reasonably lykely that the IESG will decide not to publish such a proposal. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jan 15 23:29:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17763 for ; Sat, 15 Jan 2005 23:29:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4389851C2; Sun, 16 Jan 2005 04:29:17 +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 3F3F65171 for ; Sun, 16 Jan 2005 04:29:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA06202; Sat, 15 Jan 2005 23:29:14 -0500 (EST) From: der Mouse Message-Id: <200501160429.XAA06202@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Sat, 15 Jan 2005 23:15:54 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> <41E6C711.4050506@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > 3.1. What charset to use > All protocols MUST identify, for all character data, which > charset is in use. > You would need to present a strong argument to the IESG why that > doesn't apply to you. But it does apply-- vacuously. Because the whole problem is what to do when you *don't* have "character data", just an opaque octet string. (It probably is character data at some conceptual level, in a human mind somewhere, but even assuming that that's always so, that level is totally inaccessible to software.) Of course, this is my take on it. Niels seems to think that a right answer is to just impose a character set on the octet string by fiat, and given how alone I am in holding up my end of this question, that's probably about what the WG position is going to end up being. (And in that case there is no question of violating the snippet you describe.) I find it somewhat odd that the IESG considers it so impossible for these things to be octet strings rather than character strings that they're willing to not only approve a protocol that makes no provision for octet strings, but, you say, to actively block a protocol that goes out of its way to make octet strings possible. But apparently I'm alone in wanting to be able to use protocol fields that are fundamentally octet strings to represent octet strings rather than character strings; I can only infer that nobody else cares about traditional Unices any longer. /~\ 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 Jan 16 18:06:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24442 for ; Sun, 16 Jan 2005 18:06:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 510A151D3; Sun, 16 Jan 2005 23:05:59 +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 BDD0B5172 for ; Sun, 16 Jan 2005 23:05:57 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2005 16:13:00 +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 j0GN5tl2019670 for ; Sun, 16 Jan 2005 15:05:55 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA28421 for ; Sun, 16 Jan 2005 15:05:55 -0800 (PST) Date: Sun, 16 Jan 2005 15:05:55 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: Open Issues from Recent Comments In-Reply-To: Message-ID: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> 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 Wed, 12 Jan 2005, [iso-8859-1] Niels M=F6ller wrote: > Chris Lonvick writes: > > > 4) SSH_DISCONNECT_* descriptions > > ... > > > Proposed Resolution: Can I get some feedback on this? I was under the > > assumption that the "descriptions" are the standardized text to send in > > the "description" field. I too felt that was a bit redundant but figur= ed > > that it was setting the precendence for the descriptions associated wit= h > > local namespaces. What's the right thing to do here? > > The description is an arbitrary human readably strings describing the > reason for the disconnection in some more detail. The text in will > usually end up on the users terminal or in the servers log file > (perhaps only when running in verbose mode). > > I think the text in draft-ietf-secsh-transport-22.txt is ok, it's just > the table header that must be changed, to something like > > Reason code Symbolic name > 1 SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT > > Or actually, the table is duplicated in NUMBERS, section 4.2.2, so > perhaps it could be deleted all together. Got it. I'm assuming that this will then also apply to SSH_EXTENDED_DATA_STDERR in [CONNECT] ("data" as the table header will become "Symbolic name"), and the SSH_MSG_CHANNEL_OPEN_FAILURE table also in [CONNECT]. Let me know if anyone disagrees with this. > > It would be desirable with a table describing under what circumstances > each value should be used, but perhaps we can live without that. Most, > but not all, of the symbolic names are self-explanatory. If we can't come to consensus on UTF8, I'll have plenty of time to work on that. :( Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 16 18:14:18 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25038 for ; Sun, 16 Jan 2005 18:14:17 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 1820D51D7; Sun, 16 Jan 2005 23:14:14 +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 C89F05172 for ; Sun, 16 Jan 2005 23:14:12 +0000 (UTC) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Jan 2005 15:18:15 -0800 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0GNEAvl001247 for ; Sun, 16 Jan 2005 15:14:11 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA01476 for ; Sun, 16 Jan 2005 15:14:10 -0800 (PST) Date: Sun, 16 Jan 2005 15:14:10 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Traffic Analysis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I was reminded a few weeks ago that traffic analysis has been a sore spot for SSH (both v1 and v2) in the past. SSH_MSG_IGNORE is actually called out to thwart "advanced traffic analysis" in [TRANS]. However, there is no reference to it in the Security Considerations section in [ARCH]. To rectify that, I've added the following text and reference to [ARCH]. 9.2.9 Traffic Analysis Passive monitoring of any protocol may give an attacker some information about the session, the user, or protocol specific information that they would otherwise not be able to garner. For example, it has been shown that traffic analysis of an SSH session can yield information about the length of the password. [Openwall] Implementors should use the SSH_MSG_IGNORE packet as described in [SSH-TRANS] along with any other methods they may find to prevent traffic analysis. [Openwall] Solar Designer and D. Song, "SSH Traffic Analysis Attacks", Presentation given at HAL2001 and NordU2002 Conferences, Sept 2001. Please let me know if this is acceptable. Does anyone have any better reference? Thanks, Chris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 16 18:20:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25463 for ; Sun, 16 Jan 2005 18:20:27 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 888915254; Sun, 16 Jan 2005 23:20:26 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 4C85C51BF for ; Sun, 16 Jan 2005 23:20:25 +0000 (UTC) Received: from [127.0.0.1] (HELO VIPER) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 7048142 for ietf-ssh@NetBSD.org; Sun, 16 Jan 2005 16:20:20 -0700 Message-ID: <007501c4fc21$b50c2990$6501a8c0@VIPER> From: "Jeff P. Van Dyke" To: References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> Subject: Consenus on UTF8 Date: Sun, 16 Jan 2005 16:18:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Chris Lonvick writes: > If we can't come to consensus on UTF8, I'll have plenty of time to work on > that. :( I'd like to see us get to consensus on UTF8 soon... For the purposes of this (or any IETF) working group, can someone remind me how "consenus" is defined? Jeff P. Van Dyke jpv@vandyke.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 16 18:53:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27874 for ; Sun, 16 Jan 2005 18:53:08 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B18B05302; Sun, 16 Jan 2005 23:53:07 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from cz.mit.edu (unknown [IPv6:3ffe:1ce1:0:bb:20e:9bff:fe1b:4e1]) by mail.netbsd.org (Postfix) with ESMTP id 306A85172 for ; Sun, 16 Jan 2005 23:53:06 +0000 (UTC) Received: by cz.mit.edu (Postfix, from userid 8042) id 5B942E0063; Sun, 16 Jan 2005 18:53:03 -0500 (EST) To: "Jeff P. Van Dyke" Cc: Subject: Re: Consenus on UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <007501c4fc21$b50c2990$6501a8c0@VIPER> From: Sam Hartman Date: Sun, 16 Jan 2005 18:53:02 -0500 In-Reply-To: <007501c4fc21$b50c2990$6501a8c0@VIPER> (Jeff P. Van Dyke's message of "Sun, 16 Jan 2005 16:18:31 -0700") 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 >>>>> "Jeff" == Jeff P Van Dyke writes: Jeff> For the purposes of this (or any IETF) working group, can Jeff> someone remind me how "consenus" is defined? The chair judges consensus. If the chair claims there is a consensus and someone disagrees they can talk to the chair about it or bring it up on the list. There is a formal procedure for dealing with appeals, but we won't need that here;). Bill can correct me if I'm wrong, but I don't think we are blocking on the UTF 8 change. It's already in the draft, no one has proposed alternative text. There's discussion for adding additional text (possibly in the core drafts, possibly somewhere else) to handle the case where you don't know what character set your encoding is. To the extent that I started that discussion, my intent was to start a non-blocking dsicussion. If we come to a consensus on that thread in time to make a change to the core drafts, then we do. If not, that discussion does not block the core drafts. I think the issue we're blocking on is trademark and that requires no action on this WG's part. Technically speaking Russ is the only one holding a discuss on the ssh drafts. --Sam From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sun Jan 16 22:56:09 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13040 for ; Sun, 16 Jan 2005 22:56:09 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CC666521E; Mon, 17 Jan 2005 03:56:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 562FE51DD for ; Mon, 17 Jan 2005 03:55:59 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1CqKXY-0006wA-00; Mon, 17 Jan 2005 00:14:40 +0000 From: Ben Harris To: clonvick@cisco.com Subject: Re: Traffic Analysis In-Reply-To: References: Organization: Linux Unlimited Cc: ietf-ssh@NetBSD.org Message-Id: Date: Mon, 17 Jan 2005 00:14:40 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article you write: >9.2.9 Traffic Analysis > > Passive monitoring of any protocol may give an attacker some > information about the session, the user, or protocol specific > information that they would otherwise not be able to garner. For > example, it has been shown that traffic analysis of an SSH session > can yield information about the length of the password. [Openwall] > Implementors should use the SSH_MSG_IGNORE packet as described in > [SSH-TRANS] along with any other methods they may find to prevent > traffic analysis. It might also be worth mentioning that the "random padding" field can be used to obscure the length of packets. I'd suggest, after "SSH_MSG_IGNORE packet" adding ", and variable-length random padding,", though that wording could doubtless be improved. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 05:02:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21657 for ; Mon, 17 Jan 2005 05:02:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4070851F9; Mon, 17 Jan 2005 10:02:21 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by mail.netbsd.org (Postfix) with ESMTP id D0136519A for ; Mon, 17 Jan 2005 10:02:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 82BBD3486B; Mon, 17 Jan 2005 23:02:18 +1300 (NZDT) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04556-14; Mon, 17 Jan 2005 23:02:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 697C634828; Mon, 17 Jan 2005 23:02:18 +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 65F0837746; Mon, 17 Jan 2005 23:02:18 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CqTiM-0004o8-00; Mon, 17 Jan 2005 23:02:26 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Traffic Analysis In-Reply-To: Message-Id: Date: Mon, 17 Jan 2005 23:02:26 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick writes: Very minor nitpick, the sentence break attaches the "Openwall" to the following sentence, so it appears to be reading: can yield information about the length of the password. [Openwall] Implementors should use the SSH_MSG_IGNORE packet as described Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 05:12:08 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22524 for ; Mon, 17 Jan 2005 05:12:08 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 32EE251D1; Mon, 17 Jan 2005 10:12:04 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from faui03.informatik.uni-erlangen.de (faui03.informatik.uni-erlangen.de [131.188.30.103]) by mail.netbsd.org (Postfix) with ESMTP id 7A8A1519A for ; Mon, 17 Jan 2005 10:12:02 +0000 (UTC) Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id j0HA05JM002005; Mon, 17 Jan 2005 10:00:05 GMT Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id B0E6F14275; Mon, 17 Jan 2005 09:09:18 +0100 (CET) Date: Mon, 17 Jan 2005 09:09:18 +0100 From: Markus Friedl To: Ben Harris , clonvick@cisco.com Cc: ietf-ssh@NetBSD.org Subject: Re: Traffic Analysis Message-ID: <20050117080918.GB3559@folly> References: 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, Jan 17, 2005 at 12:14:40AM +0000, Ben Harris wrote: > In article you write: > >9.2.9 Traffic Analysis > > > > Passive monitoring of any protocol may give an attacker some > > information about the session, the user, or protocol specific > > information that they would otherwise not be able to garner. For > > example, it has been shown that traffic analysis of an SSH session > > can yield information about the length of the password. [Openwall] > > Implementors should use the SSH_MSG_IGNORE packet as described in > > [SSH-TRANS] along with any other methods they may find to prevent > > traffic analysis. > > It might also be worth mentioning that the "random padding" field can be > used to obscure the length of packets. I'd suggest, after "SSH_MSG_IGNORE > packet" adding ", and variable-length random padding,", though that wording > could doubtless be improved. please don't add this, random padding is wrong and does not really help, as it can be filtered out. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 07:05:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28356 for ; Mon, 17 Jan 2005 07:05:19 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id EB1C65231; Mon, 17 Jan 2005 12:05:15 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [193.201.200.170]) by mail.netbsd.org (Postfix) with ESMTP id 90E8751CF for ; Mon, 17 Jan 2005 12:05:14 +0000 (UTC) Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local (return-path bjharris@chiark.greenend.org.uk) id 1CqVdB-0003oZ-00 for ietf-ssh@netbsd.org; Mon, 17 Jan 2005 12:05:13 +0000 From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Re: Traffic Analysis In-Reply-To: <20050117080918.GB3559@folly> References: <20050117080918.GB3559@folly> Organization: Linux Unlimited Message-Id: Date: Mon, 17 Jan 2005 12:05:13 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list In article <20050117080918.GB3559@folly> you write: >On Mon, Jan 17, 2005 at 12:14:40AM +0000, Ben Harris wrote: >> It might also be worth mentioning that the "random padding" field can be >> used to obscure the length of packets. I'd suggest, after "SSH_MSG_IGNORE >> packet" adding ", and variable-length random padding,", though that wording >> could doubtless be improved. > >please don't add this, random padding is wrong and >does not really help, as it can be filtered out. How so? The padding, and its length, are encrypted, so I can't see how an attacker is likely to be able to filter out the padding unless they've already broken the cipher, in which case their knowing the length of the packet is the least of our problems. If there's something I've overlooked, then an explanation of it probably needs to be added to the Security Considerations so that others don't overlook it too. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 09:02:27 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05904 for ; Mon, 17 Jan 2005 09:02:26 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id D815F52BB; Mon, 17 Jan 2005 14:02:22 +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 A009F519A for ; Mon, 17 Jan 2005 14:02:20 +0000 (UTC) Received: from localhost (lenin.lysator.liu.se [130.236.254.45]) by mail.lysator.liu.se (Postfix) with ESMTP id 32CFA18A80; Mon, 17 Jan 2005 15:02:19 +0100 (MET) Received: from mail.lysator.liu.se ([130.236.254.102]) by localhost (lenin.lysator.liu.se [130.236.254.45]) (amavisd-new, port 10024) with LMTP id 14911-01-3; Mon, 17 Jan 2005 15:02:13 +0100 (CET) Received: from sellafield.lysator.liu.se (sellafield.lysator.liu.se [130.236.254.103]) by mail.lysator.liu.se (Postfix) with ESMTP id A785041F3C; Mon, 17 Jan 2005 15:02:12 +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 j0HE2CbY015965; Mon, 17 Jan 2005 15:02:12 +0100 (MET) Received: (from nisse@localhost) by sellafield.lysator.liu.se (8.12.10/8.12.8/Submit) id j0HE26qY015962; Mon, 17 Jan 2005 15:02:06 +0100 (MET) X-Authentication-Warning: sellafield.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Chris Lonvick Cc: ietf-ssh@NetBSD.org Subject: Re: Traffic Analysis 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: 17 Jan 2005 15:01:57 +0100 In-Reply-To: Message-ID: Lines: 66 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at lysator.liu.se Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit Chris Lonvick writes: > I was reminded a few weeks ago that traffic analysis has been a sore spot > for SSH (both v1 and v2) in the past. I think there are sufficient support in the ssh2 protocol to make traffic analysis harder, but I think it's done very poorly in current implementations. I don't even try. My first suggestion to myself and others wanting to make ssh connections harder to analyze, is as chop up the stream into TCP segments at boundaries that are unrelated to the ssh message boundaries. To explain this idea by example, say you have some 17 bytes of data do send, an SSH_MSG_CHANNEL_DATA or SSH_MSG_USERAUTH_REQUEST, and this generates some 48 bytes of encrypted data using minimal padding. Say you want to hide ssh message lengths by sending TCP segments of 100 bytes only. Then, generate a random SSH_MSG_IGNORE packets, so that you get a total amount of encrypted data of 112 bytes, say. Send a 100 bytes TCP segment, and leave the remaining 12 bytes, corresponding to a part of the SSH_MSG_IGNORE packet, wait in the output buffer until you have any new data you want to send. This is just a simple example, one can impose more sophisticated requirements on the size and timing of transmitted segments. If this is done carefully, I think the only information you will give the adversary is 1. The TCP/IP end points. 2. A coarse measure on the activity over time. For 2, say you make the implementation send one 100 byte segment every 100ms or so (depending on how mush network resources your willing to spend on an essentially idle connection). Then if the user starts to transfer a large file over the session, then you'll want to increase the packet size or decrease the inter-packet spacing in order to get the job done in a reasonable time, and the attacker can observe this. It seems hard to avoid leaking information about (2) this problem without sacrificing a lot of either usability or network efficiency. Maybe all of this is obvious to everybody, but I appreciate comments. If/when I add resistance to traffic analysis to my implementation, I plan to use soem variant of the above scheme. > 9.2.9 Traffic Analysis > > Passive monitoring of any protocol may give an attacker some > information about the session, the user, or protocol specific > information that they would otherwise not be able to garner. For > example, it has been shown that traffic analysis of an SSH session > can yield information about the length of the password. [Openwall] > Implementors should use the SSH_MSG_IGNORE packet as described in > [SSH-TRANS] along with any other methods they may find to prevent > traffic analysis. The phrase "as described in [SSH-TRANS]" makes me think that the referenced document describes in detail what one should do. But the document (naturally) describes only the message format. Besides this minor detail, the text looks ok to me. Regards, /Niels From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 09:46:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09976 for ; Mon, 17 Jan 2005 09:46:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 297B95224; Mon, 17 Jan 2005 14:46:18 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by mail.netbsd.org (Postfix) with ESMTP id 96A4C518A for ; Mon, 17 Jan 2005 14:46:16 +0000 (UTC) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 0E5003417E; Tue, 18 Jan 2005 03:16:15 +1300 (NZDT) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32589-29; Tue, 18 Jan 2005 03:16:14 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 3BD10340F4; Tue, 18 Jan 2005 03:16:14 +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 35A3037744; Tue, 18 Jan 2005 03:16:14 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1CqXg7-00050l-00; Tue, 18 Jan 2005 03:16:23 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: clonvick@cisco.com, nisse@lysator.liu.se Subject: Re: Traffic Analysis Cc: ietf-ssh@NetBSD.org In-Reply-To: Message-Id: Date: Tue, 18 Jan 2005 03:16:23 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: ietf-ssh-owner@NetBSD.org Precedence: list Chris Lonvick writes: >I think there are sufficient support in the ssh2 protocol to make traffic >analysis harder, but I think it's done very poorly in current >implementations. I don't even try. Nor do I (well, except in the handshake phase where I pad a few packets that matter to a constant length). It'd be kind of a fun thing to play with/hack around on (there's a million parameters you can tune, cover traffic generation, padding to fixed boundaries, TCP segment slicing as you say, etc etc), but so far I've had zero user demand for this so I'm not in any hurry to implement it. Has anyone seen any significant demand for this from other than tinfoil-hat types? Peter. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 12:34:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26873 for ; Mon, 17 Jan 2005 12:34:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 4B7515302; Mon, 17 Jan 2005 17:34:09 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id F21A85219 for ; Mon, 17 Jan 2005 17:34:06 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7049935; Mon, 17 Jan 2005 10:34:05 -0700 Message-ID: <41EBF6FC.9030004@vandyke.com> Date: Mon, 17 Jan 2005 10:33:48 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl Cc: Ben Harris , clonvick@cisco.com, ietf-ssh@NetBSD.org Subject: Re: Traffic Analysis References: <20050117080918.GB3559@folly> In-Reply-To: <20050117080918.GB3559@folly> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl wrote: > On Mon, Jan 17, 2005 at 12:14:40AM +0000, Ben Harris wrote: > >>In article you write: >> >>>9.2.9 Traffic Analysis >>> >>> Passive monitoring of any protocol may give an attacker some >>> information about the session, the user, or protocol specific >>> information that they would otherwise not be able to garner. For >>> example, it has been shown that traffic analysis of an SSH session >>> can yield information about the length of the password. [Openwall] >>> Implementors should use the SSH_MSG_IGNORE packet as described in >>> [SSH-TRANS] along with any other methods they may find to prevent >>> traffic analysis. >> >>It might also be worth mentioning that the "random padding" field can be >>used to obscure the length of packets. I'd suggest, after "SSH_MSG_IGNORE >>packet" adding ", and variable-length random padding,", though that wording >>could doubtless be improved. > > > please don't add this, random padding is wrong and > does not really help, as it can be filtered out. I'm not sure I understand this? How can it be filtered out? I thought this attack was based on the fact that in most implementations, for certain key packets, the TCP segment length (which is observable) often corresponds to the the SSH packet length (which is not observable), and therefor allows certain deductions about the length of sensitive fields with-in the packet? If that is the case, then it seems to me that perturbing the pad to change the length of the the packet (and therefore the length of the TCP segment) would remove the attackers ability to make such deductions about the length of fields in the packet? It also seems that it is more likely that a packet with extra pad will be sent as one TCP segment than that a SSH_MSG_USERAUTH_REQUEST and a SSH_MSG_IGNORE will be sent in a single TCP segment (and probably easier to implement.) In fact, I believe the wording above needs some adjustment to note that for SSH_MSG_IGNORE to be effectively used to thwart this kind of attack, it MUST be sent in the same TCP segment as the SSH packet it is protecting. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 13:55:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03909 for ; Mon, 17 Jan 2005 13:55:44 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B223852B9; Mon, 17 Jan 2005 18:55:38 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id AE08051C2 for ; Mon, 17 Jan 2005 18:55:36 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7050203 for ietf-ssh@netbsd.org; Mon, 17 Jan 2005 11:55:35 -0700 Message-ID: <41EC0A09.50907@vandyke.com> Date: Mon, 17 Jan 2005 11:55:05 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> <41E6C711.4050506@vandyke.com> In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>>"Joseph" == Joseph Galbraith writes: > > > Joseph> I suppose if we really want to solve this problem, we do > Joseph> the following, we could introduce a new set of > Joseph> authentication messages where the client sends BOTH the > Joseph> UTF-8 and the raw data entered by the user. Then the > Joseph> server can pick which to use. The client knows the users > Joseph> LC_TYPE, and can therefore safely translate to UTF-8. > > Joseph> I don't think we should do this, but if we want to do > Joseph> anything in the space, I think this is what we have to do. > > Speaking as an individual, I would not support delaying the core > drafts for this change. Definitely not. To be honest, I don't really like the proposal that much-- I was just tired of repeating the same debate over and over again, so I figured we could move on to debating a solution rather than the problem :-) I also tend to be the type that figures if we've analyzed two or three different solutions we are more likely to have found the correct one than if we only considered one. So, given the fact that I'm unwilling to hold up the core drafts, think it terribly ugly that the entire auth draft would have to be duplicated with multiple username and password fields for each userauth-request message, there are ambiguities and potential security issues in terms of which username/password fields should be used by the server, and reluctance from the AD, I'll withdraw my proposal. For our unix implementations I believe that 'imposing' a character set is a fine solution. In fact, since all input systems, either local or remote, connected to a 'octet' based system, MUST use the same encoding system to provide passwords, I am quite confident that allowing the administrator to specify a single charset to translate usernames and passwords to will be sufficient to produce interoperability superior to what would be available on a locally attached terminal. For example, if a user sits down at a X-Station and logs on via XDM, the characters he types on the keyboard are encoded in a certain way. (This is irregardless of whether the passwd database is storing octets or not.) If the user then walks over to a VT320 terminal that is encoding the keystrokes in a different way, he will not be able to log in. All the input devices capable of taking username/password input MUST encode input characters identically. So, from a certain viewpoint, in such an 'octet' system, the passwd database is not really encoded in 'octets', it is simply the charset used to encode input by the login devices in use. I've felt all along that the current wording in the drafts is fine, but now, over the course of this discussion and and analysis of the problem, I've realized the limitations of such an 'octet' based system, even to locally attached terminals, so my brain now agrees with my gut. I'm confident that a properly implemented SSH server that is conformant to the drafts as currently written can produce better interoperability than is available at the locally attached terminal. Equal interoperability could be obtained locally by having the login, XDM, and passwd programs translate from the device's input encoding to a common charset encoding... but that is a discussion for a different mailing list :-) So my vote is no change to the drafts. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 14:12:21 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04931 for ; Mon, 17 Jan 2005 14:12:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2F6E7530D; Mon, 17 Jan 2005 19:12:19 +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 738B951C2 for ; Mon, 17 Jan 2005 19:12:15 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA09122; Mon, 17 Jan 2005 14:12:14 -0500 (EST) From: der Mouse Message-Id: <200501171912.OAA09122@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 17 Jan 2005 14:04:56 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: <41EC0A09.50907@vandyke.com> References: <200412230608.BAA21429@Sparkle.Rodents.Montreal.QC.CA> <200412250018.TAA11104@Sparkle.Rodents.Montreal.QC.CA> <200501040550.AAA01364@Sparkle.Rodents.Montreal.QC.CA> <41DAD2AB.3060608@vandyke.com> <41E6C711.4050506@vandyke.com> <41EC0A09.50907@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > In fact, since all input systems, either local or remote, connected > to a 'octet' based system, MUST use the same encoding system to > provide passwords, I've seen others claim basically this, and it simply isn't true. If my password is the octet string 0x20 0xe7 0x22, it doesn't matter whether I type that 0xe7 in a way that the input method thinks is an 8859-1 c-cedilla or an 8859-7 eta or whatever; it still works. (Assuming, of course, that the channel between the typing and the checking is an octet-string channel.) > For example, if a user sits down at a X-Station and logs on via XDM, > the characters he types on the keyboard are encoded in a certain way. > (This is irregardless of whether the passwd database is storing > octets or not.) > If the user then walks over to a VT320 terminal that is encoding the > keystrokes in a different way, he will not be able to log in. This is true only if the user not only insists on thinking of the password as a character sequence rather than an octet sequence, but also insists on typing it that way rather than adjusting to the difference. The login failure is really due to the mismatch between the user's concept of the password as a character string and the system's implementation of the password as an octet string. (Such a user would be better served by a character-string system, but that's neither here nor there.) > All the input devices capable of taking username/password input MUST > encode input characters identically. No, they simply must be capable of generating the necessary octets. What characters the input method thinks they correspond to is irrelevant. /~\ 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 Mon Jan 17 14:59:14 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08221 for ; Mon, 17 Jan 2005 14:59:13 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 7181C5237; Mon, 17 Jan 2005 19:59:10 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from draco.cus.cam.ac.uk (draco.cus.cam.ac.uk [131.111.8.18]) by mail.netbsd.org (Postfix) with ESMTP id 0F38E518E for ; Mon, 17 Jan 2005 19:59:09 +0000 (UTC) Received: from bjh21 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 4.43) id 1CqcWD-0001P3-8o for ietf-ssh@netbsd.org; Mon, 17 Jan 2005 19:26:29 +0000 Date: Mon, 17 Jan 2005 19:26:29 +0000 (GMT) From: Ben Harris To: ietf-ssh@NetBSD.org Subject: Channel window limits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list In draft-ietf-secsh-connect-23.txt, there seems to be no limit on the window size that an implementation can advertise. While each SSH_MSG_CHANNEL_WINDOW_ADJUST can add at most 2^32-1 bytes to the window, an implementation can send as many WINDOW_ADJUSTs as it wants. This is a problem because it means that its peer has to keep track of an arbitrarily-large window, and in particular one that can't be represented by a 32-bit unsigned integer. I doubt that this is the intention of the spec, so I'd suggest the following change: After: After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. add: The window MUST NOT be increased above 2^32-1 bytes. This isn't desperately important, since I doubt any sane implementation would violate this constraint anyway, but if there's another draft of -connect- I think it should be in there. Of course, that assumes I'm right about the implication of the current draft... -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 16:14:37 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15222 for ; Mon, 17 Jan 2005 16:14:37 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 19902531F; Mon, 17 Jan 2005 21:14:33 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id A60D051C9 for ; Mon, 17 Jan 2005 21:14:30 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7050501; Mon, 17 Jan 2005 14:14:29 -0700 Message-ID: <41EC2A83.1030802@vandyke.com> Date: Mon, 17 Jan 2005 14:13:39 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Harris Cc: ietf-ssh@NetBSD.org Subject: Re: Channel window limits References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Ben Harris wrote: > In draft-ietf-secsh-connect-23.txt, there seems to be no limit on the > window size that an implementation can advertise. While each > SSH_MSG_CHANNEL_WINDOW_ADJUST can add at most 2^32-1 bytes to the > window, an implementation can send as many WINDOW_ADJUSTs as it wants. > This is a problem because it means that its peer has to keep track of an > arbitrarily-large window, and in particular one that can't be > represented by a 32-bit unsigned integer. I doubt that this is the > intention of the spec, so I'd suggest the following change: > > After: > > After receiving this message, the recipient MAY send the given number > of bytes more than it was previously allowed to send; the window size > is incremented. > > add: > > The window MUST NOT be increased above 2^32-1 bytes. > > This isn't desperately important, since I doubt any sane implementation > would violate this constraint anyway, but if there's another draft of > -connect- I think it should be in there. > > Of course, that assumes I'm right about the implication of the current > draft... How about: After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1. The window MUST NOT be increased above 2^32 - 1 bytes. It is a little stronger than what you proposed, but I believe there are already imcompatibilites with some implementations using a signed 32 bit integer to represent this and others using an unsigned, so it does need to be clarified. - Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 17 19:17:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08446 for ; Mon, 17 Jan 2005 19:17:24 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 943BF52D8; Tue, 18 Jan 2005 00:16:47 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from virgo.cus.cam.ac.uk (virgo.cus.cam.ac.uk [131.111.8.20]) by mail.netbsd.org (Postfix) with ESMTP id E3A415288 for ; Tue, 18 Jan 2005 00:16:45 +0000 (UTC) Received: from bjh21 (helo=localhost) by virgo.cus.cam.ac.uk with local-esmtp (Exim 4.43) id 1Cqh36-0006Ly-5r; Tue, 18 Jan 2005 00:16:44 +0000 Date: Tue, 18 Jan 2005 00:16:44 +0000 (GMT) From: Ben Harris To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Channel window limits In-Reply-To: <41EC2A83.1030802@vandyke.com> Message-ID: References: <41EC2A83.1030802@vandyke.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 17 Jan 2005, Joseph Galbraith wrote: > After receiving this message, the recipient MAY send the given number > of bytes more than it was previously allowed to send; the window size > is incremented. Implementations MUST correctly handle window sizes of > up to 2^32 - 1. The window MUST NOT be increased above 2^32 - 1 > bytes. That sounds good to me, yes. I'd insert "bytes" after the first instance of "2^31 - 1", giving: After receiving this message, the recipient MAY send the given number of bytes more than it was previously allowed to send; the window size is incremented. Implementations MUST correctly handle window sizes of up to 2^32 - 1 bytes. The window MUST NOT be increased above 2^32 - 1 bytes. -- Ben Harris From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 18 15:55:25 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00888 for ; Tue, 18 Jan 2005 15:55:23 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2118951DC; Tue, 18 Jan 2005 20:55:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by mail.netbsd.org (Postfix) with ESMTP id 7213651A1 for ; Tue, 18 Jan 2005 20:55:17 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by wellington.cnchost.com id NAA04637; Tue, 18 Jan 2005 13:51:39 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: "'der Mouse'" Cc: Subject: RE: UTF8 Date: Tue, 18 Jan 2005 19:51:37 +0100 Message-ID: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200501171912.OAA09122@Sparkle.Rodents.Montreal.QC.CA> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable > > If the user then walks over to a VT320 terminal that is=20 > > encoding the keystrokes in a different way, he will not > > be able to log in. >=20 > This is true only if the user not only insists on thinking of=20 > the password as a character sequence rather than an octet=20 > sequence, but also insists on typing it that way rather than=20 > adjusting to the difference. Given that you present this as a special case ("not only ... but also = ..."), I wonder what kind of users your software is targeting. I have yet to meet a user that wouldn't fall into this "special" = category. But then again, we write our software for people, not for cyborgs. :) > The login failure is really due to the mismatch between the > user's concept of the password as a character string and the > system's implementation of the password as an octet string. And when there is such a mismatch, who is right? The machine, or the = user? (My answer is, definitely, most always, the user.) > (Such a user would be better served by a character-string system, > but that's neither here nor there.) And if I translate this into ordinary-speak ;) it says: virtually every = user would be better served by such a system. It makes no sense to write our software as though it's aimed for cyborgs when it's aimed for real people who mostly don't even know what the = ASCII code for the letter 'b' is (and probably don't even know where to look = it up, or what an ASCII code is in the first place); let alone being able = to manipulate input so as to successfully enter a password when the input charset has been set incorrectly. Maybe there are wiz kids out there who do this, but maybe they too would = be better off simply correcting the code page setting so that the password = can be entered normally. The vast majority of people cannot enter binary data from a password = prompt, and most SSH clients will probably not even allow them to. On the other hand, if you have programs connecting to other programs unattended, you can use other modes of authentication better suited for = that purpose than arbitrarily-encoded binary passwords. It seems to me too that interoperability and user expectations are = better served by treating usernames and passwords as character strings, not arbitrary binary data. Best regards, denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 18 21:41:45 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01905 for ; Tue, 18 Jan 2005 21:41:45 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2FB2F5389; Wed, 19 Jan 2005 02:41:39 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 93C79516E for ; Wed, 19 Jan 2005 02:41:37 +0000 (UTC) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa06713; 18 Jan 2005 19:40 EST Date: Tue, 18 Jan 2005 19:40:14 -0500 From: Jeffrey Hutzelman To: denis bider , "'der Mouse'" Cc: ietf-ssh@NetBSD.org Subject: RE: UTF8 Message-ID: <159240000.1106095214@minbar.fac.cs.cmu.edu> In-Reply-To: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> 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 Tuesday, January 18, 2005 19:51:37 +0100 denis bider wrote: >> > If the user then walks over to a VT320 terminal that is >> > encoding the keystrokes in a different way, he will not >> > be able to log in. >> >> This is true only if the user not only insists on thinking of >> the password as a character sequence rather than an octet >> sequence, but also insists on typing it that way rather than >> adjusting to the difference. > > Given that you present this as a special case ("not only ... but also > ..."), I wonder what kind of users your software is targeting. Really, so do I. Certainly I don't know anyone who thinks of their username or password as being an octet string. Nor do I know of anyone who would put up with this sort of behaviour from software, instead of just getting something that actually works for them. I'm not the chair of this group, so I don't get to decide when we do or don't have consensus here. However, it sure looks to me like we have "rough consensus" that these things are in fact character strings, not octet strings, and that the SSH protocol should behave accordingly. Once such a consensus has been reached, it's generally considered bad form for the one dissenting voice to keep repeating the same argument over and over again, particularly with no new information. Someone commented to me the other day that it seemed like almost no one in this group had actually _read_ IETF character set policy as defined in RFC2277. I would suggest that anyone wishing to participate further in this discussion take a break right now to do so. The entire document is only 9 pages long, and besides providing a variety of useful advice, it also represents the consensus of the IETF as to how protocols must behave with respect to character sets. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 18 22:08:32 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03373 for ; Tue, 18 Jan 2005 22:08:31 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B7118539E; Wed, 19 Jan 2005 03:08:27 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from tonnant.cnchost.com (tonnant.concentric.net [207.155.248.72]) by mail.netbsd.org (Postfix) with ESMTP id 22DB0516E for ; Wed, 19 Jan 2005 03:08:26 +0000 (UTC) Received: from nucleus (BSN-77-185-155.dsl.siol.net [193.77.185.155]) by tonnant.cnchost.com id WAA12236; Tue, 18 Jan 2005 22:08:12 -0500 (EST) [ConcentricHost SMTP Relay 1.17] From: "denis bider" To: Subject: timing of banner Date: Wed, 19 Jan 2005 04:08:09 +0100 Message-ID: <000201c4fdd4$1db37210$d7b7fea9@nucleus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable In [SSH-USERAUTH], I suggest the following clarification: Now: The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time before authentication is successful. Suggested (short and sufficient): The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time after this authentication protocol starts and before authentication is successful. Alternative (longer and more informative): The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time before authentication is successful. Note however that, like other = message types defined in this document, this message is part of the = authentication protocol, so it also MUST NOT be sent before the authentication protocol = is requested. Rationale:=20 From the current wording, superficial implementors, which more = frequently than not fail to differentiate between SSH protocol layers, may conclude that it is OK to send the BANNER message even before the service request = for "ssh-userauth" has been received. My clarification aims to prevent this misinterpretation and to affirm that, since the BANNER message is part = of the ssh-userauth protocol, it is incorrect to send it before the ssh-userauth layer is started. This helps implementors which implement = SSH layers separately, thus encountering difficulties when boundaries = between layers are incorrectly breached. denis From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 00:59:12 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13729 for ; Wed, 19 Jan 2005 00:59:12 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 00B37516C; Wed, 19 Jan 2005 05:59:00 +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 485EA516C for ; Wed, 19 Jan 2005 05:58:57 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id AAA05868; Wed, 19 Jan 2005 00:58:55 -0500 (EST) From: der Mouse Message-Id: <200501190558.AAA05868@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Tue, 18 Jan 2005 22:13:55 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: <159240000.1106095214@minbar.fac.cs.cmu.edu> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > Certainly I don't know anyone who thinks of their username or > password as being an octet string. Neither do I, usually. But I know that it _is_ an octet string to the OS, fundamentally, and if I have trouble logging in, I take that into account. > However, it sure looks to me like we have "rough consensus" that > these things are in fact character strings, not octet strings, and > that the SSH protocol should behave accordingly. "In fact"? Humans think of them as character strings (mostly, at least). OSes, at least the ones in question, treat them as opaque octet strings. Which is the "fact"? When it comes to actually successfully logging in, I would say the octet string is the fact: it doesn't matter whether the characters you type are the ones you think of your username or password as containing, if the resulting octet string doesn't match. What I think we do have consensus on, even if only consensus by apathy, is that this issue can be ignored; I appear to be the only person the least bit concerned about it. /~\ 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 Jan 19 13:24:57 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08581 for ; Wed, 19 Jan 2005 13:24:56 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B7AB952C1; Wed, 19 Jan 2005 18:24:53 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id 77BB65166 for ; Wed, 19 Jan 2005 18:24:51 +0000 (UTC) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2005 19:42:49 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0JINjW6011062 for ; Wed, 19 Jan 2005 19:23:46 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id SAA21886 for ietf-ssh@NetBSD.org; Wed, 19 Jan 2005 18:23:41 GMT Date: Wed, 19 Jan 2005 18:23:41 +0000 From: Derek Fawcus To: ietf-ssh@NetBSD.org Subject: Re: UTF8 Message-ID: <20050119182341.A19768@mrwint.cisco.com> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA>; from mouse@Rodents.Montreal.QC.CA on Tue, Jan 18, 2005 at 10:13:55PM -0500 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jan 18, 2005 at 10:13:55PM -0500, der Mouse wrote: > What I think we do have consensus on, even if only consensus by apathy, > is that this issue can be ignored; I appear to be the only person the > least bit concerned about it. I guess. I happen to agree with your position to a large extent, in that I use unix systems which are using 8859-1 (from my POV). But then since I happen to really only use the ASCII compatible part, if it's an octet string or UTF-8 becomes irrelevant. I don't have any characters outside the ASCII range in usernames or passwords. So it becomes academic. The only other argument would probably be that the original implementations (for unix I believe) would have been using octet strings, despite anything to the contrary in the spec. Rather than have a new message defined now, we could simply define a new error code which mean 'need octet string input'. Then on unix machines, if either the username or password contained octets with values >= 128 this error could be returned. Then in a new draft define new messages and a new error. These being the authentication forms with explicit interpretation as octet strings. The error could be used to indicate 'need utf-8 string input' in case some client way configured to start with the octet form. An alternate is simply a client -> server message meaning subsequent auth messages are octet strings. This would require client side config/choice to send on a per server basis. Mind, the approach of having configuration (at the client) to say what the server charset is, seems simpler. In which case the client would convert to the proper octet string, then just send the existing messages but treating the fields as if they were defined as octets - i.e. possible sequence which would be bad if interpreted as utf-8. DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 13:49:22 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10084 for ; Wed, 19 Jan 2005 13:49:21 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 146A95232; Wed, 19 Jan 2005 18:49:16 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by mail.netbsd.org (Postfix) with ESMTP id E17E95166 for ; Wed, 19 Jan 2005 18:49:13 +0000 (UTC) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0JIdZmt030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2005 19:39:39 +0100 From: Simon Josefsson To: Derek Fawcus Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050119:dfawcus@cisco.com::mk3PPyv2jLA2HSAz:40xU X-Hashcash: 1:21:050119:ietf-ssh@netbsd.org::uAznkbABLVlhh5xt:55GV X-Hashcash: 1:21:050119:ietf-ssh@netbsd.org::Yq/MDwNbWkRA2nT1:7c2P Date: Wed, 19 Jan 2005 19:39:23 +0100 In-Reply-To: <20050119182341.A19768@mrwint.cisco.com> (Derek Fawcus's message of "Wed, 19 Jan 2005 18:23:41 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Derek Fawcus writes: > On Tue, Jan 18, 2005 at 10:13:55PM -0500, der Mouse wrote: >> What I think we do have consensus on, even if only consensus by apathy, >> is that this issue can be ignored; I appear to be the only person the >> least bit concerned about it. > > I guess. I happen to agree with your position to a large extent, in > that I use unix systems which are using 8859-1 (from my POV). > > But then since I happen to really only use the ASCII compatible > part, if it's an octet string or UTF-8 becomes irrelevant. I don't > have any characters outside the ASCII range in usernames or > passwords. Perhaps it would be useful to consider what problems you would have interacting with EBCDIC systems, to imagine what the situation is for Latin-1 or Unicode users. ASCII isn't the only 7-bit encoding. Regards, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 16:45:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00095 for ; Wed, 19 Jan 2005 16:45:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id CAAC85400; Wed, 19 Jan 2005 21:45:13 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.netbsd.org (Postfix) with ESMTP id DB3815166 for ; Wed, 19 Jan 2005 21:45:11 +0000 (UTC) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2005 22:53:46 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0JLj5W6003662; Wed, 19 Jan 2005 22:45:06 +0100 (MET) Received: (from dfawcus@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id VAA05977; Wed, 19 Jan 2005 21:45:04 GMT Date: Wed, 19 Jan 2005 21:45:04 +0000 From: Derek Fawcus To: Simon Josefsson Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 Message-ID: <20050119214504.E19768@mrwint.cisco.com> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jas@extundo.com on Wed, Jan 19, 2005 at 07:39:23PM +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jan 19, 2005 at 07:39:23PM +0100, Simon Josefsson wrote: > > Perhaps it would be useful to consider what problems you would have > interacting with EBCDIC systems, to imagine what the situation is for > Latin-1 or Unicode users. ASCII isn't the only 7-bit encoding. That is part of the point. My local machine is using UTF-8, the Unix machines I ssh into are in 8859-1, and I do use a couple of 8 bit characters. However simply not in my username or password. Hence the local unicode characters (when UTF-8 encoded) are valid ASCII, and hence I can log in. Once logged in, I can use those 8859-1 characters (i.e. The pounds sterling symbol). You point wrt EBCDIC is valid, but I don't now the appropriate answer. Also, do their authentication systems work with a charset, or octets? DF From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 17:20:10 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02970 for ; Wed, 19 Jan 2005 17:20:10 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 6A9F25328; Wed, 19 Jan 2005 22:20:07 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 9ADCD5166 for ; Wed, 19 Jan 2005 22:20:05 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7057927; Wed, 19 Jan 2005 15:20:04 -0700 Message-ID: <41EEDC9C.3020803@vandyke.com> Date: Wed, 19 Jan 2005 15:18:04 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Fawcus Cc: Simon Josefsson , ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> In-Reply-To: <20050119214504.E19768@mrwint.cisco.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Derek Fawcus wrote: > On Wed, Jan 19, 2005 at 07:39:23PM +0100, Simon Josefsson wrote: > >>Perhaps it would be useful to consider what problems you would have >>interacting with EBCDIC systems, to imagine what the situation is for >>Latin-1 or Unicode users. ASCII isn't the only 7-bit encoding. > > > That is part of the point. My local machine is using UTF-8, the Unix > machines I ssh into are in 8859-1, and I do use a couple of 8 bit > characters. However simply not in my username or password. Hence the > local unicode characters (when UTF-8 encoded) are valid ASCII, and > hence I can log in. Once logged in, I can use those 8859-1 characters > (i.e. The pounds sterling symbol). > > You point wrt EBCDIC is valid, but I don't now the appropriate answer. > Also, do their authentication systems work with a charset, or octets? I don't know, but someone implementing a server on such a system would! And they could then convert the UTF-8 correctly to either EBCDIC if that is what is needed (one presumes that if the authentication is not charset aware the authentication devices attached to such a system a probably producing EBCDIC), or to some other charset if specified by the authentication system. See that is the thing. I don't know squat about EBCDIC, and my OS doesn't know squat about EBCDIC and can't convert to or from it. So even if the server told me, please send me EBCDIC, I just can't do it. On the other hand, such a server implementation running on an EBCDIC machine _does_ know about EBCDIC. Hence, the correct place for charset conversion is on the server. Thanks, Joseph PS. If your 8859-1 systems had a comforming SSH implementation, you would be able to use 8859-1 character in you password, which would potentially double the security of your password. A password guessor is probably going to stick to 7-bit characters; he'll get most passwords there. (And if you force him to include 8-bit characters, he has got a bigger space to cover-- not really double, but significantly larger.) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 17:44:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04663 for ; Wed, 19 Jan 2005 17:44:16 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5531E52E1; Wed, 19 Jan 2005 22:44:12 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by mail.netbsd.org (Postfix) with ESMTP id A82D15166 for ; Wed, 19 Jan 2005 22:44:09 +0000 (UTC) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0JMhvWn009729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2005 23:43:59 +0100 From: Simon Josefsson To: Derek Fawcus Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050119:dfawcus@cisco.com::bj+M5kxs/fZU+tXc:2d/x X-Hashcash: 1:21:050119:ietf-ssh@netbsd.org::X6uXyTJh+p2zQS1T:5MUw X-Hashcash: 1:21:050119:ietf-ssh@netbsd.org::m+8qrGSzOFxPDqoD:RVDi Date: Wed, 19 Jan 2005 23:43:44 +0100 In-Reply-To: <20050119214504.E19768@mrwint.cisco.com> (Derek Fawcus's message of "Wed, 19 Jan 2005 21:45:04 +0000") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv X-Virus-Scanned: ClamAV 0.80/664/Thu Jan 13 16:13:05 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Derek Fawcus writes: > On Wed, Jan 19, 2005 at 07:39:23PM +0100, Simon Josefsson wrote: >> >> Perhaps it would be useful to consider what problems you would have >> interacting with EBCDIC systems, to imagine what the situation is for >> Latin-1 or Unicode users. ASCII isn't the only 7-bit encoding. > > That is part of the point. My local machine is using UTF-8, the Unix > machines I ssh into are in 8859-1, and I do use a couple of 8 bit > characters. However simply not in my username or password. Hence the > local unicode characters (when UTF-8 encoded) are valid ASCII, and > hence I can log in. That works as expected if both systems use ASCII. I'd imagine that your username in ASCII would be equally valid in EBCDIC, but would mean something different. The fact that UTF-8 and Latin-1 are identical for ASCII is a useful property, but it may limit how you think of the problem. > You point wrt EBCDIC is valid, but I don't now the appropriate answer. > Also, do their authentication systems work with a charset, or octets? If humans entered a name of the user using a keyboard at some point in time, and the string was stored as octets, the string must have been encoded using some charset. You can't go from human symbols to octets without using some kind of charset. The only system I can recall that uses true opaque octets would be some kind of PIN or one-time-pad system that only uses digits. If the SECSH protocol uses ASCII today, the EBCDIC server would have to convert the wire charset from ASCII to EBCDIC before it can compare the string. This is similar to the UTF-8 situation under discussion: If the SECSH protocol uses UTF-8 tomorrow, the server will have to convert the wire UTF-8 data to the local charset, before it can compare it with the authentication systems. Only the server implementation can know the local charset. As far as I understand, Unix /etc/passwd only support ASCII usernames, so Unix SECSH implementations would naturally be limited to ASCII. Other authentication databases may support Unicode (or Latin-1, or EBCDIC...). I'm not sure I see the problem. Implementations that doesn't know what charset their authentication database uses, will be limited to ASCII, or whatever safe subset they can assume. Implementations that know what charset the authentication mechanism uses, can convert it as appropriate. Regards, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jan 19 19:24:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12645 for ; Wed, 19 Jan 2005 19:24:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id E172253C4; Thu, 20 Jan 2005 00:24:26 +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 E8E9D5166 for ; Thu, 20 Jan 2005 00:24:24 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA09419; Wed, 19 Jan 2005 19:24:23 -0500 (EST) From: der Mouse Message-Id: <200501200024.TAA09419@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Wed, 19 Jan 2005 19:11:57 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > As far as I understand, Unix /etc/passwd only support ASCII > usernames, I've seen this, or equivalent things, claimed before. I finally tried it, and it's not true, at least not for the Unix variant I have at ready hand (five-year-old NetBSD). I created a user whose name is 0xe5 0x67 0x65 (Latin-1 "åge" - I happen to know of someone named Åge). vipw did not complain. I set its password; passwd did not complain. "su åge" worked. "ssh localhost -l åge" worked, too, with an ssh that's ssh 1.2.14 in all username-processing respects. Sorry to go injecting fact into a good flamefst, but there you have it. At least one octet-string system - with a legacy ssh - does in fact support 8-bit usernames, at least minimally. (I'd try an ssh2 test of it, but the only ssh2 implementation I have on that system is my own, which at the moment is encoding-agnostic even on the wire, so it would prove nothing.) > I'm not sure I see the problem. Implementations that doesn't know > what charset their authentication database uses, will be limited to > ASCII, or whatever safe subset they can assume. Why? Why should one octet-string system talking to another octet-string system be unable to use non-ASCII octets? /~\ 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 Jan 20 01:46:50 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12569 for ; Thu, 20 Jan 2005 01:46:49 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id C4CED529D; Thu, 20 Jan 2005 06:46:41 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by mail.netbsd.org (Postfix) with ESMTP id 0782251DC for ; Thu, 20 Jan 2005 06:46:39 +0000 (UTC) Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0K6e1je027410 for ; Thu, 20 Jan 2005 01:40:01 -0500 (EST) Received: from dhcp89-089-076.bbn.com (dhcp89-089-076.bbn.com [128.89.89.76]) by po2.bbn.com (8.11.6+Sun/8.10.2) with SMTP id j0K6e1U11303 for ; Thu, 20 Jan 2005 01:40:01 -0500 (EST) Message-Id: <200501200640.j0K6e1U11303@po2.bbn.com> Subject: 2005 NETWORK AND DISTRIBUTED SYSTEMS SECURITY SYMPOSIUM (NDSS '05) IS FAST APPROACHING Date: Wed, 19 Jan 2005 03:51:09 -0500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" From: dannyv@bbn.com To: ietf-ssh@NetBSD.org Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: quoted-printable ------------------------------------------------------------------------ ** My apologies if you receive multiple copies of this message. ** JUST A REMINDER THAT THE INTERNET SOCIETY'S 2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05) IS FAST APPROACHING! February 2, 2005 - Pre Conference Workshop February 3-4, 2005 - Symposium Catamaran Resort Hotel, San Diego, California General Chair: Eric Harder, National Security Agency Program co-Chairs: Dan Simon, Microsoft Research Dan Boneh, Stanford University ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/ The 12th annual NDSS Symposium brings together innovative and forward thinking members of the Internet community including leading edge security researchers and implementers, globally recognized security technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on implementation) that cover new and practical approaches to security problems that are endemic to network and distributed systems. THIS YEAR'S TOPICS INCLUDE: * Cryptography in Network Security * Denial of Service Attacks * Peer to Peer Approaches * Internet Defense * Intrusion Detection * Platform Security. FEATURED GUEST SPEAKERS: * Amit Yoran, who was responsible for coordinating cyber-security activities for Homeland Security, will speak on "Security Challenges and Opportunities of the Future Enterprise" * Dr. Stefan Savage, Computer Science Dept., University of California, San Diego discusses "Internet Outbreaks: Epidemiology and Defenses PRE CONFERENCE WORKSHOP TOPICS INCLUDE: * Security in handling mobility on the internet * Security in wireless LANs * Security for telephony or voice over IP * Trust relations in ad hoc networks * Key management strategies to support mobility * Security in RFID. More information is available at: http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml =CA=CA REGISTER NOW Registration for NDSS'05 is now open. Student rates are available for both the workshop and symposium. See the web site for more information -- http://www.isoc.org/ndss05/ Registration fees: * After January 10, 2005 $695. Online registrations will be accepted until 20 January 2005. After that date, on-site registration will be available upon your arrival. HOTEL RESERVATIONS Remember to make your hotel reservations with the Catamaran Resort Hotel. https://shop.evanshotels.com/nds0130.html SPONSORSHIP OPPORTUNITIES AVAILABLE! If your organization would like to help support NDSS and gain visibility through sponsoring, please contact: sponsor-ndss@isoc.org. Information is also available at=20 http://www.isoc.org/ndss05/ Karen Seo NDSS'05 Publicity Chair From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 20 04:56:26 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11490 for ; Thu, 20 Jan 2005 04:56:25 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id B86685435; Thu, 20 Jan 2005 09:56:19 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by mail.netbsd.org (Postfix) with ESMTP id 121E9537E for ; Thu, 20 Jan 2005 09:56:16 +0000 (UTC) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0K9uA7q005573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2005 10:56:10 +0100 From: Simon Josefsson To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050120:ietf-ssh@netbsd.org::ghATibnoLkZ1IBG8:1iAq X-Hashcash: 1:21:050120:mouse@rodents.montreal.qc.ca::jx0DUg9G613HTMks:BMoK X-Hashcash: 1:21:050120:mouse@rodents.montreal.qc.ca::WXDLe7LfIKaXDfY5:5cTy X-Hashcash: 1:21:050120:ietf-ssh@netbsd.org::CUftHiXy3Zg5GeOZ:Q6qH Date: Thu, 20 Jan 2005 10:55:58 +0100 In-Reply-To: <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Wed, 19 Jan 2005 19:11:57 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv X-Virus-Scanned: ClamAV 0.80/674/Tue Jan 18 21:27:28 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit der Mouse writes: >> As far as I understand, Unix /etc/passwd only support ASCII >> usernames, > > I've seen this, or equivalent things, claimed before. I finally tried > it, and it's not true, at least not for the Unix variant I have at > ready hand (five-year-old NetBSD). I created a user whose name is 0xe5 > 0x67 0x65 (Latin-1 "åge" - I happen to know of someone named Åge). > vipw did not complain. I set its password; passwd did not complain. > "su åge" worked. "ssh localhost -l åge" worked, too, with an ssh > that's ssh 1.2.14 in all username-processing respects. That's a useful data point, thanks. >> I'm not sure I see the problem. Implementations that doesn't know >> what charset their authentication database uses, will be limited to >> ASCII, or whatever safe subset they can assume. > > Why? Why should one octet-string system talking to another > octet-string system be unable to use non-ASCII octets? You shouldn't compare octet-strings with each other unless you know which charset they were encoded in. It doesn't follow that an ASCII string that is equal to an EBCDIC string, octet-wise, mean the same thing. In your example, an SECSH implementation would appear to need to know what charset /etc/passwd is using. In your example, it would be ISO-8859-1. This could be specified through a configuration file, unless there is a system default. Then, if SECSH used UTF-8, the server would have to convert back and forth between UTF-8 and ISO-8859-1 before comparing. With this in place, your system could support Latin-1 usernames reliably. Try 'ssh -l åge remote-server' from a host using UTF-8 to realize why the octet string view is not reliable. Hope this helps, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 20 11:31:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12431 for ; Thu, 20 Jan 2005 11:31:47 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5F9A052A1; Thu, 20 Jan 2005 16:31:42 +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 3983D5176 for ; Thu, 20 Jan 2005 16:31:40 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA21895; Thu, 20 Jan 2005 11:31:39 -0500 (EST) From: der Mouse Message-Id: <200501201631.LAA21895@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Thu, 20 Jan 2005 11:09:37 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: UTF8 In-Reply-To: References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit >>> I'm not sure I see the problem. Implementations that doesn't know >>> what charset their authentication database uses, will be limited to >>> ASCII, or whatever safe subset they can assume. >> Why? Why should one octet-string system talking to another >> octet-string system be unable to use non-ASCII octets? > You shouldn't compare octet-strings with each other unless you know > which charset they were encoded in. (a) Take off your character-string blinders for a moment! Your statement is true only if both octet strings represent character strings, and it's equality of the character strings that you really care about. (b) That aside, why shouldn't one octet-string system talking to another octet-string system be unable to use non-ASCII octets? If a human tells them to do this, it's up to the human to ensure they use sufficiently compatible character sets when character sets matter. But such cases are relatively common - if both systems are encoding-agnostic, but the user has chosen to use the same character set on both, for example. > In your example, an SECSH implementation would appear to need to know > what charset /etc/passwd is using. Perhaps it appears that way to you. I see no particular need for it. (Except for conformance to the fiat of UTF-8, which since it's the point under discussion can be ignored for the moment.) > In your example, it would be ISO-8859-1. For that user, it is. Another user of the same system may be of Greek extraction and use 8859-7, with username, say, 0xec 0xe1 0xf1 0xea (mu alpha rho kappa, which I can't insert directly because this message is in 8859-1, and I'd rather not mess around with trying to create a multipart/mixed message). And what's wrong with that? There appears to be an unstated assumption lurking beneath all the character-string positions that users are incapable of making, or at least unwilling to make, adjustments and allowances for certain impedance mismatches - allowances such as Åge, when visiting Mark, realizing that to log in he has to type epsilon g e as his username. A lot of users doubtless are incompetent to do this. More are unwilling to. But I do not see those as reason to prevent the others from accepting the mismatch and doing useful things - especially since I rather suspect that using an encoding-agnostic system like a traditional Unix correlates positively and moderately strongly with such ability and willingness. /~\ 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 Jan 20 12:06:55 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15835 for ; Thu, 20 Jan 2005 12:06:54 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5416554FB; Thu, 20 Jan 2005 17:06:50 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from mail.vapor.com (boron.vapor.com [80.73.33.151]) by mail.netbsd.org (Postfix) with ESMTP id 94A125176 for ; Thu, 20 Jan 2005 17:06:48 +0000 (UTC) Received: from wall.tick-it.de (boron [127.0.0.1]) by mail.vapor.com (Postfix) with ESMTP id 9207039022E; Thu, 20 Jan 2005 17:43:44 +0100 (CET) Received: from [192.168.1.110] (unknown [192.168.1.110]) by wall.tick-it.de (Postfix) with ESMTP id 6444752753; Thu, 20 Jan 2005 17:43:44 +0100 (CET) Message-ID: <41EFE0F9.9060407@siliconcircus.com> Date: Thu, 20 Jan 2005 17:48:57 +0100 From: Jon Bright User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> 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 der Mouse wrote: > > (a) Take off your character-string blinders for a moment! Your > statement is true only if both octet strings represent character > strings, and it's equality of the character strings that you really > care about. ...which they do, for pretty much every user ever. No* user has ever said to themselves "Ah! The password field! I want to enter the octets 0xC4 0xD6 0xDC! Now, hm, I'm using ... ah, yes, I'm using ISO 8859-1. So, to enter those octets... ... ah, I'll need to enter the characters Ä, Ö and Ü to do that.". Seriously, nobody* has ever done this. What users say to themselves is, "Ah! The password field! My password is Äpfel. I'll type in Äpfel!". And they expect this to work. And they expect it to work whether they're typing in their password on Windows, using Unicode, or some *nix using 8859-1, or whatever. If they're using a system which only supports ASCII (or EBCDIC), they're not going to be able to enter Äpfel in the first place. Users don't know, don't care, shouldn't have to care and probably never will care about what octets those characters are. They care about words and the characters that make up those words. * with the possible exception of yourself, since you're campaigning so vehemently for this. If you do do this, then I'm sorry, but I'm pretty sure you're a lone voice, crying in the wilderness. Presumably, crying in octets. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 20 18:27:29 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26512 for ; Thu, 20 Jan 2005 18:27:28 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 3721F51CC; Thu, 20 Jan 2005 23:27:21 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mail.netbsd.org (Postfix) with SMTP id 261F55186 for ; Thu, 20 Jan 2005 23:27:19 +0000 (UTC) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa10942; 20 Jan 2005 18:26 EST Date: Thu, 20 Jan 2005 18:26:57 -0500 From: Jeffrey Hutzelman To: der Mouse , ietf-ssh@NetBSD.org Subject: Re: UTF8 Message-ID: <41010000.1106263617@minbar.fac.cs.cmu.edu> In-Reply-To: <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> 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 Thursday, January 20, 2005 11:09:37 -0500 der Mouse=20 wrote: > Perhaps it appears that way to you. I see no particular need for it. > (Except for conformance to the fiat of UTF-8, which since it's the > point under discussion can be ignored for the moment.) Actually, that point is _not_ up for discussion. IETF policy, as described = in RFC2277 which represents the consensus of the IETF, says exactly what we = must do with character data. I do not believe that revisiting that=20 decision is in scope for us. The current discussion centers around whether usernames and passwords as=20 seen in ssh are character strings or not. >> In your example, it would be ISO-8859-1. > > For that user, it is. Another user of the same system may be of Greek > extraction and use 8859-7, with username, say, 0xec 0xe1 0xf1 0xea (mu > alpha rho kappa, which I can't insert directly because this message is > in 8859-1, and I'd rather not mess around with trying to create a > multipart/mixed message). And what's wrong with that? Aha. I do believe that you just admitted this is a character string, and=20 you couldn't include it in your message because its character set did not=20 match that of the rest of the message. Note, incidentally, that you could=20 have resolved this problem by using UTF-8 instead of ISO-8859-1 -- MIME=20 does conform to IETF character set policy. > There appears to be an unstated assumption lurking beneath all the > character-string positions that users are incapable of making, or at > least unwilling to make, adjustments and allowances for certain > impedance mismatches - allowances such as =C5ge, when visiting Mark, > realizing that to log in he has to type epsilon g e as his username. Those assumptions are not at all unstated; I think we've made them quite=20 clear. The point of internationalization of text strings is that users=20 should not even have to think about those kinds of "allowances", let alone=20 actually make them. =C5ge should be able to use Mark's keyboard to type = =C5ge=20 (hint - I'm having no trouble typing it on my US keyboard) and have it = work. But see, here is the real problem. Suppose I have a nice, modern,=20 Unicode-using system. The one I'm sitting in front of at the moment uses=20 UTF-8 for nearly everything. Windows boxes also use Unicode. If I have a compliant ssh client, and =C5ge's home machine has a compliant=20 server, then he can type his username, which my client will encode on the=20 wire as <0xe3><0xa5><0x67><0x65>. His ssh server will then convert that to = its character set, in which it is represented as <0xe5><0x67><0x65>, and=20 he'll be able to log in. On the other hand, if my ssh client and his insist on treating this=20 character string as an "octet string" that does not require tagging or=20 conversion, then =C5ge cannot log in at all, because on my UTF-8 system he=20 _cannot_ produce the sequence <0xe5><0x67><0x65>, because that is not valid = UTF-8. Personally, I prefer the model which allows my Swedish friends to log in. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jan 20 18:43:16 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28263 for ; Thu, 20 Jan 2005 18:43:15 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id F040453CF; Thu, 20 Jan 2005 23:43:06 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by mail.netbsd.org (Postfix) with ESMTP id 9CEAB5186 for ; Thu, 20 Jan 2005 23:43:02 +0000 (UTC) Received: from latte.josefsson.org (c494102a.s-bi.bostream.se [217.215.27.65]) (authenticated bits=0) by yxa.extundo.com (8.13.2/8.13.2/Debian-1) with ESMTP id j0KNfu4H016737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jan 2005 00:42:57 +0100 From: Simon Josefsson To: der Mouse Cc: ietf-ssh@NetBSD.org Subject: Re: UTF8 References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:050120:ietf-ssh@netbsd.org::76OcWqmI2Gp8bE5b:3hOc X-Hashcash: 1:21:050120:mouse@rodents.montreal.qc.ca::RSG0DhB2Phpr8t1X:7lcZ X-Hashcash: 1:21:050120:mouse@rodents.montreal.qc.ca::D+1gJkqatfd+Dq4H:l8lq X-Hashcash: 1:21:050120:ietf-ssh@netbsd.org::2jMpiPmCSpNDF3mw:6qrN Date: Fri, 21 Jan 2005 00:41:45 +0100 In-Reply-To: <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> (der Mouse's message of "Thu, 20 Jan 2005 11:09:37 -0500 (EST)") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on yxa-iv X-Virus-Scanned: ClamAV 0.80/674/Tue Jan 18 21:27:28 2005 clamav-milter version 0.80j on yxa.extundo.com X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org Precedence: list der Mouse writes: > (b) That aside, why shouldn't one octet-string system talking to > another octet-string system be unable to use non-ASCII octets? If a > human tells them to do this, it's up to the human to ensure they use > sufficiently compatible character sets when character sets matter. But > such cases are relatively common - if both systems are > encoding-agnostic, but the user has chosen to use the same character > set on both, for example. That paragraph allowed me to understand your position. I think we fundamentally disagree. Here's my view: The point of requiring that you (and everyone else) use UTF-8 in the protocol is to make sure humans do not need to go through the hassles of ensuring they use compatible charsets. Few people understand these matters to make an informed choice. Further, this is an error prone topic, so it is not reliable to rely on humans to perform the task. I believe most users expect things to work. In this case, things can't work unless the entire world is using the same charset (not going to happen), or the protocols use charset-labeled fields and different systems convert as appropriate. Or, as you would prefer, users handle charset conversion by themselves. I'm not sure you realize the importance of the problem -- non-ASCII username and passwords is not a "nice thing". It is not something that you will rarely see in practice, so that educating those special users about how to convert between charsets themselves is an option. For the majority of potential users, it is critical that they can use symbols they are familiar with. Only a small part of the world uses languages that are written in the ASCII alphabet. You might want to read RFC 2277, it discuss these matters more eloquently than I can hope to do. Hope this helps, Simon From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 21 06:19:19 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29523 for ; Fri, 21 Jan 2005 06:19:18 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 37CF454DA; Fri, 21 Jan 2005 11:19:09 +0000 (UTC) X-Original-To: ietf-ssh@NetBSD.org Delivered-To: ietf-ssh@NetBSD.org Received: from citadel.cequrux.com (citadel.cequrux.com [192.96.22.18]) by mail.netbsd.org (Postfix) with ESMTP id A78AF5182 for ; Fri, 21 Jan 2005 11:19:06 +0000 (UTC) Received: (from nobody@localhost) by citadel.cequrux.com (8.12.11/8.12.11) id j0LBJ4EM005588 for ; Fri, 21 Jan 2005 13:19:04 +0200 (SAST) (envelope-from apb@cequrux.com) Received: by citadel.cequrux.com via recvmail id 5586; Fri, 21 Jan 2005 13:19:04 +0200 (SAST) Date: Fri, 21 Jan 2005 13:19:02 +0200 From: Alan Barrett To: ietf-ssh@NetBSD.org Subject: Re: UTF8 Message-ID: <20050121111902.GI2105@apb-laptoy.apb.alt.za> References: <00b001c4fd8e$be4b8460$d7b7fea9@nucleus> <159240000.1106095214@minbar.fac.cs.cmu.edu> <200501190558.AAA05868@Sparkle.Rodents.Montreal.QC.CA> <20050119182341.A19768@mrwint.cisco.com> <20050119214504.E19768@mrwint.cisco.com> <200501200024.TAA09419@Sparkle.Rodents.Montreal.QC.CA> <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501201631.LAA21895@Sparkle.Rodents.Montreal.QC.CA> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 20 Jan 2005, der Mouse wrote: > For that user, it is. Another user of the same system may be of Greek > extraction and use 8859-7, with username, say, 0xec 0xe1 0xf1 0xea (mu > alpha rho kappa, which I can't insert directly because this message is > in 8859-1, and I'd rather not mess around with trying to create a > multipart/mixed message). And what's wrong with that? Even if the underlying operating system thinks that the user name is OCTET_SEQUENCE(0xec, 0xe1, 0xf1, 0xea), the user probably thinks that the user name is CHARACTER_STRING(, , , ). and perhaps the sysadmin thinks that the user name is ENCODE_USING_CHARSET(iso-8859-7, CHARACTER_STRING(...)). I see no reason why the ssh server implementation could not have a set of rules or a database to tell it things like "The user whose username is really OCTET_SEQUENCE(x) likes to think that his user name is CHARACTER_STRING(y)", or "All users on this system like to think that their usernames are character strings encoded in CHARSET(z)". Then, when CHARACTER_STRING(y) arrives in the relevant ssh protocol field, the server could map it to the correct OCTET_SEQUENCE(x). Users who really do think of their user names as octet sequences can be handled by having an rule to say "The user whose username is really OCTET_SEQUENCE(0x01, 0x02) will login via ssh using the name CHARACTER_STRING(, , , , , )". So, the fact that the ssh protocol wants to use a character string does not appear to prevent an implementation that wants to use an octet sequence. --apb (Alan Barrett) From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 24 11:00:39 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24547 for ; Mon, 24 Jan 2005 11:00:39 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0C69F5584; Mon, 24 Jan 2005 16:00:15 +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 94B95534E for ; Mon, 24 Jan 2005 16:00:13 +0000 (UTC) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Jan 2005 08:05:47 -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 j0OFxYl2013216 for ; Mon, 24 Jan 2005 07:59:35 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA03731 for ; Mon, 24 Jan 2005 08:00:07 -0800 (PST) Date: Mon, 24 Jan 2005 08:00:07 -0800 (PST) From: Chris Lonvick To: ietf-ssh@NetBSD.org Subject: Re: timing of banner In-Reply-To: <000201c4fdd4$1db37210$d7b7fea9@nucleus> Message-ID: References: <000201c4fdd4$1db37210$d7b7fea9@nucleus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list Hi, I didn't see any further discussion on this. Unless anyone objects, I'll replace the current text with the "short and sufficient" version. Thanks, Chris On Wed, 19 Jan 2005, denis bider wrote: > In [SSH-USERAUTH], I suggest the following clarification: > > Now: > > The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time > before authentication is successful. > > Suggested (short and sufficient): > > The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time > after this authentication protocol starts and before authentication is > successful. > > Alternative (longer and more informative): > > The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time > before authentication is successful. Note however that, like other message > types defined in this document, this message is part of the authentication > protocol, so it also MUST NOT be sent before the authentication protocol is > requested. > > Rationale: > > From the current wording, superficial implementors, which more frequently > than not fail to differentiate between SSH protocol layers, may conclude > that it is OK to send the BANNER message even before the service request for > "ssh-userauth" has been received. My clarification aims to prevent this > misinterpretation and to affirm that, since the BANNER message is part of > the ssh-userauth protocol, it is incorrect to send it before the > ssh-userauth layer is started. This helps implementors which implement SSH > layers separately, thus encountering difficulties when boundaries between > layers are incorrectly breached. > > denis > From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jan 25 04:18:02 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12733 for ; Tue, 25 Jan 2005 04:18:01 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 5839354A1; Tue, 25 Jan 2005 09:17:56 +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 C69CC538D for ; Tue, 25 Jan 2005 09:17:54 +0000 (UTC) Received: from marketmailer ([24.203.74.176]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IAV00KUY5VTPX@VL-MO-MR010.ip.videotron.ca> for ietf-ssh@netbsd.org; Tue, 25 Jan 2005 03:21:32 -0500 (EST) Date: Tue, 25 Jan 2005 03:21:12 -0500 From: Team NC Offshore Subject: RE: Nagra2 Very Private Dishnet Details Here P4/P5 Soon To: Nagra Coders Message-id: <3846-22005122582112381@marketmailer> Organization: Team NC Offshore 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 Subject: RE: Nagra2 Dishnet Private Support Details Attention Respected Satellite Tester: http://www.nagracode.com/ We are contacting you today to let you know about a very important and revolutionary breakthrough that has recently evolved in the satellite testing community. What is it, you ask? Two words: Nagra Code. They are the industry's leading private software coding group, and are NOW the FIRST cracking group to offer full-out NAGRA2 scripts! In addition, also includes FTA support and more. http://www.nagracode.com/ As the anticipation arises we know the main question of when the DTV Hack will come out.From our respective sources we can tell you the time is VERY VERY near.We encourage you because anyone that purchases our support now will automaticaly be granted the DTV access in the next MONTH to come.Get ready as we are proud to announce that between February 10th and March 1st 2005 we are back up and running.Take advantage NOW of our super Nagracode combo 1 price deal.More details found at http://www.nagracode.com/ They are completely offshore owned and operated, so you can be sure to stay safe. They offer top-notch 24/7 customer and technical support via several means, and also have a 30-day moneyback guarantee. Even better, buy within the next twenty-four hours and get free P4 support when available. If you want the best, then visit NAGRACODE today, and get your discounted pricing for a limited time only. Visit them now at: http://www.nagracode.com/ Regards, Team NC rhtj dhg u From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jan 28 23:02:47 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20024 for ; Fri, 28 Jan 2005 23:02:46 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 2EADE5985; Sat, 29 Jan 2005 04:02:39 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mail.netbsd.org (Postfix) with ESMTP id EE5855164 for ; Sat, 29 Jan 2005 04:02:36 +0000 (UTC) Received: from dodgynet.dyndns.org (203-206-246-110.dyn.iinet.net.au [203.206.246.110]) (authenticated bits=0) by mailout1.pacific.net.au (8.12.3/8.12.3/Debian-7.1) with ESMTP id j0T3wdA6017654 for ; Sat, 29 Jan 2005 14:58:40 +1100 Received: from [127.0.0.1] (gate.dodgy.net.au [192.168.32.1]) by dodgynet.dyndns.org (8.12.8/8.12.8) with ESMTP id j0T3wcqp030217 for ; Sat, 29 Jan 2005 14:58:39 +1100 Message-ID: <41FA6F3D.2040501@zip.com.au> Date: Sat, 29 Jan 2005 03:58:37 +1100 From: Darren Tucker User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: tcpip-forward requests and bind addresses 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 Hi all. Section 7.1 in draft-ietf-secsh-connect-23.txt is unclear on several aspects of specifying bind addresses in port forwarding requests. It says: [quote] byte SSH_MSG_GLOBAL_REQUEST string "tcpip-forward" boolean want reply string address to bind (e.g., "0.0.0.0") uint32 port number to bind The 'address to bind' and 'port number to bind' specify the IP address and port to which the socket to be listened is bound. The address should be "0.0.0.0" if connections are allowed from anywhere. (Note that the client can still filter connections based on information passed in the open request.) [/quote] The things that aren't clear: - how to listen on all IPv4 and IPv6 interfaces. - how to listen on localhost only on IPv4 and IPv6 Working with Damien Miller, we've come up with the following suggestions. After some digging, it turns out we're (belatedly) seconding suggestions made by Niels Möller[1] in 2001! (1) the string "" should specify that connections are allowed from anywhere rationale: since we're not specifying an address, logically it could mean "any address is acceptable" or "no address is acceptable". The latter case is handled by not sending a tcpip-forward at all, so the former should be the obvious meaning. (2) "address to bind" should permit either a domain name or address rationale: direct-tcpip permits this, and the server may have better information about its addresses (eg "servername-hme0" to listen on that interface on both IPv4 and IPv4). The client still has the option of doing a lookup locally and/or sending an address instead. (3) the string "localhost" should have a special meaning to the server of "all loopback IPv4 and IPv6 interfaces". rationale: a properly configured host should get this anyway from its name resolver. Making it a special case removes a dependancy on the name service that could potentially be used to compromise forwarded connections. An older client talking to a newer server will still be fully compatible with these; a newer client talking to an older server potentially may not, however this may be trivally overcome by configuration, eg manually specifying "0.0.0.0" as a listen address instead of (1). With those in mind, I'd like to suggest the following text to replace the first paragraph in section 7.1: [proposed text] The 'address to bind' and 'port number to bind' specify the IP address or domain name and port to which the socket to be listened is bound. The address should be "" if connections are to accepted from anywhere on all supported protocol families. The server SHOULD treat an address of "localhost" to be a special case meaning to listen on all supported protocol families on its loopback interfaces only. The strings "0.0.0.0" and "::" should be used to listen on all interfaces on only IPv4 or IPv6 respectively. Similarly, strings of "127.0.0.1" or "::1" should be used to listen on the loopback interface. Note that the client can still filter connections based on information passed in the open request. [/proposed text] Thanks and regards, -Darren Tucker. [1] http://article.gmane.org/gmane.ietf.secsh/2299 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 31 19:15:06 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27191 for ; Mon, 31 Jan 2005 19:15:06 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 0891953EC; Tue, 1 Feb 2005 00:15:00 +0000 (UTC) X-Original-To: ietf-ssh@netbsd.org Delivered-To: ietf-ssh@netbsd.org Received: from vandyke.com (mail.vandyke.com [204.134.9.1]) by mail.netbsd.org (Postfix) with ESMTP id 677035182 for ; Tue, 1 Feb 2005 00:14:58 +0000 (UTC) Received: from [127.0.0.1] (HELO [127.0.0.3]) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 7088201 for ietf-ssh@netbsd.org; Mon, 31 Jan 2005 17:14:57 -0700 Message-ID: <41FECA00.3040504@vandyke.com> Date: Mon, 31 Jan 2005 17:14:56 -0700 From: Joseph Galbraith User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Connectathon... X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I just wanted to give a brief plug for Connectathon: http://www.connectathon.org/ Several of the major SSH vendors attend this event, and it is an excellent chance to flush out interop bugs-- it is a chance to work directly with the developers that are writing the bugs :-) So I would highly recommend attending if you have the chance. I know that VanDyke has found it a very productive event each of the years we've attended. Thanks, Joseph From bounces-ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jan 31 23:32:04 2005 Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18520 for ; Mon, 31 Jan 2005 23:32:03 -0500 (EST) Received: by mail.netbsd.org (Postfix, from userid 0) id 991A652DB; Tue, 1 Feb 2005 04:31:58 +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 D8EAD5182 for ; Tue, 1 Feb 2005 04:31:56 +0000 (UTC) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA02069; Mon, 31 Jan 2005 23:31:52 -0500 (EST) From: der Mouse Message-Id: <200502010431.XAA02069@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. X-Message-Flag: Microsoft: the company who gave us the zombie armies. Date: Mon, 31 Jan 2005 23:24:22 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Connectathon... In-Reply-To: <41FECA00.3040504@vandyke.com> References: <41FECA00.3040504@vandyke.com> Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit > I just wanted to give a brief plug for Connectathon: > http://www.connectathon.org/ Over *two* **thousand** dollars, for the minimum table?! Sorry. I'd love to do interop testing (anyone interested?). But I definitely won't pay outrageous amounts of money to do so. /~\ 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