IETF Meeting Minutes

Session Date/Time: 19 Mar 2026 06:00

Speaker 1: All right, looks like it's the top of the hour, so why don't we get started? I'd like to welcome everybody in the room and online to the EMU working group session here at IETF 125. As you can see in the lovely red letters, this session is being recorded. All right, I would like to point out the Note Well. I hope you have noted it well and have seen it many times this week, but we are expected to behave in a professional manner and extend respect and courtesy to our colleagues at all times. And if you have any concerns about behavior, please contact the ombuds team and they will take your report and decide what needs to be done. For more information, I suppose that QR code will take you there, to the Note Well and other information that's related to that. All right, if you are in person, please make sure that you have signed in via the Data Tracker or the QR code that I presume is outside of the room. For those in the room, please use the Meetecho Lite client, and those of us who are remote, I guess, will be using the full fat version. If you are remote, please make sure your audio and video are off unless you are presenting during a session. And since some of us are remote, please state your name each time you begin speaking in the queue, just to make it helpful for those in the room and those remote who can't see one another. Here's a list of resources for this meeting. I'm sure by now on the fourth or fifth day of the meeting, you are aware of them. Okay, so this is the agenda that we have. Somehow we have ended up with a two-hour slot; I made a one-hour request, but I guess that's the way it is. So, I believe Joe put out a request for a note-taker. If anybody wants to help, just you can—the notepad is linked off of the Data Tracker, and feel free to add notes there. And if there's anything interesting that comes out in the chat, those can be added as well. I probably won't be able to keep up with that and handling chair duties. Okay, so we have one working group document that we're going to discuss—that's the draft-ietf-emu-pqc-eapaka aka prime PQ update. And then we have three non-working group documents. Alan has the TEAP document, Guilin has a forward secrecy re-auth document, and then Tero has a PQC EAP-TLS document, which I believe will be of interest. So, I see Aritra. Aritra, are you ready to begin with your slide deck? You should be able to move the slides yourself. But we're not hearing you at this point. Aritra? Are you hearing anything in the room?

Speaker 2: No, no sound here. We're hearing nothing.

Aritra: Yeah, I think—okay. So, yeah, thanks, Tero, for the interesting comments and, yeah. So, moving on. Yeah. So, the latest version, it actually inserts a new section on message fragmentation and reassembly, which is actually quite key here because of the PQC message sizes. Aritra, we've lost audio again, I believe.

Speaker 2: Yeah.

Speaker 1: Tero, do you want to take over?

