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