Re: RESEND: Thoughts on identity attacks

["Scott G. Kelly" <skelly@SonicWALL.com>]

A few comments interspersed below...

Michael Richardson wrote:
<trimmed...> 
>     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.

Precisely - an IKE implementation may use different identities for
different flows, and I don't think the fact not many fielded vpn
implementations currently support this should be used as proof that this
capability is not important.

<more trimmed...>

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

I think I agree, but upon re-reading, I'm not sure that what I think I
understand is what you actually mean. I think the current IPsec spec has
hooks for this via the phase 2 ID payloads. That is, it is conceivable
that a given phase 1 identity is "authorized" to represent one or more
phase 2 identities (which may be presented in phase 2 ID payloads). Is
this the capability you are after, or are you referring to something
else?

Scott