Subject: [Isms] notifications and SSH authentication

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Jan 2006 20:58:23 -0800

At the last IETF meeting I mentioned in the meeting that I had heard
rumors of SSH experts stating that using a host-key for authentication
of an initiating session was considered a bad thing and would be
frowned upon.  Turns out, fortunately, that I was wrong.  Though not
"desired", it is acceptable.

reminder: politically correct SNMP speak means:

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

SSH speak:

LoF = Leap of Faith

[this is much longer than I wanted to end up putting to text but
shorting it would mean resorting to even more hand waving than I did
end up doing.  Not only that but I use different bullet types for
every list to both annoy you and allow for easy referrals at the same
time.  I didn't go into the smaller details about what triggers a
connection, when it is shut down, etc...  only about the
authentication mechanisms.  Oh, and I didn't proof read it because
it's late as it is.]

-- previously discussed and likely known CG->CR: ---------------------

Thus from a normal management session I think we have the SNMP CR
being able to respond to an incoming SSH request from a client CG
using the standard host key authentication on the CR side, and the
standard ssh client side authentication (of any of it's forms) on the
CG side.  Both sides would need, of course, to check the
authentication of the either side.

Functionally this breaks down to (I haven't verified the exact SSH
packet ordering, but roughly this is still accurate I think; I have
also skipped how public key knowledge is previously set up or how LoF
could be used instead for those willing to jump):

1) client CG connects via SSH (likely with a SNMP subsystem) to the CR
   SSH port.
2) the CR responds with it's host-key and proof of ownership.
   Note:  there are other forms of SSH responder authentication but
   these aren't widely deployed to date
3) the CG verifies that the CR is the one it expected to talk to and
   checks the authentication of the CR's host key
4) the CG sends it's credentials using one of the SSH authentication
   mechanisms
   I)  the user-name
   II) the authentication type:
       i) a client key and proof of ownership
      ii) a passphrase form of checking (exact method not described here)
     iii) ...
5) The CR verifies the authenticity of the credentials and verifies
   that the SSH user-name has a VACM map to a group that lets it do
   SNMP things.  This binding may not be 1-1 like USM, but that's
   subject to later date.
6) The CG sends commands
7) the CR responds to them using the SNMP mapped SSH user name and
   checks the VACM settings to authorize each transaction.  How the
   VACM is populated has always been subject to future debate.  It's
   irrelevant from the authentication point of view, which is all I'm
   discussing today.

Again, this is probably what is in people's heads today.  I'm just
being complete...

-- New and not discussed in detail before: NG->NR -------------------

One of the issues with ISMS has been "what happens when a SNMP agent
acting in a NG mode needs to send a notification off but no existing
session is available".  The only choice is very clear: it has to
create one.  The question then becomes, how does it authenticate to
the NR?  Well, the only likely choices available today are:

NG1) Through having password based user credentials on the device such
   that it could connect via SSH to a NG and authenticate itself using
   a username/password types scenario.

NG2) By having the NG use the host-public-key of the SSH server to
   connect to a NG since this public key is already installed in every
   SSH server out there and is truly what seems to most people to be
   the "natural" choice for how to reverse the connection.  I had said
   in the meeting that I thought I had heard people say this was not
   going to be acceptable.  However, after talking with people
   extremely familiar with SSH it turned out I was wrong about the
   current thinking of this issue.  In fact the SSH RFCs have been
   recently published and even discuss this scenario in RFC 4252 (SSH
   Authentication Protocol) section 9:

     Some sites wish to allow authentication based on the host that
     the user is coming from and the user name on the remote host.
     While this form of authentication is not suitable for
     high-security sites, it can be very convenient in many
     environments.  This form of authentication is OPTIONAL.  When
     used, special care SHOULD be taken to prevent a regular user from
     obtaining the private host key.

     The client requests this form of authentication by sending the
     following message.  It is similar to the UNIX "rhosts" and
     "hosts.equiv" styles of authentication, except that the identity of
     the client host is checked more rigorously.
     
     This method works by having the client send a signature created
     with the private key of the client host, which the server checks
     with that host's public key.  Once the client host's identity is
     established, authorization (but no further authentication) is
     performed based on the user names on the server and the client,
     and the client host name.

     ... [technical protocol details]

     The server MUST verify that the host key actually belongs to the
     client host named in the message, that the given user on that host is
     allowed to log in, and that the 'signature' value is a valid
     signature on the appropriate value by the given host key.  The server
     MAY ignore the client 'user name', if it wants to authenticate only
     the client host.

     ...

There are two important parts about the above text with respect to
using a host-key for starting an SSH session to send a SNMP
notification over:

SSH1) The NG would send the SSH host-key as a credential, and the host
      name of the NG, *and* would still send a user name

SSH2) A server MAY ignore the user name and only consider the host
      name from the sent message.

This leads me to think we have 3 choices for fulling the goal of NG2
above.

  ISMS1) we recommend the use of the host key and only the host name
         to authenticate traps at the NR.

  ISMS2) we recommend the use of the host key and the user name to
         authenticate the traps arriving at the NR.

  ISMS3) we don't recommend the use of the host key for authenticating
         incoming traps (sessions really) at the NR.

