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

From: [email-masked]
Date: Mon, 3 Mar 2003 21:50:06 -0500

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

---

From: "Geoffrey Huang" <[email-masked]>
Date: Thu, 13 Mar 2003 11:59:59 -0800

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, March 03, 2003 6:50 PM
> To: [email-masked]
> Subject: Re: "Me Tarzan, You Jane" in IKEv2-05
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Sat, 15 Mar 2003 18:43:03 -0500

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

> 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

---

From: Dan Harkins <[email-masked]>
Date: Sun, 16 Mar 2003 23:56:07 -0800

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2003 08:59:42 -0800

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
    Dan>   If a contrived use of porn is the "high volume scenario" for this

  How many times do I have to explain this?

  The average multi-user systems needs this so that it can do process to
process tunnels with real credentials. 

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

---

From: "Geoffrey Huang" <[email-masked]>
Date: Mon, 17 Mar 2003 11:06:32 -0800

> process tunnels with real credentials. 

Interesting, but I'm still convinced that the responder can use the
initiator's identity to determine how to respond.  I'm not certain how a
process-to-process tunnel would look exactly, though.

-g

> ] [email-masked] 
> http://www.sandelman.ottawa.on.ca/ |device > driver[
> ] 
> panic("Just another Debian GNU/Linux using, kernel hacking, 
> security guy"); [
>

---

From: Henry Spencer <[email-masked]>
Date: Mon, 17 Mar 2003 14:48:10 -0500 (EST)

On Mon, 17 Mar 2003, Geoffrey Huang wrote:
> initiator's identity to determine how to respond.

How does knowing the initiator tell you who he wishes to connect to?
A server may well provide more than one service, and hence wish to be
known under more than one identity.

As others have pointed out, the HTTP people initially made the mistake of
assuming that the IP destination address was sufficient identification of
the connection's target, and ended up deeply regretting it.  The result
has been a lot of unnecessary consumption of IP address space to provide
servers with many IP addresses, something we definitely don't want to
encourage further. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2003 15:56:38 -0800

>>>>> "Geoffrey" == Geoffrey Huang <[email-masked]> writes:
    Geoffrey> I agree with Dan Harkins' previous comment that the responder
    Geoffrey> can pick how to authenticate itself based on the initiator's
    Geoffrey> identity.  Since both the IDi and the optional IDr come at the

  No, it can not. 
  The responder can only do this is it has a specific policy configured for
that particular ID. Maybe the very policy poor VPN systems that current
vendors configure this is possible. 
  There are lots of messages explaining other scenarios that have been
posted in the original thread on this, back in January.

  There are other deployment scenarios where the policy is created on the
fly, and the IDi may not have any pre-configured meaning to the
responder. The initiator needs to indicate to whom it wishes to connect to.

  We (the IETF) got this right with SMTP - Envelope from/to and header
from/to. We got it wrong with IKEv1.

see: http://www.sandelman.ca/ipsec/2002/12/msg00249.html

---

From: "Geoffrey Huang" <[email-masked]>
Date: Mon, 17 Mar 2003 15:58:15 -0800

> known under more than one identity.

Granted, it depends on the type of identity presented.  But if you're
using something like user@fqdn type, ID_KEY_ID or even a cert DN, the
gateway can use that to demux what service you want to talk to.  If I'm
ghuang@cisco, the gateway knows that I wouldn't be connecting to
were-not-cisco.com.

> servers with many IP addresses, something we definitely don't want to

As long as it's clear what to do in weird cases (e.g., the responder
ignores the IDr payload, etc.) I'm not bothered.

-g

---

From: Henry Spencer <[email-masked]>
Date: Mon, 17 Mar 2003 19:31:29 -0500 (EST)

> ghuang@cisco, the gateway knows that I wouldn't be connecting to

What this amounts to, I'm afraid, is saying that in some ad-hoc way,
people can subdivide the initiator identity into two subfields, the real
identity of the initiator and some indication of who he wants to talk to. 
(They aren't necessarily related, even with the aid of configuration data
on the responder end, except in restricted applications where all possible
network connections are preconfigured.)

To be blunt, saying "well, you can usually sort of intuit the target,
somehow, based on the initiator's identity" is a total botch.  Two
separate items of information ought to be carried in two separate
packages, so there is a *standard* way to separate them. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2003 16:52:30 -0800

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

>>>>> "Geoffrey" == Geoffrey Huang <[email-masked]> writes:
    Geoffrey> Interesting, but I'm still convinced that the responder can use
    Geoffrey> the initiator's identity to determine how to respond.  I'm not
    Geoffrey> certain how a process-to-process tunnel would look exactly,
    Geoffrey> though. 

  Please explain to me how the responder can do this.

  My telnet process will say, quite simply, to the kernel:

  My ID  = [email-masked]
  YourID = [email-masked]

  (To login to the "sales" account that I have)

  Using ME-tarzan/You-Jane, my IKE would say:

  ME =[email-masked]
  YOU=[email-masked]

  Without ME-Tarzan/You-Jane, the IKE would say:

  ME=[email-masked]

  How does the responder pick the right private key to respond with?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2003 19:50:21 -0800

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

Since Dan doesn't find streaming media to be a good enough reason for
Me-Tarzan/You-Jane, I'll provide an example of using Me-Tarzan/You-Jane
to aid in key-rollover. Recall that the "You-Jane" part provides both the ID
that the initiator was expecting to talk to, but also a reference to the
public key, and optionally, the public key as well.

{Dan, please go visit the HTTP load-balancing vendors and ask them how well
they support SSL, and you'll understand why there might in fact me hundreds
of streaming sites being served as a single IP, yet with multiple keysets
involved. And... go ask the Apache people how where a lot of the money for
the people funded to work on Apache comes from}

Postulate a key distribution system with replication and caches. DNS(sec)
CERTAINLY fits this model, as does replicated LDAP.

The key characteristic is that the caches have no reason to go look for new
information until the time to live on the existing information is
over. Further, replicated servers are not updated instantly, and may not
even know there is an update until some period of time has passed and they
decide to look. (DNS Notify are hints to look now! They can get lost)

To make conversation easiest, let's assume that the characteristic time
for the system is 1 day. I.e. if I make a change, now I can reliably be
certain it will spread everywhere in 1 day. It *MAY* spread faster than
that. 

Assume that I am the responder ("Jane").

So, there are two methods to roll one's keys in the presence of a replicated
database. This is not an emergency roll-over - we can discuss that later.

1) publish the key that I will use tomorrow, today. That guarantees
   that everyone out there will have it when I start using it.

2) always sign everything with all keys that I've published.

If I've planned everything ahead of time, then I've marked the old key
as expiring at midnight (in a conveninent timezone) today. I've also marked
the new key as not being valid until midnight today. This means that all of
the peers that I communicate with had better be able to get the new key at
precisely the right time. Otherwise, they go offline.