Tero: I can take over if he's not able to present, but Aritra, you have to disable Zscaler—that's the one which is causing the trouble. So if you disable Zscaler on your laptop, you should be able to—it's proxying, that's the reason it's not working. Can you hear me, Aritra? If you can't do it, I can present it. Okay, thanks. Yeah, sorry, I don't know where he has stopped, but okay. So after this draft got adapted, we received several comments from the working group, especially on the message fragmentation and the capability negotiation because it adds new attributes and it changes some of the attributes' lengths. The idea was to negotiate these new formats only when both the peers support PQC, otherwise it could create backward compatibility issues. And then also what we did was since the fragmentation reassembly was a generic mechanism that could be leveraged by hybrid PQC as well, so that draft basically refers to this one for the message fragmentation and reassembly. Okay. So the challenges that we faced is the EAP-AKA' specifications, right, did not define native fragmentation and reassembly. That's probably because they were using asymmetric traditional algorithms whose sizes would never typically exceed MTU, and there was no reason to support that. But the PQ public keys and ciphertext sizes in all likelihood would exceed the EAP MTU, and there's a need to basically address the fragmentation problem. So to address that, what we defined is a container basically to carry the fragmented attribute. The AT_FRAGMENT is the new attribute we defined which carries the fragmented attributes within that. And it's very similar to what other EAP documents do, which support fragmentation, that we introduced two flags: one flag is the first fragment and the next one is more fragments, so basically to indicate it's the first fragment and to indicate that there are more subsequent fragments to follow, and then the last fragment would have the M bit set to zero, and then you have the total attribute length as well, and the fragmented data carries the fragmented attribute. The reassembly requirements are pretty straightforward: you reassemble them in bitwise identical reconstruction. Yeah, so we did it in a very simple manner without having to add fragment identifiers and adding a lot more complexity. So it's very simple in the sense we are using a lock-step acknowledgment model, just like EAP-TLS. So when the receiver receives a fragment, right, it responds with an EAP packet of the same type with no attributes as an acknowledgment. So this works both the ways. Imagine the EAP request could be fragmented or the response could be fragmented, so we had to handle both the scenarios. The idea is the sender does not send the next fragment unless an ACK is received, which comes as a response without any attributes. And until the ACK comes, the sender basically keeps retransmitting the fragments. The EAP identifiers are used to correlate fragments and acknowledgments. The identifier in the EAP response must match—we had some rules basically to ensure the fragmentation and reassembly happens without any desynchronization between the sender and the receiver. So these are some of the rules that are defined: the identifier in the EAP response has to match the identifier of the immediately preceding EAP request; AT_FRAGMENT EAP acknowledgment, which is the fragment acknowledgment, must echo the identifier of the fragment being acknowledged; retransmitted fragments have to reuse the same identifier as the original transmission; for the fragmented exchanges initiated by the EAP server, the identifier of each EAP request carrying the fragment must be incremented—this is to be aligned with how EAP works today. This is just an illustrative fragmentation sequence diagram. As you can see, the initial exchange happened here on the top portion of the sequence diagram without any fragmentation, then there is fragmentation where S and 1 bits—M bits are set to 1, and the EAP response is having an ACK, and then the subsequent fragments are carried, and the last fragment has M bit set to zero, and after all the fragments are received, the peer can—the EAP client can start processing the EAP request, and the same works for the in the reverse order as well. Yeah, so we have several reassembly rules as well that the receiver must reassemble the fragments strictly in the order received and it's not supposed to process the fragmented attributes till all the fragments have been successfully received. The final fragment, as I've previously mentioned, is identified by the M bit being set to a zero, and the receiver has to acknowledge all the fragments including the last fragment because the sender needs to know that even the last fragment has been received. And the sender has to wait for the acknowledgment of the final fragment before considering the fragmented attribute exchange complete. And then the EAP peer must respond to each EAP request message containing zero length attribute payload that I just mentioned previously. These responses serve only as a transport layer acknowledgment and will not trigger any EAP-AKA' cryptographic processing. Reassembly and the security part says you can't initiate any of the USIM processing till all the fragments are received because anyway, the keying material that is passed in the EAP request or response will be incomplete, so there is no way you can process that. If a fragment is lost or not received, then the EAP retransmission kicks over to retransmit those because the ACK was not received. And the receiver must check if the sender is following the fragmentation rules, if the first fragment has to have the S bit set and subsequent fragments should not have it, right, in case if there is a—an error, right, it should—if the sender is not following the order, then the receiver can throw an error and bail out. The capability negotiation that Aritra was trying to talk about before we lost the audio was regarding to the PQC KEM is negotiated using the AT_KDF_FS attribute that was already defined in the existing specs. We had to extend the attribute header basically because the current headers were insufficient to carry large public sizes and ciphertext sizes, but this does not cause any interoperability issues because you don't—unless you negotiate that you support PQC algorithms, you would never send these attributes with which are incompatible with what was there in the predecessor RFCs which defined EAP-AKA and EAP-AKA'. So that way, I don't—we don't see any backward compatibility issues with regard to negotiating and conveying larger KEM and ciphertexts which have extended attribute format. I think the doc looks stable to us, right, I think we are—we don't have any other pending comments, but we would really love to hear from the working group if they could review the document and give us comments, and then we believe the document would be ready for working group last call. Has anyone outside of the authors read the document recently, particularly since the last IETF meeting? Hiki, go ahead.

Hiki: Yeah, hello. This is Hiki. I took a look at the document briefly, so I haven't read it fully yet. But I just had a question about the fragmentation. Is it something that could be used also other possible documents that need large messages but are not about PQC, so would it be sort of a general useful extension for other possible future uses also?

Tero: Yeah, we have made it generic enough that it could be used for other EAP methods as well. But I suggest we re-look into that and see if we can—I think we have kept all the text generic enough that it would work irrespective of whether it's PQC or otherwise. But if you think we can further generalize the text, I would be happy to do that.

Hiki: Yeah, it looked like that to me also, and it would be also useful in that sense. Yeah, it looked like that to me also, and it would be also useful in that sense. Also, for example, TEAP version 2 that is going to be discussed later in this session, I noticed that there is sort of a sample testing implementation based on WPA supplicant. Would you have something similar, because I've noticed that like there have been other EAP methods also done here or specified by this working group that have had this kind of a sort of a reference implementation available for testing or so forth? I'm thinking that if you have done something like that, that could be tested against to see how it goes, because there's quite a lot of new stuff in the specification.

Tero: Right, I don't know whether we will be able to reveal our and do the interoperability because this is pretty much used by 3GPP networks, right, but I'll look into that and get back to you if it's possible that we can do an interop. Yeah.

Speaker 1: Hannes put a note in the chat about maybe being able to help with reference implementation.

Tero: That's great, thanks Hannes. Go ahead, Guilin.

Guilin: Yeah, hey, he's Guilin from Huawei International. So actually, I also think it's interesting to see the fragmentation process proposed in the new version. But I have not reviewed this part yet, I would like to take a look. Yeah, the previous session I have a look, yeah, I think the quality is quite good already. Yeah, thanks.

Tero: Thanks, Guilin, for the feedback.

Speaker 1: Is this something we need to consider pulling out into a separate document because it's a generic capability, or would it seem fine to leave it buried inside of this one?

Tero: Yeah, I think it seems right now to get it buried because EAP-TLS also has a retransmission mechanism within it. It was not removed from there, but I don't know what it means to remove it from there and keep it generic enough. But the text and sections are written—I'll make sure like the comment that was given that we don't mention any of the PQC and say that this could be used by any other EAP methods, maybe that way it would make it a lot more easier.

Speaker 1: Okay. Anyone else? All right, then I think we are up to—thank you, Tero. And I believe we're up to Alan with TEAP v2. Okay, let's—okay.

Alan: Okay, pre-flight check. Audio, audio.

Speaker 1: Yeah, we can hear you.

Alan: Thank you. Um, so there's a bit of a recap. I did a previous presentation on this. Um, there's a lot of work put into TEAP v1, documenting what people actually did. There's a lot of differences between what RFC 7170 said and what implementations did. The key derivation is pretty complicated. Um, the solution that's being proposed is to create a TEAP v2 with largely simplified key derivations. Elliot has a preliminary implementation in HostAP and EAPoL-test. One of the things that we should do is implement all of it before publishing the spec because with the previous one, there was a lot of ideas that were put into the document that nobody ever implemented. So if we have an implementation that actually works, then we know a couple of things: one is that the workflows in the specification are correct and functional, and that there is a laboratory implementation that other people can interoperate against. The other comment, based on other discussions, was to mandate all of the allowed flows. The reason for this being, if there are features that aren't mandated, then there may be implementations which implement only a small subset, and that makes the overall features significantly less useful. The other thing, which may or may not be more controversial, is based on real-world feedback with things like EAP-TLS and fragmentation issues, we address MTU issues by simply mandating a maximum MTU for TEAP. As an example, there are issues with the Ethernet layer where you may have 8K or 9K packets, and so the supplicant can go, "Hey, great, I can send massive EAPoL frames," which then do not make it through the next layer because the next layer has no way to fragment those across Radius. Radius packets are limited in size, even though they're 4K, very often they go over UDP and fragmented UDP is a poorly tested path across the internet. Um, so fixing it to 1280 means that the TEAP implementation will fragment things without any negotiation, and 1280 seems to be big enough to be able to pass reasonable amounts of data and small enough that in most of the use cases, fragmentation will not be an issue. And that's a very quick summary. Any questions?

Speaker 1: This is your chance to ask Alan the hard questions. Otherwise, I'm going to ask you, Alan, what do you see as the next steps? I see you updated the document back in February; I don't recall anything going by on the mailing list in response.

Alan: No. Um, so there's been little discussion about this, whether that means everyone's in violent agreement or no one wants to work on it is, uh, perhaps up in the air. I know there's substantial interest from Cisco, at least, for doing this, and I know from the people I talk to there is a lot of interest in using TEAP, and people are definitely running into interoperability issues. Um, so this does seem to have at least some interest. Next step is ensuring that Elliot's implementation works, is tested. Um, once we have more confidence with that, Oleg from Elliot's team will also help, and based on feedback from other people including Peter, it seems the best way forward is rather than publishing this as a patch to TEAP v1, to copy most of the TEAP v1 text into this one and publish this as a standalone TEAP v2 so that people implementing it do not have to go back and forth between different documents. Um, that makes this document a little more complicated, but the non-controversial parts of TEAP v1 are pretty straightforward. And so the current draft is really just a patch so that we can separate the new ideas from the old ones. Um, yeah, that's it. Next in the queue, Guilin.

Guilin: Okay, thank you. So here Guilin again. It's nice, it's interesting to see this document, it is about key derivation. So our next presentation, our new draft is also about the key derivation. So I'm not very sure whether this kind of key derivation will be related to each other, so maybe later we can check, yeah, to align.

