Subject: Re: Keyboard-interactive: device names and IANA

From: Darren Moffat <[email-masked]>
Date: Mon, 18 Dec 2000 12:48:51 -0800 (PST)

>> What about "mechanisms".
>
>as i understand it, the field in question was meant to select between
>multiple cards given to a single user.  

The text as I read it strongly suggests that there are "devices" of
differing types not just multiple instances of the same type.

Hence the suggestion of mechanism since I see Securid and Engima Safeword
as different authentication mechanisms both of which happen to have an
physical device, but other mechansims might not have a device.

The only problem I have with using devices is that there is a strong hint
that there is a bit or hardware rather then this being some alternate
authentication mechanism that requires the use of the keyboard (eg 
draft-perlman-strong-cred-00.txt)

Since Bill and I have read this differently I think some rewording is
required regardless of the choice of name for the field, see below for
a suggestion (which also has s/devices/mechanisms/).

- ---

3.1 Initial Exchange

   The authentication starts with the client sending the following
   packet:

      byte    SSH_MSG_USERAUTH_REQUEST
      string  user name (ISO-10646 UTF-8)
      string  service name (US-ASCII)
      string  "keyboard-interactive" (US-ASCII)
      string  language tag (as defined in [RFC-1766])
      string  mechanisms (ISO-10646 UTF-8)

   The language tag indicates the client's preferred language.  The
   server SHOULD use this language for all text that is to be presented
   to the user in the subsequent exchanges.

   If the server cannot support the requested language, the language to
   be used is implementation-dependent.

   The mechanisms field is a comma-separated list of authentication
   methods (software or hardware) that are available to authenticate
   the user using the keyboard-interactive authentication method. The
   mechanisms may be mulitple instances of the same type (eg a Securid
   Token) or different mechanisms (eg, securid,safeword,smartcard). If
   the client has knowledge of the mechanisms available to the user, it
   MAY use the mechanisms field to pass this information to the server.
   Otherwise it MUST send the empty string.  The client MUST NOT depend
   on authenticating using the mechanism list provided to the server.

   Server interpretation of the mechanisms is implementation-dependent.

   One possible implementation strategy of the mechanisms field on the
   server is that, unless the user may use multiple different mechanisms
   the server ignores this field. If the user may authenticate using one
   of several different mechanisms the server should treat the mechanisms
   field as a hint on which device the user wants to use this time.
   
--
Darren J Moffat