Session Date/Time: 19 Mar 2026 08:30
Valery Smyslov: Okay, it's 14:30. So, we can start. Hello, everybody. It's Radext session. A few people are in the room, and please, for those who are in the room, don't forget to scan your QR code on the beginning, so that you are attending the session. My co-chair, Margaret, is remote, as well as our AD. So, we have change in our personnel, so Paul is stepping down, and Christopher will be our responsible AD since then. And so, for today's session... Well, this is Note Well, and perhaps you already know it very well, because you have... You must read it when you registered to the IETF meeting. So, the session is recorded and all your contribution is subject to IETF IPR rights. IPR. So, this is the IETF Code of Conduct. So, in short, please behave professional, respect others, and... So... Meeting details. So, these are links to the slides, to note-taker, and to Zulu... Well, actually, we can have... We can use Meetecho chat. So, we have to perform a couple of administrative tasks. First of all, we need volunteers for note-taking. So, any volunteers?
Speaker 1: I can help if you want.
Valery Smyslov: Okay. So, thank you. So, just open Notepad.
Speaker 1: Yeah.
Valery Smyslov: Okay. And for agenda, we have quite enough time for today's agenda, so we are not in a hurry. So, let's start with the first presentation. It's a little bit update for the status. The RadSec draft is sent to the ASG. It has passed ASG evaluation, but there are three discusses, so the comments from ADs that need to be addressed. So, I believe that Jan-Frederik will go through all these issues. So, I will just... Just a moment, I will pass slide control to you. Okay.
Jan-Frederik Rieckers: That looks great. Thank you. You can hear me fine in the room?
Valery Smyslov: Yes.
Jan-Frederik Rieckers: Okay. Just making sure. Yeah, so our RadSec draft is finally in IESG review. So, I want to give a quick update and discuss any open issues that we have, and apologies for misspelling Shenzhen. I did not feel the need to push an update just for this. So, what happened since our last interim? We had the interim where we discussed some changes to the document, as well as the new agenda for Radext, or the new charter for Radext, sorry. And we have pushed the document to the IESG, and the IESG had some discusses. So, first, what we changed before, or what we already changed in the editor's copy on GitHub. It's not yet in Data Tracker because I was one day too late with the draft cutoff, and then we felt it wasn't needed to push this update, especially since new discusses had come in. So, first we added a text for ALPN. The text is basically compatible with the RADIUS 1.1 document. We added an IANA request to update the ALPN RADIUS 1.0 to this document. So, basically, if you signal RADIUS 1.0 in ALPN, then you mean we do RadSec as defined in this document, and if you signal RADIUS 1.1, then you mean the RADIUS version without obsolete crypto.
We had the discussion again about when to reassess the connection validity if the trust base changes. We've now changed it to a MUST, because we could not come up with situations where the SHOULD could be ignored or should be ignored in a reasonable manner. So, we just changed this to MUST. If anyone has objections to that, speak now or forever hold your peace. And one comment, and I'm a little bit embarrassed that that slipped by me, is at some point we spoke about IPs and we really meant IP addresses, and we've changed this in the document as well as port and port numbers. So, these are the changes that are already in the editor's copy ready to be pushed once we publish a new draft.
We had, or we have, three open discusses with four comments. The other IESG votes are no objection with maybe some comments, and we will address those comments as well. But first, the discusses. Éric had a discuss about the text what clients have to do when they open up a connection. What we say is when clients connect, they MUST establish a DTLS or TLS session immediately. Éric's comment or discuss on that was that it's not exactly clear what is meant, and proposed standards should be crystal clear about what we mean, especially if it's a MUST. And what we mean is don't do any negotiation beforehand, immediately start the TLS handshake. So, the suggestion from Éric was to add something like "without any non-protected negotiations such as SMTP STARTTLS," because that was what I used as an example of what we don't want. If anyone has a better idea of how to word it, please feel free to add a pull request on GitHub or put a suggestion on the mailing list. Otherwise, I will probably come up with a suggestion on how to word it in the next few days.
The next open discuss is the 5-tuple versus connection ID for DTLS session tracking. This was from Mike Bishop, a discuss. What we actually say in the previous section is that servers MAY choose the 5-tuple to track DTLS sessions, but others, other methods such as CID, are still allowed. I don't think we explicitly mention CID, maybe we could do that. But the next sections are only mandatory if you actually choose the 5-tuple as a connection tracking mechanism. So, maybe this should be made more clear, that the following sections are only applicable if you choose the 5-tuple and other methods should choose a similar method that has the same security properties, especially if to check if the correct originating IP address is met, because otherwise a connection could be opened up from an allowed IP range and then migrate outside it, and that's not something that we want.
Then we had two discusses from Gorry. One was regarding accounting delay time and event timestamp, one of our favorite topics. And Gorry asked why this was only recommended and not mandated, and at least we should explain under which circumstances it's still acceptable to use accounting delay time. My opinion is we can't mandate it because it would break existing implementations, and unnecessarily so. So, one idea would be to add an appendix with a bit more detailed explanation of how exactly using accounting delay time in a bad manner can contribute to congestion. That was another comment from Gorry, that we should not use "such as cause congestion" or "lead to congestion" but only "contribute to congestion" because it's not absolute. The other comment was on the PMTU text. So, the PMTU text is not clear on why this is an issue. So, also, same as the accounting delay time, maybe we can add an appendix detailing why path MTU discovery can help at least a little bit and how this would help, especially in proxy environments, just to explain why our standard is written in the way it is written.
Then we had a lot of comments and nits from IESG members apart from these discusses. The discusses are something that we definitely need to address, the other comments we should definitely address. My plan is to sort through all the comments. We want to reply to the IESG members on all comments and address the open issues if they need addressing. Most of them can be addressed quite easily. Some may still require some more consideration. One general comment also from Éric was that we have a lot of SHOULDs in the document without an explanation. And he referenced the IESG statement about when to use SHOULD and how to use SHOULD, and it says every SHOULD should also have an explanation under which circumstances it can be ignored. So, why is this a SHOULD? Why do we recommend it, and under what circumstances you can go around this recommendation and do something else and what are the implications? Because a SHOULD, according to BCP 14, says you should do it, but if you have good reasons, then you can do it otherwise if you understand all the implications, and to understand all the implications, we need to say what the implications are.
So, the next steps toward final publication as an RFC, to get it through the IESG and then to the RFC editor. Of course, we have to address the open discusses and comments. We will fix the editorial nits. Most of them are editorial nits. And then we will publish a -16 version of the document. My plan is to push this when most of the comments are addressed, ideally within a few days after this IETF. So, if you have time, please read the comments from the IESG, comment on pull requests when we open them on the editor's copy GitHub repo—put a link in the slides as well. And we will track the issues that need discussion as issues or pull requests on GitHub to not overlook any issues that we might still have. And that is the end of my slides. Yeah. So, if anyone has comments on what I just said on some of the discusses, now would be the time.
Margaret Cullen: So, one possibility for the PMTU stuff is to just yank it out. I mean, we keep going around and around about it, and it doesn't have to be in this document. I'm surprised that Gorry, who I know has done some UDP work, doesn't understand immediately why every UDP application that could need to send large packets has this problem. But... but it doesn't technically need to be in this document. This document does not actually make it any worse. The problem is about the size of the EAP messages sent by clients over EAPoL and the fact that we need to get those into RADIUS packets and size of certificates and so forth. It's not really specific to RadSec. So, one possibility is just to yank it... I mean, we've talked about it so many times and we never seem to get to something everyone's happy with, and maybe the answer is not say it here, I don't know.
Jan-Frederik Rieckers: Would be one... one option. Maybe put this on the agenda for the proxy BCP document, because we should still say something about it. But yes, and the only thing that this document makes... worsens the situation is by adding the overhead for DTLS. Other than that, we don't really add more issues.
Margaret Cullen: Yeah, and it would make sense probably to move it just to the proxy BCP document where we're already talking about that kind of operational advice that's more general than just RadSec.
Christian Giesee: Christian Giesee. Yeah, I would just... I see it exactly the same. It doesn't make anything worse if we do RadSec with UDP compared to not doing RADIUS security with UDP in regards to the MTU. So, I don't see that this has to be a very large topic here. It's no difference if it's... we had it before, we could have too large packets and fragmentation, so... yeah.
Valery Smyslov: So, what is the plan? So, Margaret, if you disagree, please correct me. So, I think that we should, as Jan-Frederik suggested, to publish a new version with non-controversial changes, and perhaps if there are any changes that require more discussion, the working group mailing list, please, Jan-Frederik, can you please post them to the mailing list too? Because it's an official place where discussion should be taken besides GitHub. GitHub is... is a very good thing, but still we have to discuss them on the mailing list. And also, please respond, you or Margaret as a co-author, please respond to discuss messages from ADs explaining what we're doing to address the discusses. And once that is done, well, I hope that we don't need another working group last call. So, Margaret, what's your opinion?
Margaret Cullen: Normally we wouldn't have another working group last call at this point. It's just about fixing things up. Most of them are all almost editorial, really.
Valery Smyslov: Editorial, yes, okay. I mean some less editorial and more technical stuff. But once we, well, make all these changes and responded to all discusses, I hope that IESG directors that have discussed clear these discuss... their discusses and the document will go through. Just not leave the pace, so because the document is for a very long time in development and we should finish it. It's very important, and we're all waiting for them. So, Jan-Frederik, Margaret, please, please, please. Margaret, are you agree with this?
Margaret Cullen: We will, I mean, we will send everything that we change... Well, everything substantive that we change will get sent to the working group in responses to those discusses. So, if people don't like what got done, they should speak up. I'm not saying the working group shouldn't one, know what is happening with the document, and two, get to say if they don't like what we do with it. But I don't... it's not my feel right now that the changes will be big enough to need another working group last call because they're mostly tuning and detail-oriented stuff, not... not really big changes.
Valery Smyslov: Okay, I agree. So, let's hope that we will finish this document quickly. Okay, next presentation, "Deprecating Insecure Practices in RADIUS." So, Alan... Can I jump in right before the... with regards to those changes, which is, if the chairs can like provide me and Paul some kind of statement from what I saw, the changes were mostly about refining kind of the justification for the choices made, not making a new technical choice. So, it's more exposition about those choices. If you make a technical change in how something works, that's a different thing. So, right now, from what I've heard and seen, I don't think it needs another working group last call.
Paul Wouters: Yeah, that's also what my interpretation was.
Valery Smyslov: Okay, thank you. So, next, Alan.
Alan DeKok: Yes, hopefully audio and all that works. Welcome, everyone. Deprecating insecure practices. One of the biggest changes is the document has been split up into multiple pieces because it was not just big, but it tried to do a couple of different things. So, the review of RADIUS security and why the particular choices for Blast RADIUS were done are in the review document. This one simply mandates the new behavior with very, very little explanation—just "you have to do this, you have to do that." And then any of the BCP stuff is split out into the proxy BCP, which perhaps depending on what we need from it could be operational considerations or something. My main concern with that is that document may get big.
So, the changes since the last IETF, a lot of typos, wordsmithing, checklists—which are not really necessary for operation—have been moved to the appendix. I added text on rate limiting based on some offline discussions with people. Whether or not we need to keep that in is up for discussion. The issue is that while 802.1X requires that the authenticator, which is the access point, limit the number of packets sent for one supplicant, in practice that doesn't happen. And operationally, we've seen systems send thousands of packets a second. And independent of any 802.1X issue, I would argue that because the users are completely unauthenticated in RADIUS, they can make the access point's RADIUS client, whatever, send packets to the server or across proxy networks at arbitrary rates. And this is effectively a DOS attack. The reason this hasn't been a bigger issue is no one's actually done it. But in practice, if you had 10 people worldwide with very, very badly behaved supplicants, you could take down good chunks of most of the roaming networks. So, it would be good to add some rate limiting here. And any questions? I tried to keep that very, very simple and short. Margaret?
Margaret Cullen: I vote yes. The... it's not... it's actually not... I, for those people who don't know, I work with Internet2 on running the US eduroam service. We've never seen an attack, but we have seen cases where something happens, like an IDP, one of the universities or research institutions in the US, has a power outage and their RADIUS servers are offline and their clients retry like crazy. We eventually detect that they're dead, so our proxy is answering immediately saying "reject," access reject, and they are coming right back with a response. This is kind of a known... I don't want to say bug because it may have been intentionally written this way, but a known bad behavior of quite a lot of clients that are out there, that they will as quickly as they can get back an access reject, they will send another request. I've heard from Alan DeKok actually that the IEEE specs say that they should be limiting themselves to five requests a second or something like that, but they aren't. I've seen 600 live on my network, people doing 600 a second. It's... and when you get a dozen or so of those people who happen to be roaming from an institution that's offline, that starts to add up to quite a lot of traffic. And rate limiting those... that traffic doesn't do anything bad. Okay, they were doomed to fail, and so rate limiting them, dropping their packets instead of trying to forward them, does not actually stop anything that should work from working. In fact, it allows things that should work to work. So, I'm in support of adding discussion of this to the document.
Christian Giesee: Christian Giesee. Yeah, from me there are two points. One thing is we obviously implemented rate limiting on the client to protect the servers, which is a common thing if you have heavy BNGs. But then in these rate limits we differentiate between the rate as the PPS and the number of outstanding requests. And for me, the number of outstanding requests is the more important often. So, if we say rate limiting, I was asking myself do you talk here or we have to be explicit about rate limit in PPS and the rate limit or the limit of outstanding requests from a client, which last one is actually the more important one for me.
Alan DeKok: Either one. I put some text in there about number of packets per second, but practically speaking, limiting the number of outstanding packets is likely a lot simpler to implement and has much of the same effect.
Valery Smyslov: So, Alan, this document is a working group document. So, what's your plans?
Alan DeKok: My plan is to update it as quickly as possible, get it out for a working group last call. I believe given especially things like the Blast RADIUS vulnerability, what I would like in an ideal world is to get this document out as quickly as possible, the review of RADIUS security one accepted as a working group document out as quickly as possible, and then we could publish TLS-bis and these two at the same time, which is basically, we have TLS, it's now a standard. Next document, we have to use TLS and stop all the insecure practices. And then the next document, here's why RADIUS security is so terrible. Or even maybe have the review one as the first document to help motivate it, and that way they're all in a cluster and it becomes more obvious that this is a problem and that everyone has to fix it.
Valery Smyslov: Okay. And there is another document from Alan also related to review of RADIUS security. It's next presentation.
Alan DeKok: Thanks. So, this document was split from the deprecation document, which was accepted as a working group document. I updated it as per some reviews. Some of the problematic text was deleted. The one thing I did add to, I added a deeper analysis of things like MS-CHAP and even CHAP password. The interesting thing I took a look around for security analysis of CHAP, which is MD5 of an eight-bit random number plus a password plus a challenge. There didn't seem to be much in the way of analysis of that. And my basic analysis after about five minutes of looking into it was the only real difference, the only real problem with CHAP was you had to create... sorry, let me back up. If you're going to do dictionary attacks on CHAP, you have to create 256 dictionaries because of this initial ID. That's just disk space. If you want to crack CHAP password, you create these 256 dictionaries of pre-hashed IDs and passwords, and then you simply run them through the CHAP password that you have with the challenge, and you should be able to run through billions of test passwords a second. So, there is the ASLEEP attack on MS-CHAP from years ago which could crack most common MS-CHAP passwords in milliseconds. Based on very, very simple analysis, it looks to be the same for CHAP. So, the document now says that you should consider MS-CHAP and CHAP as sending the password over the network in cleartext, as being entirely equivalent. And yeah, I have not seen any analysis of CHAP published before because I think it's MD5 and nobody cares. So, that's about the only real change to the document. It needs review from more people and maybe minor touch-ups. But again, I'm happy to get that done as quickly as possible in the interest of publication.
Valery Smyslov: Currently, it's an individual draft, but it seems that it's better to issue an adoption call, because this document is supplemental document for deprecated insecure RADIUS. So, Margaret, your opinion on this?
Margaret Cullen: I agree. Let's... let's make an adoption call. I mean, it is something people have reviewed this text whether they think they've read this document or not, because it was in the previous document that was accepted by the working group. So, I think we could probably make the working group adoption call today. The... you know, I mean, sometimes when you split a document, you just make both of them working group documents right at the same time, but we didn't, and so I think making the call will make it clearer.
Valery Smyslov: Okay, we are in agreement here. So, next presentation is Syntax for RADIUS Connect-Info. This draft is from WBA and currently Radext working group is going to recharter to be able to adopt several documents for WBA that are waiting for Radext working group for reviewing them and publish as RFC. So, Mark, please go ahead. You have slide control.
Mark Grayson: Hi, can you hear me okay?
Valery Smyslov: Yes, we can hear you.
Mark Grayson: Cool. Well, yes, so this is just an update on Connect-Info and I guess the first update is welcome to Joey on the contributors. Joey's from Helium and Helium is one of the early adopters of the Connect-Info syntax. So, the background for those who haven't been following, we presented at 121, 122, and 124 back in September. Valery sent out an email about putting it as a candidate for working group adoption, obviously with the dependency on rechartering. We discussed in Montreal the feedback on the candidate for working group adoption email thread. So, there was rough consensus that there was support for formalizing the syntax. There was some discussion about health warnings about complex data types. There was a focus... a recommendation to focus on the Wi-Fi connection specifics. That was both on the call for adoption email thread, but also there was a parallel email thread on Hostapd around the specific key-value pairs. And then there was some discussions about how to deal with legacy. So, just those updates addressing those updates, and apologies.
So, we call out the complex data types. Obviously, 6158 says that we discourage from defining new complex data types, and we argue that this isn't defining a new complex data type but rather it uses the current definition of Connect-Info, which in itself specifies a complex data type and also current implementations. The syntax differentiates between those legacy attributes that are used today in basically all Hostapd implementations, which start with connect-802.11b at 11 megabits per second, with the new key-value pairs which are related to the connection themselves. That's the second change. The third change is that all non-connection related key-value pairs have been removed from this draft. There was discussions about how we are going to address those in the future, but just in terms of this draft, it's purely focused on the 802.11 connection aspects which are between the AP and the station.
And finally, there is a new security section related to RSSI. We're reporting RSSI and RSSI can indirectly be used to infer a relative location of the user relative to the access point. If we are sending the access point location in 5580, then obviously we can use a combination of 5580 and RSSI to get a more precise location of the individual and therefore we have additional security considerations around signaling RSSI. So, that is the update. Obviously, subject to the rechartering as Valery said, that we'd like to have this adopted as a working group document. We'd welcome further feedback from anyone on the latest draft, and obviously looking forward to the call for adoption moving forward. So, that is the update on Connect-Info. Thank you.
Valery Smyslov: Thank you, Mark. And as far as I understand, the draft is mostly ready. Is it?
Mark Grayson: Correct.
Valery Smyslov: So, we are just waiting for our rechartering, then we quickly adopt this draft because it has already positive feedback for the candidate for adoption, and then we can directly very quickly go to working group last call. In the proposed charter, we marked all the WBA documents for the milestones for all WBA documents in August. Do you think, do you agree that is it feasible from authors' point of view? Okay, thank you.
Margaret Cullen: Yeah, I... I think we're still on target for, assuming the AD change doesn't affect this, but... because I don't even know if Chris has gotten to read our new charter yet, but... I think we're still on target from the interim discussion of getting rechartered around the end of April and being able to then adopt these documents and get them into last call, you know, hopefully by around the next IETF and resolve any issues then. So, I think August still makes sense.
Valery Smyslov: Yes. Okay. So, next presentation is also for individual draft that will also wait for new charter for adoption call then: the Protocol-Error specification for RADIUS. So, Alan, please go ahead. You have slide control.
Alan DeKok: Thanks. So, this was presented earlier already. There haven't been substantial changes to the document, and I think this one will take a little more time to discuss. As background, there's lots of parts of the protocol which say, "you know, if you received a packet and you don't know what to do with it, you just throw it away." And then the client has no idea what's going wrong. So, it would be useful to be able to signal a generic NAK saying, "Hey, I got your packet, but I don't know what to do with it, so please do something else with it." This is believed to help with network stability, because there are lots of operational issues with failover and proxying being uncertain.
So, silently discard is there for security reasons in some cases. I get a packet from someone I don't know, or you send accounting to an authentication port. But Protocol-Error is really only for known packets from known clients where everything else is okay, but for some reason you can't proxy it, you can't store it, you can't do anything with it. It's already defined in RFC 7930, but in a couple of paragraphs with a sort of "here be dragons, hope for the best." This document goes into a lot more detail about operational considerations and exactly what it means and how to use it.
The document proposes that there's no additional negotiation because RADIUS does not have capability negotiation. From tests, it seems that this is safe to always send it in responses, as old clients will get a packet they don't understand and throw it away. So, that should be okay. But the recommendation in the document is still to only send it if you know that the client will accept it. But for things like servers, there's no reason for servers to not accept it all the time. At the last hackathon, we did a bunch of implementations. We tested it. We verified that it was interoperable, came up with minor changes to the document, and there have not been substantial changes since then. So, the document needs a few more passes, but it can wait for other things to be done. After that, I think we should be good to go. Questions or comments?
Valery Smyslov: So, thank you, for this update. The document is currently individual draft, and it is also... it will also wait for new charter for adoption call then. Next presentation: Proxy BCP.
Alan DeKok: Yeah, this is one... it has some text taken out of the original deprecating insecure practices, and then lots of extensions. So, 2865 says, "Hey, proxying is a subject of research, figure it out." 30 years later, it'd be good to specify some details. We might have learned some things in 30 years, we might have some recommendations. There's a lot of ad-hoc behavior done in proxying, failover, load balancing, and all of this. Lots of equipment does different things. Some practices are better than others. It would be good to have a document that specifies what is known to work and what is known to not work. The document really is a big long list of things that go wrong and what to do about it. Here's a bunch of them. The document really does need substantial updates because most of the text here is pretty simple. But... it needs reviews and it needs content. So, there I expect there to be a substantial amount of work here. Questions and comments.
Margaret Cullen: So, this document and the previous one actually I think could be said to be covered in our current charter as well as the recharter. So, I don't know... I haven't read the latest version of this document, I don't think, if it was updated for this meeting, but I have read previous versions of this text. I don't think it's quite ready for working group adoption. Do you disagree, Alan?
Alan DeKok: No, it's an outline, yeah.
Margaret Cullen: Okay, so there's no need...
Valery Smyslov: I think it's explicitly mentioned in the new charter as far as I remember in the proposed text for the new charter.
Margaret Cullen: Yes, it is, but I think it was under... I think these were in charter for the working group now under that "clarify operations" or whatever it is that it says. But it's more explicit in the new charter. So, we were holding up the rechartering sort of because we were doing RadSec, mostly because we didn't want to distract from RadSec, that was the big thing we had to do. And now we have a bunch of small things that we want to get moving forward now that RadSec is almost out there.
Paul Wouters: Yeah, I cannot see the current status anymore because, in the Data Tracker, I already lost my AD powers on like the little yellow dot that's claimed here at Meetecho. So, I cannot see the recharter internal status from the IESG at this point. But I'll talk to Chris and Deb, and we'll get this rolling.
Christopher Morrow: I do have the AD powers, but Paul, you're going to have to help me walk through it. This shouldn't be a problem. We can get this done. it'll be a priority for me to like, especially as part of transition so that Paul can actually be free, so...
Margaret Cullen: Yeah, so the working group has reviewed the charter text on the list. We then discussed it at interim meeting. We then had like, you don't really have a last call on charter text because it's not technically a consensus document, but we had a two-week period for comments on it. We got one comment, which we responded to. The... so there's pretty good working group agreement that that's the charter that we want. I mean, obviously the IESG can decide otherwise, but it's not exactly a frisky charter either when you read it. It's pretty much stuff we're already doing, maintaining RADIUS and making... updating stuff that is old. Like Alan said, you know, we really don't talk about proxying and we've got a lot of large proxy networks out there and we have a good notion of how... how it's good and bad to run one, and we'd like to say some things about that. It's not... there's nothing... we were holding up the rechartering sort of because we were doing RadSec, mostly because we didn't want to distract from RadSec, that was the big thing we had to do. And now we have a bunch of small things that we want to get moving forward now that RadSec is almost out there.
Valery Smyslov: Okay. So, Christopher, do you want to say something?
Christopher Morrow: Yeah, sorry for joining this RadSec discussion very late. My first IETF, I wasn't aware about the standardization here, so I will try to finish my review as soon as possible. I see this RadSec as a first chance in the broadband market to go to security because I'm working in this BNG market where a lot of them fear or have problems to go to a TCP-based RadSec. But I really have to check this document first, so I'm quite new here. But I was wondering if the RadSec is maybe needs even a liaison to the Broadband Forum, since they use RADIUS as the... I guess they almost all use RADIUS for, I would say, a billion CPEs in the world. Or I guess it's 1.5 billion CPEs or broadband Internet access connections we have, which are mostly all RADIUS authenticated. And not sure if this has something or is something we should also discuss with the Broadband Forum here.
Margaret Cullen: So, I'll start by saying welcome, Christian. It's good to have your input. One of the things we've done in previous documents is make distinction between where we've deprecated the use of things on non-secure networks. So, you know, PPPoE between two things that aren't under the same administrative control is not the same as when you're using it as a method over something like eduroam or OpenRoaming, and we can write something that makes it clear that the danger is in sending this over the Internet, not over your like captive PPPoE link.
Alan DeKok: Yeah. For Christian's comments, I can tweak the deprecation document and the review document to explain some more of the issues about CHAP. Realistically, if you're sending the CHAP text over a secure management network, you're probably okay. But from a practical real sense of view, you really need to stop using CHAP everywhere as quickly as possible because it's substantially less secure than PAP in pretty much all possible manners. And then also for Christian's comments about the Broadband Forum. It would be really nice if people from the Broadband Forum showed up in Radext, but historically a lot of groups outside the IETF assume that RADIUS is just fine, don't do anything to it, and then are surprised when things don't happen to address their concerns. So, yeah. I don't know of anyone involved in the Broadband Forum who's been active in Radext for a long time.
Steffen Fries: Yeah, maybe... maybe just to provide some... some information about the usage of RadSec or of RADIUS in general. So, I'm... I'm also engaged in IEC standardization regarding the power system industry. I had some exchange I think a couple of years ago regarding utilizing TLS to protect RADIUS, and we were basically requiring that for the power system industry, and I was in contact, I think it was with Alan regarding the reuse of the RADIUS security port that is specified in the RadSec document. And what we did essentially was we rely on RADIUS security but have a different profile for TLS which requires stronger cryptographic algorithms. And that is pretty much aligned with what is currently being specified. So, we always... so I always tried to be in both groups and basically try to... to avoid that we are reinventing the wheel, but more or less pointing to what is being specified here. Just... just to give you some... some heads-up that your work is being seen also in other standardization bodies and industries.
Christian Giesee: Yeah, just one more comment to this PAP and CHAP. I know that the broadband industry is a very insecure industry, and we have to use PAP and CHAP because we do have these billions of CPEs and changing CPEs in the market is a thing of decades. So, we have to operate with them. But most of the operators, they just use it for client compatibility. They use line ID, line authentication and other stuff. But they have to use PAP and CHAP for PPPoE. And half of the world is doing PPPoE, the other world is doing IPoE which is not much secure because they just also use the line ID here. But yeah, this is... it is a very insecure market, but I would say it's one of the biggest use cases for RADIUS is still the broadband market. So, we should not completely... yeah. I know they are very hard in adopting things. I even could not convince all my customers to fix the Blast RADIUS stuff and... yeah. But I hope that the RadSec maybe is something which can be accepted. So, but yeah, PAP and CHAP is something we have not in control because it's the CPE market.
Valery Smyslov: Thank you. Margaret and I are very glad that we have opinion from operators' point of view, and we are here to develop a better security standards. So, still this must not be an obstacle to do our job here. So, thank you. And so, we are finished our agenda for today. And thank you very much for all those who come on site and thank you very much for those who come remotely because I understand it's not the very convenient time zone for everybody. And that is that.
Alan DeKok: Can I add one last... one last comment, Valery? To address Christian's comment, yeah, the document does say that CHAP and MS-CHAP are okay when sent over secure networks, so inside of TTLS, PEAP, or RadSec. In terms of deprecating practices that people actually use, realistically I think if you don't deprecate things like sending CHAP over UDP, people will use it forever. So, from a security point of view, we're probably better off to say, "Hey, it's officially deprecated." If you continue using it, I mean, we'll close our eyes, and many people ignore the RADIUS standards anyways. But especially with the publication of TLS-bis as a standard, there is an upgrade path.
Valery Smyslov: Yes, thank you. At some point it should be done. Well, again, thank you very much for everybody for attending, and see you all in Vienna. And please continue discussion on the mailing list, in a hope that our RadSec document will be ready very soon and we will pass recharter process in the IESG. Thank you.