EAP Keying Framework

1
EAP Keying Framework

• Joe, Jari, Pasi, Bernard
• IETF-63 in Paris, France
• Tuesday, August 2nd, 2005

2
Outline

• Role of the different documents
• Issues
• Next steps

3
Role of the Documents

• Draft-housley-aaa-key-mgt
• Describes the requirements for AAA key management
• Intended for eventual publication as a BCP
• Draft-ietf-eap-keying
• Describes existing EAP key management usage
• Analyzes existing usage against the requirements
  in draft-housley
• Is reference to draft-housley normative?
• EAP key management extensions
• Describes extensions to EAP key management model
• Analyzes new usage against the draft-housley
  requirements
• Early version available here
• http//www.drizzle.com/aboba/EAP/draft-aboba-eap-
  keying-extns-00.txt

4
Issues (1/2)

• Already closed
• 300 - Terminology for port
• 305 - Appendix cleanup
• Discussed in next presentation
• 306 - Channel bindings

5
Issues (2/2)

• Discussed today
• 294 - Analysis of existing EAP usage
• 299 - Key caching
• 302 - Domino effect clarifications
• 307 Deletion of the security reqts. section
• 279 - Additional keying protocol reqts

6
294 - Analysis of existing EAP usage

• Analyze what?
• 802.1x, PPP, 802.11i
• Analyze against
• Housley criteria document (may incorporate a
  version of these principles in the document)
• Actual Analysis
• Issue 294

7
299 - Key caching

• Keys internal to EAP methods may be cached (fast
  reconnect etc)
• AAA-Key and TSK caching, if any, happens in the
  lower layer currently
• Keeps different lower layers separated
• We may need to better define lower layer
• Does this mean key naming for these keys at
  EAP/AAA layer is not needed?
• EMSK and AMSK caching is a possible future
  extension
• Could define uses where keys derived from the
  EMSK are cached outside of EAP
• But not in this document!

8
302 - Domino effect clarifications

• Ongoing discussion on the list
• Original requirement unclear
• What is compromised?
• Not just authenticator, but AAA and end nodes as
  well
• What is compromised as a result?
• Nodes, keys, authentication server,
  authenticator, ability to spoof one authenticator
  as another,
• But still need to stay within the scope of our
  system not include, e.g., compromises of
  other nodes due to passwords sent in an e-mail
  over the compromised data channel

9
307 Deletion of the security reqts. section

• Mostly editorial
• Consolidation of Section 7 requirements (AAA,
  EAP, SAP) into Section 4
• Removal of other sections redundant with RFC
  3748, Section 4 or Section 6

10
279 - Additional keying protocol reqts

• 307 may already remove the need for this
• Need to watch for not going beyond the scope of
  the document
• go through the document and make sure we cover
  these already.

11
Next Steps

• Focus on the main document
• Please review -08!
• Resolve existing issues
• Produce a -09 version in 6 weeks
• WGLC for -09
• Revised final draft for IETF-64
• Review of draft-housley
• Need to review, resolve issues
• Continue with extensions in IETF-64 and beyond