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