EAP Scenarios and 802.1af Joseph Salowey 1/12/2006

Basic EAP Model EAP Peer EAP Authen- ticator EAP Server Authentication Keys

AAA Model EAP Peer EAP Authen- ticator AAA Server Authentication Keys (Authorization) EAP Server

AAA Model Notes Peer authenticates AAA server AAA server provides authenticator with key Possession indicates to peer that authenticator is authorized Peer does not know the identity of the authenticator, by default it cant differentiate between authenticators Authenticator receives authorizations from AAA server

3 rd Party Authentication Model EAP Peer EAP Authen- ticator Authentication Services Authentication EAP Server (Online or Offline)

3 rd Party Authentication Model Notes Peer authenticates the authenticator Peer knows the authenticators identity Peer must be able to authorize based on identity information Authenticator does not get authorization based on authentication exchange Authentication service may be offline as in PKI CA Authentication service may be online as in Kerberos

Approaches to modifying the AAA model (channel bindings) Bind authenticator/service identity into EAP exchange –EAP methods do not interpret the data, instead transport data –Draft-arkko-eap-service-identity-auth-04 Specify target authenticator/service –Mechanism dependent implementation (kerberos, channel binding, credential selection) Bind authenticator/service identity to key material –Draft-obha-aaa-key-binding-01

3 rd Party authentication case SW1SW2 Authentication Services (offline) Authentication Mutual

Unilateral AAA case SW1SW2 Mutual Authentication AAA

Bilateral AAA case SW1SW2 Mutual Authentication x 2 AAA AZ

EAP and keys EAP methods can derive key material –MSK available to the authenticator –EMSK reserved (for derivation of other keys TBD) MSK may be used to derive session keys data encryption (802.11i) MSK may be used to derive KEK to encrypt key descriptor to distribute keys (group keys) Either or both approaches may be useful for CAK establishment