Download
802 1 ae af platform considerations n.
Skip this Video
Loading SlideShow in 5 Seconds..
802.1 AE/AF Platform considerations PowerPoint Presentation
Download Presentation
802.1 AE/AF Platform considerations

802.1 AE/AF Platform considerations

383 Views Download Presentation
Download Presentation

802.1 AE/AF Platform considerations

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 802.1 AE/AF Platform considerations Ken Grewal ken.grewal@intel.com IEEE 802.1 Plenary, November 2004

  2. Agenda • Purpose • Current Status • Platform considerations • Authentication • Protocol • Authorization • Posture • Policy • Frame Format • Other Considerations • Conclusion

  3. Purpose • Clarify existing architecture, use cases, motives • Introduce platform considerations • Next steps…

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

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

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

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

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

  9. 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)?

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

  11. AE Frame Format

  12. 802.11i Frame Format MIC is weak, hence encrypted CCMP is Similar

  13. Other Observations • Aggregation • Hub considerations in 802.1X • Seen as multiple logical ports within 802.1X? • Analogous to wireless • VMs (next page)

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

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

  16. Feedback?