Re: [Isms] Comments on the BTSMS proposal

["Tom Petch" <nwnetworks at dial.pipex.com>]

----- Original Message -----
From: "Sam Hartman" <hartmans-ietf at mit.edu>
To: <dbharrington at comcast.net>
Cc: <isms at ietf.org>
Sent: Tuesday, July 26, 2005 8:57 PM
Subject: Re: [Isms] Comments on the BTSMS proposal


> >>>>> "David" == David B Harrington <dbharrington at comcast.net> writes:
>
>     David> 2) Make the transport security selection transparent, not
>     David> opaque.
>
>     David> I don't feel comfortable having one BEEP transport mapping
>     David> that might use only TLS or might user TLS with SASL or some
>     David> other combination of underlying protocols. I think TLS and
>     David> SASL-over-TLS probably meet different security
>     David> requirements, so should be considered different BEEP
>     David> profiles, different SNMP transport mappings, and different
>     David> SNMP security models. SNMP-over-BEEP seems too opaque to be
>     David> useful for security purposes.
>
> I have not yet read the document but based on your comments I
> disagree.  The security provided by TLS, SASL and any combination will
> depend on the specific mechanisms in use, ciphers used by those
> mechanisms and possibly by properties of external authentication
> infrastructures.
>
> If you try and expose this information to SNMP, you will complicate
> the mapping significantly.  In addition, you will probably find that
> several deployments do not fit your mapping.
>
> I don't think there is a lot to be gained from treating for example
> SASL+TLS differently from just TLS.
>
> I do think that exposing properties like whether there is integrity,
> whether there is confidentiality and whether there is mutual
> authentication is useful.
>
> I do believe that allowing implementations to expose additional
> information for the purpose of making security policy decisions is
> reasonable.
>
> I suspect based on some comments here that what I'm proposing may not
> be entirely consistent with the SNMP architecture.

Sam

FYI

What the SNMPv3 architecture exposes is the level of security on the wire as
(RFC3411 3.4.3. p.29)  securityLevel
 -  without authentication and without privacy (noAuthNoPriv)
 -  with authentication but without privacy (authNoPriv)
 -  with authentication and with privacy (authPriv)

Authentication applies to a message; the architecture does not specify what kind
but, for me, implies one way only, of manager/client/command generator to
agent/server/command responder.  It is also referred to as a primary threat of
Masquerade, of one principal as another.

Privacy again applies to a message and is confidentiality. The architecture also
refers to this as
Disclosure and treats it as a secondary threat.

Modification of information, integrity, is defined as a primary threat that a
security model must guard against but is not exposed in the interfaces.

As you say, it could be different, but that is what we currently have and which
I have taken as a given in this work.

Tom Petch



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