2.6.18 Security Mechanisms (secmech)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27

Chair(s):

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:
Archive:

Description of Working Group:

No description available

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Secmech BOF

IETF 63, Paris
Tuesday August 2nd, 10:30 - 12:30
Chair: Joseph Salowey
Notes taken by Hank Mauldin and Nancy Cam-Winget, edited by Joseph Salowey

Mailing-List: secmech@ietf.org

1. EAP Method Requirements (Jari Arkko)

(Presentation - Jari Arkko - ietf63_secmech_eapmeths-jari.ppt)
There are many existing EAP methods. The list is some 40+ methods long and includes many undocumented and proprietary methods. Some methods are documented in RFCs or are in the RFC editor queue. It has taken a long time (4 years) for methods to get from 00 version to editor queue. Methods listed in the original EAP RFC are no longer applicable in wireless environments.
- Technical requirements for eap methods include

o must not break EAP (RFC 3748)

o documentation of security properties (mechanism, key hierarchy, security claims, vulnerabilities)

o Address wireless LAN requirements (RFC 4017)

o Documentation required to indicate which security claims from the list defined in the EAP RFC are met

o EAP process for new methods requires expert review of method to make sure it does not break EAP and appropriate documentation is provided.


- Need for new EAP methods

EAP usage and network access authentication usage is increasing. Currently we have too many undocumented methods and no standard method that can be made mandatory to implement. There are requirements from external standards bodies such as IEEE and 3GPP. One useful item is to update EAP-TLS (RFC 2617) to bring it to standards track. Another useful mechanism method class is a pre-shared key mechanism such as EAP-PAX, EAP-PSK, or EAP-IKEv2. There is interest in password based mechanisms, although that may be intractable. Methods should generate keys and support channel bindings

- Conclusion

It may be too late, but there is industry interest in method standardization. Network access authentication is increasing so action is needed now. Flood gates should not be completely opened, work should be done on a limited number of mechanisms.

- Questions and Comments

(John Vollbrecht): How does review take place? Who are the reviewers?
(Jari): EAP working group has done 10 expert reviews.
(John Vollbrecht): Does the security of the mechanism needs review?
(Jari) Definitely. The EAP review verifies conformance with 3748 and claims are appropriately documented. It does not necessarily decide if the method is a good idea or attempt to verify security claims. Security review is needed in addition.

(from Jabber): Is there an EAP directorate for reviews?
(Jari): No

(from Jabber): What does it mean that the IETF has refused to address this?
(Jari): IETF has resisted doing this. Initially a working group was refused from a BOF in the 90's, but then one was created just to work on basic EAP specifications and not for methods.

(Uri Blumenthal): I agree with presentation. A group should be chartered to work on a small number of methods, preferably 1. Channel bindings should be included in mechanism requirements. If channel bindings are not included in a method then it should not be considered for selection since cryptographically it is broken. Avoid excessive tunneling.
(Jari): tend to agree, though there are several usage scenarios so it may not be possible to adopt just a single method need to accommodate things like certificates and SIM cards
(Uri): It should be possible to accommodate modes for legacy uses

(David Perkins): I think this BOF happened because of ISMS.
(Sam Hartman): No it did not.
(David Perkins): There's a gap between technology, usability and application, so outcome of whatever happens should be that people can actually deploy what is defined in this group.

2. Generally usable authentication mechanism (Joe Salowey)

(Presentation - Joe Salowey - ietf63-secmech-guam1-joe.pdf)

The idea of defining security mechanism so that they can be used in more than one framework is not new, it has bee promoted by Sam Hartman and others. There have been individual attempts at doing this for individual methods in the past. The mechanism frameworks of SASL GSS-API and EAP are similar; they focus on authentication and context establishment. There are differences but they are very few. Convergence is happening slowly. Examples are GSS-API PRF and channel bindings in EAP. This leads to slow rate of standardization and duplication of effort. More significantly we have inconsistent support for security infrastructure. For example GSS-API primarily supports Kerberos and has poor support for shared secret and certificates. EAP primarily shared secrets in AAA but no Kerberos. Customers build and manage a credential infrastructure, but can not use it for all applications. Frameworks also have different areas of applicability; SASL for applications and EAP for network access.

