Re: [Isms] ISMS/SSH and notifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Isms] ISMS/SSH and notifications
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
> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On
> Behalf Of Wes Hardaker
> Sent: Thursday, May 01, 2008 8:17 PM
> To: isms at ietf.org
> Subject: [Isms] ISMS/SSH and notifications
>
>
> 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
> Isms at ietf.org
> https://www.ietf.org/mailman/listinfo/isms
>
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
