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

From: Martin Forssen <[email-masked]>
Date: Wed, 29 Sep 2004 09:02:41 +0200 (CEST)

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 <[email-masked]>              Development Manager
Phone: +46 31 7744361                         AppGate Network Security AB

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 01 Oct 2004 04:13:40 +1200

Martin Forssen <[email-masked]> writes:

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

I just assumed that was historical baggage, and because draft-ietf-secsh-auth-
everything-imaginable-except-password-and-publickey.txt would be too long for
the IETF drafts directory.  In any case the proper title is actually "Generic
Message Exchange Authentication", which is a more accurate description of how
it's being used.

>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.

Fair enough.  Since it's now being used as a kitchen-sink authentication
mechanism though, it would be good to at least have an implementation-
considerations section on non-interactive auth, warning implementors that (for
example) unless they absolutely know there'll always be a real user at the
other end, they should be careful to avoid creating things that require humans
in the loop.  SSH is being used in all sorts of embedded devices and whatnot
where there's no user to handle arbitrary requests, without appropriate
cautions people may be shipping systems that break in this environment when a
small amount of forethought could prevent this.

Peter.