 your own identity, how you could run your own identity server and use that to authenticate against other services like Google or Microsoft or whatever, and how you could enable this trust relationship. A topic that is rather complicated, rather very interesting in the current times. And yeah, all more. I'm not qualified to talk this, so we have two speakers with Rick van Rijn and Henry Manson, so please give them a very warm round of applause. Thank you. I have a very small business. I do stuff with cryptography and open source protocols. I'm probably the only one here. But over the years I've constantly been annoyed by how poor authentication has been organized. Also in open source, actually, in open protocols. I think it should be trivial, as trivial as DNS is. And I know DNS is complex, but for an end user it's not noticeable, and that's the level of understanding you want to reach, because then people don't mess it up so easily. And that DNS is quite simple, right? You have an authority defying the names, exporting them over the network, and there's a resolver that can actually verify, yes, these are the names, and thanks to DNS, it's even secure. Why don't we do this with authentication? And if we can, please give users maximum control over their online presence, because I don't like if somebody else decides who I am, and whether I'm allowed to continue to exist, or whether I'm allowed to be removed from the scene. I don't know if anyone of you ever deleted account for somebody who perished, who died, and that's terrible. You have to jump through all sorts of hoops with the third party providers. Also, if you're a security officer in a company, you would like to set a certain security level and say always two-factor authentication, for example. What we see now is that service providers, like GitHub, for example, decides you need to start using second-factor authentication, because we think it's important, but as a user you want to make that decision. So basically what we've been working on over the past few years is something that we bring to users, explain to users, bring your own identity. You're just someone at your own domain name, like you have an email address under your own domain name. But how we can make this happen with identity? This should be trivial, and it can be, because every relying party can connect securely to any other domain using DNS, SACDain and TLS. We have the infrastructure to know who we're talking to, to what domain we're talking. And there are standard SAP records for quite a few identity providers. There's Kerberos, there's LDOT, there's Diameter. Diameter is radius, but designed for this sort of crossover thing, so it's the easier choice in this case. But there are standard SAP records for this sort of thing. That together means you can trust, you can find an identity provider under someone else's domain and trust it. And this identity provider then, of course, has a prerogative on the usernames, whether John exists and whether Joe exists. It can be trivial. In practice, it's far from trivial. I'm looking at really big screen trying to read it, I shouldn't. Yeah, I know. Credential handling is very often done in applications, and that's a problem, because an application programmer has quite different ideas and wishes and things he wants to do than a security programmer. So what we end up with is passwords, the lowest common denominator. We've been doing that all the time. I can't make a mistake if I do that, too. Shouldn't we just tell the application programmer, we authenticated this guy, this identity you can trust? That should be enough. Credentials managed by foreign parties, I think, are a disaster. You can't withdraw, you can't expire, you can't, why can't they make an identity that expires in three weeks? Ideal for web shops, right? Also, if other parties manage them, they need a recovery protocol, you can't have a local administrator overriding things. So you need some mechanism and some jumping through hoops to do this, and you end up supplying communication details, which means a privacy problem. So, and there are many solutions that look like the sort of thing we're doing, but I found that most of them are web only, or in other ways, protocol specific, but usually that leads to web only, meaning IMAP has to reinvent the wheel, meaning just about any protocol has to do it again. So, in terms of technology I used, I don't say bring your own identity, because that's like how users would experience it, but we speak of realm crossover. And there are ways of doing this for quite a few common authentication protocols already, and we made small extensions to existing standards and could then make this happen. In case you don't know it, it means that the server sends you a list of mechanisms you might use. It might be something like plain text, or it might be GSS API, or it might be Duchess MD5. It just gives you a list and the client chooses which mechanism to use, and then they start passing tokens back and forth, interpreted through that mechanism, until the server says, yeah, you're welcome, no, you're not. This is a very generic thing, and it allows you to negotiate what you want to do. You might go for a simple password, or you might go for something as fancy as Kerberos. Kerberos, in case you think it's old fashioned, let me rephrase that into old and fashionable. It works with symmetric keys, so in a trivial way, it's always been quantum proof, and it's already been designed to prove a campus with curious, innovative students, pretty much what we have on the internet today, where everybody's challenging security all the time. And it's with due to the test of time with, of course, crypto updates. And lastly, certificates can be used for TLS signing encryption, and we also see ways of doing realm crossover for that. So I'm going to talk about these three realm crossover mechanisms. And Henry later on is going to one of them. So for Sassel, Sassel is embedded in just about any authentication protocol. It's amazing. It's almost everywhere. So if you can support Sassel, it's wonderful. I know HTTP doesn't have Sassel, so we built that. Don't worry, we got you covered. And to make this work, we designed a new mechanism for Sassel. That's one of the extensions we made. It's a pretty trivial extension that anyone can make, basically. We call it SXO++. And that's like an end-to-end tunnel that wraps around a standard Sassel exchange. I'll show later on why. And basically, you have an intimate server that wants to use something that passes this Sassel and then in the end knows that he's talking to John at theexample.com. So this is from my internet draft, so that's why it's an ASCII art picture. Is it readable? Good, thanks. So let's say the application at hand is email, but keep in mind it could be anything. But let's say we want to have an IMAP server for a group. And it's hosted under some sort of domain somewhere. And John, who has an identity under example.com wants to use that. And this will be the identity provider for example.com. So John and example.com have some somewhere, sometime in the past set up an account. Now what John does is he says, I want to talk to the IMAP server. And I'm just saying, yeah, like you first got to log on because I need to know whether you can see this group. And perhaps wants to see what emails you've already seen. So it starts a Sassel exchange. And what a foreign server does is pretty much it says, okay, I see SXO++ being used. That means I'm not going to resolve the password locally, like web servers very often do. I'm going to pass on the request. And the SXO++ has a beginning where you can see what domain it goes to. So it's passed on to John's domain. It just says example.com. So it knows it can pass it on. And it does all the things I just mentioned. SFV, look up TLSA, and then just passes on the Sassel. It just sits in the middle, pretty dumb, just passing back and forth the Sassel packages. And at some point, the identity domain says, yeah, this is indeed an account that we have. And it's called John. It doesn't say john at example.com because he knows that he validated that using SFV and all that stuff. So the identity domain only says stick john in front. So now the foreign server knows it's talking to john at example.com, it can relay back the okay, and everything can happen as it is. So what did we need to do for this? I meant to use diameter, and it is like radius, but radius is optimized for trusted internal networks. And diameter is more optimized for realmrosoft sort of thing. So mutually untrusting domains. So we needed to define a couple, three address value per attribute value pairs to carry the Sassel content back and forth. That's pretty much all plus, of course, the sx over plus mechanism. And we implemented this stuff and it works like crazy. As I mentioned, we thought it cool to demo this with HTTP. So that's what we'll show you. So we have an authentication mechanism for HTTP that actually passed the Sassel. So then you get in this picture, a web browser speaking Sassel over HTTP to a web server. And that in the back end can use the identity domain. And something else I'm also doing now is I'm building it into PAM so you could use in sudo, for example, or in the console access for container, for example. That also means your very simple small container doesn't need to know what comes. It can just forward it to a trusted internal node. Kerberos is entirely different. But I think this is the goal path for what you want to do because Kerberos does single sign on you log on in the beginning of the day, you get a sort of method tickets and use it for the rest of the day to get additional tickets without effort. Kerberos even has realm crossover built in, but it's static. Meaning I ask my Kerberos controls key, it's called key distribution center. So I asked my Kerberos realm controller, please hand me a ticket for a service I now want to see. And he says, oh, gosh, I don't know that one. But I know the realm that does. So it says, I'm going to give you a key that I share with that realm. And you can use that to ask that realm for control. So then you have the client identity users, its own realm and service is at another realm. And this is realm crossover, but it gives us static keys that have been preconfigured like shall we say the name of my cat? Yeah, let's do that. And then it's set. All we had to do to extend this is to basically say first of all, if you ask for a service that I don't know, I want to know what realm it is, what Kerberos realm, so what domain. So it needs to be able to look that up in DNS. Well, that's a text record. It's pretty simple, except when you need to pass it through it. But it's a pretty simple idea. And then the next thing is these two Kerberos servers, when they see gosh, you're asking me for a service through DNS, I can look up what realm it has. But now I need to set exchange a key. So the two key key distribution centers, so the realm controllers for Kerberos, get in contact and do a key exchange, which basically is a key extraction facility that's standardized in RC5C05. Basically, they use the master key, add some seeding and add some strings and that ends up being a key that the two endpoints have without explicitly passing it. It's a lovely mechanism. And from then on, it might be for three weeks, for example, and the client realm would do that for everyone in the client realm can use these keys to address any service in the service realm. And of course, it might also be done the other way around. But that's independent. So this is a really efficient system and also Kerberos bloody fast. So after the first has come through, you really have very fast access to remote service. And this can serve as the internet. That's pretty much the idea. The entire internet can use this mechanism and use Kerberos for all their authentication. That's something Kerberos can't do now. So those are a few very simple things we added to make this possible. Certificates, we haven't done much on this, but we understand how to do this. Certificates have these funny names in the subject, right? They're actually an LDAP location. So they would look like user ID is john and maybe organizational unit and organization and whatever. And then the domain is split in a number of components. The domain is very long. I need to walk along and for it. But this is basically a location in the LDAP. And that is standardized. That is just something we don't do very often. But it is a standard. And even if you know the domain part, it has been standardized that you put LDAP TCP in front, find up find the SFE record and then look up the LDAP server. Of course, LDAP can be encrypted with TLS after start TLS call. And then you can continue with the with with Dain to make sure that you're talking to the right one. So yet again, the same structures, DNS stack, Dain, SFE records and you're there, you can look up things. Because these are locations for objects. And they made may have attributes with X5 and nine certificates, PGP keys. So you can use sign in your encryption with someone you haven't talked to before. And the interesting thing is, it uses a slightly different name. But open PGP has this installed. If you use minus R on PGP or GPG, you can actually pull in based on the email address, pull in that key. If they set this up, realm crossover can really be done very easily. And an extra idea that we're trying to get through. And I think people are listening is, why should I use an external authority to sign the users in my domain? I would very much like to be able to just publish a root certificate for so for a local CA and publish that with a Dain record and client Dain could do that sort of things. It's all in the pipeline. We'll see. Imagine mail servers, they talk to each other and when one domain sends something to another domain, they need to trust the identity that's been supplied to them. Imagine adding authentication here. That definitely makes it more difficult to spam. And it also makes it very pleasant to select between the ones you trust and the ones you may trust or may not trust. So it can make you switch between wide listing and great listing your mail server. It can be really valuable. And email, of course, was designed in the time that everybody trusted everyone with 32 computers online that was safe, I suppose. But you can actually expand on that quite well. And basically use the distance to retrofit more security on the SMTP. SIP, that's used for calling, not just audio, but it's generally used for telephony and video calls and all of that. With a pleasant thing that unlike all those platforms that we have like Zoom, if you use IPv6, it's very trivial to make use to user direct connections. So just call recordoperforters.nl, you will be connected. Imagine adding RomeCrus over there. You would know who's calling because you could check. You would know somebody is scamming you and you might even look up information in their enum records, for example, to see what kind of person it is. And you might even find key material there. So you could start an encrypted call. Helpful, I would say. HTTP, well, Henry is going to show all about that. As I think that's one of the lovely... Yeah, he came up with a wonderful way of building this into Mozilla using a standard that is new, but that was already in Mozilla. But in theory, it can be rolled out in other browsers as well, but they also adopt this new standard. Doing this for... Doing this for HTTP authentication means you could add RealmCrus over there, bring your own identity, so log on to Gmail, if they would support this, of course, but log into Gmail using your own identity managed under your own domain. And you want to stop using it, you just delete your identity on your own identity provider. If you want an aliases, if you want to do stuff with groups, whatever you want, you're in control. If you lose your password, you go to your local admin, you have it changed locally on your domain. I think that beats having these 30 seconds exploration that Gmail uses while they don't implement great listing properly. And here, too, I mentioned that applications have problems with getting to the information. A web server can easily set the number of environment variables and pass the information over to scripts. So we made a simple protocol to allow you to... If you need to implement diameter in every single server, it's going to be hassle because diameter isn't easy. So we made a very simple wrapper protocol that basically says we've got open authentication, close requests, and responses. They can be multiplexed. And this turns out to be very easy to build into an application. We also made, instead of just a protocol, we also made a library to use this. And we have demonstrations for synchronous, threaded, and event-driven applications. So fork-based, thread-based, and event-based. And this... Usually we copy these things and get things working very quickly. What this assumes is that within your domain, you have a central node that runs diameter, and quick-diasasal connects to that node. So you have one place that basically is declined for authentication. And all the others basically just use that. So we have had funding, but we can also hand out some of that to other people. And I'm very pleasant. I'm very pleased to say that. Sassel works is a project name we had. We did all sorts of nut and bolt work on Sassel. And it's been sponsored by Anelnet, including the Pam module that I just talked about. RealmCrossover, as a mechanism, has mostly been sponsored by NGI Point, which is a European Union project. European Union doesn't really like to offer you Facebook log-ins. And if I have to be honest, I don't very much like to say Facebook is now going to decide that I can log on to this site that holds all this personal information about me. Somehow I think that's challenging them too much, offering them too much. But some of these NGI Point funds are remaining. And as I said, with the quick-diasasal, it's really easy to add, to make a modeler's extension to your server and to actually implement this. So if you're interested in this, we can probably help you with some funding. So contact us, contact me, for example. And what we'll be looking for is things with the most impact. So if it's generic, it's interesting. If it's a frugal proposal, we can do more of those. And if it ends up in the core distributions, we say, hooray. So if you think this is interesting, if you want to implement it, talk to us. And that's where I hand off the microphone to Henry. If you download these slides, and there are many links to documentation and backgrounds, I won't go over those now. But if you download them, there's extra goodies. Good. Now to train LibreOffice. Terrible program. Hello. Hello again. I will continue the talk of Rick by demonstrating HTTP social. Which I'll introduce already. And I have to look up a little bit, because this is my first speech. How did the pay social? It's a new HTTP authentication protocol. It's a standardized way to add new HTTP protocols. As the name already says, it involves headed the social protocol, which allows you to specify the mechanism in the social protocol itself. So it could be the only HTTP authentication protocol, because social provides for choosing a mechanism, while the HTTP authentication protocol contains the mechanism. Almost all HTTP authentication mechanisms choose one specific authentication mechanism. And social habit that allows for any mechanism to be used. How did the pay social was invented by the previous speaker, which one thing in mind had the way on because of he just mentioned and his ethics over plus protocol, which will have which will be the mechanism you choose when you want to have the on crossover. But HTTP social also allows for conventional mechanisms to be used, which don't allow for crossover. There is a draft on it, and it's shown there, and that will be available on the slides. That is the last protocol, which contains the latest updates. Next slide. Here is the, I can do this by heart, this is the demonstration of a conventional HTTP social exchange, the most used one, by the way. It's very simple. You try to visit the website and you get, you are not otherwise, you have to log in. And then the browser reacts by showing a popup, that the login is required, and it shows some real HTTP real-alarm message, which is always on the top of the popup box, and it says something like, now you enter the secret area, something like that. And that's the real-alarm passed in the W, W, W authenticate header. And the client then responds in base 64 encoding, it's not encryption, it's just a simple encoding, with username and password, and then the web server checks, those credentials are correct, and they either succeed or not. Next slide. This is a flow, how it goes, with our new HTTP social mechanism, and you can see that there is one extra ping-pong, so I have to say. And the first outindicate from the web server is, here I have my list of mechanisms that I support, and then you can choose one of them, and the real-alarm is exactly the same as the real-alarm which is used in the basic authentication mechanism. This is just something you can show you're now logging in some secret area. And the next, at that time, I will show you in a minute, instead of the standard, a pop-up works from the browser itself, which is built in all modern browsers, we show up, pop-up box is shown by an external program, it's not a browser, but an external program, which not only allows you to enter the credentials, but also which mechanism you want to use to log on. And that is all happening in the R skews and the left side of this diagram. And then here you can see, as a demonstration, that the user chooses digest MD5 to log on. And then it's almost the same as a conventional HTTP authentication mechanisms, that is the web server sends challenges, which the client has to make a response on. And the only extra parameter we use is the so-called server state, S2S in this Taiwan, that's something the web server can send to the client. And the client always has to send the same state back in an extra request. And that's what you can see in the same string, it has the same string which is sent by the server and sent back by the client. And then in the case of digest MD5, business as usual, and then the credentials are checked, and when the credentials are correct, you get an OK or authorization refused. This slide, the most complex one, this is the one which cross over. And it's using the same software, but now the server had a client not selected digest MD5, but the SXO protocol. But then, my proper books of the new client program has extra fields which you can fill in. That are the alias and the client domain fields. And the most important is of course the client domain. That's the domain which Rick just talked about, which you want to log on to identify yourself. And the alias is used for showing at the entity which the foreign server had is the middle server in Rick's diagram. We'll see. I can authenticate as Henry, but I can, as the foreign server can see a totally different identity, the entity you want to provide to the server. And I will show you in a minute how that proper books look like. Let's see. Then, as on the first, after the client has chosen SXO protocol, it's nice to indicate what's inside the encoded client-to-server field. Here what you see there. And then just to make it clear a little bit how crossover works, that contains the client domain you want to log on to. And not to be confused with the realm which is shown in our proper books. Had a client domain you filled in the proper books of the client program. Let's go to the next slide. Because here I have the components which are involved in our setup, which I will show you in a minute. Here this is on the left side on the purple, how do we call it? Magenta box. It's the native client, which is a C program which is just a real authentication. And I built this, and fortunately it was possible because browsers have standardized the way plugins work. And one of the possibilities you can do is so-called native messaging, which allows a browser plugin, which is the yellow box, which runs inside the browser as a JavaScript extension. When you set it up correctly, then the plugin is allowed to talk to an external program. You have to organize it yourself. So had it not any program can talk to the browser, which would be a huge security risk. And on the right side we have a server. It can be an Apache module, but when I first started for NLNet, I had to just so that this concept works. I used, for example, a Java serverlet to do the work. Had it was, of course, only a conventional mechanism, which was unused. And I think everything I mentioned here is done. And yeah, here I can make sure that it's okay. And here maybe you will recognize some of the components which Rick showed in his realm crossover talk. Because here are the components in the Apache server identity provider. These three things, I have no pointer, but the blue, the green, and the red box are the same components which Rick showed in his slide had how the anchors of set of three parties. The Apache server contains the three-diameter client, which talks to possibly a different three-diameter server, a server on a different domain. And a three-diameter allows for that. And I will have to have a look on it because it's a little bit complicated. And it rest my heart, but this is because the Apache module, which is used here, which is capable of doing the diameter sussle, is one of the two Apache modules I wrote, a start with a simple one, which really involved that the entire authentication was done in the Apache module or on the same server. And this module, which allows for to authenticate on an external diameter server, is called the module for the diameter sussle, which uses what was it? The diameter sussle protocol between the blue and the green box. That is correct, Rick. That is the diameter sussle protocol, this is the sussle protocol you invented. And this is, we have created a demo for this, and then you can really see how the three parties and that headers of client can log in using its own domain and then the authentication succeeds. And that is one of the next slides. Here you see the headers on the 5-hubs browser, you see the new public works, which replaces the public works of the browser, which you all know, which only contains a user in the password field. And here you can see the fields I just talked about. The first one is very important that you see the same URL as in the browser, so that you know which resource you are accessing. And along with the user in password fields, there's a re-enter for dots, and you can see the alias in the your domain fields. And in this log-in session, I just used conventional log-in, so I didn't need to use alias in your domain, and I think the next slide shows the, here you can see it. Oh, no, that is not the matter. That's it, I'm afraid, because I didn't include. Yeah, this is all, huh? Yeah, sorry. Then I don't have a picture which includes, yeah, because this is essentially I just talked about, that are the fields which you can choose. But in a crossover situation which you can see in the demo we have, we have sticks and we have also virtual machines on which you can see all of this work, and then you can see a client domain log-on, as I forgot to include that slide. And that's my talk, my first talk, to be honest. Thank you very much, both of you. We do have some time for questions and answers, so if you line up the microphones, we also allow a comp, no, provide the possibility to ask questions through the interwebs. So just a second, I would like to check with the signal angels. Do we have any questions? Unfortunately not. So good for the gentleman in the first row, please ask a question. I have to, actually. So first of all, do I understand correctly that you will then use something like DNSSEC to set up trust with parties that you do not know? Yep. Alright. DNSSEC, Dain and TLS usually. Alright, question number two is, so SAML obviously is another way for cross-rail authentication. Is that something that you compared with? I think some of the problems with the Sassel seems that you still are a man in the middle, which over complicates it a little bit. I think if you do SAML, you're completely redirecting, you just wait for the answer. Yep, definitely. If you log on to your email, you have to use Sassel. So that's why we have three solutions because sometimes a protocol says use Kerberos, use Sassel or use whatever else. SAML can usually be included in a protocol and among that, there is a SAML mechanism for Sassel. So given HDP, so you could actually put SAML in there, but I know it hasn't embedded in HDP already, so that's senseless. Unless you want to give the client a choice. And I think that's valuable. Two questions, line up at the end and ask a third question. Thank you. Next question please. So thanks for the talk. In your example, you said like we can give the authentication to the local provider, which may up the security of the user. But what if the local provider actually decreases the security of the user? So the webshop of whatever is in the middle actually doesn't want to provide your local authentication party because it's less secure than what they can offer themselves. Is there something there in the protocol? You split my brain by using another term and I'm not wondering whether you mean left or right. Are you talking about local authentication as in the quick diacessal receiving note that passes it over free diameter? Or are you talking about the identity provider that received the free diameter request? Okay, let me give an example. Like if I log into my bank, I need to fill in my username, password and then do two FAE for instance. But what if my local provider only uses like username and password? So my bank would actually say, no, you cannot use your local provider because it's less secure than what we can offer. Your bank wouldn't know. Your bank would only see who as whom you logged on and you are in control of the security of your bank account. I have advice for you to do it well. This, by the way, is very much what banks like because they're not interested in security, they're interested in covering their ass. True. And you're interested in getting the best security probably better than your bank account. Sorry, if it's evolving into a dialogue, let me cut this off here for a second. Feel free to come back or continue this as far as there's another question lined up. So please. Hi, thanks. I have a question that's sort of usability related. Do you have any ideas on how to guide a user into which authentication method they should choose? Because choosing digest MD5, I mean IU and he understands it, but my mom doesn't. Now your mom probably has a system administrator. Who insists on particular practices? Not really. Of course, we would like, we would like to encourage users to use crossover whenever possible because then you can use it. It's the only protocol currently which uses your own identity provider. And all the other protocols are normal, so to speak, that authentication takes place in the same domain as the server. Yeah, but you are, I think, also making the point that if you give people more freedom to choose, they might shoot themselves with food. And it's also if you take email as an example, you don't usually configure in your email client which specific authentication method you would like to use, your email client sort of chooses one that sort of makes sense. Actually, to some degree you do. Because it's sassal and you do say stuff that you won't allow over plaintext connections, for example. Yeah, but there are ways of setting these things. And given that you have one option available or three, and basically what sassal does it matches the overlap between the server offering and the client's ability and finds a good one, maybe the best one. But if you're willing to accept all three options, then it might choose any. So yeah, you would want to control this to some degree. Thank you. I see a discussion group forming at the bar after the talk. We might get drunk if we don't. Before we get to the next question on the mic, are there any questions on the interwebs for the speakers? Harold, signal desk? Any questions? Nope. I see shaking head. So please go ahead. Very practical question. You mentioned the Apache web server. You mentioned Firefox. Obviously, there's no reason it couldn't work for other browsers, other web servers, right? Sorry, there is an anti-implementation. I can answer the question. Currently, head is dough. There was some kind of standard being built for all browsers. And currently, you know, there are only two real ones left. Head is reality is home and home contests Safari, currently even Internet Explorer, and of course, home itself. That's the one engine. And the only real other engineers still Firefox. And in principle, it would have been possible to implement this on home as well. But there is one addition which Firefox added to the native message thing, which involves that you can intercept HTTP request. And then the Firefox browser plugin can wait in the form of a so-called JavaScript promise for the answer of the external program on a request. And unfortunately, Firefox is the only browser who implemented that. And up to now. I mean, it is a standard. There's no reason why others couldn't. But there's no current use case. We define a use case. So we hope to do so. They felt very fortunate that Firefox made that extension. Otherwise, I couldn't create a demo which I created for this not only across over with the entire HTTP shuttle and external program. We really wanted to pull credentials away from the browser. I somehow feel iffy when I need the same environment for looking at adverse advertisements and logging onto my bank. So you wanted your credentials outside the browser. And underneath the application so in the HTTP layer, these were very deliberate choices. You could, of course, implement this entirely in JavaScript. But then you wouldn't have access to Kerberos, for example, unless you build entire Kerberos in JavaScript, which might be a bit of a security problem. Did we answer your question? Yes. Thank you very much. Long answer, but a good one. Thank you very much for that. We have, yes, please. A couple of quick ones. I was wondering about replay attacks. I didn't see any binding into crypto protocols in here or did it just miss it? I couldn't read all of the slides from back there. Any decently designed protocol, you have an explicit connection that wraps everything that goes on. HTTP made a choice to have independent packets that have no notion of a connection, no identity to link them. And you can send others in other connection. That is a big problem. And that we managed to get this secure. But the replay attack answer because of this design usually uses HTTPS. I'm sorry, the web doesn't have a better answer. So we don't either. Yeah. So that's actually why some of the newer authentication protocols tie the HTTPS parameters into the authentication. It's called universal second factor, UTF. But anyway. Yeah. In Cecil terms, it will be channel binding. And we do that. I can elaborate a little bit on the implementation of crossover in HTTP Cecil. Though HTTP itself is stateless, Rick introduced a server-to-server token in the HTTP headers. And the implementation of crossover in diameter contains so-called session ID, which will be disposed by diameter when the session is complete. And so when you try to replay that, if I'm correct, the diameter won't accept it because that session ID is no longer valid. OK. I want to address the S2S headers in our most of our implementations is not the real state of the server, but only in the, so to say, indirect. It's the session ID of diameter session, but not the state which headers the authentication is currently in. Because then you are totally correct when you do that. I even made a proof of concept of that because we would like to have the headers for normal protocols, the HTTP server to be stateless. But then you can very clearly see the, indeed, the risk of replay attack because, of course, that succeeds. Because then you don't have the challenge response system anymore because you have all the state, it doesn't matter whether the state is encrypted or not, you have all the state into the S2S. And then you can just replay the last poem, so to speak, to the, you can replay that and then you immediately locked in. That is indeed quite a big problem I found out and together with some guy called Steph, which is really involved in his project, who pointed that out, as I proposed it to use it on his protocol and came up with it. In the only way, perhaps we have to investigate it further, but the only way to circumvent it is indeed using a secure protocol such as HTTP. But he's right, it is not a complete answer to replay attacks. And I do have to move that conversation over to the bar because we are unfortunately out of time. I'm very sorry for that. So please give another last warm round of applause for Rick and Henry.