[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared Secret mismatch in AM3/MM5
Dan Harkins writes:
> This has come up on the list before and been rejected before. It is
> a fundamental change to a protocol that is just now getting some serious
> analysis. The only justification seems to be the desire to use
> pre-shared key authentication with a dynamicly-assigned IP address.
> This was not justification enought to change things before and nothing
> has changed.
Also doing this change also allows man in the middle always get the
initiator identity before the responder drops the negotiation (or
times out if the man in the middle just stops forwarding the packets
after that).
If the encryption key is only calculated from the Diffie-Hellman
output then the man in the middle can also calculate that and decrypt
the packet containing the identity payload. If the encryption key also
contains the pre-shared-key the man in the middle is not able decrypt
that payload.
For other authentication modes, the public key encryption mode is also
protected by this kind of man in the middle attack, but the public key
signature mode is vulnerable for this attack.
This is really a choice we have to make, do we want pre-shared-key to
be vulnerable for this attack or not?
> On Fri, 29 Oct 1999 15:07:01 EDT you wrote
> >
> > 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)
> >
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: