Current Meeting Report
2.5.11 Extensible Authentication Protocol (eap) Bof
Current Meeting Report
Minutes of the EAP BOF
Wednesday, March 20, 2002
Mayank Upadhyay <MayankUpadhyay@WoodsideNet.com>
Preliminaries (10 minutes)
Blue sheets, minute takers
Part 1: RFC 2284bis (30 minutes)
RFC 2284bis issues | Bernard Aboba (20 minutes)
EAP State Machine | Bryan Payne and Nick Petroni (10 minutes)
Part 2: Additional work (60 minutes)
802.11 requirements | David Halasz (10 minutes)
EAP methods and requirements | Dorothy Stanley (10 minutes)
Cryptographic protection of EAP (20 minutes)
EAP TTLS | Paul Funk, http://www.funk.com/NIdx/draft-ietf-pppext-eap-ttls-01.txt, (10 minutes)
PEAP | Simon Josefsson, draft-josefsson-pppext-eap-tls-eap-02.txt, (10 minutes)
EAP methods (20 minutes)
EAP SIM | Henry Haverinen, Jari Malinen, draft-haverinen-pppext-eap-sim-03.txt
EAP AKA | Jari Arkko, draft-arkko-pppext-eap-aka-03.txt
EAP SKE | Luca Salgarelli, draft-salgarelli-pppext-eap-ske-00.txt
EAP MSCHAPv2 | Darin Potter, draft-dpotter-pppext-eap-mschap-01.txt
EAP SPEKE | David Jablon, draft-jablon-speke-00.txt
Charter Bash (20 minutes)
Document Status, Bernard Aboba
So far, the IETF has published two RFCs relating to EAP: RFC 2284, which defines EAP, and RFC 2716, which defines EAP TLS. 6 other documents are in progress, including 3 in PPPEXT: RFC 2284bis, EAP SRP, and EAP TTLS; one in IPSRA: PIC (EAP within ISAKMP and UDP), and two in PANA (requirements and scenario documents).
There are also 14 individual submission, including 4 encapsulation documents, 1 additional cryptographic encapsulation document (PEAP), and 9 methods.
An important question is how do we review the individual method submissions, and what do we do with the encapsulation proposals?
(EAP within UDP, EAP within ICMP, EAP within IP, EAP within HTTP).
Part 1: Status update on RFC 2284bis, Bernard Aboba
RFC 2284bis is a work item of PPPEXT WG, scheduled for completion by June, 2002. Items to be completed by June:
. IANA considerations
. Vendor-Specific Type
. Type expansion
. Threat model/security considerations
. State machine (University of Maryland)
. Interaction between EAP and other layers
Goals of RFC 2284bis: advance EAP to ietf draft standard.
This requires an EAP implementation survey and interop testing.
First set of implementation survey were sent out in June 2001.
Many new implementations since then; need to send out survey solicitation again.
Non-goals: RFC 228bis is not EAP-ng; not a rewrite from scratch.
No non-backwards compatible changes. Not revising RFC 2869 as part of this effort (being done in AAA WG).
Not revising IEEE 802.1X as part of this effort (being done within the IEEE 802.1aa PAR).
Opportunities for interoperability testing:
Interop Last Vegas, May 2002. There will be a demonstration of IEEE 802.1X in the Interop booth (not on the Interop Net itself). Send mail to email@example.com for more information.
RFC 2284bis will need an IANA clarifications section, since RFC 2284 doesn't have one. So far 31 EAP Method Types have been allocated since RFC 2284 was published in March 1998. However, 4 Method Types were allocated in the last month, so allocation rate appears to be at approximately 50 methods a year and accelerating. If this rate of allocation continues, the entire EAP Method Type space (0-255) will be allocated within a few years. 15% of allocated EAP types have never been used; the IANA has even allocated more than one type to a single method.
An examination of the existing allocations discloses that over half are for vendor specific use with no published specification. The recommended IANA allocation policy is as follows:
Packet codes: 1-4 allocated by RFC 2284, 5-255 will be allocated by Standards Action only.
Method Types: 1-31 already allocated. Recommendation is to allocate types 32-191 by Expert Review with specification. In this case, Expert Review means sending mail to the EAP mailing list. It is also possible for the AD to appoint a designated Expert to review the specification. Note that the way this is handled is important given the large number of methods that will need review. If review is required by the EAP WG, it is possible that it will be inundated with review requests. So we need to think this through.
Types 192-254 will be reserved for allocation by Standards Action. Type 255 is reserved for vendor specific use, and Type Expansion. Vendor specific Types are differentiated using the SMI, assigned by IANA. An SMI of zero is for type expansion and enables allocation of Method Types of 256 or greater, although recognition of these types is optional.
The goal of the Vendor-Specific type is to postpone exhaustion of the EAP Method Type space for at least a few more years, until we can get support for an expanded type space deployed. Getting an IANA considerations section out, and starting implementaton of the vendor-specific type is fairly urgent, so depending on the schedule for RFC 2284bis, it may make sense to publish this as a separate RFC.
Another objective of RFC 2284bis is to address EAP interoperability issues.
Abuses of the Notification and NAK messages.
Putting data in the Success and Failure messages
Manufacturing success and failure messages (802.1X)
Ability to authenticate with multiple methods one after another
Ability to include multiple types within a NAK
Interpretation of "Alternative Indications"
Identity, Notification, NAK, Success and Failure messages are consumed by the EAP layer, so they cannot really be part of an EAP method. So you can't use a Notification to carry a Nonce as part of an EAP method, for example. In this respect, the EAP Type operates like a UDP port, except that it's only 8 bits instead of 16 (pity, that). So if you want an EAP frame to be consumed by a method, it needs to have that Method's Type included in it. Identity, NAK, and Notification have their own Types; Success and Failure have their own Packet Codes, just like Request and Response.
Manufacturing success and failure messages is an issue because it means that EAP frames sent within AAA messages may never arrive at the EAP peer. For example, if a Notification is sent inside an Access-Reject, the 802.1X authenticator will send an EAP-Failure to the peer, and throw away the Notification. Similarly, in a cryptographically protected method like PEAP, the last packet will be an encrypted Success or Failure packet. This too will be thrown away, and a cleartext Success or Failure packet sent instead. If the method is attempting to be secure, it may not accept this, so we have a problem.
RFC 2284 doesn't say how to use multiple types one after another. But RFC 2284 does say that a Success or Failure ends the exchange, so once this is sent the conversation is over. This implies that after one Type is done, you just start another one. RFC 2284bis clarifies this.
RFC 2284 says only one type is included in a NAK. However, it appears that existing implementations will not blow up if more than one is included, they'll just only look at the first one. This makes it possible to include more than one; this shortens the negotiation if the other side supports multiple methods within a NAK but does no harm to implementations that don't.
Since EAP Success and Failure messages are not ACK'd, RFC 2284 requires that implementations be able to take "alternative indications" of success and failure into account. This is problematic, because no current implementations do this, and the nature of the alternative indications is vague. For example, does receipt of a PPP NCP or even an IP packet constitute an alternate indication of Success? Does receipt of an LCP-Terminate constitute an alternate indication of failure?
One big problem with this is that this makes it very easy to attack an EAP implementation. Just send any IP packet and the implementation will think it succeeded? Doesn't make much sense.
Recommendation is to delete the references to alternative indications. This will make EAP more media independent. Only problem is how to deal with the unACK'd Success and Failure messages. In retrospect, Success and Failure should have been EAP Methods like any other, with Request and Responses. We could still add this, although to remain backward compatible, implementations need to be able to NAK these types like any other. More discussion is needed on this.
Another objective of RFC 2284bis is to fix the transport behavior of EAP. There are a number of issues here. Use of the Identifier is not specified, though most implementations increment it with each new packet (it is kept the same on retransmission). Should the Identifier always start at 0? Does it ever wrap?
RFC 2284 gives a minimum RTO of 6 seconds but implementations do not do this. Some have variable times, managed via the Session-Time attribute in RADIUS. Some have lower values. Few adjust RTO via measurements of RTT or do exponential backoff as in TCP. Where EAP runs over a reliable transport (such as TCP within PIC) you can have multiple layers of retransmission: the TCP layer, the ISAKMP layer, and finally EAP. PIC states that EAP RTO is to be to infinity when running over PIC. But how is this done?
Note that in some implementations, EAP RTO was set so low that the NAS retransmitted before the EAP Response arrived. The NAS then sent the duplicate EAP Responses to the RADIUS server, confusing it. So there needs to be a requirement for duplicate detection on the NAS; although EAP responses aren't retransmitted, they can be duplicated. Similarly, EAP Requests can also generate duplicates and EAP peers need to deal with that, too.
A final objective of RFC 2284bis is to rewrite the security considerations section of RFC 2284. RFC 2284bis will include a threat model, and also will include "unfunded security mandates" for things like mutual authentication and cryptographic protection of EAP. We have to decide when to require this additional security: for what methods, for what media? Currently the draft states that additional security is required for wireless and use over IP.
The mandates are unfunded in the sense that RFC 2284bis says that additional security is needed but doesn't specify how to make it happen. If we have to get all that work done before publishing RFC 2284bis, things will take a lot longer.
As noted earlier, the original goal of RFC 2284bis is to take EAP to Draft Standard. However, if we need to add new features, or can't get the needed interoperability data right away, it may make more sense to recycle the draft to Proposed and get it out sooner. We will make the decision after the 802.1X interop event in May. It also may be possible to hold additional bakeoffs over the next few months. For example, WECA may do 802.1X interop testing.
EAP State Machine
Univ of Maryland
Bryan Payne and Nick Petroni
The goal of the State machine is to present a "strawman" state machine as well as some issues found in the state machine. The paper includes the Authenticator state machine, the peer state machine, as well as some issues and concerns.
EAP authenticator state machine
The Authenticator state machine exists on the server side.
Implicit in state machine diagram:
erroneaous packets not conforming to spec or not mentioned in state diagram should be dropped
notify messages can come in at any time, no state transition occurs due to them
State "init": s/w init, counter init, policy init
State "unauthenticated": send id req or auth req
State "peer id": can loop upto a fixed number of times
State "auth req": murky since many auth types, auth mechanism is responsible for updatePolicy()
What is policy?
Authenticator can send multiple requests and force peer to respond to multiple auth modes. Peer can NAK some of them, policy determines what happens if some of them are NAK'd. Policy not satisfied implies FSM returns to "unauthenticated" state Auth method succeeds implies goto "auth" state.
EAP peer state machine
Peer is at mercy of authenticator to decide where to go next.
According to RFC 2284, the peer can even drop straight into an "authenticated" state because of a "canned" success message.
Peer can have policy too and that can dictate that mutual auth is required before it goes to "authenticated" state.
Issues and concerns:
Significantly affects security
RFC 2284bis specification should define policy
Peer's control over state machine:
Can mutual auth really happen without peer and authenticator on both sides? Since a peer can never send a failure back to the authenticator, this can lead to inconsistent states between the two sides. For example, a Peer can fail to verify an Authenticator's certificate, yet the Authenticator sends a Success to the peer.
The Authenticator thinks that the Peer has been given access, but the Peer refuses to accept this.
A formal state machine is still needed for each authentication method
Presentations/papers are online at
802.11 EAP Needs
David Halasz <firstname.lastname@example.org>
Chair of IEEE 802.11 Enhanced Security Task Group (Tgi)
As many people know, 802.11 has encountered security problems. The IEEE 802.11 Task Group I has been chartered with improving 802.11 security. The plan is to do this by developing enhanced ciphers, including TKIP (for upgrading existing access points) and an AES-mode cipher.
IEEE 802.11 Tgi also needs key management and authentication techniques.
Different organizations want different solutions; some are using certificates; others token cards; some are using passwords. So one size does not fit all.
To address the diverse authentication and key management needs of customers, IEEE 802.11 Tgi has adopted IEEE 802.1X and EAP and is applying it to use with 802.11.
Many products are using IEEE 802.1X with 802.11 today. Cisco Access points and NICs support it; so does Microsoft Windows XP. Many other vendors have announced support.
IEEE 802.1X is actually being used in large 802.11 deployments now, with over 100,000 users worldwide. And many new customers are deploying it.
IEEE 802.11 Tgi is looking at EAP and therefore needs EAP methods that meet its security requirements. This includes the need for mutual authentication, resistance against offline dictionary attack, key derivation. Since the IETF owns EAP, IEEE 802.11 has written a letter to the IESG describing its needs. This is up on the IETF web site at:
To get these EAP methods done, the IETF seems like the right place since it has already published RFC 2284 and RFC 2716, and has ongoing work on EAP within PPPEXT, PANA, and IPSRA WGs.
What types of EAP methods is 802.11 looking for?
The answer is that we need methods for use in a corporate environment, methods useful in the home, for public access, for adhoc (client to client).
Sometimes EAP is implemented as a passthrough to a RADIUS or Diameter server. Sometimes EAP is terminated on the Access Point. Some devices implementing EAP may be low in processing power. It is desirable for some methods to be unencumbered.
Roaming from access to access point may occur, so that "fast reconnect" functionality is useful.
Right how the EAP keying framework isn't documented, so there is no clear guidelines for key generation: how to generate the key, what kind of key it is, how the key hierarchy is defined, how it is transmitted from AAA server to Access Point, and how it is used after that. There needs to be a framework for this.
In the IEEE 802.11 Tgi model there is an authentication server, an access point, and a station. The AAA server can derive keying material in its conversation with the station. The AAA server and AP are assumed to share a trust relationship set up via a shared secret or other credential. AAA attributes are needed to transmit the key from the AAA server to the AP. There are no standards for this today, and differing opinions on how it should be done so as to establish secure, 3 way key agreement. Ideally, these attributes should be standardized and available for both RADIUS and Diameter.
An EAP WG - Methods & Requirements for 802.11 Environments
Dorothy Stanley, Agere systems
[ slides ]
Dorothy is in the 802.11 Tgi Security Task Group, but is not speaking today as a representative of 802.11. However, she will reiterate the importance of the work being proposed here, following on what Dave Halasz said.
when IEEE 802.11 Tgi was started, it focussed on three areas to improve the security of 802.11:
1. privacy/confidentiality of data over wireless link
2. message integrity/authenticity of data sent over the wireless link
3. lynchpin: end point / end entity / user authentication. This is what needs to be discussed here & in an EAP WG.
The IETF needs to provide a venue to discuss, define and specify EAP methods that provide for mutual authentication and key derivation.
802.11 Tgi has gone down path of choosing 802.1x for its authentication mechanism and adapting this for use with IEEE 802.11.
Why did IEEE 802.11 Tgi choose IEEE 802.1X and EAP. It is available today, and it works. It is the best thing we have to date; it provides for flexibility and extensibility within the EAP framework.
Authentication needs are diverse; EAP accomodates this.
Some customers want to authenticate their users with certifactes, some want username/passwords. Others want secureid tokens or OTP. In the future others may want new things like Biometrics. EAP can accomodate all of this.
Why not only support one authentication method. Wouldn't this make things simpler? How about Kerberos, for example. IEEE 802.11 Tgi couldn't get agreement that one size fits all. And Kerberos had potential security vulnerabilities: if a single method is cracked, you are stuck. If you have a framework, you can substitute another method. The EAP mechanism provides the best way of supporting multiple end user credentials and key derivation algorithms.
For security, you need authenticity, message integrity and confidentiality: authentication drives / provides info needed to feed those other two via the keying material. This allows you to link the identity verified in the authentication to each packet that arrives on the link, assuming that you have a ciphersuite supporting per-packet authentication and integrity protection. The new ciphers developed by IEEE 802.11 Tgi, namely TKIP and AES, both provide this.
One of the other requirements for IEEE 802.11 Tgi is a venue to specify where and how methods securely provide keying material for encryption and integrity protection. Some EAP methods provide for this keying material; some don't. And not all methods provide keying material of the same kind. Key hierarchies may be method specific; should this be more general?
If you're using a secure network, the authentication information must be used to derive keying material. Should this be standardized? If so, then it should be handled in the IETF.
Many EAP methods are being created today. A vendor can come up with an EAP method and say "it is great and wonderful". But it would be nice to have some peer review so customers need a venue where security claims of a method can be evaluated.
EAP methods have been applied to wired and wireless applications. In wireless applications we have 3 endpoints; supplicant (end user), authentication server and access point. Today we have two conversations: one conversation between the supplicant and authentication server; another between the authentication server and access pont. Thus, we have two 2-party conversations; do we need to support three way key agreement? Let's get a considered opinion on this because we really want to use this.
I see value in using a tunneling approach. We will be hearing monre about EAP TTLS and PEAP but there are a lot of concerns now being raised as 802.11 technology really gets deployed more broadly. Cisco & Microsoft have deployed it.
You see it in public places as a complement to 3G. It is real, growing, and it's a great thing. It may be that these approaches provide a way for a secure tunnel that any EAP method can work within so every method doesn't need to solve the key distribution problem.
. Authentication is critically important.
. Key derivation enables a proper solution for confidentiality and integrity
. EAP is needed in the real world, today for securing Wireless LANs.
Cryptographic Protection of EAP
Three major methods for cryptographic protection of EAP have been proposed:
. PIC: EAP protected by ISAKMP over UDP and TCP.
. TTLS, PEAP: EAP protected by TLS.
What can cryptographic protection of EAP provide?
. Increased immunity from offline dictionary attack
. Fast reconnect (e.g. TLS session resumption, IKE Phase 2 w/o PFS)
. Support for fragmentation and reassembly (not provided by EAP)
. Well understood key derivation and key hierarchy
. Protected method negotiation
. Protected Notification
. Protected Success and Failure messages
. Identity protection (for privacy)
. Protected ciphersuite negotiation (for the cryptographic protection)
. Protected ciphersuite negotiation (for the link layer ciphersuite)
[ slides ]
Paul Funk, Funk Software
EAP Tunneled TLS: EAP-TTLS
draft-ietf-pppext-eap-ttls-01.txt ( not yet on site )
"EAP TTLS is the be all and end all of security protocols".
It does a lot of things that are necessary for wireless networks:
1. It conceals with strong crypto any user credentials passed on the network
2. It supports tunneling, mutual authentication, key derivation, key negotiation between client and access point.
3. It works with the RADIUS and Diameter AAA protocols.
Credentials tunneled within a TLS tunnel can contain either EAP or legacy authentication methods such as PAP, CHAP, MSCHAP, etc.
Overview of EAP-TTLS
Dictionary attack vulnerabilities
On wireless networks it is easy to sniff a large number of exchanges.
If you are using a protocol such as CHAP, there is an MD5 challenge; if you have low entropy password, then it is easy to do an offline dictionary attack to derive the password. This means that it is essential in the presence of eavesdropping to protect that kind of credential exchange.
When people are mobile they may not want other people to know where they are; it is useful to have a protocol that allows this.
It is useful to be able to tie the credentials provided during authentication to each subsequent packet. This can be done by using a derived key in a ciphersuite. This protects against a hijacking attack by binding the key to per-packet authentication. To accomplish this, you need to be using a ciphersuite supporting per-packet integrity, like TKIP or AES.
Users may want credentials protected deeper into network than the point of connection. For example, if you are authenticating within a coffee shop or hotel you may not want to unbundle your credentials in that local networks. But if you have a relationship with a provider and you believe they have proper controls, you may prefer to go to them before credentials are displayed.
Lightly configured access domains need to know first hop where to send TTLS information; from there info can be passed on to further auth places.
In roaming between access points it is useful to support fast reconnect.
But it may also be necessary to use more than a single NAI.
Objectives of EAP TTLS:
* mutual auth
* support of legacy password protocols: CHAP, MSCHAP, PAP
* Support for securID
* Support for EAP methods
* Support for client certificate authentication
* Distribution of keying material to the access point in a secure way via RADIUS
A TTLS AAA server terminates the TLS connection and passes it to the home AAA server.
The client talks through the Access point to the TTLS server, performs the TLS handshake a creates a tunnel. At the TTLS AAA server, inner authentication is revealed and forwarded to the home server using RADIUS. The home AAA server is optional, since TLS can be terminated at a proxy. Password data is protected between the client and the TTLS AAA server; based on the keys negotiated, crypto keys are provided to access point by the AAA server.
Within EAP TTLS, EAP is encapsulated in TLS records. This differs from RFC 2716 in the following ways:
* The authentication doesn't stop after the handshake phase.
* The data phase is used to securely transmit user credentials.
. Any legacy protocol may be tunnelled: PAP, CHAP, MSCHAP, MSCHAP-2
In CHAP, normally the NAS generates the challenge, and RADIUS trusts the NAS. This creates the possibility of a replay attack. EAP TTLS protects against this by using the TLS master secret as the basis for the challenge. The PRF is used on the master secret to generate unpredictable challenges at client and server; this means there is no possibility of replay attacks.
EAP TTLS doesn't just tunnel EAP; it can do protected ciphersuite negotiation via AVPs sent from the client to the TTLS server and from the access pont to the TTLS server. The client collates the ciphersuites and picks one based on the configuration. The TTLS server generates keying material for the ciphersuite and notifies the client and access point.
Magnus Nystrom, RSA
PEAP stands for Protected EAP. It provides:
. Mutual authentication
. Key derivation
. Protected user authentication.
. Fast reconnect
. Fragmentation and reassembly
The architectural model: a peer, authenticator (NAS), and authentication server (which may connect to another authentication server)
Part 1: Establish a TLS connection. TLS record protocol provides a secure connection between peer and auth server. Assumption is that the TLS server is in user's home domain, and that the user's station is configured to validate the server cert.
Part 2: Authenticate user
The user on the peer authenticates by tunneling another EAP mechanism (e.g., Generic Token Card) inside an EAP-TLS connection.
3: Generate session keys.
The Master session keys are used as keying material for the session between the NAS and the user. Transient session keys are then derived by the client and NAS.
PEAP uses the TLS PRF function to derive this.
The Session key transported from server to NAS using RADIUS attributes.
There are at least three ways to support roaming/reconnect:
. New full authentication
. TLS session resumption (if session ID is valid, handshake finishes promptly). It is important that the session not be resumed unless the client has been authenticated in a previous part 2 conversation.
. Context transfer
. Injection of fake EAP/Success (or Failure) packets.
. Solution: Clients only accept EAP success/Failure inside tunnel
. Roaming to a Foreign domain
. TLS resume with home server may be too slow (need to transfer context)
Questions and Answers:
Phillip Halam-Baker: PEAP reminds me of ISAKMP.
I'm not seeing a TLS solution, I'm seeing a solution that takes some stuff from TLS and mixes it with stuff from EAP. I'm not getting the feeling of layer boundaries
What does TLS buy us? This only makes a good clean protocol harder to analyze. Taking the master secret out of TLS could be a bad thing for TLS. External use of master secret is not anticipated by the TLS spec.
Applies to TTLS too.
Magnus: The master secret is derived between the client and authentication server, but is never used by PEAP or EAP TLS. In fact, most TLS APIs do not permit retrieval of the master secret; it is only possible to call the TLS PRF. So unless there is a flaw in the TLS PRF this is not a problem.
X: I am getting a Deja vu from the IMAP working group, the LDAP working group, and the BEEP working group. We have lots of solutions to these problems. If a WG goes forwards we need to see if we can take advantage of existing solutions and technologies such as SASL. I also think we need to examine and clearly state the keying requirement.
There is no mention of key derivation in RFC 2284, so it is something of a side ffect. We need to more clearly state what you get from EAP if we're going to do this; make it more formal if keys are a side effect of methods.
Magnus: We are trying to build on existing protocols here.
Authenticated Failure and Success
[ see slides ]
Complex AAA environments are a significant problem if you don't have protection of both Success AND Failure. In this model (brokered), we are concerned about corp 1 and its user. There can be a number of provides some of which can be untrustworthy. There can be multiple corporations using the same infrastructure, some of which don't trust each other.
This means that an untrusted proxy may manipulate the AAA attributes where there is no end-to-end security such as is provided by Diameter CMS-SEC. If the EAP Success or Failure message is unprotected, then it can be changed by an unscrupulous proxy.
To fix this, the AS needs an authenticated path to inform the station of the reason for denying access. You can accomplish this via a complete EAP exchange producing session keying material, signing the failure with a reason, such as a security or cost reason. Without this the user will be in the dark as to the reason for failure.
So there is a need to protect both the EAP failure and success.
James Kempf: I think all this work looks good, interesting and needed.
Caution: Wireless links are vulnerable to ARP spoofing and Neighbor Discovery spoofing; are any of these methods dependent on routing to get beyond initial subnet? If so, there may be potential for a problem.
Discussion of EAP methods; 5 on agenda.
EAP/AKA, EAP/SIM, EAP/SIM6
[ see slides ]
All three methods capitalize on GSM authentication infrastructure for doing user / network auth. There are implementations of all three methods.
Provides 2 modes for doing auth; GSM algorithm mode; UMTS.
Usage scenario: WLAN access authentication (mobile phone, PDA, PC card).
Enhanced GSM authentication; possibility to use existing GSM SIM cards and GSM roaming infrastructure.
Derived from previous method; does the same thing for WLAN access authentication. encapsulated in AAAv6/
EAP/SKE (shared key exchange)
Luca Salgarelli, Lucent
In scenarios where clients roam, there are more and more cases where foreign AAA server will be far from the home AAA.
There will probably be a bandwidth restriction between the client and the network. It makes sense to optimize bandwidth by sending minimal messages between the foreign AAA and home AAA server.
We achieve mutual auth and derivation of master key in only one round trip between foreign AAA and home AAA, minimizing EAP messages between client and authenticator.
Scenario: roaming clients in 802.11, but nothing stops it from being used on any IEEE 802 LANs.
This method supports mutual auth between the client and the home AAA server.
Fast reconnect is not supported but it is probably not needed, since there is only 1 round trip.
This is designed for use with RADIUS, but it can work with Diameter easily.
There is no key hierarchy specified in the protocol, but it is hoped that there will be a standard way to derive keys from the master key.
Question and answer:
Glen Zorn: You're worried about bandwidth restrictions, but it's designed for 802.11; how big are the things you'll be sending because there's plenty of bandwidth.
Response: Really depends where you are and how many people are using the same access point. In non-optimal conditions, rates can be low; many users may reduce this further. Depends also on how many times auth will occur during roaming among access points. Probably talking about 10s of 32-bit integers.
Glen: If your 802.11 bandwidth is that low, you probably won't be able to do anything. This makes sense for cellular nets, less so for 802.11.
Unkown: What is the IPR contamination status?
A: Lucent has filed a provisional patent on the way MD5 is used over the nonces; not sure on status.
This protocol is a short-term interim step because passwords don't go away as fast as we'd like. If we have passwords, there needs to be a way to change them. There is an existing MSCHAP mechanism that supports that and we Want to put that capability into EAP.
David Jablon, Phoenix Technologies
This presentation is generally about EAP and Password Authenticated Key Exchange
Password-only authentication. SPEKE is the method that Phoenix has IPR over. EAP/SRP is related.
SPEKE is safe with minimal assumptions. It can be used wherever there's a microprocessor on both ends.
It can be used standalone plaintext & tunneled. It can be used without other infrastructure, EAP/SPEKE works like EAP/SRP but with better key derivation.
When used with other infrastructure, you can have: EAP-SPEKE, PEAP+SPEKE, TTLS+SPEKE, etc.
SRP-4 vs SRP-3; SRP-4 addresses IP questions ("simplifies" them), slightly more broadly useful.
Unknown: You navigated through unpatented technology and patented the solution that you found?
Unknown: SRP-4 is immune to dictionary attack, can you explain that?
A: One run, one guess means that an attacker only gets one guess at the password for one run of the protocol. Can't record the traffic and crunch it offline. Contrast with challenge-response wheree you can record traffic and run an offline attack on it.
More questions to ponder:
How do these cryptographic protection methods differ?
What problems do they solve?
Should the IETF standardize:
None of them?
One of them?
More than one?
Should some EAP methods be required to run over a "protection layer"?
If so, which ones?
When is this required?
If the protection layer handles key derivation, can EAP methods avoid doing this themselves?
Steve Bellovin: The crypto protocols are subtle and weird things. Picking them apart and using pieces of their innards is not recommended. They are hard to build; the oldest protocol, from 1976; a flaw found 18 years later. Strong bias toward a well understood method. Things don't always compose neatly. Unless you're really good, really lucky or both.
Unknown: Should EAP be in the business of defining mechanisms at all? In particular, this is the 3rd or 4th protocol that goes and defines the same mechanisms. This is 3rd presentation on SPEKE at this IETF. There should be some reusable technology. It is possible to map to an EAP mechanism from a SASL mechanism. Should focus on well-defined keying architecture, and on the requirements of the tunneling protocol, etc; that is quite enough.
We don't need to do mechanisms on top of that.
PHB: I'd reiterate what Steve says. The rush to reuse parts of TLS is because "it is understood". It's okay to reuse the method; not necessarily reusing it and then bashing it out of shape. Security protocols do not reuse very well. Must redo analysis from scratch when you start delving into them, not building on top of them. Like in IPSEC with IKE and JFK; instead of trying to reuse TLS, why not reuse a simple protocol like JFK?
X: We're going where we were in Orlando. We came to the conclusion that it is hard to use SASL and GSSAPI over a link layer.
Most of the time EAP is run at link layer.
Aboba: EAP/GSS was experiment of using GSSAPI methods. It was a failed experiment for a bunch of reasons; it was very difficult to prove you had enough entropy to generate keys for any GSSAPI method. Plus it was not appropriate for use with wireless and over the Internet, because of dictionary attack weaknesses. So because of key derivation and dictionary attack vulnerabilities, EAP GSS cannot be run securely except in a protected channel.
Glen: I'm confused again. I've not heard anybody whacking out chunks and organs off TLS and shoving them into EAP (yet). I heard people talking about running TLS, then doing something else. They are using PRF (general purpose function). As Magnus points out; if I ruin TLS security by changing the strings used, then there's a problem.
There is no work on methods or crypto in the WG charter. The milestones relately solely to revising RFC 2284, developing a keying framework, and EAP applicability statement. The milestones are to be finished in September, 2002.
Should there be more or less items?
John Meyers, Netscape:
If you require channel protection to meet your security threats then you need to specify what are the mandatory-to-implement mechanisms for that.
Otherwise it won't work. If it is the case that the current MD5 challenge does not meet your security needs. If you can have two conforming implementations that don't work with each other, your standard is broken.
X: Is the work on key derivation etc going to stop? If not, then it needs to go somewhere (e.g., EAP working group) where it can be studied and reviewed.
Aboba: Security considerations in RFC 2284bis can provide the criteria to evaluate the cryptographic protection methods.
X: Dorothy's slide was interesting; it asks whether or not this is a suitable venue to address the problems these guys are addressing. No presentation addresses the need of authentication with radius server and access point.
Aboba: AAA working group is looking at that. That is a AAA security issue for AAA wG.
X: I like this charter; especially putting state machines in. One of probs with existing EAP work; very layered protocols; as they exist today, too hard to do security analysis if they meet any of the claims that they are making. Won't be feasible to do the security analysis unless the state machine becomes a lot more formal.
X: I think actually the state machine in EAP is black box; the method.
It is important to review the methods being proposed; not sure how this will be done.
Aboba: IANA considerations states expert review is needed. We must decide what that review will be. Once we state that expert review is needed, WG will be flooded with method reviews.
X: I don't know that I can suggest an answer. But when defining what one has to do in order to get IANA assignment, the authors intended that expert review be given to designated experts..
Aboba: Designated experts is different in IANA from expert review.
X: There need to be designated experts or requirement of consensus.
Thomas Narten: On the IANA thing, IANA wants to ask one person and get one answer.
Expert review gives you the discretion to say no, pending discussion.
X: We've dug a hole for ourselves; we'll get involved whatever we say (expert review or designated experts). It's not reviewing docs, it's reviewing crypto. We don't have people to do that. There may not be a solution.
Glen: I'd rather leave RFC 2284bis in PPPEXT WG and take this working group work on other things, such as what we've been talking about for last hour; EAP types and their various qualities. Whether or not we have cryptographic expertise, we've attracted enough interest that we'd get help.
Aboba: Are you recommending taking on the entire agenda or a piece of it?
Glen: RFC2284bis can stay in PPPEXT; the rest of the "stuff" can come here.
X: I have to agree with previous speaker; if that work is going to get done, it should get done in a security area wg that is chartered for that. That is the stuff we talked about today. We should do crypto protection and all methods. I'd like to argue that we shouldn't do methods but we can't decide that here. Should be in a security area group.
Luca: Second Glen's suggestion. Need a venue to standardize EAP methods.
We have 9 method specs so far because there is a need for standarization.
X: Too bad that the other 50 couldn't come here.. How do we pick which ones we look at. I don't think there's a resolution. There's a set of requirements and a lot of methods. I don't think 802.11 will use many methods; why can't 802.11 give us a recommendation?
Luca: We should Work on requirements first, with some of the possible usage in mind, such as 802.11. In those requirements we should have reqs that would help security people do review. Methods should be analyzable in a reasonable length of time.
PHB: If you want crypto guys to come by your WG; best not to say we'll accept anything; need competition for one winner. Usually the crypto guys try to kick out everyone else's one and then you get a good soln.
Or wait until it is deployed and let them break it after deployment.
Aboba: So you're advocating reqs, and then having a contest based on those reqs.
X: EAP repair should not be done in pppext. IEEE requires IPR
Aboba: Is there interest in chartering a working group?
EAP Tunneled TLS Authentication Protocol
'EAP/AKA, EAP/SIM, EAP/SIM6' Three EAP Method Proposals
Name of the method: EAP/SKE
Name of the method: EAP/AKA & EAP/SIM
An EAP WG - Methods & Requirements for 802.11 Environments
EAP & Password Authenticated Key Exchange
EAP State Machine
EAP-SKE: Shared Key Exchange
Extensible Authentication Protocol State Machine
Authentication Failure 'Doodles'