110 likes | 203 Views
EAP Keying Framework. Joe, Jari, Pasi, Bernard IETF-63 in Paris, France Tuesday, August 2nd, 2005. Outline. Role of the different documents Issues Next steps. Role of the Documents. Draft-housley-aaa-key-mgt Describes the requirements for AAA key management
E N D
EAP Keying Framework Joe, Jari, Pasi, Bernard IETF-63 in Paris, France Tuesday, August 2nd, 2005
Outline • Role of the different documents • Issues • Next steps
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
Issues (1/2) Already closed: • 300 - Terminology for port • 305 - Appendix cleanup Discussed in next presentation • 306 - Channel bindings
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
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
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!
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
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
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.
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