RE: RESEND: Thoughts on identity attacks

["Khaja E. Ahmed" <khaja.ahmed@attbi.com>]

Paul,

Perhaps the fact that there were no responses suggests that not enough
people think it is important.  Let me introduce a counter view.  I not only
think it is not important but I think that pursuit of this goal risks
further complicating an already too complicated protocol.  I really think
our energies are best directed at more important issues.

After a year of discussions on requirements with product management of all
the big VPN manufacturers, I have never even once heard that identity
protection or 'obfuscated identities' are a requirement.  Of course as the
chair of the VPNC you may know much more about these matters and I would be
delighted if you or someone could point me at data that suggests that this
is a requirement among manufacturers and/or the user community.

My concern is that this requirement comes out of our own knowledge of what
good security practices should be - however far removed from current
practices they are.  Is it unreasonable to ask that what we know as good
security practices be reconciled with the ability of the user community to
employ and the manufacturers to support?  Can't some kind of a balance be
struck?  The risk if we proceed with this feature is that it may get tested
and have a couple of 'reference implementations built but will never be used
in any reasonable sized deployment.  We will have satisfied our academic and
research interests but will not have produced a thing widely used/usable.
In fact we may have complicated the overall solution and made it's adoption
even harder.

I think most companies find PKI itself too complicated.  Both VPN solution
providers and large users seem to prefer to stick with shared passwords
rather than build support for or manage a PKI.  Things like PKIX compliant
path validation, CRL / OCSP support, certificate life cycle management,
enrollment, etc. scare away all but the most intrepid.  At this point I
would NOT recommend adding any more features and would only consider
removing/simplifying some.  After there is a large population of users we
can learn from actual security breaches and address security concerns that
arise - as they arise - in future enhancements to the protocol.


Khaja
===============================
Khaja E. Ahmed
khaja.ahmed@cavium.com
khaja.ahmed@attbi.com
================================

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Monday, February 04, 2002 1:53 PM
> To: ipsec@lists.tislabs.com
> Subject: RESEND: Thoughts on identity attacks
>
>
> [[ This message got a total of zero responses. Hopefully, people
> consider the type of identity protection given in SuccessorToIKE to
> be important. If it isn't important, we should start talking about
> the other issues that are. ]]
>
> 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).
>
> --Paul Hoffman, Director
> --VPN Consortium