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 |