Subject: [Isms] ISMS/SSH and notifications

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 May 2008 17:16:32 -0700

The following is based on the message I sent out in January in 2007 and
then later modified in July of 2007.  I've now modified it for a third
time to fix some errors I found in it and have lengthened some of the
sections to talk more about the issues recently discussed here.

I didn't know which email was the best to reply to in the current
thread, so I gave up and started a new Subject: :-)

  (previous posting for anyone that wants to compare changes:
      http://www.ietf.org/mail-archive/web/isms/current/msg02097.html
  )

This is *long* but hopefully clear.  Please read the entire document
before responding to bits in the top; it's not a complete set of thouhts
without reading the whole thing (sorry).  Hopefully it'll be helpful,
however.  The VACM discussion in section 3 is entirely new.

This is all 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.

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            toNR       (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              toNRAddr        (arbitrary string) 
      snmpTargetAddrTDomain           snmpUDPDomain    
      snmpTargetAddrTAddress          0x0A00000100A2  (NR address, port) 
      snmpTargetAddrTimeout           1500            (in .01 sec) 
      snmpTargetAddrRetryCount        3       
      snmpTargetAddrTagList           toNRTag         
      snmpTargetAddrParams            toNR            (must match prev table) 
      snmpTargetAddrStorageType       3               (nonVolatile) 
      snmpTargetAddrColumnStatus      4               (createAndGo) 

  snmpNotifyTable row:
       snmpNotifyName                 NRNotif         (arbitrary string)
       snmpNotifyTag                  toNRTag         (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.

  An important point: the agent already needs configuration to be able
  to send notifications regardless if ssh is the transport or it's not.

1.3 Basic VACM Configuration

  The workings of the VACM is fortunately more widely understood, so I
  won't break it out in detail here.  The important thing to do know
  from a notification point of view is that the only thing the VACM
  needs to check is "am I allowed to send this notification".  It does
  that through the use of a securityName (and model and level) given to
  it by the NG.  It doesn't care where that securityName came from nor
  how it was technically authenticated.  It completely trusts the caller
  to not have lied to it and it's the callers responsibility to have
  checked the authenticity of the values.

  Here's the important key point: the VACM does not verify that the
  other end is actually who they say they are.  It's not the VACMs job.
  We'll need this later.

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 (this is a very terse description of
    what happens when you combine SSH and SNMP for notifications; it's
    obviously a bit more complex as there are more steps involved; this
    is just a high level summary):

      1) The NG would open a SNMP/SSH connection as an SSH Client to the
         NR acting as a SSH server.

      2) The NR would send it's public (host) 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; see below).

      4) The NG would transmit it's user name and it's own SSH
         authentication 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:

      1) The ability to indicate that ISMS/SSH should be used as the
         transport.

         EG: "Send a copy of the notification to host H using SSH to port P"

      2) The Ability to specify the SSH user credential type to use
         (eg, public key or password)

         EG: "I'm 'Adam'"
      
      3) The ability to configure that public-key or password

         EG: "I can prove I'm joe because I have the super secret
         password or can prove I have the needed private key"

      4) end-destination expected public SSH host-key

         - the public key of the NR acting as an SSH Server that the NG
           acting as a SSH Client should be connecting to.

         EG: "Now prove to me that you're Bob so I know that you're not
         Eve"

    Note one security risk that needs to be mentioned about the above:

      1) Username/password combinations are horrible things to use.  SSH
         allows for it but in order to use it securely in order to
         prevent agent configuration theft compromising an entire
         network (see USM Key Localization) you'd have to use a
         different username/password configured into each agent.  That
         doesn't scale wonderfully from a configuration point of view.
         Thus public/private keys should be used instead (of course).
         I'm not going to get into the debate here about whether we
         should support/allow username/password configuration for
         sending something).

2.1.1.1 Changes to the TARGET-MIB configuration

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

      snmpTargetParamsTable row:
          snmpTargetParamsName            toNR       (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              toNRAddr        (arbitrary string) 
      +   snmpTargetAddrTDomain           snmpTCPDomain    
      ++  snmpTargetAddrTAddress          0x0A00000100A2  (NR address, port) 
          snmpTargetAddrTimeout           1500            (in .01 sec) 
          snmpTargetAddrRetryCount        3       
          snmpTargetAddrTagList           toNRTag         
          snmpTargetAddrParams            toNR            (must match prev) 
          snmpTargetAddrStorageType       3               (nonVolatile) 
          snmpTargetAddrColumnStatus      4               (createAndGo) 

    *  = changed since previous example.
    +  = may change to snmpSSHDomain?  subject to debate
         (the security model already indicates SSH but if we want a v1
         or v2c security model then we'll need to use a snmpSSHDomain
         instead; I think this is likely at this point)
    ++ = shown as same but will likely change
         (likely a new port number from IANA)

    Because we need 4 configuration settings (1-4 above) and there is no
    room in the existing tables for some of that information (config
    setting #1 (use SSH) was done in the snmpTargetParamsSecurityModel
    and/or snmpTargetAddrTDomain), we'll need to create another table to
    contain the other 3 needed settings.  I'll call this the
    snmpSSHParametersTable and it will contain the following
    information:

    snmpSSHParametersTable:

       index:
          snmpSSHParameterName            sshParams  (matches 2nd * above)

       columns:
          snmpSSHUserName                 Adam       (the NG says "I'm Adam")
          snmpSSHUserCredentialType       1          (1 = userPublicKey,
                                                      2 = userPassword,
                                                      3 = hostPublicKey
                                                      ... enum list)
          snmpSSHNGUserKey                +++        (the expected NG Key if 1)
          snmpSSHNGUserPass               ++++       (the passphrase to
                                                      use if 2)
          snmpSSHNRHostKey                +++        (the public key
                                                      expected from the
                                                      expected NR)

    +++  = potential issue with config via SNMP/UDP since these are
         potentially larger than SNMP/UDP would like.
    ++++ = a GET should return "" at all times?

    With all of this in place it is possible for a NG to open a
    connection to a NR and authenticate itself and verify the other
    end is the expected end.  Note that we still haven't discussed user
    names; be patient!

    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 (there is no
    NR authorization model in the SNMPv3 STDs).

    Notification delivery would fail if the snmpSSHNRHostKey didn't
    match the returned SSH public certificate given by the NR or if it
    failed to authenticate.  The SSH connection also wouldn't succeed if
    the NR refused 

    The question many should be asking at this point is, "but...  we're
    trying *not* to configure so much stuff and we want to reuse
    existing authentication systems".

    - There is no way to avoid the configuration of the NR host key to
      be expected.  Not doing so would be insecure.  IE,
      snmpSSHNRHostKey is required.  This *could* be bootstrapped using
      the normal SSH known_hosts cache if it already had a setting.  A
      blank value, eg, could indicate use "use the existing known_hosts
      cache".  Because this is expected to be a device that probably
      hasn't done SSH Client logins before, it's unlikely this host
      cache would exist.  But it could be distributed via rdist, etc, if
      operators preferred that.  It could be that this entire column
      could be left to SSH Client side implementation, but that doesn't
      seem complete to me and I'd rather see it in place rather than
      require an external distribution mechanism.

    - There is no way to avoid the configuration required by the client
      (snmpSSHUserName and related authentication data).  *However*, if
      the snmpSSHUserCredentialType was 3 (hostPublicKey) and
      snmpSSHNRUserKey was "" (blank) then that could indicate to simply
      use the system configured ssh host key instead of using a separate
      one.  This would alleviate this configuration setting and entirely
      rely on the pre-configured ssh service's host key.  This does
      assume there is only one to choose from, however.  If a system had
      more than one it is undefined what should happen.

      This is dual-using a SSH host key for both host usage and user
      usage, and it's unclear whether this should be frowned upon or
      not.  Cryptography-wise it's generally not recommend that keys not
      be allowed to be shared between multiple identities (i.e. both a
      host and a user named 'Adam').  SSH actually already has an
      authentication mode designed to authenticate as a host directly
      though.  See the next section for details.

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 already 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 over SSH.  It is
    possible to reuse the CR's SSH public host key when operating as a
    NG SSH-Client to open a connection back to a NR SSH-Server.

    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 support is OPTIONAL in this document.  The ISMS/SSH
    document would have to require.

    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 special host-based 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?)
    *     snmpSSHNGUserKey                ""         (the expected NG Key)
                                                     (blank = default host key)
          snmpSSHNGUserPass               ""         (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 and this is the
    SSH supported mechanism for using a host-based authentication
    mechanism.  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.  Some of this desire has dropped a bit since this section
    was originally written.  [I haven't re-proof-read this section as much.]

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

3. VACM Authorization

    Here's where the important note discussed above comes into play: the
    VACM doesn't care how the securityName passed to it was derived and
    authenticated.  It's not the job of the VACM to do that.  It trusts
    the CR and NG engines to have done the right thing security wise.

    A lot of discussion has surrounded this point.  What does the VACM
    use when doing authorization lookups?  The NR/SSH server doesn't
    have a "user name" in the traditional sense of the word.  It has
    proven that it has an adequate host key, however.

    Choices:

    1) The local configuration has already dictated a user name to use
       via the snmpSSHUserName setting discussed above (assuming the
       text in this document is followed).  This is the value that
       should be given to the VACM (along with an appropriate model and
       level settings based on the connection).  It doesn't matter that
       the remote host didn't specify this value in the connection; the
       local configuration says this is the value that should be used
       and the remote side *has* proven that it can authenticate the
       NR host key that was expected.

       But, this doesn't allow for dual-user name support, which brings
       us to option 2:

    2) If there is desire to have the NG/SSH-Client use one user name to
       authenticate itself to the remote NR/SSH-Server and another to
       consider the remote NR/SSH-Server to be for purposes of VACM
       authorization then another column in the snmpSSHParametersTable
       would be needed that might have something like:

       snmpSSHRemoteUser                   "Jack"

       Again, it does not matter that the remote side didn't technically
       specify itself as "Jack".  It's already proven that it has the
       configure remote host key.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: <[email-masked]>
Date: Fri, 2 May 2008 12:04:47 +0300

Wes Hardaker wrote:

> The following is based on the message I sent out in January in 2007
> and then later modified in July of 2007.  I've now modified it for a
> third time to fix some errors I found in it and have lengthened some
> of the sections to talk more about the issues recently discussed
> here.

I think this looks pretty good! (Although there are really two
quite different solutions, depending on which of the parties
opens the SSH connection.)

Couple of minor comments/questions:

<snip>
> 2.1.1.1 Changes to the TARGET-MIB configuration
<snip>
>    snmpSSHNGUserKey                +++        (the expected NG Key if 1)

Should this be "++++ (the NG public/private key pair if 1)"?

>    snmpSSHNGUserPass               ++++       (the passphrase to use if 2)
> connection to a NR and authenticate itself and verify the other end
> is the expected end.  Note that we still haven't discussed user
> names; be patient!
> 

I guess one detail that still needs to be described is what's the
securityName value passed to the notification receiver application.

<snip>
>    should be given to the VACM (along with an appropriate 
>    model and level settings based on the connection).  It doesn't 
>    matter that the remote host didn't specify this value in the 
>    connection; the local configuration says this is the value that 
>    should be used and the remote side *has* proven that it can 
>    authenticate the NR host key that was expected.
> 

Can't we use snmpTargetParamsSecurityName for this? 

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 02 May 2008 09:30:20 -0700

PE> I think this looks pretty good! (Although there are really two
PE> quite different solutions, depending on which of the parties
PE> opens the SSH connection.)

Yep.  It's still up for debate if we want to allow the manager to open
the connection.  A few years ago it was looking like we should do it.  I
think desire has fallen a bit since then.  I'm not really sure it's
necessary and worth the complexity increase, but I'm not opposed to it
either.

>    snmpSSHNGUserKey                +++        (the expected NG Key if 1)

PE> Should this be "++++ (the NG public/private key pair if 1)"?

Yep.  Good point.

(though a GET could return the public half)

And it would probably be better to have 2 columns, one for the public
key and one for the private.  Or a button to generate a new key pair and
that column would just return the public half of the generated pair and
thus the private never has to traverse the network (but then we get into
key generation parameters etc).  Though we could also just opt-out of
the whole configuration pile and say "use this public key; you'd better
have the private somewhere in your ssh stash" (and a SET of an unknown
public key would then fail with an error). 

> NR authorization model in the SNMPv3 STDs).

PE> I guess one detail that still needs to be described is what's the
PE> securityName value passed to the notification receiver application.

For a user-server connection the security name could be pulled from the
normal SSH connection.  That's already taken care of.  For a host based
authentication you're right...  maybe we should require the NR to accept
the host based authentication name for the NR to use as a securityName.
I haven't checked what the legal lengths of a host-based SSH
authentication name can always fit within a securityName field (which is
only 32 octets long).

<snip>
> configure remote host key.

PE> Can't we use snmpTargetParamsSecurityName for this? 

Yes.  Somehow I forgot about that column.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: <[email-masked]>
Date: Mon, 5 May 2008 16:17:56 +0300

Wes Hardaker wrote:

<snip>
> And it would probably be better to have 2 columns, one for the
> public key and one for the private.  Or a button to generate a new
> key pair and that column would just return the public half of the
> generated pair and thus the private never has to traverse the
> network (but then we get into key generation parameters etc).

Is there any precedent for this, e.g. other MIBs that manage
public keys in some way? Or generate new keys?

> Though we could also just opt-out of the whole configuration pile
> and say "use this public key; you'd better have the private
> somewhere in your ssh stash" (and a SET of an unknown public key
> would then fail with an error).

Or to make it more admin-friendly, maybe just pass a name/token of
some kind; the SSH stash would be responsible for handling both 
public and private parts of the key?

(I guess on the SSH server side, we anyway won't have detailed
MIBs for configuring things.)

> PE> I guess one detail that still needs to be described is what's
> PE> the securityName value passed to the notification receiver
> PE> application.
> 
> For a user-server connection the security name could be pulled from
> the normal SSH connection.  That's already taken care of.  

Well... the SSH user name seen by the notification receiver (SSH
server) really identifies the notification generator, so it's not 
the same as the securityName given by the notification generator
application. If we want to preserve this property, we need something
else...

Best regards,
Pasi

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 5 May 2008 11:46:25 -0600

Hi -

> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, May 05, 2008 7:17 AM
> Subject: Re: [Isms] ISMS/SSH and notifications
...
> public keys in some way? Or generate new keys?
...

Yes, going back at least as far as  RFC  1352.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 05 May 2008 13:29:38 -0700

>>>>> On Mon, 5 May 2008 16:17:56 +0300, <[email-masked]> said:

PE> Is there any precedent for this, e.g. other MIBs that manage
PE> public keys in some way? Or generate new keys?

As Randy mentioned, yes.

The USM-DH MIB also has some prior history.

>> would then fail with an error).

PE> Or to make it more admin-friendly, maybe just pass a name/token of
PE> some kind; the SSH stash would be responsible for handling both 
PE> public and private parts of the key?

The problem with that is that the current SSH implementations don't
support named keys at this point.  Not that it can't be done, but it'd
require new features of the SSH service or an independent name mapping
on the SNMP side.

>> the normal SSH connection.  That's already taken care of.  

PE> Well... the SSH user name seen by the notification receiver (SSH
PE> server) really identifies the notification generator, so it's not 
PE> the same as the securityName given by the notification generator
PE> application. If we want to preserve this property, we need something
PE> else...

I'm not sure which property you're talking about preserving.  (USM
actually operates in one of two modes depending on whether TRAPs or
INFORMs are being sent).
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 9 May 2008 14:19:27 +0300

Wes Hardaker wrote:

> PE> application. If we want to preserve this property, we 
> PE> need something else...
> 

The property that securityName given in notification originator's
sendPdu() call is the same as the notification receiver gets in 
the processPdu() call (in RFC 3413 terms).

(However, it's possible that preserving this property exactly is not
absolutely required, since the current RFCs don't seem to specify how, 
if at all, the notification receiver would use this information.)

Best regards,
Pasi

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 9 May 2008 15:11:16 +0300

Ray Purvis wrote:

> [Ray Purvis] Isn't the securityName, in the current RFCs, and thus
> for the use of USM, used with the snmpEngineID to locate the
> authentication and privacy key to authenticate/decrypt the
> notification?

Yes; with SSHTM, at the point when the securityName actually
could be visible, the packet has already been authenticated
and decrypted.

Best regards,
Pasi

---

From: "Purvis, Ray" <[email-masked]>
Date: Fri, 9 May 2008 08:17:05 -0400

Yes, of course, I had USM on the brain.  For TSM, the notification receiver
doesn't really have a whole lot to do with the securityName, does it?
Thanks much.

Ray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 09, 2008 7:11 AM
To: Purvis, Ray; [email-masked]
Cc: [email-masked]
Subject: RE: [Isms] ISMS/SSH and notifications

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 09 May 2008 07:28:10 -0700

>>>>> On Fri, 9 May 2008 08:17:05 -0400, "Purvis, Ray" <[email-masked]> said:

RP> Yes, of course, I had USM on the brain.  For TSM, the notification receiver
RP> doesn't really have a whole lot to do with the securityName, does it?

It is important to identify who sent the message.  Notification
receivers are fairly boring in their current ability to log stuff,
however.  Frequently they just display logs associated with an IP
address and possibly a port.

Right now the SNMP standards don't dictate that the securityName be used
much on the notification receiver side.  Note that even the
NOTIFICATION-LOG-MIB doesn't have an entry fro the securityName used to
send the message (just the context engineID and transport information).
There is no securityName for SNMPv1/SNMPv2c so to some extent this does
make sense.

Net-SNMP (a single point of data as a reference) actually does use the
securityName to authorize what a received notification is allowed to do
(log, forward and execute being the current 3 possible outputs to the
authorization process).  I think Net-SNMP is fairly unique here as most
notification receivers don't do any authorization checks other than to
assure the packet has been properly authenticated.

But...  My point was that there is no current standard that requires
they be the same on both sides.  Both sides may need to make a decision
or use the resulting securityName.  But there isn't a requirement that
the be administratively identical on both sides.  The SSH transport will
accept a user name on the client side to "use" in the transport, and the
server side will be able to extract that same name.  There is no reason
why administratively it can't be the name configured on both sides to be
*the* securityName.  But there is no *current* great reason why on the
sending side it couldn't be different as well.

I think I'm digressing a bit though.  The original point of my message
had nothing to do with the security name the notification receiver was
using (it essentially would be the ssh user name accepted through the
ssh transport).

The issue on the table originally "if USM INFORMs considers the remote
notification receiver to be authoritative, and thus the securityName is
technically defined by the remote side and if SSH doesn't give us a
"name" to use to identify the INFORM receiver with, then what do we use
to do a VACM authorization check?".   My point was: we have information
on the client side that we can use already.  If we want to use the user
name we sent as a client, that's fine.  If we want to use something
different, that's fine too (IMHO here).  The important thing, and this
is critical, is that whatever we decide to call the notification
receiver securityName-wise we MUST make sure the public key returned by
the SSH server and authenticated by the SSH client side is the same as
the public key we were expecting.  Otherwise, all bets are off.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "Purvis, Ray" <[email-masked]>
Date: Fri, 9 May 2008 07:33:53 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, May 09, 2008 6:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Isms] ISMS/SSH and notifications

(However, it's possible that preserving this property exactly is not
absolutely required, since the current RFCs don't seem to specify how, 
if at all, the notification receiver would use this information.)
[Ray Purvis] Isn't the securityName, in the current RFCs, and thus for
the use of USM, used with the snmpEngineID to locate the authentication
and privacy key to authenticate/decrypt the notification?
v/r

Ray

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Tue, 13 May 2008 16:32:18 +0200

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 09, 2008 1:19 PM
Subject: Re: [Isms] ISMS/SSH and notifications

> if at all, the notification receiver would use this information.)

I am not clear what problem this is solving.  The problem I see, which has been
mulled over for some three years and Juergen articulated last month, is that
access control in the NO checks that the NR is permitted to see the data in the
notification based on the securityName.  For that check to be of any value, then
the name needs authenticating, which means that the NR should supply credentials
for it.

So Wes is right to say that VACM is not responsible for checking it but I think
wrong to say that it is ok to take whatever the application gives it.  The
security model should stand between the two and check that the secure transport
ends at something with that name and with verified security credentials (as USM
does).  And as has been pointed out several times, when the NO originates the
session, and the NO is the ssh client, then that credential is a public key.  So
that is what the NO should be checking and what VACM should have in its
tables:-)

I do not see these proposals as solving that problem.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 May 2008 14:11:50 -0700

>>>>> On Tue, 13 May 2008 16:32:18 +0200, "tom.petch" <[email-masked]> said:

tp> The problem I see, which has been mulled over for some three years
tp> and Juergen articulated last month, is that access control in the NO
tp> checks that the NR is permitted to see the data in the notification
tp> based on the securityName.

Correct.  The VACM uses a securityName to make an access control
decision.  The security model is responsible for determining that the
other side isn't "faking it".  The security model (SM) is responsible
for mapping "something security-model specific" (paraphrasing the
architecture here) to a securityName that could be used "beyond that
point" (again, paraphrasing), like the application (NG, NO, CR, CG) for
example.  The "beyond that point" apps trust the SM to have given it an
appropriate securityName.

The question is, where does that name come from?  There are three
potential places:

  1) configuration
  2) somewhere in the packet
  3) somewhere in the security credentials

Where it comes from only is tied together cryptographically if it's in
the keying material (#3) is chosen (keep reading to get comments on #2)

tp> For that check to be of any value, then the name needs
tp> authenticating, which means that the NR should supply credentials
tp> for it.

Not necessarily true.  In a security model that didn't have a 1:1
mapping from something in the packet to the securityName then the
security model has to *derive* the securityName to use.  It does this
through a security model specific transformation (the SNMPv3
architecture very wisely allowed for this possibly and discusses it in
various places).

What, does a protocol which has no in-packet direct "note" saying "I'm
Bob" do?

The choices (marker: ***) are:

  1) throw up your hands and say "this protocol is useless".  I don't buy
     this option but apparently some are willing to just ditch SSH because
     there is no magical 1:1 mapping transformation.

  2) Use some other in-protocol field to "transform" into a security
     name.  This could be, for example, the SSH server name offered up
     by the SSH server side of the protocol.  This is one potential
     solution out of this space.  The securityName would be set to
     "wjh.hardakers.net", for example, if a client was trying to connect
     to my laptop.  The issue will come, however, that the legal length
     of a host name is longer than that of the legal securityName value
     that is used to look up a VACM entry.

  3) A configured mapping table.  Something in the packet or in the
     configuration that created the session could be used to look up, in
     a configured lookup table, what the securityName should be based on
     cryptographically proven (assuming at least authNoPriv) portions of
     the packet.  Like the server's SSH public key.

Only public key *certificates* (note the added word) actually containing
identifying information in the certificate itself that says "I'm Bob,
and not only that if I alter this certificate saying I'm now Eve it
won't work".  SSH doesn't operate this way; the application says "I'm
Bob and I'm using this key" but the key doesn't prove it.  The keys only
prove that the application has the private key.  It could still say
"Eve" and you can still only verify that eve has a private key you
recognize and potentially trust.  The USM doesn't provide any assurance
that the keying material it uses is attached to a particular name as
well.  Every user in the USM table could all be configured with the same
localized key so that Bob, Mary, Eve and Joe all could swap account
names and the far other side would do VACM checks on whatever name was
given to it in the packet regardless of the fact that they could have
picked from a few.  That wouldn't be allowed with an X.509 cert, for
example, but would be with both SSH and USM.

tp> So Wes is right to say that VACM is not responsible for checking it
tp> but I think wrong to say that it is ok to take whatever the
tp> application gives it.  The security model should stand between the
tp> two and check that the secure transport ends at something with that
tp> name and with verified security credentials (as USM does).

No, actually the USM doesn't do this.  A couple of problems exist in
this logic:

1) The security model hands the securityName back to the application and
   says "I got this message from this dude named 'Bob'".  The
   application already takes the value 'Bob' and can change it to
   whatever it wants before handing it to the VACM.  There is no
   security check in the architecture today that the application isn't
   discarding what it got from the SM and winging it.  The security
   model doesn't "stand between the two" like you suggest.

   (a historic aside: there was actually an alternate SNMPv3 architecture
   ID that attempted to allow the SM and the ACM blocks to communicate
   so that the ACM could verify wit the SM that the application wasn't
   lying to it, but it never got published.  I was even part of a team
   that did a reference implementation of it that really showed you have
   to have the SM and the ACM blocks be memory protected from the
   application for it to actually be an effective security mitigation
   and no SNMP stack these days really supports that separation).

2) The initiating application (NG or CG) is the one that actually tells
   the remote side who it is when USM is used.  More importantly, it
   really says "we're both Bob; I can prove I'm Bob and please prove you
   are too when you send a response".  The CR and NR merely use this
   fact to look up the proper keying material to use to ensure that they
   can be Bob.

tp> And as has been pointed out several times, when the NO originates
tp> the session, and the NO is the ssh client, then that credential is a
tp> public key.

The *client* credential is a public key.  As is the servers.

tp> So that is what the NO should be checking and what VACM should have
tp> in its tables:-)

Right, that's actually what I said.  You could use the server's key to
do a lookup in a table to ensure you're talking to Bob.  If they say I
have key 0xABCD and you have "Bob" next to 0xABCD in your keying table,
then you can be completely sure it's "Bob" at the other end.

The only two forward paths that exist are #2 and #3 from *** above.  I'm
honestly happy with either, though #2 (using the SSH server host name as
the securityName) would limit the hostnames I can use but, and this is
my important point, it doesn't provide me with any extra security over
#3 (using a mapping table so the key would be used to lookup the value
of the securityName to use).  A lookup would be done in the process of
sending a trap.  The configuration would specify the remote securityName
and the public key of the remote server to verify it's the right
securityName on the other side.

Cryptographically speaking, you still don't have any assurance that the
application hasn't messed with the data before the VACM uses it nor do
you have any assurance that the public key in use wasn't intended to be
used by a completely different name.  You still can be completely
assured that whoever is listening on the other side, be it Bob or Eve,
could convenience you that they're both Bob and Eve or whatever name you
want them to be.  They have the private key to prove it and that's all
you can care about.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 13 May 2008 23:16:10 -0400

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wes Hardaker
> 
I agree.
An "SNMP application" makes the call to IsAccessAllowed, and the
application gets the answer from the ACM. No other subsytem or model
ever talks directly to an access control model.

Access control in the RFC3411 architecture is deliberately
**advisory** - it is up to the application to ask whether access is
allowed, and the application can decide what to do with the answer.
This was very deliberate.

There is no binding between the IsAccessAllowed answer and the actual
access to the underlying instrumentation. Even if IsAccessAllowed says
"no", an application MAY still decide to access the underlying
instrumentation.

For a minimal device such as a printer that has only notifications
such as "out of paper" and "out of ink", a specific SNMP application
could be written that performs no access control, because the only
notifications are not sensitive. A specific application in the same
printer might accept an operation to clear the "out of XXX" status
value, without performing access control. The working group discussed
these specific cases, amongst others, when doing the architecture
design.

There is no architectural binding between an applications' use of ACM
and the security model. Having the security check that this is the
same securityName used for ACM would violate the modularity of the
subsystems (and would disallow the minimal printer applications). 

On the other hand, specific standard applications MAY imply or require
in their elements of procedure that the securityName is the same
between the ACM and the SM. I think this is the case for the NO
described in RFC3413 section 3.3, in paragraph (2).

> tp> So that is what the NO should be checking and what VACM 

I haven't hunted this one down, but I believe it is incorrect to state
that an **ACM** should have authentication credentials in its tables.
Authentication is the domain of a security model, so authentication
credentials belong in the tables of a security model, as is done in
RFC3414. The configuration of the tables of an application, such as an
NO, might contain administratively-set pointers (such as the
securityModel, securityName, securityLevel indices) to lookup the
appropriate security credentials in the tables of the security model,
to use for the notification target, as is done in RFC3413. 

I think it is inaccurate to refer to an NO as an ssh client. An NO
does not do authentication or establish a transport connection; it
specifies which securityModel and securityName and securityLevel
should be used when authentication is performed, and which transport
address is used when transport is established. The application should
know nothing about the nature of the authentication credentials.

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 May 2008 20:42:20 -0700

>>>>> On Tue, 13 May 2008 23:16:10 -0400, "David Harrington" <[email-masked]> said:

DH> There is no binding between the IsAccessAllowed answer and the actual
DH> access to the underlying instrumentation. Even if IsAccessAllowed says
DH> "no", an application MAY still decide to access the underlying
DH> instrumentation.

Good point that I forgot, thanks for catching it.

DH> For a minimal device such as a printer that has only notifications
DH> such as "out of paper" and "out of ink", a specific SNMP application
DH> could be written that performs no access control, because the only
DH> notifications are not sensitive.

One might argue it's still performing it "architecturally"; it's just
always returning "ok".

DH> There is no architectural binding between an applications' use of ACM
DH> and the security model. Having the security check that this is the
DH> same securityName used for ACM would violate the modularity of the
DH> subsystems (and would disallow the minimal printer applications). 

Actually there would be some security gain there that wouldn't break the
applications you're talking about; but I won't dive into that here as
it's out of scope.

DH> On the other hand, specific standard applications MAY imply or require
DH> in their elements of procedure that the securityName is the same
DH> between the ACM and the SM. I think this is the case for the NO
DH> described in RFC3413 section 3.3, in paragraph (2).

I'd like to reword that before I agree with it:

... require in their elements of procedure that the securityName is the same
between the ACM and   the SM
                    ^
                    output of

Remember, I never said that the SM wasn't responsible for passing on the
securityName.  I only said that it could do it in a number of ways; one
of which could be a lookup table for which the keys might be some other
aspect of the packet/protocols involved (such as the keying material and
possibly parameters passed to it via the application just as the USM
user name to use is currently passed to it via the application).

I did *not* ever state (or mean to imply) that the securityName chosen
wouldn't be agreed to by the SM.  Only how that mapping was done.

>> 2) The initiating application (NG or CG) is the one that 
>> actually tells the remote side who it is when USM is used.  More
>> importantly, it really says "we're both Bob; I can prove I'm Bob and
>> please prove you are too when you send a response".  The CR and NR
>> merely use this fact to look up the proper keying material to use to
>> ensure that they can be Bob.

DH> I haven't hunted this one down, but I believe it is incorrect to
DH> state that an **ACM** should have authentication credentials in its
DH> tables.

I never meant to say that if I did, but I could see how you interpreted
it that way.  Specifically, the application does say "I'm Bob" and also
specifies other parameters like "and my engineID for this message is
XXX" but you're right, it's up to the SM to find the right key.

