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

comments on Photuris

Ref:  Your note of Tue, 21 Feb 1995 02:08:36 -0800 (attached)



   >I still prefer the option of signing nonces chosen by the other party.
   >It is more secure (time sync considerations, granularity of frshness, etc.)

   >However, for parties that periodically refresh their keys there is no reason
   >not to maintain a nonce sent in the previous refreshment round; in that case

   Suppose I add a rule to Photuris that says you should use an existing
   SAID whenever possible to encrypt the exchanges that create a new
   SAID. Would this give you some of the same sort of protection against
   partial compromises that you get with explicit key refreshment?

   Phil

Phil,

Yes. It definitely adds protection. Let me be more explicit on this.
Your suggestion brings up several issues that Amir and myself talked about
in past notes with not much echo... ;-)

If I understand correctly, what you mean is basically having two
(simultaneous) ways to authenticate a key exchange. One is using
signatures, the other using the previously shared key between the parties.
(Notice that when you say "encryption" using the previous key what
you really want to achieve is authentication, otherwise encrypting with the
just exchanged key, as you do in the current draft,
is good enough for anonymity).

In my opinion doing both, i.e authentication with MAC_K (where K is the
previously shared key and MAC  a shared key authentication algorithm
like keyed-MD5) and a signature using the private key is the best
combination from the security point of view. It gives

1) defense against clogging: a simple MAC on the DH parts (e.g. MAC_K(g^x))
let you cheaply verify that the right guy is talking to you
(Notice that in order to verify MAC_K(g^x) you need to know who is
communiacting to you and this may seem to contradict your requirement
for anonymity; this issue can be solved too but let's postpone it).

2) chaining: authentication requires knowing the previous (transient)
key, thus even an adversary that stole a private key in the past needs
a piece of current information for authentication. Even if an adversary has
all the information to do a successful impersonation, a later intent
to exchnage a key by the legitimate party will detect the intrusion.

3) Authentication is private-key dependent. If you keep your private key
well protected there is no way to impersonate you

4) Even if the attacker breaks into A (but not into B) it cannot impersonate
   B to A.  I believe this to be an important property of a good key management
protocol. It is analogous to the approach to passwords in UNIX: an attacker
breaking into the server that verifies your password cannot later impersonate
you to the server. This is in sharp contrast to servers that keep a file
with the passwords. In the latter case the attacker will learn the passwords and
be able to impersonate *any* user to that server.

Notice that properties 1 and 2 are achieved by the use of MAC, while 3 and
4 by use of signatures. Therefore the two mechanisms are complementary.
Because of the cheap cost of MAC it is worthwhile doing it even if you do
signatures too. A harder question is whether it is worthwhile doing the
signature if you're already doing the MAC.

The clear advantage of not doing the signature is one less exponentiation.
The disadvantage is the loss of properties 3 and 4.
There is no universal trade-off here. (For example, the signature
exponentiation comes as a third exponentiation (after g^x and g^(xy)),
which means that it adds at most 50% to the computation;
this will be significant in some places and not at all in some other).

I believe that what you propose is indeed to do both mechanisms.
(We can discuss the issue of MAC vs encryption later).
You deal with the above computational tradeoff by doing the signature off-line
and giving up on the freshness of the signature itself.
I must say that doing this, together with the off-line signatures containing
an expiration time may represent the right trade-off in many cases.

Finally, I want to argue that it is importnat that we come up
with a scheme that, beyond its default mechanisms, will allow for
tuning the level of security, freshness, etc depending on the specific
parties and scenarios. This would be open to negotiation between the parties
and may range from MAC-only authentication to MAC+signature+nonces.

Comments?

Hugo

PS: all of the above does not say how you do your first exchange with a
party. Such exchange is needed when you do not have a  previous key with
that party, or when you lose that transient key. The latter, can always
be claimed to be the case by an adversary trying to bypass the chaining
mechanism. But this still gives a good opportunity for logging and auditing
these events.