| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I’ll join the party. More comments in line, mine tagged [SG] and in green.
Steve Goeringer CableLabs® From: "stds-1904-4-tf@xxxxxxxxxxxxxxxxx" <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx> Thank you, Marek. You bring many good points that provide more food for thought. Please see below. From: Marek Hajduczenia <mxhaj79@xxxxxxxxx>
Hi Glen, Some thoughts / feedback
[GK] I don’t have a strong argument for continued support of 128-bit key. I thought that it was possible that instead of generating keys in the
OLT itself, operators will use some external security server. And that external infrastructure may or may not support 256-bit keys in various head ends. Maybe this is not the case. Just want to observe two things:
Does anyone have any concerns with not supporting AES-128? [SG] From a risk management perspective, AES 128 is considered sufficiently secure by most authorities at the moment. A lot of SDOs are moving to AES
256, but I think that’s just because they can. It’s my understanding that there is delay added by using 256 relative to 128. However, its small and implementation differences in hardware or software probably matter more than the added number of rounds that
AES 256 requires (AES 128 is 10; AES 256 is 14). However, for my part, I tend to want to trust the silicon manufacturers here because implementation matters.
[SG] That said, if we think 256 is more secure, supporting 128 provides a down grade attack path. I so no benefit to requiring 128 if 256 is mandatory
and the performance penalty is minimal.
[SG] This makes sense; however, it does provide a downgrade attack path through the configuration or management of the ONU. This is mitigated by using
secure channels to configure and manage the ONU. Note that the attack against ViaSat’s KA-SAT network last spring was enabled in part by a management network vulnerability after the adversaries had compromised the management network via a compromised VPN.
[GK] To use zero-overhead encryption, the ONU must first receive the full 48-bit extended MPCP clock from the OLT. Without this value, encryption
cannot operate, so it cannot be enabled by default. Correspondingly, the OAMPDU that delivers the extended MPCP clock to the ONU signifies to the ONU that the NMS/OLT wants it to use encryption. I called this OAMPDU “Encryption Configuration”. It has only
two fields: enable/disable flag and 48-bit MPCP clock. I think there must be a certain script or a sequence of configuration operations that is executed to configure new ONU before it can perform its duties. Rules, Queues, LLIDs, VLAN tags – all need to be
provisioned. Enabling the encryption should be set as the first step in this process. [SG] An explicit enable/disable message again provides for a downgrade attack. The message should occur after authentication and the message should be
integrity protected (HMAC/CMAC). AND, its by definition got to occur before encryption starts, or an unencrypted message, so if an adversary has found a way to do packet injection, preventing the downgrade relies entirely on authentication and integrity.
[GK] Yes, the broadcast traffic is never encrypted because every ONU must receive it. But this question asked a different thing. Just looking at
the problem from the ONU perspective. When ONU receives an envelope header, it checks if it has one of ONU’s assigned LLIDs. If not, the envelope is ignored. If it is, then ONU checks the encryption enable flag. If encryption is enabled, the ONU checks the
Key index and determines what key it should use to decrypt the envelope payload. But what should ONU do if the encryption flag is set to disabled? This could be a broadcast LLID or any LLID assigned to this ONU. This envelope arrived unencrypted. The ONU has
to make a decision. It can drop this envelope, or it can process it without applying the decryption.
I don’t think discarding such unencrypted envelope is the right approach. For example, it could be a multicast OAMPDU instructing ONUs to switch
to protection path. If OLT took the trouble of sending it, ONU should not unilaterally decide that it was not important.
Now, the follow-up question. When OLT switches from key 0 to key 1 and indicates this in the downstream envelope header, the ONU uses this indication
to also switch the encryption from key 0 to key 1 in the upstream direction. Shouldn’t ONU similarly follow the OLT’s lead, if for a given LLID, the OLT changed the encryption enabled flag to encryption disabled? ONU can follow this lead and disable the encryption
for the same LLID in the upstream direction (if it was bidirectional LLID). Alternatively, the ONU can ignore the flag it received from the OLT and continue encrypting this LLID in the upstream. To me, ONU always following the OLT lead seems like a more robust
solution. [SG] I’m pretty biased towards every frame/packet needs to be part of a secure channel (e.g., authenticated, authorized, confidential). But, then, that’s
my job and I can compromise.
[SG] As soon as possible, yes; but it would be nice if it occurred before configuration. Regards Marek On 3/7/23 15:22, Glen Kramer wrote:
To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 |