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

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

On 30 Sep, Jeffrey Hutzelman wrote:
> Indeed.  Imagine the scenario where a user has a Kerberos password and some 
> kind of challenge/response token.  Now, suppose the user comes in to work 
> and leaves the token home.  He wants to use Kerberos, so he sends a 
> submethod list containing "kerb5".  The server doesn't support "kerb5", 
> because the method is called "krb5".
> 
> Now, should the server
> (a) fail the exchange, reporting that it can't support any of the methods
>     the user asked for
> (b) continue by arbitrarily selecting the method that requires the
>     challenge/response token which the user left at home

Well, there are a couple of options here. In (a) the server could tell
the user (through kbdint or banner) which submethods it does support.
There is also a third alternative

(c) Ask the user (through kbdint) which method they want to use.

I am not saying that either of these methods is perfect nor even good...

If I were to redesign kbdint today I would probably move up the
submethod one level. So the server should present the different
submethods as different authentication methods. For example kbdint/krb5
and kbdint/securid, but in the client both of these could be handled by
the same code. The advantage of this approach is that we reuse the
authmethod presentation/negotiation already present in the protocol. The
drawback is that it requires protocol changes. So implementations would,
for a long time, need to support both the current kbdint and the new.

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