[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Photuris Long-Term Session-Keys
Ref: Your note of Wed, 22 Nov 1995 00:10:36 -0800 (PST) (attached)
>
>>The SPI LifeTime is not related to the Photuris Exchange LifeTime. That
>>is, the SPI session-key can be stored for long periods of time without
>>compromising other privacy uses of the same shared-secret.
>
>I think Bill's approach is a good one, and I agree that it should satisfy
>many of the needs of those who currently favor SKIP. I am interested in
>thoughts on the subject, though.
>
>Phil
Phil,
Here are some thoughts.
Indeed, as you say, Photuris can support long-lived pairwise master keys
thus providing many of the advantages claimed by SKIP which are based
on the existence of such (cached) long-term secrets.
Actually, Photuris does better. It refreshes short-lived keys through the
change-message and not by appending keys to the IP packet, thus
avoiding SKIP header's overhead.
However, both SKIP and the change-message way of refreshing keys are limited
by the fact that these are uni-directional methods. Bi-directional (or
interactive) refreshment of short-lived keys based on (authenticated)
handshakes between the parties,
provide for significant better security and synchronization.
It provides the parties with assurance of a successful exchange (lost
messges are detected), it provides with freshness of the keys and
authentication in both directions, it lets both parties refresh their SPI's,
both parties contribute to the randomness of the exchanged key, an
eavesdropper is required to monitor both directions of the communications
to try to learn anything, replay is easily handled (no need for timestamps,
counters, or keeping very long lists of used SPIs), and so on.
If all of this is done using cheap authentication techniques, like MD5,
there is no reason (in the vast majority of cases) not to do it.
Photuris hints to a way to do this but not in a satisfactory way.
The implementation note in page 25 (Photuris.07) implies that an
interactive key refreshment happens when the parties maintain their
exchange-values unchanged. However, as far as I understand it,
in this case only the initiator provides fresh information to the exchange
via the SPI and Cookie (I believe that the intention of the text here is
that the responder's cookie is unchanged in this case).
Thus, suffering from many of the limitation of the "uni-directional"
methods.
I believe that this "implementation note" needs to be upgraded to support
fully fresh bi-directional key refreshment. The way to do it is very simple
(and I have already argued for it in the past). Instead of unnecessarily
re-sending the unchanged exchanged-values just to discover that they did
not change, allow the parties to send fresh nonces as the "exchange-values".
In this case, all the advantages of interactive refreshment as pointed out
above hold. (Of course, the authentication of the messages is done using the
long-lived shared-secret via keyed-MD5 -- very cheap!).
[OK. If you want to use fresh cookies instead of fresh nonces, I'll live
with that...]
Let's not miss this oportunity to take full advantage of Photuris being
"bi-directional" by definition.
Hugo