Internet Engineering Task Force Interim Meetings, 17 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-KITTEN-20230117-1700

Description

KITTEN meeting session at IETF
2023/01/17 1700

https://datatracker.ietf.org/meeting//proceedings/

A

A

Right, I'm hoping to see a couple of more people like Dave, Cleveland and Ben kadak, but uh let me probably start slowly and just go through the admin bits and uh then hopefully they can join us and catch up.

A

So welcome to the kitchen working group interim.

A

We didn't have a meeting for quite a bit um so I'm, trying to both see how much interest there is in various topics as well as kind of trying to synchronize what people think are on some of them.

A

In case you haven't seen me: I'm Alexi.

A

um If you are new to ITF, then.

A

Please read note: well, there's a bunch of other documents related to code of conduct, IPR issue and stuff like that I'm not going to I. Don't really have time to recite all of them here.

A

um These are various documents that, if you're not aware of you published, read.

A

um And the main things about kind of conduct, Street colleagues with respect, speak slowly, avoid using slang and clock will stuff um dispute ideas, don't attack people use uh engineering judgment, find the best solution for the whole internet.

A

Right with that, this session is being recorded, uh we are using mitako, which is online web-based platform. We have notes which are linked here. There are I just discovered five minutes before the meeting that the link I used was not the same one using data tracker, so I added a redirect. There can I ask somebody to take notes. This doesn't have to be um Blow by blow discussion. That's just main points when there are discussions, uh no need to write down, slides or text of presentation, just basically questions answers.

A

Who would like to volunteer before I volunteer? Somebody.

A

uh Nadia I hope that's how you pronounce your name. uh That would be great if you can take notes again uh just keep the presentations. If there are any questions after that or if there are perfect excellent I know both of you are uh will be speaking or presenting bits so, uh but I hope you can cover for each other. So thank you for that.

A

With that, this is a roughly proposed agenda. I don't have uh timing of things, so um I suspect the first part will take a bit longer and then we have a smaller presentation so.

A

Today, I will basically be reviewing various stuff around so-called social too, that came out of xmpb software Foundation and whether there is enough interest in doing something like this in ITF. So it just does that doesn't just cover xmpp, but it can be used more generally, um I'll do a quick update on scrap two-factor authentication draft, uh we'll talk about faster authentication mechanism and quick update on OPEC Sasol mechanism.

A

Thank you so for the um social 2. Actually, there are two presentations. There is a bigger one and then the rake uh asked about shared key derivation, so he has a smaller one. So I know it's not something that necessarily was discussed in xsf, but I kind of group them together because they seem to belong together.

A

um We're not making decisions today, um what's going to be in Sasol 2 and whether I will try to pull people whether there is enough interest to do something like Sasso 2 in ATF. But again this is going just going to be a poll um we'll go on the mailing list and double check.

B

A

um Yeah because I couldn't actually so I added all the documents related documents which are ITF drafts as they relate to documents to the meeting, but I couldn't add xsf because um data tracker doesn't, let me add arbitrary links. So I use some of the snapshots of this documents.

A

uh My apologies, they might not be specific um latest version of what's an xsf, so I kind of got a snapshot and they don't even point to xsf website. So just but this should give you some idea. If you want to further reading um and with this um I think, Matthew will go into more details about.

A

A

Dave is not a dodgy URL, but I got it from somebody else. I know right, um Okay, so.

A

Matthew, um do you want to present your slide yourself? There is a share presentation button, or do you want me to drive them.

C

um I've never presented on me Techo before, but I can give it a try. It would be handy to be able to manage my own slides.

A

There is a share. uh There is a preloaded slide thing which is not share screen. It's like a document. Okay, try that, and you can pick one of the uh for presentations.

A

And if it doesn't work then I'll I'll I can drive it.

D

uh This one yep.

C

Is it the ask the share, slides one.

A

Yes, hold on do I need to approve it, I might need to approve it hold on I need, oh yeah. Sorry, yes, okay, got it I.

C

A

I cannot see the list of participants and chat at the same time, so I have to switch with it. So yeah, okay, right.

C

um Yeah so uh as Alexi was saying, and we've been working on, uh xmpp sassel 2 stuff um over at the xsf, um this started quite a while ago um we had an xmpp Summit uh I, think it was 2016. 2017 and uh Dave. Quidland um wrote up a bunch of stuff that we'd been thinking about and invented some new things, um basically to solve a whole range of issues. So we'll we'll uh we'll have a look at all of those, um so xmpp uses Sasol for authentication, that's defined in the core RFC.

C

um It's pretty much the same as any other protocol using Sasol. We just do a64 encoding and but in XMP it's wrapped in XML. um It's basically the only authentication method that we use uh these days. So um it's implemented in every xmpp server. Every xmpp client in practice, everyone's using scram, Shell One, mostly at the moment, and some deployments use plane for reasons.

C

um And so uh so, Dave Quinlan wrote uh Zep 388, which is called the extensible Sasol profile rather than Sasol II I. Don't think Sasson 2 actually shows up anywhere in in writing um because it could get confusing.

C

uh Dave also wrote some initial implementations um and, and then it kind of sat for five years with no one in the community really interested in it um and then in 2022 I'm, not sure what happened this, the Stars aligned I I, got a grant to work on some stuff related to authentication and authorization, including two-factor, authors and and stuff like that, and so I immediately Revisited. This um extensible Sasol profile and I thought.

C

You know this is exactly the foundation that I need um and then at the same time, I got speaking to xmpp client developers, who are also interested in um uh implementing some new stuff as well. So uh it's been the foundation for various new things that we've done in xmpp, uh which we'll go into next.

C

So some of the changes are um after authentication, so you do the usual Sasol exchange the server can, um if you offer the client uh or rather request the client um perform some additional tasks, so these are sort of after authentication, but before it's actually completed uh the other thing we added was stable, client identifiers, so that the client can identify itself before it authenticates and uh also Channel binding negotiation, so we're still using Sasol as it was.

C

But we have all these things around it now sort of bolted on um we've tried to uh as much as possible keep an open mind as to whether things will progress at the ietf and therefore you know be adaptable um to xmpp again it's It's Tricky, so there's lots of things to talk about there. So I think uh I think we'll have to have a discussion about that.

C

So uh this is the traditional um flow which again will be familiar to anyone who's familiar with Sasol in any other protocol, and uh so the the new um extensible version with the tasks ads uh the failure.

C

So, instead of Successful Failure, you can also have the server respond with a continue and the continue contains a list of tasks and the client must select one to proceed with Authentication and the tasks can be used for a range of things, and then we use the next um element to say this is some task data from the client to the server.

C

um So we have uh that right here, oops.

C

um So, for example, multi-factor authentication is an obvious place where this applies. So uh you provide credentials using your chosen Sasol mechanism and then the server replies.

C

Okay, but please provide me a one-time password and, and that would appear as a task like provide OTP or whatever, and then the clients submits that using our next element, um with whatever format uh the specification says, um and then we want to so part of what I'm working on at the moment is trying to add in uh two-factor author checks and PP in in various uh ways, and this simple flow where you just provide an OTP is: is the nice happy path, but there are lots of complicated ones where, for example, you have out-of-band challenges where you have to approve a push notification on your mobile device, or things like that, and we also have the 502 staff, which is a whole other kind of worms and pretty complicated foreign part of working on this.

C

We changed some things about Dave's original draft, um rather than uh the challenge response within tasks we changed to bi-directional. Any site can speak at any time thing which we may or may not want to keep. The reason for this was in some cases we had the client uh waiting for the server to say that authentication could proceed and in other cases we had the server waiting for the client to say you know the provide some information, basically so, for example, in SMS um code, you would want to wait.

C

The server would wait for the client to provide the SMS code and in the push notification example, the client would be waiting for the server to say that the user has successfully approved via whatever um means.

C

So. um The other thing to note about this is we change from a simple base64 payload in the tasks to uh just structured XML. um That was partly because I found I was trying to shoehorn all this information about different tasks into something that could be serialized and then put into base64 and all this structured data, just it really fit nicely as XML.

C

Obviously, we might not want to mandate XML for use in other protocols, um but it's definitely something to think about how we could represent stuff in in a nice way inside um the tasks themselves and I. Don't know whether that's you know something, we want to standardize for all tasks or maybe on a task by task basis and just say what the the payload type is.

C

uh So the other thing we did was um client identifiers and- and this is a new one- we added. um There are a few reasons we wanted to be able. So we have things like um we have questions like which clients are trying to use these outdated Satchel mechanisms like digest, md5 and such, and we didn't really have any kind of user agent pre sassle in in xmpp. So we wanted to include that, along with the initial Authentication, um it's it's optional from the client's perspective.

