RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006

Source of RFC: secsh (sec)

Errata ID: 1678
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Frank Cusack
Date Reported: 2009-02-03
Verifier Name: Pasi Eronen
Date Verified: 2009-02-16

Section 3.2 says:

   The language tag is deprecated and SHOULD be the empty string.  It
   may be removed in a future revision of this specification.  Instead,
   the server SHOULD select the language used based on the tags
   communicated during key exchange [SSH-TRANS].

   If the language tag is not the empty string, the server SHOULD use
   the specified language for any messages sent to the client as part of
   this protocol.  The language tag SHOULD NOT be used for language
   selection for messages outside of this protocol.  If the server does
   not support the requested language, the language to be used is
   implementation-dependent.

It should say:

   The language tag MAY be the empty string.  If acceptable/preferable
   languages were communicated during key exchange [SSH-TRANS], or in
   the SSH_MSG_USERAUTH_REQUEST message, the language tag SHOULD be the
   language selected by the server for the SSH_MSG_USERAUTH_INFO_REQUEST
   message.

Notes:

As originally pointed out by Alfred Hoenes (errata ID 758), this text
was incorrectly copy-pasted from Section 3.1.

The Information Request is sent from the server to the client, and it
already contains strings that make use of the particular
language/locale. The language tag in this message specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request. This parallels the use of the language tag
in, e.g., the Disconnection Message of the SSH Transport Layer
Protocol.

Errata ID: 4746
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Gabriele Bonacini
Date Reported: 2016-07-25
Verifier Name: Paul Wouters
Date Verified: 2023-07-28

Throughout the document, when it says:

section 3.2, page 4:

int       num-prompts

section 3.4, page 6:

int       num-responses

section 3.4.4

page 7:
S:   int       1
...
C:   int       1

page 8:

S:   int       1
...
C:   int       1
...
S:   int       2
...
C:   int       2
...
S:   int       0

page 9:

S:   int       0

It should say:

section 3.2, page 4:

uint32       num-prompts

section 3.4, page 6:

uint32       num-responses

section 3.4.4

page 7:
S:   uint32       1
...
C:   uint32       1

page 8:

S:   uint32       1
...
C:   uint32       1
...
S:   uint32       2
...
C:   uint32       2
...
S:   uint32       0

page 9:

S:   uint32       0

Notes:

The type "int" is not present between the list of types present in the RFC 4251, section 5 ( "Data Type Representations Used in the SSH Protocols" ) . Alone it's confusing and meaningless.

Status: Rejected (1)

RFC 4256, "Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)", January 2006

Source of RFC: secsh (sec)

Errata ID: 758
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Pasi Eronen
Date Rejected: 2009-02-16

Section 3.2 says:

"Information Requests", on page 5, RFC 4256 says:

   The language tag is deprecated and SHOULD be the empty string.  It
   may be removed in a future revision of this specification.  Instead,
   the server SHOULD select the language used based on the tags
   communicated during key exchange [SSH-TRANS].

   If the language tag is not the empty string, the server SHOULD use
   the specified language for any messages sent to the client as part of
   this protocol.  The language tag SHOULD NOT be used for language
   selection for messages outside of this protocol.  If the server does
   not support the requested language, the language to be used is
   implementation-dependent.

It should say:

[see Notes]

Notes:

[Replace by errata ID 1678]

(These two paragraphs apparently have been copied from Section 3.1
without change.)

This specification makes no sense here:

The Information Request is sent from the *server* to the client,
and it already contains strings that *do* make use of a particular
language/locale.

The one and only useful interpretation of the 'language tag'
in the Information Request message is that it specifies the
language/locale used for building the 'instruction' and 'prompt'
strings in the request.
This parallels the use of the language tag, e.g., in the
Disconnection Message of the SSH Transport Layer Protocol
(cf. RFC 4253, Sect. 11.1).

NOTE: The client might have announced a locale *list* in the
initial exchange, and the server should choose from that list;
the actual choice [for a particular message with text strings]
needs to be communicated to the client.

NOTE: In multi-stage authentication, the backend authentication
mechanisms will be the source of all these strings, and the SSH
server might have no choice than to just report the locale used
by each backend mechanism to the client; such mechanisms easily
could make use of different locales - hence the locale needs to
be announced per message from the server in this context!

NOTE: RFC 4253 recommends to send empty language tags fields in
the initial exchange; this makes the 'language tag' field in all
SSH protocol messages containing text to be presented to the user
*very* desirable !

Therefore, the 'language tag' should also better *not* be deprecated
in the SSH_MSG_USERAUTH_INFO_REQUEST message!

from pending
--VERIFIER NOTES--
[Replaced by errata ID 1678]

Report New Errata



Advanced Search