1 / 16

802.1 AE/AF Platform considerations

802.1 AE/AF Platform considerations. Ken Grewal ken.grewal@intel.com IEEE 802.1 Plenary, November 2004. Agenda. Purpose Current Status Platform considerations Authentication Protocol Authorization Posture Policy Frame Format Other Considerations Conclusion. Purpose.

Mia_John
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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?

More Related