[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: A fix for main mode with preshared keys
Hi all. Three comments.
REDEFINITION OF SKEYID_E:
As I see it, there are two problems:
1) Lack of identity protection in MM w/ preshared-keys.
2) Authentication is not confirmed in this case (such that it's difficult to
distinguish between a key mismatch and an implementation error).
I agree that Hugo's suggested redefinition of SKEYID_e solves both of these
problems. In fact, it's essentially the same as what we discussed a few
months ago.
GENERALIZING ID_KEY_ID:
I didn't say I didn't like the idea of ID_KEY_ID. I do. I just don't think
it should be inextricably tied to the MM/shared case.
Consider the current state of things:
1) MM/shared provides extra keymat entropy but no identity protection.
2) MM/sig provides identity protection against passive attacks.
3) ID_KEY_ID could provide extra keymat entropy and identity protection
against active attacks.
Why the discrepancy? Why not give both authentication methods the property
of having identity protection against passive attacks?
Then, for those of us who are truly paranoid, the ID_KEY_ID mechanism could
be used to be used to provide extra protection with either authentication
technique.
It's the same reason why we wanted XAuth to be a phase 2 exchange, rather
than part of phase 1 -- it allows you to choose the phase 1 authentication
method you want to use, allow with its various strengths, weaknesses and
idiosyncrasies. (Please don't restart the debate on the technical merits of
XAuth -- I only mention this to illustrate how the various stages of
authentication can be logically separated.)
ID_KEY_ID RECOVERY:
Also, I raised concerns about keeping a shared state with no recovery
protection. I'm not just talking about cases where the HD crashes; it is
easier than you think for the two peers to get out of synch.
For example, say that A updates her state after she sends MM5. Then what if
the physical connection is lost and B never receives MM5. Now the state is
unsynchronized and the users cannot communicate.
It doesn't matter if she waits until she receives MM6 before updating the
state because MM6 could just as easily be lost. It's just like the problem
we had with packet retransmission. You can never quite be sure that the
final packet of an exchange has been received.
I would suggest that if ID_KEY_ID is used then a recovery mechanism should
be built in. For example, consider this technique (stateless ID_KEY_ID):
1) The client sends (nonce, hash).
2) The gateway checks if prf(key | nonce, id) == hash for each id in the
list.
3) If prf matches for some id then the negotiation is allowed to proceed.
4) At the end of the negotiation, the client sends next_nonce.
On subsequent negotiations (stateful ID_KEY_ID):
1) The client sends (nonce, hash).
2) The gateway looks for nonce in its hash_table<next_nonce>.
3) If next_nonce matches, the gateway verifies that prf(key | nonce, id) ==
hash
4) If next_nonce does not match, the gateway checks the stateless case.
This provides a built-in recovery mechanism, since a client that forgets its
state (next_nonce) can fall back to using a random nonce. Also, if the
gateway forgets its state, it can still authenticate the client using the
stateless method.
The first negotiation between the peers may use stateful ID_KEY_ID (if the
state has been pre-seeded), stateless ID_KEY_ID (if the gateway has a list
of all client ids), or simply regular main mode (in which case the identity
will be divulged during the first connection but subsequent identity
tracking attempts will fail).
Note that stateless ID_KEY_ID is a DoS threat so the gateway might reject
these connections while it is under heavy load.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: francisco_corella@hp.com [mailto:francisco_corella@hp.com]
> Sent: Monday, December 13, 1999 12:22 AM
> To: dharkins@network-alchemy.com
> Cc: francisco_corella@hp.com; hugo@ee.technion.ac.il;
> ipsec@lists.tislabs.com
> Subject: 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: