[Gen-art] Re: Gen-ART review of: draft-ietf-secsh-gsskeyex-10.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 29 August 2005 22:46 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sOW-0000Pj-8l; Mon, 29 Aug 2005 18:46:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9p4n-0006fQ-UH for gen-art@megatron.ietf.org; Mon, 29 Aug 2005 15:13:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29667 for <gen-art@ietf.org>; Mon, 29 Aug 2005 15:13:48 -0400 (EDT)
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9p6B-0001wu-E8 for gen-art@ietf.org; Mon, 29 Aug 2005 15:15:16 -0400
Received: from SIRIUS.FAC.CS.CMU.EDU ([128.2.209.170]) by minbar.fac.cs.cmu.edu id aa13107; 29 Aug 2005 15:12 EDT
Date: Mon, 29 Aug 2005 15:12:44 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Sam Hartman <hartmans-ietf@mit.edu>, Bill Sommerfeld <sommerfeld@sun.com>
Message-ID: <B9EBFB08B7679865D509E5FC@sirius.fac.cs.cmu.edu>
In-Reply-To: <tslzmr0eha4.fsf@cz.mit.edu>
References: <F222151D3323874393F83102D614E055082633@CORPUSMX20A.corp.emc.com> <1125338383.453.29.camel@thunk> <tslzmr0eha4.fsf@cz.mit.edu>
Originator-Info: login-token=Mulberry:01sKgfrxoQlCP885cw4yZPHkcaVto33JgdHU0U5ig=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 29 Aug 2005 18:46:23 -0400
Cc: galb@vandyke.com, gen-art@ietf.org, jsalowey@cisco.com, Black_David@emc.com, welch@mcs.anl.gov
Subject: [Gen-art] Re: Gen-ART review of: draft-ietf-secsh-gsskeyex-10.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org


On Monday, August 29, 2005 02:20:51 PM -0400 Sam Hartman 
<hartmans-ietf@mit.edu> wrote:

>>>>>> "Bill" == Bill Sommerfeld <sommerfeld@sun.com> writes:
>
>     Bill> On Sat, 2005-08-27 at 22:52, Black_David@emc.com wrote:
>     >> I found one nit that needs attention.  Section 3.2 of the draft
>     >> uses UTF-8 for a "user name" string but doesn't say what the
>     >> applicable Unicode character usage and normalization
>     >> (stringprep) requirements are.  I believe that this problem is
>     >> already addressed via use of the SASL stringprep profile in the
>     >> SSH-USERAUTH draft, so a sentence pointing out the (obvious)
>     >> fact that "user name" is an SSH user name, and hence is subject
>     >> to the SSH-USERAUTH draft's requirements on SSH user names,
>     >> including appropriate use of stringprep should suffice.
>
>     Bill> This has been a matter of substantial discussion both in
>     Bill> secure shell and in sasl.
>
>     Bill> I may be partly mangling fine details of the consensus
>     Bill> result, but after sasl came up with a stringprep,
>     Bill> significant concerns surfaced which led to a revised
>     Bill> approach: username stringprep really belongs on the ssh
>     Bill> server side, which makes it purely a local matter between
>     Bill> the server and whatever user account database is consulted
>     Bill> by the server.
>
>     Bill> The client prepares the username in UTF-8 format without
>     Bill> need for any normalization.  The server (which is a client
>     Bill> of the notional user account database) applies the
>     Bill> stringprep or other canonicalization required to match the
>     Bill> encoding conventions of that database.
>
> Well, mostly.  We recommend to server implementers that they do
> stringprep and normalization and if they have no better profile to
> use, use saslprep.

The userauth document doesn't recommend such behavior for the general case. 
It recommends them specifically with respect to the username/password 
database that the "password" userauth method is assumed to consult.  The 
userauth document defines 4 different userauth methods (publickey, 
password, hostbased, none), and the text regarding string preparation 
applies only to one of them.

The presence of the UTF-8-encoded username in a SSH_MSG_USERAUTH_REQUEST is 
part of the ssh protocol, and is not unique to any particular method. 
While I do believe it would be appropriate for a userauth method to apply 
further constraints to usernames if needed by the method, I don't think any 
are needed for the GSSAPI userauth methods.


Of course, I'd be happy to include a reference to whatever the userauth 
document said about handling usernames in the general case, but in fact it 
doesn't say anything at all.

So, I'm not sure how to resolve David's issue.

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art