Subject: Re: Ambiguities in section 3.1 of the keyboard-interactive draft

From: Martin Forssen <[email-masked]>
Date: Wed, 29 Sep 2004 08:46:38 +0200 (CEST)

On 29 Sep, Peter Gutmann wrote:
> 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.

I have no problem with this.

	/MaF
-- 
Martin Forssen <[email-masked]>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB

---

From: Martin Forssen <[email-masked]>
Date: Wed, 29 Sep 2004 08:55:38 +0200 (CEST)

On 28 Sep, Niels Möller wrote:
> I don't think the given examples support this authentication method.
> One-time passwords are easily supported using plain "password"
> authentication. Some forms of challenge response authentication can
> also be done by combining using "password" authentication and
> USERAUTH_BANNER.

No, while implementing challenge-response with passwd auth and banners
is doable from a protocol point of view it makes the user interface
horrible. At least for a graphical client. 

> Section 3.2, Information Requests
>       
>       byte      SSH_MSG_USERAUTH_INFO_REQUEST
>       string    name (ISO-10646 UTF-8)
>       string    instruction (ISO-10646 UTF-8)
>       string    language tag (as defined in [RFC-3066])
>       int       num-prompts
>       string    prompt[1] (ISO-10646 UTF-8)
>       boolean   echo[1]
>       ...
>       string    prompt[num-prompts] (ISO-10646 UTF-8)
>       boolean   echo[num-prompts]
> 
> The "name" field doesn't make much sense for me. First I assumed it
> was a user name, which makes no sense (what is a client supposed to do
> if it differs from the user name given in the USERAUTH_REQUEST
> message?). But in the example in the end of the draft, it seems to
> rather be part of the instruction, perhaps intended for a window title
> or some such. I think this needs some clarification.

The name is intended to contain the name of the method the server is
used. The original intent was for it to be possible to show this to the
user.

> The "language tag" is already deprecated, if we make changes, it
> should be deleted. I don't remember the discussion leading to its
> introduction or its deprecation.

Agreed, but since there already is a significant installed base using
this so we should try to avoid making changes if possible.

> The "num-prompts" is of type "int", which is not defined in the
> architecture draft. I guess "uint32" is the intended type.

Yes.

	/MaF