Hi Usama, I've never looked at this RFC before, but giving it a quick read with my cryptographic engineer hat on:
> On 03.02.26 21:08, Muhammad Usama Sardar wrote: > > ## *2nd paragraph * > > A whole lot of my trouble is understanding what is being reasoned in this > paragraph and how this is leading to the first bullet as a conclusion. > Could someone explain? For example: > > > Authenticators are independent and unidirectional. > > "Independent" of what? Authenticator would use the > *certificate_request_context* from Authenticator Request, > so Authenticator is not independent of Authenticator Request, right? If > Authenticator is independent of Authenticator Request, then what prevents > replay attacks? (Recall Spontaneous Server Authentication is out of scope > of my email. One could argue that is still in scope for RFC but the quoted > statement in RFC comes without qualifier and logically should apply to all > cases.) > > I read this as "independent of each other". That is, an Authenticator generated by a Server is not bound to any earlier generated Authenticators (whether for the same identity or a different one over the same connection) by the RFC. > "Unidirectional" in what sense? The whole idea of RFC9261 in my mind is to > enable the server to send Authenticators too, since after the handshake, > RFC8446bis allows only the Client to authenticate itself and not the Server > [Sec. 4.2.6 and 4.6.2 of 8446bis]. To me, RFC9261 is bidirectional, as both > server and client can generate Authenticators. > > I read this as "each Authenticator authenticates a single direction". That is, a server-generated Authenticator cannot be used in place of a client-generated Authenticator (or vice-versa) in higher-level protocols. > > This property makes it difficult to formally prove that a server is > jointly authoritative over multiple identities, rather than individually > authoritative over each. > > Which property? I couldn't parse it how it was derived from the statements > above it. > > With "independent" interpreted how I read it above, I interpret "this property" as referring to "independent" in particular. A server could generate an Authenticator for each identity (showing it is "individually authoritative over each") but because the Authenticators are independent, there's nothing in RFC 9216 itself that enables proving that the Authenticators were generated by the same server. Presumably this might still be possible by leveraging the fact that multiple Authenticators were transmitted over the same connection and/or via data within (or bound to) each Authenticator's certificate_request_context (which I presume is why the RFC says "difficult" rather than "impossible"). > ## *State* > > RFC uses 3x"state" but never defines it. What exactly does it entail in > this context? The most important for me is the one in security > considerations. > > > The application in possession of a validated authenticator can rely on > any semantics associated with data in the certificate_request_context. > > I couldn't parse above quoted statement. What does it mean? As per scope > mentioned above, Client validates Authenticator. > > Related to my previous comment, I read this as saying that certificate_request_context is bound to the Authenticator, and thus if the Authenticator is valid, then the validator (the Client in your scope) knows that this is the same certificate_request_context that was presented to (or chosen by) the server at Authenticator generation time. Given that certificate_request_context is opaque, whoever chose it (either Client via AuthenticatorRequest, or Server for Authenticators that do not correspond to AuthenticatorRequests) could have done so in a way that commits to other data or has other semantics (as long as it satisfies the uniqueness requirement). I hope the second set of eyes helps! Cheers, Jack >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
