Subject: [netconf] FW: liaison from IEEE 802.1 - Keystore draft

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 15 Oct 2021 08:30:13 +0000

Hi Kent, NETCONF,

The attached liaison has been received from IEEE 802.1 with some comments regarding the YANG Keystore draft.

Would you please be able to review this liaison and see if there are changes to the keystore draft that we should make based on these comments.

I think that we should probably be thinking of sending a liaison response, once the WG has decided on what course of action is needed.

If you have further questions, or think that more discussion would be useful, then before sending a formal liaison response, I can check whether another choice might be to have a more informal discussion between the authors during an IEEE Yangsters call (which happens most weeks), or if that turns out to not be the right forum then on one of the IETF/IEEE coordination calls (approx. every 4 months).

Regards,
Rob

From: iesg <[email-masked]> On Behalf Of Lars Eggert
Sent: 15 October 2021 07:26
To: The IESG <[email-masked]>
Subject: Fwd: liaison from IEEE 802.1

FYI, this was generally addressed to the IETF

Begin forwarded message:

From: Glenn Parsons <[email-masked]<mailto:[email-masked]>>
Subject: liaison from IEEE 802.1
Date: October 15, 2021 at 1:45:47 GMT+3
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Paul Nikolich <[email-masked]<mailto:[email-masked]>> ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, Karen Randall <[email-masked]<mailto:[email-masked]>>, "Jodi Haasz ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Stanley, Dorothy" <[email-masked]<mailto:[email-masked]>>

Please find attached a liaison from IEEE 802.1 to IETF

Cheers,
Glenn.

--
Glenn Parsons
Chair, IEEE 802.1 WG
[email-masked]<mailto:[email-masked]>
+1-514-379-9037

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 Oct 2021 18:25:35 +0000

Hi Rob, all,

> On Oct 15, 2021, at 4:30 AM, Rob Wilton (rwilton) <rwilton=[email-masked]> wrote:
> 
> Hi Kent, NETCONF,
>  

Thanks for bringing this liaison to my attention.  For simplicity, I copy/pasted the contents of the liaison here.  Since I’m unable to rely on normal SMTP indenting for quoted text, my comments are proceeded by “[KENT]” below.

=====START=====
Dear Colleagues,

The IEEE 802.1 Security Task Group reviewed the Internet-Draft A YANG Data Model for a Keystore (https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ ).

In this draft, a number of items are identified as truly optional MAY; it would appear that some of these items would override restrictions in other security standards. For example, in Section 3, Support for Built-in Keys, there is discussion about copying the built-in keys; however this is restricted by IEEE Std 802.1AR. The draft should be clear that where provisions of referenced security standards appear to conflict or restrict the operations described in the draft, those other security standards take precedence.

[KENT] A few comments:

1) The blanket statement described seems excessive as, if it were deemed necessary for this draft, then it seems that it would equally well apply to all IETF drafts.

2) Please note that this draft does not mandate the use of 802.1AR but, rather, consistently refers to "identity certificates” and merely uses 802.1AR as a well-known example.  For example, the draft might say "identity certificate (e.g., an 802.1AR LDevID)”.

3) For the specific Section 3 example mentioned, it would be helpful to know which part of 802.1AR-2018 is contradicted.  That said, my guess is that there is confusion around the word “key” that, in this section refers to the YANG node “asymmetric-key” and not its “*-private-key” descendants, which we’d expect for an IDevID to be “hidden” due to the private key being contained inside a TPM chip.   The need to copy nodes into <running> was discussed in the recent virtual interim on “System-defined Configuration” for how to configure descendant nodes of a system-defined node, with the conclusion that all the ancestor nodes would have to be copied into <running>.  So, in this case, where the client desires to configure a certificate for a built-in asymmetric-key (note: certificate is a descendent node of the asymmetric-key node), which is a YANG “list”, the asymmetric-key node needs to be copied into <running> with at least the list’s YANG-key value.  Case in point, using the example in Section 3, the YANG-key value "Manufacturer-Generated Hidden Key” is copied into <running>.  [PS: the example shows other non-essential descendent nodes being copied into running (e.g., "public-key-format”, "public-key”, etc.).  This was discussed on the netconf list where some said it was necessary.  This was before the “system-defined configuration” draft was introduced.  Now it seems that, if we go with <running> being laid on top of <system> to create <intended>, then the non-essential nodes can now be removed.  Intrinsic to this comment is that server-side validation occurs on <intended>, not <running>]

4) The first sentence says "a number of items…”, it would be good to get a complete list so that we can address all the issues.

[continuing with quoted liaison text]

The certificate encoding specified does not appear to use any standard encoding (e.g., DER/BER). It also might be useful to reference a standard key wrap or specifier for a standard key wrap algorithm for transporting both symmetric and asymmetric keys.

[KENT] The YANG says that the certificate is defined by the "ct:asymmetric-key-pair-with-certs-grouping”.  The “ct” prefix points to draft-ietf-netconf-crypto-types, where that grouping says it uses the "end-entity-cert-grouping” grouping, which say it uses type "end-entity-cert-cms”, which is derived from type "signed-data-cms”, which is derived from type “cms”, which is a binary type with description:

      "A ContentInfo structure, as specified in RFC 5652,
       encoded using ASN.1 distinguished encoding rules (DER),
       as specified in ITU-T X.690.";

[continuing with quoted liaison text]

There is an updated standard IEEE Std 802.1AR, Secure Device Identity, which is IEEE Std 802.1AR- 2018. And there are extraneous letters (i.e., Group, W. -. H. L. L. P. W.) in the reference for [Std- 802.1AR-2009] which should be removed.

[KENT] Fixed in my local copy.  BTW, https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ieee/ <https://xml2rfc.tools.ietf.org/public/rfc/bibxml-ieee/> does not have an entry for 801.1AR-2018.

Thank you for your consideration of these matters, and we welcome continued collaboration going forward.

[KENT] Always happy to improve specs where possible!  :)

Respectfully submitted,
Glenn Parsons
Chair, IEEE 802.1 Working Group
=====STOP=====

Please advise with regards to next steps.

Kent

> Regards,
> Rob
>  
>  
> From: iesg <[email-masked] <mailto:[email-masked]>> On Behalf Of Lars Eggert
> To: The IESG <[email-masked] <mailto:[email-masked]>>
> From: Glenn Parsons <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "Paul Nikolich <[email-masked] <mailto:[email-masked]>> ([email-masked] <mailto:[email-masked]>)" <[email-masked] <mailto:[email-masked]>>, Karen Randall <[email-masked] <mailto:[email-masked]>>, "Jodi Haasz ([email-masked] <mailto:[email-masked]>)" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Stanley, Dorothy" <[email-masked] <mailto:[email-masked]>>
>  
> [email-masked] <mailto:[email-masked]>
> +1-514-379-9037
>  
> <liaison-ietf-YANGkeystore-0921-v02.pdf>_______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>