Last Modified: 2004-10-01
| 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) |
|
Extensible Authentication Protocol WG (eap)
IETF-61 Minutes, Wednesday, November 10, 2004 at 0900-1130 ========================================================== CHAIRS: Bernard Aboba <aboba@internaut.com>, Jari Arkko <Jari.Arkko@ericsson.com> SCRIBE: Gerardo Giaretta <Gerardo.Giaretta@TILAB.COM> 1. PRELIMINARIES, CHAIRS ------------------------ Presentations on the web: http://www.drizzle.com/~aboba/EAP/IETF61 Issues on the web: http://www.drizzle.com/~aboba/EAP/eapissues.html - Agenda Bashing - Documents Status RFC 3579 "EAP over RADIUS" published earlier RFC 3748 "2284bis" published earlier EAP state machine in RFC editor queue. Some comments -> back to the WGLC and then back to RFC editor. [Bernard]: We need a review and approve from others than authors [Hannes]: I'm not author and I approve. We implemented this state machine. [Bernard]: Did you find issues? [Hannes]: I'll let you know EAP Keying framework: discussion today EAP over Diameter (AAA WG - draft-ietf-aaa-eap-09.txt) approved by IESG Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG NAI Update "RFC2486bis" [RADEXT WG]: when I-D submission re-opens will be submitted and sent to the IESG Methods documents 3 submitted for RFC publication (EAP-SIM, EAP-AKA, EAP-PSK) Many issues in EAP-SIM reviewed by Bernard Binding Problem definition: not updated since IETF-58 (abandoned) Other work: need review from the WG EAP usage in PANA EAP usage in MIP6 EAP usage in DHC [Hannes]: EAP in NSIS because of authorization issues. In NSIS WG we have a number of docs describing authentication and authorization issues and need comments [Bernard]: ISMS too [Glenn]: I have two questions about the directions of the WG. There is work that has nothing to do with authentication (netdisc). Moreover no standardization of EAP methods. 1) EAP for authorization and other usages. I think we should develop a flexible authentication and authorization protocol and include network selection and discovery. What do you think about this? Or would you continue to add stuff to EAP? [Bernard]: the scope of EAP is clear. Applicability statement and IANA considerations state the purposes of EAP [Glenn]: Which are the future policies? [Bernard]: to be described in future documents. Can you send an email question? [Glenn]: OK 2) Regarding EAP methods. People need guides from the IETF: IEEE for example. They did not standardize EAP methods. The 3 EAP methods mentioned in slides are about 3GPP [Jari]: Not for PSK [Glenn]: Are we going to standardize methods? [Bernard]: We have one method we need in standard track [Jari]: People can develop new methods and standard tracks. If there is interest in people and vendors we will standardize. [Glenn]: It's very difficult to publish standard as individual submission [Bernard]: We already developed the process for publication of EAP methods [Dorothy]: To clarify 802.11 prospective: 802.11 made the decision not to select an EAP method. There are only requirements for EAP methods in IEEE. 2. KEYING FRAMEWORK DISCUSSION, BERNARD ABOBA --------------------------------------------- See issue list page at http://www.drizzle.com/~aboba/EAP/eapissues.html Requirements from Rouss Housley Keying framework try to analyze the security of EAP system The requirements are a sort of charter for the document [Glenn]: I don't remember any WG consensus on Rouss requirements [Bernard]: We took these requirements as a challenge. So far we did not find any problems with these requirements. [Jari]: I agree with Glenn. We don't need to agree with Rouss' requirements if we think he is wrong [Glenn]: These requirements seem to drive many EAP method design and I think this is a problem. Could we have a WG document regarding these method-design principles? [Bernard]: EAP keying should do this [Glenn]: I don't think it is acceptable to base these principles on a presentation [Jari]: Let's discuss technical issues [Hannes]: One requirements states that an acceptable solution must authenticate all parties. We are not always authenticating all parties [Bernard]: the important thing is to be clear on limitations and state them 21 issues (7 editorial and 14 technical) Discussion on most important open issues: ISSUE 254: KEY LIFETIMES EAP does not negotiate the lifetime of exported keys EAP does not support re-key of exported keys without re-authentication Secure Association protocol may support re-key without re-authentication EAP itself is not managing the lifetimes but SA protocol is responsible for lifetimes [Jari]: Just a clarification: re-key does not extend the original lifetime. Moreover, if an exported key expired, everything derived from it dies. [Bernard] (from slides): TEKs usually expire on the peer and server after the session ends [Joe]: I think that this is a good suggestion. Maybe deleted is better than expired. [Paul]: Agreed that expired is a wrong word. [Hannes]: Is AAA-key stored on the local AAA server? [Bernard]: It says only about expiration not storing [Jari]: What about fast handoff? we use the same AAA-key? [Bernard]: Need more thoughts on that. We have to guarantee the AAA-key freshness [Paul]: Something about SA protocol: EAP method generates fresh keys but then it is the SA protocol that is responsible of these. [Joe]: (about slide 7) better EAP server and not AAA server [Bernard]: not sure. Let's discuss on the mailing list [Joe]: EMSK has a shorter lifetime than MSK [Bernard]: the issue is that applications do not know the lifetimes of AMSKs [Joe]: These are problems of applications and are not fixable by EAP [Jari]: In theory we could negotiate all lifetimes. In practice, there are limitations so I think the approach of Bernard is trying to use is the usage of the session lifetime to regulate all lifetimes [Joe]: Session timeout is very specific to AAA protocol. [Bernard]: The idea is that we have a general timeout that could be a session timeout or another but it is generated by AAA server [Jari]: We can't describe generally but we have to look at the protocols that are used, Diameter or RADIUS [Joe]: Disagree. There are things that are independent of that. [Jari]: (about slide 8) Is it a maximum TSK lifetime or a minimum? [Bernard]: Maybe this the minimum TSK lifetime ISSUE 262: KEY NAMING Text proposed in the mailing list Some methods do not have EAP server name and use the authenticator identity. Maybe there are some implicit requirements that derive from this text [Joe]: We should not have requirements on AAA server name [Hannes]: Key naming discussion is confusing. What means key naming? [Bernard]: The naming requirement derives from caching [Hannes]: Naming keys you generate state [Bernard]: It is needed to select exported keys [Hannes]: To select a state does not require strings or names [Bernard]: this is true but...(something lost) [Hannes]: Key naming has nothing to do with what you are talking about [Jari]: If you have a connection-oriented protocol you have state and you don't need key naming. But for caching you need. None is using key naming and existing systems use link-layer names. We could have potential requirements in the future and this is also why we are discussing name. Another question is which names we use. [Bernard]: (about slide 10) there are implicit methods requirements in this paragraph and we should be careful on this [Pasi]: we are not interested in naming keys but in naming state. I don't understand why we need to name keys but something else [Bernard]: we are naming sessions and not keys [Hannes]: short comment to Pasi. Half document talks about key naming and half about Security Association. Another issue MSK is never selected again, so it does not need to be named. [Bernard]: we need to name it for caching [Hannes]: it's the AAA-key not the MSK [Bernard]: Good point. We should make it clearer in the document ISSUE 267: PRF NEGOTIATION Bernard states the proposed resolution No comments ISSUE 275: AAA-KEY SHOULD BE DERIVED FROM AMSK Bernard states the proposed resolution [Jari]: there must be something in the KDF to have different keys for different APs <Bernard added Generation # in the second bullet> [Joe]: there is the application data. The first purpose of the AMSK is not to have the EMSK around. We should discuss the requirements to understand if these keys must be different or not. [Hannes]: this key derivation can be used in some places and not in others. This is not clear in the document. I'd suggest to add usage cases. ISSUE 277: DRAFT ORGANIZATION Bernard states the proposed resolution [Jari]: Security analysis and not requirements [Hannes]: I'd like to see architectural issues pointed out, for example how EAP is used in IKEv2 and some IEE examples. For people that do not have IEEE background it's difficult [Bernard]: Agree. This is missing [Paul]: is the document a best practice? or a survey of architectures? [Joe]: I'd like to see what are the expectations for EAP methods and how the applications can use the keys exported [Madjid]: I just want to know (if it possible) in a generic way how keys are derived without IEEE or TLS details [Jari]: we are trying to describe a system. We'll try to describe how key derivation works: this part should be simpler. [Madjid]: It's hard to read and the key derivation is only in the appendix [Jari]: it's an organizational problem and we are trying to tackle. The purpose is to describe the security of the system [Jari]: We are open to different suggestions to reorganize the doc. ISSUE 278: LIFETIME OF KEYS INTERNAL TO EAP METHODS Bernard states the proposed resolution No comments ISSUE 279: SA PROTOCOL REQUIREMENTS Bernard states the proposed resolution No comments [Bernard]: the main challenge of the doc seems to be organizational 3. EAP STATE MACHINE, CHAIRS ---------------------------- [Jari]: Are there open issues? no comments 4. AUTHENTICATED SERVICE IDENTITIES, PASI ERONEN ------------------------------------------------- (slide 3) If D is compromised it can pretend to B This is because EAP does not have a concept of service or NAS identity Solution: the AAA server tells the client to which service it is sending the key It is not the same thing of channel binding: the difference is between "I believe" and "he claims" Method independent framework for service identifiers. This method independent blob can be carried in AVPs in EAP methods [Hannes]: Good document and useful [Jari]: Channel binding vs Authentication. Do people think this distinction is useful? [Pat]: This is an interesting problem. IEEE has a group dealing with fast handoff and this could be an issue because in this case the key is not obtained from the AAA server. [Someone]: If AAA server and X have trust relationship and X has a trust relationship with Y, is this framework needed? [Pasi]: Yes. With this framework we want to prevent that a problem (e.g. a node is compromised) in a part of the system spreads in the whole system. [Yoshi]: PANA is also specifying service parameters. I think we need to add to PANA this service parameters [Pasi]: we decided not to include this in the document and eventually specify in a separate document [Paul]: why not change the direction and the client sends the information to the AAA server and the AAA server confirms? For example for SSID this could be useful. [Pasi]: SSID is also carried by RADIUS 5. NETWORK SELECTION UPDATE, CHAIRS ----------------------------------- Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG No comments 6. EAP PAX, T. CLANCY --------------------- Changes due to comments during last meeting Supports provisioning with a weak pre-shared key Supports key management with forward secrecy using Diffie-Hellman List of major changes from version 00: Address Crypto Concerns Protocol Implementation Issues support for HMAC-SHA1 and AES-CBC-MAC Description of the message flow both in no identity protection and identity protection cases Implementation using FreeRADIUS and XSupplicant Working on implementation for Windows XP supplicant Comparison between PAX implementation timings: PAX, EAP-TLS, PEAP-MSCHAPv2 [Hannes]: EAP-TLS is unfair as comparison, you should use EAP-PSK [Clancy]: We just used what it was implemented in FreeRADIUS [Joe]: regarding TLS timeline, have you ran tests with session resume? [Clancy]: without [Joe]: it could be useful to compare with EAP-TLS with session resume [Robert]: Considering the complexity of the code, for slower devices this EAP method could be very useful [Hannes]: Yes, it's good to think about performance and for example memory space [Jari]: How much interest is there? Who read the draft? -> 6 people [Bernard]: Are you requesting a standard track? [Clancy]: Yes [Chairs]: Who thinks we should do something like this? -> 7 yes, 0 no [Robert]: This is very leight EAP method. For example it could be useful in bridges [Bernard]: We should have a discussion and write something about that 7. EAP SMARTCARD, PASCAL URIEN ------------------------------ [draft-urien-eap-smartcard-type-00.txt] EAP methods working with smartcards may conflict with purely software methods Proposal: one EAP type (EAP-SC) for all smartcards The EAP-SC model: three layers 1. The EAP-SC handling layer receives and sends EAP packets, selects a Smart Card handler, and passes packets to the Smart Card handler 2. The EAP Smart Card Handler layer handles the interface to the smart card and any EAP Method specific functions 3. The Smart Card executes Authentication Method functions [Hannes], [Pasi]: EAP terminates in the smartcard itself. Why is it an issue? [Pascal]: You have a conflict because you may need software methods and smartcard methods for the same protocol [Pasi]: If you are solving a software problem on the client why do you need a new protocol? [Pascal]: There is a conflict from a software point of view [Jari]: I agree with Pasi and it seems to be other mechanisms to tackle this method selection. People have implemented without nothing on the wire. [Pascal]: IMO the authentication server always knows if smartcard is required or not [Jari]: Are you saying that there is a need of communication? [Pascal]: it's an issue for the client side that should not switch from a method to another [Joe]: I don't see the need. It seems an implementation side problem. [Pascal]: I don't agree [Hannes]: We have implemented EAP methods using smartcard and this was not needed. You really need to describe which is the problem you are trying to solve in order to understand [Pascal]: It's purely a practical issue [Pasi]: Smartcards are not so special to require a new EAP type code ---discussion cut---- [draft-urien-eap-smartcard-06.txt] New support of EAP-TLS EAP Smart Cards and EAP-TLS Security Claims [Hannes]: The distinction between user authentication and computer authentication is an identity issue [Hannes]: I don't think this topic (implementation in SC) is related to EAP WG and IETF in general [Pascal]: If these devices are useful for IETF we should specify [Glenn]: I read this draft and it seems an API specification and is not for IETF. The implementation of EAP methods in smartcards is strictly internal to smartcards |