Subject: Re: [Taps] [netconf] crypto-types fallback strategy

From: "Holland, Jake" <[email-masked]>
Date: Tue, 24 Sep 2019 20:38:31 +0000

(+taps)
Hi,

Thanks for taking a look at that model, Tom.  I'll give just a
little background:

The current taps-api structure was driven basically by an attempt to
support the examples given in the taps-interface draft, for instance
in section 5.3.1:
https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.1

I didn't do much (or any? don't recall...) of a search for crypto
models before throwing together the early ietf-taps-api.yang drafts,
including the security config stuff.  I mostly worked off the API
examples, with intent to look for a more serious answer later as
we try to integrate the secure connection support into a reference
implementation or 2.

What's there now hasn't been through any kind of security review, and
I'd characterize it as a placeholder, at the moment.  (The taps use of
yang is still relatively immature.)

I'd be very grateful for a grouping or object of some kind that I
could pull in by import from another module, and would support
using it in taps-api-yang if we can use it to do what we need (which
is to configure connection endpoints to allow secured connections,
for either client or server endpoints).  I think that would make for
a very helpful improvement.

Part of the point of using yang in taps was to be able to better exploit
yang work from other wgs, and this would be an excellent opportunity to
put that into practice, I think.  So I would be very delighted to import
a model that does this right.

Best,
Jake

On 2019-09-24, 13:02, "Salz, Rich" <[email-masked]> wrote:

Jake,

As the author of the draft referenced below, do you care to comment?

The crypto-types document in the netconf WG is undergoing some pretty drastic surgery.

On 9/24/19, 4:50 AM, "tom petch" <[email-masked]> wrote:

    Going back a bit, since this is a more generic comment, I get a
    different, simpler perspective in
    draft-jholland-taps-api-yang
    which has me wondering just how complicated this needs to be for it to
    be useful in other WGs.
    
    The I-D defines
      identity security-algorithm {description "Base identity for security
    algorithms."
      identity cipher-suite { base security-algorithm;description "Base
    identity for security cipher suites.";
      identity signature-algorithm {base security-algorithm;
    description "Base identity for security signature algorithms.";
      identity ed25519 {base signature-algorithm;
      identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 {
        base cipher-suite;
    
    and
    
      grouping security-credentials {
        leaf identity { type string;
        leaf trust-ca { type string;
        leaf algorithm { type identityref {base security-algorithm;
        leaf pre-shared-key { type string;
        leaf private-key { type string;
        leaf private-key-callback-handle {type string;
        leaf public-key {type string;
    
    (No SSH but that does not surprise me:-)
    
    Again a more general comment, the IETF often starts simple and adds lots
    later, which sometimes goes wrong because no allowance was made for
    slotting in extras, but an approach which, I think, more often leads to
    successful adoption.
    
    Thus will TAPS consider using
    draft-ietf-netconf-crypto-types
    or will they RYO?
    
    Tom Petch
    
    ----- Original Message -----
    From: <Schönwälder>; "Jürgen" <[email-masked]>
    To: "Rob Wilton (rwilton)" <[email-masked]>
    Cc: "Russ Housley" <[email-masked]>; <[email-masked]>; "Sean
    Turner" <[email-masked]>; "Rifaat Shekh-Yusef" <[email-masked]>
    Sent: Wednesday, September 18, 2019 5:36 PM
    
    > On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote:
    > > >From the gist of the discussion, the punch list appears to be:
    > >
    > > - revert back to using identities, as they were in the -08 revision.
    > > - only define base identities for what's needed immediately for TLS
    and SSH and keystore key-encryption.
    > > - define these base identities in distinct YANG modules
    > > - have each identity's description statement indicate what the
    binary key data is encoded.
    > > [RW]
    > > I think that this matches my view, except for "define these base
    identities in distinct YANG modules".  I don't feel particularly
    strongly about this, but I was thinking that the base identities would
    still be defined in crypto-types.yang, which might help keep the import
    references simple.
    >
    > I tend to agree that sometimes less modules is more. For me, the
    > problem is likely more that I am not entirely sure what the proper
    > base types would be, which may depend on what exactly they are used
    > for. I guess I wait until I see the description text...
    >
    > > A bit separate from the above, but still in mind:
    > >
    > >   - specify that all TLS public-keys are a DER-encoded
    SubjectPublicKeyInfo structure
    > >   - specify that all SSH public-keys are a "ssh-public-key-type"
    type (see below)
    > >   - specify that all encrypted symmetric keys are a DER-encoded
    OneSymmetricKey structure
    > >   - specify that all encrypted asymmetric keys are a DER-encoded
    OneAsymmetricKey structure
    >
    > I would check what is commonly used in existing configuration
    > interfaces. We are not inventing the wheel here. And whatever we
    > define better is usable with existing implementations and tools.
    >
    > > The "ssh-public-key" type would be defined as:
    > >
    > >      typedef ssh-public-key-type {
    > >          type binary;
    > >          mandatory true;
    > >          description
    > >            "The binary public key data for this SSH key, as
    > >             specified by RFC 4253, Section 6.6, i.e.:
    > >
    > >               string    certificate or public key format
    > >                         identifier
    > >               byte[n]   key/certificate data.";
    > >          reference
    > >            "RFC 4253: The Secure Shell (SSH) Transport
    > >                       Layer Protocol";
    > >           }
    >
    > The SSH implementations that I use have the binary key data rendered
    > in ASCII. In fact, the whole key record is rendered in ASCII. I
    > strongly suggest to use formats that are well established.
    >
    > /js
    >
    > --
    > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
    > Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
    >
    > _______________________________________________
    > netconf mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/netconf
    
    _______________________________________________
    netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Sep 2019 08:36:20 +0200 (CEST)

Hi,

Just a quick comment on the usage of YANG in this document.  Since it
doesn't define configuration data to be used over a management
protocol like NETCONF or RESTCONF, you may want to have a look at
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext, which
introduces a YANG extenstion statement to define "structures" (with no
predefined semantics), and replace your:

  container preconnection { ... }

with:

  sx:structure preconnection { ... }

/martin

---

From: tom petch <[email-masked]>
Date: Fri, 27 Sep 2019 11:00:32 +0000

----- Original Message -----
From: "Holland, Jake" <[email-masked]>
To: "Salz, Rich" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 24, 2019 9:38 PM

Jake,

Yes!  Part of the remit of the NETCONF and NETMOD WG  is to produce YANG
modules for general use by other WG and
draft-ietf-netconf-crypto-types
is part of that.  The NETCONF *client-server* modules would be another
example

Crypto has different object classes - hash, MAC, KEX, encrypt,
signature - with plenty of options for most of these.  YANG lacks a
subset feature for saying this is the MTI subset and here are others for
you to consider; unless you divide the space up with base YANG modules
and augmentations thereto, an option which has been discussed on the
NETCONF list and not found favour.

And then you have SSH and TLS which take radically different approaches,
with TLS having ciphersuites and TLS itself changing what it uses with a
change of version.

So is a list of everything possible, in a tree or mesh structure of YANG
identity going to be useful to other WG?

Your I-D caught my eye and seemed to be a different approach based on
this is what most implementations of TLS 1.2 will need, and limiting it
to that; a different approach to
draft-ietf-netconf-crypto-types
which made me wonder if the latter would be of any use to you; and if
not, if anything would.

Tom Petch

> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>