[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 1 Re-keying Implementation Identification
Dan Harkins writes:
> <commercial advertisement>
> Note that this is the technique used in CRACK. So CRACK will also
> authenticate all optional payloads as well as the outer ISAKMP header.
> </commercial advertisement>
Crack does calculate the HASH almost in the same way, but not quite.
The crack does not include the final packet into the HASH. In crack it
does not matter, because the final packet only includes the SIG
payload so there is no need to authenticate that.
In main mode and aggressive mode the last packet includes all kind of
important payloads, thus it must be added to the HASH. This
makes the HASH calculations here little harder...
> If the attacker changes the responder's selection the exchange will
> fall apart due to the different sides having different attributes of
> the negotiated SA. Either the hash will be different, or the encryption
> algorithm, or the D-H public value, etc. but the exchange should fall
> apart in this case.
Here we ware talking about (one possible way) adding feature
negotiation system inside the SA payload instead of using vendor ID
payloads for that. Because in most cases those features cannot
directly be detected this is problem for that, so this kind of feature
negotiation system is not possible, because of the security reasons.
So we have to invent something else.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: