date: March 2, 2007, 



1) Overall approach: Use a tunneled approach to protect password authentication exchanges.
The team has agreed on a list of requirements listed at the bottom. and based on the requirements, the team has agreed to develop a TLS based EAP method for client password authentications without server's direct access to passwords.

TLS is being used since it provides tunneled protection for data (password exchanges, etc) and it provides server authentication to avoid well-known vulnerabilities of tunneled server un-authentication approaches.


Two different approaches have been discussed within the design team:

1. TLS tunnel- establish a TLS tunnel and exchange password authentication related 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 achieved more easily.
3) Allows use of externally 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. 
However, the team seems to agree that all such EAP-TLS enhancements, i.e. TLS protected EAP authentications should share one EAP type regardless of the inner authentication method. The negotiation of the inner method can be done inside the tunnel or outside tunnel (e.g. during EAP start). This is to be investigated.


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 has already ruled out XDR and 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:
1-Support transport of encrypted password to Support legacy user Data/password databases,
2-Provide server authentication
3-Provide resistance to offline dictionary attacks, man in the middle attacks, and replay attacks.
4--RFC 3748, RFC 4017 compliant, compliant with EAP-Keying draft (includes MSK and EMSK generation)
5--active User identity confidentiality for the peer
6-crypto-agility/ cipher suite negotiation (need to define mandatory supported ciphers)
7-Session Resumption (avoid need for new passwords when resuming)
8-Fragmentation and reassembly


Should we include the following as requirements, the team is looking for input from the WG.
1-support password/pin change
2. Support other password based protocols (CHAP, MSCHAP, etc) 
3. Cryptographic binding of password exchange to tunnel 
4. Defined Extension Mechanism
5-Support transport of channel binding data


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, debating:
--Capability exchange (ability to perform EAP keying versus newer keying and re-authentication methods) 
-protected result indication
-would "server authentication" requirement include support for OCSP? When server authentication is certificate based, this may be a requirement.
-Negotiation for inner method authentication inside or outside tunnel. do we need support for negotiation?-cert credentials with TLS tunnel?
-AVP framing choices and message framework
-