802.1 AE/AF Platform considerations Ken Grewal email@example.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 – – – • Built on initial (undefined?) authentication – • Key explosion / deployment considerations Multicast / broadcast considerations Others? 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 – – Group membership > 2 – Alternative AF protocol (manual / P2P) • • Live List, potential list, … KC is not authentic and may be spoofed – does it matter? 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 – • • 802.1AB TLVs extensions? Other? – • EAPOL-Posture? 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 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 • 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 • • • Create synergies between wired & wireless – – – • 802.1X / EAP Session key may be associated with posture / privilege and transparently used for policy 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?