Ekr, Thanks for your review. > As I was reading this document, I realized that I didn't understand > what it was for. > > As I understand it, this document embeds IKEv2 into EAP. Why is this a > good idea? As I understand the situation, EAP already supports a > TLS-based authentication mechanism, which allows it to do both > public-key based and asymmetric-key based authentication. So, what is > IKEv2 bringing to the party here? Obviously, there are things > IKEv2 is good for that TLS is not, but it's not clear to me that > EAP is using any of that functionality. > > It seems to me that this document would be improved by a discussion > up front of why it is desirable. > Hannes could probably add an applicability discussion that talks about when the use of this method is appropriate and how it compares to other methods. However, I should probably explain the background and rationale for taking on this document. RFC 3748 specifies the IANA rules for EAP method type code allocation. These rules call for Expert Review of methods before a type code can be allocated, basically to ensure that the specification is complete, correctly characterizes the security properties, doesn't break EAP, etc. Hannes applied for type code allocation, and after review on the EAP list and significant revision :-) his method has passed the expert review. My own review of the specification indicates that it is sufficiently well specified that those who run into this method can understand it and would likely be able to build interoperable implementations. But I do not expect this method to be a big success in the market place; its implemented and used only by the researchers in Hannes' group AFAIK. The methods that the IETF recommends to use will come out from the EMU WG, including an updated EAP-TLS spec. Nevertheless, I am in favor of documentation of EAP methods that actually exist. Some years ago we had a situation where IETF did not want to take on any methods work. At the time the IANA policy was also FCFS. This created a situation that we still suffer from: many if not most EAP methods have not been published as RFCs but exists only as drafts, typically not even matching what has been implemented. Often no documentation of a method exists at all. This is obviously bad for interoperability. In the last two or three year we've tried to improve the situation in a number of ways. Including starting up EMU, offering to publish widely used methods as RFCs via the RFC Editor or AD sponsoring, etc. Hannes' method isn't widely used, but given that he's going to get a type number I think it would be desirable to document what this type code means in an RFC. The status of his method would normally lead me to ask him to turn to the RFC Editor. However, in this case I felt that an IETF review of the method had the potential to improve the specification. There is IKEv2 expertise in the IETF, after all. This is also what happened. In addition, his document had been discussed in the EAP WG during Expert Review, so I felt that in this particular case AD sponsored submission for Experimental was the right choice. Hope this helps, Jari _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf