1 / 20

TNC EAP

TNC EAP. IETF EAP WG August 2005 John Vollbrecht jrv@mtghouse.com. TNC - Background. Subgroup of TCG - Trusted Computing Group Support authorizing of “platform integrity” Concept is to allow checking of “state” of client prior to allowing access to the network

halona
Download Presentation

TNC EAP

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. TNC EAP IETF EAP WG August 2005 John Vollbrecht jrv@mtghouse.com

  2. TNC - Background • Subgroup of TCG - Trusted Computing Group • Support authorizing of “platform integrity” • Concept is to allow checking of “state” of client prior to allowing access to the network • If client needs remediation it is quarantined • After remediation the client may be checked again and allowed admission to the network

  3. Reason for Presentation • TNC is considering implementation of a new EAP method • Method will typically be an “inner” method carried by an “outer” method • The Method may run with other methods, for examples methods doing user authentication and/or platform authentication • This presentation outlines the problem we are attempting to solve and why we are considering this approach • We are looking for feed back on this approach from the EAP group and possible to develop a formal liason between TNC and the EAP group

  4. TNC as an element of authorization • TNC provides client integrity checking and authorization • Other checks may be done at same control time, typically during access control dialog • User authentication • Platform authentication • Other • All checks are made before allowing access • Most straightforward way seems to be to allow multiple checks to be done within a outer/trusted EAP method

  5. TNC Architecture

  6. TNC Architecture - with PTS

  7. TNC Status • Three TNC Specs have been released • IF-IMC • IF-IMV • Architecture • More are in development • IF-T • IF-TNCCS • IF-PEP • TNC-EAP method

  8. TNC Architecture status - Diagram

  9. TNC IF-T • Transport between TNCC and TNCS is focus of this presentation • IF-T is the transport between NAR and NAA • Use cases and Architecture spec for this is being developed by a subgroup within TNC • Draft currently being discussed in the TNC group • Group direction is to use Inner TNC-EAP method within a “trusted” EAP method to carry traffic between TNCC and TNCS • TNC Group would like feedback from IETF-EAP wg about appropriateness of this approach

  10. Expanded NAR/NAA architecture

  11. Elements of NAR • NAR consists of multiple elements • Access Control module(s) • Trusted EAP module(s) • Access Control Use Cases being developed for • 802.1X, 802.16, IKEv2, TLS/VPN setup, and SOAP/SAML • Trusted EAP Use Cases being developed for • TTLS, PEAP, FAST, and for non-EAP TLS tunnel

  12. TNC as EAP Method • Communication between TNCC and TNCS is defined as a dialog with one or more request-response exchanges, and • EAP method provides a mechanism for defining a sequence of exchanges resulting in an indication of success or failure from each side and possibly (need input from IETF) the generation of keying material on each side • A EAP-TNC method can be an inner method on any trusted EAP method that can carry inner methods

  13. Reasons for choosing an EAP method • Alternative to EAP method might be to send TLV or AVPs • TNC requires a multi exchange dialog which is suitable to EAP method • Other services may require just sending a set of parameters which can be done with TLV or AVP • Other reasons for using EAP method • Methods have well defined interfaces - states, result signaling, keying information • EAP-TNC Method can be carried in any “outer” EAP method • Methods can be defined independently of the protected methods carrying them • Methods may be tested independently of the mechanism carrying them

  14. Reasons for EAP Method 1.TNC defines a handshake as a dialog which includes one or more request/response with the TNCS making a recommendation at the end of the dialog. 2.EAP methods interface with a defined state machine that specifies how to control EAP conversations and interface with EAP methods. This is important because TNC is a conversation, not set of attributes. 3.EAP methods can be carried in any currently known “protected” method; The protected methods include a state machine that can run “inner” EAP methods. 4.Protected methods also carry other message types such as TLVs or AVPs. These tend to be are slightly different in each “protected” method. EAP methods are identical in all protected methods. 5. If carried as TLVs or AVPs then one must include control mechanisms to let the lower layer know the result of a conversation and when it is done. This is done as part of EAP method.. 6.EAP methods can be written independently of the “protected” methods carrying them. They can be installed in the same way as other EAP methods. 7. An EAP method can be stand-alone for inhouse as well as interoperability testing. This permits testing between TNCC and TNCS as well as between IMCs and IMVs independently of any protected method.

  15. Outer/Inner Method General Flow

  16. Issues with Outer method • No standard “outer” method currently exists • Will one or more be standardized in the future • Will it be possible to add “inner” capabilities to existing or planned methods? • To do a “standard” implementation one has to have standard at all levels. This sees to mean that a standard for outer methods must be available or the TNC must create a standalone TNC EAP method. TNC prefers the former.

  17. Issues with Outer Method -2 • Keying requirements of Inner methods and method of validating them by outer method is not defined • Can this be included in Key framework as an extension? • Sequencing inner EAP methods and sending intermediate results from inner method to outer methods is not standardized • This is probably part of defining standard outer method • Would like feedback from IETF about plans for this - TCG is interested in formal liason with EAP working group. Is this appropriate

  18. EAP-TNC Method • Work is underway in defining an EAP-TNC method • Method defines messages, states, keying material generation • Plan to create RFC and request review from EAP wg • EAP-TNC method can work over any “outer” method. • Outer method definitions seem to be responsibility of IETF • TNC will provide use cases if useful • Is this correct interpretation

  19. Other TNC Issues • Not for discussion today but issues at some point • Interface with PEP • TNC re-handshake • Interface with PTS - Platform Trust Services

  20. Questions? • John Vollbrecht • Meetinghouse Data Communications • jrv@mtghouse.com • For info on TCG access to released specs - https://www.trustedcomputinggroup.org/home

More Related