Martin and fellow groupers:
> From: Martin Forssen <[EMAIL PROTECTED]>
>
> 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.
>
I agree wholeheartedly with what Martin is trying to accomplish.
Each time a new entry in the 1.2.x series came out, and now with 2.x I
have had to cobble in my custom mechanism to support the S/Key one-time
challange / response library. It would be much nicer to have a server
controlled dialogue where the type of challange and the user prompt
are sent by the server to the client and the client just knows how to
deal with it (i.e,. variable length prompt, variable length responses).
This would open up the ssh world to any kind of challange / response
dialogue that creative people want to put into the server source without
having to worry about the client. There should also be some more work
done on the protocol specs to deal with un-updated clients and rollover
to other authentication mechanisms.
For the wish list, I would love to see the binary configuration
flags for authentication types modified to reflect some sort of
ordering of desired methods (perhaps even allowing several to be at the
same level). It would also be nice to introduce the concept of
"method=FORCE" to absolutely guarantee that if a site wanted to enforce
a particular authentication policy the server would have no choice
(this will also require some changes to both the server-side and client
specs to allow cascading methods; to combine it with the ordering,
perhaps: "method=1,FORCE"). I have also cobbled in this code to
various releases. In general, I like to implement all of the
host-to-host methods and then in the user area use a login password
followed by a "forced" S/key exchange. Multi-tier may be a pain to
users, but I sleep better at night...
And now back to the regularly scheduled debate on how to
tunnel old-style primative dial-out protocols over a ssh tunnel
--> flame-bait to all of the virtual protectors of kermit and its
kin -- couldn't resist %^{0>
Regards,
b c++'ing u,
%-) sjs
PS: I am my own employer, therefore: "all opinions are twice spoken for;"
and they do, in fact, scare the hell out of said employer!!!
-------------------------------------------------------------------------------
Stefan Jon Silverman - President SJS Associates, N.A., Inc.
Suite 15-B
Inter-/Intra-Net Architecture, Implementation & Security 698 West End Avenue
New York, NY 10025
E-mail: [EMAIL PROTECTED] Phone: 212 662 9450
Website: http://www.sjsinc.com Fax: 212 662 9461
Text-Page: [EMAIL PROTECTED] Cell: 917 929 1668
-------------------------------------------------------------------------------
Weebles wobble, but they don't fall down!!!
-------------------------------------------------------------------------------
