Following on the previous discussion, attached here is a new version of the attribute clauses.
It now describes three attributes:
aInitialKeyCapability (0xDB/0x04-01)
aInitialKeyMethod (0xDB/0x04-02)
aInitialKeySharedElement (0xDB/0x04-03)
The first one is RO attribute to query capabilities.
The second is a RW attribute to set or query the ONU’s current key method. As we often do with such attributes, I added a default value to it. The secp256r1 is currently the most commonly used method, hence I made it the default. Having the default means that if that default is acceptable, the OLT does not need the query the ONU’s capabilities. Also, the secp256r1 or one of the two methods we decided to make mandatory.
The third attribute is to exchange elliptic curve points (or public keys). It is a read-write attribute consisting of one RO sub-attribute and one WO sub-attribute. Set_Request carries the WO value (called sRemote) and Set_Response carries the RO value (called sLocal).
There are two highlighted paragraphs in the document to emphasize special requirements. Please, review them carefully.
The first highlight is calling attention to the fact that the format of sRemote and sLocal depends on the selected key establishment method. If the OLT tries to provision the shared element with an incorrect format, the ONU responds with an error code and does not generate its own shared element (sLocal).
It is generally true for every other attribute that if the OLT uses incorrect TLV format to set it, the ONU rejects the request and replies with an error. But the subtle difference here is that the Request TLV format may be correct, but for a different key establishment method. I thought that warranted this extra explanation.
The second paragraph is to emphasize that only Set_Request and Set_Response are used to carry the attribute values in both directions. Using Get_Request results in an error. We have at least one existing attribute having the same behavior. But if we don’t want this kind of special behavior, then the most plain-vanilla way is to split the third attribute into separate WO attribute for OLT’s shared element and RO attribute for ONU’s shared element. This would take us back to options #1 and #2 in the https://www.ieee1904.org/4/meeting_archive/2023/08/tf4_2308_kramer_4_handshake.pdf. The OLT’s shared element will require an exchange of Set_Request/Set_Response, the ONU’s element will require Get_Request/Get_Response, i.e., two exchanges instead of one. I don’t like it.
Looking forward to your feedback.
Thanks,
Glen
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Tuesday, October 10, 2023 11:22 AM
To: 'Marion, Jc' <jmarion@xxxxxxxxx>; 'Glen Kramer' <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; 'stds-1904-4-tf@xxxxxxxxxxxxxxxxx' <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Subject: RE: [**EXTERNAL**] Update on eOAM attributes for the initial key exchange
Hi JC,
You are exactly right. Options 3 and 4 are exactly the same, because the eOAM spec only defines attributes and associated TLVs. There is no mentioning in the spec of how the OAM clients must group the TLVs into OAMPDUs, except the requirements that the context TLV must precede the associated variable descriptors or variable containers within the same OAMPDU. So, both options 3 and 4 would be equally compliant.
An alternative approach that would nail down the exact OAMPDU format and avoid a TLV size limit is to define a new OAMPDU opcode, as was done for software download OAMPDUs. The Key exchange in 1904.1 and in DPoE also relied on a special OAMPDU opcode that didn’t use any TLVs.
In my mind, using dedicated OAMPDU formats is a less preferred solution, because it requires custom parsing rules. If the key negotiation is possible using our generic TLV parsing rules then we should do it this way, IMO.
Glen
From: Marion, Jc <jmarion@xxxxxxxxx>
Sent: Tuesday, October 10, 2023 10:19 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>; stds-1904-4-tf@xxxxxxxxxxxxxxxxx
Subject: Re: [**EXTERNAL**] Update on eOAM attributes for the initial key exchange
Hi Glen.
Good catch! I agree that using sequence TLV would be cumbersome.
Between option 3 and 4, I would favor 3 because option 4 is a special case of 3 where the set requests are factorized into one OAMPDU. Which is something that can be done with all requests of same type (SET/GET). Assuming the error handling is done properly.
If we present option 3, an implementation using option 4 would be compliant with the spec.
If we present option 4, it can give the impression that the two set requests must be inside same OAMPDU. And an implementation using option 3 could be seen as NOT be compliant with the spec.
Thanks,
Jc
From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> on behalf of Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Monday, October 9, 2023 at 5:56 PM
To: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx>
Subject: [**EXTERNAL**] Update on eOAM attributes for the initial key exchange
Hi All,
I wanted to give you a brief update on the work on defining attributes for the initial key exchange. On 9/15 I shared the aInitialKeyMethod attribute. The attached document contains that attribute again (but with some updates) plus an attribute called aInitialKeyParameters.
These two attributes represent the Option #5 of the key exchange, as we discussed in https://www.ieee1904.org/4/meeting_archive/2023/08/tf4_2308_kramer_4_handshake.pdf.
This option, it turns out, has a complication. One of the elliptic curves requires to exchange points, each of which consists of two 512-bit values. Thus, one such point occupies a maximum TLV size. We cannot pack a point together with a curve ID into one TLV (without complicating the parsing operation by using the sequence TLVs). Thus, it seems we have to switch to options #3 and #4. In other words, the Curve ID and points (public keys) will be in separate attributes and will be carried in different TLVs. These TLVs can be sent in one OAMPDU (option #4) or in separate OAMPDUs (option #3).
Let me know if you have any feedback on this.
Thank you,
Glen
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