Presentation is loading. Please wait.

Presentation is loading. Please wait.

802.1 AE/AF Platform considerations

Similar presentations

Presentation on theme: "802.1 AE/AF Platform considerations"— Presentation transcript:

1 802.1 AE/AF Platform considerations
Ken Grewal IEEE 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 i (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 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

11 AE Frame Format

12 MIC is weak, hence encrypted
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 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

16 Feedback?

Download ppt "802.1 AE/AF Platform considerations"

Similar presentations

Ads by Google