The proposed solution is to develop mechanisms that are useful in any framework. (GUAM - draft-salowey-guam-00.txt). We don’t want frameworks to change so applications stay the same, frameworks could be optionally enhanced. Any mechanism that is generally useful would be a candidate.

(Eric Rescrola): so Kerberos supports everything one wants in TLS, but has poor integration. What could be done differently?
(Joe): Support for Kerberos is out of date for TLS (Nico Williams): The Kerberos cipher suites were bad. It would be nice if TLS could support GSS, would be nice to look into.
(Sam): There is a wide scope which includes TLS. But right now we should focus on EAP, SASL and GSS
(Joe): agree

(Glen Zorn): Applicability statements of the frameworks seem to be a layer 8 problem.
(Joe): Since the frameworks are similar it can be hard to understand applicability.
(Glen): It’s not clear that the authentication mechanism is the issue, some frameworks might not fit well with some protocols.

(Pasi Eronen): In your draft you say frameworks are similar, but there is a difference when it comes to EAP. EAP the context is not set up between the two parties which are communicating which is different than GSS-API which sets up a context between the communicating parties. The main difference is that in GSS-API you name the services you are communicating with and in EAP you do not, so in EAP you don't know who you are talking to.
(Joe): EAP is establishing a context between two parties. This context is then used external to EAP to establish additional contexts. Lets focus on what happens in EAP.
(Pasi): You can't consider EAP by itself.
(Sam): seen why applicability statements are necessary, not just a layer 8 issue. EAP usage has expanded from PPP to wireless. You can abstract out the capabilities of GSS and EAP mechanisms, but you cannot abstract out security analysis of the system.

(Jari): It not just about credentials types but being able to use deployed infrastructure as well. Is this in scope?
(Joe): yes
(Glen): disagree with area director and Pasi. It is necessary to abstract EAP from its transport. Much misunderstanding of EAP comes from a lack of analysis. System components need to be analyzed. Trying to analyze the whole thing as a unit only leads to disaster and confusion.
(Uri): In the beginning authentication was unidirectional. Capability has been added for key generation etc. The analysis is now a mess so it is difficult. People reuse EAP because it is there. Security is a collateral consideration.

(Unknown): good to unify proposals and unify requirements in one protocol. Will optimizations be difficult in the general case?

(John): Good idea to talk about how to figure out how these all are similar, EAP is one piece. Agrees with Glenn about analysis.

(Glen): This discussion about EAP is about layering. Putting them all together makes it impossible to analyze an EAP based authentication system.

(Joe presentation)
There are a small set of requirements that would need to be supported by a mechanism. (List in presentation). Most difficult may be dealing with naming.

Next steps - create WG

(Glen): seems like it would be useful to define authentication methods to be able to use in all frameworks. Why need a WG or RFC rather than an OReilly book?

3. GUAM continued (Nico Williams)

(Presentation - Nico Williams - ietf63-secmech-guam2-nico.pdf)
This group is to define and unify the frameworks and mechanisms that are currently disjoint sets and there is limited support for mechanisms.

Terminology - framework, mechanism, framework-specific mechanism, framework bindings of a mechanism, framework bridging

GUAM focuses on framework-bindings of a mechanism and framework bridging

Concrete Proposals:

GSS-API DTLS bindings
GSS-API plain/AAA (stackable mechanisms) to replace LIPKEY TLS v1.x to support multi-round-trip mechs and have it support GSS-API ciphersuites EAP-IAKERB

It might be a good idea to change some of the frameworks.

(Pasi): There is an internet draft that adds multiple round trips to TLS. TLS inner application extension.

(Nico Presentation)
One approach is to create bridging between mechanisms, but this may add round trips. Or you can specify mechanisms definitions for both.

(Glen): GSS-API has embarrassingly few mechanisms and EAP has embarrassingly many. I think this is an indication of sales. No-one uses GSSAPI.
(Nico): A lot of protocols use GSS-API. Many people are happy with Kerberos, others are not.
(Sam): the numbers tell me that SASL has the most success in getting people to use it. EAP most success in getting people to write mechanisms for it. This is not good and why we are having this BOF. What do you mean by bridge? One document that defines both?
(Nico): No that would be framework binding. bridging is a SASL <-> GSS thing

(Nico Presentation)
I'd like to see a revival of an EAP-GSS bridge. All new EAP mechanisms should not preclude use in GSS-API. EAP can be modeled as GSS-API interaction. Kitten work will help make this easier.

Perhaps there should be BCPs for mechanism definition. Then the work can be done in various groups, EAP, Kitten, TLS, ...

(Glen): I remember my question. IAKERB does not provide tickets to the host.
(Nico): That would be design error that could be fixed.
(Love Hörnquist Åstrand): IAKERB did provide with tickets

(Jari): Organizational aspects less interesting than what. There is limited time to make this happen. Lets not delay.

4. Next steps

(Joe): One work item is a fast track towards standardizing EAP methods
(Jari): Have you selected a way to do this GUAM?
(Joe): Not yet
(Sam): A BCP can be created for guidelines on what is applicable for various frameworks

(Nico): I agree with the charter and BCPs or guidelines would be great.
(Joe): coordination from multiple groups is required

BOF Questions:

How many people think standardization of a small number of fast track mechanisms is a good thing?
(loud Hummmm)

How many people think it isn't?
(soft Hummmmm)

(Glen): Who should do the standardizing? I think its a good idea, I don't think it is a good idea to do it here.
(Jari): Do people care where this happens as long as we get the right people?

Who believes we should standardize in security area?
(medium hummm)

Who believes it should happen outside security area?
(soft hummm)

Who doesn't care where?
(medium humm)

(Russ) I am concerned about the notion of fast track standards in the EAP space. Standards track mechanisms that don't meet the needs of the community doesn't help.
(Joe) Fast- track refers to standardizing EAP methods in parallel to GUAM work instead of waiting for GUAM work to complete. We would want to collect the requirements development methods from the requirements.
(Russ) I misunderstood

(Uri) None of the existing mechanisms completely fit. Shouldn't be too hard to modify an existing proposal to work. We have the technology. Collect requirements and then create a method.

(Jari) It is difficult to answer questions on GUAM without knowing more.

Humm if you don't have enough information about GUAM?
(medium humm)

Should the GUAM guidelines work should be done in the IETF?
(medium hum)

GUAM work should not be done in the IETF (little or no hum)

Raise your hand if you are willing to author about 3 Raise you hand if you are willing to review about 10

Any objections to fast track EAP methods and GUAM work?

(Unknown): Is this a standardization process? What does fast track mean?
(Sam): fast track means just before GUAM work Charter wording needs to be revised.

(Glen): My concern is that moving this into the security area will slow or stop progress.

(Joe) an option could be to add this work to the EAP charter

(Sam): Consensus of the group is that standardizing an EAP method before GUAM guidelines and doing it under the IETF area is acceptable.
There are some individuals willing to author a draft and more to review it.
Lack of consensus on the focus of the GUAM guidelines indicated that the group should first focus on the standardizing of the EAP mechanisms.

(Pekka Nikander) Why should they be done in the same area working group?
(Sam) My personal opinion is that the GUAM work will be more successful if the GUAM people are exposed to method standardization process.

(Jeff Altman) In general I support the notion behind GUAM. Concerned about spreading resources too thin across kitten and EAP groups.

(Sam) Next step is to track down people to volunteer, especially as authors.

(Joe) That is an action item for me and several others.









Slides

EAP Methods
SECMECH and GUAM
GUAM