Re: [Isms] ISMS/SSH and notifications

["David Harrington" <ietfdbh at comcast.net>]

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  

> -----Original Message-----
> From: tom.petch [mailto:cfinss at dial.pipex.com] 
> Sent: Tuesday, May 20, 2008 8:39 AM
> To: David Harrington; Pasi.Eronen at nokia.com; isms at ietf.org
> Subject: Re: [Isms] ISMS/SSH and notifications
> 
> ----- Original Message -----
> From: "David Harrington" <ietfdbh at comcast.net>
> To: <Pasi.Eronen at nokia.com>; <isms at ietf.org>
> Sent: Friday, May 16, 2008 4:01 PM
> Subject: Re: [Isms] ISMS/SSH and notifications
> 
> 
> > > -----Original Message-----
> > > From: Pasi.Eronen at nokia.com [mailto:Pasi.Eronen at nokia.com]
> > > Sent: Friday, May 16, 2008 6:41 AM
> > > To: ietfdbh at comcast.net; isms at ietf.org
> > > Subject: RE: [Isms] ISMS/SSH and notifications
> > >
> <snip>
> >
> > 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.
> >
> 
> 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'.

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.

> 
> 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; 

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
> 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?

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.

> 
> Please clarify.
> 
> Tom Petch
> 
> >
> > David Harrington
> > dbharrington at comcast.net
> > ietfdbh at comcast.net
> > dharrington at huawei.com
> >
> 
> 

_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms