RE: Adding revised identities to IKEv2

[Stephen Kent <kent@bbn.com>]

At 8:01 PM -0800 11/7/02, Paul Hoffman / VPNC wrote:
>At 6:45 PM -0800 11/7/02, Max Pritikin wrote:
>>Paul H. isn't proposing any fancy pkix PKI tricks. He's proposing that IKE
>>handle pkix PKI certificates correctly; instead of the existing poorly
>>stated ID mechanisms which never had a chance of working with certificates.
>
>Exactly. For the majority of users, there is a single authorization 
>policy: "everyone I trust is allowed to match any traffic policy". 
>As Jan said, in IKEv1 with presahred keys, there is no separate ID: 
>it is the IP address.
>
>With certificates, it's a mess. Is the ID the whole Subject? Any 
>part of the Subject? The whole SubjectAltName? Any part of the 
>SubjectAltName? The combination of the whole Subject *and* the whole 
>SubjectAltName? But the real question is, who cares? If the gateway 
>admin wants to trust anyone who has a certificate from the trusted 
>root, the ID is pretty much just there for logging. And if they do 
>want to differentiate by ID, they are probably smart enough to fill 
>in the right fields in the GUI for the ID type they care about. 
>(Well, I just lied there: very few IPsec GUIs allow you to 
>differentiate at the level needed.)

Paul,

What you have identified here is a mess due to a lack of sufficiently 
precise discussion in previous documents about what to do with the 
info. That does not mean that we cannot provide this level of detail 
now, so that people can make use of certs in a predictable, 
reasonable fashion. This is what IKE v2 and a cert profile should do, 
in combination. I think we do a disservice to clients if we just 
through up our hands and say it's too hard. As a nominal co-author 
for IKEv2, I will try to focus on that part of the doc, which I have 
not done previously, and work to coordinate it with the PKI profile, 
to make sure we remove the ambiguities. OK?

Steve