From:
Geib, Rüdiger <Ruediger.Geib@xxxxxxxxxx>
Date: Monday, 19 May 2025 at 09:51
To: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>, tsv-art@xxxxxxxx <tsv-art@xxxxxxxx>
Cc: draft-ietf-ippm-capacity-protocol.all@xxxxxxxx <draft-ietf-ippm-capacity-protocol.all@xxxxxxxx>, ippm@xxxxxxxx <ippm@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: AW: Tsvart ietf last call review of draft-ietf-ippm-capacity-protocol-14
Hi Magnus,
thanks for your response.
Authentication for the data phase and the encryption were added to the protocol, as both are general IETF requirements. The authors
- don’t look at a performance measurement protocol to require strong auth and / or encryption
- are no security experts.
Therefore, an early SecDir review was given and Brian Weis guided us through that. Finally, Brian suggested to present the then encryption approach at CFRG, IETF 120,
https://datatracker.ietf.org/meeting/120/materials/slides-120-cfrg-crypto-in-ippm-capacity-protocol-00. The CFRG experts patiently gave us guidance which implementation would be acceptable to them and we included these changes. So the protocol finally passed
SecDir rev.
We are happy to remove encryption as you suggest, if you accompany the draft during the process to follow and ensure that the draft is not rejected due to missing encryption. We’d prefer to keep
the security functions as these are now and add some text. If this approach is acceptable, what about appending this text to the end of 4.2.4:
Note that the chosen encryption only meets most basic encryption requirements. If to operate in an environment requiring strong encryption, two different keys are required, one for authentication
and a separate one for encryption. One approach could be to use a key-derivation function from the master secret. Another option is to add
DTLS for authentication using certificates and offering automatic key-management with limited operational impact. Coding space for a field indicating presence of a second key has been reserved in all PDUs to be encrypted. Adding these or similar features remains
out of scope of this document, however.
------ for information: reserved1a is the name of the field reserving coding space to indicate presence of a second key for some future extension -------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| authMode | keyId | reserved1a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Regards,
Ruediger
Von: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
Gesendet: Mittwoch, 14. Mai 2025 17:27
An: Geib, Rüdiger <Ruediger.Geib@xxxxxxxxxx>; tsv-art@xxxxxxxx
Cc: draft-ietf-ippm-capacity-protocol.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx
Betreff: Re: Tsvart ietf last call review of draft-ietf-ippm-capacity-protocol-14
Hi Ruediger,
Sorry for the delay in responding.
The new draft version addresses most of my issues. In regards to the firewall and NATs aspects and the Null Request. I think you have an issue if there is a NAT/FW on the client side, but if that
is assumed to not exist then I see it working as currently specified.
I think my main issue remaining issue is with the key-reuse for both encryption and authentication of the message. I think it is crucial that this is addressed. There exists also a directionality
issue that I missed in my initial review. These issues is crucial to address.
I removed all parts that I am fine with, and left below where I had something to add.
/Magnus
Hi Magnus,
thanks for your review. Please find the comments of Len and me marked [Authors] in line below.
Regards,
Ruediger
-----Ursprüngliche Nachricht-----
Von: Magnus Westerlund via Datatracker <noreply@xxxxxxxx>
Gesendet: Mittwoch, 23. April 2025 16:36
------------------------
Section 4.2.2 Assumes that authUnixTime will be unique for all status messages.
Replay protection? Appear to give a large window in time (10seconds) where all will be processed. I will note that by not having any type of sequence numbers that allow replay protection on an attacker has the possibility to attempt forgeries during a significantly
long window making the attack easier. Also to my understanding even a later duplication will be processed, thus not preventing late messages to trigger a response that the attacker can observe when forgery is successful.
[Authors]: There is no expectation that authUnixTime is unique, just that it is within the time window. This was considered a reasonable restriction without requiring the complexity of maintaining state information for potentially a large number of test requests.
MW: Thanks, okay I understand the thinking better with that comment. From my perspective this appears to ok. The setup makes it easier to construct a packet for a
forgery attempt than in many other protocols that has a tighter replay window. However, I think the HMAC-SHA256 is such a strong algorithm that performing a successful forgery is extremely hard. From that perspective the pre-shared key-management is a much
bigger risk.
----------------------------
Section 4.3: Automatic Key-management. What is the motivation for not providing an automatic mechanism? Lets looks at the arguments in RFC 4107.
https://eur02.safelinks.protection.outlook.com/?url="">
To me this usage appear more towards the MUST use automatic key-management side of the BCP. A fairly large number of keys if one expect to have different test clients for all network endpoints in an access network. Secondly, no short term keys are derived.
Although the IV for is full length it will have a limited life time. ANSSI recommendation for AES-CBC says 2^59 blocks as the limit to rekey. Tracking that could become a problem in actual deployment.
A sketch for an automatic key-managemenet for this protocol. The initial control and setup phase could be performed over DTLS, then perform an key export to use for the integrity of the status messages and activation control on the data plane. That would mean
possibility for public cert for the test server, and if one anyway was ready to give clients a secret key, why not a cert to do mutual authenticated DTLS if client auth is needed to prevent misuse of test server.
I would also note that the key-length required is dependent on cipher and that you have two different mechanisms.
[Authors]: This would seem to add enormous complexity. The protocol is designed for testing with synthetic or unsubstantial data, i.e. the information being protected has low value. The information is in timeliness of feedback or more generally, performance
of the packet exchange.
MW:
I think you should consider to remove the encryption mode then. To my understanding it represents a significant weakness in the current scheme of using pre-shared
key. The issues I see are:
-
Using the same key both for encryption and the authentication. These should be two different keys, for example by using a key-derivation function from the master secret. Because currently the encryption key uses the
first 128-bits of the key. If one crack that key one will have the first part of the authentication key. There might also be additional interactions that might simplify cracking the shared secret due to key reuse.
-
For encryption you have an invocation limit that is significantly lower than what HMAC-SHA256 will provide and this protocol has no built in support prevent overuse and fatiguing the key.
-
There are no per direction keys, the same key appear to be used in both directions. This do allow for reflection attacks where an on-path attacker can send back the same messages the server sent to the server, so
they appear to come from the client and vice versa. At a minimal this enables a denial of service attack.
I do think using DTLS for authentication using certificate and for automatic key-management avoids this protocol implementing poor security with known weakness for
in practice minimal operational impact. The pre-shared key-file becomes a certificate. The ones running the test server still needs to provide the client with a method of proving their right to use the server when using authenticated mode.
So even if staying on no automatic key-management I think there is a serious issue here with the key-reuse. That must be addressed. Either to clarify that one needs
to have two different shared keys that MUST be different and independently generated or specify a key derivation from the shared master secret into an encryption and a authentication key.
