802 1 ae af platform considerations
Download
Skip this Video
Download Presentation
802.1 AE/AF Platform considerations

Loading in 2 Seconds...

play fullscreen
1 / 16

802.1 AE/AF Platform considerations - PowerPoint PPT Presentation


  • 308 Views
  • Uploaded on

802.1 AE/AF Platform considerations. Ken Grewal [email protected] IEEE 802.1 Plenary, November 2004. Agenda. Purpose Current Status Platform considerations Authentication Protocol Authorization Posture Policy Frame Format Other Considerations Conclusion. Purpose.

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 '802.1 AE/AF Platform considerations' - Mia_John


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
802 1 ae af platform considerations
802.1 AE/AF Platform considerations

Ken Grewal

[email protected]

IEEE 802.1 Plenary, November 2004

agenda
Agenda
  • Purpose
  • Current Status
  • Platform considerations
    • Authentication
      • Protocol
    • Authorization
      • Posture
      • Policy
    • Frame Format
  • Other Considerations
  • Conclusion
purpose
Purpose
  • Clarify existing architecture, use cases, motives
  • Introduce platform considerations
  • Next steps…
current status
Current Status
  • 802.1AE Stable, but frozen until AF maturity
  • 802.1AF concept stage
  • Device Identity definition
    • Not needed to complete this project
    • If MK provisioned manually, no need for device identity at all
group based security
Group based security
  • Rationale
    • Key explosion / deployment considerations
    • Multicast / broadcast considerations
    • Others?
  • Built on initial (undefined?) authentication
    • Likely P2P – 802.1X based / other
  • AE Shared symmetric key within group
    • Prone to spoofing – no data origin authenticity
      • Contrary to project PAR!
    • Compromising a single node can cause havoc in the CA
    • Node leaving the CA will force fresh master keys refresh everyone!
    • Acceptable if every node implements TPM (TCG/TNC) like security – unlikely!
  • AF Applicability to leaf nodes (platform / host)
    • Group membership = 2
      • Redundancy in KSP negotiation fields for groups
        • Live List, potential list, …
    • Group membership > 2
      • KC is not authentic and may be spoofed – does it matter?
    • Alternative AF protocol (manual / P2P)
  • Group sharing attractive administratively, but does not offer all security services in claim
    • => Likely to be deployed with misconceptions about security offerings
ae af interdependencies
AE / AF Interdependencies
  • No need for tight coupling
    • AE useable without AF definition – OOB keys
  • Different AF (like) protocols may be mapped to AE
    • Leaf nodes Vs. core network / provider use cases
      • Leaf nodes leverage P2P key derivation protocol
      • Core leverages group based – if shared key acceptable
  • Abstract group based architecture from AE
    • Pure L2 encapsulation description
    • Separate ‘context’ for environment
platform authentication
Platform Authentication
  • Protocol
    • Host has 1:1 (client-server) relationship with infrastructure device (e.g. switch)
    • Mobility considerations
      • Single (mobile) host will support wired and wireless media
      • Consolidation of protocols / algorithms for ease of use / deployment
        • single HW to service wired / wireless crypto requirements
    • Requires a P2P authentication protocol
      • E.g. 802.11i (like) or PSK with n=2
        • Simple 4-way handshake based on PMK to derive PTK
platform authentication8
Platform Authentication
  • Posture
    • Authentication alone insufficient for applying policy
    • Need platform configuration / state to ensure platform conformance to IT policy
      • ‘posture’
    • Using authentication / posture, PDP can make better informed policy decision
    • Posture carrier protocol – which layer?
      • Post authentication mechanism (over controlled port)
      • 802.1X extension
        • EAPOL-Posture?
      • 802.1AB TLVs extensions?
      • Other?
        • E.g. EAP extension
    • If posture part of overall authentication / key derivation, then SAK can be used as a demux for policy!!!!!!!!
platform authentication9
Platform Authentication
  • Policy
    • Result of authentication / posture evaluation
    • PDP conveys policy to PEP
    • Format?
      • Single status
      • Expanded status (specific filter rules)
        • Granular policy
    • Protocol
      • Extension of 802.1X (EAPOL-Success)?
      • Other (OOB / EAP extension)?
data path considerations
Data path considerations
  • Frame format consolidation (Wired / Wireless)
    • 802.1AE Vs. 802.11i
      • Separation of media specific params from encapsulation
      • After all – Frame encapsulation is Frame encapsulation is Frame encapsulation!!!!
        • All require Key-ID, enc, auth, PN (IV), [media specific stuff]
  • Algorithms
    • GCM Vs. CCM (assuming CCMP)
    • Shared HW
802 11i frame format
802.11i Frame Format

MIC is weak, hence encrypted

CCMP is Similar

other observations
Other Observations
  • Aggregation
    • Hub considerations in 802.1X
      • Seen as multiple logical ports within 802.1X?
      • Analogous to wireless
      • VMs (next page)
more observations
More Observations
  • VMs => Multi-core / multi-OS (vanderpool)
    • Multiple identities for 802.1X to decipher
      • Possibly over same Port / MAC!
    • Multiple network stacks
      • Single / multiple NICs
  • One physical port per VM – OK
  • One physical port per multiple VMs
    • Proxy model at L2
    • Single Linksec entity representing all VMs
    • Local PEP – for VMs
  • What is ‘device identity / posture’ in this context?
conclusion
Conclusion
  • De-couple AE / AF
    • Remove group based constraints from AE – this is really pertinent to usage model and could be an opaque context
    • Multiple AFs map to a single AE based on usage
  • Authentication protocol
    • Can leverage existing work
      • 802.1X / EAP
      • Session key may be associated with posture / privilege and transparently used for policy
  • Create synergies between wired & wireless
    • Assists in implementation: common algorithms / protocols for wired / wireless
    • Inherent value in adoption
    • Convergence of algorithms (GCM  CCM) over AES?
  • Considerations of VMs for identity / authentication / authorization
ad