[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IKE problem?
Scott G. Kelly writes:
> At last week's IETF meeting(s) there were several references to "Tero's
> IKE problem", but I never heard the specifics on this. Can anyone fill
> me in on this?
Here is the mail I sent to some people just after the Los Angeles IETF
meeting.
----------------------------------------------------------------------
From: Tero Kivinen <kivinen@ssh.fi>
To: dharkins@cisco.com, carrel@ipsec.org, ddp@network-alchemy.com,
cmadson@cisco.com, rgm@icsa.net, tytso@MIT.EDU, rodney@sabletech.com
CC: wdm@tycho.ncsc.mil, mss@tycho.ncsc.mil, mjs@terisa.com,
jeff.turner@raba.com, ylo@ssh.fi (Tatu Ylonen),
tmo@ssh.fi (Tero Mononen), mcr@ssh.fi,
Subject: Some (not so serious) security problems in the IKE auth HASH.
Organization: SSH Communications Security Oy
In the Los Angeles IETF I noticed some small problems with the
authentication hash used in the IKE protocol. I don't think these
problems are serious enough to change the actual draft, but I just
want to inform you about these, so if we are going to change something
in the IKE we may want also to fix these problems (all of these
attacks require active attack in the wire).
Currently the authentication hash is calculated like this:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
The problem is that this authentication doesn't cover all of the
information in the packets. Things that might have relevance and that
are left out of the hash are:
1) ISAKMP major version number
2) ISAKMP minor version number
3) Flags (Commit bit)
4) Selected SA lifetimes
5) Certificate payloads
6) Certificate requests payloads
7) Vendor id payloads
8) Notification payloads (initial contact)
1, 2) ISAKMP major and minor version number
I think very serious issue is the missing major and minor version
numbers. This means that after we have newer version of IKE the
attacker can change the initiators version numbers to 1.0 and force
responder to use that older version of IKE. This might have security
problems later depending why the 1.1 or 2.0 version of IKE was needed.
3) Flags (Commit bit)
The flags field has commit bit flag and using that attacker can cause
yet another kind of denial of service attack. In this attack the
attacker will modify the host A packets to host B and set commit bit
in those. After the negotiation has finished the host B will wait the
CONNECTED notification from host A before it can send any packets to
host A. Because the host A has't not actuallyrequested that it will
not send it, thus the host B will timeout after some time and abort
the negotiation.
If the host B happens to be initiator it cannot start the quick mode
before it receives the CONNECTED notification so the suggestion in the
draft how to find out if the last message was lost doesn't apply.
The thing that makes this different from other DoS-attacks is that the
host A thinks it has valid ISAKMP SA, but the host B doesn't think so.
This way the host A's ISAKMP SA table gets full of SA's that are not
valid in the other end.
4) Selected SA lifetimes
The selected SA sent by the responder is not authenticated in any
other way that it must match the one send by initiator and also some
parts of it is implictly checked when the ISAKMP SA is using the
values of it (encryption and hash algorithms etc). For example the
life times are not implictly checked in the process.
So if the initiator sends out proposals:
1) DES, MD5, pre-shared, group 1, life seconds = 3600
2) DES, MD5, pre-shared, group 1, life seconds = 600
and the responder selects the first proposal, the attacker can change
that to second by just modifying the SA payload sent by the responder.
This will not be detected because different values of life time
doesn't cause any failures in the negotiation process.
If we later add some more isakmp attributes that are not implicitly
checked they can also be modified as long as the initiator sends
proposal that has different values for the given attribute.
5, 6) Certificate and Certificate requests payloads
I don't think this is really a problem because validity of certificate
is always checked before they are used, and certificate requests are
just requests, if the other end cannot provide certificate for some ca
then it cannot.
7) Vendor id payloads
So the attacker can force the other end (A)to use some extensions that
the other end (B) didn't requested, and if those extensions or
backward compatibility stuff causes some security problems the
attacker might succeeded doing something nasty. This requires that
vendor has some old compatibility code for some broken implementation
(of their own?) that has security problems in the protocol... I don't
think this is an real issue.
8) Notification payloads (initial contact)
This I think is the most serious of all the issues, because it makes
the initial contact notify almost useless, as we cannot trust it in
phase I at all if we are using aggressive mode (anyone can add any
notify payload it pleases to aggressive mode exchanges, because they
are not encrypted nor authenticated).
Attacker can also modify the contents of notify payloads in the last
packet of the main mode exchange even if it is encrypted, because it
just has to know the location of notification payload and it can for
example change its contents to invalid.
Summary
I was talking about this in the IETF with Cheryl, and I think that if
we want to fix these, the easiest fix would be to change those HASHes
to be the hash of all the packets received/sent so far (including all
generic payload headers, message header etc), and the current packet.
The contents of packets are taken in their plain unencrypted form
(just before encryption or just after decryption (if we are using
public key encryption then we are still hashing the rsa encrypted
forms of payloads)) and in the order they are sent/received (the order
of the packets in the wire). When calculating the hash of last packet
the SIG/HASH payload is filled with zeros.
I think we cannot change anything at this late point, but if we ever
are going to revise the IKE draft we might want to fix some of these
problems. We might also want to add something about these to the
security considerations section in the draft(s).
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/