[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SOI: identity protection and DOS
On Mon, 3 Dec 2001, Andrew Krywaniuk wrote:
> > I never said that the sig mode of IKE was inadequately secure.
> > I did mention the advantage of pre-shared mode against possible
> > break of a DH group in the future. The fact that pre-shared mode is
> > (much) better in this sense does not mean that people should consider
> > the sig mode "inadequately secure".
>
> When somebody changes something, I take that to mean that what was there
> before was inadequate.
I am confused. Which change and which "somebody" are you talking about?
>
>
> > Moreover, I already said many times, and "implemented" this idea in my
> > P-SIGMA proposal, that the problem of having to rely on the
> > IP address for
> > identifying the shared-key is easily solvable through
> > an ID payload of type ID_KEY_ID (this was also the motivation to
> > introduce this type several years ago).
> > In P-SIGMA this is done via the OIDi field.
> > Using this you get PFS and protection against active attacks
> > for BOTH peers (which is impossible to achieve under
> > any signature mode).
> >
> > Actually, even in IKE as it is now, where the OID mechanism
> > is missing,
> > one could have used the cookies in the header to identify
> > shared keys in
> > the keys database. Any idea, why people did not do that?
>
>
> The problem with the ID_KEY_ID is that it would require extra per host
> configuration to setup the fake ids and the fake ids still correlate to a
> real id. I guess the protocol to change the ids on each login and to keep
> the peers synchronized is complicated enough that no one though it was worth
> implementing.
There is no configuration issue involved (except maybe if you talk
about manual installation which is already a high-cost management
issue). As for correlation, I can imaging that MOST people will
not care about that. And for those, that care, doing chaining is not such
a big deal. It is quite equivalent to the management of sequence number
windows for phase 2 in IKEv2, except that you need to maintain a
number of key identifiers as the window size.
The good thing about these chained identifiers is that they require no
set-up, no management, no interaction and they solve FOR FREE the DoS
issue. Ah... and it gives active protection to BOTH iniitator
and responder! (Actually, now that I think of it they are really nice :)
>
> As for using the cookies for yet another purpose, maybe people felt that
> they had been abused enough already...
As opposed to many other abuses of cookies, this is not a real
"abuse". The real functionality of cookies in IKE is as
session-identifiers. Using them as key identifiers is not very different.
BTW, if I understand correctly the description of phase 2 in IKEv2 they
DO use the cookies in the header to point to the "phase 1 shared secret".
ANd, franky, I still have no clue why people didn't use the KEY-ID or
cookie solution? Anyway, this is a somewhat theoretical question, since we
are going to change IKE anyway.
Hugo
>
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
>
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Hugo Krawczyk
> > Sent: Wednesday, November 28, 2001 4:21 PM
> > To: Andrew Krywaniuk
> > Cc: IPsec WG
> > Subject: RE: SOI: identity protection and DOS
> >
> >
> > Andrew, see below for a clarification...
> >
> > On Tue, 27 Nov 2001, Andrew Krywaniuk wrote:
> >
> > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the
> > > > use of preshared
> > > > >keys in general.
> > > >
> > > > Yup. Some people think that identity protection is
> > absolutely needed
> > > > in every circumstance, but most people would agree that identity
> > > > protection isn't worth preventing pre-shared secrets from working
> > > > with mobile users.
> > >
> > > Well, my point was more that there isn't a conflict between
> > preshared keys
> > > and identity protection (of the passive variety). If the
> > PSK & PKsig SKEYID
> > > derivations in IKEv1 had been the same (as they could have
> > been), this
> > > argument would have never come up.
> > >
> > > As some may recall, Hugo originally argued that the PKsig
> > authentication
> > > method was inadequately secure because its strength was
> > based solely on the
> > > strength of the DH algorithm. The SKEYID for PSK was based
> > on the DH value +
> > > a secret value. Therefore, the decision to define the
> > SKEYID this way was
> > > merely a design tradeoff of identity protection for
> > increased security. As
> > > we noted in draft-improveike (and elsewhere), this tradeoff was not
> > > necessary since an alternate SKEYID derivation could have
> > given us both
> > > properties.
> >
> > I never said that the sig mode of IKE was inadequately secure.
> > I did mention the advantage of pre-shared mode against possible
> > break of a DH group in the future. The fact that pre-shared mode is
> > (much) better in this sense does not mean that people should consider
> > the sig mode "inadequately secure".
> >
> > Moreover, I already said many times, and "implemented" this idea in my
> > P-SIGMA proposal, that the problem of having to rely on the
> > IP address for
> > identifying the shared-key is easily solvable through
> > an ID payload of type ID_KEY_ID (this was also the motivation to
> > introduce this type several years ago).
> > In P-SIGMA this is done via the OIDi field.
> > Using this you get PFS and protection against active attacks
> > for BOTH peers (which is impossible to achieve under
> > any signature mode).
> >
> > Actually, even in IKE as it is now, where the OID mechanism
> > is missing,
> > one could have used the cookies in the header to identify
> > shared keys in
> > the keys database. Any idea, why people did not do that?
> >
> > Hugo
> >
> >
> >
>
>
References: