As the last discussion attempt about trying to create common way to put those multiple symmetric secure password methods IKEv2 was bit side-railed by misunderstandings etc, I decided it is better to write bit more about the issue before continue on the issue. Here is the draft that includes bit more of introduction and rationale what I want to do and what I hope the draft authors would agree to do on.
This draft is not necessarely something that requires to be published, we could simply also make sure all three secure password methods cut & paste the relevant stuff from here and put all the relevant text to their own documents, as long as all of them agree that they do things in the same way so they can all co-exists together in one implemtation. On the other hand documenting the common grounds in separate document might be easier for the implementor to understand what he needs to do and what he can assume from the secure password methods, i.e. implementor does not need to verify that all of the methods do method negotiation in the same way, if all of them refer to same document (compared to the case where they copy the same text and put it in to their document). Hopefully this draft will clarify things bit more. http://www.ietf.org/id/draft-kivinen-ipsecme-secure-password-framework-00.txt
--- Begin Message ---A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-00.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-secure-password-framework Revision: 00 Title: Secure Password Framework for IKEv2 Creation date: 2011-05-12 WG ID: Individual Submission Number of pages: 14 Abstract: The IPsecME working group was chartered to provide IKEv2 a symmetric secure password authentication protocol that supports using of low- entropy shared secrets, but which is protected against off-line dictionary attacks without requiring the use of certificates of EAP. There are multiple of such methods and working group was supposed to pick one. Unfortunately the working group failed to get pick one protocol and there are multiple candidates going forward as separate documents. As each of those documents uses different method to negotiate the use of the method and also uses different payload formats it is very hard to try to make implementation where multiple of those systems could co-exists. This document tries to create generic way for those methods to negotiate which one is used and provides one new payload which can be used to transmit method specific data. The IETF Secretariat
--- End Message ---
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
