Subject: [Emu] Draft minutes for EMU meeting - IETF 66

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 20 Jul 2006 11:35:01 -0700

Here are the draft minutes for the EMU session,  let me know if you have
any corrections:

Minutes for EAP Method Update (EMU) at IETF 66
---------------------------------------------
Date: 7/12/2006
Time: 9 - 11:30 AM
Place: Montreal, QC 
Note takers: Nancy Cam-Winget, Madjid Nakhjiri

Summary
---------------------------------------------
The first topic of discussion was presented by Hannes Tschofenig on the
draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK
EAP Method.  There was consensus in the room to take this on as a
working group item to meet the PSK charter item with a modification to
the defined cipersuites (switch AES-CCM for AES-EAX).  The action is to
solicit comments on if this should be accepted as a working group item
on the EMU list. 

Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document.  The
presentation discussed some open issues of the draft.  Interoperability
problems with the TLS 3DES ciphersuites were discussed. It was noted
that some variants of EAP methods based on TLS method used the same
label strings in deriving the MSK from the TLS master secret. This is
thought to lead to some potential problems so it might be advisable to
use different label strings for this in the future.  Lastly, identity
privacy using TLS was discussed.  The draft needs to be updated and
listed as a working group draft on the charter page.

Next we had some presentations on EAP-TLS related methods.  Hannes
Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically
for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy
scheme for TLS.  The general feeling was this would be better evaluated
by the TLS group. Hao Zhou presented on some possible enhancements for
EAP-TLS.  More discussion on enhanced EAP-TLS is needed on the list. 

Dave Mitton presented on issues implementing new EAP methods.  One
problem was that some access points don't pass some EAP types they don't
know about.  The action is to assist the WIFI alliance develop tests for
this.   

Detailed Minutes
-----------------------------------------------

1. Generalized Pre-Shared Key Method (GPSK) - Hannes Tschofenig

Hannes Presented Slides

Discussion

- Key confirmation

Russ Housley:  wants to make sure that last message has confirmation on
last message that both parties have derived the same key

Hannes: Message 4 is optional and the encrypted part is also optional

Uri Blumenthal: questions need for explicit confirmation since Message 2
and Message 3 provides the information

Bernard Aboba: may be confused, in 2nd message should know what the enc
and MAC keys are used. The SEC_SK message is authenticated using a new
key?

Hannes: Confusion was around notation, the MAC's in the messages are
using the SK which is derived from the nonces and the PSK.

- identity protection

Bernard: asks on how identity protection may be achieved? 

Hannes: Out of scope one approach may be to use only the key identifier

Joe Salowey: temporary ID may be used, encrypted payload can deliver it.

- ciphersuites

Russ: asked why not choosing NIST approved modes? Consider changing it
to AES-CCM.

David McGrew: recommended use AES-CCM

Sam Hartman: questions why have a NULL?
Uri:  mentioned simplicity thus a reduction, mode was chosen to ensure
AES was used and most efficient thus why EAX was chosen.
Pasi Eronen: why can it not be replaced with CBC, other people gave
other options
Joe: mentions crypto selection should not be contentious

+ Needs discussion on the list and with the ADs. 

- key hierarchy

Hannes: Jouni has already made first cut an implementation of this
method. Only took 8 hours.
 
Joe: How many people have read the document?
Hands -- 4 - 5

Joe: Hum for "is this in the right direction?"
for: lots
against: none

Joe: Hum to accept as a working group item
for: lots
against: none

+ take it to the list

2. RFC 2716bis - Bernard Aboba

Bernard presents

- Key derivation

Bernard: Not a good idea to derive keys using the same label, though
this may not be as easy as it seems.

Sam: mentions that TLS community should make it easy to change labels
for key derivation

- Multiple layers of negotiation

Sam: does multiple layers of negotiation with EAP-TLS introduce a
vulnerability?
Bernard: 3748 with respect to protect against downgrade attack, you
could NACK it if it is something you don't want to do.

- Ciphersuite support

Bernard: mandatory to implement ciphersuites: 3DES/HMAC-SHA1 failed
interop tests. Some very popular EAP-TLS implementations with 3DES
failed to even complete. Possibly results from  some changes in openssl.

Russ: how about the old openssl?
Bernard: not tested
Bernard: does anybody has AES implementations we can use and test?

+ question the list about AES support

- Privacy

Bernard: what does it mean to be backward compatibility especially with
respect to privacy? Bernard's interpretation is that client requiring
privacy must fail with server w/no privacy but must connect if it's not
configured for privacy with a server with or without privacy. 

Russ: questions how documentation will clarify these transitions; wants
to make sure it's captured. 
Bernard: responds that all this will be captured in the i-d.

Vidya Narayanan: why its an issue with EAP-TLS vs. just TLS. 
Bernard: responds that it's heightened at least in this group. 