Alan: Sure. Thanks.

Speaker 1: Joe?

Joe: Yeah, it would be, you know, good to get an understanding if other parties are interested in implementing this aside from Cisco, just if we have multiple vendors then that kind of puts a little more weight behind it and more reason to bring it on as a working group item.

Alan: Yeah. I'll reach out to other people I know. Part of the limiting factor here is that there really aren't a lot of different Radius server implementations at this point, and realistically speaking, there aren't a lot of supplicant implementations, right? So if everything goes into HostAP and WPA supplicant, that covers some of the market, but at least on the supplicant side, it really is, you know, WPA supplicant, Microsoft and Apple to a certain extent. We have, shall we say, limited visibility into some parts of that supplicant framework, and then from the server side, you know, it's Cisco, Microsoft for example is not going to do a lot with NPS, so that's a different story. And the question is whether other people will be implementing it. And I think some of it is just really demand-driven from customers. Um, yeah, so if Hiki says he's going to implement it, we're going to implement in Cisco, that certainly covers a big percentage of the market. I can reach out to the Aruba team and see what they're going to do.

Joe: Okay, cool.

Alan: Okay, that's it for me then.

Speaker 1: Okay, thanks Alan. Guilin, I believe we have you up next, right? Let me get the deck up. Joe, can you swap decks? Okay.