I was, unfortunately, combining the SM and the application into
"application" in the above statements and I do apologize for that.  My
bad.  (I was thinking of the application has a whole, stack included, as
I wrote the above not the "CG, CR, ..." type application above the stack).
The SM does hold the "keys".

DH> I think it is inaccurate to refer to an NO as an ssh client.

Also true; the NO itself is not.  For the NO to be useful it has to send
the message out to the point where the SM and the transport deal with it
and you're right, from an architectural standpoint it's the transport
that is the client.

However, I don't think my terminology blunders invalidate my points at
least :-)

---

From: "David Harrington" <[email-masked]>
Date: Wed, 14 May 2008 01:01:50 -0400

> From: Wes Hardaker [mailto:[email-masked]] 
[...]
> between the ACM and   the SM

Your rewording is incorrect because it presupposes this is an incoming
message. 
RFC3413 section 3.3 is actually about Notification Originator
Applications.
In either direction, it is the design of the application that makes
any binding between the securityName used for ACM and SM. 
For incoming, an application design MAY use the output of the SM when
invoking the ACM.
For outgoing, the application chooses the securityName, and the design
MAY use the same one for both ACM and SM purposes.

In the SNMPv3 WG, we worked to eliminate the explicit binding between
a security model and an ACM. There were too many issues caused by
(often-invalid) assumptions made by access control designs, about the
"strength" of authentication, integrity, and confidentiality provided
by different algorithms. These "strengths" could easily change over
time, and the strength of algorithms depends too much on the
environment to which they are being applied.
The SNMPv3 approach differed from the earlier monolithic SNMPv2p,
snmpv2u, and snmpv2* designs which had explicit sharing of information
between the message security and access controls, including knowledge
of the specific algorithms and credentials used.

The SNMPv3 approach uses layered security. In SNMPv3, we broke the
architecture into separate subsystems (layers, more or less). The
security model provides message security at a lower layer than the
using application; the interface to upper layers (the applications)
only provides the model used, a human-readable handle for the
principal authenticated, and an indication of security services
provided. All information about the specifics of the algorithms or
credentials used at lower layers is deliberately hidden from the upper
layers. This approach permits algorithm agility, and eliminates
assumptions about the strengths of different algorithms when
configuring access controls. (The ACM does consider the expected
strength of the security model.)

> user name to use is currently passed to it via the application).

I disagree with this. The application does not pass the USM user name
to use; it passes the securityName to use, and the security model to
use to determine how to translate the securityName to a
security-model-specific credential. USM happens to use the
securityname to lookup the corresponding USM user name in a table to
determine the credentials. The application layer does not know how the
lower-layer security model translates from securityName to an
SM-specific credential (for outgoing) or how the lower-layer security
model translates from an SM-specific credential to securityName (for
incoming).

> I never meant to say that if I did, 

You didn't. Tom said the public key should be stored in VACM tables.
You didn't seem to notice that.

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 14 May 2008 10:14:51 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 13, 2008 11:11 PM
Subject: Re: [Isms] ISMS/SSH and notifications

> used by a completely different name.

Yes, I agree. I am left wondering, more with the second point than the first,
if this is good enough security and thinking that perhaps it is not.  I see this
as the crux of the issue.

In passing, SSH (unlike TLS) does have a ready made session identifier that is
cryptographically bound to the session so if we do take data from the session
setup for use in the ways you describe, then that is what I think we should use
(see draft-williams-sshv2-channel-bindings-00.txt)

Tom Petch

>                                                            You still can be
completely

---

From: "tom.petch" <[email-masked]>
Date: Wed, 14 May 2008 10:23:08 +0200

<inline>
Incidentally I am using Notification Originator rather than Notification
Generator but I think we understand each other.

Tom Petch

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "David Harrington" <[email-masked]>
Cc: "'Wes Hardaker'" <[email-masked]>; "'tom.petch'"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, May 14, 2008 5:42 AM
Subject: Re: [Isms] ISMS/SSH and notifications

> Good point that I forgot, thanks for catching it.

Yes, I agree that there is no binding but ...

> DH> described in RFC3413 section 3.3, in paragraph (2).

yes, that is my thinking too so while there is no binding, there is some
linkage, I - we? - do expect there to be one common securityName for
the'transaction'.

> XXX" but you're right, it's up to the SM to find the right key.

I was suggesting, somewhat tongue in cheek:-), that the public key would be in
the tables because that is the identity, as well as the security credentials

As you imply, with certificates (as in TLS), then there is a clear separation of
the identity (host name, MAC address, IP address etc) and the credentials that
authenticate the assertion thereof.  With just a public key, then that is in a
sense doing double duty, as identity and
authentication thereof.  You could say that the private key is the credential or
that a message encrypted with the private key is or ....  Whatever, what is
comes down to we do not have a satisfactory identity for the ssh host, one that
we can authenticate.

> DH> I think it is inaccurate to refer to an NO as an ssh client.

Yes, I should have said something like ' the engine on which the NO runs as ssh
client'.  My point was really that if the engine on which the NO runs becomes
the ssh server, then, as emerged in the interim meeting some time ago, life is
simpler; this is my preferred option.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 14 May 2008 09:59:42 -0700

>>>>> On Wed, 14 May 2008 12:02:35 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> Please drop right now any notion that SNMP should track, identify, or
JH> authorize any engine based on SSH public keys.

I never said that directly (well, I probably implied it).  What I said
was that the client has to know the credentials of the other side in
order to protect against mitm attacks.  The client will have to specify
somehow which remote authentication mechanisms and credentials are
trusted.  To not do this would be to blindly allow ssh to always
perform a leap of faith which is very insecure and prone to mitm issues.

JH> To do so would be a serious abstraction violation and would defeat
JH> or seriously impair the purpose of ISMS, which is to allow operators
JH> to authenticate SNMP using their existing infrastructure.

This may well be done through existing known hosts and key material.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 14 May 2008 12:02:35 -0400

> The *client* credential is a public key.  As is the servers.

Not necessarily.  SSH supports key exchange methods in which the server is 
authenticated by a mechanism other than a public key, as well as methods in 
which public key crypto is used, but the server is not identified by a 
specific public key.  It also supports a wide range of user authentication 
methods which are not based on public keys.

Please drop right now any notion that SNMP should track, identify, or 
authorize any engine based on SSH public keys.  To do so would be a serious 
abstraction violation and would defeat or seriously impair the purpose of 
ISMS, which is to allow operators to authenticate SNMP using their existing 
infrastructure.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 14 May 2008 10:34:41 -0700

>>>>> On Wed, 14 May 2008 10:23:08 +0200, "tom.petch" <[email-masked]> said:

tp> yes, that is my thinking too so while there is no binding, there is some
tp> linkage, I - we? - do expect there to be one common securityName for
tp> the'transaction'.

I would argue that for a symmetric cryptography using SM like USM we'd
expect them to be the same.  I don't necessarily think that's true for
an asymmetric system like any public/private key system.  What we use to
identify ourselves as the "client" will be differently named than what we
use to identify the remote side.  Naming wise, no, I don't think they
need to be the same (since it doesn't buy you anything).  As a client I
may be configured to be "wes" but I'm not expecting to talk to "wes" at
the other end.  I'm expecting to talk to "bob".  

Most importantly, I'm expecting to talk to another transport end that
meets my security requirements for proof of identity requirements.  SSH
proves that sufficiently for me to trust it.  Thus I can choose to call
the remote side "bob" (or "wes" too if you really wanted to) as long as
the more important aspect is still true: they've cryptographically shown
me I've connected to the right place given the message I want to send.
I honestly don't care about the name; I care about the cryptography.

tp> Whatever, what is comes down to we do not have a satisfactory
tp> identity for the ssh host, one that we can authenticate.

I'm saying you do.  You can all it whatever you want.  Specifically, you
can use the name you assigned it when you are pointing to your local
configuration that says "use this SSH transport to talk to the remote
side".  The important security bits that MUST be agreed upon have been
taken care of by the SSH layer.  I don't see any benefit to throwing up
your hands and declaring the whole thing off just because SSH doesn't
offer an adequate securityName for the server side of the connection.

Either pull it from the configuration that specified the session in the
first place or pull it from the SSH system's configuration, such as the
offered host name.

This exact problem is likely to bite us with many public/private type
transport layers.  Somehow I think we'd rather figure out a workable
solution than throw up our hands and declare that USM is better.
Clearly that's been shown that it isn't in the terms of the people using
the systems.

tp> My point was really that if the engine on which the NO runs becomes
tp> the ssh server, then, as emerged in the interim meeting some time
tp> ago, life is simpler; this is my preferred option.

That may be an adequate solution too, but the transport doesn't work
that way if the NO needs to open the session.  And I don't think any
solution that requires a management connection first as the only way to
deliver a notification is a suitable one for all environments.

(I have no objection to allowing a reverse mapping so the manager needs
to connect; in fact I've even discussed MIB objects that would be
required to support that)
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "tom.petch" <[email-masked]>
Date: Thu, 15 May 2008 18:52:57 +0200

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>; "tom.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 14, 2008 6:02 PM
Subject: Re: [Isms] ISMS/SSH and notifications

> ISMS, which is to allow operators to authenticate SNMP using their existing

I disagree; if the only way we have of identifying the ssh server, somewhere on
which a Notification Receiver is running, is a public key, and if the use of
public keys is sufficiently widespread to make this viable, then it is an option
we should seriously consider.  I do not agree with Wes's first option (give
up:-), do not see any attractive option but do believe we should find an option
and move on.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Thu, 15 May 2008 16:13:44 -0400

Hi,

I think this discussion has gotten off-track because there are some
invalid assumptions floating around, due to using the terms loosely
and not keeping the interfaces in mind.

I will correct a couple here. I will correct others in other emails.

> > the CR and NG engines to have done the right thing security wise.

Actually, that is not quite true. It is true that VACM does not care
which algorithm within a security model was used to perform
authentication, but it does care which securitymodel was invoked to do
the job. 

There is a big difference between the community security model, the
USM security model, and the TSM security model, so there may be a big
difference between community/dbh, USM/dbh, and TSM/sbh.