If I try to be smart and make the validity periods overlap, then there is
no real reason for a peer to look for a new key until the old one is no good.
(CRLs help here, but DNSSEC certainly doesn't provide them)

So, during the overlap, I will have some peers who want to connect to me
and will assume that I have switched to the new key, and some that have
not yet seen the new key, and will use the old key. I'm left with the
question: which one do I sign with?   Me-Tarzan/You-Jane lets the peer
tell me what they expected, so that I can make them happy.

You now say, well, if the peer will just look periodically for new keys
and then not use the new key until the old is expired. The problem is that
there is really no way to do an emergency roll-over if a key is compromised -
the clients will not use the new key until the old one expires.

This DEFINITELY occurs with DNSSEC borne keys. FreeS/WAN has been using 
such keys for some years now, and we have experienced *EXACTLY* this in
IKEv1.

---

From: [email-masked]
Date: Tue, 18 Mar 2003 09:16:23 -0800

How does the responder pick the right private key? You haven't
said how "[email-masked]" is uniquely bound to a key in the
first place. For the standard way of binding identities to keys you
can use the standard way of conveying this information-- a CERT_REQUEST
payload with DN equal to the issuer of the certificate whose DN contains
[email-masked] and whose public key corresponds to the
private key you want the responder to use.

  If you're not using some standard way of binding opaque strings
(that may *look* like email names but are not necessarily) then
you can use a proprietary method to convey the necessary information
for your proprietary scheme. Use a private use payload with the
generic header and _do not set the critical bit_. 

  But you don't need to force everyone to implement a mechanism
that will not be used just so you can do some proprietary key
binding scheme between yourselves.

  Dan.

On Mon, 17 Mar 2003 16:52:30 PST you wrote
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPnZtzIqHRg3pndX9AQHTPgQA2WOw07CC8s2KU24n3cYCz497Q3heHyax
> 9wP3iQ6JVHYdmSSTUKCLH5iM5GbuKfR+aLXs5Ky7jrF8oR6Jdo9+jBX1y0ZalqLq
> ZcwbdHzI8ci8mB1BEKJfd9k71yaMoMHoQcqOgM4zZDk64itjTH0C4i2fZmCDf04Z
> IP42w1Xn6XY=
> =/HdE
> -----END PGP SIGNATURE-----

---

From: [email-masked]
Date: Tue, 18 Mar 2003 09:52:56 -0800

On Mon, 17 Mar 2003 19:50:21 PST you wrote
> public key, and optionally, the public key as well.

No, I don't recall that! In fact, this is the ENTIRE DEFINITION of the
"Me Tarzan/You Jane" feature in ikev2-05:

	The optional payload IDr enables Alice to specify which of 
	Bob's identities she wants to talk to. This is useful when
	Bob is hosting multiple identities at the same IP address.

There is no reference to a public key and no option to actually place
a public key in an ID payload. 

In fact there is not even any description of what such an identity
should contain. ID_IPV4_ADDR? Probably not but given the amount of
grief I got over how underspecified IKEv1 was ("You didn't state what
the behavior should be if you get a VENDOR ID payload you don't
recognize"-- actual quote!) I guess I was expecting new features to
be defined better.

Of course you could use ID_KEY_ID. But that's proprietary and there is
no way _independent_ implementations could interoperate with a scheme
that crams keys and undefined references to keys into an ID payload.

I snipped the rest of your email but let me ask you this: why can't you
use the CERT_REQUEST payload with type=3 (DNS Signed Key) and the body of
the payload is whatever string you want to use to convey "You Jane"?
Don't like using Type=3? OK, how about type=11 (Raw RSA Key)? Don't
like that then let's define a type=14 for whatever usage you want
and let's define _exactly_ what that use is.

What we don't need is TWO OPTIONAL PAYLOADS IN THE SAME MESSAGE (!!!)
that both give hints about what identity the initiator is expecting the
responder to use. 

  Dan.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 09:35:55 -0800

>>>>> "Geoffrey" == Geoffrey Huang <[email-masked]> writes:
    Geoffrey> Granted, it depends on the type of identity presented.  But if
    Geoffrey> you're 
    Geoffrey> using something like user@fqdn type, ID_KEY_ID or even a cert
    Geoffrey> DN, the 

  How. I'm [email-masked].
  What service do I want to connect to? Tell me.

---

From: "Geoffrey Huang" <[email-masked]>
Date: Tue, 18 Mar 2003 10:40:50 -0800

>   What service do I want to connect to? Tell me.

*I* can't tell you that because *I* am not the security gateway ;-).
This has to be a policy decision configured at the gateway.  Like if
you're [email-masked], what optional IDr would you present?
security-gateway.sandelman.ca?  Then what's the point of presenting both
pieces of information, since the latter can be inferred from the former.

But as I said before, this isn't a thorn in my side - it's an optional
payload, so I'm not too bothered by it.  I only wanted it to be
clarified what to do if the responder doesn't return the IDr the
initiator proposed.

-g

---

From: Henry Spencer <[email-masked]>
Date: Tue, 18 Mar 2003 14:16:01 -0500 (EST)

On Tue, 18 Mar 2003, Geoffrey Huang wrote:
> This has to be a policy decision configured at the gateway.

Suppose this is *not* a VPN, so it's *not* preconfigured down to the last
detail.  Then there is no policy which says which service [email-masked]
might want, because there is no way to tell that in advance.

Even if it is preconfigured, for that matter, there might be more than one
service he might want, and hence no way to intuit a single answer. 

> ...you're [email-masked], what optional IDr would you present?
> security-gateway.sandelman.ca?

Why would he present a name associated with him?  IDr is meant to be an
identity meaningful on the responder, not on the initiator.  He would ask
for, say, area51.topsecretRandD.cisco.com.  There's no way you can infer
that from [email-masked].

                                                          Henry Spencer
                                                       [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 13:15:32 -0800

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

>>>>> "dharkins" == dharkins  <[email-masked]> writes:
    dharkins> How does the responder pick the right private key? You haven't
    dharkins> said how "[email-masked]" is uniquely bound to a key in
    dharkins> the first place. For the standard way of binding identities to

  I don't see how it matters how the binding is done. It is a local matter.
Maybe I have /etc/keys. The responder has a list of identities that it is
authoritative for.  

  We generally felt that the the You-Tarzan part could indicate what
identity one might wish to speak to.

  While the CERT_REQUEST would indicate that one *also* needs to get the
full chain of the keys to authenticate that identity - that there wasn't a
way to get this otherwise. Remember that we were trying to get rid of big
certificate chains.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 13:04:47 -0800

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

    dharkins> How does the responder pick the right private key? You haven't
    dharkins> said how "[email-masked]" is uniquely bound to a key in
    dharkins> the first place. For the standard way of binding identities to
    dharkins> keys you can use the standard way of conveying this
    dharkins> information-- a CERT_REQUEST payload with DN equal to the

  I do not speak PKIX, so please explain this to me again.
  Based upon deployment experience with IPsec, neither does anyone else.
 
  If you are saying that PKIX is a *REQUIREMENT* for doing IPsec with IKEv2,
then I'll stick to IKEv1.  
  If your answer is YES, to the above, then we can stop doing any of the
legacy authentication things as well. Many people will be a lot happier.

  Raw RSA keys is a stepping stone between PSK and full-X.509. It works.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 13:09:19 -0800

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

>>>>> "dharkins" == dharkins  <[email-masked]> writes:
    dharkins> On Mon, 17 Mar 2003 19:50:21 PST you wrote
    >> Me-Tarzan/You-Jane, I'll provide an example of using
    >> Me-Tarzan/You-Jane to aid in key-rollover. Recall that the "You-Jane"
    >> part provides both the ID that the initiator was expecting to talk to,
    >> but also a reference to the public key, and optionally, the public key
    >> as well.

    dharkins> No, I don't recall that! In fact, this is the ENTIRE DEFINITION
    dharkins> of the "Me Tarzan/You Jane" feature in ikev2-05:

    dharkins> The optional payload IDr enables Alice to specify which of
    dharkins> Bob's identities she wants to talk to. This is useful when Bob
    dharkins> is hosting multiple identities at the same IP address.

  I can't be responsible for this.
  In fact, I haven't read -05 yet, I'm embarrased to say. I guess, I got
the impression that the entire text as was written was used.

    dharkins> What we don't need is TWO OPTIONAL PAYLOADS IN THE SAME MESSAGE
    dharkins> (!!!)  that both give hints about what identity the initiator
    dharkins> is expecting the responder to use.

  I don't mind putting them in a different payload. Would that make you
happy? It seemed redundant to me.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 18 Mar 2003 16:56:38 -0500

> Maybe I have /etc/keys. The responder has a list of identities that it is

yes, and it's likely to be the case that in peer-to-peer situations,
initiator and responder may swap roles over the long run -- but the
entity which was previously responder wants to ensure it talks to the
same entity which was the initiator, and it could thus convert a
received "me jane" into an outgoing "me tarzan, you jane" some time
afterwards..

						- Bill

---

From: "Jimmy Zhang" <[email-masked]>
Date: Tue, 18 Mar 2003 14:31:46 -0800

So, what is Notify payload designed for? It can handle this kind of
thing perfectly. What we need is to assign another notify type, as Dan
said. Those sites which hosts multiple domain names must support this
notify type.

Thanks,

Jimmy Zhang

> [mailto:[email-masked]] On Behalf Of Henry Spencer
> Sent: Tuesday, March 18, 2003 11:16 AM
> To: IP Security List
> Subject: RE: "Me Tarzan, You Jane" in IKEv2-05 
> 
> 
> Suppose this is *not* a VPN, so it's *not* preconfigured down 
> to the last detail.  Then there is no policy which says which 
> service [email-masked] might want, because there is no way 
> to tell that in advance.
> 
> Even if it is preconfigured, for that matter, there might be 
> more than one service he might want, and hence no way to 
> intuit a single answer. 
> 
> Why would he present a name associated with him?  IDr is 
> meant to be an identity meaningful on the responder, not on 
> the initiator.  He would ask for, say, 
> area51.topsecretRandD.cisco.com.  There's no way you can 
> infer that from [email-masked].
> 
>                                                           
> Henry Spencer
>                                                        
> [email-masked]
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 15:22:09 -0800

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

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:
    >> I don't see how it matters how the binding is done. It is a local
    >> matter.  Maybe I have /etc/keys. The responder has a list of
    >> identities that it is authoritative for.

    Bill> yes, and it's likely to be the case that in peer-to-peer
    Bill> situations, initiator and responder may swap roles over the long
    Bill> run -- but the entity which was previously responder wants to
    Bill> ensure it talks to the same entity which was the initiator, and it
    Bill> could thus convert a received "me jane" into an outgoing "me
    Bill> tarzan, you jane" some time afterwards..

  Bill, I strongly agree with you - that it is best to be specific about
who we wish to talk to, because one can swap ends.

  But, I'm not sure if you are agreeing with me that the mapping of key
names to actual keys is a local matter.

===

  Dan, I've read pieces of -05 (I was intending to read it all tonight).

  I see that we have an identity payload that is not what I wrote at:
    http://www.sandelman.ca/ipsec/2002/12/msg00250.html

  but, is also not what Paul wrote at:
    http://www.sandelman.ottawa.on.ca/ipsec/2002/11/msg00018.html

  However, there is, section 1.2, page 7:
  
          HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->

  I don't see any way in the ID payload down at section 3.5/page 43 to
know which is the IDi and which is the IDr in the third message.

  Since all of the IKEv1 types are still there, it should be simple to
implement Me-Tarzan/You-Jane. Since the CERT payload now has a RAW raw
key in it, we are there. Me-Tarzan/You-Jane is there at this point.

  I thought that the origin of this debate was whether or not to include it,
that Charlie hadn't yet, because it was not implemented.

  We do *not* need the *two-optional-pieces* in the message of last December.