NEA Requirement I-D IETF 68 – Prague Paul Sangster Symantec Corporation

March 20, 2007NEA Working Group2 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

March 20, 2007NEA Working Group3 NEA Reference Model Agreed Upon at IETF 67 Posture Collectors Posture Validators Posture Transport Server Posture Attribute (PA) protocol Posture Broker (PB) protocol NEA ClientNEA Server Posture Transport (PT) protocols Posture Transport Client Posture Broker Client Posture Broker Server

March 20, 2007NEA Working Group4 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

March 20, 2007NEA Working Group5 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

March 20, 2007NEA Working Group6 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

March 20, 2007NEA Working Group7 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

March 20, 2007NEA Working Group8 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

March 20, 2007NEA Working Group9 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

March 20, 2007NEA Working Group10 Network Connection Example 1.IT employee boots computer causing request to join network 2.NEA Server requests Posture information 3.NEA Client replies with requested Posture 4.Compliance policy indicates client out of date 5.NEA Server sends failed result and remediation instructions 6.NEA Client updates system and re-requests access to the network

March 20, 2007NEA Working Group11 Network Connection Example NEACLIENTENDPOINTNEACLIENTENDPOINT NEASERVERSYSTEMNEASERVERSYSTEM Request Access Request Attributes: Send Patch, AV, Firewall Posture Posture Attributes: Patch, AV, Firewall Posture Config. Data Result Attributes: Failure – OS Patch Missing & Remediation Attributes: Add OS Patch from x.x.x.x Request Attributes: Send Patch, AV, Firewall Posture Posture Attributes: Patch, AV, Firewall Posture Config. Data Re-request Access Result Attributes: Success Check Compliance Policy Check Compliance Policy Check Privacy Policy Check Privacy Policy

March 20, 2007NEA Working Group12 Network Service Example 1.CEO requests to access company network via VPN service 2.NEA Server sends compliance policy on AV usage 3.NEA Client verifies AV is running and up-to- date 4.NEA Client responds that AV is compliant 5.NEA Server accepts client’s claim and allows VPN access

March 20, 2007NEA Working Group13 Network Service Example NEACLIENTENDPOINTNEACLIENTENDPOINT NEASERVERSYSTEMNEASERVERSYSTEM Request VPN Access Policy Attributes: Reference to AV Policy Compliance Claim Attributes: AV Compliant Result Attributes: Success Check Compliance Policy Check AV Posture

March 20, 2007NEA Working Group14 Open Discussion Topics Virtualization NEA Client on Non-Endpoint Security at All Layers Minimal Attribute Disclosure

March 20, 2007NEA Working Group15 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

March 20, 2007NEA Working Group16 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

March 20, 2007NEA Working Group17 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

March 20, 2007NEA Working Group18 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)

March 20, 2007NEA Working Group19 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

March 20, 2007NEA Working Group20 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

March 20, 2007NEA Working Group21 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

March 20, 2007NEA Working Group22 Questions?

March 20, 2007NEA Working Group23 Common Requirements 1.Capable of multi-message dialog 2.Allow assessment prior and after network connectivity 3.Enable re-assessment by either client or server 4.Protection against active/passive attacks by intermediaries 5.PA and PB transport agnostic interfaces

March 20, 2007NEA Working Group24 Common Requirements 6.Selection process prefer reuse of existing open standards 7.Scalable (many collectors and validators on multiple servers) 8.Efficient transport of many Attributes 9.Large numbers of policies 10.Allow for Assessment with reduced amount of information exchanged

March 20, 2007NEA Working Group25 PA Requirements 1.Support transport standard Attributes 2.Support transport of vendor-specific Attributes 3.Enable validator to request Posture, Compliance Claims and Assertion Attributes from client’s Collector 4.Allow for multiple requests for posture information on existing or new session 5.Carry validator results and remediation instructions

March 20, 2007NEA Working Group26 PA Requirements 6.SHOULD support Attributes for prior remediation performed (e.g. time, server used.) 7.Capable of authentication, integrity and confidentiality of Attributes 8.Capable of carrying Attributes including binary data 9.String Attributes encoded with a I18Nable encoding

March 20, 2007NEA Working Group27 PB Requirements 1.Capable of carrying the decision and (if present) remediation instructions 2.Carry naming for collectors and validators (used for message delivery) Naming should allow for dynamic registration 3.Multiplex Message Dialogs between multiple collectors and validators 4.SHOULD be capable of authentication, integrity and confidentiality of messages, decision and remediation instructions 5.Support grouping of attributes to optimize messages per roundtrip

March 20, 2007NEA Working Group28 PT Requirements 1.SHOULD incur low overhead for low bandwidth links 2.SHOULD be capable of using a half duplex link 3.MUST NOT interpret the contents of PB messages 4.Capable of protecting the integrity and confidentiality of the PB messages

March 20, 2007NEA Working Group29 PT Requirements 5.Reliable delivery of PB messages (detect dups, fragmentation) 6.Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel.) 7.Establish a restricted session between Posture Transport Client and Server prior to allowing general access. 8.Allow for Posture Transport Client or Server Session to be initiated from either party when both have assigned network addresses

March 20, 2007NEA Working Group30 Backup Slides

March 20, 2007NEA Working Group31 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.”

March 20, 2007NEA Working Group32 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...”

March 20, 2007NEA Working Group33 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.”

March 20, 2007NEA Working Group34 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.”