Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
To: None <tech-security@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: tech-security
Date: 01/30/2000 13:07:50
  by redmail.netbsd.org with SMTP; 30 Jan 2000 18:07:56 -0000
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <woods@most.weird.com>) 
	id <m12EylK-000g6HC@most.weird.com>
	for tech-security@netbsd.org; Sun, 30 Jan 2000 13:07:50 -0500 (EST)
	(Smail-3.2.0.110-Pre 1999-Oct-27 #5 built 2000-Jan-29)
Message-Id: <m12EylK-000g6HC@most.weird.com>
Date: Sun, 30 Jan 2000 13:07:50 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@most.weird.com (Greg A. Woods)
To: tech-security@netbsd.org
Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
In-Reply-To: <20000130121507.A19495@noc.untraceable.net>
References: <20000124175648.A13877@noc.untraceable.net>
	<v04220801b4b9a9cb09b5@[204.179.128.134]>
	<m12Ewof-000g6HC@most.weird.com>
	<20000130121507.A19495@noc.untraceable.net>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada

[ On Sunday, January 30, 2000 at 12:15:07 (-0500), Andrew Brown wrote: ]
> Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability]
>
> very easy, if everyone that uses skey decides to use the same
> sequence, challenge, and secret for each host.  which is easy.  it'd
> be better if, say, skey didn't allow the user (except for root
> perhaps) to pick the challenge.

Hmmm....  The more I look on the surface of s/key the less I seem know
about how it works.  I had assumed, incorrectly it seems, that there was
a host-specific secret seed created at install time, but of course that
would defeat the ability for an arbitrary response calculator to work
properly.

I'm also now confused as to how it's not possible for someone to
determine the next appropriate challenge (and thus calculate the
appropriate response) if the /etc/skeykeys file is publicly readable.
Obviously if this is true there must be some cryptographically secure
algorithm that can combine the seed and the secret to generate a new and
hopefully unique challenge.  Unfortunately the documentation is
completely silent about the algorithms involved.  I worry about this
because in other implementations of challenge/response systems, such as
"CryptoCard(tm)", it's possible to compute the challenge response if one
knows RNG seed (and the calculator PIN?).

There are other documentation bugs too, such as how many characters
should be in a "seed"; what the format of /etc/skeykeys is, etc.
There's no reference in login(1) to /etc/skeykeys and no documentation
to describe how it knows if S/Key can be used for authentication.

> >Is the "bug" where "skey" generates different responses on different
> >architectures known and if so is it fixed in -current and 1.4.2?
> 
> yes.

Thanks for verifying.  I thought it might be but I've been unable to
boot a newer sparc release on my spare ss1 and have no non-i386 -current
machines to test on.

> the sparc has the endianness wrong somewhere.  does your "md5 -x"
> output not match the rfc perhaps?

'md5 -x' (a test I'd forgotten completely about) seems to match on all
the different machines I've got....
 
> here's a hint:
> 
> % skey -p 9 9 9 
> STUB ELSE MARY LOON COON EAR
> 
> i *always* use this one for a test case.  the choice of 9's was
> completely arbitrary, but i've been using it for years and can now
> recite "stub else mary loon coon ear" on demand.

That's a good one....  Perhaps this and 'md5 -x' should be part of the
default /usr/regress regression tests.  Maybe someone with an eye to the
corner/edge cases in the implementations could devise some even better
tests too.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>