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

Re: Phase 1 IDs ("son of IKE")



> From: "Angelos D. Keromytis" <angelos@coredump.cis.upenn.edu>
>
> Currently, the Responder in a Phase 1 (Main Mode) exchange picks the identity
> to use based on the Initiator's IP address or Phase 1 ID, or uses some default
> value (like the address of the interface the Phase 1 exchange occurs).

The responder could conceivably use any information available, such as
the proposed Phase I protection suite or the time of day.

> What I'd like to suggest is that the Initiator be allowed to send a Responder
> Phase 1 ID payload, which the Responder will use as a hint as to what ID to
> use itself; the Responder can ignore this hint, at the risk of the exchange
> not being completed. The extra code to support this is fairly small (in the
> order of 50 lines, in OpenBSD isakmpd).

This is an interesting suggestion.  The current IKE scheme is the
equivalent of calling a telephone number and saying "Hi, this is Mike,
may I please speak to someone there?" and when the responder says "This
is Joe," hanging up because you really wanted to talk to Bob.  If you
had just asked for Bob in the first place, the responder could have
handed the phone to Bob.

One problem is that the initiator's policy may not express the
desired/allowed remote identity in a simple form that can be conveyed to
the responder.  For example, the initiator's policy may allow a
connection with any remote identity that has a certificate signed by a
particular CA, or with any of a long list of remote identities, or with
a particular value of O= and OU= name components, but any CN= name
component.  The possibilities vary depending on the flexibility of the
initiator's policy language.  Even in the case of a single intended
remote identity, it's possible that the initiator might use an alternate
name for that identity that is not recognized by the responder, but
still be able to recognize and accept the name that the responder would
use in the absence of any "hint".

But if the identity hint was used as an abstract name, rather than the
exact identity that the responder is expected to use, it could be used
as a kind of generic "scope" or "role" identifier.  For example, if the
initiator sends a hint of "internal-vpn.my.org", then a responder with
many local identities could be configured to choose the identity that is
appropriate for use as a gateway to the internal VPN when it sees that
particular hint; for other hints it could be configured to use a more
public identity.

					-=] Ford [=-


Follow-Ups: References: