[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Perfect forward secrecy (on SKIP)




> > As I have already confirmed offline with Hugo, this is the same
> > proposal that I made at the San Jose IETF, (and which I also
> > mentioned verbally at the Toronto IETF). So, is this the proposal
> > that you are advocating for perfect forward secrecy? If so,
> > we are at least coming closer to an agreement.
> 
> Almost. However I think we can do better by authenticating the ephemeral DH
> using the keys from the _previous_instance_ of the ephemeral DH. One can
> either use just the previous shared ephemeral key or use the public
> exponents from previous time by computing
> 
>    shared value in round i = g^{y_{i-1}}^x_i XOR g^{y_i}^x_{i-1}
> 
> Therefore in each round we authenticate the DH keys for next round.
> the result is that breaking req' breaking into both processors together
> and then an active attack (rather than just message injection as is possible
> in SKIP).

I am happy to observe that we appear to be moving closer to agreement
on at least the basic appearance of the protocol. This is good,
because if the rest of WG members also agree, we can then talk
about how other desirable goals such as anonymity etc. can
be preserved with this approach.

Now for comments on some of the details.

In general, I like the notion of using  key components from the last 
round to authenticate the next round. (If you read my paper on wireless 
network security, Feb 93, IEEE Personal Communications, essentially the 
same principle is used to authenticate the key-change protocol).

However, if you would like to use the last round's key components
to authenticate the next round, I suggest a better way might be
to simply include the last round's ephemeral public DH values in the 
authenticated/encrypted SKIP message that is used to communicate the 
current round's ephemeral DH components. This serves to authenticate the 
messages (and thereby the key), as opposed to simply authenticating the 
key.

i.e

	A->B  (A, B, g^x_i, g^x_{i-1}, g^y_{i-1})Kab,	where A knows x_i
	B->A  (B, A, g^y_i, g^y_{i-1}, g^x_{i_1})Kab,	where B knows y_i

where Kab is the implicit SKIP master key.

new key = g^{x_i*y_i}

This has the following advantages.

- If you happen to lose state and hence knowledge of the last
round's public component, this doesn't affect coming up with the
correct key. You can simply ignore the check on the last round's
public components and still come up with the correct key. With your
suggestion, if one side doesn't have the last round's public/secret
components, it simply can't come up with the correct key for
the current round, in the absence of a resynchronization protocol. 

- With your suggestion, for every round each node has to
perform 3 exponentiations. This is as follows, 1) g^x_i, (because 
the other side needs the public value of this round) 2) g^y_{i-1}^x_i
and 3) g^{y_i}^x_{i-1}. 

This adds 2 extra exponentiations to the basic protocol, both of which 
can be eliminated by my suggestion above.

One of the advantages of the SKIP approach is that it cuts down
on the number of exponentiations as compared to approaches that
authenticate the DH exchange using RSA signatures. We should
try and preserve this advantage.

- With your suggestion each side has to maintain the *secrets*
of the last round until the next round (in order to compute 
g^{y_i}^x_{i-1}).
 
This runs contrary to the goals of perfect forward secrecy. In 
cases where there are medium to long-term gaps in communication (e.g a 
week or a month) the ephemeral *secrets* from the last round have to 
be maintained in long term memory somewhere, thereby increasing their 
vulnerability.

With my suggestion, only the ephemeral *public* values from the 
last round need to be maintained, not the ephemeral secrets.
This is in accordance with the goals of perfect forward secrecy,
which requires that ephemeral secrets should be destroyed as soon 
as possible.

- Message playback attacks are discovered directly by examining
the messages. One doesn't have to compute an incorrect key, and
then discover that keys are mismatched through a failure to
communicate.

- For the first round (i=0), null values can be subsituted for
the last round's (-1) public components. Since the last round's
components serve to protect against replays, leaving them as
null for the first round is not a problem, because there are
no valid messages to be played back when i= 0.

Let me know if there were advantages you perceived using the approach
in your suggestion, that are lost with my suggestion above. And
also if these advantages outweigh the advantages that I listed
above.

> So my proposal is to have a protocol completely based on DH with a
> non-interactive and interactive modes (we can later decide if one of them
> is only optional). This protocol would have protection against clogging
> (even from unknown addresses and even non-interactive), anonymity if we
> desire (I'll explain how to do it non-interactively later - or ask Hugo),
> and proactive security at least in the interactive modes.

I agree completely.

The only comment I would like to add is that we dont need to state
the protocol in terms of DH.

I made the mistake of specifying SKIP in terms of DH alone. This
caused some WG members to (rightfully) raise the concern whether the 
protocol was being tied to a particular crypto algorithm.

In fact, the entire protocol as we have discussed it so far is
generalizable completely to any Public Key Agreement (PKA) algorithm.

I'll observe that the distinction between a public key agreement
algorithm and a public key cryptosystem (i.e with the trapdoor 
property) has existed since the inception of public key cryptography.

Just to recall, The PKA function in this context is as follows,

shared_secret_ab = pka(public_a, secret_b) = pka(public_b, secret_a)

where pka() stands for the Public Key Agreement function. Note that
this is no longer tied to any crypto algorithm. Any cryptographic
construction that satisfies this property and the other obvious
properties of not deducing either the individual or shared secrets
through knowledge of public values (the public key property) and
not being able to discover another shared secret, even if arbitrarily 
many shared secrets are known (collusion attack resistance) will work 
in this protocol.

All we are saying is that we will use certified and ephemeral pka 
public secret values. The DH function satisfies this property, but so 
can other functions e.g elliptic curve based, or those that use composite 
moduli as opposed to prime moduli. There may also be other (as yet 
undiscovered) cryptographic constructions that satisfy the PKA property.

Just to summarize the principal benefits of this approach.

- A single Public Key Infrastructure (that of the PKA type)
serves to allow both zero message session-less and session-oriented 
key-management with perfect forward secrecy.

- The perfect forward secrecy protocols based on this approach
are computationally more efficient than protocols that use signatures
to authenticate the DH exchange.

- Key Management messages are themselves encrypted. This means there
is no need to require bypass channels for the key-management traffic.
This is important, because real attacks in the field happen on systems
that embody protocols, and not just on the theoretical protocols 
themselves. To the extent that we can plug up real systems against such 
attacks, we enhance security.

- Encrypting the key-management traffic enhances security in other
ways as well. One of the reasons Burmester's triangle attack works against
the Yacobi, Goss, Gunther and other schemes is that the key-management
traffic can be observed. Encrypting the key-management traffic completely
foils this attack. (There are also other ways that our current construction
foils this attack, but I dont want to go too deep on this one for now).

That's it for this message. Looking forward to a cooperative
and productive '95! Happy new year folks.

Regards,
Ashar.


Follow-Ups: