Re: [babel] Babel DTLS and YANG

[Donald Eastlake <[e-mail]>]

Hi Mahesh,

I would agree that a week is a reasonable length of time for people to
complain if they object to these changes.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Aug 5, 2021 at 8:07 PM Mahesh Jethanandani
<[e-mail]> wrote:
>
> Hi Babel WG,
>
> We, the authors, have not heard from the WG on this thread, so here are a list of suggested changes we are proposing to address the comments received as part of IESG review. Since the changes are substantial, we need to make sure that the WG is ok with these changes.
>
> The first is address the question Barbara raises below. We would like to introduce a new leaf called ‘algorithm’ which is a identity reference to one of the ‘private-key-formats’ defined in ietf-crypto-types module, that will identify the type of algorithm used to encode the private key. That module identifies three algorithms, RSA, EC, and One Asymmetric. The change will look something like this:
>
> +
> +          leaf algorithm {
> +            nacm:default-deny-write;
> +            type identityref {
> +              base ct:private-key-format;
> +            }
> +            mandatory true;
> +            description
> +              "Identifies the algorithm identity with which the
> +               private-key has been encoded. This value can only be
> +               provided when this instance is created, and is not
> +               subsequently writable.";
> +          }
>
> The second, and this is where the bad news comes in, is that the ietf-crypto-types module is part of draft-ietf-netconf-crypto-types. Yes, it is a draft, though in LC, so most likely this draft will end up in MISSREF queue.
>
> The third, and this was my an oversight on my part, are lines which I have introduced new as part of the model to protect any data that we do not want either read or subsequently written; or read at all. In particular, the private key within a cert are now protected by something called ‘default-deny-all’, which per RFC 8341 defines it as:
>
>          "Used to indicate that the data model node
>           controls a very sensitive security system parameter.
>
>           If present, the NETCONF server will only allow the designated
>           'recovery session' to have read, write, or execute access to
>           the node.  An explicit access control rule is required for all
>           other users.
>
>
> Similarly, nodes that were identified as “This value can only be provided when this instance is created, and is not subsequently writeable” in the Babel Information Model, are now protected by the flag ‘default-deny-write’ from RFC 8341, which describes the flag as:
>
>          "Used to indicate that the data model node
>           represents a sensitive security system parameter.
>
>           If present, the NETCONF server will only allow the designated
>           'recovery session' to have write access to the node.  An
>           explicit access control rule is required for all other users.
>
>
> If you have objections to these changes, please raise it now. Otherwise, silence will be considered consensus 🤐. Donald, would you say a week is plenty of time to raise any objection?
>
> Cheers.
>
> On Aug 3, 2021, at 8:11 AM, STARK, BARBARA H <[e-mail]> wrote:
>
> Hi Babelers,
> We're getting some comments on the YANG model that we need a little help with.
> Specifically, we need help with the modeling of the DTLS private key.
> For DTLS, we've included data model support for X.509 certificates and Raw Public Key.
> The certificate type (X.509 or Raw Public Key) is specified for every certificate.
> Both have distinct public and private keys.
> Public keys are provided via the data model in PEM format.
> The public key PEM file includes info about the cipher suite that was used to create the pair (RSA, Elliptic Curve, etc.) and therefore needs to be negotiated in DTLS handshaking.
>
> But for the private key, we had come to a consensus that the Babel implementation just wanted the binary private key value.
>
> If the private key were expressed in PKCS#8 (generic key format) PEM, we would have:
> -----BEGIN PRIVATE KEY-----
> BASE64 ENCODED DATA
> -----END PRIVATE KEY-----
>
> Within the base64 encoded data the following DER structure is present:
> -------------------------------------
> PrivateKeyInfo ::= SEQUENCE {
>  version         Version,
>  algorithm       AlgorithmIdentifier,
>  PrivateKey      OCTET STRING
> }
>
> AlgorithmIdentifier ::= SEQUENCE {
>  algorithm       OBJECT IDENTIFIER,
>  parameters      ANY DEFINED BY algorithm OPTIONAL
> }
> ---------------------------------------
>
> AlgorthmIdentifier identifies the cipher suite.
> But it sounds like the binary private key value Babel is providing is just the "PrivateKey" part of this.
> Is that correct? If so, doesn't the implementation need to know the "AlgorithmIdentifier"? Or (since we supply the public key with the private key) can or does the Babel implementation pick this up from the associated public key?
>
> Thx,
> Barbara
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel