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 Clarify existing architecture, use cases, motives Introduce platform considerations Next steps…

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

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

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

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 De-couple AE / AF Authentication protocol 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?