EAP Method Update (EMU) Minutes Meeting : IETF76, Monday November 9, 2009, 1300-1500 Location: Hiroshima, Cattleya East Chairs : Joseph Salowey (jsalowey@cisco.com), Alan DeKok (aland@freeradius.org) Minutes : Paul Hoffman (paul.hoffman@vpnc.org), Bernard Aboba (bernard_aboba@hotmail.com), Nancy Cam-Winget (ncamwing@cisco.com) Version : 0.5 ============================================================== Agenda A. Administrivia B. Tunnel Requirements C. Channel Binding D. ITU-T X.1034 Liaison Statement E. Unauthenticated Emergency Service F. EAP Session Policy G. Biometric Authentication (EAP-BIO) ============================================================= A. Administrivia Meeting scribes - Paul Hoffman, Nancy Cam-Winget - Jabber - Bernard Aboba B. Tunnel Requirements draft-ietf-emu-eaptunnel-req-04.txt (Joe Salowey) Chair (Joe salowey): Alan Dekok had lots of comments Sent to list. How many people have read -04? Two... How many people have seen Alan's email? One person has read through both Steve Hanna: Suggest that we take it back to the list Joe: Are any other people planning to do new reviews? Dan Harkins: After reading this, I'm disappointed. I was hoping that this document would provide useful capabilities. It is drawing requirements for existing EAP methods. The problems that bother me the most, is requirements language evaluating EAP methods for these requirements. It's inappropriate to instruct the WG how to decide... that whole section 4.1.2 should be deleted. An existing method should be preferred over a new method. Some people may prefer that... but it's inappropriate to tell people how they should hum. You're going to be doing a consensus call... it seems odd to discourage new work. Joe: Had earlier discussion, and this was the consensus of what we wanted to encourage Steve: This says "should be preferred", not "must happen" Joe: It's not saying you couldn't come up with something new if that was WG consensus. Dan: My other comment is that each EAP method has to do its own fragmentation, it's own identity exchange... it seems like a poor architectural design... we are repeating this with ciphersuite negotiation and protected tunnels. EAP GSK rolls its own protected data exchange. This is really bad. It would be better if this document provided a generic way to do protected data exchange with existing methods.... This document is so geared towards existing deployed EAP methods that we will lose this. Pasi Eronen: All the methods should allow methods to do that. TLS gets us all this Joe: Is there text in there now that restricts this? The work item is very focused on doing a password authentication that we had talked about for a long time. Actions: Dan Harkins and Nancy Cam-Winget said they will send reviews to the list. C. Channel Binding draft-ietf-emu-chbind-04.txt (Joe Salowey on behalf of Katrin Hoeper) Joe: We're up to revision 4. This has been done to address comments raised on the list. Joe: Trying to narrow the scope down to what it is trying to do... getting rid of attributes that were inaccurate or not necessary. Joe: It removed text discussing authorization and open ended policy discussions..... Joe: We haven't eliminated the need to do a comparison against authoritative data... it's just not referred to as policy comparisions. Joe: Removes some text around setup of the local database... attributes such as the IEEE 802.11s attributes have been removed since the WG went in a different direction? Joe: How many people have reviewed -04? Noone. Can we get volunteers to review it? Joe: We will start working group last call after the IETF. Actions: Chairs to request WGLC D. ITU-T X.1034 Liaison Statement: https://datatracker.ietf.org/liason/598 has been posted for comment request. Deadline is to provide comments by March 31, 2010 Bernard Aboba: I looked at it. It is slightly better Hannes: discusses this group extending EAP in the belief that it would address requirements but in the end, the requirements were not met. Concludes that they were looking at the wrong methods. Joe: Anyone want to read this document? Joe: Let it be noted that Dan Harkins will review it! Joe: We will go the list as well. Glen Zorn: Is this a revision of the same nonsense they sent the last time? Joe: yes. Joe: If you are interested, you can take a look and see if it is improved.... Joe: Any other comments? Bernard: I have a comment. Can't we just tell them to read NIST 800-120? Actions: Chairs send request to review to list. E. Unauthenticated Emergency Service http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-06.txt (Dirk Kroeselberg) There are countries that mandate that you can still make emergency calls without authentication, such as SIM-less calls. PSAPs receiving these calls don't like it at all... So we added a section to the draft to describe different possibilities in use... how to enter the network... it doesn't possess a subscription so normally it wouldn't be allowed.... The presentation focuses on the network aspect.... You may have an emergency subscription with the VOIP system... if you are in the hotel how do you get access for an emergency call... now there is no way to do that... but it will become more important. The goal is to give guidance on these scenarios.... the new section talks about network entry. The target is to provide an overview of what is possible today and to give a recommendation... . So in general there are two options for indications that this is for emergency purposes... some lower layer indications. If you look at WiMAX/WiFi you can add TLVs or bits to the wireless MAC layer... or you can try and enter the network in an unauthenticated mode, but there are networks that don't allow that. For example, you can't bring up an unprotected WiMAX air interface. So another way is to use EAP in some way... can choose a special NAI, either with decoration (in WiMAX, mode=2), or you could choose the MAC address, or you can pick an nai like "sos@example.com" or "sos@emergency.com" or something like that. It needs to be specified somehow. Second alternative is to think about the EAP method itself. It has been discussed, to define a dedicated EAP emergency method that is non-authenticating. Or maybe you can reuse an existing method. Or you can use an existing method and use an implicit indication... for example if the client does not present a certificate in a TLS method then it is implicitly asking for non-authenticated access... this can be done in WiMAX by sending the device certificate only, but not the subscriber credentials. Joe: Would this indicate an emergency or just that the client didn't want to do authentication? Dirk: It could also mean that you want to do initial subscription (that is how it works in WiMAX). This is not sufficient, perhaps not a good example. In WiMAX they do decoration. This is the overview of the approaches in the draft. Dirk: Does RFC 5216 allow client authenticated access? Bernard: yes Joe: Is emergency access always unauthenticated? Dirk: No. Hannes Tschofenig: The nice thing about an emergency EAP method you can use procedures like hot lining with standard attributes. Joe: If you supported authenticated and unauthenticated access for emergency calls... for authenticated access you could use EAP AKA, for unauthenticated, something else.... Bernard: Why isn't this determined by the NAI? You can do anonymous access anyway (e.g. anonymous@domain), right? Dirk: In general, you will end up with different methods for regular entry and emergency... unless you always use EAP-TLS in which case it is simple. Joe: Do you need to know when it is authenticated that it is an emergency call? Dirk: In the authenticated case, you need indication to prioritize.... Bernard: To prioritize what? SIP signalling can handle this already! Dirk: This is encouraging people to read Section 6 and give feedback. Does this group think there is anything that can be standardized? Joe: Comments should be sent to the draft authors, the ECRIT list, or this EMU list. Joe: It's hard to say if there is something to standardize... it would be advantageous if there was some common way to signal this.... Glen: There is probably something here to be standardized. It would be good if emergency calls were handled in the same way, authenticated or unauthenticated. Because otherwise you'll end up like right now. The big problem is that emergency networks are different depending on what country you're in. I'd like to avoid the same kind of issue with this kind of emergency call. If you had a heart attack right now, what number would you dial? Does anyone know? You would die! Dirk: would be good if comments to help identify what would need to be standardized Simon Mizikovsky: believes that there are different procedures already in existence, so what would happen if IETF tries to standardize it? Dirk: if we provide something, then its up to the companies to decide to provide it using this new method. Stephen McCann: mentions that if something does get standardized, 802.11 could look to leverage that work Actions: working group members read document and send comments to EMU and ECIT. F. EAP Session Policy draft-mccann-session-policy-framework-using-eap-00.txt (Stephen McCann) Stephen McCann: Still trying to work other whether or not they can even do this Simon: questions on policy enforcement at the INC, but is management by the AAA (asks the point in using ERP)? Where is the ERP going? Simon: when there’s a policy change, there is an oddity between the AAA and ERP? Not sure message 9 and 10 are needed. Not sure why ERP is needed to do enforcement? Stephen: reusing credentials during the EAP exchange for SIP too. Joe: these would just be attributes carried through Stephen: right, didn’t realize ERP could go to the visiting network Simon: EAP can only be iniated by network only? Glen: its bidirectional so can be initiated in either side Dirk: discussion in dime, ERP needs to go back to the home network, this use case seems similar. Question is whether policy needs to be updated? Steve: sounds like can be done using ERP to visiting network. But it’s future work for me to investigate Pasi: ERP is a bad idea to move large XML documents Stephen: right, pushing the boundaries, but fundamentally, we think it will work Glen: how huge? Steve: could be up to 65K without compression…using SIP compression could reduce to an order of magnitude (6K) Pasi: even 6K could be bad. Comments that ERP may not have fragmentation, so poor candidate. Leif Johansson: could potentially use SAML, though some proof of concept would be needed Joe: in the context of EAP? Leif: yes, could be considered. As the goal is to pass authorization info (802.1X) via SAML. People have played around using bare tokens that are dereferenced to get attribute assertions. It’s a bit ugly, but it’s a way to get around the large data exchange. Stephen: comments its an interesting token Leif: depends on how long they need to persist. Don’t want to keep them too long. Hannes: reviewed this a while ago. Idea for this was to allow endpoint (and network) provide info about SIP session; e.g. changing IP address or codec…the usage of the current notification bring bandwidth issues? Stephen: right. If one of the change is on codec, it comes back to endpoint. Hannes: bandwidth constraint doesn’t come from the transport layer? So would it help to put that content into a lower layer, why? Stephen: fundamental feeling to get it down at lower layer in parallel would provide efficiencies. Hannes: this would only help in session independent policies Stephen: there are some aspects of dependent policies may be interesting too Hannes: if you do this in EAP, believes this could be worse due to non-existance of fragmentations. So a by-reference approach may be better? Though that wouldn’t help either Stephen: right, because there would be delay Leif: could talk to TNC folks as they were working on this too in the context of NEA Steve Hanna: can talk about this afterwards but the “federated TNC” is the document is the one to look at Actions: None at this time G. EAP-BIO draft-urien-kiennert-emu-bio-00.txt (Christophe Kiennert) Glen: Does not really certify the voluntary action of the user Christophe Kiennert: The room is strictly surveyed with cameras, so we can see if there is a gun to the head of the user. Glen: So the user can't stand outside the range of the camera. I didn't see a way to certify that the finger print didn't come to a dead finger. Christophe: Biometric readers have developed counter measures... so that most biometric methods can detect if the finger comes from a dead body. Glen: What about a recently severed finger? Christophe: Maybe the camera will detect the severed finger... or perhaps the policeman. Glen: Does this have something to do with this EAP method? Joe: One of the signatures is done by the reader... Glen: Shouldn't that be opaque to the method? Joe: It's part of the method. Glen: I'm trying to figure out what part of this is EAP and what part is science fiction, or interpol, or spy stuff... what is part of an actual protocol???? Joe: They first do a smartcard authentication, then they have some signed biometric data that they sent back. Glen: What I meant was... what in these security requirements come from the protocol.... what security problem is solved by the protocol?? Hannes: Couldn't many of these things be EAP method-independent? Joe: You'd use EAP to transport biometric specific data... but it could be any transport. Hannes: The TNC also carries lots of data unrelated to authentication. Simon: where does EAP authentication of SIM occur? Joe: it’s not SIM, its cert based using a smartcard Simon: is key transferred in Phase 1 Joe: no, Phase 1 is just for tunnel establishment Christophe:Phase 2 is the “inner method” Simon: so is key computed where? Joe: TTLS derives key from the tunnel; this diagram doesn’t quite indicate all the information appropriately Christophe:right. Simon: inside EAP-TTLS, there would be nested methods or could do…could include more challenges. When fingerprint is sent, could just use PAP with fingerprint as the password. Joe: would have to define some framing for this….it would be have to have a standard way of doing this. Hannes: or best common practice Simon: need to think about how to bind inner method to the outer tunnel. Is this already in TTLS? Joe: no, someone needs to do this Steve: there is a new draft for TTLS to show this Joe: in EAP-FAST there is something already defined for this to make sure there is a binding between the outer and inner methods Pascal Urien: the goal of this draft is to provide strong access to networks under some conditions where PKI may not be sufficient. This demo shows that it adds biometry…in airports today, it’s done using RFID. Other example is to do it thru blood pressure. Used TTLS because it’s a fine way to use PKI, but then use biometrics as a means to do the authentication, though this example uses fingerprint, it can use other things. The signature is there to show some authorization. With PKI, there’s a presumption of identity but the biometry provides stronger assurances that it’s the right identity. Joe: look at PKI for first, do you see something like AKA for using other credentials. Pascal: sure, it could be a mobile phone using an approved biometric reader. Need both to plug in to the network. Steve Hanna: This could be used in other scenarios as well. I think that some of the assumptins are not not necessary... it could be used without user authentication before hand, such as server-only authentication. I think you should look at cryptographic binding between inner and outer, which would be desirable. Steve Hanna: You solve the problem of "under duress" other than cameras... having two sets of credentials, such as "normal PIN" and "under DURESS" PIN you know it... you could give them access so they don't get shot, but could trigger a security alarm. Actions: None at this time Meeting closed at 14:45