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?