Re: s/key changes

[Richard Johnson <rjj_(_at_)_medialab_(_dot_)_com>]

At 10:23 9/28/96, Todd C. Miller wrote:
>In message <qwon2yb4013_(_dot_)_fsf_(_at_)_reeducation-labor_(_dot_)_lcs_(_dot_)_mit_(_dot_)_edu>
>        so spake David Mazieres (dm):
>> >     5) The skey challenge has changed from:
>> >         s/key 98 xerx532405
>> >        to:
>> >         s/key MDX 98 xerx532405
>> >        Again where X is 4 or 5.
>> 
>> Ideally, the challenge would be as easy as possible to cut and paste
>> into a local xterm, so what about something like:
>> 
>>  skey -5 98 blah234425
>
>That's pretty ugly.
>
>> Or maybe allow the skey program to accept:
>> 
>>  skey MD5 98 blah234425
>> 
>> as input.


Standards track RFC 1938, "A One-Time Password System" (May 1996)
<ftp://ds.internic.net/rfc/rfc1938.txt>, which grew out of S/KEY, specifies
a challenge of the form:

          otp-<algorithm identifier> <sequence integer> <seed>

where the whitespace between the three tokens is spaces and/or tabs, the
string "otp-" is lower case, and the algorithm identifiers are currently
md4, md5, and sha1.

Having the generator (skey) accept challenges of that form, in addition to
the pre-standard skey form, will allow it to be used with other otp
packages.  Producing all challenges in that form (compile time option to
allow backwards compatibility?) will allow more transparent logins for
users employing clients with built-in generators.

For example, OPIE <ftp://ftp.inner.net/pub/opie/> using MD5 issues
something like this:

        otp-md5 269 ya0818

At least one GUI ftp client my users regularly employ (Fetch, from
Dartmouth, for the Mac) already automatically recognizes these challenges,
and handles the otp response generation transparently.


Richard