nea requirement i d ietf 67 san diego n.
Download
Skip this Video
Download Presentation
NEA Requirement I-D IETF 67 – San Diego

Loading in 2 Seconds...

play fullscreen
1 / 13

NEA Requirement I-D IETF 67 – San Diego - PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on

NEA Requirement I-D IETF 67 – San Diego. Paul Sangster Symantec Corporation. Agenda. Discussion of historical requirements I-D Draft-khosravi-nea-requirements-01.txt July 2005 version, pre-NEA 2 nd BOF Consider contents as input to new NEA requirements I-D Document’s Terminology

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'NEA Requirement I-D IETF 67 – San Diego' - jakeem-barlow


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
nea requirement i d ietf 67 san diego

NEA Requirement I-DIETF 67 – San Diego

Paul Sangster

Symantec Corporation

NEA Working Group

agenda
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
  • Document’s Terminology
  • Review Requirements:
    • General requirements
    • PA, PB and PT protocol requirements

NEA Working Group

pre nea wg i d
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

NEA Working Group

i d contents
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

NEA Working Group

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

NEA Working Group

common requirements
Common Requirements
  • Capable of multi-message dialog
  • Allow server requests prior and after network access
  • Possible for client to initiate a posture re-evaluation request
  • Protection against active/passive attacks by intermediaries

NEA Working Group

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

NEA Working Group

pa requirements
PA Requirements
  • Transport core attributes (vendor, version, operational status, …)
  • Transport of vendor defined attributes
  • Validator request of particular client component’s posture
  • Allow for multiple requests for posture information
  • Carry validator results and remediation instructions

NEA Working Group

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

NEA Working Group

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

NEA Working Group

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

NEA Working Group

pt requirements1
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 NAR and NAA prior to allowing general access.
  • Allow for NAR/NAA session to be initiated from either party when both have assigned network addresses

NEA Working Group

slide13
Questions?

NEA Working Group

ad