The IsAccessAllowed() ASI passes certain values, and it is expected
that those values will somehow be used to index the access control
tables. As with almost everything in SNMPv3, it is expected that
securityModel, securityName, and securitylevel are likely to be used
as indices to security information, and contexts and OIDs will be used
to reference data subsets.  

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security Model in use
     IN   securityName              -- principal who wants to access
     IN   securityLevel             -- Level of Security
     IN   viewType                  -- read, write, or notify view
     IN   contextName               -- context containing variableName
     IN   variableName              -- OID for the managed object
          )

--

I have concerns that Wes's email was misleading about how the target
table and parameters table are used. Please look at Appendix A in the
TSM document to see how the values from these tables are used by TSM.
Wes's email does not follow the Appendix, and fills in some fields
incorrectly, like roughly specifying a transport model (SNMP/SSH)
where an explicit securityModel enumeration is definitely called for. 

To repeat myself: as with almost everything in SNMPv3, it is expected
that securityModel, securityName, and securitylevel are likely to be
used as indices to security information. The securityModel/Name/Level
tuple will be needed to index into other tables as the processs goes
through the elements of procedure.

--

I think we will get into trouble if we keep talking about the NG and
NR doing security and transport things. The NG (actually it should be
NO) and the NR are applications. Transport model processing should not
be aware of what the operation is, because it only gets the wholeMsg
already formed, and possibly with the PDU encrypted by the security
model; the modularity of SNMPv3 means the transport model does know
what operation the message contains, and it should never look into the
PDU. 

It is an RFC3411-architectural-layer violation to have the transport
model know the operation type.

I know Wes's implementation may not follow the architectural layering
of the standard, but RFC3411 is the standard, and should abide by it
in our designs, or explicitly (not by sloppiness) re-architect SNMP.

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 15 May 2008 17:34:08 -0400

Hi,

I think the starting point of this discussion has some incorrect
assumptions and that could be causing some problems, so I would like
to correct some of the starting point for configuration. I am paying
close attention to the layering called for by the architecture,
because it is important to correctly understanding how things get
done.

The TSM describes how to work with the ParamsTable and the TargetTable
in Appendix A of the TSM document. Wes's examples showed other values.

snmpTargetParamsSecurityModel would not be configured with (SNMP/SSH
Mapping). It should be configured with the securitymodel to be used,
not the transport model to be used. The securityModel to work with our
SSH design should be the TransportSecurityModel (TSM).

This is a really important thing to know because it is the
securitymodel specified in snmpTargetParamsSecurityModel that knows
how to take the securityModel and securityLevel specified in
snmpTargetParamsSecurityName and snmpTargetParamsSecurityLevel and map
them to the appropriate security credentials.

The Transport Security Model will determine from the transportDomain
(which should have a value of snmpSSHDomain) that the SSH transport
model should be used. For an outgoing message, it will check for an
existing securityStateReference. If the application is requesting that
a notification be sent, there will not be an existing
securityStateReference (which are used to ensure responses have the
same security as the request). 

The TSM will create a tmStateReference (the structure used to pass
info between the SM and the TM), and put in the securityName and
securityLevel. Then it will create the wholeMmessage from the parts
provided by the MPM and a zeroed-out securityParameter field, and give
that back to the MPM. 

The MPM will pass the request to send the wholeMsg to the specified
transport address (and pass along the tmStateReference).

Note that up to this point, nobody has looked to see if there is an
existing connection. That's important because it is not their job to
do so. The six step process described in Wes's example is wrong for
that reason.

The TM (in this case the SSH-TM) will take the address provided by the
MPM, plus the securityName and Level, and determine how to convert
that into SSH parameters. Then it will check whether a connection
exists that matches those parameters. It does this in an
implementation-dependent manner, but it probably uses the address and
the securityname and the securityLevel to see if the local
configuration datastore has a record of such an existing connection.
It is implementation-dependent whether it checks an SNMP datastore  (a
MIB) or an SSH datastore (such as a ./ssh_config and an ssh_keys
directory). Maybe it doesn't check at all, but simply says "hey SSH,
send this for me, will you? and SSH finds an existing connection, or
establishes a new connection, and sends the message, or the SSH layer
returns an error. A lot is going to depend on the APIs provided by the
SSH implementation one is using.

The really important part here is that the application knows nothing
of the transport processing except the address and domain, or the
security processing except the Model/Name/Level. The security model
knows nothing of the transport-specific processing, and the MPM knows
nothing of the transport-specific processing. Only the transport model
really knows about the processing for that transport. 

And if the transport layer (SSH) is providing the authentication, then
only the transport layer really know what processing occurs to do that
authentication. Only SSH knows whether authentication was done using
public keys or passwords or certificates or whatever. 

Now, if we want to store client credentials locally so we have the
necessary credentials to initiate an SSH session for notifications
when no connection is available, we can define a standardized
datastore to put that into (define an SSHTM-specific MIB as part of
the transport model). But before we decide the WG should do this we
should see if the SSH configuration datastore already has a mechanism
for storing such credentials, such as an ssh_keys directory. We should
also be careful to separate the SSH-MIB from the SSHTM-MIB, since
having an SSH-MIB would allow SSH used for other purposes to be
managed as well.

So can we reach consensus that the issue we need to deal with is not
the TARGET-TABLE or PARAMS-TABLE, and not the application or the
security model? 

We should be talking about how the SSH-TM talks to an underlying SSH
implementation (whichever one that happens to be) in a standardized
manner, including implementation-dependent magic. We also need to
figure out how to bridge the gap from what we have for info
(securityName and Level and transport domain and address) to what SSH
needs to initate an outgoing connection. And we need to consider, for
incoming messages, how we get from what SSH has (user names, host
keys, or whatever) to what we need to pass up the stack (securityName
and Level and transport domain and address). 

Personally, I think we need to identify the securityModel that the TM
expects will process the provided securityName and Level, rather than
leave it to the MPM to decide which SM to use, but we can discuss that
again later.

dbh

> Sent: Thursday, May 01, 2008 8:17 PM
> To: [email-masked]
> Subject: [Isms] ISMS/SSH and notifications
> 
> 
>                                                       2 = 
> userPassword,
>                                                       3 = 
> hostPublicKey
>                                                       2 = 
> userPassword,
>                                                       3 = 
> hostPublicKey
>                                                       should be
pulled
>                                                       from 
> ssh auth types?)
> notifications
> model and

---

From: <[email-masked]>
Date: Fri, 16 May 2008 13:04:35 +0300

Wes Hardaker wrote:

> I would argue that for a symmetric cryptography using SM like USM
> we'd expect them to be the same.  I don't necessarily think that's
> true for an asymmetric system like any public/private key system.
> What we use to identify ourselves as the "client" will be
> differently named than what we use to identify the remote side.
> Naming wise, no, I don't think they need to be the same (since it
> doesn't buy you anything).  As a client I may be configured to be
> "wes" but I'm not expecting to talk to "wes" at the other end.  I'm
> expecting to talk to "bob".
> 
> Most importantly, I'm expecting to talk to another transport end
> that meets my security requirements for proof of identity
> requirements.  SSH proves that sufficiently for me to trust it.
> Thus I can choose to call the remote side "bob" (or "wes" too if you
> really wanted to) as long as the more important aspect is still
> true: they've cryptographically shown me I've connected to the right
> place given the message I want to send.  I honestly don't care about
> the name; I care about the cryptography.

I agree; if the Notification Originator side (probably either SSHTM or 
SSH module) has information mapping the local securityName (given the 
the NO application, and used locally for VACM checks) to the public 
host key that the SSH server must authenticate with, then we seem to 
have sufficient proof for sending the notification.

The fact that there could be multiple local securityNames (possibly
having different access rights in VACM) mapping to the same SSH server
host public key doesn't make this proof insufficient.

(I.e., if configured so, notifications with securityNames "alice" and "bob"
could be sent to the same transport endpoint (SSH server), authenticating 
with a single host key.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 16 May 2008 13:40:46 +0300

Hi,

Thanks for a good explanation! I think there's a way to slightly
refactor Wes's proposal to make it consistent with the
architecture (since I'm making only small adjustments
to Wes's text, I'm not quoting it all).

When a PDU is sent, SSHTM will get transportAddress and
securityName (and other information). If it needs to open a new
connection, it will need some local information (which isn't
necessarily a MIB table) to do so. This is almost the same as
snmpSSHParametersTable in Wes's text, except that we need to index
it by (transportAddress, securityName) and not parameter name
(which isn't visible in SSHTM, right?).  So the table would look
something like this:

snmpSSHOutgoingTable:

  index:
     snmpSSHTransportAddress     192.0.2.1:162 
     snmpSSHSecurityName         "Alice"
  columns:
     snmpSSHUserName             "Adam"   (I say "I'm Adam")
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword,
                                           3 = hostPublicKey
                                           ... enum list)
     snmpSSHUserKeyPair          ++++     (the public/private
                                           key pair to use if 1)
     snmpSSHUserPassword         ++++     (the passphrase to
                                           use if 2)
     snmpSSHRemoteHostPublicKey  +++      (the public key
                                           expected from peer)

Most importantly, this same table would be used when sending PDUs for
command generator -- since SSHTM isn't supposed to know what's inside
the PDU.

(Although there's one difference in how the table would be
typically configured; on management stations, a common
configuration would use same string in both snmpSSHSecurityName 
and snmpSSHUserName, while on agents, they would be typically
different.) 

The side acting as an SSH server also needs some information 
(which might not be a MIB table); this is similar to the 2nd
snmpSSHParametersTable in Wes's text, except we index it 
by user name:

snmpSSHIncomingTable:

  index:
     snmpSSHUserName             "Adam"   (peer says "I'm Adam")
  columns:
     snmpSSHSecurityName         "adam"   (this is what gets
                                           passed outside SSHTM)
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword, ...)
     snmpSSHUserPublicKey        +++      (the public key to use if 1)
     snmpSSHUserPassword         +++      (the correct password if 2)

(In this setting, it's possible that there exists multiple 
snmpSSHOutgoingTable entries that contain the same
snmpSSHRemoteHostPublicKey -- but I don't think this is really
a big problem.)

Would this be consistent with the architecture?

Best regards,
Pasi

