Subject: [Isms] Comments on the BTSMS proposal

From: "David B Harrington" <[email-masked]>
Date: Fri, 15 Jul 2005 12:18:44 -0400

Hi,

This draft was obviously done quickly to get it in under the deadline,
so understandably has some things not well described yet. Here are a
few comments:

1) What do BTSM (from the filename) and BTSMS (the title abbreviation)
stand for? Is that BEEP Transport Mapping Security Model? If so, the
acronym is wrong. It should be BTMSM. Or is it BEEP Transport Security
Model? It obviously isn't an acronym for "A BEEP Profile for SNMPv3
PDUs"

2) Make the transport security selection transparent, not opaque.

I don't feel comfortable having one BEEP transport mapping that might
use only TLS or might user TLS with SASL or some other combination of
underlying protocols. I think TLS and SASL-over-TLS probably meet
different security requirements, so should be considered different
BEEP profiles, different SNMP transport mappings, and different SNMP
security models. SNMP-over-BEEP seems too opaque to be useful for
security purposes.

3) Separate the transport issues from the security-mapping issues.

I suggest breaking your proposal into two proposals:
1) an SNMP transport mapping for SNMP over BEEP, which gives you
flexible ways to transport SNMP messages, that subsequently use USM or
other authentication security model to determine the SNMP securityName
and securityLevel, and
2) a TMSM security model that uses the SNMP-over-BEEP transport, and
in addition maps the authenticated identity from the BEEP transport to
an SNMP securityName and securityLevel.

Doing this would help separate the issues of a BEEP transport, such as
session establishment and channel initiation and response to a lost
session, from the issues of mapping transport security to SNMP
securityName and securitylevel.

4) Identify certain requirements for each securityLevel. 

For SNMP access control to function properly, the security mechanism
must establish a security model identifier, a securityLevel, and a
securityName. The document does not discuss how to determine the
securitylevel. 

The SNMPv1/SNMPv2c security model uses plain text passwords, so the
securitylevel is noAuthNoPriv. Given the wide variation of options
supported by BEEP, how does one determine the securityLevel for SNMP
purposes?

There needs to be a mechanism by which the BEEP TMSM (as compared to
the BEEP profile or the SNMP-over-BEEP transport mapping) identifies
the securityLevel used for the message. This will probably require a
set of clearly defined requirements to qualify for each securityLevel
(and might be better in a generic TMSM document rather than being
BEEP-specific). 

5) Identify the source for the securityName. 

For SNMP access control to function properly, the security mechanism
must establish a security model identifier, a securityLevel, and a
securityName. The document does not discuss how to determine the
securityName. 

How is the translation from a mechanisms-specific authenticated
identity to a securityName done? What BEEP interface will provide this
translation from TLS or from SASL to SNMP?

If this translation is done as per the TLS cache approach of the TMSM
design, then what benefit does BEEP add to a direct SNMP-over-TLS
solution or a direct SNMP-over-SASL solution?

6) I am concerned about the discussion of using engineID as an
identifier rather than securityName. First, this does not seem
consistent with RFC3411 architecture, where engineID is never used as
the principal, and second, the engineID is not authenticated.

It may be possible to authenticate the engineID or provide a mapping
between the authenticated identity and an engineID (why use this
rarther than securityname?), but this will require much more
discussion about the implications of such an architectural change.

7) The requirements for compliance need to be unambiguous.

The specification needs to provide more MUSTs and fewer
SHOULDS/options so we can assess how secure the resulting solution is.
If I select an SNMP-over-SASL BEEP profile (and transport mapping and
TMSM), then I'd like to know whether that means DIGEST or PLAIN
security will be used; vendors shouldn't be allowed to implement a
wide array of options that make it impossible to assess the security
characteristics of the solution. 

Maybe this will require defining specific "profiles" of the BEEP TMSM
(as compared to the BEEP profiles or SNMP transport mappings) for
various combinations of options.

8) Auto-discovery should be supported.

There should be a mechanism for SNMP managers to auto-discover
SNMP-capable devices; this was one of the killers of SNMPv2 party
security. We cannot make this secure in a manner that prevents
existing applications that provide autodiscovery from having an
approach to continue providing this feature. Obviously the mechanism
can change, but no application vendor will be willing to move to the
new approach if they are burdened with telling their customers that
auto-discovery is discontinued, and operators will now have to
manually "discover" the SNMP agents, and manually configure their
topology maps. That simply won't fly.

This is a topic that requires further discussion for any TMSM model or
any new security model, but will need to be discussed by each proposed
model.

If a BEEP transport mapping can accommodate not only a secure channel
over TLS or SASL, but also a non-secure NoAuthNoPriv option for
autodiscovery, possibly over UDP, I think that would be a good thing.
Maybe a BEEP transport mapping could use two different BEEP profiles
to accomplish this. Of course, two different transport mappings
(SNMP-over-UDP and SNMP-over-BEEP) might accomplish the same thing
more simply.

