2.6.7 Extensible Authentication Protocol (eap) bof

Current Meeting Report

Minutes of Extensible Authentication Protocol BOF
43rd IETF, Friday, 11 Dec 98
09:00 EST
Orlando, FL
Recorded by Bernard Aboba, Microsoft

Chair: Glen Zorn, Microsoft

A number of conclusions were reached:

1. To date, the proliferation of authentication frameworks and APIs is a significant problem within the IETF. The strategy of "letting the marketplace decide" does not work here because having N frameworks dramatically increases the work that developers need to do in order to make a new authentication method widely available, decreasing the economic incentive to develop such methods, and diluting the value of existing standards. Saying "we should only do public key authentication" is not a valid approach because this ignores millions of users now using password authentication and token cards, as well as ignoring the interest in other techniques such as biometrics.

2. The profileration problem has arisen because of lack of coordination among IETF Working Groups, and could have been prevented by earlier IESG intervention. Rather than continuing to spawn new frameworks, we need to address the issues in the existing ones that have caused new ones to pop up.

3. The IETF needs to work on rationalizing the existing authentication frameworks, including GSS_API, EAP, and SASL. A concensus was reached on a general architecture by which this rationalization could be achieved, and a draft will be written summarizing the approach, which requires additional work on GSS_API, to permit initial authentication, as well as introduction of an EAP-Type for GSS_API.

4. The IESG should consider a moratorium on introduction of new authentication frameworks, such as XAUTH, since current frameworks cover the requirements very well, and introduction of additional frameworks will merely dilute the value of the existing ones. During discussion, it was agreed that instead of XAUTH, the IPSEC Working Group should focus on enabling extended GSS_API authentication within IKE.

5. The focus of EAP is to provided extended authentication in situations where IP is not available. SASL cannot substitute for EAP since it does not provide transport services, as EAP does. It was noted that while EAP methods can provide extended security services, including public key authentication, integrity and replay protection, these services are not provided by EAP itself.

6. Within the overall architecture, it is best to think of both SASL and EAP as protocols for encapsulation of authentication methods provided by GSS_API. Thus rather than adding new methods to SASL, it is best for new authentication methods to be added to GSS_API, where they can become available within EAP as well as SASL. This will provide the most efficient use of resources.


None received.