Guilin: Yeah, okay. So the title of our presentation is "Forward Secure Re-authentication in EAP-AKA’". Yeah, so here is a very short brief history for EAP-AKA series. Yeah, in IETF basically we have four documents. The first one called the RFC 4187, yeah, it's given just the first RFC document, I believe, for mobile device connecting to networks using the credential from the USIM card. So in our document, we call this card a long-term secret key. Yeah, so re-authentication procedure has been specified as optional, yeah, in this document. So and the next, RFC 5448, it gives the improved Extensible Authentication Protocol method for 3GPP and key agreement, so this document called it as the EAP-AKA'. Yeah, so it introduced a new key derivation function using SHA-256 instead of SHA-1, mainly for security issues. So at the same time, this document also actually used the KDF, yeah, the above hash function, yeah, just to bind the key derived with the name of the network of access network. Yeah, the purpose is to limit the effects of a compromised access network nodes and keys. Yeah, and the next coming RFC is 9078. This is a further detail about how to use EAP-AKA' in 4G and 5G networks. Yeah, it specified the protocol behavior for 4G and 5G. Yeah, so here is a some detail: yeah, how to construct network name field, how EAP-AKA' actually use identities, yeah, in 5G, how to define session identities, and also exported parameters. And the last one is about how to update the requirement on generating pseudonym names and also re-authentication identity, yeah, to ensure security. And the most new document is RFC 9678, this is from Tero and other co-authors. Yeah, it introduced the forward secrecy or forward security for the key agreement. So basic idea is that just use ephemeral ECDH such that the session key will not just be decided by the long-term secret key, and it also has the input, yeah, using the ephemeral shared secret key between two parties. Of course, also together with some public information like the random number, nonces, etc. Okay. So what is the motivation for our draft? Yeah, but the one issue is that actually as remarks given in Section 7.6 of RFC 9678, so it remarked that, okay, actually the to delivery and the use of the re-authentication ID, the ID is actually delivered from the server side to the client by encryption. And the encryption key is called the K_ENCR, we may just say key, encryption key. So it is a key without forward security. So in this case, once the long-term key is compromised, in that case, attackers can actually decrypt the re-authentication ID. The ID is actually generated and delivered to client side gradually, like the first ID delivered and then the client will use the first ID, then the second ID for re-authentication will be encrypted and delivered to the client again, and the server can use the second one again and then the third one, yeah, something like this. But here is the issue, yeah, if the encryption key for the re-authentication ID is compromised, yeah, can be derived by the attacker just from the long-term secret key, in that case, all these different rounds of re-authentication can be linked together. Yeah, so in this section, the authors comment that if the pseudonym linkage risk is not acceptable, one way to avoid linkage is to always require full EAP-AKA' authentication. Yeah, but the problem is that re-authentication is much faster than full authentication. So if we do like to actually keep the efficiency using re-authentication or sometimes we call fast re-authentication in that case, yeah, so maybe we can consider how we can do better. Yeah, so the proposed solution in our draft is that we would like to specify an update to the RFC 9678; it actually also applicable to the previous documents for EAP-AKA' and EAP-AKA. So this update just in forward—just update the forward security for called the transient EAP keys. Yeah, of course, it including two keys: one is just we re-mentioned, yeah, for the encryption key for the re-authentication ID, together another key for integrity called the K_AUT, yeah, authentication key. Yeah, because both of the key will be used in the re-authentication procedures, yeah, either for encrypt the re-authentication ID or probably for the get the integrity protection for the re-authentication procedures. Both of the keys are related for the forward security. Here we—in the next slides, I will mainly re-mention about the why this is important, yeah, to keep the forward security for the encryption key, but it's similar for the integrity key. If the integrity is not forward security, we will have a similar issue because the attacker can use the compromised integrity key to check whether the MAC value is actually a particular valid one, yeah, which with respect to the particular K-authentication key. So it is the same. Okay, so based on this one, so re-authentication after a full authentication will be unlinkable to each other. Yeah, so this can be good to provide better privacy for end users. So we proposed actually this is just an optional feature for the above methods. Okay, next we'll go to a little bit detail. So this is the original how actually EAP-AKA' can be update for forward security for key exchanger part. Yeah, it's from the RFC 9678. So from here in the left side, the protocol procedure, we can see there's two part underlined. This is about the public key from the server side, yeah, to the user side and from the user side to the server side. Just from these two ephemeral public key from both side, so both side can derive a shared secret. And then the shared secret, highlighted on the right side, it is about the key derivation. So once you get this shared secret, yeah, from running ephemeral Diffie-Hellman, so you can derive the master key called the MK_ECDHE. Then you can get some session keys. This kind of session keys has the forward security. But the problem is that the two keys for doing re-authentication called the K_ENCR key and K_AUT for integrity, both of them just derived from the long-term secret key—no input from the shared secret key. In that case, as we just mentioned, these two keys called the TEK keys are not forward secure. Yeah. So next we will show a little bit more why this linkage attack is available, as noted by the RFC 9678. Yeah, the right side we mentioned information, yeah, the right side is just a procedure how actually re-authentication procedure from the protocol viewpoint. So we can see it is once the long-term key compromised, the attacker can know or can derive K_ENCR key and K_AUT key, then use these two keys, the attacker can decrypt the next re-authentication ID. This attribute, yeah, is actually encrypted by use the K_ENCR key and also can verify whether MAC value is actually a particular valid one, yeah, with respect to the particular K-authentication key. So multiple re-authentication rounds can be linked together. Yeah. Okay, so next going to our proposal, yeah, what we can do, how we can update the key derivation part. Yeah, here is the proposal one: the left side is still the key derivation message from 9678 and the right side is the proposal from our draft. So in our draft, basic idea is that we still have the original K_ENCR key and the K_AUT, but at the same time once we get the shared secret key from running ephemeral DH, then we will also derive an update version for these two keys. Yeah, so in that case, yeah, we have two versions of the K_ENCR key and K-integrity key. So for sending the re-authentication ID and to do the authentication for re-authentication procedures, we just use these two update keys with forward security, yeah, such that no more linkage attack is available. Yeah, so this update also apply to the following two PQ extensions to RFC 9678. Yeah, the main author is Tero, as you may know, Tero also just presented the one of the draft for the hybrid key exchange, so it is the same. Yeah, so 9678 is using ephemeral Diffie-Hellman, and these two drafts using either just pure ML KEM or hybrid ML KEM. Yeah, so our draft actually the key derivation can be used for all of the three documents as well. I think that's all. Yeah, we hope your review comments, yeah, thanks. Any questions? Go ahead, John.

John: Yeah, I think the analysis is correct and I think the solution works. We would need to read more detail and think about if it's worth doing and so on, but yeah.

Guilin: Okay, great. Yeah, thank you. So we will also consider how to actually integrate in the EAP-AKA' protocols, maybe some issue together, yeah, but main idea should be quite clear. Yeah, thanks a lot.

Speaker 1: Tero.

Tero: Thanks, this looks like an interesting draft and I agree at least with the problem. I need to analyze the solution, but I'll review the draft.

Guilin: Okay, thank you Tero.

Speaker 1: Anyone else? All right, then thank you Guilin.

Guilin: Thank you, thank you all of you, thanks.

Speaker 1: All right, so Tero, you're up next, I believe, with the PQ updates for EAP-TLS and TTLS.

