Re: New work for sacred working group?

From the surface, though, it seems as if the SPEKE scheme and/or Radia & 
Charlie's new scheme (if at least one of these schemes can be used as 
"unencumbered," i.e. without requiring a license from somewhere) would be 
better suited for SACRED than TLS-PSK since (and correct me if I am wrong 
here):

a) It would make SACRED more independent on its transport, perhaps even
    allowing it to work on top of UDP or other connection-less transports.
    It would be nice, I think, not to have to rely on transport-provided
    security services.

b) The number of roundtrips would be smaller.

c) We would get protection against active attackers (admittedly,
    throttling or similar protection mechanisms could perhaps be used
    in the case of PSK-TLS) as well as passive ones (TLS-PSK basic mode).

d) TLS-PSK with server-side RSA-based authentication obviously requires a
    PKI, whereas the alternatives would not.

e) As I understand it, TLS-PSK with D-H where the PSK is a password or
    derived from one allows an active attacker (posing as the server) to
    learn information that will allow for a later, off-line dictionary
    attack, whereas the alternatives would not.

Don't you think it would be useful, also for the IETF as a whole, if we 
could determine whether at least one of the mentioned schemes are usable 
for SACRED ("usable" in the sense discussed here)?

-- Magnus

On Tue, 28 Jun 2005, Peter Gutmann wrote:

> Stephen Farrell <[email protected]> writes:
>
>> As I read it, that works by basically appending a (hashed?) password to a D-H
>> derived key (with some length fields) and using the resulting value as the
>> TLS pre-master key. Presumably the handshake falls over at the finished
>> message if the wrong password was used.
>
> Yup.  Or you can use RSA (without the heavyweight DH on the client-side), or
> just a plain shared key.
>
>> I'll have to read that I-D again and think about whether it really is better
>> than the current sacred scheme
>
> Well, I don't know about technically better, but it does more or less the same
> job, it's unencumbered, and it's tuneable for low-powered devices.  It's most
> importantly property however is that it's a TLS standards-track mechanism,
> which means that it actually exists (i.e. it's implemented and eventually,
> it's hoped, widely deployed).