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

Re: linux-ipsec: Decrypting ID payload in Main Mode w/shared secrets

  I don't understand the need for pre-shared keys in solving the
problem described. You don't want the problems with DNS, certificates,
and patents? OK, don't use certificates, and don't check DNS. Just
create DSA keys bound to some identity (like you bind pre-shared keys
to an identity) and distribute them in the same manner you want to
distribute pre-shared keys. 

  Making and using 4 unauthenticated keys, throwing them away and the
making 4 authenticated keys sounds like a hack. If you're going to
make a hack then do El-Gamal public key encryption using manually
distributed public keys. No certs. No DNS worries. No patents. It also
provides ID protection against an active man-in-the-middle attack.

  I'm also a bit confused about the problem using ID_KEY_ID. As described
by John Gilmore:

   This proposed solution permits eavesdroppers to determine that the same
   person (the same opaque blob) is connecting from a variety of places,
   even if they don't know the "identity" of that person.

That would require large scale traffic analysis to derive this information
and I'm not sure what use can be made of it-- that some opaque blob (the same
person) is connecting from a variety of places. If that's scary in your 
environment than why isn't an active attack against "open secret" scary? 
Yes, the Quick Mode exchange would break down but now this attacker knows
who (the actual identity, not just "the same opaque blob") and where. If
I was running a hit squad that would be valuable intelligence; knowing that
an opaque blob is running around connecting from various POPs would not.

  Dan.

On Tue, 27 Apr 1999 22:31:19 EDT you wrote
> | From: John Gilmore <gnu@toad.com>
> 
> | My suggestion is that the "pre-shared key" used to generate SKEYID for
> | the third exchange in Main Mode (the ID payload and the hash) be set
> | to some generic open secret, unless the parties know a secret specific
> | to their IP addresses.
> 
> I think that this is a reasonable stab at trading a little to get
> support for an unknown IP address.
> 
> This requires each party to know whether the other party knows its IP
> address -- one piece of information beyond what is needed.  Perhaps it
> would be better to allow the sender to use either form of SKEYID and
> require the receiver to try both if it can generate both.  The sender
> can use the universal shared secret if (a) it is not sure that the
> receiver knows its identity from its IP address, and (b) it is willing
> to give up one layer of man-in-the-middle protection.
> 
> This could be generalized to, say, a hierarchy of shared secrets, but
> I think that way lies madness.
> 
> In a sense this is backward compatible.  For the possibly-unknown
case, it doesn't work with old IKEs, but there was no other way that
> would.  For the know-to-be-known case, this is compatible.
> 
> Perhaps a more conservative approach would be to add either a header
> flag or a new exchange type for this.
> 
> Implementors (and others):
> 
> - What have you implemented for this problem?
> 
> - Would you be willing to throw this proposal into your system?
>   Sooner rather than later?
> 
> - Is there another approach that you find more appealling?
> 
> We want to solve this problem AND interoperate.
> 
> Hugh Redelmeier
> hugh@mimosa.com  voice: +1 416 482-8253
>
Follow-Ups: References: