Last Modified: 2004-06-16
1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition
Items 1-6 were included within RFC 3748. Items 7-9 will be handled as separate documents.
While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC 3748.
When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods.
| 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-60 Minutes, Wednesday, August 4, 2004 at 0900-1130 ======================================================= CHAIRS: Bernard Aboba <aboba@internaut.com> Jari Arkko <Jari.Arkko@ericsson.com> SCRIBES: Pete McCann and Yoshihiro Ohba, merging by Jari Arkko 1. PRELIMINARIES, 10 MINUTES ---------------------------- o Minutes & Bluesheets o Agenda Bashing Jari presents the agenda... o Document Status - RFCs: 3579 (EAP over RADIUS) and 3748 (EAP aka RFC2284bis) published. - EAP state machine (draft-ietf-eap-statemachine-04.{txt,pdf} in RFC editor queue. some discussion on the list. - EAP keying framework (draft-ietf-eap-keying-03.txt). One open issue about key naming. - EAP over DIAMETER [AAA WG]. In second WGLC. Two issues resoved during the AAA WG. - Network selection problem definition (draft-ietf-eap-netsel-problem-01.txt). Needs one more revision. - Netwowrk discovery (draft-adrangi-eap-network-discovery-01.txt). Needs another revision Targetting indivisual submission process due to tight 3GPP schedule. - NAI update, RFC2486bis [RADEXT WG] (draft-arkko-roamops-rfc2486bis-02.txt). WGLC to the end of this month. Officially, there are no open issues, but one issue brought that needs discussing with international names, IKEv2, and EAP strings. - EAP Methods [individual]. A large number of methods. EAP FAST was reviewed by IESG, needs to be revised, due to TLS extension IANA rules. TLS extension will be submitted separately. 3GPP has requiested EAP-level review for EAP-SIM and EAP-AKA I-Ds, which have been submitted to RFC Editor and need an AD sponsor review. RFC 3748 compliance review by EAP WG would be useful. Please read and submit your comments in the near term to the list We are looking for descriptions of all the security properties required in 3748 Doesn't do anything broken with respect to base EAP RFC. [Joe]: didn't we already have WG/EAP review on these? [Bernard]: ADs want a formal statement they can point to as a reviewer [Bernard]: if you want to volunteer to be the expert, come see us. - Binding problem definitions (draft-puthenkulam-eap-binding-04.txt). Not updated; abandoned. 2. EAP STATE MACHINE, PASI ERONEN, 10 MINUTES ------------------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-04.pdf o Status: 2nd WG last call ended in March, during Seoul Were some minor comments/clarifications in -03, then sent to IETF last call and approved by IESG. In RFC Ed q, But then got a really thorough review by Florent Bersani. Issues: - 247 and 251: mostly editorial comments. Handled in -04, just before cutoff. - 250: technical comments and requests for clarification. Some things clarified in -04; mostly things that could be done one way or another. Comment #12 included in 251. - 251: "canned" messages. 1X-REV sends canned success/failure. These aren't really allowed by 2748, but aren't really part of EAP conversation. Perhaps using eapolLogoff would have been better, but too late to change now. Conclusion: no change? [John Vollbrecht]: Thinking about this, if I send a success/fail, nothing bad will happen. Fail: nothing bad, success: client might attach when he wouldn't. [Pasi]: No, because when you send success, the port would have been disabled, so there is no conversation. [John Vollbrecht]: If he was in the middle of something, he might connect somebody: failure/success results might be ignored. [Pasi]: Right thing is to ignore them, not send anything. [Bernard]: If you are disabling the port, you want to kick the guy off probably lower layer message would be better. [John Vollbrecht]: Not an IETF issue, it is an 802.1x issue, they might or might not do something about it. [Pasi]: They are aware of it. Nothing breaks in the real world because of this. [Jari]: Right, but there is a nother part that is when 3748 allows you to send canned success message. [Pasi]: Issue 251 in peer state machine: Reading 3748 carefully: sending success/failure immediately after identity request/response is allowed, not the same as canned it is even mentioned in an example. Of course, in many cases peer would have a policy that it must authenticate The state machine allow this, so no change required [John Vollbrecht]: Point on the list was that if you are going to allow this without requiring an identity, I don't understand. [Pasi]: But that is something in 3748, and this document is not going to change that. [John Vollbrecht]: If I have to wait for Identity for guest access, it's just weird. [Pasi]: No one is going to use it. Issue 251 in authenticator state machine: Auth state machine does not prohibit canned messages Proposal: add "Policy.getDecision MUST comply with RFC 3748 restrictions about canned Success and Failure messages.". This was intended, can we do this at AUTH48? Next steps: Publish this as RFC. Postscript/PDF version requires some work by the authors. 3. WLAN REQUIREMENTS, 5 MINUTES ------------------------------- o http://www.ietf.org/internet-drafts/draft-walker-ieee802-req-02.txt o Individual submission being discussed on WG mailing list o Status: been through IETF last call One action item left, issue 243, clarification of state synchronization Each time it is changed, dorothy has to go to 802.11 to approve the change. [Dorothy]: Right, but I think we're done now [laughter]. [Bernard]: We sat down and tried to resolve Florence's 243: Using term "shared state equivalence" instead of "synchronization" Now says the state must be "equivalent" instead of "synchronized" Rest of language is more or less unchanged does not include state external to the method ... Is there any objection from the group to going forward? [Jari]: Pay attention to the words "terminates successfully ON BOTH SIDES". [Bernard]: Yes. Florent came up with examples where they didn't complete successfully on both sides and they wouldn't know.. Dorothy, you will have to decide whether this is editorial or not editorial We hope this is the last time [Hannes]: Might be editorial in this document, but whole discussion has implications to many EAP methods. We had to add a new message. [Bernard]: We couldn't think of any EAP method that didn't do this already. [Jari]: There always seems to be a message that isn't called synchronization but which in practice does this. [Joe]: Original had "protected result indication" which might be the complaint. [Bernard]: Right, we think this can be done. Don't want to disqualify all existing EAP methods. Hopefully this is the last we'll ever hear about this. 4. EAP KEY FRAMEWORK DRAFT, B. ABOBA, 30 MINUTES ------------------------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-03.txt o We've done 2 revs since IETF59 (02 and 03). Hopefully most of the material is in there now. We should make it readable and then have a disucssion on what it actually says Some of the key naming and lifetime issues are more important as people start to implement 802.11i. o The Participants diagram. Both peer and authenticator may have multiple ports In many dial-up situtation you can have multiple phone numbers true of other link layers as well. Conversation/keys are not bound to a particular port This has caused some confusion. o Conversation Phases. Discovery is lower layers, authentication is EAP, AAA transport is AAA, SA establishment is lower layer. Discussion about what happens at each phase is important for key management/caching o The Conversation. 3 party message flow diagram. o Requirements were outlined by Russ Housley at IETF56 All AAA WG documents need to meet these requirements EAP Key Management framework defined to help List of housley requirements on 2 slides o A bit about naming: this is all about cache management, there seems to be no other use. Allows peer and authenticator to have a conversation about what keys are in the cache. There is no need for an authenticator to request a key from the server. [Joe]: Wrt naming session keys, requesting keys by name, in general context of network access that's true; but, there may be cases where there are keys derived from an EAP session that need to be named. [Bernard]: So when we discussed in AAA, we decided this isn't an EAP thing it is an application thing. [Joe]: But the name comes from EAP, even though at that point EAP is not running. [Bernard]: Requirement is uniquely name session keys, but we don't think of those as being cached. [Hannes]: "Naming of a key" is a bit confusing. In the literature, in MIKEY, for instance, it means you must attach the identity of every key in the key exchange. Depending on the definition, some issues are fulfulled in EAP and others are not. I came up with 3 definitions for what it might mean. [Bernard]: Send it to the list, we will discuss each of those issues. [Hannes]: Helped to find some issues in PANA case. [John Vollbrecht]: Seems like there are cases where EAP might be given a key, then do an exchange to bind something to the key as opposed to create the key and give it to somebody. E.g., Diffe-hellman then bind key to authentication afterwards. Not always EAP that's giving the name. [Bernard]: We have to distinguish long-term secrets from actual keys developed by EAP. Key thing is that you don't name things you don't have to refer to. I don't name my toenail. [John Vollbrecht]: agree, but if I were to try to bind an authentication of the user to an already established key, e.g., session key, might want to give name of key to EAP method... [Bernard]: Let's have in the discussion on the mailing list specific examples so that we can understand [Jari]: One example is the resume function in EAP-TLS [Bernard]: Right, method-specific stuff. Examples will help understand o Another Russ requirement: compromise of a single NAS does not compromise the system. Note that a single NAS can have multiple ports. Binding requirement relate to channel binding. o EAP Invariants: Media, Method, Ciphersuite independence. o Types of EAP Keys. Tried to be more explicit in the document. - Keys calculated locally by EAP method but not exported - Exported keys - ... - Transient Session Keys New key hierarchy diagram in the document. o Key Naming: - MSK - EMSK - AMSK - AAA-Key - Key Name Characteristics - Key Name is NOT based on key itself, unlike in 802.11i - Key name used for cache negotiation between peer and authenticator we need to understand what else used for and why AAA server provides key name (and AAA-Key) to the authenticator, they are not kown prior to this - Key name sent to the authenticator as part of the EAP exchange o Key Liftimes: One of the harder to understand issues. - Management: Negotiation vs. out-of-band. - Resource reclamation: NAS are quite tiny, key caches fill up. How to synchronize the state? - Transient EAP Keys (TEKs): . Internal to the EAP method. Valid only for the duration of the EAP conversation. [Someone]: You can have cache strategies related to method...? [Bernard]: Have to clean up and distinguish between cacehd and not-cached - MSK, EMSK, IV: how long do they live? When the MSK ends up on the authenticator (or things derived from it) its life is defined by Session-Timeout, so can be controlled on a per-user basis by AAA server. [Jari]: In addition to not having re-key, you cannot delete because EAP is not running. [Bernard]: You could kill the session or cause re-auth. When it's not in use, then life gets more complicated Distinction between re-key of MSK (only possible on re-auth) vs. re-key of TSKs which can happen without re-auth. [John Vollbrecht]: would help to distinguish between what EAP does (creates keys, exports keys, refresh TEK) but it doesn't do anything else. So all other re-key is external to EAP. A lot of the discussion is "how to use EAP in the context of keys" But we should distinguish between general key things vs. EAP things. [Bernard]: Need to understand what there is to manage (SNMP, AAA variables) e.g., there is no AAA attribute to tell NAS how ofter to re-key without re-auth. [John Vollbrecht]: that's an issue with AAA not having a way to do that, isn't EAP issue. [Bernard]: Right, but this doc has system-wide charter. [John Vollbrecht]: Right, but should be split. [Bernard]: Just got into this on -03, new section, but it's important that we get things right. Re-key of TSKs is separate from the MSKs, not an attribute today (maybe it should be). We don't have any way of, if keys are setup at pre-auth, how long they live or how long they stay after session ends (Session Timeout is only after session is connected). We don't know how long the EMSK is kept on AAA server. If we knew these lifetimes, then derived keys would be no longer than that. Thoughts: EAP methods don't negotiate lifetime of exported keys e.g., EAP in IKEv2, there's no notion of MSKs, EMSKs living inside IKE. Having EAP negotiate some value wouldn't be helpful because it depends on whether lower layer lets them live or not. EAP itself doesn't do it either. SA protocols don't either. Should they? Well, there's a potential gap between EAP and SA. 802.11i, secure association protocol may run hours later. Not that many choices. Do it inside lower layer encapsulating EAP? (then not secure) Discovery based solution (e.g., broadcast global key lifetime)? [John Vollbrecht]: Seems that if I'm creating a key, I would create the lifetime if there was going to be one. Otherwise there is no control. [Bernard]: Can't do that because lifetime depends on lower layer and EAP methods are media independent. [John Vollbrecht]: Why? [Bernard]: media controls caching [Somebody]: not EAP methods responsibility, AAA protocol would tell you with Session Timeout. For MSK & EMSK, AAA server may have its own policy. For sub-keys you can just try them and they might fail. [Bernard]: Real difficulty is between authenticator and peer. AAA server can always attach lifetimes to authenticator. What I think we can conclude: . On AAA server, this is a system parameter. How do you sync it up in the system? Can at least send to authenticator. . If you don't have anything in lower layers (e.g., SAs) what do you do? . How does the STA know whether a particular key is in there or not? * should assume some default value * if it is a big mismatch, there would be problems . Maybe manage TSK re-key time as a distinct thing from session time . Not always clear that AAA management of exported keys is good, especially if server is unaware of NAS resource constraints. If NAS is in a resource reclamation situation, STA cannot find out what keys are there and what are not. Per-user key lifetimes might actually make things worse. Maybe a default lifetime would make it more likely to be in sync. This whole area is something we need more discussion on the list It is important as people develop key cache management for 802.11i [Paul Funk]: The question of key naming: you suggest independent, why? [Bernard]: Russ's original guidelines were about the idea of hierarchy, and that you are always able to name everything. There may be some issues about revealing some information about a pre-shared key. It's clear that if it's based on the key, you can't know it until you have the key. This would be a limitation. Draft needs more work on key names and key lifetimes, we can contribute to better understanding. 5. EAP NETWORK SELECTION PROBLEM STATEMENT, J. ARKKO, 15 MINUTES ---------------------------------------------------------------- o http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-01.txt o History, basic problem, issues o History and status -00 created based on EAP discussions based on Farid's contribution During last few months, we've had some additional work: - NAIbis in radext - Farid's EAP network discovery - Groeting draft and implementation - IEEE WIEN network selection - 3GPP network selection work Draft-01 updates problem definition based on discussion and external events o Recent developments IEEE 802.11 WIEN study group formed. Liaison letter received from 802.11 chair, requesting review of network discovery docs Plan o Way forward: Issue another version Request feedback on problem statement document from 802.11i Last call o Technical stuff: There's actually multiple problems - Access network discovery: which network to attach to? - Identifier selection: which NAI? - Roaming intermediary problem: how to route the request to the home AAA? - Payload routing: if there is tunneling, how do we direct the traffic - Other decompositions: Discovery, Decision, Indicating decision to selected network (attaching) - Another decomposition: Type of information discovered: Access network identity, roaming agreement, QoS parameters, ... - Some earlier findings: . All the problems are relevant, and new solutions are needed . Yet, problems in the presence of large numbers of networks, fast handoffs, they are hard . Would be bad to have multiple competing mechanisms . Need to produce some early simple solutions and then maybe produce some full-blown schemes later - A few issues... . Scope of Information. Haven't considered how much information is necessary In future, ideal network selection scheme would include, e.g., whether there are middleboxes, service parameters, QoS, cost, etc. EAP is an unlikely carrier for this information because of the amount But is there a relationship between advertising/verifying this info and EAP? There might be a security requirement to verify advertised parameters One potential way is to verify these things through channel bindings. Proposal: tell in the document that there are these different pieces of potentially useful information, point out security consideration, mention possible role for EAP. . Relationship between mediating network discovery and identifier selection Bernard's observation: both mediating networks and identifiers are represented in same data item (NAI). Maybe EAP network discovery advertisement would work as a hint for selecting identifier, not just for routing. Proposal: Document in farid's document. . Need to document better work going on in other SDOs (e.g., IEEE) o Anything else? [Blair Bullock]: Compelling models, proprietary ones, that we might want to look at. [Jari]: Would be good ot have references and short descriptions [Blair Bullock]: XML transport, etc... lot of good systems out there. [Blair Bullock]: on EAP validating parameters, how far do you intend to go? There's the "asseration by this org" and then "truth". [Jari]: There is a limit to what we can do in EAP in terms of parameters; we don't want to start transfering XML documents with pricing information. I don't think we can verify whether info is the truth. What we can do is verify that whatever you tell to the client and what the home network and the access network believe is the same thing. [Bernard]: This is a synchronization problem not a verification problem. As we discus in channel binding of 3748, it's possible for the authenticator to tell one thing to the peer and another thing to the AAA server (i.e., "I'm free" vs. "I'm $5/minute"). [Somebody]: Should provide that framework of disclosure through the home system. [Jari]: Right, one possible transport. Whatever real-life verification happens after that is not a protocol issue. If you get a bill you can complain. [Somebody]: The channel should be there. 6. EAP NETWORK DISCOVERY, F. ADRANGI, 10 MINUTES ------------------------------------------------ o http://wwww.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-01.txt o Draft to meet 3GPP requirements. This focuses specifically on network discovery. Version -01. o Main changes: - Describes a solution for mediating network discovery only, references 2486bis for network selection part - Draft was shortened and restructured for readability - There was an implementation of this draft, provides proof-of-concept - Recently got several comments from bernard. Some resolved in 01, but there remain some issues to be resolved o Outstanding issues: - Problem should be referred to as "identity selection hint" instead of "mediating network discovery" - Coexistence of mediating network information with existing proprietary info in the IdentityRequest. We already have addressed that, but haven't posted draft yet. - Error handling and recovery for cases where the access network cannot route the AAA traffic (e.g., supplicant did not provide decoration). - Bug in definition of "realmlist" ABNF Main problem is the first one: changing name is going to require rewording work throughout the draft. That's something we can discuss and decide how to proceed. Need to meet release deadlines for 3GPP release 6 (december) We need to get this done by September Want to resolve all open issues by August 15 Submit for final review on the mailing list [Someone]: First bullet is right on, identity selection is part of the process of constructing an NAI. [Farid]: Yeah. That's our plan to reword and make it more generic. [Bernard]: Logic is that 802.11 has gone over very carefully to make sure there is no conflict with what they are doing, want to make sure there is no impact on what they are specifying. [Farid]: Will not impact the underlying protocol this is more like presentation and positioning in the draft. [Bernard]: Only comment is that this draft should be sent to 802.11. 7. EAP METHODS PUBLICATION PROCESS, CHAIRS, 5 MINUTES ----------------------------------------------------- o Goal: Review the current rules for EAP method publication. o History: In 2284, there were no IANA considerations (oops). It was free for everyone to define what they wanted. In 3748 there were well define rules. In discussing what is going on, many of these proposals have been around for years. Some already have a type code allocation done prior to adoption of new rules. Any new methods have to comply with the rules. o Case 1: old methods. IANA acted on FCFS basis No spec required, no IETF approval A lot of vendor-specific methods A lot of them no longer in use. o Case 2: leftovers from old times. EAP methods currently in process, they have a type number. If this is the situation, the regular IETF rules apply. In order to publish an IETF document you can do that Information, document your protocols as long as you are not trying to circumvent process in competition with a WG. If it is a standards-track item, you need to have an AD sponsor or WG draft. In any case, regardless of EAP methods, other IETF rules have to be obeyed e.g., TLS extension must be standards track. o Case 3: New rules in 3748. You can do vendor-specific methods, or request Expert Review. o Case 4: standards track methods. WG items or AD sponsored. Some question as whether the EAP WG should do this Some interest, ADs somewhat positive. We need some high quality contributions to move forward We have some good-quality proposals in this space. We need people willing to work on these documents to completion We need a WG and a world who cares about new methods and would actually use the results [Someone]: Document the requirements of standard EAP methods? [Bernard]: We've asked various SDOs for their requirements. Sometimes, they say, "WLAN works for us to". 3GPP said "we have our own requirements". IESG says it's not one size fits all, so it's not just one Proposed Standard. It's ok to let each group define their own requirements. That's the reason we have the security claims in 3748. We don't have any list of things that a PS must do, it must authenticate and derive a key in a reasonably defensible manner. [John Vollbrecht]: one issue was whether there would be a "MUST implement" method for e.g., testing [Jari]: We can have that disussion when we have reasonable methods. [Bernard]: What came up was that we were requested by 802.11 to change the mandatory to implement method in 3748. We decided not to do that. Other SDOs are free to set their own requirements. [Jari]: If you have a method you believe is worthy of standards track, it is your job to propose it and convince us. 8. AUTHENTICATE SERVICE IDENTITIES FOR EAP, PASI ERONEN, 10 MINUTES ------------------------------------------------------------------- o http://www.ietf.org/internet-drafts/draft-akko-eap-service-identity-auth-00.txt o Background: EAP does not have a concept of service (NAS) identity (identifier) Since there is no identity, it can't be authenticated. The "lying NAS" problem. When you look at the whole system, protocol has 3 parties, but no identity for NAS End result is that client knows it is talking to one NAS, but doesn't know which one If you compromise one NAS you can impersonate any other. o One approach: channel binding. Send an identifier inside some EAP-protected field; AAA server has to verify that node it is sending the MSK to actually owns this identifier. [Glenn Zorn]: Your trivial consequence I didn't understand. It's true that the client doesn't know the identity of the NAS, but what difference does it make? someone: if there's no underlying trust, the client only needs to know that it's getting service. [Pasi]: Right, the reason no one has tried to solve this yet is because the internal structure of the network is not visible to clients. [Glenn Zorn]: It's not possible for someone with no identity to impersonate someone with no identity. Although you've compromised a NAS, you cannot impersonate it *to the server*. [Bernard]: Conversation is between peer and server, so the only bad consequence would be some server impersonating another server. This is not an EAP vulnerability. [Someone]: Perhaps it's not the NAS identity but the network identity [Bernard]: No, server identity. It's a conversation about a server that distributes some keys that may then make its way to your network. [Pasi]: The client is interested in service identifier, not necessarily NAS identity: - SSID - BSSID - AP IP address - AP DNS name - Human readable "network name" Depends on what you want to do. [Someone]: Also depends on when. If it's subnet, you're already attached. [Bernard]: There's identity of NAS for purpose of deriving a key. When you go to another NAS you need to know what keys it might have. Then theres the service identity which is something else. Some of the identities do or do not identify an authenticator (NAS) independent of ports, others are dependent on ports. [Someone]: Why not separate this into AAA group vs. EAP requirements for key mobility. [Pasi]: From client viewpoint, it is trying to authenticate some of these identifiers someone: all you have is a secure EAP transport. You are trusting the chain. [Bernard]: We are getting confused. When you make a claim of identity, the subsequent exchange confirms the identity. Service identifiers are different. You can confirm them but not solve the lying NAS problem. [Hannes]: You find some of those things already in some EAP methods. That may be the solution we want to go to. [Pasi]: So identifiers may identify larger part of the network bigger than a NAS This draft defines some example identifiers, how to embed them in lower layers. Example: Identifiers for 802.11. This prevents IKEv2 gw from impersonating an AP. [Glenn Zorn]: Probably also the lack of an antenna. [Pasi]: We assume one NAS might be compromised, this prevents that. Idea is to do it the same way for all EAP methods. [Someone]: this provides the inner secure channel. [Jari]: This defines an extensible data model and some initial parameters. It could be used for carrying any kind of information. [Somebody]: Same trouble that Glenn had understanding... if you have mutual auth with a server, and server vouches for device, isn't that good enough. If I go to a payphone, do I want to authenticate model of payphone? It's the carrier that I have the relationship, not the piece of hardware. Providers can switch hardware on short notice, how would i judge that? [Pasi]: Example for 802.11i is that this AP is allowed to use this SSID. If you are not interested in the internal structure of the network, then this is not useful to you. But, if you are using EAP for WLAN and also for some other credentials for VPN, you don't want APs to impersonate the IKE gw. [Someone]: in the payphone, there is inherent trust in the infrastructure. In wireless, that trust is no longer there. [Glenn Zorn]: So lemme see... in the model of the attack that you're trying to fight, the AP has been compromised. You don't trust AP/NAS to tell you who he is. Who is vouching for this identity? If this NAS is part of the network, he has impersonated himself or someone else to the AAA server. [Bernard]: authentication is not the issue, it is service parameters [Pasi]: You have a NAS that has been compromised but gone bad, the AAA server has no way to know that. [Someone]: In a larger network, if you have partitions, e.g., Europe and US where SSIDs are shared, you need to make a client decision. Could this be used to help? [Pasi]: No, not easily. What next? Comment welcome. Lying NAS problem has been discussed in a lot of EAP keying discussions. [Jari]: The consensus was that this problem was not important to solve in 3748, but it is still important for some people and some situations. [Bernard]: with network selection where money is on the line, then this may become an issue. [Jari]: Two questions: 1. do you need the function? 2. if yes, then different ways of doing it. Right now tunneling methods have their own attributes for carrying information like this. That is problematic in the sense that different EAP methods look at information in different ways, more code, less interoperability. If tied to specific link layers, then methods might start to become link-specific. Should we have something general? [Glenn Zorn]: Pasi got interrupted... how do you trust the information that you get back in these AVPs, given that you only have a relationship with AAA server? AAA server can tell you who the NAS is, as far as he knows. NAS can tell you the same thing. Who is vouching for identity of NAS, and how does he know it? [Pasi]: AAA server is vouching and telling info to hte client. Client believes AAA server more than he trusts the NAS. [Bernard]: this is one of the key framework issues: [Someone]: NAS can have a different identity on client side vs. AAA server side [Bernard]: That is a part of key framework doc, should be discussed there. Theres a distinction between the identity and the key scope. When you give the key, it's for the NAS that's identified. There's a problem of key caching which is what the AAA server sees vs. client sees. What this leads us to believe is that people have not read the key framework draft as closely as possible. [John Vollbrecht]: Seems like you want some sort of little extension to EAP that you can tag on or not tag on [Jari]: almost like that, just an attribute [Someone]: as opposed to overloading something to get the same result [John Vollbrecht]: could think of it as a hunk of a script. [Joe]: I don't want to have EAP methods evaluate these conditions. Having an interface from an EAP method to the AAA server so someone else can do evaluation is better than put this in an EAP server. [Pasi]: That's the idea that the EAP method wouldn't use this, but because EAP server and AAA server are same box, that's implemetnation that IETF doesn't usually touch. [Joe]: There's separation of those two things in many of our documents [Glenn Zorn]: EAP documents says the EAP server and AAA server are not identical. [Pasi]: Right but interface is not specified in any IETF protocol. [Somone]: Assuming this is useful, it fits into general channel binding problem, shouldn't we have a generic solution for all channel binding solutions? [Pasi]: This is the generic channel binding problem. [Somone]: Then it's not just the identity. [Pasi]: In all the examples, parameters are identifiers, but you could use if for cost or whatever. 9. SHARED-KEY EAP METHODS, F. BERSANI, 10 MINS ---------------------------------------------- o http://wwww.ietf.org/internet-drafts/draft-bersani-eap-synthesis-sharedkeymethods-00.txt http://wwww.ietf.org/internet-drafts/draft-bersani-eap-psk-02.txt o Shared key methods and Updates on EAP PSK Overview of important EAP pre-shared key methods MD5 challenge is deprecated There have been many individual submissions, none given official WG status Point: we need to develop pre-shared key method We don't have any official WG doing EAP methods It's like a pizza without toppings Why special pepperoni preshared key topping? It is the simplest one. Before we do PKI, credentials, etc, we should have simple solution We want to make sure we have methods that work well and address some links out there Pre-shared keys seem to fit many deployments: My home network, Small businesses What do we want to do? Jaris' presentation is good news Want to help o Trying to start the joint work. Defining what EAP methods should do Do we want pre-shared key or password methods? Password is a weak pre-shared key. There are different techniques zero-knowledge password protocols are very IPR encumbered. Conclusion: Pre-shared key would be a good start. Passwords are a little more complicated. Lightweight: use only symmetric cryptography? Conclusion: Yes, although some phones out there run TLS today [Someone]: Can you clarify your definition of the difference between password and pre-shared keys? [Florent Bersani]: Depends on resources of hacker. A pre-shared key is not obtainable by brute-force attacks now or in a few years. [Someone]: You mean pre-shared key is used in some algorithm rather than just a raw password? [Bersani]: If you use PSK with some 128 bit key, then it is not attackable by dictionary attacks or other means. If you use a password, then the PSK cryptography cannot protect you. 0-knowledge crypto can protect you (e.g., Bellovin and Merit) in the case of passwords. Standalone: why develop methods that accommodate various types of credentials: isn't it redundant with EAP? Maybe add pre-shared key to TLS or other "monolithic" method? [Hannes]: Big in terms of large in code size. If you use EAP-PSK vs. TLS bits on wire might not be a big difference. [Bersani]: True, if we develop EAP methods somewhere, will we develop a big method or separate method that can handle different situations. [Someone]: The two approaches are not exclusive. [Florent Bersani]: Available quickly: people don't want to wait anymore (it's been a long time). IPR free Secure o EAP PSK Status: - proposed open solution - draft-03 - free implemetnations at http://perso.rd.francetelecom.fr/bersani/ Next steps - slightly re-work based on feedback from cryptographers - New version -04 in Sep Then, after security review - go informational? - Will there be a standardizaiton effort? Some more points... - EAP-PSK was designed to be quick - Some extensions are possible - Key management can be added (updating keys, etc) - EAP-PSK includes no options for its security when you claim security, you need to say which setting of options - EAP-PSK always perform mutual authentication some people argue about mutual auth vs. authenticated key exchange 10. EAP PAX, T. CLANCY, 10 MINS ------------------------------- o http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-00.txt o Similar to PSK: - Bootstrap key authentication using simple credentials like 4-digit PIN - Keep it simple - Provide support for key management - Provable security o PAX is 2 separate protocols - PAX auth - PAX update o PAX auth is a 1 round HMAC-based client auth - Optional server-side cert for identity protection - Secure under standard model o PAX update is a 2 round mutual auth diffie-hellman protocol - Only used when key update is required - Optional server-side certs provides identity protection and security against deictionary - Secure under the RO model o PAX auth message flow - Server sends nonce + cert, client sends another nonce ahnd HMAC, can encrypt with server's public key - DH exponent echanges - Acks - Key derivation - Cryptographic primitives: Extensible. Currently supported: HMAC: HMCA-SHA1-128 DH: 3072-bit MODP Group 2048 bit public key o Other work: - EKE, SPEKE, SRP: auth schemes secure against dictionary attacks; IPR issues - TTLS: slow; require public key operations for every authentication - PEAP: cumbersome; provisioning mode not secured against dictionary attacks - PSK: no support for passwords; no key management o Conclusion: Looking for feedback [Glenn Zorn]: TTLS slow & requires public key...? In order to protect against dictionary attacks, don't you need public key? [Clancy]: only on the first time. [Glenn Zorn]: but update is a D-H. [Clancy]: if you want to call D-H public key, then yes... but no certs. [Someone]: PEAP provisioning mode not secure...? PEAPv2 supports 2 modes, can use anonymous D-H. [Joe]: EAP-FAST has a provisioning mode defined very similar to this. [Hannes]: EAP-IKEv2 provides same capability but with different names [Joe]: Claim of mutual authentication, looking at the protocol, it didn't seem that you actually had. [Clancy]: only claimed mutual auth for the update protocol [Bersani]: Do you have an implementation? [Clancy]: Working on it, working on open RADIUS and 1x implementation 11. EAP TTLS, P. FUNK, 10 MINS ------------------------------ o http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-05.txt o Version 1 of EAP-TTLS Version field defined in very first byte, similar to what other tunnel protocols do. Version negotiated by client telling what he can support. New features of protocol are for precluding mitm attack described by key binding attack (draft abandoned, but attack still valid) Idea is that you have to bind session keys inside the tunnel with the keys that are generated outside the tunnel so that you can't inject an MS-CHAP inside a tunnel from an unsuspecting user who's not using a tunnel. Old version did not have a cryptographic confirmation that everything went ok. Now it is so you can't have truncation attacks. Normally, the AVPs occur after the TLS handshake. We want to create an extension of TLS to allow AVPs within the handshake. So, you can use it there and then the data phase can be used for something else (e.g., HTTP) - TLS "InnerApplication" Extension (TLS/IA) - TLS handshake is multi-phase. - Two phases: Initial phase (handshake) ends in a "phase finish" message Application phase (carries AVPs) ends in ordinary finish message - Master key is permuted in every phase The one generated in the handshake is not the final one for generation of EAP MSKs - Data phase doesn't exist in EAP TTLS but would in HTTP [Someone]: What is the benefit? [Paul]: One advantage is that there is a more natural way to bind inner session keys in a TLS kind of way. What we really want is an extension of TLS that can do EAP. Now you can have many protocols that utilize it to do authentication. Becomes more general than just an EAP method. Session Key binding: - Inner session keys are mixed into master key and: Confirmed by finished message mixed into outer session keys (e.g., MPPE keys) - TLS master secret permutation Initial master key is derived as usual during initial handshake phase Master key is permuted at the end of each applicati onphase PRF is applied to create 48-octet vector Any inner session keys developed during this phase are arithmetically added to vector Result is new master key Master key at end of final phase is actual master key for session Advantage comes when hacker has cracked the server private key. In that case, he would be able to decrypt master key and all the data - Success/Failure confirmation: - Handshake message confirmation - Each phase finished or finished message confirms - handshake messages in current and all previous handshake phases - Inner authentication confirmation . Success is signalled by exchange of Finished message . Failure is signalled by TLS failure alert Other uses of TLS/IA - AVPs can be used for all different purposes (key exchange, provisioning VPNs, etc) o IETF Plans - Split into 3 drafts . EAP-TTLS v0, which is deployed and has several interoperable implementations . TLS/IA, the Inner Application extension to TLS . EAP TTLS v1, specified as an encapsulation of TLS/IA - Submit each draft for RFC proposed standard status (weather permitting) |