Tero: Thank you. Yeah, thanks for giving the control on the slides. I'll—yeah. This draft was presented last year, and we did some changes to this draft, so I thought I'll recap what was presented last time and get a feedback from the working group how to progress on this. I think by now everyone in this working group knows that when cryptographically element quantum computers come, they're going to break the traditional asymmetric key algorithms. It's especially going to impact EAP methods which rely on TLS, EAP-TLS and EAP-TTLS, and TLS has already been enhanced to address various of these threats. So this draft is trying to do some recommendations as well as modifications to EAP in a way that to address the challenges to this PQ migration. Just just for a quick recap, there are two problems with CRQCs: one is the harvest-now-decrypt-later attack, which happens because somebody stores the entire TLS handshake transcript and then later decrypts it to get access to both the handshake and the messages that were exchanged. The other one is when CRQCs become available, they could act as a—they could spoof the identity of the EAP client or the EAP server, and you could be connecting to a rogue access point, or the network would be allowing a rogue entity to join the network with falsified credentials because they could easily spoof the client's certificate. So why is this important for TLS 1.3? TLS 1.3 encrypts most of the handshake, and there's an RFC in EAP which talks about the privacy properties that gives in. For instance, the client identity information which includes the client identity name, username, device or organizational identifiers are all encrypted today. But with harvest-now-decrypt-later attack, the attacker would be able to extract the client identity information. The bigger threat is with regard to EAP-TTLS which carries the inner authentication credentials like MS-CHAP, and and that would all be exposed in clear for the attacker, for instance, to try offline password attacks. The other problem this draft is trying to solve is PQC signature key sizes and signature sizes, public key sizes and signature sizes are much larger than traditional algorithms. And that's documented as one of the problems in RFC 9191, which talks about multiple round trips, fragmentation, and basically the EAP session being dropped out as it is taking too long to complete. For instance, if you take ML-DSA-65, which is with let's say three intermediate certificate chains, each the entity cert itself would take around 7 kilobytes, and if you add the additional three certificate chains, it would run into somewhere around 16 to 21 kilobytes. The other attack is—this is not an imminent attack, this is going to happen eventually in the future when CRQCs are popularly deployed. The CRQC can compute the client and server private keys from public keys in certificates much before the certificate expiry, and for instance, they could spoof the access point so that the endpoints can connect to these rogue access points. So the draft has three recommendations. One recommendation is straight away coming from the work happening in TLS, which is preferably pick hybrid as that one gives defense-in-depth security, right? Or else you can pick the pure KEM. And then depending on the time for migration, right, I mean if it takes time for you to update your certificates and root of trust, then you can plan ahead of time and then plan whether you want to go with composite certificates or go to pure PQC certificates. And then and then it discusses few recommendation on certificate chain optimization to avoid fragmentation. So this is what the draft recommends: that there are two paths for migration—one is the one that NIST and IETF and the industry is recommending to go to hybrid and then eventually at a later point of time when the industry has confidence in pure PQ, then migrate. But there are some regulatory and government agencies like CNSA provided by NSA asking to directly migrate from PQC to pure PQC from traditional. And the same goes for certificates as well, right? You have a transition path, the PQT composite certificates is is done in LAMPS working group, is is in IESG review and it's going to become an RFC, so there is a transition path that if you don't have confidence in PQC certificates, then you can try PQT composite certificates for similar defense-in-depth security and then eventually plan the transition. The most important optimization that this draft talks about is how do we prevent the exchange of the intermediate certificates' exchange during the TLS handshake? So this basically talks about a mechanism that you would use the EAP EST server to out-of-band request the intermediate certificate chain. So this document defines two URIs basically: one for the server to retrieve the client intermediate certs, and the same goes for for the client as well to retrieve the server's intermediate cert chain. So once the retrieval is done, basically the client and server can proceed and not exchange the intermediate certs during the TLS handshake, and the only overhead would be the end-entity certs which will have to be exchanged, but then you could save several round trips and fragmentation other challenges because all your intermediate certs are not transmitted in the TLS handshake. We got some feedback from the working group on this document; we have addressed those, and we believe this is quite important for networks which use EAP-TLS and EAP-TTLS with the imminent attack from post-quantum cryptography, and we would request a working group adaptation call on this. Thank you. Has anyone taken a look at the document recently? Alan, go ahead.

Alan: Sorry, hit the right button, thank you. Um, I have not read the document recently, but I do have questions about fragmentation. And this is not just for this method in specific, but in general. If there's a way to address fragmentation, I think that would significantly help with adoption. So either a generic EAP thing, which may be difficult, or if it's possible for these drafts to address fragmentation directly, I believe that would significantly help with implementations and interoperability.