> Behalf Of ext David Harrington
> Sent: 16 May, 2008 00:34
> To: 'Wes Hardaker'; [email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 16 May 2008 10:01:51 -0400

> Sent: Friday, May 16, 2008 6:41 AM
> To: [email-masked]; [email-masked]

Yes. and we would define this within the SSHTM specification,
presumably.
If we wanted to develop one that could work for multiple transports,
with possible support for different securitylevels, then we could add
transportdomain and securityLevel to the index so we could
differentiate the different address types, and have connections
with/without privacy (for example).

The indexing is definitely SNMP-related. The other columns seem to be
purely SSH-related. This raises the question, if we were to do a MIB,
whether the two parts should be modeled separately, with a pointer in
the SSHTM table to the relevant row (or whatever) in the SSH
datastore. What we need for ISMS is the SSHTM side of the table, to
get a mapping to an SSH-specific datastore.  

> and snmpSSHUserName, while on agents, they would be typically

You used "management station"; did you mean SSH server? The SNMPv1
distinction between manager and agent went away with the RFC3411
architecture. From an RFC3411 architectural perspective, both ends are
just entities that can include any of the applications. The TM, SM,
MPM, and dispatcher don't know or care what role the entity is acting
in, and in the case of a manager-to-manager Inform or agent-to-agent
Inform, there is no manager/agent pairing.  We need to avoid
assumptions that TM and SM and MPM processing for manager and agent
are different; the difference only happens inside the application
layer. 
 
I would like to reach consensus on separating the SSHTM table from the
SSH-specific stuff, with a pointer in the SSHTM table to a row in an
SSH table. That would allow us to get from the TargetTable to the
pointer in the SSHTM table. 

SSHTM table:

   index:
      snmpSSHTransportDomain      snmpSSHDomain
      snmpSSHTransportAddress     192.0.2.1:162 
      snmpSSHSecurityName         "Alice"
      snmpSSHSecurityLevel        authPriv
   columns:
      snmpTMCredentialsEntry      "27"

then we narrow the discussion to become purely an SSH client vs server
matter.
> snmpSSHParametersTable in Wes's text, except we index it 

Remember that requests, responses, and notifications are all outgoing
messages. (RFC3411 was designed to permit additional applications to
be added later if desired, possibly using new SNMP protocol versions,
so we shouldn't preclude the possibility there are other message types
as well.) What we know in the TM is what is passed via the ASIs.

If we need to use server-auth rather than user-auth for notifications,
then we need to tell operators they should configure the paramstable
for notifications with the appropriate host identity. Assume user
"Alice" is located at host "gandalf". If the admin wants to send traps
to host gandalf, rather than specifically to Alice, then put an entry
for gandalf in the target/paramstable configuration.

To support ACM, add gandalf to the userToGroup table in VACM (or
suitable table for other ACM). This might be the same or different
group than Alice belongs to.

Then, in the SSHTM table, we have an entry for Alice and one for
gandalf. These point to SSH entries for "adam" and "gandalf". (I
changed the indexing just to show that these values are not
semantically important. Human-redaable tags could still be used to
make it easier for operators in the general case)

When securityname=Alice, such as for get-requests, that will map to
user-auth for "adam". When securityname=gandalf, that will map to
host-auth for gandalf.

>      snmpSSHIndex                "27"   

>      snmpSSHCredentialType   1        (1 = userPublicKey,
>                                        2 = userPassword,
                                         3 = hostPublicKey,
                                             ...)
>      snmpSSHuserName          "adam"   (user anme when using
user-auth)

>      snmpSSHcredential        +++      (user public key to use if
type=1)
                                         (user password if type=2)
                                         (host public key if type=3)
> 
> 
>   index:
>      snmpSSHindex                "28"   
>   columns:
>      snmpSSHUserCredentialType   3        (1 = userPublicKey,
>                                            2 = userPassword, 
                                             3 = hostPublicKey,
                                             ...)
>      snmpSSHHostName         "gandalf"   (this is what gets
>                                            passed outside SSHTM)
>      snmpSSHcredential        +++      (user public key to use if
type=1)
                                         (user password if type=2)
                                         (host public key if type=3)

--

This table can be expanded for different types of credentials using
AUGMENTS if necessary. I think the union discriminator we are using is
inappropriate; We need a column for authtype (user/host) and for
authcredentials (public key, password, etc., because user-auth
supports multiple credential types.) 

Ideally, the SSH credential is really only in the SSH confguration,
not in the SNMP configuration. So we might be able to get by with an
SSH table containing only the index value, user- or host- auth flag,
and an (implementation-dependent) index into the associated SSH config
that would contain the "adam" user-auth credentials and the "gandalf"
host-auth credentials. 

OR, if we are really lucky, the index from the SSHTM table points
directly to the SSH config without needing our own SSHTable.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 May 2008 12:32:56 -0400

>      snmpSSHUserCredentialType   1        (1 = userPublicKey,

If you're going to do this, the correct thing to record is not a made-up 
"credential type" number, but an ssh user auth method name.  The problem is 
that then you need some way to record information about the credentials to 
be used (which may be one or more keys, or just a reference to something), 
and that's going to be specific not only to the method being used, but also 
potentially to the implementation and how it is configured.

For example, it's fairly straightforward that "publickey" requires a key 
pair of some sort, and "password" requires a password, but what does 
"keyboard-interactive" require?  The answer is that it depends on how the 
server implements keyboard-interactive and what questions it is going to 
ask.  Similarly, what does "gssapi-with-mic" require?  Well, at a minimum 
it requires a GSS-API mechanism OID, which is really not part of the 
credential but a sub-negotiation parameter, like a public key algorithm 
identifier.  And then it's going to require some mechanism-specific 
credentials; for example, if you're using the Kerberos GSS-API mechanism, 
then you need some way to get a Kerberos ticket, which might involve 
knowing a symmetric key, but might not, depending on your Kerberos 
deployment.

In other words, this is difficult to standardize, and if we're going to 
try, we had better leave holes into which it is possible to shove whatever 
kinds of credentials are required, instead of telling someone that he can't 
use SNMP with his existing authentication infrastructure (remember: this is 
the goal of ISMS) because we didn't anticipate what form of credentials his 
NO's would have.

In addition, while I don't think this is very common in practice, the SSH 
protocol allows servers to require _multiple_ authentications with 
different methods before granting a client access.  So you probably 
actually need a set of (method, credential) tuples.

>      snmpSSHRemoteHostPublicKey  +++      (the public key

Again, you can't assume a public key is involved.  Not all SSH key exchange 
mechanisms identify hosts by public keys.  Some may use certificates, or 
underlying security mechanisms that do not involve public keys at all. 
What you actually end up needing here, I think, is a set of (keyex-method, 
keyex-data, key-type, public-key) tuples, where either of keyex-method or 
key-type can be "don't care".  The implication is that the host is 
legitimate if there is a tuple for which

- keyex-method matches the key exchange used
- keyex-data matches the host in some key-exchange-specific way
- key-type and public-key match the key presented by the host

For example, the list for the sshd running on my desktop machine might look 
like this:

(*,*, 'ssh-rsa', 'AAAA...GR/E=')
(*,*, 'ssh-dss', 'AAAA.../HRU=')
('gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==', [email-masked]',
 *,*)

The first two lines match my server's two public keys; the third allows use 
of GSS-krb5 regardless of host key, as long as the service name matches.

On the SSH server side, I think you have a much easier time of it, because 
SSH does more of the work for you.  Once an SSH session is set up, the SSH 
server knows the authenticated and authorized user name of the client.  How 
the authentication mechanisms work and how the server decides what 
credentials are adequate to use what username are not things I believe are 
in scope for ISMS.  It might be appropriate for some group to define an SSH 
server MIB someday that allows some configuration of this policy, but I do 
not believe that is within our charter and I'm not convinced enough of the 
SSH community is engaged in this group to get it right.  Fortunately, we 
don't have to -- simple use the SSH user name as the SNMP securityName, as 
we had previously agreed, and the problem is solved.  If people think it is 
necessary to introduce a mapping from SSH user names to SNMP securityNames, 
I won't object.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 May 2008 12:44:31 -0400

> then we narrow the discussion to become purely an SSH client vs server

I agree with this approach in principle, as it puts the SSH-specific, 
mechanism-specific, and implementation-specific bits where they belong. 
However, I'm concerned that simply mapping to a "row number" is not very 
helpful, because there is no SSH MIB, there is no such table, and no SSH 
client implementation identifies servers by small positive integers.

At least one major SSH implementation does support a database such as you 
envision, where each entry can contain complete information about the 
transport address of the server, what security algorithms to use, what 
public keys to expect the server to present (really an index into another 
database), and even what user name and authentication methods to use. 
OpenSSH allows all of this information to be stored in its configuration 
file on a per-server basis, and the "host name" you type on the command 
line is really an index into this database, with appropriate default values 
being computed if no entry is found.

So, I think we would be much better off if snmpTMCredentialsEntry were a 
string, rather than simply a number.  I can certainly see an implementation 
which simply passes this string to the ssh client, which looks it up in its 
config file but also handles "[email-masked]:162" just fine, provided there 
is a suitable entry in the host key databse for "192.0.2.1:162".

-- Jeff

---

From: "David Harrington" <[email-masked]>
Date: Mon, 19 May 2008 13:15:39 -0400

Hi,

I agree. Note that I have the number "27" in quotes - it is a string. 
I also said "(I
changed the indexing just to show that these values are not
semantically important. Human-redaable tags could still be used to
make it easier for operators in the general case)"

I used a number in my example only so that we would not assume any
semantic value to the index, like "oh, this is the user's name" such
as was likely when using indices like "adam".

While I did refer to "rowe number in the SSH table", I agree that we
should not assume any such database format. How the "index" gets
converted into something meaningful to an SSH implementation is
implementation dependent. I believe this "index into some other thing"
should be a string (probably an OCTET STRING rather than a Display
String or SnmpAdminString, which have limitations). 

dbh

> From: Jeffrey Hutzelman [mailto:[email-masked]] 
> Sent: Monday, May 19, 2008 12:45 PM
> To: David Harrington; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Tue, 20 May 2008 11:54:44 +0300

David Harrington wrote:

> presumably.  If we wanted to develop one that could work for
> multiple transports, with possible support for different
> securitylevels, then we could add transportdomain and securityLevel
> to the index so we could differentiate the different address types,
> and have connections with/without privacy (for example).
> 
> The indexing is definitely SNMP-related. The other columns seem to
> be purely SSH-related. This raises the question, if we were to do a
> MIB, whether the two parts should be modeled separately, with a
> pointer in the SSHTM table to the relevant row (or whatever) in the
> SSH datastore. What we need for ISMS is the SSHTM side of the table,
> to get a mapping to an SSH-specific datastore.
> 
> > 
> > snmpSSHOutgoingTable:
> > 
> >   index:
> > Most importantly, this same table would be used when sending PDUs
> > for command generator -- since SSHTM isn't supposed to know what's
> > inside the PDU.
> > 

I agree that the processing should be the same; by "management station", 
I simply meant an SNMP entity that (in this context) doesn't usually call 
isAccessAllowed(), while the "agent" does that all the time (for both 
commands and notifications).

> then we narrow the discussion to become purely an SSH client 
> vs server matter.

This would be the table used when SSMTM acts as SSH client.  When it
acts as SSH server, the information needed (and how it's indexed) 
is different -- see more below.

> as well.) What we know in the TM is what is passed via the ASIs.

Right, my choice of terminology was poor; "snmpSSHOutgoingTable"
should have been called "snmpSSHClientTable" and
"snmpSSHIncomingTable" is "snmpSSHServerTable". Even for ordinary
request/response, both are needed, and TM doesn't indeed know what 
the PDU is.

> group than Alice belongs to.

Yes, this would work. The admin could also decide that the host
authenticating with certain host key is "authorized representative" 
of Alice, and simply have single Alice entiry in VACM. This would
be purely a configuration issue -- in this case, the tables
could contain something like this:

-- table that's used when SSHTM needs to open a connection in
-- SSH client role
snmpSSHTMClientTable:
   index:
      snmpSSHTransportDomain        snmpSSHDomain
      snmpSSHTransportAddress       192.0.2.1:162 
      snmpSSHSecurityName           "Alice"
      snmpSSHSecurityLevel          authPriv
   columns:
      snmpSSHClientParameters       "27x"

snmpSSHClientParameterTable:
   index:
     snmpSSHClientParameters     "27x"
   columns:
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword,
                                           3 = hostPublicKey
                                           ... enum list)
     snmpSSHUserKeyPair          ++++     (the public/private
                                           key pair to use if 1)
     snmpSSHUserPassword         ++++     (the passphrase to
                                           use if 2)
     snmpSSHRemoteHostPublicKey  +++      (the public key
                                           expected from peer)

-- table used when SSHTM establishes a connection in SSH server role
snmpSSHServerTable:
   index:
     snmpSSHUserName             "alicek"  (peer says "I'm alicek")
  columns:
     snmpSSHSecurityName         "Alice"   (this is what gets
                                           passed outside SSHTM)
     snmpSSHServerParameters     "99foo"   (how the SSH client is
                                            authenticated)
snmpSSHServerParameterTable:
   index:
     snmpSSHServerParameteres    "99foo"
   columns:
     snmpSSHUserCredentialType   1        (1 = userPublicKey,
                                           2 = userPassword, ...)
     snmpSSHUserPublicKey        +++      (the public key to use if 1)
     snmpSSHUserPassword         +++      (the correct password if 2)

And I agree that of these tables, snmpSSHClientParameterTable and
SNMPSSHServerParameterTable don't have to be MIB tables, but could be
just data structures in the SSH implementation. Since the details
will anyway depend on the implementation (and as Jeffrey pointed
out, get complex for GSS-API and keyboard-interactive), that's 
probably the best solution.

Best regards,
Pasi

---

From: "David Harrington" <[email-masked]>
Date: Tue, 20 May 2008 08:39:51 -0400

> Sent: Tuesday, May 20, 2008 4:55 AM
[...]

[...]
> 
> The admin could also decide that the host

Here's the crux of the problem from the standpoint of editing the
secshell draft - how does the TM know it needs to open a connection in
a client role or in a server role? 

The information the TM is given includes transportDomain,
transportAddress, securityName, securityLevel, and a wholeMsg  which
is opaque to the TM. It is asked to send the message. It checks to see
if there is already a connection associated with (transportDomain,
transportAddress, securityName, securityLevel) and does not find one.
The PDU in wholeMsg might contain an outgoing GET-REQUEST or a Trap;
it doesn't know. 

How does the TM determine whether to open the new connection as a
client or as a server? Where in the system is that decision made? what
information is needed by the module making that decision? which
subsystem *has* the necessary information to make that decision? 

If an existing connection is available, should the TM use it? Does the
TM need to know in which direction that connection was opened, i.e.
does it need to know whether it is acting as a client or server to
reuse the connection? Do the security properties differ if the TM's
role is client or server? Is the TM the right place to make that reuse
decision - it is obviously the only module that understand SSH
client/server roles so it appears that it must, but if the security
properties are different, which module should be making that decision
(or should it be the admin)?

And then, Should these decisions be admin-specified deployment
decisions (e.g., in a MIB), implementation decisions, or hard-coded
model-specific decisions?

The information below requires the client/server decision be made
first, so we know which tables to look in.

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

---

From: "tom.petch" <[email-masked]>
Date: Tue, 20 May 2008 14:38:34 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, May 16, 2008 4:01 PM
Subject: Re: [Isms] ISMS/SSH and notifications

<snip>
> for gandalf in the target/paramstable configuration.

I keep coming back to this because I see this as the 'open issue' - SSH
authentication is asymmetric - that remains stubbornly open while the rest may
be tricky but it is more along the lines of 'implementation detail'.

What is the host identity (or identifier)? (The public key?)

SSH (RFC4251) says
"Each server host SHOULD have a host key"
" The server host key is used during key exchange to verify that the
   client is really talking to the correct server."
"Two different trust models can be used.
    The client has a local database that associates each host name (as
      typed by the user) with the corresponding public host key....
    The host name-to-key association is certified by a trusted
      certification authority "

Wes seemed to be saying that once we have validated the public key, we can use
any securityName we like; you seem to be suggesting that the trust model uses
the SSH local database which is the SSHTM table and the host identity becomes
the securityName.

Where are Alice and Gandalf in this and what is the securityName used in the
ASIs and PDUs?

Please clarify.

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Tue, 20 May 2008 18:30:46 -0400

> Sent: Wednesday, May 14, 2008 1:35 PM
[...]
> Most importantly, I'm expecting to talk to another transport end
that
> I honestly don't care about the name; I care about the cryptography.
That sounds true as far as it goes.
But ...

All operations use the same transport security.
Some operations will go on to use access controls.
For those types of operations, the admins need to preconfigure an ACM.
To do that, they need to know the securityName that will be reported
by the transport model for a given principal. The transport model
declares who the incoming message was authenticated as being on behalf
of (regardless of whehter internally that principal is called bob or
wes), and this principal is who the operations in the message will be
done on behalf of.

So, while it is not necessarily important that the SSH sender and SSH
receiver agree on the securityName as long as they agree on the
cryptography, it is important that the secure transport model and the
operator doing ACM pre-configuration agree on the securityName for
that principal.

In a similar vein, the operator configuring the target and params
tables and ACM tables may have expectations of which authentications
will be performed (mutual authentication, client-only, or server-only)
to secure the message in transit, and the securityName specifies to
the secure transprt sender which principal should be authenticated.
While in our modular architecture, the ACM has no visibility into the
types of authentication performed by SSH, the admin does have
visibility to that information. The admin also has responsibility for
configuring SSH to determine which types of authentication are
required for the principal. So the params table, the ACM, the
transport model, and the SSH config need to agree on who the principal
is, whatever he is called. And if the authentication uses RADIUS, the
admin needs to somehow correlate the securityName with the identity of
the principal in RADIUS-speak as well.

If the "principal" in SSH is called something different than in SNMP,
that's fine, but we need to have a predictable translation so the
admin knows how the principal can be tracked through the different
translations that occur.

Of course, since the admin needs to configure the SSH and the AAA and
the target/pamas tables and the ACM on multiple systems, it really
would be helpful if the principal was identified using consistent
names across the nodes in the system, so if we make the securityNames
used by the sender and receiver consistent, we'll be doing our part to
help reduce confusion.

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

---

From: "David Harrington" <[email-masked]>
Date: Tue, 20 May 2008 13:07:09 -0400

Hi,

I answered this post explaining the need to maintain clarity about who
has what info at what point in the process.

Let me see if I can answer some of these questions more directly.
comments inline.

dbh  

> From: tom.petch [mailto:[email-masked]] 
> Sent: Tuesday, May 20, 2008 8:39 AM

For me the issue of assymmetry is about operator expectations,
application-level configuration, and application-level access
controls. If the admin configures "alice" to have certain permissions
in ACM for request-response traffic, will it be acceptable to that
admin to perform only host-level authentication when sending
notifications to alice?

Alice will only get notifications if alice is configured as a
notification target in the target and params mib tables. If the
asymmetry in access control is not acceptable to the admin, then don't
configure alice to get notifications.

Instead, the admin can configure the target and params tables to use
the securityName "gandalf" (or maybe more accurately, application "HP
Openview" at SSH address 192.0.1.297:162), and send notifications to
that principal rather than to the user-level princiapl alice, and then
you can configure "gandalf" or "HP OpenView" in the VACM tables, with
approrpiate application-level access controls for that securityName.

All of this is about the operator expectations and configuring the
application-level tables, including target-mib, params-mib, and VACM.
At this point in the process, it is not about configuring SSH-specific
parameters.

> What is the host identity (or identifier)? (The public key?)

Asking this means you have now moved down into the bowels of the
interface between the SSHTM and SSH.

> any securityName we like; 

Deep down in the transport model, we can define a mapping table to
translate from SSH-specific parameters to a security-model-independent
securityName that can be used elsewhere in the system as a label for
the authenticated identity, no matter how that identity was
authenticated, or what transport was used. The securityName cna be
anything an admin wants to preconfigure into the mapping table. The
preconfigured mapping table will be part of the SSHTM local datastore.

If we want to avoid requiring preconfiguration of a mapping table, we
can do an automatic translation, such as by using the identity
function, to take some unique identifier for the authenticated
identity from the SSH layer and "plugging it into" the securityname
(for incoming messages).

For outgoing notifications, we almost certainly need to use
preconfiguration beecause the admin needs to decide who shluld get
notifications, but we might be able to automate the TM-to-SSH mapping
by using the opposite identity function for converting from a
securityName to SSH-specific parameters.

> you seem to be suggesting that the 
> trust model uses

I don't think mulitplexing is justified, so I don't really distinguish
between "alice" and "Alice". 

To me the difference between 'alice" and "gandlaf" is that alice is
authenticated using user-auth, and gandalf is authenticated using
host-auth only.

The securityName to be used in the ASIs depends on the direction. For
an outgoing message, the securityname is provided by the application
requesting a message be sent. For an incoming message, the
securityName can be determined either by a preconfigured mapping
table, or by an automated transform of something SSH-specific. Since
the securityName is meant to be meaningful only at layer 8, and simply
an opaque label referring to a layer 8 principal for SNMP processing,
I don't care what how the value is determined; the admin should care.
If we do an automated mapping, then we should try to make the
securityName something that would be meaningful at layer 8. 

The PDU contains no securityName. It never has.

You might mean "what securityName is passed in the message?"
The security parameters field in an SNMPv3 message are determined
solely by the security model, and in the Transport-security-model,
there is no securityName passed in the SNMPv3 message.

---

From: "David Harrington" <[email-masked]>
Date: Tue, 20 May 2008 11:02:00 -0400

Hi Tom,

Because we have modules and ASIs in the architecture, we need to keep
clear as to which module has access to what parameters at which point
in the process.

Unfortunately, Wes's examples did not so a good job of maintaining
that clarity; he used a bunch of "shortcuts" that I think are
confusing people who don't live-and-breath the architecural
modularity.

--
The securityName is an administratively-defined identifier for a
security principal. A principal might be a user, an application, a
host. We don't care, it is something the operator knows about, and
which is provided as a value that SNMP normally does not ever try to
interpret; from the SNMP perspective it is an opaque label for some
layer-8 thing the operator knows about. 

The main purpose of securityName is to have a
security-mechanism-independent value representing the principal. Part
of the original goal of securityName was to have a human-readable
value that could be used in system logs to record SNMP activity, such
as "daveH" or "HP OpenView" or the host machine "helpdesk machine #4".
In all cases, we should not need to know what authentication mechanism
was used for an operator to understand which principal the value
represents.

--
For outgoing messages:

The application specifies transportDomain, transportAddress,
securityModel, securityName, and securityLevel. 

What the transport model sees for parameters coming from the "rest of
the system" is an opaque wholeMsg and the 4-tuple (transportDomain,
transportAddress, securityName, and securityLevel), plus some
miscellaneous stuff not relevant to this conversation.

The transport model can use the passed 4-tuple to lookup, in an
implementation-dependent manner, the SSH-specific parameters to use
from the local SSH configuration datastore (such as a MIB or an
ssh_XXXX.conf file). Since the SSH config doesn't know about
securityName and securitylevel, and transportDomain, we will probably
need to have something that is SSH-TM-specific that translates from
the 4-tuple to an implementation-dependent value that can be used to
lookup connections/users/servers in the SSH config, as needed.

This translation is often referred to in our discussions as the
"mapping" between securityName and some security-specific parameters.
It may well be that in the SSH case, the thing that the 4-tuple maps
to is an SSH host-key.

The SSH config and operators know about host keys; nothing in SNMP
does.

If an operator used a host key as a securityName, then when
configuring the application-level datastore, such as the target-mib or
parameters mib, when that securityName reaches the SSH transport
model, the mapping from securityName to an SSH-specific configuration
data for a "host" might be rather simple, and would require no
preconfiguration by an operator; this could easily be automated as the
identity function.

--
For incoming messages:

SSH receives a message through some connection that has been
previously established. SSH authenticates whatever is on the other end
of the connection, to arrive at some type of SSH-specific identity.
The SSH layer negotiates whether the connection requires user-auth or
host-auth authentication, but either way it somehow comes up with an
authenticated identity.

Now that it has an SSH-identity, it needs to perfrm a mapping to an
SNMP 4-tuple - (transportDomain, transportAddress, securityName, and
securityLevel). In the SSH case, three elements of the 4-tuple ar
eobvious; the securityName is less obvious. The mapping from
security-specific parameters to a securityName could be done by having
an operator preconfigure a "mapping" table, but it would be nice if we
could automate the process to not require preconfiguration. 

If the incoming authentication is host-based, then, in Wes's proposal,
we presumably have a host key. If we simply set the value of
securityName equal to the value of the host key, we can have an
automatic mapping.

--
So it might be possible to use a host key as input (and output) for
the mapping algorithm for both outgoing and incoming messages, when
host-auth is used.

This is similar to using the SSH "user name" field as input and output
for the mapping algorithm for both incoming and outgoing messages,
when user-auth is used.

However, in both these cases, if you must know that SSH was used, then
I think that violates the original design goal of securityname.

--
This description does NOT include an analysis of the multiplexing that
Wes proposed. Personally I think that having to multiplex simply adds
complexity that is unnecessary. 

I hope this helps,
David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: <[email-masked]>
Date: Fri, 23 May 2008 14:02:10 +0300

David Harrington wrote:

> secshell draft - how does the TM know it needs to open a connection
> in a client role or in a server role?
> 

If there's no existing connection, and the TM needs to send a message,
it needs to open connection. In SSH, the party opening the connection
is always in the client role, so there's no decision needed.

> (or should it be the admin)?

I guess for e.g. Response PDUs, we usually get a tmStateReference that
identifies a connection -- if that connection still exists, that would
be used, right?

On the other hand, if transportAddress includes both the IP address
and TCP port number, a "client" connection (connection I opened)
wouldn't match a "server" connection (connection the other end
opened), because in the latter case, the (remote) source port number
isn't the well-known port, but some ephemeral randomly selected port.

