Subject: I-D ACTION:draft-ietf-secsh-userauth-22.txt

From: [email-masked]
Date: Thu, 28 Oct 2004 11:07:17 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Authentication Protocol
	Author(s)	: T. Ylonen, C. Lonvick
	Filename	: draft-ietf-secsh-userauth-22.txt
	Pages		: 16
	Date		: 2004-10-27
	
SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  This document describes the SSH
   authentication protocol framework and public key, password, and
   host-based client authentication methods.  Additional authentication
   methods are described in separate documents.  The SSH authentication
   protocol runs on top of the SSH transport layer protocol and provides
   a single authenticated tunnel for the SSH connection protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-22.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-userauth-22.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-userauth-22.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: der Mouse <[email-masked]>
Date: Thu, 28 Oct 2004 12:33:22 -0400 (EDT)

Good to see all the new drafts.

In architecture-17, I see new text

	It should be noted that these names resemble [RFC0822] email
	addresses.  This is purely coincidental and actually has
	nothing to do with [RFC0822].

RFC 822 is long obsolete; shouldn't that refer to 2822?  (Similar
remarks apply to assignednumbers-07 4.6.1.)

I also see

	(commonly known as the Rogaway attack
	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,

s/,)/)/ surely?

In assignednumbers-07, 4.2.3, what about reason codes from ffffffea
through ffffffef?  Similar remarks apply to 4.3.3 and 4.4.3.

userauth-22 contains (in the description of password authentication)
more character set issues, similar to those raised by the recent
discussion of filenames.  Built into this text is the assumption that a
password is a sequence of characters; on most systems, it is actually a
sequence of octets, with any conversion between them and characters
left undefined.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 28 Oct 2004 19:45:23 -0400

> remarks apply to assignednumbers-07 4.6.1.)

Actually, RFC822 is not "obsolete"; it is an Internet Standard.

It is entirely appropriate to refer to "RFC822 addresses", especially in a 
context like this where the reference is informative.

> 	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,

And s/][/],[/

> sequence of octets, with any conversion between them and characters

Sorry; that's just not true.  It wasn't true of filenames and it's not true 
of passwords, either.

Kerberos treats passwords as character strings.
Windows treats passwords as character strings.
SASL treats passwords as character strings.
MacOS X treats passwords as character strings.
In fact, if you look, you can probably find a number of situations in which 
various UNIX systems treat passwords as character strings and not octet 
strings.  Consider xdm.  Consider the behaviour of 'passwd' with a UTF-8 
locale.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 28 Oct 2004 18:50:30 -0700 (PDT)

Hi,

> Good to see all the new drafts.

Sorry for the delay.  I'll pick up the pace.

> remarks apply to assignednumbers-07 4.6.1.)

I was going from the IESG comments and the brief discussion we had on the
mailing list.  Does anyone disagree that we should be referencing RFC
2822?

> 	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,

I just put that in there to see who was reading the drafts.  ;)
..just kidding.  Good catch, I'll fix that.

> through ffffffef?  Similar remarks apply to 4.3.3 and 4.4.3.

My apologies for that.  I was distracted by a side issue during the last
few weeks and hadn't realized that I had not completed my edits for that
issue.  The ranges are inconsistent throughout the documents and I will
correct that when the ID Editors start accepting new documents again.

Just to summarize the discussion, I am planning on the following:

=====
For SSH_MSG_CHANNEL_OPEN_FAILURE we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFEFF FFFF        PRIVATE USE - channel-type specific
0xFF00 0000 - 0xFFFF FFFF        PRIVATE USE - (experimental stuff)

with accompanying notes about

- The range starting with 0xFE should be used when localized names are
used for opening a channel (e.g. SSH_MSG_CHANNEL_OPEN message with a
'channel type' of "[email-masked]").  Interoperability is
assumed by a "gentleman's agreement" that IF you accept the localized
channel open type THEN you will understand the failure 'reason code'
values associated with that localized name.  Also, the IANA assigned
'reason code' values are still valid even when opening a channel using a
localized name.

- No restrictions or suggestions for the range starting with 0xFF.  No
interoperability is expected for anything used here - it's for
experimentation.

=====
For SSH_MSG_DISCONNECT we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFFFF FFFF        PRIVATE USE

=====
For SSH_MSG_CHANNEL_EXTENDED_DATA we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFFFF FFFF        PRIVATE USE
=====

> discussion of filenames.

Was that the discussion with the subject line of "SFTP and unicode file
names..."?  I wasn't paying close attention to that.

> Built into this text is the assumption that a

Is that this paragraph:

   Note that the 'plaintext password' value is encoded in ISO-10646
   UTF-8.  It is up to the server how it interprets the password and
   validates it against the password database.  However, if the client
   reads the password in some other encoding (e.g., ISO 8859-1 - ISO
   Latin1), it MUST convert the password to ISO-10646 UTF-8 before
   transmitting, and the server MUST convert the password to the
   encoding used on that system for passwords.

If so, would anyone care to propose text as to how it can address this
issue?

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 28 Oct 2004 19:14:38 -0700 (PDT)

Hi,

> context like this where the reference is informative.

OK, I should'a looked before my prior response.  STD-11 still points to
RFC-822.  However, RFC-822 has been "Obsoleted by RFC-2822" and "Updated
by RFC1123, RFC1138, RFC1148, RFC1327, RFC2156".  Nonetheless, it's
usually more appropriate to go with a STD so I'll keep the reference
pointing to RFC-822.

> > 	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,

I used White Out.

> strings.  Consider xdm.  Consider the behaviour of 'passwd' with a UTF-8

OK.  No changes planned unless we get some consensus.

Thanks,
Chris

---

From: der Mouse <[email-masked]>
Date: Thu, 28 Oct 2004 22:03:52 -0400 (EDT)

[Jeffrey Hutzelman <[email-masked]>, replying to me]
>> RFC 822 is long obsolete; shouldn't that refer to 2822?

The RFC index I fetched on 2004-10-19 says

0822 Standard for the format of ARPA Internet text messages. D.
     Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733)
     (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148,
     RFC1327, RFC2156) (Also STD0011) (Status: STANDARD)

I'm not sure what other construction to put on that "Obsolete by" bit.

> It is entirely appropriate to refer to "RFC822 addresses", especially
> in a context like this where the reference is informative.

Perhaps, but to reference 822 rather than 2822 for them?

>> 	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,

Actually, I find I cut-and-pasted from the old version of that text
rather than the new - both have the ,) problem, but the new text
doesn't have the ][ problem.

>> Built into [userauth-22] is the assumption that a password is a
>> sequence of characters; on most systems, it is actually a sequence
>> of octets, with any conversion between them and characters left
>> undefined.
> Sorry; that's just not true.

It's true on every system I've ever used enough to know how passwords
work on it - which admittedly is restricted to Unix variants.

> In fact, if you look, you can probably find a number of situations in
> which various UNIX systems treat passwords as character strings and
> not octet strings.  Consider xdm.

xdm login windows treat passwords as character strings, yes - but it's
the octet sequences behind them that matter: the password is actually
the octet sequence, not the character sequence. If you set your
password to "rÃë" using 8859-1 (ie, 0x72 0xc3 0xeb), I believe you'll
find you can log in just fine to an xdm login window using 8859-7 by
typing a password consisting of characters two of which I can't display
here in 8859-1: r, capital gamma, lowercase lambda.  (I phrase it that
way because I can't try it; I can't tell how to set the locale for an
arbitrary program, and my xdm (R6.4) doesn't seem to have any explicit
options for it.)  If the password truly were the sequence of characters
rather than the sequence of octets, that wouldn't work.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Thu, 28 Oct 2004 23:09:57 -0400 (EDT)

> I [...] hadn't realized that I had not completed my edits [...]

Good.  I thought it was odd to entirely omit six of the 2^32 possible
values; I also thought it didn't look much like the consensus I
remembered from the list.  Your description of what you're planning
looks much better on both counts. :)

> Was that the discussion with the subject line of "SFTP and unicode
> file names..."?  I wasn't paying close attention to that.

I think that was it.

>    UTF-8.  It is up to the server how it interprets [...]

Yes.

> If so, would anyone care to propose text as to how it can address
> this issue?

I don't have a good fix.  Basically, the problem is that passwords (or
filenames, for the sftp issue) are, on some systems, octet sequences,
with conversion between them and character sequences happening only
when they need to be displayed or typed; whereas, on others, they are
character sequences, with octet sequences involved only because of the
need to store some representation of those character sequences.  From
the one point of view, character set conversion in the protocol is
complete nonsense; from the other, it's reasonable even to the point of
being necessary.  Short of providing a character set tag field for
which some distinguished value means "this is actually an octet
sequence", I see no way to handle both with the same protocol.

For example, on the system I'm using right now, passwords and filenames
_are_ fundamentally octet sequences rather than character sequences.
Given the edict

>    However, if the client reads the password in some other encoding
>    (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to
>    ISO-10646 UTF-8 before transmitting,

then what should I do upon reading a password?  I _don't know_, and in
many cases finding out is not just difficult but impossible, what
character set is being used for display; what characters the user is
thinking of those octets, or the keystrokes behind them (if any), as
corresponding to is even more difficult to determine.

>    and the server MUST convert the password to the encoding used on
>    that system for passwords.

This appears to say that in order to implement password authentication
in my server, I have to redesign and reimplement how passwords are
handled and stored to make them character sequences rather than octet
sequences.  Is that really what we want the drafts to require?  I for
one would much rather simply not implement password authentication.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign