Re: [Isms] wg last call followup - sshtm

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "David Harrington" <ietfdbh at comcast.net>
To: "'Jeffrey Hutzelman'" <jhutz at cmu.edu>; "'tom.petch'"
<cfinss at dial.pipex.com>; "'Juergen Schoenwaelder'"
<j.schoenwaelder at jacobs-university.de>; <isms at ietf.org>
Sent: Sunday, March 01, 2009 3:58 PM
Subject: RE: [Isms] wg last call followup - sshtm


> Hi,
>
>
> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:jhutz at cmu.edu]
> > Sent: Sunday, March 01, 2009 9:05 AM
> > To: David Harrington; 'tom.petch'; 'Juergen Schoenwaelder';
> > isms at ietf.org
> > Cc: jhutz at cmu.edu
> > Subject: RE: [Isms] wg last call followup - sshtm
> >
> > --On Sunday, March 01, 2009 08:58:24 AM -0500 David Harrington
> > <ietfdbh at comcast.net> wrote:
> >
> > > Whoa!!!!!!
> > >
> > > There is NO securityName in the message.
> > > Where do you think the message contains a securityname?
> > >
> > > IN 4.2, TSM
> > >    3) Set securityParameters to a zero-length OCTET STRING
> ('0400').
> >
> >
> > OK; I haven't had much sleep, so maybe my memory is wrong,
> > and I certainly
> > need to go back and re-read the draft.  But, I think it is
> > essential to
> > actually transport the security name and level in the SNMP
> > message, and for
> > TSM to verify that they are the saem.
>
> The securityLevel and securityModel are transported in the message,
> and the specified securityModel will (presumably, but definitely in
> the case of USM and TSM) verify the securityLevel is at least as
> strong as specified in the message.
>
> securityName, on the other hand, is a security-model-dependent
> parameter, and only exist sin the message if the sending TSM includes
> it in the message, and presumably the incoming TSM processes it. For
> USM, it is included because USM authenticates that securityname. In
> TSM, it is not included because TSM relies on the transport model to
> provide a proposed securityname in the tmSecurityName. TSM does not
> validate the tmSecurityName at all; it accepts it as being the
> securityName for subsequent use for access control for the associated
> incoming message.
>
> For SSH, the two sides do not have to agree on the same securityName.
> The principal known as alice in snmp entity#1 might be known as bob in
> snmp entity#2. The securityname is a local construct. I don't think
> that was the intenrtion of the SNMPv3 WG, but the asymmetric nature of
> SSH has forced it to be so, and the RFC34xx do not seem to require
> that it be so (despite my expectations).
>
> Basically, if the MIB information being sent in a message is from a
> local MIB, then verify that the local securityName is allowed to send
> the data. There are three current applications that send data from the
> local MIB -
>
> 1) NO - the securityName used for access control is a prinsipal known
> tot he local system, via the NOTIFY-MIB, for example. ACM verifies
> that the local principal is allowed to send data off the box. It does
> not matter to whom it is being sent; either they are allowed to send
> the data or not.
>
> 2) CR - the securityName used for ACM is based on the principal that
> was authenticated during the receipt of the message. If
> bob at example.com was authneticated by SSHTM, and SSHTM sets
> tmSecurityName to "bob" as a result (or to fred, or to barney, or to
> router at 192.168.0.1), then the value passed by SSHTM in tmSecurityName
> becomes securityName, and ACM uses that securityName.
>
> 3) proxy - I have not checked this thoroughly, but the information
> passed to the proxy application for an incoming message should be the
> same as what would be passed to a CR for an incoming message. The
> information used for an outgoing message comes from the the proxy-mib
> (and associated mibs) just like in the NO case. In some instances, the
> same tabl;es are used for transportdomain/address and security
> parameters as the NO use case.
>
> The proxy use case is important if, say, SNMPv1 security model is used
> within an enterprise network, but USM is used to send SNMP data over
> the Internet. The router that separates the enterpise network form the
> Internet might act as the proxy. Proxy could be used if the enterprise
> network used USM security model, and SSHTM+TSM was used to forward
> SNMP messages over the Internet.
>

David

I agree but my concern is the one Pasi expressed, that in the Command Generator,
the application will send a Request with securityName of alice and the Response
within the Command Generator (forget CR, that I do not have a problem with) will
have a securityName of bob.  Pasi called it surprising, I would suggest
unacceptable, and in need either of preventing or of warning people of the
consequences.

And I think we also need a warning that the two engines can have different views
of securityName, I think that that is not something to be expected from the
RFC341x series.

Tom Petch


>
> > Otherwise, among other
> > things, you
> > can run into the situation Tom describes, where the two ends
> > disagree on
> > what the securityName is.
> >
> > -- Jeff
> >
>