Re: [Emu] use of EAP in IKEv2/ an effort to bring legacy EAP methods to RFCs/
From: Madjid Nakhjiri (mnakhjirihuawei.com)
Date: Tue, 17 Oct 2006 16:36:42 -0700 (PDT)
Hi,

Sorry for hijacking this email for something that might seem as an unrelated
topic. The following may be a personal misunderstanding or may be that the
fact that many of EAP methods have not been formally standardized by IETF
have some impact on the use of EAP elsewhere:

IETF has published IKEv2 as RFC4306 less than a year ago and included use of
EAP methods as an alternative method in performing authentications required
for Internet key exchange. However, even though the text states (section
2.16):

   "...this memo references [EAP] with the intent that new methods can
   be added in the future without updating this specification..."

Still in the same section it is stated:

   "In addition to authentication using public key signatures and shared
   secrets, IKE supports authentication using methods defined in RFC
   3748 [EAP].  Typically, these methods are asymmetric (designed for a
   user authenticating to a server), and they may not be mutual.  For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public key signature based authentication of the responder to the
   initiator.  These methods are often associated with mechanisms
   referred to as "Legacy Authentication" mechanisms."

I am guessing "legacy authentication" mean EAP methods listed in 3748 and
the text possibly refers to some specific EAP methods (at the time, such as
possibly EAP-TLS or EAP-TTLS) that required use of public keys or it is
actually requiring the use of public keys for every EAP method that is used
with IKEv2.

Clarification is appreciated, as EAP for IKEv2 is now being used in some WGs
quite seriously.

Thanks and again sorry for hijacking the subject line,

Madjid

   



-----Original Message-----
From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
Sent: Monday, October 16, 2006 6:57 AM
To: eap [at] frascone.com; emu [at] ietf.org
Cc: IESG; Bernard Aboba
Subject: [Emu] an effort to bring legacy EAP methods to RFCs


As you you are well aware, much of the
real-world EAP authentication happens through
methods that are either undocumented, poorly
documented, or not documented in a stable
reference. Some methods have been described
as expired Internet Drafts, but there is little
certainty that the descriptions match to the
protocols that are actually implemented.

We are and have been addressing methods in the
EMU WG, as well as in some individual submissions.
For instance, there are currently four methods
in the RFC Editor's queue. However, these activities
are mostly about creating new methods that
can be used in future networks.

In addition, the IESG would like to see some commonly
used current EAP methods to be published as RFCs.
The intention would be to document current practice
and focus on accurate descriptions (as opposed to
improving the protocols or attempting to fix bugs in
them). We believe this improves overall interoperability
and makes it easier for anyone to implement equipment
that employs EAP.

I have talked with the RFC Editor about this and
we expect to be able to publish such documents
via the independent submission channel at the
RFC editor. A number of volunteer reviewers (Cced)
have agreed to help make sure the documents are
clear and implementable (additional reviewers
are always welcome; please contact me).

We expect the publication process to go fairly fast,
particularly given that we can help the RFC Editor
with the ISR review task, focus on documentation
rather than development, and clear IESG position.

So please contact me to indicate your willigness
to participate in this. If you have an EAP method
that has a type number and has been deployed in
current systems but not described in an RFC, talk
to us. What we expect from you is a commitment to
edit the document, but we hope that the rest of the
process in the RFC Editor, ISR, IESG RFC 3932
review, etc. goes smoothly.

Jari Arkko


_______________________________________________
Emu mailing list
Emu [at] ietf.org
https://www1.ietf.org/mailman/listinfo/emu


Results generated by Tiger Technologies using MHonArc.