Re: [Isms] wg last call followup - sshtm

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

Hi,

I have the same concerns. I feel very uneasy about this.

I think that the way to resolve it is to have sshtm record the
SnmpSSHAddress and the tmSecurityName for outgoing messages, and match
them up to incoming messages. If the principal identity matches the
user part of an SnmpSSHAddress in email format, and that is different
than the tmSecurityName used with that transport adddress for the
outgoing message, then use the tmSecurityName that was used for the
corresponding outgoing message.

If we send the message to "bob at remote.org", then I presume the
response will come back from "bob" at remote.com's address. However,
we might have used a domain address (remote.org) on the outgoing, I am
not sure whether we get a response from remote.org or from <10.1.9.34>
(an address that remote.org resolves to).

I have documented the elemts of procedure as well as I can given my
current understanding.

dbh


> -----Original Message-----
> From: tom.petch [mailto:cfinss at dial.pipex.com] 
> Sent: Sunday, March 01, 2009 3:05 PM
> To: David Harrington; 'Jeffrey Hutzelman'; 'Juergen 
> Schoenwaelder'; isms at ietf.org
> Subject: Re: [Isms] wg last call followup - sshtm
> 
> ----- 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
> > >
> >
> 
>