Op 2024-03-02 om 11:27 schreef Alexander Clouter:
On Sat, 2 Mar 2024, at 03:21, David Mandelberg via Datatracker wrote:
(nit) If I understand the TEAP version negotiation and Crypto-Binding
correctly, the negotiated version is not cryptographically verified until
either (1) after the first inner method is completed or (2) just before the
final result, if there are no inner methods. Is that correct?
Correct (section 4.2.13), these are when the peer sends a Intermediate-Result or Result TLV which must be accompanied with a Crypto-Binding TLV.
Does that mean
it's possible for an attacker to get both sides to speak a lower-than-ideal
TEAP version while performing the first inner method, and if so, does that
matter? Or could an attacker get one side to think it's using one version and
the other side to think it's using another version? What affect would that have
on the first inner method?
I think it does but I do not think it matters as none of the inner methods are aware or coupled to the version of TEAP being used.
In the future, if TEAPv2 came along, maybe the fallout could be that a non-superset of inner methods and attributes would be allowed and there would be no guards that may bump the state machine around.
Not sure what could be done, as RFC7170bis describes what is already deployed.
Maybe a TEAPv2 could use ALPN for the TLS jacket to avoid this..erk, I think I may have suggested something that could be retro fitted here without impacting existing implementations; assuming they would just ignore the ALPN.
ALPN would solve the problem of speaking different versions, but the
version downgrade problem would still stick around until the first
Crypto-Binding, right? (Not saying that's a problem, just want to make
sure we all understand what it would and wouldn't provide.)
(nit) Also, should section 4.2.20 recommend against using that TLV until after
the server is authenticated?
For the unauthenticated server this means really a provisioning process is about to take place which limits what the client is allowed to do next by section 3.11.3. Those methods must provide mutual authentication as one of their requirements.
I suspect we could limit the TLV to only be sent by *configured* clients as they would have verified the server always by that point using the outer TLS jacket.
We though would be unable to do this if someone knows of a use case where two authentication methods for provisioning are required (user+machine auth?).
If it's not feasible to require server authentication before sending
Identity-Hint, then maybe at least document what information can be
leaked by it and in what circumstances? Or maybe recommend that
implementations don't send it by default to unauthenticated servers, but
offer a way for the user to override that default?
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