C

So it's up to them. You know what what information they give and the second one was a stable, unique identifier. So this is a uuid or something like that, um and that was useful for uh knowing for the server to know which um which tokens to compare with on the server side. So I think we're going to talk about that a bit later. This is using the Satchel HT um yeah I I yeah I I.

C

Note that browsers are trying to deprecate user agent and I've tried to be mindful of that in in the uh zep, with the wording like regarding privacy and so on. It's not quite the same um because you are obviously only sending it to the party that you're authenticating to and so on, but but yeah I think there are definitely things that we could discuss there.

C

um So the unique identifier uh helps with those things and it's it's similar to the um authentication ID except it's uh specific to um one of the user's clients, and so the user can have multiple clients um with different parameters.

C

uh So one of the other things that we used the tasks mechanism for was, um as I mentioned before xmpp is very much stuck on scram Shell One um servers have been storing hashed versions of credentials for a long time, and so we can't simply upgrade on the server side, um and so one way to sort of upgrade to say shell 256 is to ask the user to reset their password. But this is awkward.

C

um We I think we do have a spec for that, but the user experience isn't great because they're, probably just you know, think why can't I just enter the same password. That kind of thing. um So we wanted to see if we could do something a bit more automatic with the cooperation of the client, and so um we worked on uh this defining these upgrade tasks, and this has mostly been the work of tilo who's who's on the call foreign.

C

And yes, um that's a good point: they the upgrade tasks, avoid sending resending the password in the clear which the password reset mechanism does.

C

uh So these are just some examples, um the uh so this is the interesting part. So this is a normal authenticate, um so we're starting scram authentication um the upgrade task that the client recognizes has been selected up front as well.

C

um That's so that after the credentials are verified, the server knows that the client supports this upgrade mechanism, because otherwise it might because the tasks are mandatory. The server should only send back upgrade mechanisms that the client is known to support, and you know actually is able to complete foreign, so I'll skip through most of these, but you can review the slides if you need to um so. This is uh declined executing the upgrade task, providing the information.

C

um And then, eventually, we get the success response, which is the end of the normal, uh so uh negotiation.

C

um The other thing that we've had in xmpp is um we had uh scram plus uh widely ish implemented, but we haven't really had much success with it on the network. I think it's used in Pockets um around and about because largely because we sort of introduced it just as TLS 1.2 was going away and we had uh standardized on um the TLs. uh Unique I forgot the right way around. uh That was only defined for TLS 1.2 and not for TLS 1.3.

C

um So implementations have started now supporting TLS exporter, which is supported in TLS 1.3. However, because scram doesn't include, for example, in the mechanism mechanism name or any advertisement about what uh Channel binding methods the server supports. If the client picks the wrong one, then the authentication just fails and the client doesn't really know why it failed and doesn't really know what other avenues it can take like. Should it try again with a different Channel, binding mechanism or what so?

C

This is a real problem um that we've encountered interoperability, issues between clients and servers, and so we had to uh create this method. Where the server can advertise to the client uh which channel binding methods it supports, um and this can change per connection depending on, for example, if the client connects with TLS 1.2 or 1.3.

C

um Also tilo's been working on uh Channel, binding negotiation, downgrades um which I I personally find very theoretical, uh given that it requires someone to be on the TLs Channel, but I get there are use cases for that.

C

um So that basically involves various um methods to have the client and server agree on what the client saw and what the server saw and and tie that into the uh to the scram negotiation.

C

um So yeah this is defined in z474, which is new at the xsf.

C

um We don't have any server implementations currently I think but I think tilo has worked on at least a client implementation, so we'll probably get to that soon. Foreign.

C

And that's more or less it I hope. I was on time um and yeah. So I I think Alexi's list of uh specifications was a bit more complete and had links, um but yeah.

A

Right, let's open the queue for questions, Ben.

B

A

B

Yes, great um so I guess we sort of started talking about this in the chat already, but when we were doing the TLs exporter Channel binding type. My understanding was that uh the party that speaks first, which I think is the client here- would look at the TLs Channel and say if it's TLS, 1.2 I will use the TLs unique Channel, binding type and.

D

B

Has three I would use a Tails exporter and so I was curious. If you had some more insight about how that breaks.

C

um I suspect that the client that I was dealing with which I forget, which one it was um because TLX export it can technically be used on 1.2 I, believe um I think that's what they were doing, but I yeah I'm, not I'm, not sure I, don't remember the details. This was um at some point last year, so um I can try and dig that up for you. If you like and figure out exactly what was going on.

E

I I think it was. uh It was in fact my client I tried to use team X TLS exporter on each body for TLS 1.2 and it failed. If I recall correctly, we.

C

Try to sorry yeah.

B

E

C

B

To put some text in respect to uh have you not tried to use TLS exporter when there is an existing ecosystem? What maybe that didn't.

E

Work yeah, even if even if you put the TLs export things aside, um some server setups can only provide TLS server, endpoint or some such and if I have such a server, it would be better to do this. Tls server endpoint Channel binding instead of the not supported TLS exporter than nothing.

E

So if I don't have any negotiation, I can only do TLS exporter or nothing, but not the server endpoint stuff right.

C

Okay, Dave yeah I think that's what I was thinking of um I I just remembered, so we had a server that was doing um server, endpoint and then yeah it. It kind of falls. Apart with that negotiation.

F

I was just going to where to reiterate the that, as I said in chat, the the xmpp community has used Channel binding, quite heavily um more heavily I, think than most other uh communities of this kind of nature. I've never seen it in email, for instance, but it means that we've experienced cases where TLS exporter is great.

F

um That came out of the xmpp community. Indeed, uh there is some use of of the endpoint as well, um and that is often the only thing, that's possible if you have early TLS termination- and we also have plenty of experience in cases where you can't use any channel binding at all, because the the client is, for example, a web client where there is no Channel binding data available. So I think there is a need for negotiation, even though it's not the the ideal situation in a in a purist sense.

C

Which so one other thing I note that the Sasol HT mechanisms encode the channel binding method into the mechanism? Name which may or may not be the the right way of doing it, um but that that does solve it. For that set of mechanisms which has been useful. I can say.

A

Right, this is a good reminder that, if we are going to take on all of this work, we'll need to make sure it's all kind of makes sense together.

A

A

Any other questions.

A

Do people feel enthusiastic about too I know we probably have majority of xsf on the call, but uh I'm still interested to see what are other interests. Other people, um it's a it's a interesting collection of ideas and we don't necessarily have to um take all of them. But if anybody wants to speak up.

F

Just make one one other comment: uh I did spend a little time sketching out, um but not publishing, because I didn't get around to it um a uh an idea for taking most of what was then sassel II, which was uh in a previous version of the spec, but wrapping that up such that you had a nested saddle profile Within.

F

What we badly call saddle one so.

A

We did actually talk about this like five years ago, yeah.

F

Yes, I know I, know well.

A

This might be just one way of uh kind of implementing this.

F

But it would, it would mean that there isn't necessarily such a major breaking change, um I'm, not suggesting we. We even need to do one or the other.

F

We can do both if we want the the feature successful too, but the extensibility in particular, but the that that would give you uh that would give you the the mechanisms that would give you uh tasks um and I think it would also potentially give you some of the some of the additional uh parts that uh Matthew and Tila have added uh like client identifiers and things like that. Right.

A

A

Okay, um let's move on.

A

um I grouped with this one more presentation, so um my theory, if can, if you can let go of the control, excellent right uh Rick, they want to come in and try to.

A

Yeah I can see slides now. uh One thing that occurred to me is that actually some of their pre-authentication stuff can possibly be done by from Key derivation. If we had a facility for saying that you know an extended social profile, you know if there is a social mechanism that satisfies it and it has key derivation function at the end of authentication. It can be used for your authentication, for example, uh and I. Think correct will talk about other cases that he had in mind.

A

Please go ahead.

B

The instant enable his audio stream.

A

um Yes, I just saw message from from Rick.

A

Well, I can show you uh you can flip through your slides but I'm afraid you kind of need to explain them.

A

uh What we can try to do is uh Rick, maybe you can try to uh disconnect and reconnect and see if you can sort out your audio foreign.

D

A

Now I can hear you so perfect. We.

D

Should do the slides instead, sorry about that I, don't know what happened I tested beforehand! That's all right! Could you share the slides, then.

A

I can show you slides. Yes,.

D

So this is mostly an idea, just a thought that came up um with Cecil. We usually don't use the security layer, but that's because we consider it encryption when it's used in a profits and force I think that's a very potent possibility, because Sasol um protocols usually run over TLS and TLS basically does.

D

If you have an encryption and if you have a public key or keys are signed with a public key Diffie Harman as far as I know, does not have a Quantum proof alternative, so that basically means that all TLS stuff is at risk of being cracked by a quantum computer. And that's a big problem.

D

Usually what's being done, then, is to look for some entropy to mix that with the different Helmet Key exchange, so that you get something. That's at least also needs the secret to be known, as well as the cracked diffie-high um Cecil usually has entropy or sorry a secret, that's shared by by the two endpoints already, and it used it to derive authentication.

D

But if you could also derive a key, you might mix that with whatever you're doing at a transport, for example your TLS, and to benefit from that, um and one place where this came up is when I looked into opaque, which has a great possibility for extracting uh key material, but to use that for encryption is a bit silly if you run it over TLs, but to use it for all sorts of other purposes. I think in general is a useful purpose. So I added this to a spec that I wrote it's a different example.

D

It's not TLS um next slide, please. This is uh realm crossover, basically a client on the left and a remote domain, which is their domain where they have an account. They they exchange a key, and they do that beforehand. If, with that, an end-to-end encryption tunnel can be set up and S6 over plus does exactly that. It passes plain to social authentication inside the tunnel. The client program will pass it to wherever the server is.

D

Some third party that doesn't know about the account it mentions the domain name and then, with that saso can be ported back to the client's domain to the remote domain um over diameter and that's basically, the assessor tokens are passed back and forth until the domain says either it's uh rejected, or it's accepted as this user identity.

D

Next slide please. So this can be done with just about any protocol. um It's basically just Sasol used in a in an awkward way in a different way that can be done with all Sesso mechanisms and basically all Sasso protocols. It just sits in between um this is one of the most wild examples that that I have thought of and that I think might be really cool to use, and that is when you go to a cafe or something you want to use the Wi-Fi.

D

um Why not use Satchel to log on to it extract the key? Have that key, delivered back alongside with the diameter stuff and use that to have your local Wi-Fi connection, secured and then parcel the traffic to your home network, where you have an RP address in your room home in your home network, so that nobody really is bothered by um oh gosh I'm I'm, giving away uh bandwidth because it's not within the RP range or anything scary you might be doing- is not all the responsibility of the IP address owner.

D

This is just an idea. Just a possible application. I think there are many more, including, of course, the plane, encryptions security layer, stuff, that's sometimes used, um but in general I think the entropy that we have in the secrets that we share with Sasol um can be a very useful benefit in a time that we have quantum computers and needs some form of entropy to be able to derive all sorts of things. So that's why I'm? Basically, it could be very useful to use that and think about key extraction mechanisms for Cecil methods.

D

That's what I wanted to share.

A

Comments, questions.

A

Yeah Dave go ahead.

F

I put this in the in the chat anyway, but um when you say defi Hellman I assumes we really mean elliptic curve if he heldman, probably yeah. Possibly the screen algorithm, definitely, which ironically, is slightly more secure against Quantum Computing as I as I recall, probably because it's bigger, um but there are other uh diffie-hellman possibilities. uh I know that there was I know, that's been at least one uh Quantum proof version thrown around based on lattices by no cryptographer.

F

um So in principle, all of the post, quantum or Quantum proof. Problems can be addressed at the TLs layer by changing the diffie-hellman. uh Whatever it is, it's a generative group or something like that, isn't it, but that uh that mechanism.

D

Okay, that's news to me I'm very happy with that. um I still think that you, so it basically says that this example might not be applicable.

D

um I still believe that in general, since we have the entropy available, or at least the secret available, that's shared between two parties, Crypt of cryptographically uh beneficial, to be able to extract key material from that, especially with something like opaque. That is so very good at doing that, but that's yeah.

A

Yeah my um as I mentioned quickly, my use case is a bit different is for the authentication you can extract. If you have key derivation in both scram and OPEC, then you just say created authentication token using key derivation and you say it's in direct generic way and then the authentication mechanism can be used with eight of them. Basically, that's that's. That's the benefit. I see so kind of glue that can be used for multiple things.

D

Yeah, indeed, for multiple things, also, the hash token might also benefit from it.

A

A

D

Rick, thank you.

A

I think that's now me I will very quickly.

A

Okay, so look at this.

A