ISMS3 doesn't of course meat the goal of NG2.  The question then
becomes which of the other two options to pick from.  I think ideally
we should allow for both alternatives to be used in the field, but
maybe suggest one in practice over the other.  IMHO, I prefer ISMS1
because note that the security credentials required by ISMS2 are
actually the same and you have to trust the NG that it's correctly
selecting the user name sending the notification.  Security wise,
using the user name doesn't buy you anything.  Administratively I can
see cases where it might be more helpful.

Here's a concrete example of what I think we should end up doing:

A) NG connects to NR using SSH over subsystem SNMPNotification at a
   new port number to be assigned by IANA.

B) NR responds with it's host based credential.

C) NG would have to verify this as being the right place to send
   notifications to.  Note that there is no infrastructure in place
   today either in SNMP terms or otherwise that will allow existing
   NGs to make this decision.  However, there are a number of ways to
   combat this via either radius like things that people are already
   talking about or a MIB configuration (which could allow
   configuration of it over ISMS/SSH).  The up shot is still the same:
   the knowledge of the NRs host public key doesn't exist today on the
   NG.  There isn't a way around this though regardless of the
   solution space.

D) NG would send it's information and credentials to the NR.  This
   would likely be (but doesn't have to be) the same public key being
   sent by the CR in step 2 way up above.  Something along the
   breakdown of (defined by the SSH authentication mechanism not
   ISMS):

   Key:   [data]
   Proof: [data]
   Host:  me.example.com
   User:  USER

   The choice here being what to set for USER.  My view is that we
   should allow USER to be either:

   D1) USER = "" to indicate only host-based authentication is going
   to be submitted.

   D2) USER = "wes" to indicate that [email-masked] is the person
   trying to send the notification.

   We could only allow for one of these choices, but I think allowing
   for both options is the best way forward.

   [keep reading]

E) the NR would receive the credentials, verify that the key and the
   proof work together and that the key matches the expected key for
   the me.example.com host.  (This also doesn't have an existing
   database counterpart, but is much easier to construct on the fly
   from a given operators .ssh/known_hosts file if need be or through
   LoF techniques for those so willing).  It would have to then make a
   choice:

   E1) if USER="" deal with the notification as if sent by the host.
   In SNMPv3-speak, this would be akin to only ever receiving
   notifications from a given NG being protected under a single USM
   securityName or the alternative view of only from the engineID without the
   usm-securityName half at all.  I doubt many operators (if any) have
   notifications sent out over different USM users to the same
   destination, but I could always be wrong about that.

   E2) if USER="wes" we have 2 sub-choices:

     E2A) ignore the USER and continue as if E1 happened
     E2B) accept the notifications functionally as [email-masked],
          similar to how operators can send notifications as
          usmSecurityName@engineID today.

---------- MIB notes ----------------------------------------------------

I'll leave it to the reader to decide whether the notification/target
mibs need to be modified to support D1 and/or D2 above.  I don't think
so since the snmpTargetParamsTable today specifies a security model
and name which functionally would be SNMPv3/SSH and USER from step D1
and D2 above.  The secLevel may have to have special meaning though
("at least" or...).

---------- Conclusion ---------------------------------------------------

The important take away point here (aside from me being wrong
previously) is that we can use the host-key to initiate a connection
to a NR.  I think something like the above is likely the only real
usable solution for notifications under ISMS.

---------- Implementation notes -----------------------------------------

If *I* were implementing this in a paranoid system, I'd be seriously
tempted to not allow the snmp service to access the private/public
keys of the local host.  Instead I'd have a special socket from the
snmp system that could trigger the snmp service to open a connection
using it's own private/public key.  However, that being said most
systems today have the snmp service running at a really high level of
access (root-level) by necessity since it has to be able to configure
and access the important parts of the device.

-- 
Wes Hardaker
Sparta, Inc.

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 31 Jan 2006 10:12:44 +0100

Wes,

Small mostly unrelated nit.  I'm still digesting the rest of your message.

Wes Hardaker wrote:
> [Typical CG -> CR]
This depends on how the doc is written.  If you don't use a separate
port then there are really three steps here:

5a.  CR verifies the authenticity of the credentials
5b.  CG requests "snmp-isms" service.
5c.  CR verifies that SSH user-name is authorized for "snmp-isms"
service first via whatever SSH subsystem checks there
5d.  If 5c checks are passed, then a VACM check is done.

N.B. initial radius transactions take place during 5a.  If a separate
port is used, an assumption can be made by the ssh server that the use
is ISMS, but even here it's important to note that some code changes
would be necessary in order to make the assumption.  You're not using
SSH out of the box.

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 31 Jan 2006 08:10:18 -0800

>>>>> On Tue, 31 Jan 2006 10:12:44 +0100, Eliot Lear <[email-masked]> said:

Eliot> This depends on how the doc is written.  If you don't use a separate
Eliot> port then there are really three steps here:

I think the last I heard was that the WG consensus was that we were
going to recommend the use of a different port (by default) but
wouldn't do anything to prohibit it from using the same port.  You're
right that we should be requesting the snmp-ssh service or some
service name we haven't yet discussed.  Regardless of the port, I
actually think a particular service name should always be requested
regardless of whether it's expected to be a dedicated port or not.  It
makes implementation on both sides easier and is less prone to
conflict of any kind.

-- 
Wes Hardaker
Sparta, Inc.