[Emu] Password-Based EAP Method: Proposal to Move Forward

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

Hi all,

I went through TTLSv0, through the EAP Passwd-based DT and my notes from 
the EMU IETF#68 meeting.

Here is a short summary:

* Within the Design Team we have investigated different EAP methods 
including the ability to carry EAP payloads, CHAP, MS-CHAP and 
MS-CHAP-V2 in addition to PAP. Within the design team we were not sure 
about the approach we should take. Hence, we solicited feedback from the 
EMU working group. See
http://www1.ietf.org/mail-archive/web/emu/current/msg00394.html

As part of the design team work a strawman proposal was compiled. Please 
find it at:
http://www.tschofenig.com/svn/draft-zhou-emu-pp-eap/draft-zhou-emu-pp-eap-00.txt

* At the IETF#68 EMU WG meeting (see 
http://www3.ietf.org/proceedings/07mar/slides/emu-3.ppt) a number of 
questions were asked and the following feedback was provided (based on 
my notes):

- Protected result indication: Indicated that it is required.
- Channel Binding: Sam indicated that this is required due to the 
Housley criteria.
- Password Pin/ changes: Provided as an extension.
- CHAP, MS-CHAP, MS-CHAP-V2 Support: Provided as an extension.
- EAP Support: Provided as an extension
- Crypto-Binding: Indication that Crypto-Binding should be added to the 
base specification even though it is not required for PAP.

Removing CHAP, MS-CHAP, MS-CHAPv2 from draft-zhou-emu-pp-eap-00.txt 
makes it obviously quite similar to 
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt (when 
CHAP, MS-CHAP, MS-CHAPv2, EAP is removed and Crypto-Binding added). This 
is not a big surprise given that there are only finite ways to encode 
packets carried on top of EAP-TLS.

Taking an existing document and removing some parts, rewriting other 
parts and adding some section OR creating a new document by adding 
content from other documents is not a big difference.

Here is my conclusion and a suggestion to move forward:

* The EAP-TLS part would be based on 
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt

* Add a crypto-binding similar to the one defined in 
http://www.tschofenig.com/svn/draft-zhou-emu-pp-eap/draft-zhou-emu-pp-eap-00.txt

* Use the MSK/EMSK generation from 
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt
  http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt does 
not generate an EMSK -- this needs to be added since it is mandatory.
  Unfortunately, the details with regard to the MSK generation in 
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-08.txt 
are different to
  http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt .

* Packet format:
  We could make use of the packet format defined in Section 9 of 
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt
  (that is based on Diameter).
  Section 8 of 
http://www.watersprings.org/pub/id/draft-funk-eap-ttls-v0-00.txt when we 
base our work on the recent EAP-TLS work.
  We would duplicate the EAP-TLS work if we were to include Section 8 
and create inconsistency.

* Add protected results indication as requested

* Add channel binding as requested
  The question is just which approach.

--- stop here for the base document // something for discussion ---

* Define an extension for EAP usage in a separate document (including 
the multiple authentication concept), if someone wants it. This at least 
reflects what most people wanted at the meeting. In some sense this is a 
pure document handling aspect. For multiple authentication EAP runs it 
would be necessary to apply multiple crypto-bindings. For the 
crypto-binding to work it would be necessary for EAP-TLS to export 
keying material. EAP-TTLSv0 does not address this aspect.

CONCLUSION:

Does this address Bernard's concern
"
In my discussions with customers, I invariably hear complaints about 
this explosion, and about various interoperability and compatibility 
problems that it causes.  Simply put, customers do not want "yet another 
password-based EAP method";  they want a single method that is widely 
implemented and interoperable.
"
?

I don't know. It depends where the interoperability and compatibility 
problems come from. Is an EAP method that is based on a previous one 
with enhancements reflecting the state-of-the-art a new protocol or not?

Ciao
Hannes


_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu