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 piuha.net]
Sent: Monday, October 16, 2006 6:57 AM
To: eapfrascone.com; emuietf.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
Emuietf.org
https://ww
w1.ietf.org/mailman/listinfo/emu
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|