1 / 8

ICOS BOF

ICOS BOF. EAP Applicability Bernard Aboba IETF 62, Minneapolis, MN. Outline. EAP usage scenarios RFC 3748 applicability statement Process of analyzing new applications. EAP Usage Scenarios. EAP parties: EAP peer, EAP server/AAA server, authenticator Basic scenarios

acalderon
Télécharger la présentation

ICOS BOF

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. ICOS BOF EAP Applicability Bernard Aboba IETF 62, Minneapolis, MN

  2. Outline • EAP usage scenarios • RFC 3748 applicability statement • Process of analyzing new applications

  3. EAP Usage Scenarios • EAP parties: EAP peer, EAP server/AAA server, authenticator • Basic scenarios • Peer and authenticator speak some other protocol, authenticator and AAA server speak AAA protocol • This is basic AAA usage (prior to EAP) • Peer and authenticator speak EAP; authenticator and EAP server/AAA server speak EAP over AAA • This is the basic EAP/AAA scenario (e.g. 802.11i) • Peer and authenticator speak some other protocol, but use keys derived from a previous EAP conversation between the same EAP peer and EAP server • This is a new application not yet defined.

  4. RFC 3748 Applicability Statement • Applies to Scenario 2 only: EAP over the wire • Realm of applicability • EAP was designed for use in network access authentication, where IP layer connectivity may not be available. • Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. • Limitations • Just enough support for the reliable transport of authentication protocols, and no more. • EAP assumes ordering guarantees from the lower layer; out of order transmission not supported • EAP authentication methods generating payloads larger than the EAP MTU need to provide fragmentation support • It may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP. • Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. • Where significant packet loss occurs along the path, EAP methods requiring many round-trips can experience difficulties.

  5. Process for Analyzing New EAP Applications • System level security analysis required for EAP key management applications • Requirements outlined by Russ Housley at IETF 56 • All EAP key management applications need to meet these requirements • EAP methods used in those applications need to meet the requirements as well • EAP Key Management Framework document (work in progress) • Focus is on Scenario 2: defining and analyzing existing usage • EAP Key Management Extensions may handle new applications (Scenario 3)

  6. Acceptable solution MUST…(Housley, IETF 56) • Be algorithm independent protocol • For interoperability, select at least one suite of algorithms that MUST be implemented • Establish strong, fresh session keys • Maintain algorithm independence • Include replay detection mechanism • Authenticate all parties • Maintain confidentiality of authenticator • NO plaintext passwords

  7. Acceptable solution MUST also … • Perform client and NAS authorization • Maintain confidentiality of session keys • Confirm selection of “best” ciphersuite • Uniquely name session keys • Compromise of a single NAS cannot compromise any other part of the system, including session keys and long-term keys • Bind key to appropriate context

  8. Feedback?

More Related