Subject: [Isms] using notifications with SNMP/SSH

From: Wes Hardaker <[email-masked]>
Date: Mon, 17 Jul 2006 19:03:44 -0700

The following is based on the message I sent out in January about
sending notifications over SNMP/SSH and the usable authentication
mechanisms.  It's been edited heavily for improved readability and
usability.  I can probably be coerced into further formalizing the
writing for suitable inclusion into the resulting draft assuming
the description below is sufficient for forward progress.

I'll send the original again for reference right after I ship this one
off.  I won't be able to respond to comments on the following text
until after mid-next week unfortunately.

Note: I have not trolled through all the docs to make sure everything
below is 100% accurate and secure.  Think of it as a white-board
diagram not an end-specification.

1.0 Background

1.1 Terminology

  Politically correct SNMP terms:

    CG = command generator
    CR = command responder
    NG = notification generator
    NR = notification responder

  SSH terms:

    LoF = Leap of Faith

1.2 Basic Notification Configuration

  The SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB already allow for
  configuration of notification receivers destinations to which
  notifications should be sent.  The following examples depict
  possible configuration of this setup using a USM configuration.

  snmpTargetParamsTable row:
      snmpTargetParamsName            toCR       (administrative string)
      snmpTargetParamsMPModel         3          (SNMPv3)
  *   snmpTargetParamsSecurityModel   3          (USM)
  *   snmpTargetParamsSecurityName    usmUser    (The USM user name)
      snmpTargetParamsSecurityLevel   3          (auth|encr)
      snmpTargetParamsStorageType     3          (nonVolatile)
      snmpTargetParamsRowStatus       4          (createAndGo)

  snmpTargetAddrTable row:
      snmpTargetAddrName              toCRAddr        (arbitrary string) 
      snmpTargetAddrTDomain           snmpUDPDomain    
      snmpTargetAddrTAddress          0x0A00000100A2  (CR address, port) 
      snmpTargetAddrTimeout           1500            (in .01 sec) 
      snmpTargetAddrRetryCount        3       
      snmpTargetAddrTagList           toCRTag         
      snmpTargetAddrParams            toCR            (must match prev table) 
      snmpTargetAddrStorageType       3               (nonVolatile) 
      snmpTargetAddrColumnStatus      4               (createAndGo) 

  snmpNotifyTable row:
       snmpNotifyName                 CRNotif         (arbitrary string)
       snmpNotifyTag                  toCRTag         (matches tag list above)
       snmpNotifyType                 2               (inform)
       snmpNotifyStorageType          3               (nonVolatile)
       snmpNotifyColumnStatus         4               (createAndGo)

  The above will configure an agent to act as a NG and send informs to
  the NR at 10.0.0.1 port 162 using the SNMPv3/USM user "usmUser".
  The configuration for the "usmUser" settings in the
  SNMP-USER-BASED-SM-MIB and SNMP-VIEW-BASED-ACM-MIB objects are not
  shown here for brevity.  The columns marked with a "*" are the items
  that are USM specific.

  We'll refer back in later sections about how this changes when using
  SNMP/SSH.

2.0 Notification Generation by a Notification Responder

  Notification Generators (NGs) need to send notifications to management
  stations acting as a Notification Responders (NRs).  There are three
  possibilities for how this might be done depending on the current
  SNMP/SSH sessions available for use and the directionality associated
  with them.

  Section 2.1 describes 2 authentication mechanism procedures for how
  a Notification Generator would open and authenticate a SNMP/SSH
  connection to a Notification Receiver.

  Section 2.2 describes how a Notification Receiver can open a
  connection (or more than one) to the Notification Generator and
  configure it to send notifications over an existing connection.

2.1 A Notification Generator Opening a SNMP/SSH Connection to the
    Notification Responder

    There are a number of interesting issues with how to do the case
    where a Notification Generator needs to open a connection to the
    Notification Receiver.  The hardest issue with this has been 
    authentication mechanism to authenticate the NG at the NR side.
    Additionally, the NR must be authenticated at the NG side and the
    NG must properly check VACM settings to ensure each notification
    sent to the NR is authorized.

