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

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


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


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


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


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


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


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


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


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


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


CheckPrivacyPolicy

CheckPrivacyPolicy


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


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


CheckAVPosture


Open Discussion Topics

• Virtualization

• NEA Client on Non-Endpoint

• Security at All Layers

• Minimal Attribute Disclosure


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


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


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)


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


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


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


Questions?


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


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


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


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


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


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


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


Backup Slides


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


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


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


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 Requirement I-D IETF 68 – Prague Paul Sangster Symantec Corporation.

Documents

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