Re: SSH operations modelled in YANG

[tom petch <ietfc%btconnect.com@localhost>]

From: Jeffrey Hutzelman <jhutz%cmu.edu@localhost>
Sent: 26 January 2023 13:27

I haven't read the document, but it sounds like the author has just listed the GSS mechanism OIDs they know about as if they were the only ones that existed. That's kind of pointless and possibly harmful. It's all well and good to have a machine-readable form of a registry, as long as it's updated alongside the real registry. But it's inappropriate to assume and claim that an open-ended namespace with no registration process contains only the items the document author happens to know about.

Jeff

The IETF has plenty of prior art going, back to SMI, of modelling a protocol IANA registry in a DDL and maintaining the two in parallel with the protocol registry being subject to all the usual rules about who can update it and how with the DDL version firmly labelled that it cannot be updated except by IANA as a consequence of an update to the protocol registry e.g. YANG registry iana-if-type YANG Module, so that is fine as long as the instructions to IANA are clear.  Here, after reviewing the I-D, I have doubts.

SSH KEX has e.g gss-curve25519-sha256-*
which has been modelled as 
    identity gss-curve25519-sha256-nistp256 {
       base key-exchange-alg-base;
       description
         "GSS-CURVE25519-SHA256-NISTP256 (secp256r1)";
       reference
         "RFC 8732:
            Generic Security Service Application Program Interface
            (GSS-API) Key Exchange with SHA-2";
     }
with other entries for 
     identity gss-curve25519-sha256-nistp384 {
     identity gss-cure25519-sha256-nistp521 {
     identity gss-curve25519-sha256-1.3.132.0.1 {
     identity gss-curve25519-sha256-1.2.840.10045.3.1.1 {
     identity gss-curve25519-sha256-1.3.132.0.33 {
     identity gss-curve25519-sha256-1.3.132.0.26 {
     identity gss-curve25519-sha256-1.3.132.0.27 {
     identity gss-curve25519-sha256-1.3.132.0.16 {
     identity gss-curve25519-sha256-1.3.132.0.36 {
     identity gss-curve25519-sha256-1.3.132.0.37 {
     identity gss-curve25519-sha256-1.3.132.0.38 {
with entries as well for 
     identity gss-curve25519-sha256-curve25519-sha256 {
     identity gss-curve25519-sha256-curve448-sha512 {
 I am sure that the author has done his homework and has consulted those with familiarity of this area (unlike me who has never understood GSSAP!) .  I did follow up the references e.g.8732 and concluded that IANA would struggle to make the expansion from asterisk to the OID listed above.  

I will flag this at IETF Last Call if IANA themselves do not raise a flag.  There has been a SecDir review by Barry Leiba and the Security ADs on the IESG will of course see it in due course.

YANG identity are perhaps not the best DDL for modelling such as this.  You can create and reference hierarchies but only in a limited way, lacking the sort of expressions you can devise with XPath.  The expectation is that a Protocol model will have a leafref for its KEX which is constrained to be one of the YANG identity that have a  key-exchange-alg-base statement in its definition, which all the SSH KEX in the YANG KEX identity module have but would not match a KEX with an unlisted OID.

HTH

Tom Petch

-- Jeff

On Thu, Jan 26, 2023 at 8:12 AM tom petch <ietfc%btconnect.com@localhost<mailto:ietfc%btconnect.com@localhost>> wrote:
From: Jeffrey Hutzelman <jhutz%cmu.edu@localhost<mailto:jhutz%cmu.edu@localhost>>
Sent: 26 January 2023 12:37

> what should IANA do when SSH registers a new GSS KEX

There's no such thing. GSSAPI mechanisms are identified by OIDs, which are assigned by the owner of the parent arc.  There is no central registry, and certainly not one run by IANA.

SSH can be used with any GSSAPI mechanism that includes the features it needs. No registration is required or possible.

The same problem affects other algorithm and method identifiers, too. All of these namespaces include provision for privately-assigned names, and it's common for algorithms with such names to become widely deployed and even considered best practice without any sort of registration.

Jeff

Thanks for the information;  GSSAPI has always been a blind spot for me.  On the privately-assigned names, yes, those I am familiar with and so is the author of this I-D and he explicitly caters for that in the instructions to IANA for the maintenance of the modules (but does not say anything about the OID, just includes 13 of them in the initial version of the YANG module - ah well, IANA will get to see this and decide what they understand:-(

Tom Petch

-- Jeff