2.1.1 Authentication Using a User Credential

    Devices could be configured with user credentials (EG, a user name
    and the user's public-key or password) to use when connecting to a
    NR.  This would make use of the normal user-to-host mode of
    operation of SSH.

    Steps to send the notification:

      1) The NG would open a SNMP/SSH connection to the NR.

      2) The NR would send it's public key and proof of ownership

      3) The NG would verify that it was talking to the expected NR (by
         verifying the public key against the proof and by verifying
         that the public key presented matched the expected public key
         for that destination).

      4) The NG would transmit it's user name and it's own credentials
         (either the a public key, and proof or a password).

      5) The NR would verify the authenticity of the received
         credentials.

      6) The NG would send the notification through the established
         connection.

    The configuration pieces missing that are not currently available
    in any modern MIBs at this time:

      A) Ability to specify the SSH user credential type to use
         (eg, public key or password)
      
      B) the ability to configure that public-key or password

      C) end-destination expected public SSH host-key

         - the public key of the NR the NG should be connecting to.

    This would result in notification destination parameter
    configuration that looked like (the settings explained next):

      snmpTargetParamsTable row:
          snmpTargetParamsName            toCR       (administrative string)
          snmpTargetParamsMPModel         3          (SNMPv3)
      *   snmpTargetParamsSecurityModel   4          (SNMP/SSH mapping)
      *   snmpTargetParamsSecurityName    sshParams  (The SSH parameter name)
          snmpTargetParamsSecurityLevel   3          (auth|encr)
          snmpTargetParamsStorageType     3          (nonVolatile)
          snmpTargetParamsRowStatus       4          (createAndGo)

      snmpTargetAddrTable row:
          snmpTargetAddrName              toCRAddr        (arbitrary string) 
      +   snmpTargetAddrTDomain           snmpTCPDomain    
      ++  snmpTargetAddrTAddress          0x0A00000100A2  (CR address, port) 
          snmpTargetAddrTimeout           1500            (in .01 sec) 
          snmpTargetAddrRetryCount        3       
          snmpTargetAddrTagList           toCRTag         
          snmpTargetAddrParams            toCR            (must match prev) 
          snmpTargetAddrStorageType       3               (nonVolatile) 
          snmpTargetAddrColumnStatus      4               (createAndGo) 

    *  = changed since previous example.
    +  = may change to SSHDomain?  subject to debate
    ++ = shown as same but will likely change (port number likely new from IANA)

    Because we need 3 configuration settings (A, B, and C above) and
    there is no room in the existing tables for that information,
    we'll need to create another table to contain the needed
    settings.  This will be the snmpSSHParametersTable and will
    contain the following information:

    snmpSSHParametersTable:
          snmpSSHParameterName            sshParams  (matches 2nd * above)
          snmpSSHUserName                 sshUser    (the NG says "I'm sshUser")
          snmpSSHUserCredentialType       1          (1 = userPublicKey,
                                                      2 = userPassword,
                                                      3 = hostPublicKey
                                                      ... enum list
                                                      should be pulled
                                                      from ssh auth types?)
          snmpSSHNRUserKey                +++        (the expected NG Key)
          snmpSSHNRUserPass               ++++       (the passphrase to use)
          snmpSSHNRHostKey                +++        (the expected NR Key)

    +++  = issue with config via SNMP since these are potentially
           larger than SNMP/UDP would like.
    ++++ = GET = "", SET = set it?

    With all of this in place it is possible for a NG to ope a
    connection to a NR and authenticate itself and verify the other
    end is the expected end.

    It is implementation dependent how the NR decides whether to
    accept notifications given the authentication provided by the NG.
    This is already true for SNMPv3/USM NR engines today.

