IETF 102 - EMU Working group Agenda Friday, 20 July 2018 Morning Session I 0930-1130 Minutes taker: Zhen Cao Jabber: Rahul Jadhav ----------------------------------------------------- 1. Using EAP-TLS with TLS 1.3 draft-ietf-emu-eap-tls13-00 John: Jouni implemented this draft and found the NewSessionTicket was inconvenient Darshak: Point is well taken. We should not restrict NewSessionTicket. The server could signal with EAP that it will send other things. Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand exactly which state it is, not an EAP task but method specific. Reception of properly encrypted message should take precedence over EAP-Success. At every point, important to know if you are in continuing, success or failed state. It has nothing to do with EAP. Jim Schaad: Have the server send an encrypted content message. Will add latency. Bernard: That's how EAP-TLS does currently with Finish message. Darshak: Does sending this encrypted content message indicate that no more TLS messages will be sent. Jim: TLS content message (a record) to know when you are done and make transition. That takes the place of the TLS Finish message. Hannes: Differenced to other EAP messages. Before there were clear definitions. What is finished actually? NewSessionTicket is still a handshake. Cram it in earlier in the exchange. Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you restricting it in EAP? Eric: You want to know that there will be no more TLS messages? Profile TLS to say don't do this. None of the Post-Handshake messages are needed. John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS. Bernard: If you use this and it determines cryptographic state, then you have just introduced a vulnerability. Don't do that. John: Piggyback Newsessionticket on the EAP-SUCCESS Bernard: Not a good idea. John: Key derivation with exporter : what's the best tradeoff ? Mohit: I should be able to update openssl and EAP should magically update to the new TLS version. But if the EAP is aware of the TLS version, then a lot of these problems will be simplified. Bernard: Problem with sessionid. Bunch of EAP methods use different prefixes. Missing prefix. Mohit: Its MethodId. Bernard: Uniqueness of sessionid. You should have prefix in sessionid. Hannes: how easy it is to get the randoms in diff TLS stacks, have access to source code of EAP method, and reuse the implementation. Joe: Moving forward we won't have access to master secret. We are moving towards using exporters. IV and sessionID perhaps more publicly available values. John: IVs are now secret in protocols. JABBER QUESTION: from Alan. Eric: Not do old version. Please use exporter. John: Use exporter. Will add prefix to sessionID. Joe: Do we know who is working on implementations. Alan/Jouni? John: We have a project but we are currently doing EAP-AKA. Don't have EAP-TLS timeline yet. ----------------------------------------------------- 2. Large Certificates in EAP protocols Eric: ECC public key size compressed vs. uncompressed. Hannes: May be you don't want to have endlessly long hierarchy. Reduce the transmission inf overhead by use of cache info and client certificate URI. John: Not using PKI or reducing number of CAs could be a point that could be made in the draft. Jari: Document has good options. Seems of protocol discussion. There is also operational issues. Don't do deep hierarchy if its problematic. Bernard: EAP-TLS1.2 very commonly deployed in large organization, you cannot reorganize the organizational hierarchy. Darshak: Using TLS cached information exchange still is a chicken and egg problem. Bernard: Opportunity to fix a lot of things with TLS 1.3. Going back and telling people to change code is not likely to succeed. I don't think it can do harm. It is weird that it is very draft. Eric: Charter item is primarily about guidance, which is valuable. There 3 settings: people who already have deployed not change anything, the people who are not going to change code. But those that are changing code should already move TLS 1.3. Hannes: Sometime the exchange does not work. We are not talking about this never works. Once you get through the exchange and cache them. This is not web environment where you randomly to talk to server. complicated multihop AAA is when things break. And that is when you should have things cached. Darshak: Fair guidance. A lot of this happen based on the size of the EAP packet. Probably include that in guidance as well. Mohit: If it does complete because of DoS protection in AP. Not able to use the cache (experience from Hackathon) Hannes: Then the recommendation should also be to reconfigure/change the APs. RSA key sized that resist post-quantum etc. You can't have everything. John: Would there be a security issue from caching cert chain from non-successful handshakes. Eric: Maybe you could do. I take your point why this would not be a problem. But this is not how we rool and not sure if really need this. Some analysis on why its okay. Sean: PKI provides footguns. We can provide example of what not to do. Pick shorter OIDs. I can volunteer to help you with that. ----------------------------------------------------- 3. Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') draft-ietf-emu-rfc5448bis-01 Identifier usage: 5G has two distinct identifiers SUPI and SUCI. When network begins in 5G use SUPI for key generation, otherwise behave as RFC5448. Ongoing coordination with 3GPP R15 Specs John: Have done a thorough review and no technical changes needed. Very much ready but will do the review again. Security considerations section: demands on privacy and eavesdropping issues higher. More text needed. What happens from SUPI is not used. Jari: Thanks. Will add to security consideration. This is planned to be part of 1st release of 5G. I think this should go forward as soon as possible. We should initiate last call after update to the security considerations. Sean: About timing. Fast months: 6 months, year. Usually it takes 3 years to get anything done. Jari: Takes longer time for new things. This is a bis. Sean: I want to help. Let me know. Joe: When we get an updated security considerations section. We could last call it. There is little risk if 3GPP decides we are going to make changes. Then there is problem. Jari: I think 3GPP is ahead of us. I would like them to reference this 3GPP. We are running project to implement this. Joe: If we can identify implementations for EAP-TLS and EAP-AKA', that would be good. ----------------------------------------------------- 3. EAP-AKA’ PFS draft-arkko-eap-aka-pfs-02 Planned for 5G Phrase 2 Hannes: DH Exchange, a concern of DOS attack. Can get server to do work. Jari: Initiated from the network side. First request from server with DH key. So attack is constrained. Hannes: EAP methods are not only used for classical network authentication but also fro VPN access. Where it is initiated by the client. Jari: All cases where I am aware, the client initiates connection but it is the VPN box that asks for authentication. John: EAP-AKA in 5G with encrypted SUCI the server will always use asymmetric crypto. Adding this is 2 PK operations instead of one and not an order of magnitude more. Russ: Without this DH, where is the auth available for AKA'. Can you validate before doing additional DH. If you are spoofed, then no point of DH. If you can order that, it would eliminate thing that Hannes. Jari: Seems doable. Want to have backwards compatibility. If not done. Russ: Send all but the order in which you validate. Max: is the public key is the same that encrypts the SUCI. jari: We have our own exchange. And use public keys. Russ: I assumed that you were using ephemeral DH Jari : right John: This is real-world problem. IETF BCP says we should do. Support to go forward. Joe: poll the support in the room, and clear for support. Against working on this? No one. Will call for adoption on the list. Is on our charter. There will be discussion of the details. ----------------------------------------------------- 5. ANIMA and BRSKI topics (if there is time) Jabber (Alan DeKok): Who implements TEAP? IIRC, it's almost no one . that does make this more difficult. The other question is if the MASA doesn't trust network 1, why is it doing an 802.1X exchange with it? Perhaps this is more "not the right network" than "not trusted". I'm not familiar with BRSKI Owen: Even on wired network. Pledge does not know whether to trust 802.1x server certificate or not. Nancy: MASA would not be in 802.1x path. TEAP is not used predominantly. Not used because EAP-FAST is not standard. They are pretty much the same state machine. Subir: How is it different today when you have AAA infrastructure. Owen: You are expecting that the network is well-behaved and reject the device. Subir: If AAA is there. This is not adding. I understand BRSKI is not adding anything. It is already solved with AAA. I will not get IP address if not right network. Owen: Making assumption that network well-behaved. Hannes: Big issue. Under cover of BRSKI came up with a new network attachment procedure. The device does not have except. Wishy washy claims. Same issue as Subir. Trying to change the way AAA works. The claim is that you need to talk to the manufacturer for privacy reasons. Instead talk to MASA. Very few people pay attention to ANIMA. We have bought into that concept that this is a good idea of the alternative approach of network attachment. Owen: You want to trust on first use. I don't need any pre-provisioned trust anchors? Hannes: I want to have an honest conversation about what we are trying to accomplish with this alternative network access authentication infrastructure. When I read BRSKI I see problems being state. Later the same problems being resolved using things that are solutions you complained about and found problems in. You complain that it is difficult to put manufacturer certificates on the device. Later you use them. You claim about privacy implications of running exchange to the manufacturing AAA server. Later for security reasons you still have to interact with the manufacturer. Whole thing is marketing nonsense. Subir: If I deploy AAA infra? Do I need this? Good to have a section if I already have AAA infra, what is the benefit? Owen: You are asking what is the benefit of BRSKI and not what is the benefit of putting it here. Subir: I don't know the trust network. This gives benefit. With backend AAA infra it already happens today. I am not given IP address or any resource. Brian: BRSKI is allowing you to the point where you could authenticate the network instead of moving on. You could move on all day. This is getting you to the point where you are provisioned with credentials. Subir: If MASA says network B is network. That will fail right? Brian: Little weirdness here in slide. Alway enterprises decision whether to trust a device or not. MASA is helping it determine. There are cases where enterprise use MASA for something more. Enterprise can decide. Nancy: BRSKI. Help endpoint know that that network infrastructure is to be trusted. You talk about AAA infra. The diff here is that the AAA infra does not have the right identity which is what BRSKI is trying to help. It is trying to provision the right identity. Subir: There are other ways to do that. NEtwork discovery with 802.11u. Nancy: Chicken and egg problem we are attempting to solve with BRSKI. 11u is the other aspect of how to do signaling. WE could use DPP 11u. We could use extensions. That's separate piece. Can embed on WiFI while you are in that 802.1x channel. Max: This is provisioning mechanism. This is not. That comes as a good benefit afterward. Totally support that. TEAP already supports. Maybe have more general approach for provisioning method. Maybe a generic EAP method for provisioning. Using TLVs rather than own method. Seems easier method. However, problem that TEAP is not implemented. However you could do a separate method and combine that with any existing tunneling method. Through other already deployed methods. Then you don't have to implement a new EAP method. Owen: TLVs are simpler. Working assumption that we are going to ship EAP-TEAP quickly. Nancy: Could be its own EAP method. by establishing that TLS tunnel. It makes security and privacy considerations would be more complex if it is was a standalone method. Max: Understand your point. There is an opportunity to have generic provisioning. Nancy: That is fine. If that is what group wants, we could update the draft. Security is improved when you run. --- From Jabber --- Henry B Hotz Maybe not possible to improve, but it seems like there are steps where the device is trusting things it doesn't yet know it can/should trust. How does it work (properly fail) if Network A is evil? Alan DeKok but if 802.1X succeeds, then the network is trusted. If the MASA later rejects the network, it means that the network is known and trusted, but not the right network if network 1 isn't trusted, why does 802.1X succeed? Why would the device trust BSRKI data sent over an untrusted 802.1X configuration? Henry B Hotz Suppose Network A and the MASA that Network A connects the device to are both evil? Henry B Hotz Of course the device may not have any value to an attacker if it knows that little. Simplifying: suppose the attack target is the device, not the network? Alan DeKok Hmm... I guess this presumes TEAP provisioning, which wasn't clear from the slides. I'll withdraw my questions... --- END From Jabber --- Owen: Completes 802.1x. MASA has not issued voucher. It will be device side logic. I had to trust on first use. Mohit: No hat. I have the same question. Why did 802.1x succeeds if it is not the right network. Nancy: It doesn't. Mohit: Why does it get DHCP, IP address. That is how 802.1x. You haven't solved the problem to connect to the right SSID. You assume that this could be the right SSID. Which is fine. And now you connect and you succeed. Owen: That is the problem we are trying to solve. You unbox a device and it sees 20 network and it does not know which one to connect. Mohit: So it tries. So why does it succeed? Joe: Not in charter and cut the mic line; Mohit: How do I know which manufacturer to send it. Owen: Based on IdevID. Mohit: Now 802.1x all Authenticator/AP which server to talk. Now TEAP server should know which BRSKI registrar to talk to. Setup security association to registrar of different manufacturer. Owen: Registrar will be on prem. IdevID will tell Mohit: Additional configuration to associate with different manufacturers. Setup AP, server and then server to different MASA server. Sean: Having lots of flashbacks from when I was an AD with all EAP Fast and TEAP and TTLS. TEAP is a protocol that is standardized by the IETF that went through the working group process. It was bloody as hell. At the end of the day, the proponents are doing the right thing. BRSKI is a working group item for another working group. And they are asking how this could be done. This is more than Cisco wants to do this. There is more than Cisco people in that room so I think we should consider that. You can question if it is used or not but at least it is being worked on at the IETF. Hannes: Sean tricky issue. I have complained about in the past. There were several different provisioning protocols being worked upon in the IETF concurrently. It was not just ANIMA but Netconf with 0 touch. Lots of fancy names. It gives the impression that you magically solve some really hard problem. No configuration and everything just works out of the box. Whereas in reality we just move the problems around. Instead of regular authentication exchange to the AAA all the way to the manufacturer we are now setting up the backend infra with vouchers etc. which looked like research efforts with whatever the other ANIMA dynamic network bootstrapping was. Nobody paid attention to that. Now we are looking into this. What is this actually. Oh My God. All these claims at the beginning and what it does and what the problems are. I feel that I mislead. I am going to write this up. Joe: Issue with BRSKI and those need to be taken up with. Eric: purpose of the presentation? What is the purpose the presentation. You want adoption. As I recall it would be out-of-charter so does this require re-charter. My question: bunch of work going on already. Would you be able to take on this work? May not even viable for WG discussion?? Joe: Difficult to tell right now. We are just bring on. Eric: Just chartered a month ago. Joe: Most of the work in charter is straight foward. With AKA PFS more work and analysis is needed. My concern here is just making sure that we don't have a common idea of what BRSKI is, or what these other things are. That's going to be difficult until we get that. Eric: Figuring out what is the sensible way to move forward. People can yell each other a lot longer then. Jari: Not sure fully understand. Checking my mental model. You have a very particular way of doing things. Bootstrap a device. Talk to infrastructure and infra puts you in sandbox and you can do enrollment and after completion you can do the proper thing. That seems a fine thing at the architecture level. You still have many question. What level is right. Doing it at the EAP level. Doing in a tunnel. Lots of choices. Following up what Hannes. You have a problem. You still have to solve the problem even if you move it to this sandbox stage. The sandbox and device still needs to have an association. That should be recognized that is a necessary step. Owen: When device bootstraps with IdevID it is put in some kind of sandbox network segment where it can continue provisioning. Jari: In theory, you might do a regular attachment on open sandbox SSID and then just do regular IP with web exchange with somebody. you wouldn't have to anything at EAP level. Owen: BRSKI exactly covers that kind of flow. Connect to fallblack registrar in the cloud. BRSKI supports multiple types of flow. Max: Provisioning thing for 802.1x. Could be useful in some use cases (cellular network)? We might do re-charter. This could be initial work. I would like to see re-charter that looks at provisioning with EAP. Important work. Brain: Reflect the main contribution is removing the whitebox. It is handling withing 802.1x. The slide with complex device side workflow. Zhen: Need a use case draft, well documented first Owen: We can make some edits to the draft. Alan: I owe a draft for fast re-auth. Joe: not in charter right now; BRSKI is ANIMA. need to talk to ANIMA chairs. See where they are at. Not just an EAP method. It is more than that. It is an architecture. Beyond the original charter. If there is or consensus in the IETF to move towards this architecture then that could be withing our scope. Max: I don't think it is related to architecture. Underlines an architecture but the architecture is not in scope of the work. Ask chairs if we can recharter adding this type of work. Joe: I think there is an architectural change. It is not for this group to decide that change or not. We need to make sure. I don't want to spend a lot of time and argue a long time about what we are going to do here and then find out that ANIMA is not pursuing this direction. Or find out that there is not consensus in the IETF to do this. Hannes: Elaborate on architectural change. Previously sandbox was at application layer with CoAP/HTTP proxy. That was used locally. That is moving to lower layers. We are trying to make an optimization. Also checked IPR situation. Worthwhile to consider. Several IPR filed on the BRSKI stuff. Jari: Bootstrapping is interesting after finishing the current work; If we were to do. This WG cannot be responsible for the architecture. We would still have to be convinced that we need a sandbox at our layer and that is a sensible architecture. And about mobile networks can benefit from more generic bootstrapping. There are many solutions outside EAP. You have hardwareless SIM cards and also some deployment. And not a space where nothing has been done in the past. That should be kept in mind. Joe: Can have some discussion on the list although we really need to make our other work items a priority. But if this becomes a distraction then we will have to take it off. Next steps is for chairs to sync up with ANIMA and see where they are at and then talk with our AD and amongst ourselves and come back to the list. Max: What is criteria to define whether distraction or not not and don't care about other things. Joe: Right now it is not in charter. If it becomes a contentions discussion and if people are spending more time on this than chartered items then that become a problem. Max: IS re-charter right now. Joe: Right now we are not re-charting. We are going to look at what will be involved in re-charting and why we would re-charter. -----------------------------------------------------