2.7.3 EAP Method Update (emu)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-03


Jari Arkko <jari.arkko@ericsson.com>
Joseph Salowey <jsalowey@cisco.com>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

The Extensible Authentication Protocol (EAP), defined in RFC 3748 is a
network access authentication framework used in the PPP, 802.11,
802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is
a simple protocol and actual authentication happens in so called EAP

Over 40 different EAP methods exists. This includes many undocumented
and proprietary methods. Only a few methods are documented in RFCs,
and out of these, methods listed in the original EAP RFC are no longer
applicable in today's environments. For instance, none of the EAP
methods that are applicable in a wireless environment are in Standards
Track RFCs. This poses a problem for, among other things, the
selection of a mandatory to implement EAP method in new network access

Some methods have been defined in Internet Drafts, many of which have
expired or have not been updated to reflect the true behavior in the

The lack of documented, open specifications is a deployment and
interoperability problem. In addition, new requirements such as those
posed by wireless environments are creating needs that are currently
not well matched by existing methods. For instance, RFC 4017 documents
IEEE 802.11 requirements for EAP methods. Currently, there are only a
few EAP methods that satisfy the mandatory requirements listed in this
document, and there are no methods that satisfy all requirements. Some
proposals for such methods exist, however.

Finally, there are authentication mechanism types that are not
supported by existing RFCs. For instance, there is no widely
applicable method that would be able to authenticate using shared
secrets in a wireless environment.

The purpose of this BoF is to continue the work started in the EAP WG
and in the SECMECH BOF, in a manner focused on few key EAP method
needs. One immediate goals is to bring existing widely deployed EAP
methods such as EAP-TLS (RFC 2716) to Proposed Standards with
clarifications learned during deployment. Another goal is to
standardize additional mechanism to match the current requirements.

The BoF should have an organized discussion of what specific needs the
community sees as worthwhile pursuing, and to discuss the specific
technical solutions.

The potential work items of the group include:

1. Revision of EAP-TLS, to be placed on the standards track. The
primary goal of this would be to bring the specification up to date,
clarify unclear issues, etc. A standards track specification would
also enable the consideration of EAP-TLS as a mandatory requirement in
other Proposed Standard specifications.

Note that there are limitations in current implementations which may
need to be considered during this update. Similarly, the existing EAP-
TLS specification may not accommodate all types of extensions in a
backwards compatible manner. For instance, there may be issues in
adding channel binding support or the use of new TLS mechanisms such
as TLS PSK when run against RFC 2716 compliant devices. These issues
shall be investigated and clarified; the revised EAP-TLS must be
backwards compatible with existing deployment.

2. Shared Secret - a pre-shared secret method. This is likely to be
widely deployed if available, and another likely candidate to be
referred to by other Proposed Standard specifications. Desired by IEEE

3. Password based - essentially a shared secret mechanism that
provides resistance to dictionary attacks. It should support various
backend databases of password that use different storage techniques
and perhaps support for one time tokens as well. Could use something
related to EKE or a tunneling approach. Desired by IEEE 802.11, and
would likely be widely deployed if available.

4. One time passwords - a secure one-time password -based mechanism
that can provide keying material.

5. Tunneling - a tunneling method is useful to protect weaker
authentication mechanisms. Tunneling methods are also used to exchange
other types of authentication data.

6. Channel binding support - it has been suggested that new methods
should have an ability to authenticate identifiers claimed by NASes.
But it has also been suggested that backwards compatible extensions to
do this in a few commonly used current methods should be developed for
security reasons.

Similarly, for the ability to retain EAP method and media indepedence,
it may be necessary to have coordinated approach or even binding data
formats between different methods.

7. Enrollment mechanisms - methods to automatically enroll clients in
wireless environments. However, this list should not be taken as a
proposal but rather as a template that can be used to determine
community consensus on which of the items are worthwhile. It is
certainly impossible to take on ALL of the above tasks, so a set of 3-
4 priority tasks needs to be determined. There may also be IPR,
complexity, or existing deployment concerns that make it undesirable
to take on work for a specific item.

Although the GUAM work is not a subject of the current BOF, the
group's charter may later be extended to cover GUAM work discussed in
the SECMECH BOF in IETF-63. This requires an explicit rechartering,

The creation of this group does not affect existing procedures for
IANA allocation of EAP method type numbers, or the publication of
individual submissions documenting EAP methods as RFCs.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Thursday, November 10, 2005, 9:00-11:30
Vancouver, Canada

