**Session Date/Time:** 23 Jul 2026 09:30

[00:00:41] **Alexey Melnikov**: Oh, yeah. Thank you. I was about to ask. Right. It is time. We do have one hour. So this is kitten working group. We do have kind of three presentations. We might not take the full hour, but if we need more time, I think we are fine. Kitten working group is the one that doesn't meet very often. We do have entrance once in a while. But when there is a spiral activity, I think it's it's nice to make community aware of what's happening as well as to discuss potential new work. So I'm Alexey Melnikov. My co chair is probably asleep in US. This is super inconvenient time for West Coast. So this is just a reminder. This is a note well. I hope you are aware with this. You've seen it before. If not, please investigate by basically, there are various rules that you're obligated to follow if you participate in the ITF within meetings or on the mailing list. Various BCPs related to this, how you know, process, anti harassment procedure, code of conduct, etcetera, patents. Most specifically to well, this is relevant both to meetings and mailing list discussions is remember of kind of conduct, treat colleagues with respect, speak slowly, try to avoid slang because a lot of us are non native English speakers and can miss various, you know, idioms, etcetera, etcetera. User is an argument. Use the best engineering judgment. It's okay to attack the argument, but never please attack the person that presents it or on the receiving end of it. So okay. With that, would anybody be so kind to take some notes? Mostly, like, the major decision points. If not, I can probably cope. I I I don't think we'll have that. That would be great. Do you know where? Yeah. Okay. Thank you. That very helpful. Like and add your name and, you know, I probably didn't copy the template, but thank you. Okay. So this is our agenda. Administrative is five minutes. Me rambling about, you know, ITF process and all the rest. So we we just done that. I will do an update on various documents and just draw people's attention to various things happening. At the moment, this is mostly the SASL's side of the kitten working group, and then we'll have two presentations about side about new potential work. Any agenda bashing? Okay. With that, And I don't know whether editors of various documents I'm talking about are going to be in the meeting. I tried to invite some of them. Maybe it was a bit last minute, so we'll see. If I say something incorrect, please feel free to correct me. You know? That that's kind of part part of this. So we do have actually a fair number of activity at the moment in the working group, which is nice nice to see. We had a hash token. SASL mechanism document was in working group last call. The last call ended. There was a fair bit of comments. I think most of them are resolved, but I will have a you know, next slide, I'll show you where we are on this. It looks like the document will need at least one more revision to address the comments. There were some technical changes like changes to what's being hashed, for example, which have quite significant impact. At the moment, so the previous versions of the document were defining something that was implemented, but the document broke compatibility. So the mechanism names were renamed from HT to HT to something. For because of that, my understanding at the moment, there are no implementations, but there is interest to implement this. So and as a reminder, HashToken SASL mechanism is one round trip pre authentication. One of the two mechanism in this space. Then we have Kitten password storage, best current practices for social password caching and storage. This is currently in working group plus call till the end of the month. Please review. I will have another slide saying that it's just the same. So in case you just had an app, you know, I'll remind you. We also have a couple of SCRAM-related mechanisms, documents. One we recently adopted is a document about different KDFs functions used in a core of of SCRAM. It's basically use the same machinery, but allows the crypto parts to be replaceable with more modern technologies, and we can evolve this. They're not you cannot migrate from one mechanism to another in a sense that, you know, hashes cannot be reused, but it allows the framework to evolve and use, you know, new deployments use different stuff. We are going to figure out whether this is going to be update to Scram, whether the you know, whether they're going to be new make SASL mechanism names for for for this sort of thing. So this is one of the open issues. And then the document on two factor authentication for Scram was refreshed just because it was expired. We have another quick re authentication document called SASL Remember Me adopted. It's currently expired. We might need co editor for this one. I was hoping that a current editor will be in this room, but it's okay. I'll I'll gently nudge him after this meeting anyway. So going into slightly more details on this. Right. So this is a summary of issues raised for the hash token authentication mechanisms. Simon Josephson great did great review of this, raised a bunch of issues. I think I mostly listed them on the slide. The issues that are underlined, I think we have resolution for. Maybe not in in the updated document, but I think editors agreed that this will be done, and I think we know how it's going to be fixed. So one issue was HMAC over transcript wasn't covering the full transcript, which was a obvious submission. I think there is agreement to change this. There was a discussion about in SASL, you have concept authentication ID is who you authenticate authenticate as, and then you can have separate authorization ID so you can assume somebody else permissions if allowed by the policy and you authenticate successfully. So the text about how authorization ID, it was defined as missing. It was unclear what it meant and what the implications are. I think there is there are some suggestions where this is going, but this probably needs a bit more discussion. Simon also pointed out that hashed extension TLS session hashed extension reference for TLS 1.3. The text in the document was TLS 1.2 specific. It needed to reference for TLS 1.3 in slightly different text. Again, this doesn't sound super con controversial because it's basically just doing similar thing with proper references. There was also text in the document allowing arbitrary key value pairs to pass extra data as a part of authentication. Several people commented that that sounds like a very wide scope. You can, like, tunnel a bunch of stuff there, and you don't even know whether it's related to authentication at all. I think editors agreed that the scope was too wide, and they will tighten the language to use something similar to other SASL mechanism that that have extensibility to be more specific about the use cases for this and and and how to define extension mechanism. And then the last issue that still needs a bit of discussion is how channel bindings advertise, which ones I recommended. There was quite a bit of discussion and where the policy about what is recommended. Is it protocol specific? Should it be in the base in the base spec? I think that still needs to be resolved. Again, so this document is passed working group plus call. However, if people want to do late reviews, that's absolutely fine. This will make this chair very delighted about this. So if you have other comments, please do so. Any comments, questions on this? I'm just going to check whether Simon is actually in the room. He doesn't seem to be. Okay. If there are no questions, I'll move on to the other stuff. This is your second reminder that we have a document in working group plus call, and the document the working group plus call is ending end of the month. So please review. Please send your comments. I know Simon did a review. I will do a review without without my chairs hats on as well, but we need more than that. So please have a look. It's kind of interesting design document because it affects design of other SASL mechanism and what we put in them. But, yeah, have a look. Send your comments. Let us know if you agree or disagree with recommendations. And, again, I think I mentioned this already. So we have one Scrum related document adopted, and we also have two factor authentication. So for the newly adopted document, somebody I will try to do that, but hopefully somebody other than me also cross check the three documents mentioned that they are all in sync, and they all have the best recommendation. I appreciate that one of the documents is my documents, which is not currently working group document, but, again, if people can cross check that by this recommendation. For example, recommendation on iteration counter used by default that they're consistent between, you know, scrum documents and password storage. So that would be very helpful. Okay. With that, any other thoughts, comments on the Sasol part of this? Everybody excited about Kerberos now and JSS? We have to have a little dance. I don't know. Alright. Fine. With that, let's talk about some proposed work. Shall we try Clicker?

