Subject: Comment on draft-tschofenig-eap-ikev2-15

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Oct 2007 06:05:59 -0700

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.

-Ekr

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Oct 2007 21:30:45 +0300

Ekr,

Thanks for your review.

> 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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 08 Oct 2007 18:10:57 -0700

If a type code is going to be allocated anyway, it makes perfect sense 
to have the protocol documented in an RFC.  Procedurally, I am curious 
about the experimental status however, given that the general mode of 
operation on EAP methods was to document the method in an informational 
track RFC.

I will also ask the obligatory :) question:

After the experiment, are we entertaining the possibility of advancing 
this work to standards track?

thanks,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Tue, 09 Oct 2007 11:21:34 +0300

Lakshminath,

> to have the protocol documented in an RFC.

OK.

> Procedurally, I am curious about the experimental status however,
> given that the general mode of operation on EAP methods was to
> document the method in an informational track RFC.

I admit that this looks somewhat arbitrary choice, and Inf would
have worked too. But here's my rationale: some of the other EAP
methods that are Inf were truly non-research efforts with a very
clear target in the market place and in vendor's products. There's
less clarity on EAP IKEv2's role, it came out of what to me appeared
as a researcher's interest to see if a method can be defined this
way. This is why Exp felt more appropriate, with the experiment
being whether this method finds use in the world.

> this work to standards track?

We would consider that for any document. I think its somewhat
unlikely in this case, though. Again, the recommended methods
to use will come out of EMU.

Jari