Based on Notes taken by Nancy Cam-Winget Notes Edited By Joe Salowey

Chairs: Jari Arkko, Joe Salowey


Background Discussion and relation to Secmech - Sam Hartman

+ Conclusion of previous BoF at IETF 63:
  - unify authentication mechanisms currently existing in IETF would be nice, needs more people
  - EAP mechanisms meeting requirements of others standards organization is important

+ today's meeting looks at the second conclusion
  - charter working group to meet EAP method requirements of other SDO's so it's not a free for-all, it's a small number of mechanism to meet external requirements
  - for now "grand unifying framework" is out of scope for the working group.  But those working on the specific EAP methods would work with those interested in unifying the different framework to ease the path further down the road for when it may become the scope of the working group charter.

Rohan Mahy: will the 7 presentations address the requirements imposed by the SDOs?
Sam Hartman?: I don't think so
Jari: It will be discussed later.


BOF Goals - Joe Salowey 

Presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-7/sld1.htm

+ Charter group to focus on EAP methods.
+ Focus on standardization of 1 or 2 methods. Once completed charter may expand to include other work. 
+ What methods?
  - what infrastructures are required most?  (PKI, shared secret, username/password?)
  - which ones are likely to succeed in a short amount of time?
+ Process is in place to go through IANA for EAP assignment; that will not be replaced, it will persist.  This group is more focused to enable some of the drafts to become standards track and of better quality.  So this group is not to replace the already existing process for EAP assignment and individual submission.


EAP-Method Requirements - Bernard Aboba

Presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-3/sld1.htm

+ Work in progress: peer to peer in 802.1af RFC 4017 lists method 
+ requirements
  - Different credential types mentioned
  - mandatory requirements for key strength, key derivation and key distribution to name a few.
  - No Requirements for PSK

Don: Why is pre-share key different than password?
Nancy Cam-Winget: in 11i we differentiated based on ease of deployment
Bernard: differentiation was conscious

+ Some thoughts
  - some usage scenarios still unsolved
  - don't try to drain the swamp or boil the ocean

Derek Atkins: Lack of kerberos, does that fall under username/password?  
Bernard: yes, it probably would.
Rohan Mahy: Unmet requirement of public/private key with no certificates. This could that be met using certificates without a trusted root.
Hannes Tschofenig: agrees with Rohan and stresses username/password can be dealt with existing methods.  
Bernard: while they may exist, they are not widely deployed.  
Hannes: there's a difference between widely deployed vs. widely used.


802.11 and EAP methods - Jari Arkko on behalf of Dorothy Stanley

Presentation http://www3.ietf.org/proceedings/05nov/slides/emu-1/sld1.htm

+ 802.11i requires one or more published EAP methods.
+ Bernard's presentation covered most of the contents of this in this presentation.


Overview of proposed EAP methods, credential types and uses - Pasi Eronen

Presentation http://www3.ietf.org/proceedings/05nov/slides/emu-14/sld1.htm

+ Many methods using shared secrets.

+ Passwords (his definition):
  - distinction with shared secret methods is that username/password requires access to a database
  - many widely used and deployed methods using password, most of them using tunneled mechanisms (EAP-FAST, EAP-TTLS, EAP-PEAP)
  - tunneled methods also used for one-time passwords and tokens
  - No kerberos specific method (EAP-GSS expired)

Hannes asks: got impression that use of kerberos within EAP was really bad idea, so that's why it might have been dropped.  
Pasi: not sure we want to discuss now. 
Bernard: says different environments, like Universities that are using it today, doing it through PAP.  
Sam: Methods that cannot deal with kerberos pre auth, methods where one peer has no Kerberos credentials at the end of the authentication and methods that expose the long term shared secret should not be identified as kerberos methods.  

Yoshihiro Obha: With regard to the differentiation between password and shared secret being that password stored in a backend database, if there is an API to get the password wouldn't they be the same?
Pasi: The API may not provide access to the password itself. 

+ Summary
  - PKI: some are using EAP-TLS.  If we were to adopt this, may be good chance.
  - Shared secrets:  no methods.  Believes we should have a standardized method.  Should have a good chance of succeeding on meeting this requirement.  But will require a substantial amount of work, especially in building consensus.
  - Passwords: many proprietary methods widely deployed and used.  It would be nice to have a standardized means, but pessimistic on its success.  Not sure how much the vendors would be interested in standardizing.  May be very difficult to get consensus in the IETF.

  - Shared secret methods

Hao Zhou: Is the difficulty in getting vendors to change their interface to the databases or the authentication methods with no data base change?  
Pasi: difficulty is more in getting the clients to implement the standard method.
Bernard: Definition of password different for 802.11. 802.11 distinguished between password+asymmetric auth from pure password.

  - Kerberos: no new methods, but not much demand.  

Bernard: the university community would have an interest in using it in internet 2.  
Rohan: comments a better way to say it is that it is probably not the first thing we would do as responding with SDOs would take precedence in priority.

  - Other possible work is to address channel binding.  Not sure there is strong demand and is unclear on its success.  

Sam:  methods that we standardize will have to satisfy the Housley criteria. 

BOF Discussion and Questions

Presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-13/sld1.htm

X.509 certs, shared secrets, passwords, one-time passwords, cellular credentials, kerberos, channel bindings
+ Jari presents an overview for how to lead this discussion.

Yoshihiro: Channel Binding, does each method require channel binding? is common functionality?
Jari: Common to all methods and things we can do for existing methods.  

Madjid: Fast reauthentication required for methods?
Jari:  Yes
Bernard: Cellar credentials are already covered.  OTP is not as high priority, don't see the demand.  What looks important are shared secrets and passwords (pure passwords not asymmetric).  
Sam: clarifies on shared secrets, shared good keys, shared low entropy keys and then there's passwords where server recovers the plaintext.  Third category is only possible with a server cert.  In the 2nd case, people should follow the work that's not been done in the scared working group and be aware of why it has and hasn't progressed.  
Pasi: Password against existing database is most important. Such as using a tunneled proprietary thing which will require a cert of something to authenticate the server.  
Hannes: highlights that we might fail if we rely on a backend server. Learned from sacred working group

Madjid: comments whether there's no work needed to EAP-SIM but queries whether the group should standardize on this.  
Jari: IETF has approved the individual submissions of EAP-SIM and EAP-AKA
Sam: approval status of informational RFC is not the seal of approval from IETF, it should be a standardize by the group as it will require a fuller review.  
Madjid: comments it would be better if it had a fuller review.  
Sam: asks whether the group would be allowed to make changes to EAP-SIM or EAP-AKA before it gets standardized?  
Madjid: doesn't know, but would like to see a review as he believes it will be widely deployed in WiMax.  Interested in seeing if EAP-SIM/AKA could be used securely, so requests a secure review.  
Pasi: comments that they went through a very long process, they didn't "just" get published, it was widely reviewed and became informational since it was clear that there was no consensus to standardize it.  So we have to live with the limitations it has and the resulting method may not be as nice unless we impose that SIM cards be changed.  
Rohan:  if the group decides on what changes would be made, it would be irrelevant since SIM cards can not be replaced as a result of IETF spec.  

Hao Zhou:  different take on one-time password.  Agrees that we need to get the vendors working together, but if we solve the standard password methods, then we may be able to get the one-time password issues addressed as well.  We being Cisco.  
Dave Mitton:  defends one-time password.  Though, Pasi hit a point that there is an assumption that there's a method to protect the one-time password and bottom line is that RSA is interested in putting their protocol out to the IETF. 

Michaela Vanderveen: why is the channel binding important?  
Jari:  it could become a separate item and not a hard requirement for every method.  
Michaela:  as this is an IEEE optional feature what should we treat it?  
Jari:  consider both optional and mandatory requirements.   
Pasi: comment on channel binding is separate item, as it is a feature of the method, it would be important to do it roughly the same way in all methods so that the different layers do not need to know the specific method.  
Joe Salowey:  we need to clarify what is meant by channel binding is.  3748 is not clear on a mechanism.
Pasi: there's 3 diff ways the term is used.   Same identity is used by NAS in both with the AAA server and the peer.  

Rohan:  wants to talk about enrollment, should be a high priority item on the list.  Higher than one-time password and cellular credentials.  We look at stuff as technologists and not ordinary people.  It's a problem when different devices in factories, hospitals with no display, so providing a way to enroll them is essential for their deployment.  Some vendors in consumer space are doing proprietary mechanisms for their enrollment, so it's important for this group to address the problem to come up with a  standard mechanism.  In terms of priority,  EAP-TLS is highest priority then either shared-secret/password is second but after its enrollment.  
Jari: speaking as a vendor, don't think we should work on cellular credentials.  Don't see how we can effectively address those vendors without hardware intervention.  Small updates on EAP-TLS would be on top of the list and then channel-bindings on the methods would be second.  Third would be shared-secrets.  In response to Rohan, believes enrollment is a big problem and it would make sense to address but have reservation of how likely we'd succeed in defining this.  
Hannes: comments on Rohan, agrees and advocates for this work.  But there seems to be discussions and impressions that some vendors don't really care. 

Madjid: is the issue that we want to inject channel binding in every method?  
Jari: maybe but it is not germane to today's discussion.  The group is chartered to address some of the keying framework but we're not directly chartered to address the channel binding per se.  We are mute on how we would address channel binding, e.g. as method independent or dependent.  
Michaela: is it a requirement?  
Sam: believes it is because it is part of the Housley criteria. 

Jari: reason for this as a possibility that we could make an extension to some (existing) methods to allow them to achieve channel binding.
Rohan: unclear on what channel binding is...seems like it's clear we need to do it, but the questions is how?  all methods or independent?
Joe: we can look to see how to ensure that its done consistent for all methods, or we can leave it to each method to achieve it on its own which may be inconsistent. Consistency is probably better so we can understand what it means when it is claimed.
Rohan: asking for a single document for how channel binding is to be achieved?  Address it in terms of a work item.
Jari: Sam will require that all methods we standardize will address channel binding.  Question is whether we do something more, where the "more" is a general document that attempts to update already existing methods.
David Mitton : some EAP authors have tried to do channel binding and run into issues into RFC 3748. Needs clarification. Its an issue.
Jari: that's a discussion for the EAP group
Sam: recommends that we drop the channel binding question.


* Do you believe EAP methods for infrastructure of type X.509 are important?
   Yes: lots of hands   No: no one

* Do you believe the IETF should work on standards track EAP methods for X.509?
   Yes: lots of hands   No: no one

* Do you believe EAP methods for infrastructure of type strong shared secrets are important?
   Yes: Many hands (less than X.509)  No: no one

* Do you believe the IETF should work on standards track EAP methods for strong shared secrets?
   Yes: many hands   No: no one

* Do you believe EAP methods for infrastructure of type weak shared secrets are important?
    Yes: 22   No: 2

* Do you believe the IETF should work on standards track EAP methods for weak shared secrets?
    Yes: 13  No: 8 

* Do you believe EAP methods for infrastructure of type passwords are important?
    Yes: 25  No: 0

* Do you believe the IETF should work on standards track EAP methods for passwords?
    Yes: 13  No: 0

* Do you believe EAP methods for infrastructure of type OTP are important?
    Yes: 6  No: 4

* Do you believe the IETF should work on standards track EAP methods for OTP?
    Yes: 4  No: 6

* Cellular credentials important?
    Yes: 23   No: 1

* Cellular should IETF work?
   Yes: 0   No: lots of hands

* Kerberos important:
   Yes: 17 No: 0

* Kerberos IETF work?
   Yes: 17 No:  2

* Enrollment important:
   Yes: 18  No: 0

* Enrollment IETF work
    Yes: 5 hands  No: 0

* Many hands raised to willing to contribute to this group.

Joe: Same order of interest for X.509, strong/weak and password based secrets.  Some support for Kerberos though not as much as the other credential types.

*How many items?

Sam: had hoped for only 2.  Note some of these can be combined.  Let's try to clarify some of the polls.

Sam: how many people believe the existing password databases are sufficient to meet the strong secret passwords.
Hannes: comments that merging them would be difficult as the device types would be different.
Sam:  talks about dropping some of them.
Hannes: do not understand the implications of dropping or merging them.  Perhaps we should ask whether we're willing to standardized on EKE, SRP, etc.
Rohan: agrees as we didn't ask that in the poll explicitly
Sam: ok so 1st category is like TLS PSK and kerberos variant,  problem is that it depends on strong key, no certs.  The 2nd category is like SPEKE, EKE, DoCoMo proposal, SRP where it's not cert based but the issue is the IPR (weak shared secret).  The 3rd category is actually sending the password in a protected tunnel.  
Hannes: clarification helps, but there needs more investigation where databases are not used but certificates from server and password from the client are being used.
Jari: we can't do everything, especially if there is IPR.
Sam: keep in mind that this if for the first round.  We can come back and do more.
Hannes: who knows by then, the IPR might have expired!
* Are you willing to work on strong shared secret?
   Yes: 4 1/2

* Are you willing to work on weak shared secret (EKE etc.)?
   Yes: 2 

* Are you willing to work on existing password database
   Yes:  4

Jari:  so it looks like strong shared and password are close.

* Seems like there's lack of critical mass.
   Sam: 4 means 4 document authors.  We need to ask for reviewers as others would be willing to review.

* Who's willing to review generally (anything)?
   Significant number of reviewers.

Sam: not comfortable working on 3 methods out of this group.  Consider trivial ways in which some of these can be combined.  So, if the working group can remove one of the methods and still not violate requirements, we should do this.

Sam: who is willing to start a working group to address X.509, strong shared secret and username/password to meet the SOD requirements?
   Yes:many hands   No: no one

* Who's willing to work on X.509?   7 hands

EAP-TLS report - Bernard Aboba

Presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-0/sld1.htm

+ RFC 2716
  - original goal is to support EAP over PPP, took 24 months from beginning to end.
  - Made experimental: new at a time and few existing deployments
  - Security analysis provided by Arbaugh and Se, issues were addressed in RFC 3478 and RFC 4017.
  - WFA using EAP-TLS as part of interoperability testing since 2003.
  - FIPS 140-2 has EAP-TLS as only FIPS certifiable method.  Restriction on mechanisms.
Hannes: asks how many of the implementations EAP-TLS are deployed?  
Bernard: about 10%. Much higher among sites that deploy certs

+ Options:
  - Do nothing:  leaves some points unclear though no outstanding issues blocking development of interoperable implementations.  Though some issues per SOD requirements may be overlooked.
  - Standard approach: leverage wfa test program, remove features that have not been shown to interoperate between the already existing implementations.  Issue RFC2716 as a proposed standard.  Add features that would be "nice to have"

Sam: Speaking as individual would like to see if we can merge for instance the use of PSK in EAP-TLS for addressing the strong shared secret authentication.
Bernard: it may depend on how we deal with this especially with already deployed systems.
Sam: Can you abort and continue in EAP?
Bernard: No
Thomas Narten: Strongly encourage draft standard approach. Leverage community knowledge now before it fades. 
Joe: we should consider that there's something to be gained in tracking what happens in TLS as issues arise and are addressed within TLS and not have a divergence.  
Bernard: responds that clarifications could be made and included.
Joe: Beyond clarifications things may need to be fixed, PRF is an example.  best to avoid divergence. 

EAP-PSK , EAP-IKEv2 - Hannes Tschofening presentation http://www3.ietf.org/proceedings/05nov/slides/emu-15/sld1.htm

+ Contextual history: work stemmed from Jesse Walker/Russ Housley EAP-Archie work.
+ Based on a strong pre-shared secret, relies on strong shared secret and its simplicity allows it to not require fast reconnect,  fragmentation, is immune to DoS attacks.
+ Reviewed by Jesse Walker, answered comments waiting for response for a number of months. 
+ Implementation is available

+ Reuses IKEv2 authentication, key establishment and protection 
+ mechanisms Flexibility in supporting pre-shared and certificate based 
+ authentication Reviewed by Pasi Eronen

EAP-PAX Charles Clancy
Presentation http://www3.ietf.org/proceedings/05nov/slides/emu-11/sld1.htm

+ Pre-shared secret based authentication Provides ciphersuite 
+ extensibility, provisioning with a weak key or password, key management, identity protection/user anonymity and authenticated data exchange.
+ Charles completed full proof of security, publication pending.
* Provable security is based on random oracle model [bellare 93], provides the different bounds and limitations of the authentications and shared secret strength.
+ Reviewed by Jari Arkko

Charles: claims that this proposal addresses all 3 shared secret types.
Hannes and Sam: challenge claim as this method doesn't address how it handles the interface to password database Nico Williams: sees this as an enrollment to a stronger shared secret.

EAP-POTP - David Mitton
Presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-9/sld1.htm

+ Designed for one-time password tokens
+ Features offers strong user mutual authentication, fast reconnect, 
+ optional channel binding, key management (fresh keying), protected 
+ results

EAP-MAKE2 - Michaela Vanderveen
presentation - http://www3.ietf.org/proceedings/05nov/slides/emu-10/sld1.htm

+ Requests review
+ version 1 was defined in 2001.
+ Pre-shared key method: key derivation to satisfy 802.11i

Bernard: asks if its related to MAKEv1, different authors?  
Michaela: clarifies that it really doesn't have anything to do with EAP-MAKE the original version


goals of the bof
technical method requirements
ieee liason requests
method classes
questions for the bof
eap tls
eap psk and ikev2
eap pax
eap potp
eap make2