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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf