NEA Requirement I-DIETF 68 – Prague
Paul Sangster
Symantec Corporation
March 20, 2007 NEA Working Group 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
March 20, 2007 NEA Working Group 3
NEA Reference ModelAgreed Upon at IETF 67
Posture Collectors
Posture Validators
PostureTransportServer
Posture Attribute (PA) protocol
Posture Broker (PB) protocol
NEA Client NEA Server
Posture Transport (PT) protocolsPostureTransportClient
PostureBrokerClient
PostureBrokerServer
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 NEA Working Group 10
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, 2007 NEA Working Group 11
Network Connection ExampleNEA
CLIENT
ENDPOINT
NEA
SERVER
SYSTEM
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
CheckCompliancePolicy
CheckCompliancePolicy
CheckPrivacyPolicy
CheckPrivacyPolicy
March 20, 2007 NEA Working Group 12
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, 2007 NEA Working Group 13
Network Service ExampleNEA
CLIENT
ENDPOINT
NEA
SERVER
SYSTEM
Request VPN Access
Policy Attributes: Reference to AV Policy
Compliance Claim Attributes: AV Compliant
Result Attributes: Success
CheckCompliancePolicy
CheckAVPosture
March 20, 2007 NEA Working Group 14
Open Discussion Topics
• Virtualization
• NEA Client on Non-Endpoint
• Security at All Layers
• Minimal Attribute Disclosure
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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)
March 20, 2007 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
March 20, 2007 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
March 20, 2007 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
March 20, 2007 NEA Working Group 22
Questions?
March 20, 2007 NEA Working Group 23
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, 2007 NEA Working Group 24
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, 2007 NEA Working Group 25
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, 2007 NEA Working Group 26
PA Requirements6. 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, 2007 NEA Working Group 27
PB Requirements1. 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, 2007 NEA Working Group 28
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, 2007 NEA Working Group 29
PT Requirements5. 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, 2007 NEA Working Group 30
Backup Slides
March 20, 2007 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.”
March 20, 2007 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...”
March 20, 2007 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.”
March 20, 2007 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.”