[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: