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

Re: RESEND: Thoughts on identity attacks



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> 2. Properties of identities

    VPNC> In certificate-based IPsec, the identities are those that are bound
    VPNC> in each side's certificates. For reasons of history but not
    VPNC> necessity, the identities in these certificates are usually a human
    VPNC> and/or company name, an IP address, a DNS name, or an email
    VPNC> address. However, PKIX certificates can contain any sort of
    VPNC> identity, including opaque blobs, in the subjectAltName using the
    VPNC> otherName or registeredID types.

  I think that there is something else that is important about identities.
  1) we try to make them unique.

  2) we try to use identities which can be looked in some database to
     retrieve the public key.
     (this doesn't mean that you can't load them from trusted store)

    VPNC> 3. Who needs identity protection

    VPNC> In key negotiations, the IP address of each IPsec system is always
    VPNC> known to a passive or active attacker. The identities being
    VPNC> protected by the key negotiation system are those in the
    VPNC> certificates or identification payloads.

    VPNC> Typically, an IPsec system that is at the same IP address over a
    VPNC> long period of time does not need identity protection because an
    VPNC> attacker can use other means (such as traceroute and reverse DNS
    VPNC> lookup) to determine its identity. Identity protection is most
    VPNC> useful to users with dynamic IP addresses, usually users whose IP
    VPNC> address is assigned by DHCP or by a variety of different ISPs.

  3) a system may have numerous identities. 

     People have forgotten this in the windoz-road-warrior<->gateway
     scenarios, but those of building ("real") systems that use IPsec in
     routine process-process scenarios have a multitude of identities
     (i.e. users, servers) that may cause negotiation to occur.
     
    VPNC> The four cases for a negotiation are:

    VPNC> Stationary initiator, stationary responder -- This is typical of
    VPNC> gateway-to-gateway VPNs. Identity protection would not achieve much
    VPNC> here.

  I strongly disagree.

    VPNC> Mobile initiator, stationary responder -- This is a typical
    VPNC> remote-access scenario. Even though the responder's identity can
    VPNC> probably be determined by other means, the initiator can get value
    VPNC> from identity protection.

    VPNC> Stationary initiator, mobile responder -- For the initiator to be
    VPNC> able to find the responder, there must have been some recent prior
    VPNC> contact between the two parties. This could, for example, be a
    VPNC> rekeying of an existing SA. In this case, the responder would want
    VPNC> its identity protected.

  In a peer to peer network, these two scenarios are equivalent, so I'm
not certain I see what we gain by splitting them.

  I can trivially scan dialups (or IETF terminal room laptops) to find
people who will respond on port 500.  Thus, every machine is always
potentially in the situation of being a responder.

  One thing that has been asked for, particularly for gateways that 
can reboot now and then, is for the gateway to remember for a period where
the mobile nodes are and initiate to them again after the reboot. 
  (see "Address inertia" on http://www.quintillion.com/moat/wishlist.html)

    VPNC> Mobile initiator, mobile responder -- For the initiator to be able
    VPNC> to find the responder, there must have been some recent prior
    VPNC> contact between the two parties. This could, for example, be a
    VPNC> rekeying of an existing SA. In this case, each side would want its
    VPNC> identity protected.

  Or, more practically, could be due to a registration in an online game, 
a SIP gateway, the latest instant messaging protocol, etc..

    VPNC> The model in JFK draft 00 (expose the responder's identity in order
    VPNC> to protect the initiator's identity from active attacks) only works
    VPNC> if the initiator never turns into a responder. However, in JFK

    VPNC> Although IKEv1, IKEv2 draft 00, and LBJ expose the initiator's
    VPNC> identity to an active attack, that attack seems unlikely to be
    VPNC> common. The man-in-the-middle would have to be intermittent, and

  Depends upon private key hygiene, and law enforcement regime, but I agree
in principle, that this should be the case.

    VPNC> If the parties in a negotiation are worried about an attack on
    VPNC> their identities, they can use PKIX identities that will give the
    VPNC> attacker little or no information about the real identities. This
    VPNC> sometimes means that the CA that they mutually trust needs to issue
    VPNC> certificates with identities other than the typical ones, but any
    VPNC> reasonable CA system should be able to do this. Further, depending

  The protocols should permit some notion of "rekeying" for identities
within the phase 1 SA. That is, I should be able to use this opaque (but
trusted) identity to start things off, and then offer new identities
afterwards. Whether one permits multiple concurrent identities (attaching
them to individual phase 2 negotiations perhaps) or only a single identity at 
a time, is an engineering tradeoff that needs to be made.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPF9ZU4qHRg3pndX9AQEixgP/UtuQGvj3CZNOlhOOUKi/XEpFbvqsMJK4
t4hleYLopbarUvO3+rfouT8nzfE6BIcRKU6VrwQXdIQbOxZ2CEm444P0rE5k8kzx
7wFKrWvwUEgu2kTUcS7Y0bO5biFKk+j0QL9iz2oD5VQFFjrqp5cko5UsBxiuin8L
2fUymDjIJ5A=
=HpP4
-----END PGP SIGNATURE-----