802 1 ae af platform considerations l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

802.1 AE/AF Platform considerations PowerPoint PPT Presentation


  • 276 Views
  • Updated On :
  • Presentation posted in: General

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.

Related searches for 802.1 AE/AF Platform considerations

Download Presentation

802.1 AE/AF Platform considerations

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

802.1 AE/AF Platform considerations

Ken Grewal

[email protected]

IEEE 802.1 Plenary, November 2004


Agenda l.jpg

Agenda

  • Purpose

  • Current Status

  • Platform considerations

    • Authentication

      • Protocol

    • Authorization

      • Posture

      • Policy

    • Frame Format

  • Other Considerations

  • Conclusion


Purpose l.jpg

Purpose

  • Clarify existing architecture, use cases, motives

  • Introduce platform considerations

  • Next steps…


Current status l.jpg

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

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

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

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

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

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

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


Ae frame format l.jpg

AE Frame Format


802 11i frame format l.jpg

802.11i Frame Format

MIC is weak, hence encrypted

CCMP is Similar


Other observations l.jpg

Other Observations

  • Aggregation

    • Hub considerations in 802.1X

      • Seen as multiple logical ports within 802.1X?

      • Analogous to wireless

      • VMs (next page)


More observations l.jpg

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

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


Feedback l.jpg

Feedback?


  • Login