IETF EMU WG PP-EAP Protected Password-Based EAP Method draft-zhou-emu-pp-eap-01.txt

1. IETF EMU WGPP-EAPProtected Password-Based EAP Methoddraft-zhou-emu-pp-eap-01.txt Hao Zhou on behalf of PP-EAP Design Team hzhou@cisco.com IETF 69, July 24, 2007

2. Design Team Members • Mohamad Badra • Ray Bell • Charles Clancy • Vijay Devarapalli • Jouni Malinen • Madjid Nakhjiri • Joe Salowey • Hannes Tschofenig • Pascal Urien • Hao Zhou IETF EMU WG

3. Why Another Password-based EAP? • Existing EAP methods: PEAP, EAP-TTLS, EAP-FAST • However: • No Standard RFC based • No standard way to extend data exchanges inside the tunnel • No crypto algorithm agility • WG charter item IETF EMU WG

4. Overview Phase 1 - TLS-based server authenticated tunnel Phase 2 - TLV data exchanged inside the tunnel with protected result indication and crypto-binding exchange Support crypto algorithm agility Extensible IETF EMU WG

5. How the Design Requirements Are Met? • Support secure transport of clear text password to support legacy user name and password databases, such as One-time Password (OTP) and LDAP – send clear text password in Password-Authentication TLV. • Provide mutual authentication – server authentication in Phase 1 and client authentication in phase 2 using password. • Provide resistance to offline dictionary attacks, man-in-the-middle attacks, and replay attacks – provided by TLS. • Comply with RFC 3748, RFC 4017, EAP keying management framework draft (including MSK and EMSK generation) - see security claims & key hierarchy. • Support user identity confidentiality for the peer – exchange real identity in phase 2. • Support cipher suite negotiation and cryptographic algorithm agility – provided by TLS • Support session resumption and avoid the need for use to re-enter the password every time) – provided by TLS. • Support fragmentation and reassembly – provided by TLS. • Cryptographic binding – supported and always enforced, including version negotiation validation • Password/PIN change – supported thru Password-Authentication TLV. • Transport Channel Binding data – supported thru defining and exchange additional TLV. • Support protected result indication – thru Result TLV exchange. • Support for certificate validation protocols – via TLS extension. • Support standard way of extending inner data exchanges to other than password-based authentications – thru defining additional TLVs. IETF EMU WG

6. Highlighted Features • Version negotiation – future extensibility • Protected termination • Crypto-binding • Crypto algorithm agility • Use TLS PRF and HASH, with TLS 1.2, they all can be negotiated. • TLV extension and negotiation IETF EMU WG

7. Protocol Layer +--------------------------------------------------------+ | TLV (Password-Authentication TLV, Result TLV, etc.) | +--------------------------------------------------------+ | TLS | +--------------------------------------------------------+ | PP-EAP | +--------------------------------------------------------+ | EAP | +--------------------------------------------------------+ | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.) | +--------------------------------------------------------+ IETF EMU WG

8. Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Ver | Message Length : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Message Length | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags 0 1 2 3 4 +-+-+-+-+-+ |L M S R R| +-+-+-+-+-+ L Length included; set to indicate the presence of the four- octet Message Length field M More fragments; set on all but the last fragment S PP-EAP start; set in an PP-EAP Start message R Reserved (must be zero) IETF EMU WG

9. TLV Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Optional TLV 1 - Mandatory TLV R Reserved, set to zero (0) TLV Type A 14-bit field, denoting the TLV type. Allocated Types include: Password-Authentication TLV Result TLV NAK TLV Vendor-Specific TLV Crypto-Binding TLV IETF EMU WG

10. Password Authentication Exchanges • Exchanged using Password-Authentication TLV. • A simple format is selected than ASN.1, XDR: • Simplicity • Lower cost to implement • Uses "LABEL=Value” format: • “REQUEST=Please enter your user name and password.” • “RESPONSE=[username]\0[password]” • Error codes defined to handle password change, retries, etc., similar to MSCHAPv2. • Non-ASCII credential exchanges are support using UTF-8 and stringprep. IETF EMU WG

11. Extensibility • Additional TLVs can be defined to support exchanges of other type of authentications, such as CHAP, MSCHAP, even certificate-base or bio-based authentication. • Additional TLVs can also be defined to exchange arbitrary data exchange between the peer and the server. This can be used to support channel-binding etc. • Additional Vendor-Specific TLVs can be defined to support non-standard and experimental data exchange. • Basic operation of the protocol including its session key generation and crypto-binding exchange remains unchanged. IETF EMU WG

12. Next Steps • More Reviews • Issue Resolutions • Adopted as WG Item • WGLC? IETF EMU WG