IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: SSH operations modelled in YANG



From: Sam Hartman <hartmans-ietf%mit.edu@localhost>
Sent: 25 January 2023 20:31

>>>>> "tom" == tom petch <ietfc%btconnect.com@localhost> writes:
    tom> registries which might be a source of mis-interpretation.  One
    tom> aspect that I could not resolve relates to the GSSAPI entries
    tom> for KEX where the SSH IANA registries end with an asterisk
    tom> which in the YANG Identity in most, but not all cases, have
    tom> been expanded to 13 separate entries with an OID as suffix.  I
    tom> do not know where IANA are expected to get those OID from as
    tom> and when a new KEX entry is created.

That's correctish.  The gss entries are a family of entries.  Basically,
the root of the algorithm registered in IANA explains the ssh part of
what you do.  But to actually exchange keys or authenticate users, you
need to combine that with a specific GSS mechanism.  So you tack on the
OID of a GSS mechanism you plan to use, and then go use that.  You can
use any OID that corresponds to a GSS mechanism you implement; there is
no central registry.  And in fact there are implementations where the
SSH implementation doesn't even know which GSS mechs it supports; it
simply queries the GSS library for mechanisms with suitable attributes
and then uses all those mechanisms.

<tp>
Sam

Thank you for the explanation.  It leaves me with the question of what should IANA do when SSH registers a new GSS KEX, how will they know which OID to add assuming that they follow the pattern of the YANG identity in the initial version of the KEX identity module and replace the asterisk of the SSH IANA registry with OID.  The instructions in the I-D do not seem to mention this AFAICT and I think that they should spell it out.

One more general point.  This I-D like the rest of the set is mostly not usable YANG modules but building blocks for others to use so an expert in ProtocolX, which uses SSH as a transport, is expected to create a module for ProtocolX and import the SSH groupings from this I-D trusting that they incorporate best practice where SSH is concerned.  I do not know of anyone doing this for SSH but they certainly are for the TCP I-D but that I-D has had exposure on the TCPM WG list and so has had wider review.

Tom Petch 

--Sam



Home | Main Index | Thread Index | Old Index