(Using the same well-known port for both source and destination
wouldn't work in TCP.)

However, in this case, if we're sending a Response PDU, and the connection
identified by tmStateReference doesn't exist any more, we can't use
that port number (=the ephemeral port used as source port by the
entity that sent the GetRequest) to connect back. So responses would
always have to use the same transport session as the request, unless
we treat transportAddress in some special fashion.

Best regards,
Pasi

---

From: "David Harrington" <[email-masked]>
Date: Mon, 26 May 2008 20:26:29 -0400

Hi,
 
> In SSH, the party opening the connection

Duh! Forget I asked. ;-)

> identifies a connection -- if that connection still exists, that
would

Yes, for responses, we're all set. the securityStatereference caches
the transport information to ensure the same session can be used.

> (Using the same well-known port for both source and destination
The WG decided that reuse of existing connections was acceptable, so
one  connection could be used for both R/R traffic and notifications.
I don't think we discussed the different port numbers used and how
that might impact this approach. Are you saying that reuse might be a
problem? Or that the application would need to deliberately request
reuse of a (presumably) existing connection (by specifying  the right
destination port)? (We did discuss that the receiving port would need
to be listening for incoming traffic of both types.)

I usually work with UDP and I don't think I've ever tried to use the
same port number for source and destination. Is using the same port
for source and destination a problem in TCP? or just for well-known
ports? Is this something I should be recognizing as obvious and am
simply overlooking? ;-)

