Re: [Isms] ISMS/SSH and notifications

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

> -----Original Message-----
> From: isms-bounces at ietf.org [mailto:isms-bounces at ietf.org] On 
> Behalf Of Wes Hardaker
> 
> tp> So Wes is right to say that VACM is not responsible for 
> checking it
> tp> but I think wrong to say that it is ok to take whatever the
> tp> application gives it.  The security model should stand between
the
> tp> two and check that the secure transport ends at something 
> with that
> tp> name and with verified security credentials (as USM does).
> 
> No, actually the USM doesn't do this.  A couple of problems exist in
> this logic:
> 
> 1) The security model hands the securityName back to the 
> application and
>    says "I got this message from this dude named 'Bob'".  The
>    application already takes the value 'Bob' and can change it to
>    whatever it wants before handing it to the VACM.  There is no
>    security check in the architecture today that the application
isn't
>    discarding what it got from the SM and winging it.  The security
>    model doesn't "stand between the two" like you suggest.
> 
I agree.
An "SNMP application" makes the call to IsAccessAllowed, and the
application gets the answer from the ACM. No other subsytem or model
ever talks directly to an access control model.

Access control in the RFC3411 architecture is deliberately
**advisory** - it is up to the application to ask whether access is
allowed, and the application can decide what to do with the answer.
This was very deliberate.

There is no binding between the IsAccessAllowed answer and the actual
access to the underlying instrumentation. Even if IsAccessAllowed says
"no", an application MAY still decide to access the underlying
instrumentation.

For a minimal device such as a printer that has only notifications
such as "out of paper" and "out of ink", a specific SNMP application
could be written that performs no access control, because the only
notifications are not sensitive. A specific application in the same
printer might accept an operation to clear the "out of XXX" status
value, without performing access control. The working group discussed
these specific cases, amongst others, when doing the architecture
design.

There is no architectural binding between an applications' use of ACM
and the security model. Having the security check that this is the
same securityName used for ACM would violate the modularity of the
subsystems (and would disallow the minimal printer applications). 

On the other hand, specific standard applications MAY imply or require
in their elements of procedure that the securityName is the same
between the ACM and the SM. I think this is the case for the NO
described in RFC3413 section 3.3, in paragraph (2).


> 2) The initiating application (NG or CG) is the one that 
> actually tells
>    the remote side who it is when USM is used.  More importantly, it
>    really says "we're both Bob; I can prove I'm Bob and 
> please prove you
>    are too when you send a response".  The CR and NR merely use this
>    fact to look up the proper keying material to use to 
> ensure that they
>    can be Bob.
> 
> tp> And as has been pointed out several times, when the NO
originates
> tp> the session, and the NO is the ssh client, then that 
> credential is a
> tp> public key.
> 
> The *client* credential is a public key.  As is the servers.
> 
> tp> So that is what the NO should be checking and what VACM 
> should have
> tp> in its tables:-)

I haven't hunted this one down, but I believe it is incorrect to state
that an **ACM** should have authentication credentials in its tables.
Authentication is the domain of a security model, so authentication
credentials belong in the tables of a security model, as is done in
RFC3414. The configuration of the tables of an application, such as an
NO, might contain administratively-set pointers (such as the
securityModel, securityName, securityLevel indices) to lookup the
appropriate security credentials in the tables of the security model,
to use for the notification target, as is done in RFC3413. 

I think it is inaccurate to refer to an NO as an ssh client. An NO
does not do authentication or establish a transport connection; it
specifies which securityModel and securityName and securityLevel
should be used when authentication is performed, and which transport
address is used when transport is established. The application should
know nothing about the nature of the authentication credentials.

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