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

Re: Me-Tarzan/You-Jane and key rollover (was Re: "Me Tarzan, You Jane" in IKEv2-05 )



On Mon, 17 Mar 2003 19:50:21 PST you wrote
> 
> 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.

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.