NEA Requirement I-D IETF 68

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

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

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

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

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

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

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

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

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
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 clients claim and allows VPN
  access

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
14
Open Discussion Topics

• Virtualization
• NEA Client on Non-Endpoint
• Security at All Layers
• Minimal Attribute Disclosure

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

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 IDS,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
• Cant 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

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

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)

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

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

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

22

• Questions?

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

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

25
PA Requirements

• Support transport standard Attributes
• Support transport of vendor-specific Attributes
• Enable validator to request Posture, Compliance
  Claims and Assertion Attributes from clients
  Collector
• Allow for multiple requests for posture
  information on existing or new session
• Carry validator results and remediation
  instructions

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

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

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

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

30

• Backup Slides

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.

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

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.

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.