I will quickly do update on on scram to factor authentication I've just done it last week, um Simon so um initially I added uh gltp that was basically stolen from Dave krillin's zap. So thank you for that um and then Simon Josephson said well what about Fighter, 2 or Fido stuff, um for you know, working with USB devices, NFC, Bluetooth, low energy and stuff like that, so basically um I think he mentioned it last summer. It took me a couple of months to actually go through various specs to figure out what it was all about.

A

um It's quite a comprehensive framework in itself for authentication uh and yeah I basically was slowly working on it.

A

You can see details in the document if, um if you dealt with Fido stuff in any of your projects, if you can read what I wrote and double check, whether it makes sense and whether it's detailed enough, if you haven't but want to give it a try, also try to implement from what I wrote and see if it works, and let me know obviously so um the other bit that I had already had in the document was.

A

uh Re-Authentication token.

A

A

I was thinking about you know um it's nice to have Cecil 2 framework, but if, if you are using a different protocol and it's not available and If deployment will take you, you know five years, maybe I'm a bit pessimistic, but you know um then I would like to have inbound way for.

A

Returning authentication token- and basically there is an attribute for this and then this authentication token can be used directly with HT subtle mechanisms uh without any uh protocol machinery for requesting them explicitly and then basically, if client, so server will return. One of these, if clients uh wants to do quicker, authentication recognize this extension. It will use the token and then we'll use HT making this one after that, so yeah have a read. uh Let me know what it's understandable. If you want to cut and paste the text to any of your documents feel free.

A

um And then just quickly um to introduce uh next talk, I just want to. uh Why do we care about faster authentication just to make sure that we're all on the same page.

A

I think a lot of applications either need to re-authenticate very often because they get disconnected and they just want to do it without prompting user for the password, but also some of them use multiple Connections in parallel, because there is quite a lot of drive to use to multi-factor authentication onto-factor Authentication.

A

uh Can you imagine that every time you reconnect you get a prompt to for SMS, this will drive you as crazy, so I think the idea here is once you authenticated and did two-factor authentication. You can get re-authentication token, and then you will do quick, reauthentication mechanism that, firstly, it will be, it will bypass the fact authentication and second, it will be just one round trip, so it will be um quicker to do and probably will be less CPU intensive than the full scram or or pack um Exchange.

A

D

Yeah first, first of all, lovely developments, um I'm, always a bit afraid of re-authentication we've seen as delicious. It's very difficult to do it well, and then it becomes a problem, um but I have um on another path. I've tried to embed social in HTTP as you've tried before and I'm now trying um and yes, it drove me mad to have to log on with every different page or with every TLS connection draw because there, of course, it might happen anytime that you need to set up a new connection so yeah.

D

That would definitely be beneficial to every fast re-authentication.

A

Right and uh the way it works uh you know, server can decide that it will allow the authentication for, like so many times so for a certain period of time and then at some point it can. It can reject and then it will force the client to re-authenticate. You know using the original mechanism or similar mechanism, so yeah it's another component in the toolbox.

A

A

A

So with that introduction, Dave yep.

F

Yeah, sorry, and just as a a general comment on fast re-authentication tokens. Obviously the token is is very- uh is very high risk.

F

um If someone obtains that token there's been a number of of HTTP based session token, stealing attacks recently um Circle CI and last past were both at that later, I believe, and so obviously you you, there is a lot of risk in in these. uh These tokens um I think it's very important that those that the token issuing uh is also uh combined with the token listing and um and other token management and uh token revocation solutions for that are available to the user.

F

Now I know that the original designs around uh around HT that Florian did maybe Florian can talk about them more around ISR, for instance in the xmpp world, also included the ability to to track uh which device it's already used by the by the user, which uh which had a token I believe that was all part of it and I think that's a lot of the driving force. Maybe Matthew and T Logan will correct me, but I think there's a lot of the driving force behind having device identifiers in in the newscastle too.

F

So I would be very hesitant about handing out tokens without suitable tracking and management.

C

Yeah, that is why one big reason that we added the identifiers.

A

Okay sounds good right. I'll give Florian opportunity to present.

G

My check was this thing on yes, okay, I turn on my video. Also. This should also work. Unfortunately, my camera is to the right, so my left side will be a mystery for you and I'm going to try to share some slides.

G

I requested to share slides I think you have to approve it.

G

Okay, um ah okay I can only checks this pre-selected, slides Okay, so hello, um I'm Florian, thanks for having me and um I think I have to continue with the tradition of disappointing Dave by saying that the is Eric step actually has no mechanism for tracking or managing tokens, but I agree that something like that would be nice to have. Certainly um with that I'm going to talk about the mechanism.

G

um And I start with its origin story, and um the original motivation is except I wrote um also many years ago. That seems to be a common topic today.

G

That's called instant stream resumption and instant stream assumption um is actually motivated um by XMP peace, long reconnect, delay I gave a talk at fostem 2015 about that, but the gist of it is that um just like a two to three seconds, delays that you always have until the xmpp session is usable, uh using techniques um that were available back then- and this was probably fine in the non-mobile age, but today, with mobile devices that encounter frequent reconnects, we have to do better.

G

So initially, um HT mechanism was part of this ISR specification and I think it was Dave who encouraged me to um out Factor the sussel parts into an extra ID and to put it into the kitten working group for review and comments and of course, I'm always happy about feedback says. The current state of the ID is a working draft and it's there's probably many things that can be improved.

G

So what is um Cecil HT? It's a very simple set of mechanisms for Bureau tokens and um the basic idea is just to be a little bit better than using Sasol plane. So you you obfuscate, the actual token. By using an hmax to construct, um you can borrow some IDs from scram to get Mutual authentication and if you mix in Channel binding, that's always a good idea.

G

um Channel binding was initially mandatory in the ID, but um Matthew asked me. Matthew antilo asked me to also add support for a channel binding, less flavor, um yeah well, and the reason is web clients So Below on the slide. You see Cecil HD score, which is a very simple construct.

G

um So the idea was um to to don't have multiple sassal round trips because we want fast or instant authentication. Basically, um so the current situation is um the is Eric's app and by set I also mean um the HT mechanism was written before GLS 1.3 was standard, standardized and backsense. There was a lot of Buzz about TLS 1.3 early data and when I looked at it, it appeared as a good fit for Cecil hd's.

G

First message to show off this message into TLS early data, but I think it was Nadia ever pointed out that TLS requires that early data requires the usage of a pre-shade gear, pre-shared key, so the ID currently talks a little bit about early data, but I basically think that um it's not really what you want to do. If you want really fast re-authentication, you could also think about using TLS, PS key and maybe sussel external I'm, not sure if it would work I'm, not absolutely sure if it would work on a technical perspective.

G

So this is something one has to figure out, but I've looked at various TLS psk implementations and their apis and I think it looks promise promising and doable. But if those ingredients are not available, not every TLS library, May Provide support for psk, then you can always fall back to performing a Cecil HT, which should always work because it doesn't require anything from from the TLs library and from the TLs layer. If you don't do Channel binding so well, more or less. Unfortunately, my instant screen resumption zap did not catch on.

G

However, we see current there's currently much traction in the xmpp community for an alternative sap. um That's accept fast by messian tilo, and that also uses Sasol HT and whatever gets us fast. Reconnects um is what we should do, because that's something mobile xmpp users certainly suffer from so the set I. Thank you for your attention.

B

In and confirm the to jump in and confirm the TLs 1.3 early data psk usually comes from a previous handshake. It doesn't have to be a external configured psk.

G

I'm sorry was this a statement or a question: I didn't catch. It.

B

It was a it was a statement. uh Okay, sure. The way you described it, sort of swept that part onto the rug, um so I wanted to make sure that the whole audience knew that.

G

So um maybe I can, since, since we have many knowledgeable people here um using, for example, Alexis o attribute to obtain a token, could I feed this token into the TLs psk and use subtle external? Would that be feasible.

B

I think that the protocol pieces are all there. You would have to ensure that the token you get has you know the right amount of entropy and whatnot doesn't have any um like identifiable personal data or something that's in the clear but I think at the protocol level. That would work.

G

Okay, so that's something I'm considering looking into okay.

B

Yeah, your server-side implementation would be a little bit complicated to you know, hook the pieces together where you're looking to your database of issue tokens in the TLs layer as the pre-shared keys, but I think that uh most implementations would at least give you the Rope to build that. Even if it's a bit clunky to to.

G

The only thing I'm not sure about is if TLS psq requires some chord, some sort of identifier for the PS key for the key. Thank you so that you can provide the identifier and the secret key.

B

You can see two need to have something like that, but you can always have a convention based on you know, issuing them together from the attribute or naming or using the identifier as a hash, with some other name, data.

E

Okay, um quick question: why show the token in into the psk, if you could just use the TLs 1.3 mechanism to generate the psk for the early data in the first connection and then use early data in having the talk in the early data in the second connection?

E

That wouldn't be that complicated? uh So.

G

You basically suggesting we should retrieve the token from the TLs stack and not not from somewhere.

E

No, you, you generate a random token uh store that on the server- and this is the first TLS connection, so this generates the psk for the second connection, using early data and then in this early data you just sent over the random token. The client and server agreed upon in the first connection and this I'll take authenticates the client to the server in the second connection.

E

Wouldn't that also work.

B

I think it becomes a little bit harder to make workable, because the early data in TLS 1.3 is considered part of the application streams, and so you need your application to have a protocol. Spec saying this is how we're going to use the early data to to do.

E

That yeah yeah that's right, yeah guys.

A

Okay, sorry can I can I uh I'm just mindful that there are two minutes left and some people will disappear at the end of this. um That's a great discussion. I wish. We have more time, can I move to the last slide. I just want to kind of figure out what the next steps are, uh whether we want another, you know meeting you know, etc, etc.

A

So let me just quickly: do this.

A

A

Sorry, I'm kind of jumping to the very end.

A

We don't need to decide on any specific technical details here.

A

um What I would like to know if, first there is enough interest to work on re-authentication mechanism in the kitchen to take it to the kitchen and try to adopt it as a document uh and do this work and then also if people are interested in starting uh subtle, 2 type draft, which is more generic than just XMP and again try to adopt a 10 kitchen.

A

Would people be willing to work on these and interested in progressing this.

A

If you can just speak on audio or or on the chat, either way is fine.

C

um I can say that the two-factor Earth in scram, well clever, probably doesn't satisfy my requirements, as is um I, don't know I I, it does tie us to. Obviously it doesn't tie us specifically describing the same thing can be done and repeated in other mechanisms, but it does, for example, roll out using plane and then using two factors which you know some deployments in xmpp definitely do have playing and like I, can't see that changing anytime.

A

Soon, I I think uh I propose, will kind of pursue both uh for people who couldn't wait uh for social to. uh There is an example how to do this with scram and it works for OPEC as well, because of the same uh syntactic structure, uh but I'm. Definitely up to working on the uh you know, two-factor within the social 2 framework.

A

Does it answer your question sounds good yeah, obviously, I mean this is just my proposal. I cannot do a proposal as a chair of the working group I still trying to get consent as well. There is enough interest, but I'm sensing. There is enough interest, but I kind of want some kind of confirmation.

B

Yeah I think I'm in a similar boat, where you know the scrim dedicated to factor Roth is potentially useful for some cases, but I would prefer to have the two-factor support, be sort of more generic dropped, and so the bits about doing a slimmed down sassle to you uh that would include two-factor stuff seems a little bit more appealing to me. Okay,.

A

Yeah I think uh for me, is I, probably will Implement both, but in short term I probably need something Quake that doesn't because uh I will need to to make this work in SMTP, IMAP and ldap, probably, which is probably quite a bit more work than you know, and first we need to Define what susselt2 is right.

A

A

Okay, uh any other comments.

A

Yes, Dave, we can always layer another thing on top of another layer. Another thing all right, um thank you all. uh Nadia I'm. Sorry, we kind of ran out of time for OPEC. Would people be interested in another in three meeting in a couple of months or should I start? um Shall we start with adoption, calls first for other authentication mechanisms, for example, foreign.

A

I'll follow up with various people and, let's see if we can do some progress on what we've done and also we can have a discussion on OPEC as well.

A

Okay sounds good. Thank you all thank you for coming.

C

A

All right see you around.

G

um Alexa will the room stay open if you leave.

A

um I'm not sure it might not. Okay,.

G

uh Shall we switch to another venue or everyone interested of course.

F

I'm, probably interested as well but I'm, not sure how long I can stay.

G

The same okay tilo: would it be the kind and paste the link and Alexa? Would you wait until the tilo has posted the link in the chat sure.

G

E

F

Alexa is an obscure question. um If we are moving to a BBB server, I assumed with them know, Well no longer apply. What does it.

A

Well, uh How likely of a problem. This is going to be.

F

Well, very little hopefully, but if it is a problem, then it becomes a massive problem.

A

Well, if you're, if you guys having a discussion on another server going to introduce IPR, this IPR still need to be disclosed. When you bring this book to the ATF, so.

F

A

E

E

Okay, see you over there.

A

Okay, see you bye all right, see you guys.