Subject: [SECMECH] Summary of IETF63 secmech BOF

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 4 Aug 2005 00:33:15 -0700

The secmech BOF met on Tuesday morning.  We had discussion on the
standardization of EAP methods and on unifying GSS-API, SASL and EAP
mechanism development.  

We had a discussion on the status and history of EAP method development,
which has largely happened outside the IETF. This may lead to a
situation where network access interfaces are less open and
interoperable than perhaps desired. A concern was also raised that if
standards work is started in this space, it may not be good to gate this
on EAP, GSS-API, and SASL mechanism development unification.  A small
set (1-3) of EAP mechanism types should be selected for standardization
based on requirements from IETF and external SDO's.

The discussion of EAP, SASL, and GSS-API mechanism development
unification. There was discussion on several approaches to unifying
mechanism development.  There was some discussion on how closely EAP
needs to be tied in with AAA requirements.  There was discussion of
bridging vs. alternate approaches to mechanism development.  There was
no clear preference so more discussion on the list is necessary.  

The basic results of the BOF were as follows:

1. There was rough consensus that EAP method standardization is
important 2. Most people didn't care where the work was done, but there
was a preference for doing the work in the security area.
3. There was rough consensus that unifying authentication mechanism
development would be good.
4. The current proposals for mechanism development unification need to
be more concrete.
5. There was light interest in actually authoring and review drafts in
the unifying authentication mechanism area. 

Next Steps / Action Items
--------------------------
1. Collect the requirements we have for EAP methods and select a (1 - 3)
types of mechanisms to support.
2. Better define the GUAM proposal and see if there is more interest in
a more focused proposal. 
3. Submit a charter for a working group if enough document authors and
reviewers can be found in the respective areas.  

_______________________________________________
SECMECH mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/secmech

---

From: Charles Clancy <[email-masked]>
Date: Thu, 4 Aug 2005 04:35:19 -0400 (EDT)

> Next Steps / Action Items

I'd suggest the so-called "Housley Criteria", as documented by section 6.2 
of draft-ietf-eap-keying, and expanded on in section 4 of 
draft-housley-aaa-key-mgmt as a good set of technical requirements. 
These are a superset of the WLAN EAP requirements (RFC 4017).  These 
include:

* Extensible ciphersuite
* Establish strong, fresh session keys
* Maintain algorithm independence
* Include replay detection mechanism
* Authenticate all parties
* Maintain confidentiality of authenticator
* No plaintext passwords
* Perform client and NAS authorization
* Maintain confidentiality of session keys
* Confirm selection of "best" ciphersuite
* Uniquely name session keys
* Compromise of a single NAS cannot compromise any other part of the
   system, including session keys and long-term keys
* Bind key to appropriate context

As for methods to select, I proposed EAP-PAX (draft-clancy-eap-pax) and 
EAP-TLS (RFC 2716).  EAP-PAX is a non-tunneled, shared-key method 
supporting key management, provisioning, and identity protection.  It 
satisfies all the aforementioned requirements.  EAP-TLS would require some 
minor updates to meet the requirements, but would make a solid public-key 
standards-track method.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]