[00:15:48] **Presenter**: Can we have a senior question session with him? We

[00:15:51] **Alexey Melnikov**: Entirely up to you. You're the boss. Okay. Think, Joel, he he wants questions at the end. Shall we do questions at the end of each document? Or or you want

[00:16:05] **Presenter**: not have enough time. Like so this way, I'm sure we I go through all the presentation before

[00:16:11] **Alexey Melnikov**: K.

[00:16:11] **Presenter**: We go for the question.

[00:16:12] **Alexey Melnikov**: That's fine. I think we have enough time, so don't don't Okay. So then

[00:16:17] **Presenter**: we can have question.

[00:16:18] **Alexey Melnikov**: Yeah. I I wouldn't worry because I think when I only use sixteen minutes, and we have we still have, like, forty forty four. So and you asked for twenty. So we should be alright. Try let's try this quicker. Yeah. Yeah. Okay. Here we go.

[00:16:36] **Presenter**: So good morning, everyone. I'm. I'm from Red Hat.

[00:16:42] **Alexey Melnikov**: Try to speak probably or even take the mic if you want, you know, your hand.

[00:16:51] **Presenter**: Is it better now?

[00:16:52] **Alexey Melnikov**: Yeah. Yes. Okay.

[00:16:54] **Presenter**: So I'm. I'm from Red Hat. I'm the maintainer of MIT for and. I also sometimes contribute to MIT. I'm going to present two different drafts. The work on this draft is part of QR project, which is driven by the Bernard University of Technology and funded by the European Union. So again, it is basically the extension of the Kerberos protocol that enables client to authenticate using x five zero nine certificates. So the first draft is about deprecating some outdated parameter and algorithm in this standard. There are four changes in the first draft. The first one is about transport. It's one of the three methods that are currently supported along with FiniteField Diffie Hellman and Elliptic curve Diffie Hellman. This method is well known for being vulnerable to type of attacks. It's already actually completely removed from MIT Kerberos. It's disabled by default in handle. And if you enable the if the credential guard policy is enabled in Active Directory, it's also disabled. The second change is about the MODP, well known MODP group two, which is used when using Finite Field. It's part of the original PKINIT RFC. It's also well known for being weak parameter. It's one of the reason why the IKEv1 was duplicated. It's already blocked on Federer and RHEL. And so it's also blocked on Windows if the credential guard policy is enabled. The third change is about the octet string to KDF. This is the KDF the only KDF that is defined in the original PKINIT RFC. The main problem is it's based on SHA-one. There are now alternatives that were defined in RFC eight six thirty six. These new RFC, have the advent these new KDF, have the advantage of being based on SHA two. And also, they are they are used as an integrity checking mechanism because in the original, only accepts the shared secret while with eighty six thirty six. They are based on both the, you know, the request, some parts of the response, and the shared secret. So basically guarantees integrity on the on the request, which is useful, especially especially for anonymous mode in PKINIT because in this mode, there's no certificate to sign the request. And the final change is about PHX sum, which is so it's a checksum of the payload, basically, of the initial request, the KDC reg body, basically. It's using SHA one. Microsoft implemented an additional checksum using SHA two. It's kind of duplicated of the KDS from LC eighty six thirty six. That's a change we mainly like to introduce in the LC because contrary of the other extension that are part of the other part of the Microsoft extension, this one is required in a lot of cases when authenticating against active directory. That's actually why it's already implemented by MIT, Keros and Heimdall. So this is about the first the first draft. So if you have question or remarks, please ask now.

[00:21:31] **Alexey Melnikov**: So Out of curiosity and without no commitment to implement, who is doing the to work in this room? Can you can I have a show of hands? Okay. Alright. Nobody else wants to admit. Alright. Fair enough?

[00:21:54] **Presenter**: Okay. So the second draft is about bringing post quantum key encapsulation support in Kerberos PKINIT. So the core part of the Kerberos protocol is not really vulnerable to post quantum to quantum computing attacks because it's based on symmetric cryptography. But PKINIT is since it's using asymmetric cryptography. And because of harvest now and decrypt later problem, we have to adapt quantum resistant algorithm as soon as possible. So this is the draft we have. It's basically a digest of the discussion discussion that has been happening on the mailing list for a few months already. It introduces a chem path, which is very similar to the Diffie Hellman one, which was a recommendation made by Nico Williams, who is working on Heimdall. We introduced a few changes, especially on the KDF side. One of the problem we have the previous implement in the with the DH path is that the in the response, the KDF identifier is not part of the science section of a response. So for security and safety improvement, we moved it to the science section. Also, in the draft, we try to clearly differentiate the part that is about the CAMPAD the CAMPAD definition and the policy that is in charge of ensuring quantum resistance. In practice, it simply means that the list of algorithm that are part of the campa the campaft must be different from the list of the algorithm called Concept dot QuantumSave. In practice, it's currently the same list, but it must be written in a way that we can easily extend this draft to have different sets of algorithm. We already have a prototype based on MIT Kerberos. It basically implements all the draft except the composite MLKM part. And during the I got on earlier when last weekend, we we implemented a Wireshark detector. Also working both of them are available for federal in this RPM repo. So a few additional details about the design decision in this draft. I think it's a surprise for no one that post quantum signature, ciphertext, keys, certificates, etcetera, they are significantly larger than the traditional cryptography ones. So these are measurements we made with implementations. This de facto requires use of TCP transport instead of UDP. So the draft acknowledges that. We cannot really do any improvements on on the mess in the message size part, but we can improve parameter agility. There's a basically, the the behavior of Kerberos PKINIT when dealing with and the new campaft. Well, is that the client first has to do not first request tentative without necessarily without knowing what's of parameter that's supported by the KDC. So it creates this kind of guess and retry. So, basically, you have you have a first request with a parameter that the client guessed, And then it gets the list of supported parameter in the in the error, and then the client can retry. So, basically, you double the size of the traffic in this kind of scenario. So what this draft draft does, which is based on the recommendation that was formulated by from Microsoft, is that we extended the definition of the the the element advertising. We can need support in the initial request to the KDCs. So by when running the actual packet request, the the client already knows about the supported parameter groups. So, basically, we we just have a single packet request and response. Another important point when dealing with postcotome cryptography is that there should be some downgrade downgrade protection measures to avoid falling back to traditional cryptography. It's a well known problem in the extension that the errors are not signed with the errors and the list of supported parameter it that it contains is not signed by the KDC. The consensus seems to be that it's not really worth fixing with this problem because we can mitigate it by enforcing client client side policies. The idea basically is that if the client uses a post quantum certificate, it must ensure that the whole authentication process is also using post quantum cryptography for both the key exchange part and the request and response signature part. While we also, we should still default to PQC cam key exchange if traditional certificates are used. And depending of client side configuration, you may accept to fall back to traditional cryptography traditional key exchange if it's not supported. So we achieved, like, backward compatibility with all the clients and releases. We know there's there's some room for improvement in the draft as it is right now, especially we haven't reviewed this draft with anonymous mode in mind. That's something that still have to be done. And during the hackathon, we noticed that this list of supported parameters that we include in the initial error, the previous required error, is actually quite large. It it makes the request more than two kilobytes large. And the main actually, responsible for that is the MODP parameter used for field. Problem is that this parameter, it contains the literal value of the parameter while these are actually well known parameter well known groups. So there's still definitely something we can do to optimize that and use identifier instead of the the raw value. So we think most of the changes in these drafts are consensual. At least there's definitely a consensus on taking actions on both these fronts. So we'd like to see this draft adopted as drafts. So if now if you have questions or remarks.

[00:30:38] **Alexey Melnikov**: I'm not going to do a poll because I don't think, you know, people are expected to be here there than necessarily in in the room remotely. But I'll send them a YouTube link so they can watch and, you know, respond after the fact. Any thoughts, any comments from anybody in the room remote? Alright. Thank you. With my chair hats off, I think that the application draft is fairly straightforward. I mean, there are some language about backward compatibility that if this document is adopted, that the working group might want to discuss. But I kind of don't have a feeling which way it will go. So and I'm sure our area director will have feedback. You don't have to to tell me now. You know? I I'm I'm just, you know, more

[00:31:52] **Participant**: the comment that you know, so you're writing a draft of things that have been deprecated for years in practice, it seems, in certain cases.

[00:32:03] **Alexey Melnikov**: Yes.

[00:32:04] **Participant**: Right? And so it I can imagine there's some controversial parts, but it seems like there's significant portions that are

[00:32:13] **Alexey Melnikov**: Yeah. I think out of five changes, you know, probably two or three are, you know, universally noncontroversial, and the other two might need a bit of discussion. Discussion or Right. Yes. But still implemented by majority. So okay.

[00:32:26] **Participant**: Seems straightforward.

[00:32:28] **Alexey Melnikov**: K. And then pick pick you see I mean, this is a very popular topic in the moment in various ATS groups. So I okay. I'm not allowed to say that. Okay. Well, okay. Okay. Yeah. Yeah. Yeah. I I I know what you mean. I don't I don't want to attract the attention of certain people to this working group as much as I want more participation. I don't think that's the way to do it. Okay. Alright. Thank you. And with this, thank you all for coming. I I'll talk to Ben, and we'll follow-up on the two Kerberos proposals with editors and on the mailing list. If we're going to do adoption, I probably will wait till September or, you know, late August just because of holidays. But we can possibly do a longer adoption call. The the risk of it is people think, oh, I still have, like, four weeks to do it. And then they go on holidays, and then they forget. So I'll still have to make them at the end. But alright. Thank you, enjoy the rest of ITF.