2.1.2 Authentication Using a SSH Host-Key

    Devices with deployed SSH Host public-key credentials
    ("Host-Keys") already have a public key that is likely known to a
    network management station.  This is the same host identity that
    must be authenticated to when connecting to an agent operating as
    a CR when a management station takes on the role of a CG.  It is
    possible to reuse the agent's (CR's) SSH public host key when
    operating as a NG to open a connection back to a NR.

    To accomplish this, the NG would open a SSH connection to the NR
    and both sides would authenticate each other.  The NR would use a
    host-key certificate per-normal SSH usage.  The NG would present
    it's own host-key certificate to authenticate itself rather than
    present the more typical user-based credential as discussed in
    section 2.1.1.

    How to accomplish this via the SSH protocol is discussed in
    Section 9 of [RFC4252].  Note that for SSH this form of
    authentication is optional.

    Steps to send the notification:

      1) The NG would open a SNMP/SSH connection to the NR.

      2) The NR would send it's public key and proof of ownership

      3) The NG would verify that it was talking to the expected NR (by
         verifying the public key against the proof and by verifying
         that the public key presented matched the expected public key
         for that destination).

      4) The NG would transmit it's user name (see below) and it's
         host credential.

      5) The NR would verify the authenticity of the received
         credentials.

      6) The NG would send the notification through the established
         connection.

    Note: Section 9 of [RFC4252] actually specifies that for
    authorization purposes the NR can ignore the user name field for
    this authentication type.  The NG must fill it in, however.

    For the new snmpSSHParametersTable settings, they would look
    like:

    snmpSSHParametersTable:
          snmpSSHParameterName            sshParams  (matches 2nd * above)
          snmpSSHUserName                 sshUser    (the NG says "I'm sshUser")
    *     snmpSSHUserCredentialType       3          (1 = userPublicKey,
                                                      2 = userPassword,
                                                      3 = hostPublicKey
                                                      ... enum list
                                                      should be pulled
                                                      from ssh auth types?)
    *     snmpSSHNRUserKey                ""         (the expected NG Key)
                                                     (blank = default host key)
          snmpSSHNRUserPass               ""         (none)
          snmpSSHNRHostKey                +++        (the expected NR Key)

    *    = changed from last time
    +++  = issue with config via SNMP since these are potentially
           larger than SNMP/UDP would like.

    With the above in place, it should be possible to open a host-key
    based authentication from the NG to an NR.

    It is implementation dependent how the NR decides whether to
    accept notifications given the authentication provided by the NG.
    This is already true for SNMPv3/USM NR engines today.

    The primary advantage of this over the user-based credentials used
    in Section 2.1.1 is that the host-key has likely already been
    created and no credential configuration is needed.  The NR,
    however, still needs to be configured to accept notifications from
    an NG using it's host-key credentials (and tied to the
    snmpSSHUserName passed in the "user name" field of the
    SSH_MSG_USERAUTH_REQUEST message described in Section 9 of
    [RFC4252].

2.2 Reusing an existing SNMP/SSH Connection That Was Previously
    Established between the NG and NR.

    There has been desire to have an architecture where a Notification
    Receiver connects to a Notification Generator and notifications
    are then sent via this connection.  This section describes how
    this can be done via SNMP/SSH using additional MIB configuration
    settings.

    Steps to send the notification:

      1) The NR would open a SNMP/SSH connection to the NG.  There are
         two choices here:

         a) Open only a single connection to the standard CR service
            endpoint which also happens to be capable of sending
            notifications back over the same stream (acting as a NG on
            the same session).
         b) One connection to the standard CR service, and a second to
            a NG service port.

         Note that notifications would not be sent until the rest of
         the following steps had taken place.

      2) The CR and/or NG service(s) would send it's public key and
         proof of ownership.

      3) The CG and/or NR would verify that it was talking to the
         expected CR/NG (by verifying the public key against the proof
         and by verifying that the public key presented matched the
         expected public key for that destination).

      4) The CG/NR would transmit it's user name and credentials
         (either a public key, password or other SSH authentication
         mechanism).

      5) The CR/NG would verify the authenticity of the received
         credentials.

      6) The CG would configure the CR to send notifications over the
         already existing SNMP/SSH channels (configuration of the
         snmpNotifyTable not shown as it matches that in section 1.2):

      snmpTargetParamsTable row:
          snmpTargetParamsName            toCR       (administrative string)
          snmpTargetParamsMPModel         3          (SNMPv3)
      *   snmpTargetParamsSecurityModel   4          (SSH)
      *   snmpTargetParamsSecurityName    XXX        (see below)
          snmpTargetParamsSecurityLevel   3          (auth|encr)
          snmpTargetParamsStorageType     3          (nonVolatile)
          snmpTargetParamsRowStatus       4          (createAndGo)

      snmpTargetAddrTable row:
          snmpTargetAddrName              toCRAddr        (arbitrary string) 
      *   snmpTargetAddrTDomain           snmpSSHSession
      *   snmpTargetAddrTAddress          YYY             (see below)
          snmpTargetAddrTimeout           1500            (in .01 sec) 
          snmpTargetAddrRetryCount        3       
          snmpTargetAddrTagList           toCRTag         
          snmpTargetAddrParams            toCR            (must match prev) 
          snmpTargetAddrStorageType       3               (nonVolatile) 
          snmpTargetAddrColumnStatus      4               (createAndGo) 

    *  = changed since previous example.

    In order to enable the NG to start sending notifications over
    either the current ssh session (the connection to the CR service)
    or another SSH session (a connection to the NG service), the XXX
    value of the snmpTargetParamsSecurityName and the YYY parameter of
    the snmpTargetAddrTAddress field need to be filled into to point
    to the proper session.  This could be done in 2 different ways
    that I can think of (possibly more):

    option 1)

      snmpTargetAddrTDomain        =       snmpSSHSession
      snmpTargetParamsSecurityName = XXX = "NRUser"
      snmpTargetAddrTAddress       = YYY = ""

      This would effectively state that the NG could send notifications
      to all connected SNMP/SSH sessions that the incoming (***only***)
      SNMP/SSH connection had authenticated as the SNMP/SSH user
      "NRUser".  Outgoing sessions from the NG MUST NOT be checked for
      when looking for sessions that match this criteria.  The VACM
      would be consulted based on the SNMP/SSH security model and the
      security Name of "NRUser" in this example.

    option 2)

      snmpTargetAddrTDomain        =       snmpSSHSession
      snmpTargetParamsSecurityName = XXX = ""
      snmpTargetAddrTAddress       = YYY = 0x00000001  (session id)

      This would effectively state that the NG could send
      notifications to the SNMP/SSH session with a session id of 1.
      This could potentially be the exact same session that the CG/CR
      were speaking over, or it could be an "external" session such as
      one connected to via the CR.  The VACM would be consulted based
      on the SNMP/SSH security model and the security name of the
      ***remote*** user name associated with the remote session #1 for
      incoming sessions.  Outgoing sessions MUST NOT be referred to by
      the NG (see ????)

      (???? aside: actually I'm not sure this is required from a
      security stand point, but I don't like the security name
      associations that would have to happen between the configuration
      and the sessions...  I'd rather just only do this for incoming
      sessions as it doesn't make my hairs stand up as potentially
      problematic).
-- 
Wes Hardaker
Sparta, Inc.

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 18 Jul 2006 13:03:02 -0400

Hi,

I need some editorial guidance from the WG and the chairs.
The consensus has been that the SSH particulars be hidden.
As a result, we have not defined (in fact I have removed) a MIB to
carry SSH-specific parameters.
The current documents just say there is SSH-specific (or
transport-specific) data stored in a Local Configuration Datastore.

If that is all we need, then the documents may be close to done, but
there is quite a bit of hand-waving about implementation-dependent
configuration and parameter passing. I think this will make it harder
to get independent interoperable SSHSM model implementations, but I am
not implementing, so I could be wrong.

Wes's email describes such an LCD and how it relates to the snmpTarget
tables. Does the WG want an snmpSSHParametersTable included in the
SSHSM document? Should I put this into an appendix as a sample of how
an LCD might be designed? Should this be a normative MIB module to
allow SNMP configuration of the security model (we cnosidered snmp
configurability important for the snmpv3 standard)? I think defining a
MIB module, either informative or normative, might be helpful to guide
implementors, but we risk defining a model that is harder to integrate
with some implementations of SSH and SNMP.

By relying on an implementation-dependent opaque datastore of
transport parameters, we have been able to genericize the
session-based security model wording to be transport independent. If
we define a MIB module for SSHParameters, we may not be able to hide
the security-model elements of procedure details behind an opaque LCD.

Should we define an snmpSSHParametersTable, and reference the managed
objects in the elements of procedure section?

dbh

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Monday, July 17, 2006 10:04 PM
> To: [email-masked]
> Subject: [Isms] using notifications with SNMP/SSH
> 
> 
>                                                       2 = 
> userPassword,
>                                                       3 = 
> hostPublicKey
>                                                       should be
pulled
>                                                       from 
> ssh auth types?)
>                                                       2 = 
> userPassword,
>                                                       3 = 
> hostPublicKey
>                                                       should be
pulled
>                                                       from 
> ssh auth types?)
> notifications

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 20 Jul 2006 12:58:35 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Wes Hardaker'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 18, 2006 10:03 AM
> Subject: RE: [Isms] using notifications with SNMP/SSH
...
> objects in the elements of procedure section?
...

I'd say yes, if we ever want to provision these things in an interoperable
way.  However, since it's configuration data, shouldn't it be done in the
form of a netconf data model rather than a MIB?

But the question that really nags at me is whether this will still be subject
to the same criticisms as USM with respect to the effort required to set
up and maintain a system's security configuration.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Jul 2006 11:35:59 +0200

> objects in the elements of procedure section?

As far as I can tell, we first need to figure out how to ship
notifications and settle on hopefully just one mechanism.

As a technical contributor and implementor, I would not mind to have
things spelled out in order to achieve interoperability. I assume that
MIB details will be transport specific (specific for SSH or for TLS)
and as such they are different from the MIB module that previously
existed in the session-based security model and which was transport
agnostic (correct me if I am wrong).

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 24 Jul 2006 11:36:49 +0200

> the description below is sufficient for forward progress.

[...]

Thanks for writing this up. I think this is very helpful input.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Jul 2006 10:05:09 -0400

> > SSHSM document? 
>[...] I assume that

I think it likely we will need to have entries in the
snmptargetParamstable that reference entries in the SSHSMParamaters
table (referenced by securityModel/Name/Level, where model=SSHSM tells
us to use the SSHSMParameters table, and securityName/level tells us
which row to use). So, we can define the MIB in the SSHSM document, in
an SSH-transport-mapping specific manner.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 25 Jul 2006 19:12:15 -0400

Hi,

Without having gone through the elements of procedure (EOP) in both
the TMSM and SSHSM documents, using each of the three approaches
described by Wes, I cannot say for sure we can still accomplish the
separation of transport mapping from security model.

I think there are two different concerns here.
First is how to identify the target system and have a notification
generator open a session. I think the EOP in the TMSM and SSHSM
documents may be able to do this just fine already with no changes.
Currently the documents say the information about the target system is
taken from the LCD, withuot specifying what the LCD actually contains
(and saying it is implementation-dependent). Adding an
snmpSSHParamsTable will simply spell this out more clearly, and show
how the correct entry in the LCD is identified using the existing
snmpTargetParamsTable et al.

The second issue is how to apply data access control appropriately,
when authentication has two different principals (the server and the
client). Wes says the NG must send notifications as a "notification
responder". There is currently no such thing as a notification
responder, only a generator or reciever.I do not know if this was a
typo and he meant to say "receiver" rather than responder. 

Maybe he is proposing a new "snmnp application" to supplement the NG
and NR applications. I think doing  so might create bindings between
the application and transport mapping, i.e. the application would need
to know what transport sessions existed. I fear this would violate the
modularity of the architecture. 

If Wes meant receiver rather than responder, then I have different
concerns. I think a notification generator needs to send notifications
as a notification generator, otherwise we will need to change how the
EOP of RFC3413 work.

dbh

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 5:36 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] using notifications with SNMP/SSH
>