EMU Password based Method Design Team

The members of the design team are:

The purpose of this design team is to complete the following WG charter item: "A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments."

The output of the design team is one or more documents to the EMU working group. This design team will use a separate mailing list and conference calls.

The initial deliverable is a statement of a basic approach to be used in developing the method sent to the working group list for discussion.

As with any design team in the IETF, the output of this design team must be approved by the EMU working group nor carries any special consideration in development of EMU working group consensus.

Literature

• IETF#67 EMU WG Meeting Slides - http://www3.ietf.org/proceedings/06nov/slides/emu-3.pdf
• PEAPv0 - http://tools.ietf.org/id/draft-kamath-pppext-peapv0-00.txt
• PEAPv2 - http://www.watersprings.org/pub/id/draft-josefsson-pppext-eap-tls-eap-10.txt
• EAP-FAST - http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-06.txt
• TTLSv0 - http://tools.ietf.org/id/draft-ietf-pppext-eap-ttls-05.txt
• TTLSv1 - http://tools.ietf.org/wg/eap/draft-funk-eap-ttls-v1-01.txt
• TLS Inner Application - http://tools.ietf.org/wg/tls/draft-funk-tls-inner-application-extension-03.txt
• EAP FAST Provisioning - http://www.potaroo.net/ietf/all-ids/draft-cam-winget-eap-fast-provisioning-03.txt

Phone Conferences

6th December 2006

• Attendees

• • Hannes
  • Ray
  • Charles
  • Joe
  • Pascal

• Introductions

• • Hannes - Siemens Networks - DIME and ECRIT chair - Munich
  • Charles - dept of defense - HOKEY Chair - DC area
  • Ray - Grid Net - utility automation - power automation
  • Pascal - ENST - Research - Security, smart cards and networks - Paris
  • Joe - Cisco - EMU chair - Seattle

• There have been some requests to have the meeting at 9AM PT.

Would Wednesday 9AM PT work fine for this group?

• Approaches to password mechanism discussion

Charles gave summary from IETF in San Diego

Question: Do you have access to the password or just the comparison function?

Conclusions from IETF meeting:

• • only had access to the comparison function
  • Need to transport password through secure means
  • Public key crypto on server
  • Try to reuse existing mechanisms such as TLS

Hannes - agrees on conclusions - try to use existing mechanism not SRP SEKE, instead more PEAP and TTLS

Charles - SPEKE, SRP - access to password or password hash required

Hannes - Password in TLS, tunneled method, drawback too many messages.

Joe - methods like EAP-FAST and TTLS try to meet many requirements, such a crypto-binding. Perhaps these can be optimized.

Hannes - existing methods have shortfalls, such as TTLS does not derive EMSK.

Joe - There is an effort to document EAP methods as informational as they are and not to change them. We would probably not directly reference this, but rather define something similar.

Pascal - Some questions -

• • Do we want identity protection?
  • Do we want mutual authentication?

Joe: Identity Protection, seems like a good requirement especially since we are probably dealing with end users. - Charles: PK makes it easy, for GPSK identity protection was hard

Hannes: agrees

Mutual: Charles - password authentication client - server side authenticated by public

Charles: Cert vs. Raw public keys - can be supported with just self signed cert, no protocol differences necessary.

Hannes: Mutual auth must be supported

Pascal: EAP-SIM does mutual with secrets

Joe: We would probably use public key on one side and password for the peer. Calculations based on the password alone are usually vulnerable to dictionary attack.

Hannes: EAP-SIM/AKA uses strong key

Pascal: require PKI and PK operations?

Hannes: yes, PK operations seems to be OK with 3G providers (for example), PKI requirements depend upon deployment.

Pascal: Ok

Summary: seems to be agreement on using a tunneling approach based on TLS with a minimal set of attributes sent within tunnel to convey username and password.

• Wiki

Hannes will create a Wiki where we can place references to existing and ongoing work

• Target

For Prague IETF we must agree on approach to be presented to the WG. Ideally we will have a draft started as well.

• Next meeting

Either next week or in January. Take it to the list.

10th January 2007

• Attendees

• • Madjid
  • Hannes
  • Hao
  • Pascal
  • Joe

• Agenda

1. Close on approach to method 2. Assign actions to draft a summary of the approach

Password tunneling within TLS:

Madjid, Hao, Pascal - agree on password tunneling approach.

** general agreement on tunneling within TLS

Is EAP-TLS the right place to start:

Hannes - good place to start

Madjid - start with PEAP?

Joe - base should be standards track

Hao - What are the requirements? channel binding, crypto binding, agility, ...

-- Discussion of framing of attributes within the tunnel

Hannes - DO we need EAP inside TLS?

Joe - not necessary

Pascal - EAP encapsulation for identity privacy, WIMAX

Hannes - WIMAX uses it for device and user authentication not necessarily a requirement for us

Hao - Seems like choices are: Use EAP, RADIUS or own TLV.

Joe - RADIUS is a backed protocol, EAP does not support user name password

Hannes - EAP needs more round trips

Pascal - EAP allows password challenge and response

Hao - regardless we need to frame the message. password comparison necessary

Pascal - TLS tunnel can be vulnerable to man in the middle password should not be in the clear.

Madjid - this is a TLS problem

Hao - TLS approach relies upon security of TLS. If not we should develop a new method

Madjid - Agree

Joe - also can't assume the server has access to a usable password transform

Pascal - Is RADIUS appropriate?

Hannes - perhaps it is, other groups are looking at encapsulating RADIUS and DIAMETER to provide more information to end users

Madjid - TLV could look like RADIUS or Diameter

Pascal - RADIUS provides its own protection, you would need to remove this

Joe - Also we are not looking at encapsulating and decapsulating this messages. They are between the client and RADIUS server.

Hannes - encapsulation and decapsulation not really necessary. Could even use XML. What is easy to design?

Joe - Simple TLV may be better

Pascal - ASN.1 could be possible

Hannes mentions that the XML suggestion was a joke.

Joe - What advantage does it bring us?

framing within tunnel needs more discussion

• Actions

• • Hannes - statement of overall TLS based approach
  • Pascal - start discussion on format within tunnel
  • Hao - description of requirements
  • Madjid - work on a statement to present to working group based on above discussions

14th February 2007

• Attendees

• • Madjid
  • Hannes
  • Hao
  • Joe
  • Pascal

• Agenda

Discuss TLS integration vs. tunnel approach

Humm about the approaches: 5 hums for tunneling approach

Madjid: Messaging framework is needed. No EAP payloads needed at the moment for passwords. Future extensibility possible. Hao: Multiple roundtrips; PAP (CHAP and EAP for the future) Joe: PAP (CHAP and EAP for the future); extensibility for multiple roundtrips important. Pascal: Agrees with the above-mentioned list.

Group agrees to start with PAP and to design the protocol for a multiple roundtrip protocol Messaging framework needs to be defined.

Discuss attribute format

ASN.1 format did not find excitement with all participants. 4 out of 5 participants agreed that we are not going to use ASN.1

Discussion about carry AVPs/TLV payloads on top of TLS application data (record layer). Hannes will compile a proposal.

Discuss 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 )

• pswd_consensus_1.txt: consolidated statement as of Feb 9, 2007

• pswd_consensus_3alpha2_Feb21.txt: pswd_consensus_3alpha2_Feb21.txt
• pswd_consensus_3march2.txt: pswd_consensus_3_march2.txt

-- HannesTschofenig - 25 Feb 2007