Re: SSH operations modelled in YANG

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

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

Well, those are interesting-looking. They seem to be confused about what the possible keyex methods are and how their names are constructed. I see a number of names formed by appending a dotted representation of the GSS mechanism OID to the method family name from RFC4462 or RFC8732. Others seem to use names that the author has made up by combining a method family name with substrings of other method family names (e.g. "gss-curve25519-sha256-nistp384", which is nonsensical -- "curve25519" and "nistp384" both identify sets of elliptic curve domain parameters).

The actual form used by SSH on the wire consists of the family name from RFC4462 or RFC8732, concatenated with a base64-encoded MD5 hash of the DER-encoded mechanism OID. I think it would be feasible to represent as YANG identities the set of registered family names which can be used to construct keyex method names this way. Actually doing anything with that information would require _also_ having a list of available GSSAPI mechanisms, which depends on which mechanisms are installed/implemented/configured on the server.

Jeff

Thank you for that.  Looking at RFC4462 et al. I see what you mean.

I did try another tack to see what options manufacturers offer for configuration  of key exchange thinking that the values in the I-D might have come from manufacturer documentation  but did not find any with GSS, only such as 
ecdh-sha2-nistp521 
ecdh-sha2-nistp384
which I see as straightforward when it comes to a YANG identity (identity do not have wild cards).

I started by doubting whether IANA could create GSS identity as and when a new GSS method came along and am still doubtful!  I do not think I know enough to offer a way forward and so am inclined to wait and see what emerges from the AD Review.  Given the large number of large I-D that have been requested for publication by the Netconf WG in December that could be some time.  I will also keep an eye on the IANA Review and if they say 'IANA OK' I will query that. Meanwhile I will look again at GSS so I can get the terminology and structure right.

Tom Petch

Tom Petch
On Thu, Jan 26, 2023 at 12:25 PM 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 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><mailto:ietfc%btconnect.com@localhost<mailto:ietfc%btconnect.com@localhost>>> wrote:
From: Jeffrey Hutzelman <jhutz%cmu.edu@localhost<mailto:jhutz%cmu.edu@localhost><mailto: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