Re: New work for sacred working group?

[Stephen Farrell <stephen.farrell@xxxxxxxxx>]

Hi Eric,

Thanks for that.

Eric Grosse wrote:

> (clarifying my earlier message)
>
> Encrypted key exchange protocols seem like the right tool for
> credentials download and I have been using them daily for years.
> Indeed, I had planned to convert Securestore to SACRED, just to
> be more standards compliant, but was put off by this missing
> protocol option, so I would encourage the new work.

Good to hear.

> My threat scenario is this:  boot the local device with a LiveCD
> or other trusted, generic kernel and filesystem.   Tell the
> client your (SACRED servername, username, password) to fetch
> your credentials.    Notice that in general you don't have a
> place to save a key fingerprint for the SACRED server or a high
> entropy preshared secret.  The threat scenario includes the risk
> of connecting to a fake server that will try a dictionary attack
> on the password.
>
> I am not a lawyer, but the Lucent Public License seems ok.  We
> give away our implementation along with a license to whatever
> patents we own (like EKE) that might be needed.
>   http://plan9.bell-labs.com/plan9dist/license.html
>   http://plan9.bell-labs.com/plan9dist/factotum.html
> We use PAK because that was the technically best protocol of
> this class that I had heard of.  There are newer PAK variants
> that might give better privacy or faster computation, but what
> we use now seems good enough to me.  I don't know exactly how
> this affects your choice of protocol.  The EKE patent looks
> pretty broad to me, and the license might only be good for
> PAK.  I guess you need a lawyer (or a court case) to be sure.

Looks to me like the license maybe only covers uses of the
s/w as released by you guys, but allows doing pretty much
anything with that. (Which is pretty cool.)

Without getting into whether that's a good or bad interpretation,
do you know whether that plan9 code includes EKE code? (Or e.g.
enough code to do EKE beneath some API.)

> I do worry about keyboard loggers or shoulder surfers or
> whatever, so in practice I use two-factor authentication (both
> PAK and SecurID) with the intent that my system should remain
> secure if either factor were compromised.  From the view of
> SACRED, let's pretend hardware tokens don't exist and build
> something independently strong.

Ok,
Stephen.

> Eric Grosse
> Bell Labs, Computing Science Research