Tero: Thanks, Alan. EAP-TLS already defines a fragmentation and reassembly mechanism, but even if the intermediate certs are skipped, ML-DSA itself could be carry—could be around like 5K then in that case fragmentation itself cannot be avoided, but EAP-TLS does take care of fragmentation and reassembly.

Alan: Sure, but the point there is is if you have issues with, uh, the local Ethernet having say 8K MTU as I was saying earlier, EAP-TLS does handle fragmentation at the EAP layer, but there's no way of discussing or negotiating MTU across any other layer. So you could have the supplicant send 8K EAPoL packets and then they just can't get across the network. And that's why the earlier discussion for TEAP v2, the mandate was that the TEAP v2 packets themselves are no more than 1280 bytes. Um, and that should address subsequent Radius UDP whatever fragmentation issues too. So this is just something to be aware of.

Tero: Okay, that's a—that sounds like an interesting good point to add to the document. I'll take care of that, thanks.

Speaker 1: Hiki.

Hiki: Yes, so Hiki. I yesterday I did a quick test with EAPoL-test that is compiled against latest OpenSSL, which implements for example X25519-MLKEM-768 hybrid key agreement. So I think a lot of let's say at least the key agreement part already comes if we just use a recent enough TLS implementation. So I was thinking that how much would we need to specify separately here and how much can the TLS implementations just give us already if we just use recent enough TLS. For example, at the moment I'd say that recent enough EAP-TLS and EAP-TTLS clients and servers already have solved the first problem because they can use the hybrid key agreement methods. So I was just thinking that is there a possibility that we sort of specify things that are done already within the TLS working group for example or related working groups?

Tero: Thanks, Hiki, that was a good comment. So if you look at the document, right, this does not—this refers to the work that is already happening in TLS and the optimizations that were done in TLS, for instance, not to send multiple PQC public keys within the key share, right? Those optimizations are already covered in other drafts and specifications, so the draft just refers to them for optimizations and does not give any new recommendations for key exchange at least beyond the ones that the industry has already tested and discussed. And there's a working group adopted document in UTA which talks about all these optimizations especially to avoid larger client hello messages, especially to avoid multiple PQC public keys. I think that's—that's where I think you might have seen that the size of the client hello may not have fragmented beyond one—more than one packet, especially if it's 1500. But for—but for ML-DSA, I believe I don't think there is any deployments that are there in the market, and and the fragmentation is is something that cannot be avoided.

Hiki: Yeah, true. The certificates I also tested some time ago with ML-DSA certificates and they are really big and this work on the authentication side is really interesting to avoid having transfer all the long certificates. Thanks.

Speaker 1: Joe.

Joe: Uh, yes. And and I'm a little bit behind on 802 and advances there, but at least at—and this may have already been discussed and I may have just missed it, but at least at some point like the—one of the things that might be interesting for the harvest-now-decrypt-later threat is if the keying material from EAP-TLS can be used in the lower layer to in—in some kind of key mechanism to encrypt data in the lower layer. And so if that—I mean depending on how that is—how that key is used, if if that key is vulnerable to decryption at some point, then you know if you capture say the Wi-Fi traffic you might be able to decrypt it. Now probably the 802 group is working on some thing or has already something to fix that, but it may not be widely deployed yet. So that might be another threat vector for encrypt-now—I mean harvest-now-decrypt-later.

Speaker 1: Right. I'll jump in here, Joe, and just mention that 802.1, I talked to them about that and, you know, they're supportive of of the PQC work that's being done in in the TLS working group. They don't I think as far as I know have any plans to do anything particular in .1X. And then 802.11bt is looking at PQC for Wi-Fi and they're basically going to rely on both, you know, draft-ietf-tls-mlkem and then they're also looking to see that there is a a matching EAP-TLS implementation because for their CNSA 2.0 requirements, they're basically just going to point at 802.1X, so it's basically comes down to us giving them something.

Joe: Yeah, so then I'd say like that's probably something you should mention in that draft. Given—there may be depending on what 802 does, it may make some difference but at least now like you would have potentially your traffic, your Wi-Fi traffic is vulnerable or whatever protocol it is. Thanks.

Tero: All right, yeah, I'll do that, thanks.

Speaker 1: John.

John: Thank you. Um, I think if EMU makes a PQC document like this, I think it should concentrate on things that are specific for EAP, but that might also that might also be my personal preference. It's—I think you should more refer to PQ-in-TLS for generic things, but you can also of course have the opinion that you should duplicate the work. I think the scope here is EAP-TLS and EAP-TTLS. I think the scope should be either all EAP methods or all EAP-TLS based methods. There are more EAP-TLS based methods than these two. I don't see why you would restrict it. These recommendations I think if you do a document like this, the recommendations will probably apply to all EAP-TLS based method and maybe all EAP methods that use public key crypto. Then some part seems to go before the TLS working group; the TLS working group has not started working on hybrid certs, unclear whether they will. The last thing I saw from the TLS chairs was much later.

Tero: Thanks, John. Yeah, especially on the TLS, right? I mean this document is trying not to reduplicate the work that's already happening in TLS by just referring to the documents there, and so many of the documents are adapted, especially the hybrid key exchange and the pure ML-DSA ones, right? But the hybrid key exchange is already adapted and I believe it's already in the RFC editor queue I believe except the hybrid certs. So hybrid certs still is an individual document that this draft is referring to and hoping TLS will will pick it one day or the other. But beyond that, we—this document does not go into any recommendations beyond what TLS and UTA working group are doing. The only specific one that it is asking to do is these are the TLS profiles that are being defined in TLS and you pick which one suits you, and then it talks about the optimizations like the one in the last slide that you would want to use to reduce the overhead. But yeah, I'm pretty sure we can we can review it and give more suggestions. But I agree with your line of thought.

Speaker 1: All right. Looks like there's a lot of agreement in the chat for making it all TLS-based EAP methods.

Tero: Yeah, I like the suggestion from Alan, right? I mean the certificate optimization is is probably predominant for PQC, but it still could be used in existing deployments as well. So yeah, I think we can add a line or two that if existing deployments are facing challenges, right, they could consider this optimization for the for the EST modifications. Is that something we're going to need to run through the LAMPS working group or something we we can get away with here? What do you think?

Tero: Uh, I think I think at some point of time after adaptation, right, we should definitely get it reviewed from the LAMPS because EST is being covered in that working group. But I'll leave it up to the chairs on how we coordinate with the LAMPS working group chairs.

Speaker 1: Yeah, I think if we decide to go down that path, I think we would want to coordinate. Um, but it might be something to evaluate later. Like maybe there are other methods for distributing cert chains out there, it seems like there should be—I mean this might be a very convenient one for us, so it may make sense, but there might be other options as well.

Tero: Right, and there are other options, I'd definitely like to hear and update the draft.

Speaker 1: Okay. Michael.

Michael: Um, so RFC 8995 first created or a registry for that EST thing with a bunch of rules, um, and then later changed it all to wind up in a BRSKI registry instead. Um, and actually we did all that without talking to LAMPS, but of course you could talk to LAMPS. I think the only thing you'll need to do is is—the question is, I—there isn't a registry right now, so you'll have to create one, is what I would say. There's no IANA rules on that piece of well-known. It exists in 7030 only. That's all. I don't think it's impossible and I don't think you need a big coordination effort with LAMPS, you just need to tell somebody.

Tero: Thanks, Michael. That reminds me of ANIMA using this work, so thanks.

Speaker 1: All right. Anyone else? Hannes, did you want to make your comments verbally?

Hannes: Um, I could, briefly summarize. So I think this work that Tero is doing is quite important and it will have to be done sooner or later anyway, like I don't see a chance that we get away without specifying or describing how PQC-based algorithms are used in EAP-TLS and EAP-TTLS. Um, and as John suggested, like focusing on all TLS-based methods in one document seems like a fine suggestion.

Speaker 1: Tero, does that sound like something you'd be willing to take on?

Tero: Yeah, I agree. I mean I agree with Hannes and this document is written very generically for all EAP-TLS and EAP-TTLS documents, but if there are any other methods which are trying to use asymmetric cryptography beyond EAP-AKA', right, I can definitely look into that and see what can be added. But we just wanted to restrict this for any EAP method which uses TLS.

Speaker 1: All right. Looks like there's a lot of agreement in the chat for making it all TLS-based EAP methods.

Tero: Right, and there are other options, I'd definitely like to hear and update the draft.

Speaker 1: Okay. Michael.

Tero: Thanks, Michael. That reminds me of ANIMA using this work, so thanks.

Speaker 1: All right. Anyone else? Okay, well, I think that brings us to the end of our meeting. Thank you, everyone. I appreciate your participation. I hope you'll enjoy the 55 minutes or 54 minutes that you're getting back from this this time slot. And we will take discussions to the mailing list in terms of what gets adopted, what changes need to be made, and things like that. So, thank you.

Tero: Thanks, everyone. Bye.

Speaker 1: Bye-bye. Bye-bye. And thank you again, John, appreciate you sitting at the head table.