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

RE: SOI: identity protection and DOS

> 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.


> 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.

As for using the cookies for yet another purpose, maybe people felt that
they had been abused enough already...

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
>
>
>
Follow-Ups: