Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

I basically agree with what Martin is saying.

Either one YANG module containing all of the crypto identities, or a few YANG modules as previously suggested.

If advertising the specific identities is important, then a per identity if-feature could be used, although I'm not entirely sure that one feature per identity is really a great option either, but I think that this would be better than one per module.

Or, we could do an augmentation to YANG library with a leaf-list of the crypto identities that are supported by the server.  This is sort of equivalent to a feature per identity solution without polluting the feature list with lots of features.  Something along these lines could even be extended if it is likely that a given identity might only be supported by some of the protocols.  E.g. a separate list for NETCONF supported crypto identities vs RESTCONF supported crypto identities, etc.

But I also think that this is just another instance of the generic capabilities issue, and really it would be good to a have a solution where the capabilities are available offline as well as from the device.

Thanks,
Rob


> -----Original Message-----
> From: Martin Bjorklund <[e-mail]>
> Sent: 27 September 2019 16:09
> To: [e-mail]
> Cc: Rob Wilton (rwilton) <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [netconf] crypto-types fallback strategy
> 
> Hi,
> 
> Kent Watsen <[e-mail]> wrote:
> > [cc-ing my co-authors, as they're beginning to convert crypto-types
> > back to identities again]
> >
> >
> > Rob et. al.,
> >
> > > 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...
> > >
> > > Okay, we'll keep just the one YANG module.
> > > [RW]
> > > Do you mean one module for all the identities of just the base
> > > identities?
> > >
> >
> > Dunno.
> >
> > Identities provide the desirable benefit of hierarchy and
> > extensibility, but they come with the weight of the module needing to
> > be implemented (not just imported) in order for the identity to be
> > defined.  This is how YANG works; it would've been better if, e.g.,
> > identities could be defined by "implemented" via YANG-library...
> 
> Yes, but it only matters if the server implements some data node of type
> identityref with the base that these identities are derived from.
> 
> While I agree that it would be good to find a solution to the "advertise
> identities supported"-problem, I don't think it is importang enough for us
> to find some clever little workaround...
> 
> So I think a single module wih the identities will work.  Or perhaps one
> for tls and one for ssh.
> 
> > The thing with crypto algorithms, the algorithms a server supports is
> > a matter of importance, e.g., because the algorithm isn't approved for
> > use on the network.  The ability to configure algorithms supported is
> > not currently present in the ssh-client-server and tls-client-server
> > drafts, as I was hoping it could be added later as a -bis extension or
> > an update, but perhaps it should be, in order to drive this problem,
> > to ensure a proper crypto-types solution.
> >
> > Working within the current YANG construct, one possible solution would
> > be to define every algorithm identity in its own module, thus enabling
> > servers maximum flexibility to describe which are supported.  The
> > ostensible negative is that doing so would produce many modules.
> > While not a computer problem, it could become onerous.
> >
> > Another idea is to not use identities either (in addition to
> > enumerations), but instead define a data model that preserves the
> > extensibility of identities without needing to implement modules.  For
> > instance, instead of assuming the "algorithm" field is an
> > 'identityref', perhaps a "leafref" is used.
> >
> >
> > ietf-crypto-types.yang snippet:
> >
> > 	// protocol accesible nodes  (note: config false)
> > 	list algorithms {
> > 	  config false;
> > 	  key name;
> > 	  leaf name {
> > 	    type string;
> > 	    description "The name of a collection of algorithms.  Suitable
> > 	    values are defined in the TBD IANA registry...";
> > 	  }
> > 	  list algorithm {
> > 	    key name;
> > 	    leaf name {
> > 	      type string;
> > 	      description "The name of an algorithm.  Suitable values are
> > 	      defined in the TBD IANA registry...";
> > 	    }
> > 	  }
> > 	}
> >
> > 	grouping public-key {
> >           leaf algorithm-type {
> > 	    type leafref {
> > 	      path "/ct:algorithms/ct:name";
> > 	      require-instance false;
> > 	    }
> > 	    must '../algorithm';
> >           }
> > 	  leaf algorithm {
> > 	      type leafref {
> > 	        path "/ct:algorithms[ct:name =
> > 	        current()/../algorithm-type]/ct:algorithm/ct:name";
> > 	        require-instance false;
> > 	      }
> > 	    must '../algorithm-type';
> > 	  }
> > 	}
> >
> >
> > PROs:
> >   - allows a server to advertise (in <operational>) which algorithms it
> >     supports without any need to implement a module, other than
> >     crypto-types.
> >   - supports extensibility via IANA registries.  Sequence: RFC updates
> >     registry --> server supports --> client configures to use.
> >   - "require-instance false" enables YANG-based config validations to
> >     succeed w/o presence config false data.
> >
> > CONs:
> >   - only one level of hierarchy (would more every be needed?)
> >   - "require-instance false" enables YANG-based config validations to
> >     succeed even when misconfigured (though commit should fail).
> 
> The last CON here is essentially the same as you get with identities.
> I think we should stick to identities, and describe that it is ok for a
> server to reject config for an identity representing an algorithm that the
> server doesn't implement (even though it "supports"
> (understands) the identity itself).
> 
> 
> /martin