| RE: draft EAP WG minutes from IETF-62 | <– Date –> <– Thread –> |
From: Hannes Tschofenig (hannestschofenig hotmail.com)
|
|
| Date: Tue, 29 Mar 2005 10:14:24 -0500 (EST) | |
hi jari,
could you add a link to the eap-psk and the eap-ikev2 slides?
could you add a link to the eap-psk and the eap-ikev2 slides?
http://www.tschofenig.com/eap/IETF62/eap_ietf62.ppt covers both: eap-psk + eap-ikev2
ciao hannes
From: Jari Arkko <jari.arkko [at] piuha.net>
To: eap [at] frascone.com
CC: Bernard Aboba <aboba [at] internaut.com>,"Nelson, David" <dnelson [at] enterasys.com>, subir [at] research.telcordia.com
Subject: [eap] draft EAP WG minutes from IETF-62
Date: Tue, 29 Mar 2005 18:09:16 +0300
Here are the draft minutes, thanks to Subir and Dave for taking notes! Comments, if any, to Bernard and me in the next couple of days, please.
----
EAP WG meeting Notes, IETF-62, Minneapolis
Extensible Authentication Protocol WG (eap)
Thursday, March 10 at 0900 - 1130 =================================
CHAIRS: Jari Arkko <jari.arkko [at] piuha.net> Bernard Aboba <aboba [at] internaut.com>
SCRIBES: Subir Das and Dave Nelson, merging by Jari Arkko
POINTERS: The presentations are on the web at http://www.drizzle.com/~aboba/IETF62/eap
And issues are at http://www.drizzle.com/~aboba/EAP/eapissues.html
1. Preliminaries (chairs), 10 min
- Blue Sheets
- Minute Takers
- Agenda Bashing
Agenda bashing by Jari Arkko. Farid's draft will be presented by Pasi.
EAP-TTLS draft presentation will not be done, due to Paul Funk not making
it to the meeting.
2. Document Status RFCs - 3579, 3748 Recently approved RFCs, in RFC Editor's queue: - EAP State machine document - EAP SIM - EAP AKA - EAP over Diameter Progressing work on: - EAP Keying framework has some open issues and will be discussed today - Network Selection will also be discussed today - Methods... EAP PAX, EAP PSK, EAP Smartcard, to be discussed - Authenticated service identity will also be discussed today Other documents, please review: - EAP usage in PANA - EAP usage in MIP6 - EAP usage in DHC - EAP usage is NSIS - EAP usage in ISMS - Also ICOS boF discussion at IETF-62 on EAP usage
3. Keying framework discussion (Bernard Aboba), 50 min http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-05.txt
- Drsft 05 is presented by Bernard - Russ Housley's requirements were reminded once again - Binding key to appropriate context has been the most difficult/contentious/discussed issue
- 7 issues filed in IETF 61 - closed 4, 3 are open
- Issue 277: Organization of the document
Caused by conceptual issues.
Mixed framework with extensions.
May not accurately discuss potential discussions, possibly misleading.
Suggested Resolution: Split the document in two parts
First one will analyze the existing applications and 2nd one will focus on documenting and analyzing the keying framework
Suggested breakdown is described in details: Key management framework (today) and key management extensions (future).
This will allow us to finish the framework document. Presented proposed section breakdown in slides.
Seek to move speculative discussions out of the framework document into the extensions document.
- Issue 279: Requirements
Requirements need to be integrated with section 7, which is not a trivial task. Ferret out high level criteria expansion of the Housley Criteria.
Need volunteer to review the document. It's a big task Joe Salowey and Donald Eastlake volunteered
- Issue 291: Key cache Synchronization
Change submitted by Jari Arkko: EAP does not negotiate the lifetime of keys, nor do the methods Note disadvantages of method-specific key lifetime negotiation. Breaks method independence properties. Proposed to accept, ask for review and discussion of other alternatives.
Proposal: Accept; If people have any any objections
John Volbretch: Is the intent of the requirement of EAP method? In general with the whole keying document, are we making suggestions on what methods should do?
Jari: Methods are expected to provide the key. You should not start doing key lifetime in methods.
John: Is the point to judge EAP methods?
Bernard: Looking at the Housely criteria, then the following requirements come out of this. Expands to detailed criteria for specific modes of EAP usages. RFC 3748 mandates truth in advertising, not any minimum level of security. RFC 3748 OK for creating keys. This document helps use keys in a system. 802.11 requirements document explains the security properties of the system. A roadmap for the future, or a cookbook. Does have some normative impact for EAP methods.
Question: Are there advantages to non-method specific requirements?
Comment: If we knew how to do it...
Comment: We can do it at the link-layer below EAP.
There are implications of individual link layers doing key lifetime negotiation.
Question: Don't establish requirements for link layers we don't control?
Comment: Method specific lifetime probably not desirable.
Layers that are using the leys are caching them and negotiating the lifetime
Question: Is there a multiple layer conflict?
Comment: Methods could have different lifetime than the AAA server sets. Because of entropy of the key. Look at both the method and the AAA dictated lifetimes.
AD Comment: Security problem with the protocol. We don't have the right information to trade-off between not working and not secure. Random hangs because of key expiration are annoying.
Comment: Limit AAA capability to specific lifetime information. APIs?
- Architectural issue, key cache management.
Bernard: How is the EAP key cache is managed on the peer and on authenticator? To date, this has been link specific.
Question: What happens when a host is multi-homed?
Answer: Separate EAP keys for each media type.
Comment: Use distinct names for the same key on each media/interface.
Comment: Creates inter-media handoff issues. There seem to be a number of problems.
Question: Is the same key used on different media?
Answer: The key is not bound to a media, its passed up to the server, based on the client and not bound to an interface.
Comment: Don't use same key on different interfaces.
Comment: Not structured as an interface specific cache today.
Question: Are keys managed by the link layer?
Question: Where is the cache, in the EAP layer or in the interface layer?
Pasi: The whole issue depends how you look the EAP layer. If you see EAP is above link layer, then it's different. But if you think EAP below link layer then the issue came. If you consider EAP is a building block then it is link independent
Comment: Agree with that comment. Sharing of keys across media would need to be addressed in the extensions document.
Sam: If sharing keys is a problem, look at key derivation within the layers using the keys, otherwise security analysis becomes media dependent, and gives rise to potential attacks.
Question: If we have multiple interfaces on the same media, is caching for the host or for interface? Is it for a particular media type, regardless of interface?
Sam: Using the same key with different protocols (media) is risky.
Bernard: With 802.11 and 802.16 both on the same box, does the key apply box-wide?
Sam: There is a need for cross application security analysis. Future media types can compromise existing media types.
Sam: The context of the Housley Criteria is not specific to media types, causing the need for added analysis.
Comment: Media types need key separation. Different media on different interfaces needs case by case analysis.
Comment: This is only an issue if you have a key cache.
Comment: In practice, a key is used in a particular context.
Comment: The EAP state machine is media independent.
Sam: The key is linked to an application.
Comment: EAP methods do not pass information as to the application that calls them.
Comment: The AAA server might know the application.
Question: But where is the cache?
Comment: We have security across protocols outside EAP. Does that not create the key association and media dependent keys? The client is not responsible for EAP keys.
Comment: EAP methods create an AAA key. The AAA key goes to the NAS for use in the security association protocol.
Comment: Operation cannot depend on the media type.
Comment: The key cache is at the NAS today. Keys are given out for specific purposes. Are some bindings implicit and some explicit?
Comment: That's an authorization issue.
Comment: Yes. There is no explicit authorization in the key. Attacks likely exist with implicit expansion of key scope.
Comment: EAP can operate without an AAA sever. May clarify the discussion. Multiple applications invoke AMSK considerations. Make this issue a futures work item?
Comment: We need to understand what we have now.
Comment: We have key caching in the NAS, but at what layer? We don't have key caching at the AAA server.
Comment: The most difficulty is if EAP is a layer rather than a building block.
Comment: It's still an issue. We need to explicitly state if an application even has caching.
Comment: Distinct key names for the same keys or different keys? The logic of key names is media independence. If managed at the link layer there is little need to name at the EAP level. What good are the EAP key names?
Comment: What are the key names good for if we don't understand that? Let's remove the names from the spec.
Question: Is there a true cross-media need? When do you need a media independent key name?
Mani: Has the PMK caching issue been raised in CAPWAP?
Bernard: What is a NAS - the thing to which an AAA server gives a key, a unique NAS ID - does not matter how many ports it has.
Comment: Keys owned by the AC for use by any attached devices. Not bound to the WTC. Not bound to an interface on the peer.
Comment: What about the key names? If using PSK, then consistent naming is not possible because there are separate name spaces. Use ASCII format? Is that too large?
Bernard: Continue the discussion on the EAP WG list.
- Roadmap
. Produce split strawman based on -05 . File additional issues . Resolve issues
The idea is to bring this document to WG last call by IETf-63
4. Network selection update (Pasi Eronen), 10 min
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-10.txt
Pasi presented the draft. The draft went to IETF last call. There were number of revisions. Not all were resolved. Hope to resolve the issues quickly.
Issue Status Type Description proposed Resolution 286 IDSEL-08 Technical Security Issue Accept 287 -10 290 -10 same Roaming model 293 -10
- Issue 293: The document does not define the required client behavior
Additional text is proposed
Jari: I would like to give some background. Initially 2/3 year ago when these drafts were presented all these things were there but removed and it is coming again. We are going around in circles.
Issue raised by Glenn Zorn
Document is fuzzy about the role of AAA server
Proper text will be provided and will be discussed in the mailing list
Some other issues related to grammer and sysntax will be edited according to some comments.
Jari: Please sit with Glenn and make sure that he is happy with the changes.
5. EAP methods and Methods extensions
Jari: First some history. Original methods unsuitable for WLAN usage Large number of vendor specific, often undocumented methods exist. Recently, RFC3748 requires expert review for allocation, unless vendor specific. Multiple expert reviews are pending.
Jari: Is there any interest in standards track methods? Or leave it to the market and other SDOs to decide? Should the WG undertake to standardize a limited number of methods? Chairs think that there is a need for few initial interesting methods but the question remains how do we select those. Let's discuss after these set of presentations.
Need high quality contributions and folks to work on this and agreement on a few methods to work on. Need for a market demand for this work. Recommend a limited number of methods to consider as standards. This would require a charter change. But the decision to be made where? Input form other WGs or other SDOs?
6. EAP PAX (Charles Clancy), 10 min http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-01.txt
Charles Clancy, UMD presented the draft. Described the PAX overview. Simple shared secret -key mutual authentication. Extended mode of support. Described the changes since -01 and -02 versions. Complete implementation for -02 version. Free RADIUS 1.0.2 XSupplicant 1.0.1. tested APs: Cisco AP 1200, HostAPD 0.3.7 Different timings are also mentioned. Author wants to see this a as Stds document
Glenn: Is the timing measured on the client or server side?
Charles: It includes both and I am running in the same box. If you run in different this can be minimized.
Jari: Do you have specific application in mind where this could be applicable?
Charles: we have two appendix: This is in particular WLAN environment. Shared key bootstrapping
7. Service Identity Authentication (Pasi Eronen)
http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt
Pasi gave the update. He described the background and problem again. He also described a one way to fix this.
Hannes: This is really useful document and this should be accepted as WG documents as well. I will strongly vote for this.
Glenn: So what are we exactly proving here? Why cann't we prove it in the first place. How does it know which NAS I am talking to.
Pasi: What it does is that one NAs get compromised, it can't do damage to others.
Bernard: As I recall there are number of problems here. IEEE 902.11u announcing the cost, lets assume there is a cost? If NAS tells its free, we have an attack.
Glenn: How do you fix that?
Pasi: This draft is most useful when you are using EAP for both WLAN and other purposes, then this is useful.
Jari: You are asking how are we doing this? What it does is: you are delivering the same information from AAA server both NAS and Client. Without additional configuration you can not do more, but at least you are making sure that everyone has the same information.
Bernard: there is a way you can go beyond this; via RADIUS server authorizing specific usage.
Joe: One thing I am wondering here: does this introduce any other dependencies?
Pasi: Our draft does not assume that AAA server can be trusted and NAS is dishonest. I don't think this introduce any other dependencies.
Jari: What are the next steps? Interest in adopting this as a WG item?
Bernard: There seems to be some interest, please discuss in the list and what people think; whether any modification is required.
8. EAP-PSK (Hannes Tschofenig)
Lightweight method.
Based on EAP Archie work.
EAP-MD5 replacement.
Pre-shared secrets only .
EAP-AES.
Only well known security methods, which have security proofs.
Symmetric crypto.
Extensible in that it establishes a protected channel that allows exchange of information between peer and authenticator.
No known IPR encumbrance.
9. EAP-IKEv2 (Hannes Tschofenig)
Powerful method Adds support for PKI based authentication Design based on IKE v2 Cipher suite negotiation Variable key strength Fast reconnect Active user identity for initiator, passive for the responder No known IPR encumbrance
10. General methods discussion
John: It might be a good think to standardize the methods because if there is a method people and implement and prove that EAP works. One of the things is not entirely clear to me is that key generation. I am in the favor of a EAP method that is easy to implement and has check for certain things.
Jari: Default assumption is that IETF requirements document (RFC 3748) needs to be followed but we can go much beyond that if we want. Say, we could target IEEE requirements for WLAN. We are not talking the mandatory implementation of a method. If we define the methods
Comment: Some other WG could specify a mandatory method.
John: Not sure what standards track means if it's not required to implement? EAP-PSK seems like a good candidate. EAP-PAX has extra features not required externally.
Dave: My understanding is that standards track gives you the mandatory interoperabity tests bit Information RFC does not.
Nicole Williams: There are instances where STds track documents are not interoperable.
Mark: It's a nice thing to have multiple interoperability but it is not a mandatory for standards track PS RFC. INT area treats it as optional.
Bob: If we gpo down the path we need to identify the requirements. There are too many methods and we can go some nasty political situation.
Jari: That's a good point. We may go to a dangerous area. We can take two paths: one is to define some IETF requirements and other one is to see how these methods develop on their own, by the markets. But we have already tried the latter, I think we need some guidance from the IETF to converge EAP method usage at least a bit from the current situation.
Sam: It would be good to have some Stds method but I agree 100% with Bob. However, I would like to add one thing: I don't know whether this is the right place to do this. There are other places we can do this, would need a tighter tie to the Security Area if we want to do it.
Pasi: We certainly we have one method that is an RFC, EAP TLS. Might not be
a bad idea to recycle that to a PS RFC from Experimental.
Jari: Good idea.
Pasi: I also see some value in defining simple share secret method.
Majid: What is the relationship with other SDOs? I see .11, .16 are also using different methods
Bernard: If you look at Liaison statements from 802.11, you will see they have requested help in the definition of methods. Some are done, others are not.
Jari: Look at these things from top level perspective. There's lots of variety in methods including vendor specific and experimental. It appears that method quality is tied to the level of standardization. Where does that work happen? Many methods in use have not been documented in RFCs. Looking for convergence going forward.
AD Question: How do we get EAP to Draft Standard without any approved methods?
Answer: We probably don't.
Joe: Probably we can do this in a different group where there are some alignments with other authentication methods.
Pasi: On the other hand people in this group are working on EAP methods. We can change our specifications.
Sam: We need more alignment with other security frameworks. The matrix doesn't look real good right now. The approach going forward is to unify... Clearly, coming up with another framework is not the right thing. Elements of technology that can be reused in the existing framework would be good.
Joe: Sam's idea is to unify things and not to create another framework.
Jari: I am glad to hear that we don't need another framework.
Sam: We have several frameworks, and perhaps there is a reason for that. While evaluating these proposals, there must need minimal code changes and useful to the people.
Hannes: I am little bit worried about this. We have been discussing this quite long and that's why I think people are coming with new vendor specific methods. Will we make progress on EAP methods? The discussion has been going on too long, and we always postpone it to the next meeting.
Bernard: We have an existing process for publishing methods.
Question: Do methods need to conform to something other than RFC3748?
Answer: No.
Pasi: It is not only the question of whether we can stop or not. Some vendors are proposing their methods as proprietary.
Jari: We have to continue this discussions with AD . At least part of the room things that EAP methods are required.
Bernard: This is interesting discussion.
Sam: I guess I am not sure who proposes the procedure and type code change.
Jari: We will discuss this more in the mailing list.
11. EAP and the Trusted Computing Group (John Vollbrecht)
John presented this document. TNC is the sub-group of TCG. It is subscription oriented group. TNC is trying to define and promote an open network architecture that enables network operator to enforce polices. He presented the overview of TNC. It operates in client and server mode. Integrity checking is the first step and most important thing to start the dialogue. TNC version 1 contains 3 specs. The interest here is the transport. TNC as part of EAP dialog. It may be a method or something else. If the assumption is correct, EAP methods can be used within a protected mode. He also described how one can do this with the help of EAP by some inner methods. Can we take this as WG document/work?
Jari: Are you suggesting to standardize some inner methods. But we have not yet standardize the tunnel methods.
Answer: No, this is just about the tunnel methods.
Jari: You also mentioned that TNC is coming to IETF to standardize the methods. Do we have a request from TCG to IETF requesting this work?
Answer: We could arrange for that request. The work in TCG is just getting to that point.
12. EAP POTP (Magnus Nystrom), 10 min http://www.ietf.org/internet-drafts/draft-nystrom-eap-potp-00.txt
Dave presented this draft. Part of One-time-Password Spec. He described the state of affairs and goals; End-to-end protection, mutual authentication, sports key derivation for 802.1x, minimal initial configuration. IPR statement also mentioned. Trying to make it royalty free. He described RSA EAP 32 method and computational details
Russ: What the heck is pepper?
Dave: Pepper is a symmetric shared secret.
Question: Why is it needed?
Dave: Pepper is a randomly generated number. A server has to "grind the pepper" i.e. iterate over the permissible range of values to find what matches. The salt is in the clear. The range of the peeper is communicated across the wire, but the actual value is not. An option would be to assign a pepper value and send it via AES protection.
Question: Does that still leave a key distribution problem?
Comment: Where do we go from here? Conduct an RFC3748 review of the method?
Answer: an RFC3748 review would be nice. Will be advocating this method to other token vendors. Will be using an existing IANA code point.
13. EAP Smart Card (Pascal Urien)
Pascal described the EAP Smart card framework without slides due to the time limitations. He emphasized that this is a framework and can use many methods. We need a type for smart card.
Jari: I think you are requesting the review of your document. At this moment we need volunteer to review the documents. If you are interested pl. contact either me or Bernard.
_______________________________________________ eap mailing list eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
-
draft EAP WG minutes from IETF-62 Jari Arkko, March 29 2005
- RE: draft EAP WG minutes from IETF-62 Hannes Tschofenig, March 29 2005
- RE: draft EAP WG minutes from IETF-62 Hannes Tschofenig, March 29 2005
Results generated by Tiger Technologies using MHonArc.