EAPOnly Authentication in IKEv 2 drafteronenipsecikev 2 eapauth

EAP-Only Authentication in IKEv 2 draft-eronen-ipsec-ikev 2 -eap-auth Pasi Eronen, Yaron Sheffer, Hannes Tschofenig IETF-76, Hiroshima

Motivation n Client auth using certificates is hard to do n Even server auth requires some provisioning n IKE shared secret often abused for password authentication n EAP-only auth is often more practical n n E. g. EAP-AKA (long shared secret) EAP-EKE, EAP-PWD (password) n Current IKEv 2 requires server cert-based auth, even when you’re doing EAP n AUTH payload in message 4

Proposed Solution n Prerequisite: a mutual authenticating, key generating EAP method n Add an EAP_ONLY_AUTHENTICATION notification to message 3 n Responder cert is not required, AUTH payloads computed using the EAP MSK n If the responder does not understand, initiator is free to ignore or to validate cert-derived AUTH payload

Message Sequence Initiator Responder HDR, SAi 1, KEi, Ni, [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)] HDR, SAr 1, KEr, Nr, [CERTREQ], [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)] HDR, SK { IDi, [IDr], SAi 2, TSi, TSr, N(EAP_ONLY_AUTHENTICATION), [CP(CFG_REQUEST)] } HDR, SK {IDr, EAP(Request) } HDR, SK {EAP(Response) } HDR, SK {EAP(Success) } HDR, SK {AUTH} <-- HDR, SK {AUTH, SAr 2, TSi, TSr, [CP(CFG_REPLY]}

Channel Binding n EAP should authenticate the identity of the IKE Responder n Otherwise a rogue Access Point can masquerade as a VPN gateway n This means: n The EAP method should be mutually authenticating and key generating (MSK) n The EAP exchange should include both parties’ IKE identities n These identities should be crypto-bound into MSK n We trust the AAA server to include the correct gateway identity in EAP

Why in IPsec. ME n This is an extension to the “mainstream” protocol use case n Likely to be widely adopted n As a replacement to insecure PSK use

Thank You!