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
–
–
–
•
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?