Subject: [Isms] ISMS/SSH implementation report

From: Wes Hardaker <[email-masked]>
Date: Thu, 15 Sep 2005 23:48:22 -0700

Now that I've caught your attention, I'm going to state more clearly I
had a few hours to kill a few nights (hah) and wondered how quickly I
could do a "hack" to get something working.  My biggest question was,
given the Net-SNMP stack, how much of a pain it was going to be to
implement a tunneled protocol given the current signaling between
different sections of the code.  Specifically, I was most curious
about how passing information from the transport layer all the way to
the security layer was going to work out if I didn't want to modify
the API sets at all.

More importantly: this was a hack.  It was a huge hack.  It is not
efficient nor is it implemented in a way that would be a reasonable
way to do things in the long run.  Details below.  Have I mentioned
this was a hack?  Please don't slam the experiment below as being
secure, robust, etc.  It was a just an experiment.  But I thought I'd
at least report it.

The results were that the total time I spent was about 4 and a half
hours (4.42).  Which isn't much time.  (a bit more reading of code was
involved beyond that time accumulation).

Stack Modification Details:
--------------------------------------------------

The hardest part about doing this wasn't the majority of the straight
forward hack described below.  The hardest part was making the
transport (dispatcher in SNMPv3 speak) pass data to the local security
model about the fact that the packet had arrived over a "trusted"
mechanism (more below).  I was most paranoid about having to modify
APIs in order to pass that information around.  Fortunately it only
required modification of a structure and of the internals of a
function.  This was due to a large redesign that happened during the
creation of the kerberos security model, however, where the API was
left flexible through the passing of parameter structures rather than
a fixed API (IE, the ASI data was passed through a structure instead). 

Hack details:
--------------------------------------------------

Net-SNMP is very flexible with transports it can make use of.  Because
of this, adding a new one was fairly trivial.  Adding SSH, however,
was not going to be trivial because the lack of public libraries that
would allow the easy addition of SSH code directly into Net-SNMP.  So,
I did the next worst thing: I added support for input and output to
and from either stdin/stdout or from a application.  This would easily
allow for SNMP messages to be sent over just about anything, including
directly to another application.  The strangest invocation would
be something like the following (I'm using this as an example because
it gets more complex when we start involving ssh):

  % snmpget -t 5 'std:snmpd -f -Le -r std:' sysContact.0
  SNMPv2-MIB::sysContact.0 = STRING: hardaker@

The above executes a GET PDU piped to the special designation name
beginning with std: in single quotes, which in this case is the direct
invocation of the agent who in turn was passed a port to open of
'std:' which is the magical invocation of stdin/out.  IE, a pipe is
opened by the snmpget application to and from the snmpd application.
snmpd is invoked with the std: token to indicate it should open a
channel from stdin, and respond back on stdout.  snmpget, on the other
hand, speaks to and from the pipe to the opened snmpd application.  A
large timeout (5 seconds) was needed to ensure the agent would start
up within that time period.

It is important to note that this is still sending SNMPv3/USM between
the apps.  To assume that the local user was the securityName to be
used for the transaction, a "local" security model had to be
developed.  Which I also implemented where the internals did no
checking of the packet and merely took the security name from the
local process information.  (and then, of course, that user name with
that security model would have to be added to the VACM which was also
done in the configuration of the agent).  So, by doing this I'd no
longer be tunneling USM and it's security but would rather be
tunneling v3 with a 'local' security model.  FYI, the local security
model does no packet checking and has an empty security parameters
field and forces the security level of the PDU to be flagged as
noAuthNoPriv since it doesn't know the detail of the transport.
Putting real ssh in place directly as a transport would fix this as
the code really would know what the level was.  If this code was left
around in the future, I'd modify it to include an optional default
context engineID probe.  Finally, the code checks to make sure that
the packet came in over a non-network transport (currently only the
std: transport of some form).  Not doing this would let UDP packets to
trigger the local SM into thinking that the user name to pass to VACM
was the user the agent was running at without any sort of authentication.

  %snmpget -u hardaker --defSecurityModel=localsm -t 5 'std:snmpd -f -Le -r std:' sysContact.0
  SNMPv2-MIB::sysContact.0 = STRING: hardaker@

  (in the config file was: "rouser -s localsm hardaker noauth")

So, the next was to link these two stages through ssh.  To do this,
the sshd configuration was modified to call snmpd when the isms
subsystem was invoked:

  Subsystem       isms    /bin/ismssnmpd

and that program merely launched:

  snmpd -f -Le -r std: 2> /tmp/sshd.snmp.log 

Finally, snmpget could then invoke ssh to connect to the remote agent
under the isms subsystem (everything was done connect to the localhost):

  % snmpget -u hardaker --defSecurityModel=localsm -t 5 'std:ssh -s localhost isms' sysContact.0
  SNMPv2-MIB::sysContact.0 = STRING: hardaker@

Whew.  And it worked (ok, not the first time of course).  The ssh
client logged me into the local server using my public/private key
pair and executed the agent (as me) to pass the SNMP PDUs to.

I'll be impressed if anyone understands the above given the attempt at
a brief description of something fairly complex...

Reminder: this was a hack test.

-- 
Wes Hardaker
Sparta, Inc.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Sep 2005 09:24:49 +0200

Wes,

Nice work.  Please see below.

> would allow the easy addition of SSH code directly into Net-SNMP. 

Yah, I've noticed the sorry state of affairs of OpenSSH's libraries as well.

> So,
> and from either stdin/stdout or from a application.  

WHAT A KLUDGE!  WHAT A HACK!  HOW COULD YOU?!

just kidding ;-)

Actually it demonstrates something else... see below.

> [...]

>   snmpd -f -Le -r std: 2> /tmp/sshd.snmp.log 

So, to implement CH functionality, all one would need to do in your hack
would be on one end to do the the following:

agent% ssh -p {ISMS-port} -s isms-turn user@manager snmpd -f -Le -r std:
2> /tmp/isms-turn.log

and on the other end...

Subsystem	issms	/bin/isms-turn

Where...

isms-turn pipes, forks (in the simple similarly ugly way), and execs
something along the following lines:

exec("/usr/bin/snmpget", "--defSecurityModel=localsm", "std:???",...)

Not quite sure of ???...

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Sep 2005 09:31:20 +0200

> would allow the easy addition of SSH code directly into Net-SNMP.

There is an LGPLed implementation called libssh which offers an API.

<http://0xbadc0de.be/wiki/doku.php?id=libssh:libssh>

Unfortunately, this seems to be client side only at the moment...

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 16 Sep 2005 06:44:26 -0700

>>>>> On Fri, 16 Sep 2005 09:24:49 +0200, Eliot Lear <[email-masked]> said:

Eliot> So, to implement CH functionality, all one would need to do in your hack
Eliot> would be on one end to do the the following:

Yeah, I almost tried to include that within the report too but in the
end it didn't quite work.  It'll take a bit more modification.
However, fundamentally you're right that it should work about the same
way.  The agent, of course, has to have credentials and this is where
currently this isn't deployed as most credentials out there are for
the agent side and are not user based which is what is ideally needed
for sending notifications.  (this is one of the points that David
P. has been trying to state I believe).  Technically there is no
reason you couldn't use the host key as a user key when sending a
notification, but it's not necessarily something you'd want to do.

-- 
Wes Hardaker
Sparta, Inc.