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

[Dan Harkins <dharkins@tibernian.com>]

  If a contrived use of porn is the "high volume scenario" for this
feature then I think my observation that this feature will never be
used has been strongly validated.

  We don't need to add features to this protocol that will never
be used because these "options" must all be implemented by all
compliant implementations even though the features will never be
used. More cruft, more spagetti code, more possibility of mistakes,
more mandatory "options". More of the stuff we are supposed to get
rid of with IKEv2.

  Dan.  

On Sat, 15 Mar 2003 18:43:03 EST you wrote
> 
> "Geoffrey Huang" <ghuang@cisco.com> wrote:
> > 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.
> >
> SSL can't use the identity of the initiator to demux its own possible
> identities because the responder gives its name first. IKE could use
> the initiator's identity to decide what name to respond as, but this
> assumes that each initiator would only ever want to talk to a single
> responder identity at the shared IP address. Suppose there are a few
> dozen porn sites (i.e. different site names) all at a single IP address.
> You have to connect to them over an encrypted channel because they
> take credit card numbers, but they can't use SSL because they send
> streaming video over UDP. A single user might want to connect to
> multiple of these sites - not knowing (or caring) that they are
> colocated. The operator of the server would like to disguise - at
> least to a limited degree - the fact that the services are colocated
> (say - to provide the illusion of variety), but doesn't want to waste
> IP addresses. In this case the server can't tell
> from the initiator name which virtual server is being accessed.
> 
> There are probably more respectable uses for this protocol, but this
> sadly may be the high volume scenario.
> 
> 
> > A related question I have is what happens if the responder sends an
> > identity that's different from the IDr requested by the initiator?
> 
> The responder is free to ignore the IDr; the initiator has to decide
> whether the provided identity is acceptable. Or it could reject the
> connection if it didn't think its identity is going to be acceptable.
> 
>           --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).
>