secure transfer using skey

[Rob Hartill <ha...@ooo.lanl.gov>]

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

Re: secure transfer using skey

["David M. Oliver" <da...@newshare.com>]

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 |
+------------------------------------------------------------------+

Re: secure transfer using skey

[Brian Behlendorf <br...@organic.com>]

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/