Mailing List Archive

>I think the skey code is PD, so could be dropped into clients and
>servers.
>
>I must be missing something, cos this is just too simple.

As I recall, keeping the clients and server synchronized is
the problem -- skey assumes too much about the quality of the
communication link. There is a revised version of skey (with
a different name) now out as an Internet Draft, but I can't remember
the name. It might be referenced in the www-security archives.

Phill Hallam-Baker is the person here who knows about that stuff
(I avoid it like the plague, since security requires too much time
to keep up to date). Phill (hallam@w3.org) will likely
talk your ear (or fingers) off on the subject.

.....Roy

>I think the skey code is PD, so could be dropped into clients and
>servers.
>
>I must be missing something, cos this is just too simple.

As I recall, keeping the clients and server synchronized is
the problem -- skey assumes too much about the quality of the
communication link. There is a revised version of skey (with
a different name) now out as an Internet Draft, but I can't remember
the name. It might be referenced in the www-security archives.

Phill Hallam-Baker is the person here who knows about that stuff
(I avoid it like the plague, since security requires too much time
to keep up to date). Phill (hallam@w3.org) will likely
talk your ear (or fingers) off on the subject.

.....Roy

> >I think the skey code is PD, so could be dropped into clients and
> >servers.
> >
> >I must be missing something, cos this is just too simple.
>
> As I recall, keeping the clients and server synchronized is
> the problem -- skey assumes too much about the quality of the
> communication link.

hmmm,

server calls skey with users name, and is given a challenge
server calls skey one-time-password generator with challenge and
client password
server gets a one-time-password
server encrypts data using o-t-p and sends data and challenge to client

client reads challenge and calls skey o-t-p generator using clients
password
client gets the same o-t-p as the server saw earlier
client decrypts the data using the o-t-p

client and server now pass the challenge back and forth with all their
encrypted data.
The server can call skey whenever it wants in order to generate new
challenges.

I can't see any obvious synchronisation issues here.

> Phill Hallam-Baker is the person here who knows about that stuff
> (I avoid it like the plague, since security requires too much time
> to keep up to date). Phill (hallam@w3.org) will likely
> talk your ear (or fingers) off on the subject.

the security people scare me :-)


rob

> >I think the skey code is PD, so could be dropped into clients and
> >servers.
> >
> >I must be missing something, cos this is just too simple.
>
> As I recall, keeping the clients and server synchronized is
> the problem -- skey assumes too much about the quality of the
> communication link.

hmmm,

server calls skey with users name, and is given a challenge
server calls skey one-time-password generator with challenge and
client password
server gets a one-time-password
server encrypts data using o-t-p and sends data and challenge to client

client reads challenge and calls skey o-t-p generator using clients
password
client gets the same o-t-p as the server saw earlier
client decrypts the data using the o-t-p

client and server now pass the challenge back and forth with all their
encrypted data.
The server can call skey whenever it wants in order to generate new
challenges.

I can't see any obvious synchronisation issues here.

> Phill Hallam-Baker is the person here who knows about that stuff
> (I avoid it like the plague, since security requires too much time
> to keep up to date). Phill (hallam@w3.org) will likely
> talk your ear (or fingers) off on the subject.

the security people scare me :-)


rob

>I can't see any obvious synchronisation issues here.

The one-time-password generators on each system need to be synchronized
(probably the wrong word, since they aren't clocks) because the
generator increments the seed on each password generated, which works
just fine until the server generates a password which never gets seen
by the client. However, this is just from memory of a conversation
I had eight months ago, so it may be completely bonkers. I believe
this problem may be addressed by the newer specification.

.....Roy

>I can't see any obvious synchronisation issues here.

The one-time-password generators on each system need to be synchronized
(probably the wrong word, since they aren't clocks) because the
generator increments the seed on each password generated, which works
just fine until the server generates a password which never gets seen
by the client. However, this is just from memory of a conversation
I had eight months ago, so it may be completely bonkers. I believe
this problem may be addressed by the newer specification.

.....Roy

There is only one problem with skey. Some OS's can't use it... just
as Linux. skey requires crypt which linux does not contain, and can't
because it's a international product.

Although the idea is sound, skey will not work on such systems.

<Aram>


At 11:11 AM 9/1/95 MDT, you wrote:
>
>Secure http doesn't really interest me, but I was thinking last night
>about how "skey" technology could be used to make secure transfer possible
>at no cost to end users.
>
>Basically, skey involves giving challenges which result in a
>one-time-password, so if I'm not missing something obvious, clients
>and servers can just pass these challenges back a forth inside HTTP
>headers, and send the rest of the information encrypted using the
>one-time-password.
>
>the passwords never get transmitted over the net, only the challenges
>and encrypted data.
>
>I think the skey code is PD, so could be dropped into clients and
>servers.
>
>I must be missing something, cos this is just too simple.
>
>
>rob
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

There is only one problem with skey. Some OS's can't use it... just
as Linux. skey requires crypt which linux does not contain, and can't
because it's a international product.

Although the idea is sound, skey will not work on such systems.

<Aram>


At 11:11 AM 9/1/95 MDT, you wrote:
>
>Secure http doesn't really interest me, but I was thinking last night
>about how "skey" technology could be used to make secure transfer possible
>at no cost to end users.
>
>Basically, skey involves giving challenges which result in a
>one-time-password, so if I'm not missing something obvious, clients
>and servers can just pass these challenges back a forth inside HTTP
>headers, and send the rest of the information encrypted using the
>one-time-password.
>
>the passwords never get transmitted over the net, only the challenges
>and encrypted data.
>
>I think the skey code is PD, so could be dropped into clients and
>servers.
>
>I must be missing something, cos this is just too simple.
>
>
>rob
>
>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

> >I can't see any obvious synchronisation issues here.
>
> The one-time-password generators on each system need to be synchronized
> (probably the wrong word, since they aren't clocks) because the
> generator increments the seed on each password generated, which works
> just fine until the server generates a password which never gets seen
> by the client. However, this is just from memory of a conversation
> I had eight months ago, so it may be completely bonkers. I believe
> this problem may be addressed by the newer specification.


The one-time-password generator is independent of the challenge
generator.
You can run the o-t-p genarator a thousand times, it just acts as
a challenge+password -> string function.
It'll give the same answer over and over again and it doens't know or
care what sequence things are requested.

The server just calls the challenge generator whenever it feels like.
It is this program that decrements a seed when given the o-t-p in
response to the challenge.


--
http://nqcd.lanl.gov/~hartill/

> >I can't see any obvious synchronisation issues here.
>
> The one-time-password generators on each system need to be synchronized
> (probably the wrong word, since they aren't clocks) because the
> generator increments the seed on each password generated, which works
> just fine until the server generates a password which never gets seen
> by the client. However, this is just from memory of a conversation
> I had eight months ago, so it may be completely bonkers. I believe
> this problem may be addressed by the newer specification.


The one-time-password generator is independent of the challenge
generator.
You can run the o-t-p genarator a thousand times, it just acts as
a challenge+password -> string function.
It'll give the same answer over and over again and it doens't know or
care what sequence things are requested.

The server just calls the challenge generator whenever it feels like.
It is this program that decrements a seed when given the o-t-p in
response to the challenge.


--
http://nqcd.lanl.gov/~hartill/

On Fri, 1 Sep 1995, Rob Hartill wrote:

> Basically, skey involves giving challenges which result in a
> one-time-password, so if I'm not missing something obvious, clients
> and servers can just pass these challenges back a forth inside HTTP
> headers, and send the rest of the information encrypted using the
> one-time-password.
>
> the passwords never get transmitted over the net, only the challenges
> and encrypted data.

This is not quite the way S-Key works from my reading, but
"close enough".

It seems to me, though, that each user would have to have
a relationship with each server, since the SKey "initial passwd"
has to be given to the server "off-line" (this is how the
server can generate the intermediate phrase, and subsequently
know what the client will return "one time"). Thus the user
needs, in advance, a "relationship" -- off line -- with each
server.

Another issue is how a client can generate a sequence of
one-time passwords that would be known to a server (since you'd
certainly not want to prompt the user to enter the intermediate
phrase for every hyperlink).

I have been thinking about this, too, from a slightly different
perspective, and I find SKey very attractive (if you are willing
to force clients to adopt new/additional software). The key,
I think, is having a secure way to avoid this previous relationship
requirement. We're trying to fit this into our software in such a
way that there would need to be only one (prior) relationship, yet
access to a "universe" of providers. Our thinking is not beyond
the "concept fits" stage, though.

> I think the skey code is PD, so could be dropped into clients and
> servers.

The actual "SKey" is copyright Bellcore but there
are several versions extant that appear to be PD.
Also, Bellcore is sponsoring a "One Time Password"
proposal at IETF.

> I must be missing something, cos this is just too simple.

Yes, and no. :-)

dave

+------------------------------------------------------------------+
| David Oliver dave@newshare.com |
| Managing Director-Technology Newshare Corporation |
+------------------------------------------------------------------+

> > Basically, skey involves giving challenges which result in a
> > one-time-password, so if I'm not missing something obvious, clients
> > and servers can just pass these challenges back a forth inside HTTP
> > headers, and send the rest of the information encrypted using the
> > one-time-password.
> >
> > the passwords never get transmitted over the net, only the challenges
> > and encrypted data.
>
> This is not quite the way S-Key works from my reading, but
> "close enough".

I relalise it's not the way S-Key works, but it can be used in this way
for secure http.

> It seems to me, though, that each user would have to have
> a relationship with each server, since the SKey "initial passwd"
> has to be given to the server "off-line" (this is how the

This is the snag as far as I can tell. But we're all used to having
pin numbers sent to us by snail mail or using the phone to initialise
services.

> Another issue is how a client can generate a sequence of
> one-time passwords that would be known to a server (since you'd
> certainly not want to prompt the user to enter the intermediate
> phrase for every hyperlink).

The client can prompt for the secret password once, then use it locally
to compute a (series of) one-time-password to unlock the data.. subject
to the usual timeouts that are useful in these cases.


rob
--
http://nqcd.lanl.gov/~hartill/

On Fri, 1 Sep 1995, Aram W. Mirzadeh wrote:
>
> There is only one problem with skey. Some OS's can't use it... just
> as Linux. skey requires crypt which linux does not contain, and can't
> because it's a international product.

There must be an S/Key product available for Linux, even if only
within U.S./Canada. FreeBSD is also as "international" as Linux, but
S/Key, Kerberos, DES crypt(), etc. are available for it. What does
Linux use for password hashing? DES or MD5?
--
Brian ("Though this be madness, yet there is method in't") Tao
taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org

At 02:33 PM 9/2/95 +0800, you wrote:
>On Fri, 1 Sep 1995, Aram W. Mirzadeh wrote:
>>
>> There is only one problem with skey. Some OS's can't use it... just
>> as Linux. skey requires crypt which linux does not contain, and can't
>> because it's a international product.
>
> There must be an S/Key product available for Linux, even if only
>within U.S./Canada. FreeBSD is also as "international" as Linux, but
>S/Key, Kerberos, DES crypt(), etc. are available for it. What does
>Linux use for password hashing? DES or MD5?
>--
>Brian ("Though this be madness, yet there is method in't") Tao
>taob@gate.sinica.edu.tw <-- work ........ play --> taob@io.org
>

DES( I think ) you can add crypt to it.... but you have to load a whole bunch
of stuff into it. The only difference between FreeBSD, and Linux is that
FreeBSD is a US product, the main production goes on here. Linux's
main production is in Finland. Which means, they don't have access to
things like crypt, so it never gets into the disterbution. I'm sure someone
out there has created the correct files/libs for crypt to get integerated into
Linux, but most likely, it will never get into the public disterbution.

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

In reply to Aram W. Mirzadeh who said
>
> At 02:33 PM 9/2/95 +0800, you wrote:
>
> DES( I think ) you can add crypt to it.... but you have to load a whole bunch
> of stuff into it. The only difference between FreeBSD, and Linux is that
> FreeBSD is a US product, the main production goes on here. Linux's
> main production is in Finland. Which means, they don't have access to
> things like crypt, so it never gets into the disterbution. I'm sure someone
> out there has created the correct files/libs for crypt to get integerated into
> Linux, but most likely, it will never get into the public disterbution.

FreeBSD is most definately NOT a US product and you should be rather more
careful about making definitive statements about projects that you are not
directly involved in. FreeBSD is an international project just like Apache
is, it just happens to be hosted on a US site at this point in time.

Anyway, onto the technical issues, FreeBSD has an MD5 based crypt which IS
exportable because it is a one-way encoding and is therefore not
encryption. An algorithm is only encryption technology if the encrypted
item can be decrypted using a key. MD5 cannot be and therefore is not
encryption and is therefore not covered by the export laws. The libcrypt
library in FreeBSD is carefully designed to only do the one-way encoding
so that it is not covered by US export restrictions.

A one-way encoding is ideal for authentication purposes since all you are
doing is scrambling the plain-text password in some way to make it unreadable.
A one-way encoding algorithm such as MD5 is actually far more secure
than an encryption algorithm such as DES because given enough time
and the encrypted passwords you can crack the code and do the decryption.
You simply *can't* decrypt MD5 encoded passwords so even if you manage
to get ahold of the encoded passwords there's no way to get back the
plain-text passwords.

We also supply a DES based crypt of which there are two versions,
one of which is available on US sites and another that is available
on non-US sites, although in practice they're identical since the
changes to the non-US version get imported to the US version.

FreeBSD has s/key by default and it works perfectly well with either
crypt library since all the crypt() call does is encode the plain-text
in some way and whether you use a one-way encoding such as MD5 or an
encryption algorithm such as DES makes no difference.

I guess a lot of people here already know all about this but some probably
don't.

DISCLAIMER: This really isn't my area, I just know how we use it in
FreeBSD.

--
Paul Richards, Bluebird Computer Systems.
Internet: paul@FreeBSD.org, http://www.freebsd.org/~paul
Phone: 0370 462071 (Mobile), +44 1222 457651 (home)

At 08:56 PM 9/4/95 +0100, you wrote:
>In reply to Aram W. Mirzadeh who said
>>
>> At 02:33 PM 9/2/95 +0800, you wrote:
>>
>> DES( I think ) you can add crypt to it.... but you have to load a whole bunch
>> of stuff into it. The only difference between FreeBSD, and Linux is that
>> FreeBSD is a US product, the main production goes on here. Linux's
>> main production is in Finland. Which means, they don't have access to
>> things like crypt, so it never gets into the disterbution. I'm sure someone
>> out there has created the correct files/libs for crypt to get integerated
into
>> Linux, but most likely, it will never get into the public disterbution.
>
>FreeBSD is most definately NOT a US product and you should be rather more
>careful about making definitive statements about projects that you are not
>directly involved in. FreeBSD is an international project just like Apache
>is, it just happens to be hosted on a US site at this point in time.

Sorry, didn't mean anything by it.

>
>Anyway, onto the technical issues, FreeBSD has an MD5 based crypt which IS
>exportable because it is a one-way encoding and is therefore not
>encryption. An algorithm is only encryption technology if the encrypted
>item can be decrypted using a key. MD5 cannot be and therefore is not
>encryption and is therefore not covered by the export laws. The libcrypt
>library in FreeBSD is carefully designed to only do the one-way encoding
>so that it is not covered by US export restrictions.

Hmm... I do agree with you here.
>
>We also supply a DES based crypt of which there are two versions,
>one of which is available on US sites and another that is available
>on non-US sites, although in practice they're identical since the
>changes to the non-US version get imported to the US version.
>
>FreeBSD has s/key by default and it works perfectly well with either
>crypt library since all the crypt() call does is encode the plain-text
>in some way and whether you use a one-way encoding such as MD5 or an
>encryption algorithm such as DES makes no difference.

I don't know about this. having two versions that is. I know that if you run
skey on a linux system and on any other OS, ( ex dos is the one I tried )
you get two different set of results. And I belive I heard somewhere that
the Linux people had to specificly take out the crypt stuff for it to be
exportable. I'm not sure if they were told to remove it or removed it by
themselves. I'll check into this.

<Aram>
--
Aram W. Mirzadeh, MIS Manager, Qosina Corporation
http://www.qosina.com/~awm/, awm@qosina.com
Apache httpd server team http://www.apache.org

If your focus is on passwords in the clear, which is what skey solved,
what's wrong with the MD5 password digest proposal?

I don't know enough about security to have an opinion as to why using
skey to encrypt data is a bad idea, but I do happen to think that
encryption of data is a lot less interesting than digital signatures.

Brian

On Fri, 1 Sep 1995, Rob Hartill wrote:
> Secure http doesn't really interest me, but I was thinking last night
> about how "skey" technology could be used to make secure transfer possible
> at no cost to end users.
>
> Basically, skey involves giving challenges which result in a
> one-time-password, so if I'm not missing something obvious, clients
> and servers can just pass these challenges back a forth inside HTTP
> headers, and send the rest of the information encrypted using the
> one-time-password.
>
> the passwords never get transmitted over the net, only the challenges
> and encrypted data.
>
> I think the skey code is PD, so could be dropped into clients and
> servers.
>
> I must be missing something, cos this is just too simple.
>
>
> rob
>

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/