[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt
On Wed, 23 Jun 1999, Tero Kivinen wrote:
> 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...
>
I agree. But anyway, both ends get the authenticated SA at the end of
Phase 1 negotiation.
> 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.
>
Yes, the change of SA lifetime cannnot be detected in an attack.
How will a delete notification be sent out if either side does not
detect the attack?
Suppose the initiator's SA has a longer lifetime than the responder's
SA. Suppose the keys have compromised after the responder's SA expires
but before the initiator's SA expires. An attacker can masquerade as the
responder in a communication session.
A more secure solution is to include both SAi_b and SAr_b in HASH_I
and HASH_R.
Jianying
Follow-Ups:
References: