Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

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



"Holland, Jake" <[e-mail]> wrote:
> (+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" <[e-mail]> 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" <[e-mail]> 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" <[e-mail]>
>     To: "Rob Wilton (rwilton)" <[e-mail]>
>     Cc: "Russ Housley" <[e-mail]>; <[e-mail]>; "Sean
>     Turner" <[e-mail]>; "Rifaat Shekh-Yusef" <[e-mail]>
>     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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>     > Fax:   [phone]         <https://www.jacobs-university.de/>
>     >
>     > _______________________________________________
>     > netconf mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/netconf
>     
>     _______________________________________________
>     netconf mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/netconf
>     
> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf