Subject: Re: New work for sacred working group?

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2005 18:24:03 +0100

Hi Eric,

This [1] is the relevant license, right? Too hard to read
this late in what's been a very nice summer's day here (i.e.
I'm off home now:-)

One question though: did you mean that you'd support doing
more work here, or are you saying there's no need since
you've already released your stuff?

Cheers,
Stephen (also nothing like a lawyer).

[1] http://plan9.bell-labs.com/plan9dist/license.html

Eric Grosse wrote:

> Stephen,
> 
> I think encrypted key exchange protocols are exactly the right
> tool for credential download and I use them daily.  I am not a
> lawyer, but the Lucent Public License which covers the
> securestore implementation (and hence EKE and PAK) seems ok.
> 
> Eric
> http://plan9.bell-labs.com/plan9dist/factotum.html
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: New work for sacred working group?
> From:
> [email-masked] (Peter Gutmann)
> Date:
> Mon, 27 Jun 2005 23:49:55 +1200
> To:
> [email-masked], [email-masked]
> 
> To:
> [email-masked], [email-masked]
> CC:
> [email-masked]
> 
> 
> Stephen Farrell <[email-masked]> writes:
> 
> 
>>Does the lack of response mean that there's no longer much interest in using
>>schemes like SPEKE for credential download or that no-one's reading this list
>>anymore?
> 
> 
> I'm reading it, but purely in passive mode.  In theory I'd be strongly opposed
> to the use of any crippled/patented technology in Sacred (particularly when
> there are unencumbered alternatives available), but since I'm not an
> implementor it's really just a personal opinion.
> 
> Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jun 2005 19:15:15 +0100

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