date: Feb 14, 2007, 



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 MAY include crypto-binding as a mitigatiion mechanisms (this needs further investigations).

Two different approaches have been discussed within the design team:

1. TLS tunnel- establish TLS tunnel and exchange password as data within tunnel.
2. TLS "native" - extend TLS ciphersuites to allow for use of passwords

The design team achieved near-full-consensus on approach 1 based on the follows pros:

1) There seems to a fair amount of previous work on approach 1: PEAPv2/TTLSv1/EAP-FAST and this seems to reduce the work-load 
2) Easier extensibility, future efforts for extending TLS to support other than password authentication mechanisms (CHAP, MS-CHAP) could be easily achieved.
3) Allows use of external use of available TLS libraries, and reduces interdependency to outside TLS developer to modify their TLS library.
4) Can be done within EMU WG


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) Message formats:
After agreeing on use of AVPs, the group discussed various messaging options:
a) Creating TLS record layer extensions, this would require TLS WG buy-in
b) Carrying data within TLS application layer, this seemed to be the prefered approach.
Based on b, several alternative were proposed:
b1) Define only AVPs needed for password authentication
b2) Use EAP as a way to carry PAP, CHAP, etc. exchanges
b3) define a messaging framework that provides requests/response/result indication, etc.

b3) seemed to be the most favored one based on the following pros:
-creating AVP-alone does not seem to properly address the multi-roundtrip requirements (password authentication may require 2 RT or more).
- result indication is better addressed
-Extensibility: Although the current focus is password authentication, the design should allow tunneling of other authentication methods (CHAP, etc) in the future, a messaging framework would allow transport of a variety of exchanges (including EAP based exchanges).

open issue: AVP framing choices and message framework

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 additional roundtrips for password changes and PIN updates
-Identity Protection 
-Ciphersuite negotiation (offered thru TLS). Need to define MUST supported ciphers.
-Crypto-agility
 
NICE TO HAVE: 
-Fragmentation and reassembly
-Ability to support exchange of arbitrary parameters within the secure channel (e.g. channel 
binding parameters, , etc.)



MAY HAVE
--Capability exchange (ability to perform EAP keying versus newer keying and re-authentication methods) 


the following are considered out of scope and thus not actively pursued:
-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 )


closed issues:
-choice of TLS approach: use TLS tunnels.
-Use of XDR and ASN.1 has been ruled out. 

Open issues:
-AVP framing choices and message framework
-Fragmentation must have or nice to have?
-what does support for multiple round trips.
-Do we use one EAP method type for TLS tunneled password-auth only, or one EAP method type of all non-cert credentials within TLS tunnel
-do we need support for negotiation?