Transcript feb05_eap_usage

EAP Usage Issues
Feb 05
Jari Arkko
1
Typical EAP Usage
• PPP authentication
• Wireless LAN authentication
– 802.1x and 802.11i
• IKEv2 EAP authentication mode
– Client side only, server authenticated with a cert
– Universal Mobile Access technology will use this
• PANA
– Initial deployment is for DSL
2
Main EAP-related IETF WGs
• EAP WG
• AAA & RADEXT WGs
– Transport of EAP over AAA
• PANA WG
– Defines the use of EAP in an IP-layer version of
802.1X
• IPsec WG
– Defined the use of EAP in IKEv2
3
Other EAP-related IETF WGs 1
• MIP6 WG
– Problem to solve is “bootstrapping”
– This is about how to (a) find a home agent and (b) set up a
security association with it so that the mobile node can use
the home agent’s services
– Want to avoid deployment problem of yet another
configuration and secret just because you want to be mobile
– One approach is the integration of EAP in some form to the
protocol
– Another approach is the use of keying material derived by
EAP
– A third approach is to use IKEv2
– Zero-config solutions could perhaps be developed as well
(e.g., based on SEND certificates or CGA)
4
Other EAP-related IETF WGs 2
• DHCP WG
–?
5
Other EAP-related IETF WGs 3
• NSIS WG
–?
6
Other EAP-related IETF WGs 4
• ISMS WG
–?
7
Other EAP-related IETF WGs 5
• SIP WG
– Many years ago, suggested the use of EAP in
application protocol
– Decided to go for support of a legacy credential
inside HTTP Digest instead (RFC 3310, Digest
AKA)
– Positive experience -- simple, clean
• Others?
8
EAP Applicability Statement
• EAP was created for network access
• RFC 3748 has an applicability
statement:
EAP was designed for use in network access
authentication, where IP layer connectivity may
not be available. Use of EAP for other
purposes, such as bulk data transport, is NOT
RECOMMENDED.
9
EAP Applicability Statement 2
Since EAP does not require IP connectivity, it
provides just enough support for the reliable
transport of authentication protocols, and no more.
EAP is a lock-step protocol which only supports a
single packet in flight. As a result, EAP cannot
efficiently transport bulk data, unlike transport
protocols such as TCP [RFC793] or SCTP [RFC2960].
While EAP provides support for retransmission, it
assumes ordering guarantees provided by the lower
layer, so out of order reception is not supported.
Since EAP does not support fragmentation and
reassembly, EAP authentication methods generating
payloads larger than the minimum EAP MTU need to
provide fragmentation support.
10
Deployment Problem
• The crux in deploying security seems often to
be configuration, or setting up the shared
secrets and/or certificates
– Much of this cost is in the people and physical
transaction process, not equipment or software
– Exercise 1: ask your corporate manager to deploy
an additional per-user token or secret
– Exercise 2: calculate the investment to change all
SIM cards to better ones (which are available)
• N = 1.5 * 10^9, cost per user perhaps 20 $
11
Deployment Problem 2
• Good solutions are solicited!
• Making things zero-config is useful
– In limited applications this has been possible
– HIP, MULTI6, SEND
• One-sided configuration
– Web-server certs and TLS
– SEND router certificates
• Weaker bootstrap phase
– SSH, SIP signaling end-to-end security
• Sharing the same credentials
12
Deployment Problem 3
• Are the protocols sufficient & secure for you
to actually share credentials with with some
other purpose?
• Need to look for some non-trivial issues, such
as the binding problem
• Need to think whether our solutions are
secure in theory, or also in practise
– Do the credentials that you shared with another
purpose really exist for a large part of the user
base?
13