Session Date/Time: 24 Jul 2026 09:30
[00:00:04] Peter Yee: Okay. Weird times. Alright. Alright,
[00:00:11] Joseph Salowey: folks. We're gonna get started here. This is the emu meeting. If somebody could do me a favor and shut the door so it's a little less distracting. Also, if we could get a notetaker.
[00:00:28] Alan DeKok: Alright. Yeah. If don't have
[00:00:32] Joseph Salowey: to catch very much because we have fabulous AI notetaking now, which is sometimes accurate.
[00:00:39] Matt (UK NCSC): Well,
[00:00:43] Joseph Salowey: But so catching important decisions and things like that is what we really need. Let's see. Do you have the who's got the control? Who's got the power? I can take the power. No. It's I have a strange interface here right now.
[00:01:15] Peter Yee: I can advance the slides. How's that?
[00:01:17] Joseph Salowey: Yeah. That that would be good. Okay. You probably have all seen the note well because it's Friday, not even the first meeting on Friday. So we'll leave it here for another ten or twelve seconds so that you can remember what all your obligations are. And do remember that all of the media that we use should be your your conduct and should be professional, and that includes the the chat the meeting chats. Sometimes people forget that those are record of your participation. Next slide, please. And if you're in the room today, please join with the on-site tool so that, we can get a wonderfully sized room next time as well. And, that's what will be used to manage the queue. Alright. Resources. Okay. Agenda. I think we're most way through the administrivia. We'll talk about TEAPv2. And then we have several nonworking group documents. Does anybody have anything to agenda bash? I think I'll turn it over to Peter so we can give maybe a little update of some of the existing working group documents right after this, but any other additions, subtractions from the current list of items. Alright, Peter.
[00:03:03] Peter Yee: Alright. Looking at the data tracker, active documents, obviously, TEAPv2 was just adopted. Adam will talk about that in the next. No changes on EAP TLS using PQC. We have two documents, PQC related for EAP aka prime, one hybrid, one pure. Those are still in working group last call. I'm I'm grateful to see that some reviews are starting to trickle in. This is very helpful. And I will try to get that closed out next week. EAP PPT, Bart has indicated that an update is coming soon, so I expect to see something there. Michael, do I put you on the spot and ask about onboarding? Okay. I won't.
[00:04:00] Michael Richardson / Guanjun: No update. Running code. Waiting for running code.
[00:04:02] Peter Yee: Okay. We're waiting for running code. EAP EdHoc, my understanding is oh, Chris has something to say. So Here's our AD.
[00:04:10] Chris Patton: Yeah. So I believe
[00:04:13] Peter Yee: I got an update, frankly,
[00:04:17] Chris Patton: and and it's Renzo. I I went and searched after our quick conversation. K. Looks like I do have an update, which means I just have to clear it, and I will
[00:04:26] Peter Yee: do it now that I realized there's one waiting for me. Okay. Thank you, Chris. So button will be pushed. Publication will be moved along. Alright. I think that covers all of our active items. So now on to Alan.
[00:04:46] Joseph Salowey: Alright. Did did they change the interface to MeetEco, like, today?
[00:05:01] Alan DeKok: Alright. T p two. So this came out of the long, long discussion with TEAPv1. The key derivation in that is very, very complicated so that everyone essentially did something different, and they're vaguely interoperable. There's basically no negotiation. And one of the use cases, which is not covered and may or may not work in TEAPv1, is differentiating machine versus user credentials, which is the use case of when a machine is on the network, but the user isn't logged in. You wanna put them in a different VLAN so they can still download updates, but you want to treat that machine differently when a user's actually logged in. Not a bad thing to do. The document is completely silent on that, and it's a, shall we say, poorly tested area. The solution is you create TEAPv2 with significantly simplified key derivations. We're going to implement Elliott has first drafts in host AP. The idea is all of the flows are going to be mandatory. So TEAPv1 allows for provisioning CSRs, all kinds of stuff. Nobody does it. So then we have test cases for functionality, not so much compliance, but at least test cases for interoperability. And because a lot of EAT methods have MTU issues, we fixed that just by mandating a maximum MTU. One thing which was brought up in discussions is if this is substantially different than t v one, we may want a new EAP type code for the simple reason that it makes the code easier. Otherwise, the code has all kinds of state machine issues of do we do this or that depending. We can probably also simplify the design by mandating order. So the issue with a complex protocol is you can do machine and user or user and machine or machine or user or provisioning, and now your state machine becomes very, very complicated. If instead you go, it always proceeds in a particular order, then it becomes a lot easier to, figure out what to do. Your state machine becomes simpler and interoperation becomes simpler. Elliot has a question.
[00:07:38] Elliot Lear: This is Elliot. I have to disappear off in a little while. I just wanna say I've actually in the code that I've implemented, it doesn't quite match the draft right now. So, first of all, I invite people to look at it. I'll post it again to the list. I've done it twice, but I'll post it again. The second thing is I have implemented all of the x five zero nine machinery inside of TEAPv2 in host AP and in WPA supplicant up to and including things like pushing a, what should we call it, request action frame for PKCS 10 when you see a certificate that's on its that that is two thirds through its lifetime. Now that's just demons the host AP code's really demonstration code. I expect that that's pretty easy also to implement in free radius. I was talking to Alan about it. It sounds like he's got a pretty elegance piece of code for that. And I like the idea of doing this ordering. One of the problems with TEAp is that it is like free range chicken. Right? You just they go everywhere. And and so nailing down the code path a little bit will just simplify things. The idea of machine auth first and then, you know, there are there are some itty bitty things we need to talk about and then user auth, and you have to make sure that the signaling is right to know whether or not you have user auth to do. Some of that still needs just a touch of work and then reprovisioning as you say. So all all that, I think, is I think in flight, what we need most is people to grab the code and feel free to whack with me. The other thing I I just wanna add is that TLS1Dot3 code is almost there. It it actually, TLS1Dot3 code is there. Other thing that's not on that list that's really important is the changes to crypto bindings. In TEAPv1, you crypto bound to things that had no crypto. Okay. So that's gone. Right? And that's important. And Alan did a great job in the draft of simplifying how to generate the the crypto information. So that's not quite in the code yet either, but that's a small thing, I think. And so I will probably be doing some emails with with people here just to make sure I've gotten that right, and we'll play around with the code base to see if I can get that right too. So that work will happen over the rest of the summer. And by the time we get around to November, the, at least the TEAPv2 code should match the spec very nicely, and the spec should be well baked. The only question then is, as Alan said, two questions. Number one, do we get another code point? And the second thing is once the code and the draft are stable, do we do we pull in the bits of the TEAP RFC so that it's so that this TEPV two rests on its own?
[00:10:32] Peter Yee: Thank you. Yeah. And I have asked Alan about bringing in the bits of TEAP and making it a unitary document instead of pointing back to all the spaghetti of the original TEAPv1.
[00:10:45] Alan DeKok: Yeah. I I I think it's useful initially just so people don't have to read 80 pages of gobbledygook. The initial draft is basically a diff from TEAPv1. But once we get agreement as to the base functionality and implementations and some interoperability, then, yeah, pull in everything else and then make make TEAPv2 standalone. The other thing is I've been talking to enterprises and telcos about this. They like the idea of being able to reprovision on the fly because there's not always good solutions for them. So there is some interest in this.
[00:11:25] Joseph Salowey: And and when you say reprovision, is that
[00:11:27] Alan DeKok: A certificate.
[00:11:28] Joseph Salowey: Certificates? Okay. And then with respect to ordering, not all the things would they would be you would have be able to have optional. Right? So, like, if you didn't wanna do machine auth, you wouldn't have to do machine auth. Yeah.
[00:11:43] Elliot Lear: I think that's the plan. That that's the plan. But the when you say honestly, when you said the word optional, my my I just shivered, but that's those points are exactly right. Yeah. Right? That it's an if you do machine auth, then do it. Then if you do user auth, then do it. And then make sure that the signaling is right so that you know which has to happen. And some of that's policy on some of that signaling. We have to be really careful.
[00:12:12] Joseph Salowey: Yeah. Yeah. Absolutely.
[00:12:21] Heikki Vatiainen: Yes. So the previous slide says that mandate all flows. So I was thinking that are there any known new plans that flows that might be planned? And would that help deciding should a new EAP code be added for the person too? I mean, if it comes if more things aren't added, would it then be easier to decide that if new EAP code is needed?
[00:12:53] Alan DeKok: Yeah. Not right now. But, yeah, if we especially if we do more flows, it becomes much more relevant to use in the deep type. I'm happy to add more flows, just they need actual use cases Alright. That'll use
[00:13:09] Heikki Vatiainen: Let's say that is it easier to ex
[00:13:13] Peter Yee: Hi, Keith.
[00:13:14] Elliot Lear: This this is Elliot.
[00:13:14] Heikki Vatiainen: Was thinking that it would it make it easier to add new flows if there is a new, EAP code or something like that?
[00:13:23] Alan DeKok: Probably because, the TEAPv1 state machine is really implicit. What are you doing right now? I don't know. I look at the data and sort of try and guess. If we make the state machine explicit, then it becomes much easier to add new flows.
[00:13:41] Elliot Lear: It does. This is Elliot again. But, like, all of us should bring our golf clubs around and swing at people who bring new flows who don't have a very compelling case. Like, the problem we have with with with these protocols is if you just add the kitchen sink and this is what happens, we end up with a document that doesn't get well implemented. So we should be very, very discerning before we add an an additional anything additional into them.
[00:14:10] Joseph Salowey: Yep.
[00:14:13] Alan DeKok: Okay. Anything else? Slides, questions, comments?
[00:14:24] Michael Leclerc: Code. Code. Code.
[00:14:26] Peter Yee: Code? Yes. Will have Your turn.
[00:14:31] Joseph Salowey: Okay. Alright. Thank you. Hi, Keith. Did you have another
[00:14:38] Praveen: question?
[00:14:42] Joseph Salowey: Or are you up next?
[00:14:54] Heikki Vatiainen: No. It's a problem with audio.
[00:14:58] Joseph Salowey: Okay. Who's next? Forward security. Which
[00:15:05] Michael Leclerc: one is it? Yeah.
[00:15:20] Joseph Salowey: K. And you should have control.
[00:15:22] Michael Richardson / Guanjun: Yeah. Okay. Thank you. So I would like to present my
[00:15:27] Joseph Salowey: You may wanna get closer
[00:15:28] Michael Richardson / Guanjun: to the mic. Okay. So it is called the forward security authentication e a p a k a prime. Yeah. So, actually, we did a presentation, yeah, as a first one. It's Shenzhen. Yeah. IETf-one hundred 20 5. So today is the second time. Yeah. So the first several slides are actually just repeated from last time because I guess some of you are not here. But I want do not go to detail. Just to tell what's the main information here should be fine. Then I would like to tell a little bit more detail what is the attack, how we actually can update the protocol. Yeah. So in this version, yeah, we just updated. So it's last night. Yeah. Sorry for that. So we actually added the protocol call flow. So how we can actually enable the EAP aka Prime FS? It is RFC nine six seven eight such that yeah. So for re authentication can be also forward secure because this problem has been announced that it's the RFC nine six seven eight. So if you use that one so, actually, for re authentication, forward secure cannot be guaranteed. So we would like to solve this issue. Yeah. So below the slides is some brief history about EAP a k a or EAP a k a prime. So maybe I just ignore it. The main information is that one. Yeah. So I have to say nine six seven eight published something like two years ago. So it actually employ the ephemeral DH such that as a case change, actually, can have the forward security. But, unfortunately, only that that part about the distribute of the re authentication ID and also deal with this procedure to the, actually, authentication code part as a attribute at MAT is actually not forward secure. So we try to solve this issue. Now this is actually motivation. Okay. I just mentioned this one already, so I don't need to go to detail. Yeah. So this is the original RFC nine six seven eight. So from here, actually, we can see. So, yeah, okay. So this part is actually going to do the ephemeral DH. So the server side will generate a ephemeral public key. Yeah. ECDH public key. And then the p the PSI, the client side, will also generate his ECDH public key. So do, by using these two info two piece of information, so we can get a shared security key. So this one, can the security key. So arrange your key equipment to use empty from this sort of random function, yeah, p r f prime. But it is this stage, actually. Yeah. We have the I a k I k prime and the c k prime. Both are actually derived from the long term secret keys to the sync. Yeah. And also some other information, like, etcetera. But, anyways, so this means this MK together with some public information transferred on the protocol. Yeah. So the question is that if the long term key is actually compromised, when we can say there's a forward security, yeah, we can assume the long term public long term secret key stored either the server side or the user side could be compromised. In that case, according to this long term key together with some public key transferred on the protocol, So MK can be actually also derived by attacker as well. Yeah. But the question is here. So the KERC and the KAUT, this actually used it for re authentication. Yeah. And it derived some other information here. There's two case. One for encryption, one for authentication or integrity. Both of them, which you derive just from the MK. But this one, once the public get compromised, these two case can be controlled by attacker as well. So they see the problem. They see problem. Yeah. So into the in the, would say, nine six seven eight Yeah. Because we actually, the ephemeral different human skill is used here, so we can get the shared secret key. But once we get the shell key, we we we we derive another key series called the MKECDHE. But in this part, don't update, these two keys for re authentication. So they see the reason why if we still use two keys for re authentication, it cannot get the forward security for re authentication. Not for the full authentication. Full authentication still has the forward security. Okay. This is the key points. Yeah. If you got to these points, it is easy to know, yeah, what the attacker would be if it's a long term key, yeah, compromised in that case. Yeah. So as we just mentioned here. Yeah. These two key will be controlled by attacker. So in that case, when we do the faster re authentication between the peer and the authenticator or the server, is that the case? Yeah. So this part information is like a newly a generated re authentication username or maybe just the call to, like, a re authenticate ID. This is actually encrypted by this key, k e a n c r, or encryption key. And this MAC also actually generated by the k a u t. But this tool can be actually controlled by the attacker in that case. So, yeah, when anytime, yeah, actually, the such kind of authentication happen. So a tech can copy the information and then do some simple analysis, or decryption, etcetera, can get to the newly generated re authentication ID or can link to such a kind of the re authentication sessions such that they can they can deduce that, okay, those two sessions or a particular ID must belong to some identity. So they see the provider, the linker ability, so it does not have re authentication. Does not have the forward security. So our purpose is that we just needed to update these two case, k for encryption, k for authentication, for the re authentication ID. So we update it this way such that this information also actually generated from this mask key. Yeah. Where is the input of the shell, the secret key derived from the ephemeral. Yeah. Okay. So all of this actually has been present to the one to five meeting. So next, I would like to ease that. We would like to show how we can actually execute the protocol itself. So how actually we can use the updates, these two case, yeah, called the transit encryption key. Yeah. Both the k e n c r and the k a u t, such that we can get to the protocol. Yep. Okay. This is update one. So this is updated the a p a k a prime FS. So in other ways, it means we propose this update to the RFC nine six seven eight. So what is the change? The change part is actually highlighted here, basically, for attributes here. Yeah. So we would like to say this one. This is this d r authentication ID, but this one is actually just same as the. But this information is encrypted by the old k encryption key, k e n c r. So in some way, we can say they actually they distribute real authentic ID. Does not have the forward security. Yeah. And the server also may need to send some information like a notice, called the support t e k s f s. So this means it's just a one bit of information to tell the peer the peer, the client, to that. I actually support this particular update. Yeah. So once the peer also supported this update, they will also send back a notice. So this is a new attribute. We introduced the this this document. Yeah. And, also, once once actually, the the the server get the notice, the support the GEKS from the peer. Yeah. So said I wanna okay. The client, the peer does support this functionality as well. So I can update both of these key to this key and also the authentication one, k a u t to the k a u t prime. So then for the next run to distribute the authentication ID or to the authentication code so we can use the updated case for encryption and for authentication. Yeah. So that's it. So but here, yeah, we actually redistribute another re authentication idea here. And then this one and then this one still the same attribute, but the contained actually encrypted by different keys. The first one encrypted by old key and say r. This one actually encrypted by use the key key and say r client. So this key is already for the secure. Okay. So this about the distribute, actually, the first forward the secure authentication ID. Okay. Next, we will see how it can run with the faster re authentication itself. Once I already got a for a forward a secure re authentication ID, how I can run it. Okay. So before that, we just gave a a shorter notice. What is the newly introduced at the support of TKSFS? It's just a notice. Basically, we don't need any value, any data, so just attribute. It is for octaves. Yeah. So very simple. So the protocol call is actually still the same as the original re authentication protocol calls. Yeah. Specified by oh, I forgot the IC number. Should be 4173. Right? Yeah. Okay. Anyway, we can find it from our draft. So so the old the procedure is totally same. But the only thing, the real difference is just that the content, like, is every authenticate ID and the the with the encryption part and messenger authentication code MAC, they are actually all actually generated with the updated case. Yeah. This is the information. This is the update. So this actually just repeat. But the content is that you have or the case used here is different, but the attribute itself to deal the same as the paragraphs RFC specification. So that one yeah. This one. Okay. So the re authentication protocol call is actually, yeah, according to the RFC four one eighty seven. Yeah. Four one eighty seven. Yeah. So this means in our proposal, yeah, for to actually to execute the faster authentication, we still just run the same protocol procedures as specified for one eight seven. But here, the key used it just the user updated the key. That's the point. Yep. So the real change is actually about the about the full authentication part. So because here, we're actually just in such a protocol run, we're actually distributed twice. Yeah. Every authentication here and also here. But this one, you could be the ways the original k e n c r. And this, yeah, real authentic ID is encrypted by updated key. Yeah. This is actually for, yeah, backward compatibility. Because in that case, if the peer does not support this update, in that case, we can still use the this original authentication ID, but it does not have a full security. If it's a p also support, so it will use the next one. So this authentication will never be used. So this is the port. Okay. So that's it. I would like know your suggestion, comments, or you may review later. Yeah. That's it. So does this require
[00:29:47] Joseph Salowey: changes to the where where where do you have to make changes in order to implement this protocol in in the server and the in the back end systems? Like, maybe the other slide is better when it has all those. Yeah.
[00:30:04] Michael Richardson / Guanjun: It's just here. So here is a really change we need. So we need to have this one. This is a notice to say, okay. I'm at server. I supported this one, so I let you know. Do you also support it? If your support, the peer support, you also replies a notice here. Yeah. Also, part of this one, in our case, we needed to redistribute a if the peer also support, we will distribute another re authentication ID here.
[00:30:34] Joseph Salowey: Does this
[00:30:35] Michael Richardson / Guanjun: This one encrypted by forward security key.
[00:30:38] Joseph Salowey: Does the server have to maintain more state or anything like that? Like, does it have to maintain this Yeah.
[00:30:44] Michael Richardson / Guanjun: It's a more state. Yes. Okay. Yeah. It's a more attribute. We need to introduce another attribute. This one's still same, but there is a in included by a updated key.
[00:30:56] Joseph Salowey: Yeah. And so it has to keep persist that updated key? Or
[00:31:01] Michael Richardson / Guanjun: does The key itself is actually updated here. Okay. So maybe I show here. Yeah. The key updating is here. So, originally, the key is just this one, and then this one derived from the m key. So now because we will likely to get the forward security, so we need to get these these two after the key, yeah, from this one. Yeah. Original in original scheme in the, would say, 9678. Yeah. We do not have this part. So now we're having to edit this part. So get this out of the key from this service. Yeah. Where is the input of a shared secret key?
[00:31:47] Joseph Salowey: But the would would there's k and c r prime and k odd prime, do those need to be store persisted? Or
[00:32:00] Michael Richardson / Guanjun: Or not? Yeah. I I I think it should be stored by per session. Yeah. Run by the peer. Yeah.
[00:32:12] Joseph Salowey: But how about cross session? Does it because if if you're doing the reauthentication, like Mhmm. Do you need the the k encryption to process the reauth ID? Reauthentication ID? Yeah. Like, if you get a reauth ID, do you have to decrypt it using k and e n c r prime?
[00:32:33] Michael Richardson / Guanjun: Yeah. You need to. So the peer needed to.
[00:32:36] Joseph Salowey: Yeah. So you you does it have to so the peer would have to maintain that across sessions?
[00:32:41] Michael Richardson / Guanjun: Yes. Okay. For the full yeah. Full authentication. Like, a full authentication, maybe maintain for one day or something. Yeah. During this process, we need to keep the this information. Yeah.
[00:32:51] Joseph Salowey: Okay. And but the server just keeps the server's behavior is the same. Is that right?
[00:32:58] Michael Richardson / Guanjun: Yeah. Actually. Yeah.
[00:32:59] Heikki Vatiainen: Okay.
[00:33:00] Praveen: Yeah.
[00:33:01] Michael Richardson / Guanjun: Alright. Thank you. Thank you.
[00:33:10] Peter Yee: Alright. Next up, we're gonna have Michael and Emmanuel. You'll get the next set of slides, Joe.
[00:33:20] Michael Leclerc: Hi, everybody. Do you listen us quite well?
[00:33:33] Emmanuel Conesa: Yes. We can.
[00:33:34] Joseph Salowey: Yes. Who wants control of the slides?
[00:33:38] Michael Leclerc: I'll take control of the slides, please.
[00:33:41] Joseph Salowey: Is that Michael? Yes, please. K. Thank you.
[00:33:45] Michael Leclerc: Fine. So hello, everybody. Thank you for letting us to present a proposal to enhance the EAPPSK standard RFC forty seven sixty four. First, we will present us we are a group of five people working in DS and electricity DSO. First, two people from any this, Clementeva and myself, my Michael Leclerc. Bruno Roy working for SIGN four. Emmanuel Conesa working for Onisek. And Vincent Murray working for Trialog. Our email addresses are in the draft. Second, the proposal for a quantum resistant version of EAP PSK. Let's first state a bit of context. We use EAP PSK in the g three hybrid standard, which is used for smart metering and IoT devices communication on power line communication or radio frequency networks. This was from that we relies on both I three eight hundred two dot 15 dot four, which is widely used in many protocols, and EAPP ASK. I three protocol added support for a s 256 bits CCM encryption to withstand the quantum threats, and it was added in 2021. And g three standard adopted this evolution recently. Since EAP-PSK relies on AES with 128 bits keys. It will need to be upgraded and it is not the case today. We use EAPPSK for authentication and case to mention in a g three hybrid protocol. First, we noted that using a a s 128 bits keys is a weakness against quantum threat, and it it affects key derivation, which relies on a s 25 count mode in EAPPSK, message authentication codes mechanism, which relies on AES CMEK mechanism, and also the protected channel encryption, which relies on AES EAX mechanism. Second, EEPPSKK derivations can be improved can be improved. And first, the AES modified counter mode is nonstandard unstandardized mechanism, and it isn't an agreed mechanism nor for any zone, nor for nest. Second, the authentication keys, the revision is not context based. Meaning that if you independently of the from the peer, with the same PSK, it will produce the same derived case, AK and KDK, which leads to all communications eavesdropping and manipulation in case of the disclosure even after reauthentication unless the PSK is rotated. And last, the session key duration for TEK, MSK, and EMSK lies on only one peer on TrimpeSource named run p. I will let Emmanuel follow the presentation. I will take will keep control of the slide.
[00:38:01] Emmanuel Conesa: Thank you, Michael. So I will not go into the technical details. We opt for just showing our choices to make our proposal. So first, let's start with the cryptographic primitives. For our work, we we've made our choice based on NIST and ANSSI recommendation. So the global idea is to double the key size as you noticed. So we go from 128 bits for all the keys to go to 256 bits. So it starts with the PSK, which is a key needed to start the protocol, so it is not generated by the protocol. So for this key, specifically, we need to think about the strategy of a way to distribute it. And second, for the derived keys, AK, KZK, and TA key, we first propose to change the key derivation mechanism. Today, is AES modified counter model. We propose to base our work on a missed special publication, which is numbered eight hundred one zero eight. In this publication, there is three key derivation mechanism, content mode, feedback mode, double pipeline mode. We opt for a double pipeline mode because in this derivation, we you find all the same logic of the two first key derivation mechanism. And we also formed a security analysis of this key derivation mechanism. And the conclusion of these papers of these papers, sorry, is to state that the one on which we stand the most to cryptographic attacks, mainly collisions, is the double pipeline mode and the feedback mode. For message authentication code mechanism, we also double the key size used to produce the the MAC. So we go from a s c MAC 128 bits to a s c MAC one 256 bits. And for the protected protected channels, we opt for the same logics. But I would like to add that e x is recommended by ANSSI. But today, there is no special publication from list which states this authenticated encryption mechanism as a recommendation. We kept it to minimize the implementation changes from initial PSCA. So we are open to the propositions. Next slide, please, Michael. And last, as Michael said, we also propose to make more instrument of EAPPSK. So besides the quantum cryptography needs, we propose to use a context based authentication key derivation using the peer network access identifier, which is not the key today. And last but not least, we also propose to enhance the session key derivation by using both peer and server, random generated numbers. So we'll use one p and one s in the key derivation mechanism. So that's all for our presentation. If you have any question, we are open to respond to them. Thank you.
[00:41:45] Peter Yee: Alright. Anybody in the room or online have something to say about this? Okay. Hi, Keith. Go ahead.
[00:42:04] Emmanuel Conesa: Can't hear what is being said.
[00:42:11] Peter Yee: It says his audio died. He just typed into the chat. Matt, g one, go ahead.
[00:42:19] Emmanuel Conesa: K.
[00:42:21] Matt (UK NCSC): Hi. Thanks. Yeah. Matt from the UK NCSC. So having read the the draft and things, I think there's some kind of misappentance by Grover in the draft. I don't think the threat is quite what was put forward. So, you know, I've had no strong opinions about whether or not to have a new PSK and have to agility or something. That's that's fine. But the the the arguments don't quite stack up for me on the Grover.
[00:42:50] Joseph Salowey: Do you mean for the Grover's algorithm? Is that what you mean?
[00:42:57] Matt (UK NCSC): Yeah. I mean Yeah.
[00:42:58] Emmanuel Conesa: Okay.
[00:42:58] Matt (UK NCSC): We the statement from this is the a e s one twenty eight is secure for decades. It's not really a quantum thing. I mean, change stuff, have good fragility, add more things that you need. No no objection there, but it's just the predicating on quantum's cybersecurity.
[00:43:17] Emmanuel Conesa: Can we answer or wait for the next question?
[00:43:21] Nokia Representative: Sorry. I think just one second. From Nokia. Sorry. I just wanted to echo Matt's comments as well. So, yeah, I think I mean, is AES one twenty eight under a quantum threat? That's actually the first question that we sort of need to analyze. And secondly, obviously, I mean, doubling the key size, I think it's also a lot of question for the implementers on how this is gonna affect if it's not as big of a quantum threat as, I think, asymmetric cryptography. So I think it's the the bigger question is I would want to ask is is a s one twenty eight actually gonna be a quantum threat? Yeah. Thanks.
[00:44:06] Peter Yee: Go ahead, Michael or Emmanuel, if you wanna address the that point.
[00:44:10] Michael Leclerc: Yes. Because the main change, I we agree that a s 128 bit keys are not immediately threatened by Grover algorithm. But nonetheless, we we have regulations that asks us to increase the size of the keys.
[00:44:41] Emmanuel Conesa: And I would like to add that even if today there is not a a proof which shows that Goover will be able to to be implemented and work in a reasonable amount of time to break a year's 128 bit skis today. There is no guarantee that tomorrow, we do not not have this evolution. So we are trying to anticipate the threat. We are not waiting the day this algorithm will be implemented in the real life. And we state that in the draft, which is a security position to do the most to date we avoid trying to catch up the the straight in the future.
[00:45:31] Alan DeKok: Okay. This is Alan. I mean, to a certain extent, yes, it takes years to implement something and widely use it. So there's a certain interest in doing this before there's a problem. The one question I have is how widely used is EPSK? At least for the cases I see, I don't see substantial amounts of uses for this. So, I guess, is there a use case, some enterprise telco, whatever, that will be using this EPSK with the quantum resistance?
[00:46:14] Michael Leclerc: So you're right. It's used in we know in a protocol using a PLC communications. We we should look for other applications. And but the main the main challenge is that in on this medium, we need to keep the communications very light and we must stick to symmetric cryptographies. And we are dealing with also with established use by the manufacturers. So it's difficult for us to change.
[00:47:04] Emmanuel Conesa: I agree with Michel, and I would like to have that in cost on constrained devices. It is quite difficult to implement complex protocols. I see in the chat someone's teaching me about EAP a k. We we saw this protocol, but in our domain, which is a smart metering, we use devices which have very, very short capabilities in term of computation. And protocols like EAPPSCA is quite interesting. And we discussed with the the consortium. It is called the g three PLC aliens. And the companies which are in this consortium are quite agree with the move to go from the 108 bit keys to 256 bit with the with by adding the the the recommendation we we propose in the in the draft. Is it possible to share a URL in the chat? Yeah.
[00:48:15] Peter Yee: Yes.
[00:48:16] Emmanuel Conesa: Okay. Thank you. So I'm going to send the website in the chat so you can check what it is.
[00:48:30] Peter Yee: Alright. Thank you very much for that presentation. I don't, let's see. Heikki is, well, alright. Give your audio a try.
[00:48:40] Heikki Vatiainen: Yeah. Yeah. Now it works. I put it in the chat also, but just in case that, I wanted to point out that, WPA supplicant supports RFC of forty seven sixty four EPSK already. So that might be a good testing tool if you want to have, more people who would like to test against your trust. If you update or create batches for WPA supplicant, then, it might help testing. That's all. Thanks.
[00:49:18] Emmanuel Conesa: Okay. Thank you.
[00:49:21] Peter Yee: Okay. We are at time for that, presentation. Next up will be Praveen.
[00:49:35] Joseph Salowey: You should have control to change the slides.
[00:49:39] Praveen: Okay. Thank you. Thank you, everyone.
[00:49:44] Praveen: Good afternoon, and good very early morning from here in Bay Area. As the what I'm proposing here is an EAP-WSIM, which is for the enterprise Wi Fi networks. The idea here is that the enterprise Wi Fi doesn't know much about the MNO devices, and and they are actually anonymous in the in the in the enterprise network, act as an enormous dry device where the Wi Fi authentication is done through through the enterprise means or, you know, guest SSID means. But then e p a k a prime is used or used on top of the Wi Fi connection or Internet connection by Wi Fi to reach the EPDG and and do that e p k k a prime to allow the wife MNO devices to offload the traffic onto the Wi Fi. And the the the the normal typical Internet traffic works by that offload, but the especially the voice services, which is called voice over Wi Fi, that service doesn't work very well as the device moves from one AP to another AP. And and and the and the performance of the voice traffic is very, very poor. So there is there is a need to to solve for the solve and improve the performance of the y performance of the Amino devices when they are connected to the enterprise Wi Fi. And that's what we are trying to solve by this introduction of EAP-WSIM. So I covered the the problem a little bit already as part of the introduction. I'll skip this. Now there is another set of set of use cases where the the end the Wi Fi network is also owned by the operator, and those are called trusted Wi Fi's. And those trusted Wi Fi deploy in in the trusted Wi Fi, the Wi Fi network is also owned by the by the MNO, and then there there is a dedicated link from the Wi Fi network to the MNO for for both the Internet traffic as well as for the for the for the authentication. And those are and that and that's where the eep e k eep a k a lives. So eep a k a is basically used in the trusted Wi Fi networks. Enterprise Wi Fi Wi Fi is not a trusted Wi Fi network. Enterprise Wi Fi is a untrusted Wi Fi network in which which is not managed by operator and is independently deployed on which the EPK prime is used for the y for the MNO traffic. But for actual Wi Fi connection, usually, EEP SIM is used to connect to the to the for the for the device Wi Fi connection to the to to the to the network.
[00:53:52] Praveen: So that distinction is very important. And there is no viable solution to solve this problem at this point. I mean, we can't use the hosted hosted radius because the the network is not really deployed by by by the by the MNO, and they there's they and and there's no dedicated link connecting the Wi Fi network to the enterprise to to the to the MNO. So and and so they they they won't offer the hosted hosted MNO radius for those kind of those kind of networks. We can use enterprise eight zero two dot eleven r plus ePLS, but then because the MNO device is anonymous in the enterprise Wi Fi, you won't be able to distinguish between which one is an MNO device which requires eight zero two dot 11 r and which flows don't require eight zero two dot 11 r, and that would be a problem. The other thing is because the device implementations vastly differ from one implementation to another implementation, in our testing, what we have seen is that eight two two dot 11 hour of the device doesn't work. Like, if you try to test the iPhone and Android and the laptop, they they all have different versions of eight two two dot 11 r, which do not work work with the APs today. So interoperability of AP with the device a two dot 11 r is a big problem at at this point in the in the market marketplace. The other option is the DSCP based QoS without any authentication, but that won't really give you eight two two dot 11 r. So so so we we we developed EAP WSIM with the design goals of of using a a using a some sort of a mechanism to to create MNO device authentication within the enterprise Wi Fi network. And and so that MNO devices can be recognized at the Wi Fi connectivity layer as at the layer two in the in the enterprise Wi Fi, and then be treated treated, you know, according to the flows of that MNO device and and some kind of policies that you want to enforce on on on the MNO devices. The other goal is, like I was saying, the device Wi Fi is currently not tested by the by the MNO. Any vendors native implementation is used, and then that creates interoperability issues. Zero touch provisioning. So, basically, MNO device comes pre provisioned for the authentication with the with the not with the with the radio server, which is which has the MNO keys installed in the in the server as well so that one can do mutual authentication without any onboarding of the MNO devices in the enterprise network. There is no per subscriber provisioning.
[00:57:52] Joseph Salowey: Praveen, we're we're getting close to the end of your of of this session, so you you might want to go a little bit quicker.
[00:58:02] Praveen: Sure. Thank you. And forward secrecy quantum proof algorithms, eight zero two dot 11 r, fast transit, MNO identity as as association, and and no device side changes is are the design goals. This is the you this is the flow basically where the WSIM from the device is talks to the WSIM AS, which is hosted at the radius, which is hosted as a radius server on the on the enterprise Wi Fi. And then then basically push the pre shared PMK r one to the APs and then allow eight zero two dot 11 r. I won't go into the details. Also, the the master key is used both on the on the on the master key is derived with the the SSIDs and the MZs are provisioned on the SIM card and the and the AS server to allow for a derivation that can be mutually that can create a mutually shared key. We are proposing a quantum safe algorithm for this. So in a way, EWSIM is a is a is is is a is an improvement derived from ePKA as well as ePKA prime. And and a lot of those design elements are introduced or are added as part of the e p w sim. And I think I will skip this one. That is the last slide.
[01:00:01] Peter Yee: Okay. Go ahead, Mark.
[01:00:04] Mark Grayson: Yes. Mark from Cisco here. Yeah. I I guess we don't understand. I I don't understand the the the fundamental premise about why why you can't use ePaka in enterprise deployments, at least from an open roaming federation. We see a number of MNOs that have joined open roaming federation and use eP AKA over third party enterprise networks, including those enterprise networks amid inbound roaming using AKA. Also note that The UK all UK operators have have defined something called Fed Wi Fi, which is advocating over third party enterprise networks. So I guess I don't really understand what problem we're trying to solve here. Thank you.
[01:00:49] Praveen: What what the WBA broadband is proposing is a passport type type concept, but that is essentially a a concept which is which still requires an anchor at the MNO for for authentication. And and I don't think that those those those those passport type implementations are are supported for the enterprise Wi Fi at the at at this point. They are met usually meant for public Wi Fi's.
[01:01:31] Mark Grayson: If I can just at least The UK Fed Wi Fi isn't pass point based, so it's just normal e p a two one x. But so that's the first point. So there are other operators advocating more e p a k a over enterprise networks. And I guess the other issues is perhaps PassPoint isn't enabled in the enterprises, but I'm sure the the Wi Fi equipment in those enterprises is is PassPoint. So, yes, it may need some configuration, but that's an enterprise decision as to whether they want to accept inbound roamers from those MNOs.
[01:02:09] Joseph Salowey: Thank you.
[01:02:10] Praveen: So ePaka is fundamentally a trusted Wi Fi network. And, I mean, if UK is allowing a allowing a an enterprise Wi Fi network as a trusted Wi Fi network onto onto their radius or and onto their authentication servers of the MNO. It's directly. That is something which which which is an individual m n MNO's decision. But what I have seen is that a lot of MNO's don't want to connect to enterprise Wi Fi's for authentication.
[01:02:57] Peter Yee: Okay. I'm sorry. We we probably needed more time on the agenda for this. I'd like to take the any further discussion to the mailing list. And thank you, Praveen, for making your presentation. And, Alan, if you have a real quick Very,
[01:03:17] Alan DeKok: very, very, very quick. One issue that came up in Radix is supplicants blasting the RADIUS server, authenticator slash NAS client with traffic. It's probably worth updating the RADIUS security document with a requirement on supplicants to say, don't spam if you get something wrong. It's not really part of Radius, but it's part of the ecosystem. The Radius security document already suggests that the Radius client should do rate limiting, but it's probably worth adding a paragraph or so for supplicants, but I'll post that to the list too.
[01:03:54] Peter Yee: Okay. Yeah. Please take that to the list. Alright. Thank you, everyone.
[01:03:59] Praveen: Thank you. Bye bye.
[01:04:02] Emmanuel Conesa: Goodbye.
[01:04:06] Michael Leclerc: Thank you. Goodbye.
[01:04:17] Peter Yee: Yes. 90 would have been good. Ninety minutes would have been better, but when I get a ninety minute, I don't use it up either.
[01:04:24] Joseph Salowey: Although, like Yeah.
[01:04:28] Peter Yee: Yes. It's it The one time we we do the long slot that we don't open. Yeah. We use half of it.
[01:04:37] Joseph Salowey: We're out of sync. We're virtual interims. We still virtual interims. Yeah.