1. EAP-PSK v8 IETF 63 – Paris, France August 2005

2. EAP-PSK: an independent submission to IESG Requested EAP method type number allocation Reviewed June 2005 by expert Jesse Walker – Update from v07 to v08 following this review – Ongoing private discussion with J. Walker on remaining open points Opened to any proposal to move forward!

3. Expert review received by EAP- PSK Many thanks to Jesse for his thorough review and detailed comments! Some remarks have been included into EAP- PSK which prompted update of EAP-PSK from v07 to v08 Some issues remain open…

4. AK and KDK derivation Issue: should AK and KDK drivation from PSK take identities of the parties into account? Applicability: problem arises if the same PSK is used by multiple parties (>2), which is explicitly forbidden in the draft (section 2.1.1 «EAP-PSK assumes that the PSK is known only to the EAP peer and EAP server. The security properties of the protocol may be compromised if it has wider distribution ») Proposed solution: – Nice feature but for the sake of simplicity, should this be the case? – Ongoing cryptographic analysis on « simple » ways to do this – The discouraged PSK from password algorithm could be enhanced to better support this feature (already partially supported)

5. Mutual authentication Issue: security review claims mutual authentication is flawed Claim: – This is not the case as mutual authentication is a cut-and- paste from a well-known cryptographic protocol – Only difference is explicit or implicit communication of elements over the wire. Be the communication of these elements explicit or implicit, there are included in the cryptographic calculations according to the protocol!

6. EAP-PSK authentication is a cut- and-paste from AKEP2 Source: [EAKD], Figure 2 Source: EAP- PSK, Figure 8 Notation: [x] K := x || MAC(x,K) = B || A || R A || R B || MAC(B || A || R A || R B,a) = A || R B || MAC(A || R B,a)

7. Key control Issue: only RAND_P (and KDK of course) are used in the TEK, MSK and EMSK derivation Claim: – This is explicitly noted in EAP-PSK section 6.7 («It should be emphasized that the peer has control of the session keys derived by EAP-PSK. In particular, it can easily choose the random number it sends in EAP-PSK so that one of the nine derived 16-byte key blocks (see Section 2.1) takes a pre-specified value. It was chosen not to prevent this control of the session keys by the peer because: a) Preventing it would have added some complexity to the protocol (typically, the inclusion of a one-way mode of operation of AES in the key derivation part). b) It is believed that the peer won't try to force the server to use some pre- specified value for the session keys. Such an attack is outside the threat model and seems to have little value compared to a peer sharing its PSK. This is however not the behavior recommended by EAP in section 7.10 of [2].)Section 2.1[2] – Is this a blocking point?

8. Other miscellaneous issues NAK and Expanded-NAK: To what extent doesn’t EAP-PSK comply with NAKs and Expanded-NAKs? Key naming: what would be the purpose and the value of EAP-PSK including explicit key names as there is no fast reconnect mechanism? And usual wording and clarity of text…

9. And now? Take the opened review issues to the list? Add more issues?

10. Any feedback welcome! Florent Bersani, France Telecom R&D florent.bersani@francetelecom.com