Hi Jack,Thanks very much for sharing your insights. I like your interpretations and it solves most of my problems towards the proof. ISTM that Karthik may have proposed the three points independently that are in 2nd paragraph in security considerations and they were (mistakenly?) put together as one paragraph. To me, they don't seem to have any specific logical connection or dependency. Anyway, some thoughts and one small question in "State" part inline, in case you or someone could have a look, please:
On 17.02.26 00:02, Jack Grigg wrote:
Hi Usama,I've never looked at this RFC before, but giving it a quick read with my cryptographic engineer hat on: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.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.)
Sounds good.
Sure, that makes a lot of sense since client and server use different /labels/ in the /exporter values/ (Sec. 5.1). But I feel like the term "unidirectional" in security considerations invites unnecessary trouble rather than being helpful. I don't see how unidirectional is helpful in any way to the reasoning following this sentence, and I would have less confusion if "unidirectional" was not mentioned at all or if additional context was provided why it is being mentioned.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."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 think it is very much possible (and appreciate your distinction of "difficult" vs. "impossible" as helpful). I believe: unless the server (say server A) sends its Exported Keying Material (EKM in RFC8446bis sense) over to another server (say server B), server B should not be able to generate a valid CertificateVerify and Finished messages since both of these messages use the /hashed authenticator transcript/ which includes EKM.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.> 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.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").
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.## *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.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 am not sure I fully understand that. Perhaps the terms "bound" and "semantics" are confusing me. Anyway, I do the following in ProVerif (showing the minimal related steps):
1. Client side: Generate a fresh nonce to be used as /certificate_request_context/ (fresh nonce satisfies the uniqueness requirement) 2. Server side: Add received /certificate_request_context/ as an extension to the Certificate message (this is my addition on top of RFC9261) 3. Client side: Verify that the received /certificate_request_context/ matches the sent one (to ensure freshness of Authenticator)Do you think it matches your reading? In other words, do you think it contradicts something in your reading of RFC9261 in general?
I hope the second set of eyes helps!
It certainly does. Thanks a lot. Best regards, -Usama
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
