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

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



Jianying Zhou writes:
> > 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. 

With weaker (but allowed) cipher than was requested. I think this is
much bigger attack than ability to change life times. 

> 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?

The site which did get lower lifetime, will send delete notification
to the other end, and that end will delete the SA at the same time.

> 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.

If the attacker can break keys during any lifetime proposed by the
initiator, initiator has security problems anyways. I don't really
think this will be real problem. 

> A more secure solution is to include both SAi_b and SAr_b in HASH_I
> and HASH_R.

That would be one way to fix this problem. Anyways I don't think this
is serious enough problem to modify IKE 1.0 protocol now. We can fix
this and other problems later when we start thinking about next
version of IKE.

BTW, this (and other problems) have been pointed out by me in the
ipsec-list earlier (Message-Id: <199809062326.CAA29797@torni.ssh.fi>),
and that mail was sent to the key people of the ipsec working group at
9th of April 1998. The security problems described in that email
waren't serious enough to delay IKE 1.0 at time, and I don't think
they are any more serious now. 
-- 
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: