NEA Requirement I-D IETF 68 – Prague

1. NEA Requirement I-DIETF 68 – Prague Paul Sangster Symantec Corporation

2. Agenda • Reference Model – from IETF 67 • draft-ietf-nea-requirements-01.txt • Attribute Types • Use Case Examples • Open Discussion Topics • Privacy Considerations • Security Considerations • Requirements NEA Working Group

3. NEA Reference ModelAgreed Upon at IETF 67 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 NEA Working Group

4. Desired Usage Models • Leverage common Reference Model to enable: • Request/response for Posture information • Request for compliance to given policy • Allow for re-use of assertions from prior assessments • Different types of Attributes enable these models over the PA protocol NEA Working Group

5. Attribute Types • NEA WG will define “base set of standard posture attributes” • Requirements I-D does not define specific Attributes • These Attributes will be defined post-requirements • Describes types of Attributes based on common role • Types of Attributes • Subset of Attribute name space with common role • Seven types of Attributes defined • Each type enables an expected usage model • One type is for requesting Posture information • Attribute types used in example protocol exchanges • Indicates expected sender of particular type of Attribute NEA Working Group

6. Attribute Types Sent by Server • Request Attributes • Desired Posture information from client • Policy Attributes • Compliance policy client expected to meet • Result Attributes • Result of Assessment of client Attributes • Remediation Attributes • Instructions on how to repair client • Specific Attributes will not be specified by NEA NEA Working Group

7. Attribute Types Sent by Client • Posture Attributes • Report information about Endpoint configuration • Compliance Claim Attributes • Claim of compliance to a requested policy • Assertion Attributes • Recent Assessment results for consideration during current assessment • Types may be used in combination NEA Working Group

8. Attribute Type Relationships • Posture Information Exchange • Request Attributes for particular component(s) information • Posture Attributes with requested component(s) Posture • Assertion Attributes stating prior component compliance • Policy Compliance Exchange • Policy Attributes express (or reference) desired policy • Compliance Claim Attributes provide claimed answer • Final Compliance Result • Result Attributes describe compliance level (yes, no, partial) • Remediation Attributes instruct how to become compliant • Assertion Attributes for future client use NEA Working Group

9. Use Case Examples • I-D contains 5 use case scenarios • Initial Assessment • Triggered by network connection request • Triggered by service request • Triggered by endpoint/user • Re-assessment • Triggered by NEA client • Triggered by NEA server • Each use case has detailed example flows NEA Working Group

10. Network Connection Example • IT employee boots computer causing request to join network • NEA Server requests Posture information • NEA Client replies with requested Posture • Compliance policy indicates client out of date • NEA Server sends failed result and remediation instructions • NEA Client updates system and re-requests access to the network NEA Working Group

11. Network Connection Example Request Access N EA C LIENT E NDPOI N T N EA S ERVER S YSTEM Request Attributes: Send Patch, AV, Firewall Posture Check Privacy Policy Posture Attributes: Patch, AV, Firewall Posture Config. Data Check Compliance Policy Result Attributes: Failure – OS Patch Missing & Remediation Attributes: Add OS Patch from x.x.x.x Re-request Access Request Attributes: Send Patch, AV, Firewall Posture Check Privacy Policy Posture Attributes: Patch, AV, Firewall Posture Config. Data Check Compliance Policy Result Attributes: Success NEA Working Group

12. Network Service Example • CEO requests to access company network via VPN service • NEA Server sends compliance policy on AV usage • NEA Client verifies AV is running and up-to-date • NEA Client responds that AV is compliant • NEA Server accepts client’s claim and allows VPN access NEA Working Group

13. Network Service Example Request VPN Access N EA C LIENT E NDPOI N T N EA S ERVER S YSTEM Policy Attributes: Reference to AV Policy Check AV Posture Compliance Claim Attributes: AV Compliant Check Compliance Policy Result Attributes: Success NEA Working Group

14. Open Discussion Topics • Virtualization • NEA Client on Non-Endpoint • Security at All Layers • Minimal Attribute Disclosure NEA Working Group

15. Virtualization • Virtualization not currently mentioned • Many virtualization systems are abstracted from applications • Virtualization layer (e.g. VMM) not included in Assessment • Options: • No change (ignore virtualization) • Mention VMM outside Assessment, • Discuss VMM Assessment as well NEA Working Group

16. NEA Client on Non-Endpoint • Should our model allow for an Assessment of a Clientless Endpoint using network infrastructure hosting the NEA Client? • E.g. An ID[S,P] system with an NEA Client reporting Posture based on observed on network traffic • Limited on Attributes supported (even from standard set) • Not in-band with connection request • Can’t remediate or detect non-networking functions • Options: • No change (NEA Client on Endpoint only) • Minor mention of limited NEA Client on non-Endpoint • Revise spec to allow non-Endpoint NEA Client and mention limitations NEA Working Group

17. Security at All Layers? • Currently security protections are required in PA, PB and PT; should we change this? • PA, PT are MUST; PB is SHOULD to implement • Deployer controls which protections to use • If not required, then vendor specific approach may arise • Each layer offers slightly different security properties • PA is end to end so validator can authenticate collector • PB might be beneficial for broker to broker messages • PT addresses transport attacks • Options: • Leave PA,PT as MUST, PB as SHOULD • Drop or reduce (to MAY) requirement for PB • Mandate security in each protocol NEA Working Group

18. Minimal Attribute Disclosure • Privacy topic in section 9.2 • Disclose minimal information required to satisfy Assessment • Model Summaries: • Client sends all Attributes by default • Client has local policy dictating Attributes to send • Client responds to Attribute requests based on policy. Server can iteratively request Attributes (factoring in values of prior Attributes) • Should minimal attribute disclosure be: • Not changed • Removed • Reduced (or Enlarged) NEA Working Group

19. Privacy Considerations • NEA technology is invasive and could raise privacy concerns • User consent to share information to network • Employment contacts • Privacy rights subject to local laws and customs • NEA WG focused on protocols not client policy • Section highlights guidance to implementers • Enable User controls over Attribute disclosure • Encourage opt-in with granular disclosure policies • Network providers pre-disclosing required Posture NEA Working Group

20. Security Considerations • Trust • Endpoint • Accurately represent Posture of Endpoint • Correctly evaluate compliance with specified policy • Only when Policy Attributes are used by NEA Server • Not trusted beyond the above • NEA Server • Protect Posture information provided • Not send malicious remediation instructions • Largely trusted by Endpoint • Network Infrastructure • Deliver messages in timely manner • Not cause DoS (e.g. altered or dropped Messages) • Not assumed to be trusted beyond the above NEA Working Group

21. Security Considerations • Classes of Attack • Man in the Middle (Authentication/Confidentiality) • Active as authenticated intermediary proxying Messages • Passive eavesdropper for later replay • Message Modification (Integrity) • Altering messages to cause incorrect decisions or repairs • Attribute Theft (Confidentiality) • Observing Endpoint contents to gauge vulnerability • Possible replay of compliant Attributes • Denial of Service • NEA Protocol I-Ds will document security considerations for their technologies NEA Working Group

22. Questions? NEA Working Group

23. Common Requirements • Capable of multi-message dialog • Allow assessment prior and after network connectivity • Enable re-assessment by either client or server • Protection against active/passive attacks by intermediaries • PA and PB transport agnostic interfaces NEA Working Group

24. Common Requirements • Selection process prefer reuse of existing open standards • Scalable (many collectors and validators on multiple servers) • Efficient transport of many Attributes • Large numbers of policies • Allow for Assessment with reduced amount of information exchanged NEA Working Group

25. PA Requirements • Support transport standard Attributes • Support transport of vendor-specific Attributes • Enable validator to request Posture, Compliance Claims and Assertion Attributes from client’s Collector • Allow for multiple requests for posture information on existing or new session • Carry validator results and remediation instructions NEA Working Group

26. PA Requirements • SHOULD support Attributes for prior remediation performed (e.g. time, server used.) • Capable of authentication, integrity and confidentiality of Attributes • Capable of carrying Attributes including binary data • String Attributes encoded with a I18Nable encoding NEA Working Group

27. 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 • SHOULD be capable of authentication, integrity and confidentiality of messages, decision and remediation instructions • Support grouping of attributes to optimize messages per roundtrip NEA Working Group

28. 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

29. 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 Posture Transport Client and Server prior to allowing general access. • Allow for Posture Transport Client or Server Session to be initiated from either party when both have assigned network addresses NEA Working Group

30. Backup Slides NEA Working Group

31. Out of Scope • From the approved NEA Charter: • “Specifying mechanisms for providing restricted access is outside the scope of the NEA WG.” • “The NEA working group will not specify protocols other than PA and PB at this time.” • “Detecting or handling such endpoints is out of scope of the NEA WG.” – about lying endpoints • “Note that NEA is not chartered to develop standard protocols for remediation.” NEA Working Group

32. Out of Scope • “NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter...” NEA Working Group

33. In Scope for Requirements “A requirements document will be written and used as a basis for evaluating the candidate protocols.” • “The priority of the NEA working group is to develop standard protocols at the higher layers in the architecture: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB).” • “However, the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints.” NEA Working Group

34. In Scope for Requirements • “The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis.” • “It will also include generic requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT).” • “PT protocols may be standardized in other WGs since these protocols may not be specific to NEA. The NEA WG will identify and specify the use of one mandatory to implement PT protocol that is fully documented in an RFC.” NEA Working Group