Last Modified: 2005-06-27
Done | RFC 2284bis submitted for publication as a Proposed Standard | |
Done | RFC 3748 published | |
Done | EAP state machine document submitted for publication as an Informational RFC | |
Sep 04 | EAP Keying Framework document submitted for publication as an Informational RFC | |
Oct 04 | EAP Network Selection Problem Definition document submitted as an Informational RFC |
RFC | Status | Title |
---|---|---|
RFC3748 | Standard | Extensible Authentication Protocol (EAP) |
EAP WG Meeting at IETF #63 Location: Paris, France Date: August 2nd, 2005 Time: 14:00-16:20 Notes: Jouni korhonen and Dirk Kroeselberg (merging by Jari Arkko) 1. Preliminaries (5 min) -- Jari Arkko Agenda bashing Blue sheets and notes takers Arkko: Doing agenda bashing and presenting the issue tracker. No changes to the agenda. 2. Document Status (5 min) -- Jari Arkko
Goal: Discuss issues http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt Joe Salowey gives the presentation:
Jari: Are Russ' requirements binding? For EAP, there are pretty precise definitions of the requirements, what happens if there are conflicting requirements? Who gets to discuss the content of Russ' document? (Russ not present)Closed issues: 300, 305 Issue 306: to be handled in Yoshi's presentation afterwards. Issues discussed today (read the slides for the content):
Alper: there are a lot of systems than those 3 listed earlier Jari: Concentrate on known widely deployed cases.. however people are free to submit more analysis on other cases. Glen: widely deployed rules out PANA & IKEv2 etc Jari: that is debatable of course Someone: People willing to work on this is a good flow control..So if people are willing to work on some analysis then just do it. Action item: Hannes and Dirk will review Bernard's text and post comments to the list. ** 299 - key caching, keys internal to EAP methods may be cached fast re-auth etc)
Do we need to name the keys cached in the EAP layer? ** 302 - Domino effect clarifications
** 307 - deletion of the security requirements section
#307 may already remove the need for this. But need to make sure we cover these already.
Action item: Jari to ask Jesse Walker to check whether the new draft covers his requirements.** Next steps
4. Channel Bindings Goal: Discuss definitions, alternative schemes http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt http://www.ietf.org/internet-drafts/ draft-ohba-eap-aaakey-binding-01.txt and draft-arkko-eap-service-identity-auth-03.txt Yoshihiro Obha gives the presentation on lower layer parameter & channel bindings (read the slides for then content): Background for the discussion explained by Jari: Yoshi has a draft which suggests a channel binding mechanism which, if adopted, needs to go to the keying framework document so that the key calculation rules can be documented and standardized. Lets focus on the question if this is the way to go for the keying framework discussion or not. Ohba: Yoshi's draft is based on the list discussion on alternatives for this. The draft defines a key binding blob carrying lower layer information. The blob is sent by the authenticator to the server, and is an input to the key derivation. If the lower layer parameters of EAP peer and authenticator do not match, the lower-layer security cannot be successfully established (keys of supplicant and authenticator not matching). The solution impacts the AAA protocol (e.g. new Radius attribute), but its advantage is that it works for all EAP methods without requiring an extension to them. Main drawback is impact to deployed APs, and possible also to lower layers protocols such as 802.11. Pasi: Does not work with existing 802.11 access points. Yoshi: Yes, in this case AP can still use the legacy version, then EAP method support for channel binding would be required. Pasi: There are code changes? Obha: Yes. Joe: This should not be part of current keying framework, needs to many changes to existing stuff. John: Naming (channel binding) should be changed, since exact problem is not clear. Jari: Does not really belong into Housley document. Housley does not have much text HOW to implement these things. Joe: We need to clearer what problem we are trying to solve. The channel binding name might be slightly misnomer. Glen: EAP is so mixed up with AAA stuff, which causes lots of trouble. Probably belongs into the protocol, but it is not EAP. Pasi: Some documents call this \\u201cthe EAP system\\u201d, which is EAP plus other things. This is really the scope of the keying framework. Jari: Sounds like Yoshi's draft should not be part of keying framework. It may be worked on separately later, however. 5. Methods Discussion (40 min) Goal: Talk about the results of the reviews, make progress EAP PSK Review (10 min) -- J. Walker http://www3.ietf.org/proceedings/05aug/IDs/draft-bersani-eap-psk-08.txt Independent submission to IESG. Requested EAP method type number. Reviewed by Jesse Walker in June. Update integrating some review points in -08 version. Still number of open issues, e.g. for key derivation. Key naming is not planned, since there is no application like fast reconnect. Discussion will be continued on list.Hannes: On key control issue: it wouldn't add more complexity to include it here. Bersani: ok, moving on adding the key control Jari: The right process for this is to talk about the issues and gather more expert reviews on the list Hannes: I am one of the authors of PSK, Jesse actually criticized some things he originally proposed so we are a bit confused what he wants. EAP IKEv2 Review (10 min) -- P. Eronen http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-07.txt Pasi likes the approach, but document not considered ready. Inaccurate comparison to EAP-TLS mostly fixed in -07 version. Major issues e.g. with current fragmentation mechanism (since EAP is lock-step), fast reconnect does not clarify how the server picks the correct key, channel binding. Needs more work, but no major obstacles found.Dirk: Channel binding was not updated since authors had to wait for the outcome of Yoshi's proposal on channel binding. Hannes: Thanks to Pasi for the review. One additional issue on channel binding.. Could we come up with our own solution or reference to something (and if so to what?) Pasi: There are 2 ways how to do channel bindings (Obha and Pasi & Jari) no selection which one has been made Jari: I think we can do a decision on channel binding in the list after the meeting, which one of the two to select. We will send a question to the mailing list how to proceed with channel bindings. EAP Smartcard Type Review (5 min) -- G. Zorn http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-02.txt There are already a number of EAP methods on token or smartcard types. Expert review has been performed by Glen Zorn. Answers to the review comments: see presentation slides. Pascal disagrees with review comments in a few points, e.g. on the IANA requirements compliance. Some discussion about security claims. Glenn: Either take out security claims altogether, but then it must be clear that the method itself has no security properties.Jari: Running out of time, discuss this in the mailing list EAP Double TLS Review (5 min) -- H. Tschofenig http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-03.txt Found some confusing text about "inner" method. Many optional parts make analysis quite difficult. Some issues, e.g. key strength and hierarchy not properly documented. Crypto-binding still needs investigation.Jari: More discussion on the mailing list. EAP PAX Update (5 min) -- T. Clancy http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-04.txt
Jari thanks the reviewers. Hopefully we will be able to work on few methods to get them into standards track, either here or in SECMECH. Please inform the list and the IESG on what needs to happen on this front.6. Trusted Computing Group EAP Issues (20 min) -- John V. See the slides for the main content. Note: Different naming for lower layer nodes and functions in TNC than in IETF. General idea is to check client state before allowing network access (quarantined). For EAP, TNC is considering a new EAP method (protected method, inner method carried by outer method). This method could map to IF-TNCCS (see slides). The presentation is meant to seek feedback from the IETF EAP community, maybe create a formal liaison later on. Possible work could be a protected method, a generic "outer method", or inner method keying requirements in the keying framework. Jari: If you want more feedback on this.. Do you have anything else than these slides?? John: We have some but not all are publicly available. A participation to the consortium is generally required. May need a formal liaison, since TCG is a closed group. If such a method will be specified in IETF, this needs to be worked out. Jari: That has worked out earlier.. e.g. a certain consortium allows access to relevant documents for a certain WG. John: No standard "outer" method for protected EAP methods still exists. And is it possible to add "inner" capabilities to existing or planned methods?? Pasi: Sounds interesting and worth doing. Maybe without the help of EAP group. And we need those documents. Hannes: Also likes the idea.. Security Ads won't like this however.. Many of these things have already been discussed. But don't start with one specific tunnel method. The tunneled method might be inefficient as everything can be run inside the tunnel Jari: Tunnel methods can sometimes be used to avoid the IANA registration rules :) Glen: EAP specs currently do not define sequencing details, I thought that was clearly outlawed! Alper: Why? Glen: It was not allowed to run a sequence of EAP authentications. Alper: The latest 802.16e supports sequencing. Glenn: But this is not supported by the EAP spec Alper: These are two independent EAP sessions. However, discussion in IEEE is already closed. Jari: Volunteers to review for TCG..? Contact Jari. 7. EAP Enrollment (5 min) -- Rohan Mahy http://www.ietf.org/internet-drafts/draft-mahy-eap-enrollment-00.txt Motivation is that small wireless devices (e.g. phones) are a pain to enrol onto WLANs. Basic proposal is to start with some weak credentials and then let the client fetch stronger credentials after that. Use existing methods. Presentation just seeks thoughts on this. Hannes: Very good thoughts and has also been thought here in this and other WGs earlier. Why we never managed to move this forward earlier? Alper: It goes back EAP applicability statement. Hannes: a number of methods provide the capability to exchange config parameters. Want to see some guidance on how to move things forward.8. Meeting concluded 16:20 |