Presentation on theme: "802.1 AE/AF Platform considerations Ken Grewal IEEE 802.1 Plenary, November 2004."— Presentation transcript:
802.1 AE/AF Platform considerations Ken Grewal IEEE 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 i (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 i 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 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