Dan Harkins writes: > Nobody said anything about "adding everything". That is a complete straw > man argument. In fact, it is decidedly not the case that "everything" is > being > added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick > to leap to unfounded conclusions you would see this IANA update as the > innocuous event that it really is.
Not if you count the authentication methods in to it too. That do require quite a bit of work to make sure everything is done correctly. Especially as IKEv1 exchanges are quite different depending which authentication method is used. Adding only the Diffie-Hellman groups is much easier, but I understood that the idea was to add both. And for SPSK there was also text for adding that to IKEv1 too, before it was removed. Same is now with the ike-over-tcp, which again has IKEv1 text in it. > This is allowing existing implementations to have more flexibility in the > ECDH operations they perform to comply with various requirements that > may exist in different locales or in different circumstances or situations. I would think the ECP groups we already have in the IKEv1 should be enough for the most common case, i.e. the suite-b uses. Also I still do not think that many implementations are going to update their IKEv1 implementations. > > I think otherwise, as using new group mode allows using them without > > changing any single line of code, provided the IKEv1 implementation do > > support ECP groups at all (and support the new group mode which is > > SHOULD). > > There is a capability in New Group Mode to accept or reject the proposal > and this is to allow the recipient to verify that the group is acceptable. > Enabling this in IKEv1 for the brainpool curves would be substantially more > code than just using the existing code point interface that all > implementation > have. If I remember those old times when our code actually could use new group mode, I think there was two ways to use it, either accept any group other end proposed (without any verification, very useful for testing etc), or to allow the same groups defined in the configuration file. Of course if you were using the group for IKEv1 SA you can also include all the parameters in the SA propsals from RFC2409: Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. So what is wrong with using the already existing mechanisms of using groups directly in the SA for that already obsoleted protocol? It seems the only reason to add numbers for them is to support non IPsec use... > > This is exactly why new group mode was made a SHOULD in the IKEv1, > > i.e. to allow adding new groups without need to changing the > > specification or the actual code. > > Your recollection differs from the person who actually wrote the RFC. > And when that happens one should typically defer to the author. In fact, > your statement seems to differ from the RFC which says it SHOULD be > supported as a mechanism to define "private groups". The brainpool > groups are not private and there is no reason to treat them as such. Brainpool groups do not have number in the IANA registry, which makes them private for IKEv1 use. There is nothing there claiming that you can only use new group mode to negotiate groups that are not know for anybody else. > Since groups added with New Group mode MUST be assigned private > code points it would result in a case of code bi-furcation because > the same domain parameter sets would be accessed using different > code points. That's unnecessary code complication for implementations > that support both IKEv1 and IKEv2. Or you can simply give all the parameters in the SA payload, and not give it number at all. Then it does not matter what the number is. The whole idea of that feature was to allow adding Diffie-Hellman groups to existing implementations by just changing the configuration without modifying the actual code. Implementations supporting IKEv1 and IKEv2 already needs to keep track of separate number spaces, as IANA registries for the IKEv1 and IKEv2 are separate. Also IKEv2 does not support this feature at all, so there is no over the wire negotiated private groups there. > > I agree on that. I do try to convince to switch to IKEv2, as it is > > MUCH better protocol and works much more robustly and has standarized > > features for things which IKEv1 only has multiple non-standardized > > non-interoperable protocols. > > And bully for you! I wish you much success in your advocacy. Actively > trying to make people's programmatic lives worse because your advocacy > isn't as successful as you'd like is a completely different matter though and > is, I think, inappropriate. > > The fact that you admit you want a blunt club to force compliance > with your wishes speaks volumes. And it seems you want to get the Diffie-Hellman numbers there only for the IEEE-802.11 uses as there is no reason to add them to IKEv1 registries as there is already standardized methods to use them in IKEv1 without code line changes. I have never tried to hide the fact that I think IKEv2 is much better protocol than IKEv1. IKEv1 do have some security problems (not big enough to cause it to fail completely, but they are there). IKEv1 does not have standardized support for many things that are there for IKEv2. Many IKEv1 implementations uses methods described in the expired Internet-drafts for some things, and there are multiple of those methods different implementations use. I think IKEv1 needs to DIE. It is so broken I see no reason for it to kept alive anymore. I do not want anybody to add anything to it for two reasons: 1) I am the implementor who might need to implement them in our code. Up to this point I have been able to say we do not want to do any changes to IKEv1 code. 2) It might make people feel like IKEv1 could still be used. This is my opinion and I do stick to it, and I do continue trying to convince others to it too. I see no problem there. Are you saying that I am not allowed to try to do what I belive is right? > > We do not need to keep adding features to the old obsoleted protocoles > > either. > > This is NOT a feature. ECDH already exists in IKEv1. This is allowing > existing implementations, of which they are legion, to use certain > domain parameter sets that may be required or desired in certain situations > and in certain locales. Anything that changes the code in implementations needs to be categorized in two ways, i.e. either they are: 1) Bugs 2) Enhancements / new features I do not consider this to be bug, so it is new feature / enhancement to the IKEv1. Especially as there is already a way (actually 2 ways) to do the same thing in the standard IKEv1 protocol. > There is no reason for different repositories for IKEv1 and IKEv2. They > are identical with the exception that the EC2N groups were removed in > the IKEv2 repository. Interestingly, the number space that is EC2N in > IKEv1 is "reserved" in IKEv2 and this is done, apparently, to have symmetry > in group definitions. This way implementations can share the same > mapping from code point to domain parameter set. Check the other IANA registries for IKEv1 and IKEv2 too, and you will find more changes. The reasons why the IKEv1 and IKEv2 registries are mostly same is because the IKEv1 registry was copied to work as base for IKEv2, and at that time we removed those groups which were not defined by any RFCs (i.e. the groups 6-13 which were only defined in already expired Internet-Draft). Those 2 RFCs published after that both made same allocations in the both IKEv1 and IKEv2 registries, so thats why it still stayed in sync. There is no reason them to be in sync. > The IKEv1 repository for Diffie-Hellman groups has been updated in > the past after its designation as "deprecated". We should follow precedent > and continue to keep these repositories in harmony. Yes, RFC4753 (which was replaced by 5903) was published in 2007 and draft already existed before IKEv2 RFC was published, so it was logical for it to add groups to both IKEv1 and IKEv2. RFC5114 started around 2007 only 2 years after IKEv2 was out, and at that point it might have been still useful to update IKEv1 protocol. Now IKEv1 has been obsoleted now for 7 years, and I think situation is bit different for now work starting now. We might keep or might not keep those registeries in sync. For example the authentication algorithm registry is completely different after the initial allocation. The encryption algorithms registry is same (even when IKEv1 cannot even use some of those algorithms described there). On the other hand ISAKMP has completely different encryption algorithm registry... There is no point to make changes that on purpose make them out of sync, but also there is no need to allocate every single item from both registries, and we should still allocate first free number to new allocations. But I think we are quite far now from where this dicussion started, and I am not sure if it is useful to continue this discussion as we simply disagree whether IKEv1 should die or not. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
