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

Re: Comments on draft-ietf-ipsec-ike-01.txt

Jianying Zhou writes:
> There was a security flaw in RFC 2409. 
> When SAi_b is used in HASH_I and HASH_R, an attack is possible so that 
> at the end of Phase 1 negotiation, the SA being negotiated may not be
> authenticated. (The problem also exists in the new draft.)
> To avoid the attack, simply replace SAi_b with SAr_b.

Changing SAi_B to SAr_b would open another problem. In that case
attacker can modify the SA proposal sent by the initiator and remove
proposal that he doesn't like from the list and neither side will
detect anything.

Lets take an example where both ends are configured to prefer 3des.
They also accept des as a second choice if the other end doesn't
support anything else (say there are some old systems out that only
support des).

Now even if both of them support 3des, attacker can modify the
proposal sent by the initiator and remove 3des from the proposal.
Responder doesn't notice anything and it will just select the des that
was included in the proposal (it just assumes the other end is one of
those old implementations only supporting des). Initiator will not
detect anything it will just assume the responder is only supporting
des. This is not what was really wanted...

In the current case the attacker can change some things inside the
proposal, but the SAr_b must be one of the transforms from the
original SAi_b (the initiator will reject it if it isn't). Also if the
attacker selects different transform from the initiators list it
is detected in most cases (because initiator and responder are using
different parameters).

Here is a list of the possible changes (by attribute class) and how
they are detected:

	1) Encryption algorithm: Decryption of isakmp packet fails
	2) Hash algorithm: Hash calculation fails
	3) Authentication method: Decryption of isakmp packet fails,
	   because encryption keys are calculated differently.
	4-10) Group description or parameters: Diffie-Hellman will give
	   different results, thus causing decryption of isakmp packet
	   to fail.
	11-12) Life duration: This will not be detected, so both ends will
	   use different values, but that is not fatal, nor it should
	   not cause security problems.
	13) PRF: Hash calculation fails.
	14) Key length: Decryption of isakmp packet fails
	15-16) Field size/group order: see group parameters
	17) Block size: Decryption of isakmp packet fails

So the only change that is not detected inside the ike (or the first
quick mode packet if using aggressive mode) is the change in life
times. If both ends send out delete notifications even that doesn't
cause real problems.

> (The full paper is available by request.)

I would really like to see that paper. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: