[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thoughts on identity attacks
Greetings again. Some users want to have their identities hidden when
they use IPsec because they do not want an attacker to know with whom
they are communicating. This is a summary discussion from the mailing
list, the WG sessions in Salt Lake City, and side conversations.
1. Attacks to get identities
There are two types of attacks that can mounted to find out the
identity of one or both of the parties in a key exchange protocol:
- Passive attacks look for identities that passed in the clear during
the negotiation. In a passive attack, neither party can detect that
the identity is being seen.
- Active attacks find identities by being a man-in-the-middle or by
replacing the responder in the negotiation. The attacker proceeds
through the key negotiation with the attackee until the attackee has
revealed its identity. In a well-designed system, the negotiation
will fail after the attackee has revealed its identity because the
attacker cannot spoof the identity of the originally-intended system.
The attackee might then suspect that there was an attack because the
other side failed before it gave its identity. Therefore, an active
attack cannot be persistent because it would prevent all legitimate
access to the desired IPsec system.
2. Properties of identities
In certificate-based IPsec, the identities are those that are bound
in each side's certificates. For reasons of history but not
necessity, the identities in these certificates are usually a human
and/or company name, an IP address, a DNS name, or an email address.
However, PKIX certificates can contain any sort of identity,
including opaque blobs, in the subjectAltName using the otherName or
registeredID types.
3. Who needs identity protection
In key negotiations, the IP address of each IPsec system is always
known to a passive or active attacker. The identities being protected
by the key negotiation system are those in the certificates or
identification payloads.
Typically, an IPsec system that is at the same IP address over a long
period of time does not need identity protection because an attacker
can use other means (such as traceroute and reverse DNS lookup) to
determine its identity. Identity protection is most useful to users
with dynamic IP addresses, usually users whose IP address is assigned
by DHCP or by a variety of different ISPs.
The four cases for a negotiation are:
Stationary initiator, stationary responder -- This is typical of
gateway-to-gateway VPNs. Identity protection would not achieve much
here.
Mobile initiator, stationary responder -- This is a typical
remote-access scenario. Even though the responder's identity can
probably be determined by other means, the initiator can get value
from identity protection.
Stationary initiator, mobile responder -- For the initiator to be
able to find the responder, there must have been some recent prior
contact between the two parties. This could, for example, be a
rekeying of an existing SA. In this case, the responder would want
its identity protected.
Mobile initiator, mobile responder -- For the initiator to be able to
find the responder, there must have been some recent prior contact
between the two parties. This could, for example, be a rekeying of an
existing SA. In this case, each side would want its identity
protected.
4. Identity protection in the current proposals
The following describes IKE and the different proposals for its successors.
IKEv1, IKEv2 draft 00, and LBJ (a proposal briefly made by Angelos in
Salt Lake City that will be an option in JFK draft 01) all have the
same properties. There is no passive attack possible, and an active
attack is possible against the initiator's identity. Such an attack
will reveal the identity but will cause the negotiation to fail in
the next message.
In JFK draft 00, there is a passive attack on the responder's
identity, but no active attack possible on the initiator.
SIGMA has proposals that match each of the above two identity protections.
5. Personal observations
The model in JFK draft 00 (expose the responder's identity in order
to protect the initiator's identity from active attacks) only works
if the initiator never turns into a responder. However, in JFK draft
00, there is a strong chance that the original responder will want to
rekey the SA, at which point the original initiator will have to
expose its identity. The only ways around this are to change the
protocol to never allow the original responder to rekey (very bad
from a security policy standpoint), or to add some mechanism whereby
the two parties can agree to who will reveal their identity first
(bad from a complexity standpoint).
Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's
identity to an active attack, that attack seems unlikely to be
common. The man-in-the-middle would have to be intermittent, and even
then would raise suspicion every time the attack was successful.
These solutions also solve the "original responder rekeys first"
problem of JFK draft 00. Further, when talking to someone who hasn't
investigated identity attacks, it is much easier to explain "no
passive attacks" than it is to explain "a passive attack against one
of the two parties is OK because the other party gets better
protection".
If the parties in a negotiation are worried about an attack on their
identities, they can use PKIX identities that will give the attacker
little or no information about the real identities. This sometimes
means that the CA that they mutually trust needs to issue
certificates with identities other than the typical ones, but any
reasonable CA system should be able to do this. Further, depending on
the level of worry, the parties can get new certificates with new
identities as often as they wish (or as often as their
mutually-trusted CA can handle).