| Re: eap wg minutes from ietf-58 | <– Date –> <– Thread –> |
From: John Vollbrecht (jrv umich.edu)
|
|
| Date: Thu, 20 Nov 2003 15:46:52 -0600 (CST) | |
Thanks very much for the good notes. I have cut and pasted some comments
below.
--On Tuesday, November 18, 2003 5:34 PM +0200 Jari Arkko <jari.arkko [at] piuha.net> wrote:
.
I think the identity response should be worked on by the group for the long term, but not as part of 2284bis.
I also would suggest that the document might be helped with a framework that shows as outside the EAP/RADIUS framework, but that EAP/RADIUS is one place that it can be used.
I think a diagram in a PDF document would be very helpful in this case, along with a text document, like the State Machine doc.
Is the "normal" authentication in IKEv2 (not EAP) without Intellectual Property hindrances?
--On Tuesday, November 18, 2003 5:34 PM +0200 Jari Arkko <jari.arkko [at] piuha.net> wrote:
Preliminary Minutes of the Extensible Authentication Protocol (eap) WG at IETF-58
Time: Monday, November 10, 2003 at 1930-2200
Chairs: Bernard Aboba <aboba [at] internaut.com> Jari Arkko <Jari.Arkko [at] ericsson.com>
Minutes: Dirk Kroeselberg (Dirk.kroeselberg [at] web.de) Henrik Levkowetz (henrik [at] levkowetz.com) Edited by Jari Arkko (jarkko [at] piuha.net)
URLs: Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip
. .
When will the group decide whether to work on methods? Seems like this is very close.o Method documents: Approval of methods needs to wait for completion of base EAP specifications. Currently not in EAP WG charter to work on methods. Future methods might be specified either as individual submissions, Informational documents outside the WG or as chartered EAP WG work
.WG Work Items -- RFC 2284bis, Henrik Levkowetz ==============================================
- http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rf c2284bis-07.d.html
- 3rd last call on the document was held in September. There are two open issues left:
1) Handling of Identity response 2) Editorial comments by J. Puthenkulam
.
I think the identity response should be worked on by the group for the long term, but not as part of 2284bis.
As I noted in response to Pasi, I think this should stay in as well. I think it says that tunnelled and non-tunnelled EAP and EAP methods have the same structure, except that tunnelled methods are allowed to do sequences of methods.WG Work Items -- EAP State Machine, Pasi Eronen ===============================================
- http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt
- Now in WG last call. Next steps: Handle issues from last call, and publish as informational.
- Draft describes state machine for EAP peer and EAP authenticator. No changes on peer side since IETF-57.
- The approach for the authenticator now is changed, due to comments on AAA interaction: three state machines:
o Standalone (no pass-through or AAA)
o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP methods).
o Full authenticator (Interfaces to lower layer (matching 802.1X-REV), EAP methods, AAA module)
- Discussion:
o Bernard: What is the difference for handling tunneled methods (tunneled variable)? Pasi Eronen: If you are not inside the tunnel, you are not allowed to do multiple authentication methods. Complicated, tunneled-variable will be taken out. Joe: Makes me somewhat nervous to have that in there. Bernard: For now, should be in there to stimulate discussion.
I think this is good work, and is making progress. I am confused about why it is not needed for methods, especially methods that generate, and possibly keep keys. I would like to see at least one required to implement method that generates and keeps keys for anyone who implements such capabilities. I don't care much which method is required, but I think that TLS could be one since it is widely implemented, or I personally think requiring an Archie method, or an IKEv2 method would be good. I think such a requirement should go at least with implementing the Key Framework RFC.o I'd also like to say that the quality is very good, and thank the authors, and tell people to set aside 4+4 hours and go and read it.
WG Work Items -- EAP Key Framework, Bernard Aboba =================================================
- http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt
- Normative statements relating to EAP moved to RFC2284bis. As a result, EAP methods no longer depend on keying framework. Substantial revisions are in progress, currently the draft lacks a threat model.
- Open issues:
o 15 (key distr. Insecure), o 179 (EAP PRF), and o 187 (Service SAs).
- Security issues are:
o Key scoping: AAA protocols authenticate at NAS granularity Client may not be able to recognize NAS scope without assistance from the lower layer. Possible solutions:
. AAA agent checks . Logging . Key Mixing . Method-specific binding
o Correctness in fast handoff & context transfer
o Lying NAS Problem
- There were no questions.
I also would suggest that the document might be helped with a framework that shows as outside the EAP/RADIUS framework, but that EAP/RADIUS is one place that it can be used.
I think a question is who interprets the identity and how is it used. Do we expect the identiy response to be kept whole for the method but brokenup by the NAS for routing? This seems a big question, which I think should not be included in 2284bis, but possibly considered by the working group.
Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi Eronen ========================================================================= ===
- http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-a nd-selection-00.txt
- Discussion scoping by Jari: there's been previous question marks on whether this functionality is needed. Since feedback is required from other organizations, and we don't have much time for discussion in the meeting, we will assume that network selection is needed. Lets use the meeting time to discuss what alternatives we have for providing this feature.
- Problem: Even if you select an AP (based on e.g. SSID) you haven't selected a mediating network which will carry your traffic back to your home network
- Farid presented examples of mediating networks, such as iPass, 3GPP-VPLMN, GRIC. Home service network is e.g. wireless provider. Access networks are public hotspot. Problem is not AP selection in hotspot. EAP-based client needs information on which home network /mediating networks are affiliated to the access network. The proposed solution complies with the EAP spec and uses EAP-Identity Requests to deliver network information.
- Proposed solution is to use a "decorated NAI" inside the Identity Response, on first or subsequent Identity Request. Identity Request may carry information about the network which makes it possible for the peer to select an appropriate NAI (if more than one is available).
- There is a 3GPP dependency for this work (3GPP TSG CN).
- Related presentation by Pasi Eronen: Based on a discussion between Jari, Bernard, Pasi.
o But other solutions are possible, e.g. SSID-based.
o Suffix routing on a NAI is better than prefix routing.
o If an eap-layer based solution is used, EAP identity request hints are probably OK.
o The network cannot always ( and maybe should not ) do the selection. So information has to be provided to the users.
o If you try to encode the mediary network information into virtual AP's ssid's, the amount of beacons needed might end up consuming a significant part of the bandwidth.
o On the other hand, if you have to associate with each of a large number of APs, and start a EAP exchange with each in order to get the information about
- Discussion:
Margaret Wasserman: Are there lessons to learn from loose source routing? Can we become victims of single points of failure?
Pete: Seems we are limiting us to a solution which doesn't scale very well. And I'm not sure we should be doing this at all.
Bernard: Today we have internet connectivity and DNS-based routing. This was not possible with RADIUS. Why are we doing this? It looks like there is no layer-2 alternative that can handle all cases.
Margaret: Assume I can choose based on some string between mediating networks. Does not seem to be right as there should be some policy. Do we gain something over the existing solutions today?
Farid: These policies can be pushed to the subsciber device from the home network
Farooq: It's the home network which has to settle the roaming cost.
Farid: Some users may care about QoS, some about cost. Policy can be pushed by the user's home network. Margaret: There are other WGs that investigated the concept, should be looked at as well. Bernard Aboba: Take it to the list.
Jari: We have a cost factor in selecting the right network. End users care about the cost.
- Strawpoll:
Should this be solved in the IETF? Consensus that the problem is worth solving.
Should the EAP WG solve the problem? Consensus that it should be solved in WG, but less strong than for the first question.
- Comment by Pasi: There are solutions that do not involve EAP at all. But EAP WG could be a good place to explore this.
Can someone describe the different directions?
Related Work -- EAP Key Derivation for Multiple Applications, Joe Salowey =========================================================================
- http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt
- Changed the draft name to "EMSK usage guidelines"
- 2284bis defines the EMSK. Several applications have been suggested that use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv) The current proposal should either be incorporated into key framework draft, or the keying framework should reference it.
- Jari: May be a separate specification as well. Joe: Key framework itself references EMSK. So either take that out, or reference it. Russ: Its just two pages, merge it in. Jari: Ok
Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of Jose Puthenkulam) ========================================================================= =================
- http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt
- Status update for 04 version of the draft: mostly editorial improvements. Three issues (64, 191, 192) are still open. Some crypto experts have reviewed the draft, no issues so far. Timeline is to resolve open issues this year. Revise section 4, synchronize with keying framework. Submit for final review in January, close in February 04.
- Issue: The EMSK may not be the best thing to use for the compound bindings. We need to look a this
- Bernard: We started looking at this because many other groups needed something like this. Now IKEv2 is doing something similar, and .... is doing something similar. Right now it seems like the IETF is going violently in different directions and we get incompatibilities. An there may be different views of whether there is a problem.
This draft is very long, and for me sometimes confusing. I would like to see an overview of what the overall flow is, including key generation and use, how the innner and outer keys are bound, how methods are sequenced, whether remote authorization over the tunnel is permitted (and what the reasoning is- perhaps this is here, but I am not finding it). I also am confused about what the crypto binding TLV does and why it is necessary.
- Russ Housley: True, need solution, proposal to formulate this in a few slides for broader presentation in SAAG. Farid: his has already been done in former IETFs. Bernard: We got no input then.
EAP methods - EAP SIM/AKA, Pasi Eronen ======================================
- http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt - http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt
- No open issues with the drafts. It is part of 3GPP Release 6 WLAN inter-working. EAP/SIM products are available, deployment is beginning. Plan is to do individual submissions as informational, once EAP base docs finalized. No implications to 2284bis, state machine or keying framework.
EAP Methods -- PEAPv2, Jose Salowey ===================================
- http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07 .txt
- Recently submitted draft -07. Features are complete. Added support for sequences of EAP methods. Supports inner method binding. Goal is to submit as informational. Currently WG item not requested.
I think a diagram in a PDF document would be very helpful in this case, along with a text document, like the State Machine doc.
Can just the initial authentication part of IKEv2 be used as a "norm", not including other payloads?- Margaret: All drafts are planned to be published as informational. I wonder about this. Bernard: It took so long to get this WG started that much work was already more or less done, and it may be hard for people to give up change control now, and make these WG documents. Pasi: Correct with respect to EAP/SIM and EAP/AKA
EAP METHODS - EAP-IKEv2, Dirk Kroeselberg =========================================
- http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt
- A number of issues have been improved in the update, e.g. error handling, fragmentation. There are still open issues like optimizing the no. of messages, security claims section. Another update planned before next IETF to address these issues.
- Michael Richardson: Tunneling seems to be complicated, suggestion remove support of tunneled methods or to detail use case. Dirk: True, but applies to all tunneled methods. Is only an optional feature in IKEv2.
- Bernard: Is it intended to handle address assignment in EAP-IKEv2, do we need that? Bernard: Are all identity payloads needed? Is IKEv2 a limitation in terms of identity payloads? Dirk: Need to check this.
Is the "normal" authentication in IKEv2 (not EAP) without Intellectual Property hindrances?
EAP Methods - EAP Smartcard, Pascal Urien =========================================
- http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt
- Goal of the proposal is to support EAP in smartcards. No discussion.
Roadmap discussion (10 minutes), WG Chairs and ADs ==================================================
- Steven Hayes: (clarifying 3GPP position) 3GPP requires the two methods discussed, and network selection. Otherwise there are no further requirements on EAP. Request to publish EAP-SIM and EAP-AKA as informational.
- Someone: Are the available methods sufficient to progress the documents to Draft Standard?
Margaret: Good point. Especially for the keying framework, a method that uses all the features is required.
Bernard: There is no standard method required for this, just the use of the features with any method.
Russ: Requirement is two independent interoperable methods.
Bernard: You can show interoperability without having particular methods showing them
Margaret: Are all the methods done informational forever? So what does the EAP WG do - wait till somebody comes along with a method to be standardized?
Bernard: There is one standardized mandatory method
Russ: But that one doesn't exercise all features.
Bernard: Somebody has to ask for a standardization effort.
Margaret: There is no interoperability without using informational RFCs.
Bernard: The same issue (mandate one method) has been brought to the group by 802.11.
Pasi: Could update EAP-TLS as this is the only key-generating RFC method. Current status is experimental, however.
Jari: Some defined methods should be standardized in their second revision, e.g. EAP-TLS.
Margaret: We don't have the rule that because something has been deployed, it can't be a standards track document!
Donald: It almost seems like everything developed outside never is to become IETF standards. We have some examples where v2 of some documents have become - after rework - standards track documents.
Margaret: How will expert review differ from the expert review done for standards track documents.
Bernard: The intention is to basically raise the bar for new methods, as many have already been allocated, but about 70 percent do not have a useful documentation (expert review is defined in 2284bis).
Bernard: If you already have a type code, it's not even sure that the need for expert review will get triggered. Even if you have a code allocated, that's not a guarantee that the RFC editor would publish a document, he could decide this is awful.
(Editor's note: Margaret later sent this e-mail to the list: "Apparently, I said something at the EAP meeting in Minneapolis that has caused some confusion about the IANA allocation of EAP codepoints.
Just to erase any confusion, I want to make it clear that I support the current wording in the EAP draft -- that EAP codepoints should be allocated on the basis of expert review. This represents an increase in scrutiny from the current policy (first- come- first- served), which I think is appropriate. I do not believe that EAP codepoints should require an IETF standard, and I do believe that it would be appropriate to allocate EAP codepoints in some situations (vendor-specific or environment-specific) where it wouldn't make sense to produce an IETF standard.
I do hope that the WG will consider standardizing secure, general purpose EAP methods in the future, but I do not believe that we should require a standards-track document in order to obtain a codepoint.")
Chris Elliot: I'd really like to se you take on methods work.
Meeting adjourned.
_______________________________________________ eap mailing list eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
-
eap wg minutes from ietf-58 Jari Arkko, November 18 2003
- Re: eap wg minutes from ietf-58 John Vollbrecht, November 20 2003
Results generated by Tiger Technologies using MHonArc.