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" <[email protected]> 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" <[email protected]> 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 protected]> 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 protected]>
> To: "Rob Wilton (rwilton)" <[email protected]>
> Cc: "Russ Housley" <[email protected]>; <[email protected]>; "Sean
> Turner" <[email protected]>; "Rifaat Shekh-Yusef" <[email protected]>
> 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 protected]
> > https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> netconf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netconf
>
>
>
> _______________________________________________
> netconf mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
