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

From: [email-masked]
Date: Sat, 27 Aug 2005 22:52:53 -0400

Background for those who may be unaware of GenART:

GenART is the Area Review Team for the General Area of the IETF.
We advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are included.

Review criteria for WG submissions: "Is this document a reasonable
contribution to the area of Internet engineering which it covers? If
not, what changes would make it so?"

This draft is basically ready for publication, but has nits that
should be fixed before publication.

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.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2005 14:20:51 -0400

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> On Sat, 2005-08-27 at 22:52, [email-masked] 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.

I think copying the text from the userauth draft would be reasonable.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2005 15:19:57 -0400

I think the username part of the password text may be generally
applicable.  I'd be happy to copy that text.

I'd also be happy to argue with Brian that this should not be a
discuss comment.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 15:12:44 -0400

> stringprep and normalization and if they have no better profile to

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 15:48:15 -0400

> applicable.  I'd be happy to copy that text.

Maybe, in which case we probably should have said something more about it 
in userauth.  But that ship has sailed, I believe.

My main concern is that we not encourage ssh server implementations to 
normalize usernames passed to the OS in a way that is incompatible with how 
the OS treats usernames.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Aug 2005 13:59:44 -0400

> names, including appropriate use of stringprep should suffice.

This has been a matter of substantial discussion both in secure shell
and in sasl.

I may be partly mangling fine details of the consensus result, but after
sasl came up with a stringprep, significant concerns surfaced which led
to a revised approach: username stringprep really belongs on the ssh
server side, which makes it purely a local matter between the server and
whatever user account database is consulted by the server.

The client prepares the username in UTF-8 format without need for any
normalization.  The server (which is a client of the notional user
account database) applies the stringprep or other canonicalization
required to match the encoding conventions of that database.

							- Bill