Skip to main content

Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method
RFC 6678

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from emu-chairs@ietf.org, draft-ietf-emu-eaptunnel-req@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Alexey Melnikov
2012-08-22
09 (System) post-migration administrative database adjustment to the Abstain position for Lars Eggert
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2012-07-26
09 (System) RFC published
2011-01-11
09 (System) IANA Action state changed to No IC from In Progress
2011-01-11
09 (System) IANA Action state changed to In Progress
2011-01-11
09 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-01-11
09 Cindy Morgan IESG state changed to Approved-announcement sent
2011-01-11
09 Cindy Morgan IESG has approved the document
2011-01-11
09 Cindy Morgan Closed "Approve" ballot
2011-01-11
09 Cindy Morgan Approval announcement text regenerated
2011-01-11
09 Cindy Morgan Ballot writeup text changed
2011-01-10
09 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to Abstain from Discuss
2010-12-23
09 Russ Housley
[Ballot discuss]
Based on the discussion following the posting of the Gen-ART Review
  by Roni Even on 25-Oct-2101, at least one chaneg to the …
[Ballot discuss]
Based on the discussion following the posting of the Gen-ART Review
  by Roni Even on 25-Oct-2101, at least one chaneg to the document was
  agreed.  The revised document has not been posted yet.
2010-12-23
09 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss
2010-12-20
09 Alexey Melnikov [Ballot comment]
[RFC4510] is a better reference for LDAP than [RFC4511].
2010-12-20
09 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss
2010-12-19
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2010-12-19
09 (System) New version available: draft-ietf-emu-eaptunnel-req-09.txt
2010-12-03
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Lt. Mundy.
2010-12-03
09 (System) Removed from agenda for telechat - 2010-12-02
2010-12-02
09 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-12-02
09 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2010-12-02
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2010-12-02
09 Jari Arkko
[Ballot comment]
I support Lars' discuss, but I also think that the document is clear
with respect to what it is recommending, i.e., I'm not …
[Ballot comment]
I support Lars' discuss, but I also think that the document is clear
with respect to what it is recommending, i.e., I'm not supportive of
Alexey's discuss.
2010-12-02
09 Jari Arkko
[Ballot discuss]
I would have voted Yes on this excellent document if it were not
for the following statement:

  The mandatory to implement cipher …
[Ballot discuss]
I would have voted Yes on this excellent document if it were not
for the following statement:

  The mandatory to implement cipher suites MUST NOT include "export
  strength" cipher suites

First of all, I want to know what this means. What specific requirements
are you setting, and from whose perspective?

Secondly, the IETF has not been and I don't think it should be in the
business of changing its technical requirements based on requirements
from governments. And in particular not requirements specific to any
individual country. I think we need to make this new method as strong
as it needs to be. In terms of symmetric ciphers, AES-128 or AES-256
would be fine, for instance. If that's exceeding the particular export
limitations mentioned above, I do not think we should compromise the
specification. If not, why do we need to say something? Finally,
do you expect to be able to implement this method based on OpenSSL or
some limited version of it? I surely hope that the intention is the
former.
2010-12-02
09 Jari Arkko
[Ballot comment]
I support Lars' discuss, but I also think that the document is clear
with respect to what it is recommending, i.e., I'm not …
[Ballot comment]
I support Lars' discuss, but I also think that the document is clear
with respect to what it is recommending, i.e., I'm not supportive of
Alexey's discuss.
2010-12-02
09 Jari Arkko
[Ballot discuss]
I would have voted Yes on this excellent document if it were not
for the following statement:

The document says:

  The mandatory …
[Ballot discuss]
I would have voted Yes on this excellent document if it were not
for the following statement:

The document says:

  The mandatory to implement cipher suites MUST NOT include "export
  strength" cipher suites

First of all, I want to know what this means. What specific requirements
are you setting, and from whose perspective?

Secondly, the IETF has not been and I don't think it should be in the
business of changing its technical requirements based on requirements
from governments. I think we need to make this new method as strong
as it needs to be. In terms of symmetric ciphers, AES-128 or AES-256
would be fine, for instance. If that's exceeding the particular export
limitations mentioned above, I do not think we should compromise the
specification.
2010-12-02
09 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2010-12-02
09 Tim Polk
[Ballot comment]
After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other
architectural information are necessary …
[Ballot comment]
After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other
architectural information are necessary for this document to be widely useful.  I enter this as a comment, since the
primary audience for the document is the emu working group, and I expect that the participants are in rough agreement
about the architecture.  That is, adding the diagrams and architectural information will have limited utility for emu
itself (although we might identify some unknown disagreements in the process!)  The specification can serve its
main purpose as it stands - guide and focus the development of a standards track EAP tunnel method.

