Skip to main content

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
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