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

Revised identity, again



Wearing his WG chair hat, Ted said about the revised identity proposal:

>This would be fundamental change in the management and administraton of
>IPSEC and IKE, so is not something to adopt lightly, and without a clear
>consensus of the working group.

It is inappropriate for the WG chairs to, with less than two weeks 
before the document is supposed to be finished, to make such 
pronouncements about WG procedure. Many people assumed that because 
the proposal had as much support as other proposals, it would go into 
the current draft.

It is also inappropriate for the WG chairs to recast a proposal as 
something that it is not. The revised identity proposal doesn't 
change anything major about the management of administration of 
either IPsec or IKE. It clarifies the use of identity in PKIX 
certificates, and makes it more likely that IKEv2 will work in 
environments where IKEv1 does not, namely where fragmented UDP 
payloads get dropped.

>   This was discussed in two threads on
>the IPSEC mailing list: one starting on November 5th (subject Adding
>revised identities to IKEv2), and one starting on December 8th (subject:
>Summary of revised identity changes).  People who spoke in favor on the
>mailing list included Francis Dupont and Bill Sommerfeld, with qualified
>support from Michael Richardson (if support for bare keys is added) and
>Tero Kivinen (who is concerned about the complexity of the proposal).

And, if I remember correctly, no one spoke against it. This is 
typical of this WG. Almost every other change to IKEv2 has been made 
with about the same amount of support. It is inappropriate for the WG 
chairs to now say "that much support is enough for some proposals, 
but not for this one".

>This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted
>were left with the impression that there was not consensus among those
>who met to discuss legacy authentication after the IPSEC wg meeting to
>pursue adoption of Paul's proposed change.  Paul believes otherwise.

This is irrelevant. The revised identity proposal was barely 
discussed in that meeting *because it is unrelated to legacy 
authentication and remote configuration*. The revised identity 
proposal is almost exclusively about normal authentication with 
certificates.

The statement "Paul believes otherwise" is also completely untrue. 
Ted never asked me about it; if he had, I would have said "we didn't 
really discuss it much because it was irrelevant".

>Since it is the job of working group chairs to determine consensus, we
>(Barbara and Ted) hereby ask that those who believe we should pursue the
>revised identity proposal to please speak up.

The WG chairs need to explain to the WG how they will judge consensus 
on this. Without that, we cannot determine whether or not we should 
bother to have a discussion.

>It should be noted that there are some intermediate positions beyond
>what is currently in draft-ietf-ipsec-ikev2-04.txt and the
>revised-identies draft.  For example, we could add the Hash-and-URL type
>to the Certificate payload, if the goal is shrink the size of IKE
>messages (with the tradeoff of increasing complexity in IKE
>implementations).   We could also add a CERT hash type to the ID
>payload, without nuking the traditional FQDN or IPv4/6 addresses
>identity mechanisms (although again, by adding new types, we would be
>increasing the complexity of the specification and implementations).

This paragraph means that the many years of on-and-off discussion 
about the lack of clarity of IKEv1 with respect to what does an ID 
payload mean when using certificates is now ignored. The fact that 
there is vastly less interoperability for certificate authentication 
than for preshared secret authentication (or even XAUTH 
authentication!) is now irrelevant.

According to the WG chairs, IKEv2 should use the same under-specified 
and non-specified rules for certificate processing as IKEv1.

Is this what the working group wants?

--Paul Hoffman, Director
--VPN Consortium