I leave to the authors, chairs, and sponsoring AD's discretion whether the working group has sufficient cycles or
energy to fill this gap.
2010-12-02
09 Tim Polk
[Ballot comment]
After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other
architectural information are necessary …
[Ballot comment]
After reading the secdir review and various AD comments, I have come to the conclusion that diagrams and other
architectural information are necessary for this document to be widely useful.  I enter this as a comment, since the
primary audience for the document is the emu working group, and I expect that the participants are in rough agreement
about the architecture.  That is, adding the diagrams and architectural information will have limited utility for emu
itself (although we might identify some unknown disagreements in the process!)  The specification can serve its
main purpose as it stands - guide and focus the development of a standards track EAP tunnel method.

I leave to the authors and sponsoring AD's discretion whether the working group has sufficient cycles or energy to
fill this gap.
2010-12-02
09 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
09 Adrian Farrel [Ballot comment]
A number of acronyms need to be expanded on first use.
2010-12-01
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
09 Robert Sparks [Ballot comment]
Support Lars' DISCUSS re: 2119 language
2010-12-01
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
09 Alexey Melnikov
[Ballot comment]
3.1.  Password Authentication

  Many legacy systems only support user authentication with passwords.
  Some of these systems require transport of the actual …
[Ballot comment]
3.1.  Password Authentication

  Many legacy systems only support user authentication with passwords.
  Some of these systems require transport of the actual username and
  password to the authentication server.  This is true for systems
  where the authentication server does not have access to the cleartext
  password or a consistent transform of the cleartext password.
  Example of such systems are one time password (OTP) systems and other

I don't think OTP systems require password in the clear, or at least not all of them.

  systems where the username and password are submitted to an external
  party for validation.

4.2.1.  TLS Requirements

  The tunnel based method MUST support TLS version 1.2 [RFC5246] and
  may support earlier versions to enable the possibility of backwards
  compatibility.

Just not SSL 2.0 :-).

4.5.  Requirements Associated with Carrying Username and Passwords

  This section describes the requirements associated with tunneled
  password authentication.  The password authentication mentioned here
  refers to user or machine authentication using a legacy password
  database or verifier, such as LDAP, OTP, etc.  These typically
  require the password in its original text form in order to
  authenticate the peer, hence they require the peer to send the clear
  text user name and password to the EAP server.

LDAP needs an Informative Reference.


4.5.2.  Internationalization

  The password authentication exchange MUST support user names and
  passwords in international languages.  It MUST support encoding of
  user name and password strings in UTF-8 [RFC3629] format.  The method
  MUST specify how username and password normalizations and/or
  comparisons is performed in reference to SASLPrep [RFC4013] or Net-
  UTF-8 [RFC5198].

Please add "or their replacement", as SASLPrepbis is going to be worked on in the Precis WG.

4.5.2.  Internationalization

  These numeric codes are not subject

Missing "to" after "subject".

  internationalization during transmission.
2010-12-01
09 Alexey Melnikov
[Ballot discuss]
For readers not familiar about internal discussions within EMU WG, it would be helpful to understand what exactly is the WG planning to …
[Ballot discuss]
For readers not familiar about internal discussions within EMU WG, it would be helpful to understand what exactly is the WG planning to design. Can you please describe in the Introduction the thing you are trying to build.
Sean explained to me that that is supposed to be a new EAP method, that uses
TLS and multiple EAP methods inside the TLS tunnel.

Once I understood the scope, it became easier to review the document. Some additional comments:

3.9.  Certificate-less Authentication and Generic EAP Method Extension

  In some cases the peer will not have a way to verify a server
  certificate and in some cases a server might not have a certificate
  to verify.  Therefore, it is desirable to support certificate-less
  authentication.  An application for this is credential provisioning
  where the peer and server authenticate each other with a shared
  password and credentials for subsequent authentication (e.g. a key
  pair and certificate or a shared key) can be passed inside the
  tunnel.  Another application is to extend existing EAP methods with
  new features such as channel bindings.

This is the first time the term channel bindings is used. Did you mean
EAP channel bindings or the channel bindings as used by other protocols
such as GSS-API and SASL?

I think you meant the latter here, but this is not clear.
2010-12-01
09 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded
2010-12-01
09 Peter Saint-Andre
[Ballot comment]
1. In Section 3.9, a reference to RFC 5056 would be helpful with regard to channel binding.

2. In Section 3.9 and Section …
[Ballot comment]
1. In Section 3.9, a reference to RFC 5056 would be helpful with regard to channel binding.

2. In Section 3.9 and Section 4.6.3, it might be good to describe in a bit more how cryptographic binding is different from channel binding.
2010-12-01
09 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-12-01
09 Stewart Bryant [Ballot comment]
I support Lars' Discuss on RFC2119 language. I also found it very confusing.
2010-12-01
09 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2010-11-30
09 Russ Housley
[Ballot discuss]
Based on the discussion following the posting of the Gen-ART Review
  by Roni Even on 25-Oct-2101, at least one chaneg to the …
[Ballot discuss]
Based on the discussion following the posting of the Gen-ART Review
  by Roni Even on 25-Oct-2101, at least one chaneg to the document was
  agreed.  The revised document has not been posted yet.
