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

[Martin Forssen <maf%appgate.com@localhost>]

On 29 Sep, Peter Gutmann wrote:
> It also makes it extremely difficult to implement in any app that doesn't have
> a UI, i.e. where you can't just keep asking the user for input until the
> server is satisfied.  Fortunately for standard password auth I've never found
> anything that sends more than one prompt, but I'd like to see a bit more
> consideration given to non-interactive apps.  Currently the draft seems to
> assume that the client-side is tied to a live user in front of a terminal who
> can read, interpret, and respond to each prompt, which isn't always the case.

It is very true that the draft assumes that. A fair indicator is that
the name contains the word "interactive".

My rationale when starting to do this was that I had a new
authentication token (cryptocard) which I wanted to use but I realized
that I would have to upgrade all my clients to add support for it. And
when another token came out I would have to upgrade again. I wanted to
design a protocol so we could add new authentication methods without
having to modify the installed client base.

	/MaF
-- 
Martin Forssen <maf%appgate.com@localhost>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB