IETF-SSH archive

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

Re: SSH operations modelled in YANG



>>>>> "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.

--Sam



Home | Main Index | Thread Index | Old Index