Here are draft minutes from the EMU minutes. Thanks to Donald and Hao
for taking excellent notes.
EAP Method Update (EMU) working Group
--------------------------------------
IETF 67
11/06/2006
13:00
--------------------------------------
Chair: Joe Salowey
Note Takers: Donald Eastlake
Hao Zhou
--------------------------------------
Agenda
1. Administrative
2. RFC2716bis (EAP-TLS)
3. EAP-GPSK
4. Password based
5. Enhanced-TLS
---------------------------------------
Administrative
- Current Drafts
EAP-TLS
draft-simon-emu-rfc-2716bis-04.txt
close to last call
EAP-GPSK
Draft-ietf-emu-eap-gpsk-00.txt
close to WGLC, but needs some more revision
----------------------------------------
RFC2716bis (EAP-TLS)
Presenter: Bernard Aboba
Draft: draft-simon-emu-rfc-2716bis-04.txt
Changes from RFC 2716, two draft revisions since last IETF
- Open Issues
What if EKU (extended key usage) is present or ANY?
What if more than one altSubjectName?
Is result dependent on the order of altSubjectName fields?
Russ: Your description is accurate, any of EKU will work. If you want
to assign one, we can assign one.
Bernard: I would like to have a reference to point to
Joe: I would like to avoid mandating a particular EKU
Bernard: The question is how to address that so existing implementation
is compatible.
- EAP-TLS certificate profile different from TLS certificate profile?
RFC 4334 seems to assume yes.
But implementations typically just rely on TLS for cert
handling.
Dave Johnston: are we going to specify an EAP-TLS profile? The
IEEE802.16 standards assume it exists and refers to it.
Bernard Aboba: No. Maybe we need to specifically say there isn't such a
thing. Other people shouldn't be changing EAP-TLS by requiring OIDs,
etc., that will break existing implementation.
Joe: How is that?
Bernard: 802 has forked 3 version incompatible with existing
implementation. Existing implementation don't look for any EKU Oids.
Bernard: There is no such thing of EAP-TLS profile, if you create a new
profile,
Joe: Existing implementations already has issue with dealing with CN and
SAN.
Bernard: At least they can look at RFC3280. Question is where do we go
from here. Look at 3280 to specify what people are doing today.
Russ: Two aspects: application needs to make authorization decision on
top of TLS, SIP RFC3269 is an example on how to deal with two SANs.
Bernard: Will look into it to modify.
Chair: target for working group last call at the end of November
beginning of December
--------------------------------------------
EAP-GPSK
Presenter: Charles Clancy
Draft: Draft-ietf-emu-eap-gpsk-00.txt (-01 submitted, should be on site
soon)
Issue tracker: www.tschofenig.com:8080/eap-gpsk/
- Issues believed closed:
#4 delimiters in KDF (Key Derivation Function), swapped two
items for more self delimiting
Russ Housley: Doesn't conform to NIST 800-56A and should.
Hannes: What do we need to do?
Tim Polk: 800-56A is key establishment algorithms. This document has
requirements for KDFs. Specifies two functions with some mandatory and
optional fields. One is ASN.1 and one is byte string.
Sam Hartman: Is 800-56A a key hierarchy or for turning stuff into a
symmetric key?
Tim Polk: Not for hierarchy where you derive one key from another. We
are working on that but document is just an internal draft right now.
#3 KDF data, way to include arbitrary data has been taken out.
#5 cipher suites, AES-EAX-128 changed to AES-CBC-128.
#2 channel binding, has been removed but could be added back.
Minor KDF inconsistency. Now allows arbitrary length input but one case
where it says truncate is still there.
Need to take out truncation.
- Issues still open:
#5 error handling: what to do if there is a MAC error? Return en
error or just drop the packet? How long till user finds out about the
error?
Bernard Aboba: There is now an error message you can send back that
doesn't change state.
Lakshminath: maybe it's not DOS, but guessing the key
Charles: with strong key, we shouldn't worry about
Glen: It would be good to get some result back, knowing the reason.
Bernard: Radius client will try to retransmit, if message is discarded.
Vidya: not just a radius problem, EAP problem as well. User experience
an issue
Hannes: what do other EAP method uses
Bernard: EAP-TLS uses TLS-alert
Lakshminath: ok with EAP-failure as long as we put some user guidance on
how to deal with it
Vidya: Is EAP or radius failure?
Joe: They are linked, EAP-failure implies RADIUS reject
Bernard: RFC 3589 describe retry within the method
Charles: PSK is a strong key, we don't have to worry about offline and
online dictionary attack.
#1 Protected Results Indication
Define PRI within document, rather than as something that could
be added later.
Hannes: different than the first issue
Hao: Agree with Hannes, two different issues. This is to protect the
clear text result. may include additional errors with result indication.
Glen: Not useful in failure case, especially in the case of mismatch
key. Might be useful in authorization failure, indicating failed reason
Target: Working group last call before next IETF
---------------------------------------------
Password Based Mechanism
Presenter: Charles Clancy
Draft: none, design team forming
- Goals
Simplicity, Wide Applicability, Efficiency, Flexibility,
Extensibility
- 1st approach, client ->password-> EAP-server ->password->pwdatabase
- 2nd approach, send hash of pw back from database, more limited, not
what is in charter.
Sam: charter in scope is to support #1(sending clear text over), wider
clear text password support.
- Problem is dictionary attacks:
on-line protected by locking account after invalid attempts.
Protection again off-line dictionary attack requires some sort
of public key crypto.
EKE style approach - IPR covered, expiring soon
tunneling approach
- Choices:
write our own PKI-based protocol,
use tunneling method
write inner method or with an existing inner method.
Russ Housley: Starting from scratch is hard. Frequently one party has a
certificate and the other does not. Could make use CMS building blocks.
Glenn Zorn: I thought there was an EAP method that just sent the
password under raw RSA using the servers public key.
---------------------------------------------
Enhanced TLS Based Mechanism
Presenter: Chair
Draft: none
- New Type Code (and Name)
Perhaps one for each cipher suite class.
- Channel Binding
- Protected Results Indication
Bernard Aboba: Didn't mean to suggest a new type code for each cipher
suite class.
Sam Hartman: Don't want to commit to an EAP type code until you know you
can succeed. If later we allow multiple layers of negotiation, this
becomes much more complex. For example, you might want to ack or nack
EAP-TLS EAP method depending on what cipher suite it is going to be
offered in later stages.
Various: Long discussion of multi-level of EAP methods, authentication
methods, cipher suites a la TLS, ...
Sam: Can EAP send data with the first packet?
Room: yes
Sam: Then why are we having this discussion?
Question: are there any asymmetric methods, that is with radically
different credential on the two sides?
Pasi: Only one with pre-shared key on one side and certificate on the
other side.
Hao: Looking at the password-based requirements and enhanced-TLS
requirements, a lot of them are similar. I wonder if we can come up with
a single method, especially we are using a tunneling method.
--------------------------------------------
Additional
Rohan: Time for Enrollment to be considered?
ADs (Sam and Russ): Not until we complete more of our goals and
recharter!
Rohan: I'll be back with this question at the next IETF
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
