Re: [babel] Babel DTLS and YANG

Mahesh Jethanandani <mjethanandani@gmail.com> Fri, 06 August 2021 00:07 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A833A1278 for <babel@ietfa.amsl.com>; Thu, 5 Aug 2021 17:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0v0XSGHXC73 for <babel@ietfa.amsl.com>; Thu, 5 Aug 2021 17:07:27 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7043A1275 for <babel@ietf.org>; Thu, 5 Aug 2021 17:07:27 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id mt6so12975822pjb.1 for <babel@ietf.org>; Thu, 05 Aug 2021 17:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BVyUPBKjkN7hdoOE1L2kSM3ZVd9jzwpDAp4ewGRCAEw=; b=VLUeuplk+a1ksfx9p/tFtbxylnvzY/Eyw9jLdD8zRxqtzGIeSIFkeGUGaTLtGoiWR2 wmT+AMlP1GWWVg2R07SgDs4bIe6SR6ohcfNZ9WdjqUda0LSgtBjgCaeSX2l4mo9S/5KT F4YwcjiOmIeuF/9RU6+Lf7q6WVlZN0zFnAIWucowjj6eORkYx/dQVqBR25H3UiaQfDNo wWEAEwvWBkUKTEMRn30/PvanltzylZrUOo9dyklZMFeoIoCSzuUX1aSy2PE7IcjRclYp jytCCQP29IDhpc25WrFe2hR+YxFgvbkrdHo5FP/OFGmXiuBoPYQiiL8S3Y5gZIFWJvtQ IFGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BVyUPBKjkN7hdoOE1L2kSM3ZVd9jzwpDAp4ewGRCAEw=; b=qL2q8wi0mmR8HdF2NbWlU0Cfgzr7m6eV9ijHw27oxcsdBHRO/pv06lw69ORzxJach3 y7z6FahfSkK9alLZoTtG/zFTFMjH3GTylyAnvijt5XVr7LgIq1rd7CqdNwUCTtpJ/3vN I9HUry8mxLrKTeh6bOBjyH54b7IHUyzHJtugPbBZxUPihBXk9VtBc8df2Czs7zS/sR7P ZyuSQQKJ2S+W95TCn6RLqiVTSxOc+0M4osuseLjjRub3+vU+hXv7vdCYzWIWxjF1mKBx HRW7rcND+T/ICLxd6zr1fH8JYdDPblOEsDPjUhBBVMq7LpQGOe+IE7LF9BJ0b4njx5i7 EU4A==
X-Gm-Message-State: AOAM532FeuDmgt4xKfBaUBe94Sk9uyqqg8q/gSEyjU+GfPEgzG2bmR2l DWwa0CR1i1Lr2i97zo2/AaZVugA54zA=
X-Google-Smtp-Source: ABdhPJywda8CCPVXSdyDxo5UMvXcGzJyNRLdpED4sepCNFyVCQb9q5DO7UVWto92mJBe8Ysvboa43g==
X-Received: by 2002:a17:90a:8b95:: with SMTP id z21mr17282506pjn.131.1628208445417; Thu, 05 Aug 2021 17:07:25 -0700 (PDT)
Received: from [192.168.1.133] (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id b190sm4788682pgc.91.2021.08.05.17.07.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 17:07:24 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <828CE2EA-5DED-4E96-B3E3-B4F94D96A4F2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AFE99CC-440C-485F-9120-A526835343FE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Thu, 5 Aug 2021 17:07:23 -0700
In-Reply-To: <DM6PR02MB69240809030DD2B249100282C3F09@DM6PR02MB6924.namprd02.prod.outlook.com>
Cc: "STARK, BARBARA H" <bs7652@att.com>
To: "babel@ietf.org" <babel@ietf.org>
References: <DM6PR02MB69240809030DD2B249100282C3F09@DM6PR02MB6924.namprd02.prod.outlook.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/RfYIAfLfop6qPLBVIY6Zc-qY5OU>
Subject: Re: [babel] Babel DTLS and YANG
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 00:07:32 -0000

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 <bs7652@att.com> 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
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
mjethanandani@gmail.com