Re: [Isms] wg last call followup - sshtm

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

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.


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