dbh

---

From: <[email-masked]>
Date: Tue, 27 May 2008 09:48:39 +0300

David Harrington wrote:

> > On the other hand, if transportAddress includes both the IP
> > address and TCP port number, a "client" connection (connection I
> > opened) wouldn't match a "server" connection (connection the other
> > end opened), because in the latter case, the (remote) source port
> > number isn't the well-known port, but some ephemeral randomly
> > selected port.
> > 

Let's see how this could work...

Suppose a management station (apologies for sloppy use of terminology
-- this is just an example :-) at 192.0.2.1 opens an SSH connection 
to an agent at 192.0.2.33. The TCP connection would be, for example, 
from 192.0.2.1/1418 (where 1418 is a random ephemeral port) to
192.0.2.33/NNN (where NNN is the port allocated by IANA for SSHTM).

Let's assume that there's a GetRequest/Response exchange, but the
SSH connection is left open in case it's needed in the future.

The SSHTM on the agent side will have a table (or something)
containing all the currently open transport connections, probably
indexed by (at least) transportDomain, transportAddress, securityName,
and securityLevel. The most obvious choice (but perhaps not the only
one) for transportAddress in this case would 192.0.2.1/1418.

If the agent now wants to send a notification, the transportAddress
given by notification originator application would probably be
192.0.2.1/NNN -- so it won't match the existing transport connection
(and the agent will open a new one).

In general, it seems if the transportAddress contains the TCP port
number, and TCP source ports are ephemeral random ports, there are
situations when two simultaneous connections between two entities are
needed (e.g., a connection opened by manager for sending requests will
be used also for responses, but not notifications).

However, I don't think this is really a problem. This comes from
using TCP (and is not really SSH specific), and it seems to be exactly 
how the current TCP transport mapping (RFC 3430) works:

   TCP connections are established on behalf of the SNMP applications
   which initiate a transaction.  In particular, command generator
   applications are responsible for opening TCP connections to command
   responder applications and notification originator applications are
   responsible for initiating TCP connections to notification receiver
   applications, which are selected as described in Section 3 of STD 62,
   RFC 3413 [8].  

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Wed, 28 May 2008 12:25:51 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 27, 2008 2:26 AM
Subject: Re: [Isms] ISMS/SSH and notifications

<snip>

> ports? Is this something I should be recognizing as obvious and am

I have seen the same (well-known) port used as UDP source and destination quite
frequently; I have wondered why and then why not?

TCP is different and the TCP source port is usually used cyclically, starting at
some value, may be determined by the implementation but sometimes appears to be
pseudo-random.  But does it have to be?

(I remain convinced that reusing a CR/CG connection for a NO+CR entity remains
the simplest deployment, even if the CR/CG is just used for the retrieval of a
one well-known object eg snmpTsmHereiamsendmenotificationsplease )

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 May 2008 19:04:14 +0200

> one well-known object eg snmpTsmHereiamsendmenotificationsplease )

As I pointed out in some WG meeting, reusing a SSH (or simply TCP)
connection means to install SNMP target configuration that is only
meaningful as long as the connection exists. I doubt it very much that
there is a portable way to share a listening TCP endpoint and a
connection TCP endpoint; I would be surprised if this works at all in
any meaningful way if I look at the TCP state machine.

Hence, when the SSH (or simply TCP) connection goes away, the SNMP
target configuration pointing to it needs to be garbage collected.
This implies that once the TCP connection is gone, there is either no
way to send a notification anymore or you have to have a backup SNMP
target configuration to be used after the connection has disappeared
(which again requires configuration information so that the SNMP
engine hosting the notification originator knows about this fail-over
situation).

To make this work, several extensions to the SNMP target tables are
needed and I recall that we abstained from this when we wrote the SNMP
over TCP mapping since all this creates several new failure modes.

/js (speaking as technical contributor)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms