Re: [Last-Call] [Emu] Secdir last call review of draft-ietf-emu-rfc7170bis-15

[David Mandelberg <[e-mail]>]

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?