An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol
RFC 6124
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
09 | (System) | Notify list changed from gwz@net-zen.net, yaronf.ietf@gmail.com, sfluhrer@cisco.com, Hannes.Tschofenig@gmx.net to (None) |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the Yes position for Russ Housley |
|
2011-02-23
|
09 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-02-23
|
09 | Cindy Morgan | [Note]: 'RFC 6124' added |
|
2011-02-22
|
09 | (System) | RFC published |
|
2010-11-29
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2010-11-24
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2010-11-24
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2010-11-24
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2010-11-23
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2010-11-16
|
09 | (System) | IANA Action state changed to In Progress |
|
2010-11-16
|
09 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2010-11-16
|
09 | Russ Housley | Subject: Problem with draft-sheffer-emu-eap-eke Date: Mon, 15 Nov 2010 20:43:46 -0800 From: Bernard Aboba <bernard_aboba@hotmail.com> To: <iesg@ietf.org>, … Subject: Problem with draft-sheffer-emu-eap-eke Date: Mon, 15 Nov 2010 20:43:46 -0800 From: Bernard Aboba <bernard_aboba@hotmail.com> To: <iesg@ietf.org>, <ietf@ietf.org> I just took a look at the EAP EKE document recently approved by the IESG for publication as an Informational RFC: draft-sheffer-emu-eap-eke-09 The document does not define the following parameters required by RFC 5247: 1. Peer-Id 2. Server-Id 3. Session-Id In particular, the omission of the Session-Id is a significant problem, since this is required for EAP methods to be usable within IEEE 802.1X-2010. My suggestion is that ID_P be designated as the Peer-Id. Since the Server identity is not authenticated (just asserted), it is not clear to me whether ID_S is suitable for use as the Server-Id. My suggestion is that the Session-Id be defined as follows: Session-Id = Type-Code || Nonce_P || Nonce_S |
|
2010-11-15
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2010-11-15
|
09 | Cindy Morgan | IESG has approved the document |
|
2010-11-15
|
09 | Cindy Morgan | Closed "Approve" ballot |
|
2010-11-15
|
09 | Cindy Morgan | Approval announcement text regenerated |
|
2010-11-15
|
09 | Russ Housley | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
|
2010-11-06
|
09 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk |
|
2010-10-19
|
09 | Russ Housley | [Ballot discuss] Please respond to the comments from Dan Harkins on 18-Aug-2010. |
|
2010-10-19
|
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from Discuss by Russ Housley |
|
2010-10-19
|
09 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov |
|
2010-10-10
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2010-10-10
|
09 | (System) | New version available: draft-sheffer-emu-eap-eke-09.txt |
|
2010-08-29
|
09 | Alexey Melnikov | [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: … [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: This field ("proptected nonce") contains the encrypted and typo: protected integrity-protected response to the other party's challenge, see Section 5.3 and Section 5.4. Similarly to the PNonce_P field, this field's size is determined by the encryption and MAC algorithms. The following used to be a DISCUSS: 7.5. Identity Type Registry In addition, an identity type registry is defined: +-----------+---------+---------------------------------------------+ | Name | Value | Definition | +-----------+---------+---------------------------------------------+ | Reserved | 0 | | | ID_OPAQUE | 1 | An opaque octet string | Is this value ever entered by a human? If the answer is yes, then this need some common user friendly input format for management of such identities. |
|
2010-08-29
|
09 | Alexey Melnikov | [Ballot discuss] This is a well written document and in general I have no objections to its publication. I am agreeing with Russ' DISCUSS and … [Ballot discuss] This is a well written document and in general I have no objections to its publication. I am agreeing with Russ' DISCUSS and would like to see how it gets resolved, so I am holding a DISCUSS as well. |
|
2010-08-26
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2010-08-26
|
09 | Tim Polk | [Ballot discuss] [revised to include the URL...] This is a placeholder discuss. Issues raised in Brian Weis' secdir review have not been addressed yet. The … [Ballot discuss] [revised to include the URL...] This is a placeholder discuss. Issues raised in Brian Weis' secdir review have not been addressed yet. The review is available at http://www.ietf.org/mail-archive/web/secdir/current/msg01953.html Please involve Brian in the discussion as you address these issues! |
|
2010-08-26
|
09 | Sean Turner | [Ballot comment] I support Russ and Tim's DISCUSS positions. |
|
2010-08-26
|
09 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded by Sean Turner |
|
2010-08-26
|
09 | Adrian Farrel | [Ballot comment] I couldn't work out which range of EAP Method Types should be used for the allocation described at the head of Section 7 … [Ballot comment] I couldn't work out which range of EAP Method Types should be used for the allocation described at the head of Section 7 for "EAP-EKE Version 1". I presume you are headed for 1-191 or 256-... The difference at this stage is whether expert review needs to be invoked. |
|
2010-08-26
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
|
2010-08-26
|
09 | Tim Polk | [Ballot discuss] This is a placeholder discuss. Issues raised in Brian Weis' secdir review have not been addressed yet. Please involve Brian in the discussion … [Ballot discuss] This is a placeholder discuss. Issues raised in Brian Weis' secdir review have not been addressed yet. Please involve Brian in the discussion as you address these issues! |
|
2010-08-26
|
09 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
|
2010-08-26
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2010-08-26
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2010-08-25
|
09 | Alexey Melnikov | [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: … [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: This field ("proptected nonce") contains the encrypted and typo: protected integrity-protected response to the other party's challenge, see Section 5.3 and Section 5.4. Similarly to the PNonce_P field, this field's size is determined by the encryption and MAC algorithms. |
|
2010-08-25
|
09 | Alexey Melnikov | [Ballot discuss] [This is a preliminary DISCUSS and I might add a few extra items before the IESG telechat.] This is a well written document … [Ballot discuss] [This is a preliminary DISCUSS and I might add a few extra items before the IESG telechat.] This is a well written document and in general I have no objections to its publication. However I have several points I would like to discuss before recommending approval of this document: 3) 7.5. Identity Type Registry In addition, an identity type registry is defined: +-----------+---------+---------------------------------------------+ | Name | Value | Definition | +-----------+---------+---------------------------------------------+ | Reserved | 0 | | | ID_OPAQUE | 1 | An opaque octet string | DISCUSS DISCUSS: Is this value ever entered by a human? If the answer is yes, then this need some common user friendly input format for management of such identities. |
|
2010-08-25
|
08 | (System) | New version available: draft-sheffer-emu-eap-eke-08.txt |
|
2010-08-24
|
09 | Russ Housley | [Ballot discuss] Please respond to the comments from Dan Harkins on 18-Aug-2010. |
|
2010-08-24
|
09 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Discuss from Yes by Russ Housley |
|
2010-08-24
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
|
2010-08-23
|
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2010-08-20
|
09 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Brian Weis. |
|
2010-08-16
|
09 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Brian Weis |
|
2010-08-16
|
09 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Brian Weis |
|
2010-08-15
|
09 | Alexey Melnikov | [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: … [Ballot comment] It would have been nice to be able to piggyback on one of existing MAC/PRF/Encryption algorithm registries. 4.2.3. The EAP-EKE-Confirm Payload PNonce_PS/PNonce_S: This field ("proptected nonce") contains the encrypted and typo: protected integrity-protected response to the other party's challenge, see Section 5.3 and Section 5.4. Similarly to the PNonce_P field, this field's size is determined by the encryption and MAC algorithms. 5.3. EAP-EKE-Confirm/Request Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). The messages are included in full, starting with the EAP header, and including any possible future extensions. This implies that no extensions can be added to the EAP-EKE-Confirm/Request or EAP-EKE-Confirm/Response itself. I don't have a problem with that, but it would be good to state this explicitly. |
|
2010-08-15
|
09 | Alexey Melnikov | [Ballot discuss] [This is a preliminary DISCUSS and I might add a few extra items before the IESG telechat.] This is a well written document … [Ballot discuss] [This is a preliminary DISCUSS and I might add a few extra items before the IESG telechat.] This is a well written document and in general I have no objections to its publication. However I have several points I would like to discuss before recommending approval of this document: 1) 5.1. EAP-EKE-Commit/Request The output is the binary representation of the processed UTF-8 character string. A Normative Reference to UTF-8 (RFC 3629) is missing here. It might also be worth mentioning security considerations for UTF-8 (from RFC 3629) in the Security Considerations. 2) 7.3. Pseudo Random Function Registry PRF_HMAC_SHA256 has no normative reference to the document that defines SHA256. 3) 7.5. Identity Type Registry In addition, an identity type registry is defined: +-----------+---------+---------------------------------------------+ | Name | Value | Definition | +-----------+---------+---------------------------------------------+ | Reserved | 0 | | | ID_OPAQUE | 1 | A printable UTF-8 string whose format is | | | | undefined | What is "printable UTF-8 string"? A reference to RFC 3629 would be good here as well. | ID_FQDN | 5 | A fully qualified domain name | Is this Unicode (IDN) version, or ASCII only? 4) The document needs to explicitly say that all multioctet fields are in network byte order. 5) 4.5. Channel Binding Values This protocol allows higher level protocols that are using it to transmit opaque information between the peer and the server. This information is integrity protected but not encrypted, and may be used to ensure that protocol participants are identical at different protocol layers. EAP-EKE neither validates nor makes any use of the transmitted information. The information MUST NOT be used by the consumer protocol until it is verified in the EAP-EKE-Confirm exchange (specifically, it is integrity protected by the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon in case an error occurs at the EAP-EKE level. Are you talking about Channel Bindings as defined in RFC 5056? I am missing the Normative reference to this RFC. |
|
2010-08-15
|
09 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov |
|
2010-08-15
|
09 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
|
2010-08-15
|
09 | Russ Housley | Ballot has been issued by Russ Housley |
|
2010-08-15
|
09 | Russ Housley | Created "Approve" ballot |
|
2010-08-11
|
09 | Alexey Melnikov | Area acronymn has been changed to sec from gen |
|
2010-08-10
|
09 | Cindy Morgan | Telechat date has been changed to 2010-08-12 from None by Cindy Morgan |
|
2010-08-08
|
09 | Russ Housley | Placed on agenda for telechat - 2010-08-12 by Russ Housley |
|
2010-08-08
|
09 | Russ Housley | State changed to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley |
|
2010-06-16
|
07 | (System) | New version available: draft-sheffer-emu-eap-eke-07.txt |
|
2010-06-01
|
09 | Amanda Baber | IANA's questions have been answered. |
|
2010-05-27
|
09 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Brian Weis. |
|
2010-05-19
|
09 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2010-05-14
|
09 | Amanda Baber | IANA questions/comments: NOTE: IANA has questions about actions 7, 8, and 9. Upon approval of this document, IANA will perform the following actions: ACTION 1: … IANA questions/comments: NOTE: IANA has questions about actions 7, 8, and 9. Upon approval of this document, IANA will perform the following actions: ACTION 1: make the following assignment in the "Method Types" registry at http://www.iana.org/assignments/eap-numbers Value Description Reference ----- ------------------ --------------------------- TBD EAP-EKE version 1 [RFC-sheffer-emu-eap-eke-06] ACTION 2: create the following registry at located at http://www.iana.org/assignments/TBD Registry Name: Diffie-Hellman Groups Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Initial content of the registry per section 7.1 ACTION 3: create the following registry at http://www.iana.org/assignments/TBD Registry Name: Encryption Algorithms Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Initial content of the registry per section 7.2 ACTION 4: create the following registry at http://www.iana.org/assignments/TBD Registry Name: Pseudo Random Functions Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Initial content of the registry per section 7.3 ACTION 5: create the following registry at http://www.iana.org/assignments/TBD Registry Name: Keyed Message Digests Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Initial content of the registry per section 7.4 ACTION 6: create the following registry at http://www.iana.org/assignments/TBD Registry Name: Identity Types Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Initial content of the registry per section 7.5 ACTION 7: create the following registry at http://www.iana.org/assignments/TBD Registry Name: Channel Binding Types Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: Specification Required Type Description Reference ------------- ----------- --------- 0x0000 Reserved [RFC-sheffer-emu-eap-eke-06] 0x0001-0xfeff Unassigned 0xff00-0xffff Private Use [RFC-sheffer-emu-eap-eke-06] QUESTION: Section 7.6 says "All other values up to 0xff00". Does that mean "up to and including"? In other words, is the 0xff00 value unassigned or private use? QUESTION: Is this registry related to the existing "Channel Binding Types" registry at http://www.iana.org/assignments/channel-binding-types/ ? If not, is it possible to give it a slightly longer or more specific name, to differentiate the two? ACTION 8: create the following registry at http://www.iana.org/assignments/TBD Registry Name: EAP-EKE Exchanges Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: RFC Required Value Description Reference --------- ------------------------ --------------------------- 0x00 Reserved [RFC-sheffer-emu-eap-eke-06] 0x01 EAP-EKE-ID exchange [RFC-sheffer-emu-eap-eke-06] 0x02 EAP-EKE-Commit exchange [RFC-sheffer-emu-eap-eke-06] 0x03 EAP-EKE-Confirm exchange [RFC-sheffer-emu-eap-eke-06] 0x04 EAP-EKE-Failure message [RFC-sheffer-emu-eap-eke-06] 0x05-0x7f Unassigned 0x80-0xff Private use [RFC-sheffer-emu-eap-eke-06] QUESTION: Section 7.7 says "All other values up to 0x80". Does that mean "up to and including"? In other words, is the 0x80 value unassigned or private use? ACTION 9: create the following registry at http://www.iana.org/assignments/TBD Registry Name: EAP-EKE Failure Codes Reference: [RFC-sheffer-emu-eap-eke-06] Registration policy: RFC Required Value Name Description Reference --------------------- ---- ----------- --------------------------- 0x00000000-0x00000006 (As of section 4.2.4) [RFC-sheffer-emu-eap-eke-06] 0x00000007-0xfeffffff Unassigned 0xff000000-0xffffffff Private use [RFC-sheffer-emu-eap-eke-06] QUESTION: Section 7.8 says "All other values up to 0xff000000". Does that mean "up to and including"? In other words, is the 0xff000000 value unassigned or private use? |
|
2010-04-25
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2010-04-25
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2010-04-21
|
09 | Amy Vezza | Last call sent |
|
2010-04-21
|
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2010-04-21
|
09 | Russ Housley | State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley |
|
2010-04-21
|
09 | Russ Housley | Last Call was requested by Russ Housley |
|
2010-04-21
|
09 | (System) | Ballot writeup text was added |
|
2010-04-21
|
09 | (System) | Last call text was added |
|
2010-04-21
|
09 | (System) | Ballot approval text was added |
|
2010-04-21
|
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2010-04-21
|
06 | (System) | New version available: draft-sheffer-emu-eap-eke-06.txt |
|
2010-03-18
|
09 | Russ Housley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley |
|
2010-03-18
|
09 | Russ Housley | Comments on -05 were sent to the authors. A revised Internet-Draft is needed to resolve the comments. Many of the comments were technical. |
|
2010-03-18
|
09 | Russ Housley | State Change Notice email list have been change to gwz@net-zen.net, yaronf.ietf@gmail.com, sfluhrer@cisco.com, Hannes.Tschofenig@gmx.net from gwz@net-zen.net, yaronf@checkpoint.com, sfluhrer@cisco.com, Hannes.Tschofenig@gmx.net, … State Change Notice email list have been change to gwz@net-zen.net, yaronf.ietf@gmail.com, sfluhrer@cisco.com, Hannes.Tschofenig@gmx.net from gwz@net-zen.net, yaronf@checkpoint.com, sfluhrer@cisco.com, Hannes.Tschofenig@gmx.net, draft-sheffer-emu-eap-eke@tools.ietf.org |
|
2010-03-08
|
09 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Russ Housley |
|
2010-03-08
|
09 | Russ Housley | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document … (1.a) Who is the Document Shepherd for this document? 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? Yaron Sheffer, a co-author, is shepherd for this document. I have reviewed this version and believe it is ready for publication. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been reviewed by members of the CFRG and EMU communities. It has had multiple in depth reviews by community members, including Dan Harkins, Bernard Aboba, David Jacobson, Gabriel Montenegro and Steve Bellovin (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? No. (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? 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 interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. It is noted that the EKE protocol is patented, with the patent due to expire in 2011. IPR statement #1071 was filed accordingly. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There is no "community" behind this document. There is ongoing interest within the community in solving the problem that this document attempts to solve. And several people have expressed support for the document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? 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.) No extreme discontent. (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? IDnits only complains of the trust language (which the most recent XML2RFC appears not to support yet). No formal reviews are applicable. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split. All normative referenes are OK, other than the following two informational RFCs: RFC 2104 (HMAC), RFC 2548 (RADIUS attributes for carrying MSK/EMSK). (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? 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 suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. 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? New registries are defined and initial values are populated. There is no requirement for expert review. (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? No such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. Working Group Summary Was there anything in the discussion in the interested community that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Was the document considered in any WG, and if so, why was it not adopted as a work item there? The document was presented twice to the EMU WG. The WG did not adopt it (or at least one other password-based protocol) despite some interest by participants and the chairs, because it has had its hands full with existing charter items. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document was implemented by a university team, who added support to both an existing EAP client and a RADIUS implementation, and tested for interoperability. Some protocol changes resulted. |
|
2010-03-08
|
09 | Russ Housley | Note field has been cleared by Russ Housley |
|
2010-03-06
|
05 | (System) | New version available: draft-sheffer-emu-eap-eke-05.txt |
|
2010-02-26
|
09 | Russ Housley | Draft Added by Russ Housley in state Publication Requested |
|
2010-01-06
|
04 | (System) | New version available: draft-sheffer-emu-eap-eke-04.txt |
|
2009-11-30
|
03 | (System) | New version available: draft-sheffer-emu-eap-eke-03.txt |
|
2009-07-06
|
02 | (System) | New version available: draft-sheffer-emu-eap-eke-02.txt |
|
2009-02-10
|
01 | (System) | New version available: draft-sheffer-emu-eap-eke-01.txt |
|
2009-02-02
|
(System) | Posted related IPR disclosure: Yaron Sheffer's Statement about IPR related to draft-sheffer-emu-eap-eke-00 belonging to AT&T Bell Laboratories (possibly Alcatel-Lucent today) | |
|
2009-01-29
|
00 | (System) | New version available: draft-sheffer-emu-eap-eke-00.txt |