1 / 9

EAP Method Update

EAP Method Update. PSK Design Team Status Update Mar 20, 2006. Design Goals. Create a Pre-Shared Key mechanism, that is based on strong shared secrets meets RFC 3748 and RFC 4017 req’s is simple and compact enough implementable in resource constrained environments. Milestone:

sfernando
Download Presentation

EAP Method Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EAP Method Update PSK Design Team Status Update Mar 20, 2006

  2. Design Goals • Create a Pre-Shared Key mechanism, that • is based on strong shared secrets • meets RFC 3748 and RFC 4017 req’s • is simple and compact enough • implementable in resource constrained environments. • Milestone: • Submit draft by next IETF for WG consideration

  3. Design Team • Jari Arkko • Mohamad Badra • Uri Blumenthal • Charles Clancy • Lakshminath Dondeti • David McGrew • Joseph Salowey • Suman Sharma • Hannes Tschofenig • Jesse Walker

  4. Decisions made so far… (1) • Not based on TLS-PSK • To limit number of required crypto primitives • To simplify implementation • Symmetric key credentials only (no PK) • Performance • Avoiding implications of multi-layered trust/CA • Limiting the number of crypto primitives • No true multi-party (more than 2) • EAP framework shuns three+ party models

  5. Decisions made so far… (2) • Fast resumption: no need • must be fast enough to begin with • Channel binding – must support • Because of tunneling possibilities • Format and encryption req’s are open issues • Algorithm agility – necessary • Because some algorithms are broken, and others will be • How granular “agility” is – is an open issue • Provisioning – SNMP  • Simply Not My Problem • Out of scope of this design team

  6. Keying approach • Generation/transport vs. Derivation • Team favors derivation • Both existing proposals do derivation • Charles and Hannes • Looking at transport, but… • not as sound cryptographically

  7. Algorithms to implement • Minimize number of required primitives • Ideally base on one primitive • Implementation simplicity! • Favoring block cipher as base primitive • Example: entire suite based on AES only • FIPS compliance • Team made NIST aware of EMU work • Hope: get NIST to bless EMU key derivation • Compliance with existing FIPS is considered

  8. Open Issues • Randomness source • Can we live with only one peer contributing? • Alternative: both peers must contribute • Cipher selection • Nice to do everything with just one primitive • However need to clear AES with NIST • NIST hasn’t yet defined AES-based key derivation • Algorithm agility – how granular should it be? • Identity Hiding – postpone discussion • Need to see justification/demand first • Likely to be added as an extension (later) • Channel bindings • Define format • Determine if encryption is necessary

  9. Questions? None – Thank you!

More Related