NEA Requirement I-D IETF 67

1
NEA Requirement I-DIETF 67 San Diego

• Paul Sangster
• Symantec Corporation

2
Agenda

• Discussion of historical requirements I-D
• Draft-khosravi-nea-requirements-01.txt
• July 2005 version, pre-NEA 2nd BOF
• Consider contents as input to new NEA
  requirements I-D
• Documents Terminology
• Review Requirements
• General requirements
• PA, PB and PT protocol requirements

3
Pre-NEA WG I-D

• draft-khosravi-nea-requirements-01.txt
• Primary Contributors
• Editors
• Hormuzd Khosravi, Intel
• Paul Sangster, Symantec
• Content authors
• Kevin Amorin, Harvard University
• Diana Arroyo, IBM
• Uri Blumenthal, Intel
• Steve Hanna, Juniper
• Thomas Hardjono, SignaCert
• Ravi Sahita, Intel

• Mauricio Sanchez, HP
• Jeff Six, NSA
• Joseph Tardo, Nevis
• Susan Thomson, Cisco
• John Vollbrecht
• Hao Zhou, Cisco

4
I-D Contents

• Introduction
• Architecture and Components
• Common Requirements
• Protocol Requirements
• Posture Attribute (PA) protocol
• Posture Broker (PB) protocol
• Posture Transport (PT) protocol
• Security Analysis
• Operational Considerations
• Security Considerations

5
Definitions

• Component Software, hardware or firmware entity
  performing a particular logical function within
  the NEA conceptual architecture (e.g. AV software
  or a Firewall or more generally an OS kernel.)
• Message Self contained unit of communication
  between components (e.g. PA message might carry
  a set of attributes from a Posture Collector to a
  Validator.)
• Session Common PB transport connection capable
  of carrying one or more messages from multiple
  subscribed Posture Collectors and Validators.
• Dialog Sequence of request/response messages
  exchanged over one or more sessions.

6
Common Requirements

1. Capable of multi-message dialog
2. Allow server requests prior and after network
   access
3. Possible for client to initiate a posture
   re-evaluation request
4. Protection against active/passive attacks by
   intermediaries

7
Common Requirements

• PA and PB transport agnostic interfaces
• Selection process prefer reuse of existing open
  standards
• Scalable (many collectors and validators on
  multiple servers)

8
PA Requirements

• Transport core attributes (vendor, version,
  operational status, )
• Transport of vendor defined attributes
• Validator request of particular client
  components posture
• Allow for multiple requests for posture
  information
• Carry validator results and remediation
  instructions

9
PA Requirements

1. Selection process prefer re-use of existing open
   standards for transport and attribute
   representation
2. SHOULD support expression of prior remediation
   state (e.g. time, server used.)
3. Capable of authentication, integrity and
   confidentiality of attributes, results and
   remediation instructions
4. SHOULD optimize transport of messages and
   minimize PB RTs

10
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
• Capable of authentication, integrity and
  confidentiality of messages, decision and
  remediation instructions
• SHOULD support grouping of attributes to optimize
  messages/RTs

11
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

12
PT Requirements

1. Reliable delivery of PB messages (detect dups,
   fragmentation)
2. Capable of mutual authentication (possibly
   leveraging an authentication inside the protected
   tunnel.
3. Establish a restricted session between NAR and
   NAA prior to allowing general access.
4. Allow for NAR/NAA session to be initiated from
   either party when both have assigned network
   addresses

13

• Questions?