Ambiguities in section 3.1 of the keyboard-interactive draft

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

This draft currently contains ambiguities that make it more or less impossible
to create interoperable implementations:

  The submethods field is included so the user can give a hint of which actual
  methods he wants to use.  It is a comma-separated list of authentication
  submethods (software or hardware) which the user prefers.  If the client has
  knowledge of the submethods preferred by the user, presumably through a
  configuration setting, it MAY use the submethods field to pass this
  information to the server.  Otherwise it MUST send the empty string.

  The actual names of the submethods is something which the user and the
  server need to agree upon.

  Server interpretation of the submethods field is implementation-dependent.

So there's a pile of undefined methods that are handled in an implementation-
dependent manner.  Let's say the client wants to use the standard lowest-
common-denominator password authentication.  So it sends the submethod
"password" to let the server know this.  This is compliant with both the
apparent intent of the spec ("password" is the submethod "preferred by the
user"), and the wording, which really allows more or less any sort of
behaviour.  The server sees this submethod, decides that it doesn't like it,
and immediately sends back a SSH_MSG_USERAUTH_FAILURE (it could also
execl("/usr/games/hack", "submethods", 0) as its implementation-dependent
interpretation, I guess).

Both of these interpretations are fully compliant with the spec, but they
result in non-interoperable implementations.

As I see it, the intent is that the client provide a hint to the server as to
which method(s) it'd prefer to use.  In this case the server behaviour (the
second two paragraphs above) should be specified as:

  The names of the submethods are client- and server-dependant.  If the server
  encounters an unrecognised submethod, it MUST ignore that submethod.
  Otherwise, it MUST process the submethods in the order specified by the
  client.  In other words if the client specifies submethods
  "method1,unknown,method2" the server should first try method1, skip the
  unknown method, and then try method2.

This avoids the problem given in the earlier example, and nails down the exact
behaviour of client and server during the exchange.

Peter.