1 / 13

NEA Requirement I-D IETF 67 – San Diego

NEA Requirement I-D IETF 67 – San Diego. Paul Sangster Symantec Corporation. Agenda. Discussion of historical requirements I-D Draft-khosravi-nea-requirements-01.txt July 2005 version, pre-NEA 2 nd BOF Consider contents as input to new NEA requirements I-D Document’s Terminology

jakeem-barlow
Download Presentation

NEA Requirement I-D IETF 67 – San Diego

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 Requirement I-DIETF 67 – San Diego Paul Sangster Symantec Corporation NEA Working Group

  2. Agenda • Discussion of historical requirements I-D • Draft-khosravi-nea-requirements-01.txt • July 2005 version, pre-NEA 2nd BOF • Consider contents as input to new NEA requirements I-D • Document’s Terminology • Review Requirements: • General requirements • PA, PB and PT protocol requirements NEA Working Group

  3. Pre-NEA WG I-D draft-khosravi-nea-requirements-01.txt Primary Contributors: • Editors: • Hormuzd Khosravi, Intel • Paul Sangster, Symantec • Content authors: • Kevin Amorin, Harvard University • Diana Arroyo, IBM • Uri Blumenthal, Intel • Steve Hanna, Juniper • Thomas Hardjono, SignaCert • Ravi Sahita, Intel • Mauricio Sanchez, HP • Jeff Six, NSA • Joseph Tardo, Nevis • Susan Thomson, Cisco • John Vollbrecht • Hao Zhou, Cisco NEA Working Group

  4. I-D Contents • Introduction • Architecture and Components • Common Requirements • Protocol Requirements • Posture Attribute (PA) protocol • Posture Broker (PB) protocol • Posture Transport (PT) protocol • Security Analysis • Operational Considerations • Security Considerations NEA Working Group

  5. Definitions • Component – Software, hardware or firmware entity performing a particular logical function within the NEA conceptual architecture (e.g. AV software or a Firewall or more generally an OS kernel.) • Message – Self contained unit of communication between components (e.g. PA message might carry a set of attributes from a Posture Collector to a Validator.) • Session – Common PB transport connection capable of carrying one or more messages from multiple subscribed Posture Collectors and Validators. • Dialog – Sequence of request/response messages exchanged over one or more sessions. NEA Working Group

  6. Common Requirements • Capable of multi-message dialog • Allow server requests prior and after network access • Possible for client to initiate a posture re-evaluation request • Protection against active/passive attacks by intermediaries NEA Working Group

  7. Common Requirements • PA and PB transport agnostic interfaces • Selection process prefer reuse of existing open standards • Scalable (many collectors and validators on multiple servers) NEA Working Group

  8. PA Requirements • Transport core attributes (vendor, version, operational status, …) • Transport of vendor defined attributes • Validator request of particular client component’s posture • Allow for multiple requests for posture information • Carry validator results and remediation instructions NEA Working Group

  9. PA Requirements • Selection process prefer re-use of existing open standards for transport and attribute representation • SHOULD support expression of prior remediation state (e.g. time, server used.) • Capable of authentication, integrity and confidentiality of attributes, results and remediation instructions • SHOULD optimize transport of messages and minimize PB RTs NEA Working Group

  10. PB Requirements • Capable of carrying the decision and (if present) remediation instructions • Carry naming for collectors and validators (used for message delivery) • Naming should allow for dynamic registration • Multiplex message dialogs between multiple collectors and validators • Capable of authentication, integrity and confidentiality of messages, decision and remediation instructions • SHOULD support grouping of attributes to optimize messages/RTs NEA Working Group

  11. PT Requirements • SHOULD incur low overhead for low bandwidth links • SHOULD be capable of using a half duplex link • MUST NOT interpret the contents of PB messages • Capable of protecting the integrity and confidentiality of the PB messages NEA Working Group

  12. PT Requirements • Reliable delivery of PB messages (detect dups, fragmentation) • Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel. • Establish a restricted session between NAR and NAA prior to allowing general access. • Allow for NAR/NAA session to be initiated from either party when both have assigned network addresses NEA Working Group

  13. Questions? NEA Working Group

More Related