[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Shared Secret mismatch in AM3/MM5
Choosing between identity protection and DoS resistance is probably a
necessary constraint of IKE (I can think of solutions but they ain't
pretty).
But I think the point here is that currently implementations are forced to
choose between identity protection and shared secrets. This is not a
necessary constraint.
Implementations wanting DoS resistance should migrate to base mode.
Implementations wanting identity protection really have no option,
currently.
MM w/ shared secrets doesn't really have identity protection. Sure, the id
payload is encrypted, but the shared secret has to be tied to the ip. If the
encrypted identity is something other than the ip, it can't be trusted
because only the ip was authenticated.
The solution, as was already pointed out on this list is to redefine SKEYID
and the signature payloads for shared secrets.
I believe Jianying already suggested:
SKEYID = prf (Ni_b|Nr_b, g^xy) [the same as for signatures]
AUTH_I = prf (pre-shared-key, HASH_I)
AUTH_R = prf (pre-shared-key, HASH_R)
That looks secure to me. Perhaps it could be tweaked a bit for performance.
For example, instead of calling prf twice, we could just use:
HASH_I = prf(SKEYID | pre-shared-key, g^xi | g^xr | CKY-I | CKY-R | SAi_b |
IDii_b )
Anyone else have any suggestions?
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Walker, Jesse [mailto:jesse.walker@intel.com]
> Sent: Friday, October 29, 1999 9:24 AM
> To: 'Jianying Zhou'
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Shared Secret mismatch in AM3/MM5
>
>
> Right. That's why so many implementations rely on aggresive
> mode for remote
> access IPSec hosts. Maybe in the future they will use base
> mode instead, as
> it affords somewhat more flexibility for the remote access case.
>
> -----Original Message-----
> From: Jianying Zhou [mailto:jyzhou@krdl.org.sg]
> Sent: Thursday, October 28, 1999 6:23 PM
> To: Walker, Jesse
> Cc: 'Ricky Charlet'; ipsec@lists.tislabs.com; Andrew Krywaniuk
> Subject: RE: Shared Secret mismatch in AM3/MM5
>
>
> On Thu, 28 Oct 1999, Walker, Jesse wrote:
>
> > Rick,
> >
> > I don't know what the designers were thinking, but consider
> > man-in-the-middle for a minute. In order to defeat it, the IKE
> > authentication proof has to demonstrate the peer's
> knowledge of both the
> > shared secret and the negotiated Diffie-Hellman keying material. The
> design
> > of IKE does this quite effectively by binding the two
> together in a single
> > hash. If you remove the binding, then you reenable
> man-in-the-middle if
> you
> > don't introduce some other means to tie them together.
> >
> > -- Jesse
> >
>
> But that kind of definition of SKEYID excludes nodadic users
> in the main
> mode with pre-shared key for authentication.
>
> Jianying
>
Follow-Ups: