Re: Open Issues from Recent Comments

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> 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