Hao Zhou: asks whether privacy updates will be mandatory or optional? 
Bernard: states it'll be made optional

Bernard: I will send out a survey for the implementations (so far 4
responses) and work with interop.

3. Enhanced TLS - various presentations
 
*EAP-TLS-PSK - Hannes Tschofenig presents on EAP-TLS-PSK

- privacy

Bernard: is it possible to support privacy in it.
Hannes: I have seen some papers on it that does it without too much work
Pasi: you could do within the first handshake, but it is probably a
hack..
Hannes: it was not initially a requirement, now it depends who you talk
to.

- method number and negotiation

Question: why is there a mapping of a specific EAP method to negotiate
this versus doing it inside EAP-TLS itself? 
Hannes: responds that they should be equivalent.

Sam: comments that options may cause problems when for example, if
preference is to do EAP-TLS with some cipher suites vs. EAP-AKA but that
fails then it may be better to do it through the EAP-TLS to choose a
different ciphersuite then you get into a situation you need to decide
which method you are committing before you start the method.  EAP does
not have a good way of saying this is the method I want to use or half
way through it thinks I have a problem with this and want to start
another one.
Hannes: Isn't this a problem with any general EAP method.
Hao: comments that EAP Identity response may include the realm shouldn't
that help? 
Hannes: no, unless credentials are shared. RFC 4284 is there to provide
identity selection hint from the server to help; 
Bernard: comments that while it may hint the network connecting to, but
it doesn't really relate to the EAP method so not sure how it helps.

John Vollbrecht: mentions that this is important work, but its not clear
how we can best proceed forward.

*EAP-TLS identity protection - Pascal Urien presents

Joe: it seems to be a change in TLS, what would the TLS WG think about
this?
Sam: post this to TLS as an extension to TLS, and if they are ok, bring
back
Pasi: as an individual this seems that it would the same end result as
adding a couple of roundtrips

*EAP-TLS enhancements - Hao Zhou Presents

Bernard: comments that this is more like the kitchen sink. Some of the
requirements seem viable, but putting them all under one identifier is
not good. 
Joe: agrees but questions that perhaps there is merit to considering
trying to put them as one base for several methods. 
Bernard: responds that having too many options may break
interoperability; mixing Kerberos, PSK seem to put things over the top. 
John: mentions that we should consider this, though its not clear that
we could put this into a single standard...but states that this would be
a very good thing and mentions that NEA group would need something like
this. 
Joe: mentions that NEA is out of scope for this group. 
Stefan Santesson: using protected TLS tunnel is a very useful thing.
Joe: comments that since TLS is evolving; 2716bis is only a subset and
since the presentations today of how to make use of the extensions, it
seems that this work is within the scope of this group. There could be
one base framework and potentially manifest itself in multiple methods,
but we must consider support for the requirements within the group.

Joe: Asks whether other people would be willing to edit on the TLS
enhancements? 
3.5 folks 
Joe: review? 6.5 folks

Password based mechanism discussion

Joe: What about weak password mechanisms? Are there other alternative to
methods like TTLS, PEAP or EAP-FAST?
Sam: mentions that tunneled methods is out of scope for our charter, but
addressing weak passwords may be within the scope of our charter.

Bernard: asks how we're going to deal with PSK, is GPSK it or
EAP-TLS-PSK should be considered? 
Joe: states that GPSK should be it. 
Sam: it seemed that there was no consensus to consider EAP-TLS-PSK, but
it has not been decided yet. 
Hannes: mentioned that there was enough interest to trigger the design
group to generate the GPSK method draft; also mentions the focus of the
preso is on passwords not PSK. 
Stefan: questions the limits of the enhancements, better to include all
of the TLS enhancements. 

Joe: agrees that the intent is to make the interface allow for
supporting the new TLS enhancements. 
Bernard: questions having multiple standards for PSK. 
Sam: mentions difference between group's adoption of using something
that may be widely adopted in our own GPSK versus defining or
constraining the ability to use all of the TLS options just because they
also support PSK.

+ Joe concludes: since there's enough interest, we should continue the
discussion in the list to see where it leads.

4.  Implementation experience - David Mitton

David presents

Bernard: we had an EAP bakeoff long time ago, maybe we need to have
another Bakeoff.
Russ: why would the vendors have to come to bakeoff if it is not a new
EAP method?
Sam: you can figure out characteristics of the problems people are
running into and design test case accordingly to have people come and
test it

?: In Korea some people have deliberately only allowed specific EAP
methods
Pasi: there is already procedure where all WiFi vendor come to
(alliance), so maybe you can include that right there.
Dorothy Stanley: that is a great idea, we can take that idea to WiFi
alliance. vendors do their best, nobody is perfect, also iEEE does not
do these kinds of tests, WiFi is the best places.
Bernard: I have a lot of weirdo problems that maybe RADIUS related not
EAP.
Joe: it is within our interest that methods that this group develops
will be tested.

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