2010-11-30
09 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded
2010-11-30
09 Lars Eggert
[Ballot discuss]
Section 2., paragraph 0:
> 2.  Conventions Used In This Document

  DISCUSS: It is *extremely* confusing to see RFC2119 terms being
  …
[Ballot discuss]
Section 2., paragraph 0:
> 2.  Conventions Used In This Document

  DISCUSS: It is *extremely* confusing to see RFC2119 terms being
  redefined in the local scope of a document, especially since the
  redefinitions seem comparable to what RFC2119 specified. Suggest to
  either include the normal RFC2119 boilerplate and reference, or else
  chose different local terms.


Section 4.2.2., paragraph 1:
>    Tunnel establishment sometimes requires the exchange of information
>    that exceeds what can be carried in a single EAP message.  In
>    addition information carried within the tunnel may also exceed this
>    limit.  Therefore a tunnel method MUST support fragmentation and
>    reassembly.

  DISCUSS: I'm not sure I understand this requirement. A TLS tunnel uses
  TLS on top of TCP. TCP byte streams have no fragmentation issues.
2010-11-30
09 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded
2010-11-10
09 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2010-11-10
09 Sean Turner Ballot has been issued
2010-11-10
09 Sean Turner Created "Approve" ballot
2010-11-10
09 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2010-11-10
09 Sean Turner Placed on agenda for telechat - 2010-12-02
2010-11-10
09 Sean Turner Status Date has been changed to 2010-11-11 from None
2010-11-10
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2010-11-01
09 Amanda Baber We understand that this document does not request any IANA actions.
2010-10-24
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2010-10-24
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Lt. Mundy
2010-10-20
09 Amy Vezza Last call sent
2010-10-20
09 Amy Vezza State changed to In Last Call from Last Call Requested by Amy Vezza
2010-10-20
09 Sean Turner Last Call was requested by Sean Turner
2010-10-20
09 (System) Ballot writeup text was added
2010-10-20
09 (System) Last call text was added
2010-10-20
09 (System) Ballot approval text was added
2010-10-20
09 Sean Turner State changed to Last Call Requested from Publication Requested by Sean Turner
2010-10-19
09 Amy Vezza
(1.a) Who is the Document Shepherd for this document?

==> Alan DeKok.


Has the
Document Shepherd personally reviewed this version of the
document and, in …
(1.a) Who is the Document Shepherd for this document?

==> Alan DeKok.


Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

==> Yes, and yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

==> Yes

Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

==> No.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

==> It may be useful to have a review from someone in the security
community who has not been involved in the document development.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

==> No.

For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

Has an IPR disclosure related to this document
been filed?

==> No.

If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

==> The consensus shows strong consensus from a number of individuals.
The WG as a whole understands and agrees with the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

==> No one has threatened an appeal.

If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

==> Yes. The ID Nits are:

1) uses RFC 2119 text without RFC 2119 template. This is
intentional, and explained in the document

2) Using non-RFC3330 compliant IP addresses. This appears
to be a "false positive", as the document does not use
example IP addresses.

There are no other reviews necessary.

(1.h) Has the document split its references into normative and
informative?

==> Yes.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?

==> Yes. The document depends on draft-ietf-emu-chbind.

If such normative references exist, what is the
strategy for their completion?

==> The channel bindings document is expected to to be published
before any tunnel method document.
As a result, there appears to be no issue with publishing the
tunnel requirements document now.

Are there normative references
that are downward references, as described in [RFC3967]?

==> No.

If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

==> Yes. There are no IANA considerations.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?
(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

==> This is not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:


Technical Summary
This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will
provide support for password authentication, EAP authentication and
the transport of additional data for other purposes.

Working Group Summary
The document has had substantial review from a number of working
group participants. The working group is ready to start working on
protocols.

Document Quality
The document is a requirements document that has had contributions
from Working group participants from different vendors. Discussion
in the Working group has resulted in improvements to the document.
2010-10-19
09 Amy Vezza Draft Added by Amy Vezza in state Publication Requested
2010-10-19
09 Amy Vezza [Note]: 'Alan DeKok (aland@deployingradius.com) is the document shepherd.' added by Amy Vezza
2010-09-17
08 (System) New version available: draft-ietf-emu-eaptunnel-req-08.txt
2010-06-24
07 (System) New version available: draft-ietf-emu-eaptunnel-req-07.txt
2010-05-14
06 (System) New version available: draft-ietf-emu-eaptunnel-req-06.txt
2010-03-08
05 (System) New version available: draft-ietf-emu-eaptunnel-req-05.txt
2009-10-08
04 (System) New version available: draft-ietf-emu-eaptunnel-req-04.txt
2009-07-06
03 (System) New version available: draft-ietf-emu-eaptunnel-req-03.txt
2009-02-27
02 (System) New version available: draft-ietf-emu-eaptunnel-req-02.txt
2008-11-01
01 (System) New version available: draft-ietf-emu-eaptunnel-req-01.txt
2008-06-26
00 (System) New version available: draft-ietf-emu-eaptunnel-req-00.txt