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

Re: IKEV2: Issue #4 Revised Identity



At 11:07 PM -0800 2/10/03, Eric Rescorla wrote:
>In IKEv1 the authenticating party tells the client what its identity is
>and then the verifying party compares the ID payload to the
>certificate.

That is one interpretation; there are many others. As others have 
said before on this thread, anyone who has gone to the bakeoffs knows 
this.

>  In your scheme the verifying party has to
>guess based on the certificate, which is a potential problem
>if the cert has ambiguous identity information.

There is no such thing as a certificate with ambiguous identifying 
information. You inherently trust the certificate issuer to give the 
right information.

>  > But this is not what the WG chairs have proposed. There is no proposal
>>  for clarifying the semantics in IKEv2 on the table. We are left with
>>  the same nothing as in IKEv1. Why would an implementer go to IKEv2 if
>>  the major user problems with IKEv1 are left the same?
>As far as I can tell, it is what they've proposed. Quoting from
>Ted's message:
>
>         The choice between the working group, then is between using
>         language taken from pki-profile-01 to make explicit when
>         certificate payloads are sent, or choosing the
>         revised-identity proposal.  More comments about the tradeoffs
>         inherent between these two choices are hereby requested.

So, let's ask the WG chairs then: is Eric's interpretation correct? 
Is this also a WG last call on pki-profile-01? If not, then IKEv2 
will be plagued with the same interop problems that IKEv1 has. If it 
is a last call, the WG should be discussing the document, which has 
gotten no traffic to date.

--Paul Hoffman, Director
--VPN Consortium