[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A fix for main mode with preshared keys
Dan,
When I said that the ID_KEY_ID solution only seems to work for keys shared
between two parties, I was referring to ID_KEY_ID with your method for
preventing traffic analysis. Without it, ID_KEY_ID seems like a weak
mechanism for identity protection, especially given that the protocol
includes a DH exchange that allows you to provide proper encryption for the
identities.
The synchonization problem between two parties, when using the method for
preventing traffic analysis, does not require a disk crash. It can also
happen if there is a reboot due to a software error or power failure or
anything else before the latest value of the key has been written out to
secondary storage. This means that whenever there is an uncontrolled
reboot, an operator will have to manually resynchronize *all* the preshared
keys in case one of them has become out of sync.
The redefinition of SKEYID_e described by Hugo solves the problem elegantly. If
adopted, it would also clarify the IKE protocol by removing any need to rely on
source IP addresses in IP packets for identification instead of relying on the
ID payload.
Francisco
______________________________ Reply Separator _________________________________
Subject: Re: A fix for main mode with preshared keys
Author: Non-HP-dharkins (dharkins@network-alchemy.com) at HP-ColSprings,mimegw5
Date: 12/12/99 5:06 PM
ID_KEY_ID is just another way of identifying a pre-shared key. If you
choose to not authenticate the peer and want to have a group pre-shared
key there is nothing inheirent in ID_KEY_ID that would prevent you from
doing this.
There are no syncronization problems with using ID_KEY_ID anymore than
there are with plain identified-by-ip-address pre-shared keys. The
problem came when I described a technique to prevent traffic analysis
(although I think that's not really an issue but it has been raised in
the past as one so I felt I should address it) by hashing the key _after_
authentication. Now the problem Andrew described was something along the
lines of "what happens if my hard drive crashes and I want to restore
my drive without re-syncronizing". But a security protocol is not the place
to address these problems (after all what if you had a disk crash and a
fire in the closet where your tapes were stored! This line of reasoning
could go on forever and after all, backup tapes that contain authentication
information should probably be stored in the central office so
resyncronization with the database is not an issue). On the other hand, if
it's such a worry then don't rehash the ID_KEY_ID; it's not necessary.
But if you can live with the scaling difficulties in pre-shared keys
then you can live with the scaling difficulties of uncertified public
keys and use RSA encryption mode (or El-Gamal encryption mode). You
get ID protection and all the rich negotiation of Main Mode.
Dan.
On Sun, 12 Dec 1999 16:17:01 PST you wrote
>
> Hugo,
>
> I like very much your solution based on redifining SKEYID_e.
>
> Concerning the ID_KEY_ID solution, if I understand it correctly, it works whe
>n
> the key is shared between two parties only. It does not work in the case whe
>re
> it is shared by multiple parties (e.g. all machines in a given domain). And
>in
> the case of two parties, it has the synchronization problems that were pointe
>d
> out by Andrew Krywaniuk. So I think the SKEYD_e solution is much better.
>
> Francisco
Follow-Ups:
References: