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

RE: Out of Sync Security Policies - Design Flaw



> Andrew,
>
> if you were right, then what is the purpose of multiple SA
> proposals in IKE?
> One proposal would be enough.

Three possible interpretations:

1. The discovered policy could be ambiguous. You need to chose between one
of several possibilities.

2. The sets of transforms that are likely to work are "preshared" in that it
is generally well known which algorithms are likely to work. (e.g. if you're
using anything other than 3DES or AES with MD5 or SHA-1 with commonly used
block sizes and # of rounds and mode of operation and hash output length
then you are unlikely to work with some random host on the net).

As the combinatorics majors known, if two people each randomly draw 3
coloured balls from a sock containing 6 different colours of balls then
there's a good chance that they will have at least one ball colour in
common.

3. This is an example of a case where people are using IKE to perform policy
discovery instead of policy enforcement.

On the other hand, one thing has been proven multiple times now: Don't
assume that there's a good reason for doing something just because it's in
the spec.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.


> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Valery Smyslov
> Sent: Wednesday, November 08, 2000 10:36 PM
> To: andrew.krywaniuk@alcatel.com; 'Kim Edwards'; 'ipsec'
> Subject: Re: Out of Sync Security Policies - Design Flaw
>
>
> ----- Original Message -----
> From: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
> To: 'Kim Edwards' <kimed@nortelnetworks.com>; 'ipsec'
> <ipsec@lists.tislabs.com>
> Sent: Wednesday, November 08, 2000 9:25 PM
> Subject: RE: Out of Sync Security Policies - Design Flaw
>
>
> > I've said this before and I'll say it again.
> >
> > The reason these issues occur is because IKE is (among
> other things) a
> > policy enforcement protocol which some people want to use
> as a policy
> > discovery protocol.
> >
> > The same types of issues come up with the cert request
> payload and, to a
> > lesser extent, exploded SA proposals.
> >
> > Selectors shouldn't need to be negotiated. They should
> either be known to
> > both peers or they should be discovered independently by
> each peer (by
> > taking the intersection of two policy rule sets) and then
> the resulting
> > policy should be enforced by each peer.
> >
> > The purpose of the negotiation phase is merely to confirm
> that both sides
> > arrived independently at the same result. That is the only
> sane way to do
>
> Andrew,
>
> if you were right, then what is the purpose of multiple SA
> proposals in IKE?
> One proposal would be enough.
>
> The fact is that IKE *has* some kind of policy negotiation
> capabilities,
> but they are limited.
>
> Regards,
> Valery.



Follow-Ups: References: