Overview of proposed EAP methods, credential types, and uses

Pasi Eronen

IETF64 EMU BoFNovember 10th, 2005

Introduction

• If you have <some kind of existing credentials and related infrastructure>, what EAP methods could you use?

• Focus on methods documented in internet-drafts (really old ones omitted)– Only EAP-TLS is an RFC

X.509 PKI

• EAP-TLS

• EAP-IKEv2

• Private keys could be in software or hardware tokens (7816, USB, …)

Shared secrets

• EAP-IKEv2• EAP-PAX• EAP-SKL• EAP-PSK• EAP-MAKE• EAP-Double-TLS• EAP-TLS with TLS-PSK• + some that I probably forgot (sorry!)• + several expired drafts

Passwords

• My definition– Shared secret methods require the EAP

server to have the shared secret– Password methods work with existing

user/password databases (the EAP server does not necessarily have the password)

• You don’t have to agree with this definition!

Passwords (cont.)

• Tunneled methods: EAP-FAST, EAP-TTLSv0, EAP-TTLSv1, PEAP v0, PEAP v1, PEAP v2

• Inside tunnel:– PAP/GTC (=just send the password)– CHAP/MD5– MS-CHAP– MS-CHAP-v2

• EAP server authenticated using certificates

One-time passwords/tokens

• Tunneled methods + inside tunnel:– PAP/GTC (=just send the password)– OTP– EAP-POTP

Cellular infrastructure

• EAP-SIM

• EAP-AKA

Kerberos

• No currently active methods?– EAP-GSS expired– Some password methods might be able to

use Kerberos back-end

Other ways EAP is used

• Provisioning/enrollment– Provisioning certificates (instead of existing

certificate management protocols)– Enrolling strong credential from weak

single-use credential – draft-mahy-eap-enrollment, EAP-FAST, PEAP

• Client integrity checks• Two-factor / two-entity (device and user)

authentication (sequences)• + Other things I don’t even want to mention…

Summary structure

• Status– What’s the situation, both in standardization

and deployment

• Need for new work– Problems not yet solved?– Real demand for solving them?

• Chances of success– How likely that WG could achieve rough

consensus on the problem and solution(s)?– How likely that the solutions would have impact?

• Note: These are just my opinions. They will change. You don’t have to agree.

Summary (1/5)

• X.509 PKI– Status: EAP-TLS.– Need for new work: Some. EAP-TLS works, but

the spec would benefit from updates.– Chances of success: Good.

• Shared secrets– Status: No standardized methods.– Need for new work: Yes.– Chances of success: Good — but requires draft

author interest in standardization

Summary (2/5)

• Passwords– Status: Proprietary methods widely used.– Need for new work: Standardized method would

be “nicer”, but…– Chances of success: …depends?

• Are the existing vendors interested?• Difficult to get consensus about anything related

to passwords in IETF

• One-time passwords/tokens– See “Passwords” (or is POTP different case?)

Summary (3/5)

• Cellular infrastructure– Status: 3GPP has EAP-SIM/EAP-AKA,

3GPP2 has something, too– Need for new work: No

• Kerberos– Status: No methods– Need for new work: Not much demand?

Summary (4/5)

• Other types of infrastructure or credentials? – Credit card payment?– Biometrics?– Chances of success: unclear.

Summary (5/5)

• Provisioning/enrollment– Status: Unclear.– Need for new work: Unclear.

• Client integrity checks– Status: Proprietary things exist, TNC working

on standardizing some parts– Need for new work: Depends on what

TNC and vendors want.• Two-factor authentication / sequences

– Status: Supported by tunnel methods, but not widely used?

– Need for new work: Unclear.

Other possible WG work items

• Channel bindings– Status: Proposals exist.– Need for new work: Some?– Chances of success: Moderate.