On 22 Feb, Frank Cusack wrote:
> Here is an updated version of my proposal, fully formatted as an
> I-D.
This is looking good. I think it is more worthwhile to work on this
draft than on mine. But I do have some comments:-)
First the big issue. After some thinking I have reached the conclusion
(this is all IMHO of course) that we do not need to try to define some
generic protocol which can handle all smart-cards biometric devices
etc. Instead we need a way to let the client and the server load new
authentication methods dynamically. Therefore we should be able to
remove everything but the keyboard input type, and thus postponing many
potential problems (divide and conquer).
The basis for removing the non-keyboard types is that I think we should
separate those methods who need special code (drivers unique for that
method) on the client from those who do not (I do not count keyboard
interaction as defined here as special code). This document describes
the keyboard method.
Other methods who needs special code could take two approaches. One is
to document the protocol and write a draft about it. This is IMHO a
good idea. Or if one does not want to write a draft describing the
protocol one could use a private method name (one with an '@' in it).
We could even make a convention that one could register pam-modules as
module_name@pam.
The imporant thing is to define a common API (perhaps some modfied form
of PAM) which those methods cna use to connect to ssh.
And now over to the comments on the draft itself.
> 3.1 Initial Exchange
...
> The authentication starts with the client sending the following
> packet:
>
> byte SSH_MSG_USERAUTH_REQUEST
> string username
> string service
> string "password-plus"
> int num-supported-input-types
> int input-type[0]
> ...
> int input-type[n]
I would feel more comfortable if we used the same list format as the
sshauth draft does (ie a comma-separated string). I would like to
propose the following format instead:
byte SSH_MSG_USERAUTH_REQUEST
string username
string service
string "password-plus"
string methods
Where methods is a comma-separated strings of supported authentication
methods using the keyboard input type.
The rationale for having the methods field is that the user may have
multiple methods availbale (for example both SecurID and CryptoCard).
This list should be normally be provided by the user. The server should
also be able to ignore this field if it knows from some other context
which method(s) are avilable for the user.
> 3.2 Information Requests / User Interface
...
> part" and an "input-type-specific part". The "common part" is
> defined as follows:
>
> byte SSH_MSG_USERAUTH_INFO_REQUEST
> int input-type
> boolean name-present
> string name (if name-present is TRUE) (ISO-10646 UTF-8)
> boolean banner-present
> string banner (if banner-present is TRUE) (ISO-10646 UTF-8)
> rest of the packet is input-type-specific
Why do we need the booleans? Should not just a zero-length string
suffice to inidcate that no value is given? I think the protocol would
look cleaner if one always had the same fields in a packet.
I also miss the language-tag for these fields. Perhaps it would be
enough for one language-tag for each packet (which would force the
name, banner and prompts to be in the same language).
> 5. Protocol constants
> All negative values for input types are reserved for locally
> defined methods. No method is specified for determining what
> "locality" a negative input type is valid in.
IMHO strings should be used to identify protocols. Then we can use the
same mechanism as the architecture draft (section 5) uses for
algorithms to denote local methods (appending @your.mail.domain).
/MaF
