RE: "Me Tarzan, You Jane" in IKEv2-05

["Geoffrey Huang" <ghuang@cisco.com>]

I agree with Dan Harkins' previous comment that the responder can pick
how to authenticate itself based on the initiator's identity.  Since
both the IDi and the optional IDr come at the same time, I don't see how
including the optional payload buys you anything.

The difference between IKE and SSL is that SSL doesn't use the identity
of the "initiator" to demux its own possible identities.

A related question I have is what happens if the responder sends an
identity that's different from the IDr requested by the initiator?

-g

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of 
> Charlie_Kaufman@notesdev.ibm.com
> Sent: Monday, March 03, 2003 6:50 PM
> To: ipsec@lists.tislabs.com
> Subject: Re: "Me Tarzan, You Jane" in IKEv2-05
> 
> 
> 
> 
> 
> 
> I think in the discussion of this feature, there has been 
> some confusion
> concerning what it's for and what endpoints MUST, SHOULD, and 
> MAY do to
> follow the spec.
> 
> The sole addition to the protocol is that the initiator MAY 
> in Message 3
> include the DNS name of the node he's trying to connect to. 
> The responder
> MUST ignore the value supplied unless he has multiple 
> identities by which
> he can authenticate, in which case he SHOULD select an 
> identity based on
> the supplied DNS name. So most implementations of responders 
> will ignore
> the value and most implementations of initiators will either 
> not supply it
> or will drop in a DNS name.
> 
> The motivation for this feature springs from a problem 
> commonly experienced
> with HTTP over SSL. It is fairly common for "vanity" web sites like
> www.batmanforever.com (which existed when the movie came out 
> and may still)
> to be hosted on a machine that hosts a lot of other web 
> sites. In the early
> days, this was implemented by having a whole range of IP 
> addresses routed
> to the one server, and that server would decide which content 
> to send you
> according to the IP address to which the request was 
> directed. This became
> sufficiently wasteful of scarce IPv4 addresses and HTTP was 
> modified to
> optionally include the DNS name of the web site in the 
> request so that the
> vanity web sites sharing a server could also share an IP address. But
> today, this solution is not available to web sites that use 
> SSL, because
> the SSL server has to authenticate before it gets the HTTP 
> request. So they
> continue to require a separate IP address for each virtual server they
> host.
> 
> By putting this extra field in Message 3, an implementation 
> could have a
> single IP address but many DNS names and authenticate as 
> being the node the
> initiator was trying to talk to. It would be good practice 
> for initiators
> that are looking up the responder by DNS name to include the 
> name in case
> the responder is so configured.
> 
>           --Charlie
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or 
> otherwise).
> 
>