1 / 15

NEA Working Group IETF meeting July 27, 2010

NEA Working Group IETF meeting July 27, 2010. nea [-request]@ ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com. Note Well.

rad
Download Presentation

NEA Working Group IETF meeting July 27, 2010

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. NEA Working GroupIETF meetingJuly 27, 2010 nea[-request]@ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com IETF NEA Meeting

  2. Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: • The IETF plenary session • The IESG, or any member thereof on behalf of the IESG • Any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices • Any IETF working group or portion thereof • The IAB or any member thereof on behalf of the IAB • The RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

  3. Agenda Review 1300 Administrivia Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 Description of NEA Asokan attack 1345 Open Discussion 1435 Consensus Questions 1450 Next Steps 1455 Milestones 1500 Adjourn IETF NEA Meeting

  4. WG Status – No change from last IETF • Published as RFC: • PA-TNC: RFC 5792 (Mar 2010) • PB-TNC: RFC 5793 (Mar 2010) • Individual PT proposals submitted (Jan 4) http://www.ietf.org/id/draft-sangster-nea-pt-tls-00.txt http://www.ietf.org/id/draft-hanna-nea-pt-eap-00.txt http://www.ietf.org/id/draft-cam-winget-eap-nea-tlv-00.txt http://www.ietf.org/id/draft-cam-winget-eap-tlv-00.txt • Virtual interim NEA WG meeting held (Jan 28) IETF NEA Meeting

  5. NEA Reference Model IETF NEA Meeting

  6. NEA Reference Modelfrom RFC 5209 NEA Client NEA Server Posture Attribute (PA) protocol Posture Collectors Posture Validators Posture Broker (PB) protocol Posture Broker Client Posture Broker Server Posture Transport Client Posture Transport Server Posture Transport (PT) protocols IETF NEA Meeting

  7. PA-TNC Within PB-TNC Within PT PT PB-TNC Header PB-TNC Message (Type=PB-Batch-Type, Batch-Type=CDATA) PB-TNC Message (Type=PB-PA, PA Vendor ID=0, PA Subtype= OS) PA-TNC Message PA-TNC Attribute (Type=Product Info, Product ID=Windows XP) PA-TNC Attribute (Type=Numeric Version, Major=5, Minor=3, ...) IETF NEA Meeting

  8. NEA Asokan Attack IETF NEA Meeting

  9. NEA Server NEA Client PT Trust Model • If the NEA client is configured to only talk to trusted/authorized NEA Servers, then MiTM attacks are mitigated • If the NEA client is configured to allow it to talk to untrustworthy NEA Servers, then a MiTMcan access and intercept the conversation. Tunnel Establishment IETF NEA Meeting

  10. NEA Server NEA Client PA Trust Model • To address the lying endpoint problem,the trusted party at the endpoint can establish the authenticity of the Posture Attributes in a way that the Posture Validator can verify them. PA conversation IETF NEA Meeting

  11. Asokan Attack on NEA ☺ • Preconditions • NEA Assessment • CorpLaptop Infection • Lying Endpoint Detection (PA Trust Model) • SpyLaptop configured to allow communication with untrustworthy SpyServer(PT Trust Model) • PA Forwarding attack ! ! CorpUser CorpLaptop CorpServer ☺ SpyUser SpyLaptop SpyServer Any questions? IETF NEA Meeting

  12. Consensus Check Question • NEA Asokan attack needs to be addressed? • Yes • No • Don’t know IETF NEA Meeting

  13. Proposed Next Steps • Address PT trust model in base PT protocol I-Ds • Address PA trust model in PT extension I-D • PT-independent IETF NEA Meeting

  14. Milestones Aug 2010 Set up design team to work on PT extension I-D Oct 2010 Output of Design team due Nov 2010 Review and Resolve issues with PT I-Ds at IETF 79 Dec 2010 Publish -00 NEA WG PT I-Ds Jan 2011 Resolve issues with -00 NEA WG PT I-Ds Feb 2011 Publish -01 NEA WG PT I-Ds Mar 2011 Resolve issues with -01 NEA WG PT I-Ds at IETF 80 Apr 2011 WGLC on -01 NEA WG I-Ds May 2012 Publish -02 NEA WG I-Ds Jun 2012 IETF LC IETF NEA Meeting

  15. Adjourn IETF NEA Meeting

More Related