130 likes | 142 Views
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
E N D
NEA Requirement I-DIETF 67 – San Diego Paul Sangster Symantec Corporation NEA Working Group
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
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
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
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
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
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
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
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
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
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
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
Questions? NEA Working Group