9) How will SNMP-over-BEEP impact the SNMPv3 message fields?

Since the BEEP transport simply carries SNMPv3 messages in ASN.1
format, there needs to be some discussion of how the SNMPv3 message
fields get filled in, and what they mean. How do they impact the
Elements of Procedure discussed in RFC3412 and elsewhere?

In particular, how will the securityParameters be impacted? 

How will the BEEP TMSM handle msgFlags?

10) How will SNMP-over-BEEP impact the SNMPv3 Elements of Procedure?

Is there an authoritative engine that still applies? (This is a
generic TMSM issue).

What information needs to be securityStateReference cached for
incoming and outgoing messages? When can the cache be discarded?

11) Coexistence needs to be discussed.

For any new security model, we will need to discuss how the new
security model will coexist with SNMPv1 and SNMPv2c (and SNMPv3). See
RFC 3584 for an example.

Since the BEEP transport simply carries SNMPv3 messages in ASN.1
format, it could presumably be used to carry ASN.1 messages in the
SNMPv1 and SNMPv2 formats. Since the BEEP TMSM provides the mapping to
authenticate the principal and securityLevel, can this be used to
provide an authenticated principal for SNMPv1 and SNMPv2c messages, so
that SNMPv1 and SNMPv2c can now be used reasonably with VACM or other
SNMPv2 access control? 

--
Hope this is enough to start the discussion,
David Harrington
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Kaushik Narayan <[email-masked]>
Date: Sat, 16 Jul 2005 09:03:55 -0700

HI David,

Thanks for your comments.

Some clarifications inline.

>Model? It obviously isn't an acronym for "A BEEP Profile for SNMPv3

The draft specifies a BEEP Transport Mapping Security Model, ideally
we would have liked the file name to btmsm but since -00 version was
already submitted with btsm, we thought it would be too painful to
change the file name.

>security models. SNMP-over-BEEP seems too opaque to be useful for

We were planning to define a single BEEP profile that uses TLS + SASL,
with TLS for channel protection and SASL for authentication only, we do
not plan to use SASL for channel protection.  We haven't thought about
more than one BEEP profile but I would not like to preclude that without
some more consideration.

>securityName and securitylevel.

Do you believe that there is value in a BEEP transport mapping
with USM ?  I always thought BEEP was interesting as a transport since
it provided the security services and integration with authentication
systems that does not exist with USM.

>(and might be better in a generic TMSM document rather than being

I believe that the management of securityLevel must happen within the
TMSM framework and TMSP needs to be able flag an error if the underlying
transport layer cannot meet the securityLevel as specified in the SNMP
message.

>solution or a direct SNMP-over-SASL solution?

We are still working on the interfaces between the TMSP and MPSP
for the BEEP TMSM.

>discussion about the implications of such an architectural change.

I would like to clarify that the draft discusses the use of the engineID
as an identifier in addition to the use of the securityName. The SNMP
securityName identifies the client principal, in addition the TLS channel
will need to be authenticated and SNMP engine acting as the TLS
server will require to be identified.

>various combinations of options.

We would like to make SASL DIGEST mandatory but as stated in the
Security Considerations of the -01 draft, MD5 digest authentication is
not supported by most RADIUS implementations and we need to rely
on PLAIN (RADIUS PAP).

>incoming and outgoing messages? When can the cache be discarded?

Handling of SNMPv3 message fields and definition of the stateReference
attributes passed between the TMSP and MPSP will be specified in the
next revision.

>that SNMPv1 and SNMPv2c can now be used reasonably with VACM or other

Isn't the coexistence issue something that we need to discuss in
the overall TMSM context.

regards,
   kaushik!

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Jul 2005 14:57:43 -0400

>>>>> "David" == David B Harrington <[email-masked]> 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.  If so, I'd
recommend that the WG seriously consider the possibility that the SNMP
architecture is wrong in this regard.  We've got significant
experience in the applications area that exposing this information is
not necessary.  If the working group does decide to split these into
separate profiles, I'd recommend explaining why SNMP's requirements
are different than other applications that use similar security
models.

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 29 Jul 2005 10:26:48 +0200

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 26, 2005 8:57 PM
Subject: Re: [Isms] Comments on the BTSMS proposal

> 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

---

From: Sam Hartman <[email-masked]>
Date: Sat, 30 Jul 2005 11:16:33 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> Sam

    Tom> FYI

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

These seem like reasonable things for the encapsulation layer to
communicate to the rest of SNMP.

I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or
DTLS.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jul 2005 09:20:08 -0700

> I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or

Agreed.

Though it's worth noting that as far as I know all of these establish
a single connection-level set of security parameters. This contrasts
with the current USM, which lets you set per-message parameters.

-Ekr