1) Overall approach: Use a tunneled approach. 
The team has agreed on a list of requirements listed at the bottom. Based on the requirements, the team has agreed to work on a TLS based EAP method using password based client authentications without server's direct access to passwords.
comment: TLS and server authentication is to be used for tunneling of client password authentication exchanges.
The team is aware of the well-known vulnerabilities of tunneled authentication methods, such as those to man in the middle attacks. The team is using a TLS based approach to get around issues with server unauthenticated tunnels and will include crypto-binding as a SHOULD have in its design to mitigate these concerns.

Two different approaches have been discussed:

1. PEAP/TTLS/EAP-FAST - establish TLS tunnel and exchange password as data within tunnel.
2. TLS "native" - establish TLS security and exchange password as part of TLS messaging

There seems to be more previous work on approach 1. A consensus still needs to be achieved.

2) Method Type:
The team agrees that EAP-TLS method type is reserved for certificate authentications with EAP-TLS. This means new EAP method type/s need to be used to represent TLS enhancements using long term credentials other than certificates. 
It is however to be determined whether each EAP-TLS enhancement will have its own type, or one EAP method type will represent all TLS based EAP methods using a variety of long term credentials. Following the latter approach requires addition of exchanges allowing for negotiation of the EAP-TLS "flavor" to the existing EAP signaling (e.g. EAP start). This needs further investigation.

3) Data formats:
The group has been discussing the possible data formats:
a) XDR: external data representation standard RFC 1832, used in TLS protocol (RFC2246)
b) AVP: a flat tree structure to represent a list of attributes, 
c) ASN.1: Abstract Syntax Notation One: ISO standard used for X.509. This is structured as a tree of elements. Used for certificates, SNMP and LDAP.

The team is discussing on a choice between AVPs and ASN.1, while it has already ruled out XDR.
The team has reached consensus on use of AVP rather than ASN.1 due to perceived complexity of ASN.1 parsers relative to the need at hand.


4) Requirements
MUST HAVE:
Support legacy user Data bases, so clear text password needs to be 
sent to the server 
-Mutual authentication (offered by TLS)
- Protection of the clear-text password (Integrity and confidentiality
protection - offered by TLS
-Replay protection - offered by TLS
-Protection against MITMs, such as dictionary attacks, or attacks results from server unauthenticated tunnels - (offered by TLS Standard Key Generation) 
-Adequate MSK and EMSK generation
- Session Resumption (to avoid the need for new passwords in conjunction with resuming a session), a MUST requirement for one-time passwords,
-Protected Result Indication
-Support for Multiple roundtrips
-Identity Protection 
-Ciphersuite negotiation (offered thru TLS). Need to define MUST supported ciphers.
-Crypto-agility
 
NICE TO HAVE: 
-Flexibility to extend the communications inside the tunnel 
(e.g., allow other inner methods, especially password-based 
> methods, multiple inner method in sequence, etc.) 
-Fragmentation and reassembly
-Exchange of arbitrary parameters in a secure channel (channel 
> binding, NEA, etc.)
-Capability exchange (ability to perform EAP keying versus newer keying and re-authentication methods) 



MAY HAVE
-crypto-binding (only needed if running other inner methods generating keys)
-Protected method negotiation (only if other inner method is allowed) Optimized for light weight  devices (minimize PKI requirement, number of roundtrips and computation, e.g., use TLS-PSK, TLS-Ticket )
comment: team is charted to look at password authentication, thus crypto-binding and protected method negotiation might be out of scope.



Open issues:
-choice of TLS approach
-Fragmentation must have or nice to have?
-what does support for multiple round trips.