In message <>,
Chris Newman writes:
> On Wed, 10 Feb 1999, Martin Forssen wrote:
> > In this case I am trying to design a protocol to handle challenge-response
> > authentication in ssh. I do not plan to design a new authentication
> > mechanism.
> >
> > let me restate: The important thing here is to design a protocol which is
> > generic enough so that one only has to modify the ssh server when adding
> > support for a new challenge-response system (only those systems where the
> > user is expected to type the response on the keyboard). No further
> > modification of the ssh clients should be necessary. I think my original
> > proposal augumented with a message packet (with an error bit) fits this
> > bill. Unfortunately I am currently in the midst of moving to a new house
> > so I will not have time to write a new draft this week.
>
> So you're trying to do a mechanism to do generic prompts and responses?
>
> If the server has several OTP/challenge-response mechanisms, how will it
> know which one to use?
server-defined. eg, use PAM.
>
> If the client has automated assistance (where it generates the response
> given the challenge and password), how will it know which one to use?
I don't think automated assistance is an issue in this case.
An automated challenge-response authentication already exists; RSA.
>
> If all you want is an OTP mechanism, why not just directly encapsulate RFC
> 2243?
Well, it seems to me, (having skimmed it just now), that RFC 2243 requires
the client to have some knowledge of the OTP used (to specify the
encoding). It also seems closely tied to S/Key.
Part of the attempt here is to completely insulate the client from
needing any such knowledge. We don't want *an* OTP mechanism, we
want a *generic* mechanism for handling *generic* OTP's.
Also, assuming PAM would be used, the RFC requires a means to
re-initialize the seed; PAM provides no such support.
~frank
