Subject: [Syslog] Threat model requirements discussion

From: HarringtonDavid 73653 <[email-masked]>
Date: Thu, 26 Jan 2006 09:46:29 -0500

Hi,

Since syslog and snmp are both IETF standards for network management, I think it would be beneficial to consider the same set of security requirements. The set of requirements in RFC3411 have undergone signficant review within the IETF, and especially within the security community of the IETF. Therefore I recommend that the syslog WG consider the threats described in RFC3411, section 1.4. 

It is possible the requirements will be different for syslog than for snmp, but it would be good to discuss the requirements in similar terms so operators can understand how to balance the security properties, and mitigate the security threats, of the two protocols when used within the same system.

>From RFC3411:
1.4.  Security Requirements of this Architecture

   Several of the classical threats to network protocols are applicable
   to the management problem and therefore would be applicable to any
   Security Model used in an SNMP Management Framework.  Other threats
   are not applicable to the management problem.  This section discusses
   principal threats, secondary threats, and threats which are of lesser
   importance.

   The principal threats against which any Security Model used within
   this architecture SHOULD provide protection are:

      Modification of Information
         The modification threat is the danger that some unauthorized
         entity may alter in-transit SNMP messages generated on behalf
         of an authorized principal in such a way as to effect
         unauthorized management operations, including falsifying the
         value of an object.
      Masquerade
         The masquerade threat is the danger that management operations
         not authorized for some principal may be attempted by assuming
         the identity of another principal that has the appropriate
         authorizations.

   Secondary threats against which any Security Model used within this
   architecture SHOULD provide protection are:

      Message Stream Modification
         The SNMP protocol is typically based upon a connectionless
         transport service which may operate over any subnetwork
         service.  The re-ordering, delay or replay of messages can and
         does occur through the natural operation of many such
         subnetwork services.  The message stream modification threat is
         the danger that messages may be maliciously re-ordered, delayed
         or replayed to an extent which is greater than can occur
         through the natural operation of a subnetwork service, in order
         to effect unauthorized management operations.

      Disclosure
         The disclosure threat is the danger of eavesdropping on the
         exchanges between SNMP engines.  Protecting against this threat
         may be required as a matter of local policy.

   There are at least two threats against which a Security Model within
   this architecture need not protect, since they are deemed to be of
   lesser importance in this context:

      Denial of Service
         A Security Model need not attempt to address the broad range of
         attacks by which service on behalf of authorized users is
         denied.  Indeed, such denial-of-service attacks are in many
         cases indistinguishable from the type of network failures with
         which any viable management protocol must cope as a matter of
         course.

      Traffic Analysis
         A Security Model need not attempt to address traffic analysis
         attacks.  Many traffic patterns are predictable - entities may
         be managed on a regular basis by a relatively small number of
         management stations - and therefore there is no significant
         advantage afforded by protecting against traffic analysis.

David Harrington
[email-masked]

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

---

From: Balazs Scheidler <[email-masked]>
Date: Mon, 30 Jan 2006 12:14:54 +0100

Hi,

I tried to create a prioritized list of threats, however as I see we
have separate threats that affect the hop-by-hop nature of syslog (which
is not present in SNMP, AFAIK) and the messages itself. 

So the list of threats is doubled: a threat can be affecting a single
sender and each message of that sender (per-message threats), and a
threat can affect the hop-by-hop link between two relays where the
information sent by multiple senders are "merged".

Primary threats:
----------------
* modification of information while transported from one 
  relay to the next (integrity checking, hop-by-hop)
* disclosure of information while transported from one 
  relay to the next (encryption, hop-by-hop)
* masquerading as an information sender while transported 
  from one relay to the next (authenticity checking, hop-by-hop)

Secondary threats:
------------------
* modification of information while it traverses multiple 
  relays (integrity checking, per-message)
* masquerading as an information sender while the message 
  traverses multiple relays (authenticity checking, per-message)
* message stream modification for an individual sender 
  (reordering and replay, per-message)
* message stream modification while messages are being transported 
  from one relay to the next  (reordering and replay, hop-by-hop)

Less important threats:
-----------------------
* DoS
* Traffic Analysis

My rationale of giving more importance to hop-by-hop threats is 
that it is easier to build a syslog infrastructure which does 
hop-by-hop encryption/integrity/authenticity than one which 
expects _ALL_ sending devices to sign messages. And additionally 
a dedicated syslog infrastructure can already be trusted enough 
not to modify in-transit messages which makes per-message 
authenticity less important. 

My vision is as follows:

legacy syslog device -> encryption capable relay -> log center

where the encryption capable relay is close to the syslog source, 
so that the link between them can be trusted (e.g. possibly 
dedicated local LAN), and the encryption capable relay can use 
all nifty crypto stuff to make sure that the center receives 
what it originally received.

And one last note: I've put message stream modification to the 
secondary group, even though I know that any decent crypto 
transport layer is capable of eliminating this threat.

-- 
Bazsi

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 30 Jan 2006 09:40:16 -0500

Hi,

Comments inline

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Balazs Scheidler
> Sent: Monday, January 30, 2006 6:15 AM
> To: HarringtonDavid 73653
> Cc: [email-masked]
> Subject: Re: [Syslog] Threat model requirements discussion
> 
> Hi,
> 

First, let me try to clarify some terminology, since I find Balazs's
terminology a little murky.

In SNMP we make a distinction between the message and the PDU. The
message is the complete message including the header and the content.
The PDU is the content of the message.

All SNMP messages have a hop-by-hop nature. Authentication and
integrity-checking of the complete message is done on a hop-by-hop
basis. 

A PDU can be passed on through a proxy - the PDU typically receives no
processing at the proxy but is just forwarded between engines of the
same SNMP version. There are "translating proxies" that do alter the
PDU, when the message is being translated between versions of SNMP.

When a proxy forwards a message, the message header for the incoming
message is different than the message header for the outgoing message.
For a message passing from A to B to C, the message header from A to B
contains the necessary information to authenticate the security trust
relationship between A and B. The message header from B to C contains
the necessary information to authenticate the security trust
relationship between B and C. Integrity checking is done using a
digest created from the whole message, so the integrity-checking data
also differs between A and B and between B and C.

There is an assumption that A trusts B to not alter the PDU in
undesirable ways. If A didn't trust B, then A wouldn't have a security
trust relationship with B and send B the PDU in the first place. The
same is true for B to A, B to C, and C to B, and so on.

So every step between engines is a hop that gets authentication and
integrity checking, whether the step is from the originator of the PDU
to a proxy, between two intermediate proxies, or between a proxy and
the final receiver of the PDU. (or between the originator of the PDU
and the final receiver of the PDU, with no proxies in between).

In SNMP, an engine that originates a message and an engine that
receives a message is simply an engine. A proxy forwarder is an engine
that is configured to both receive a message and originate a message
for the purpose of forwarding the PDU. 

I assume this is roughly equivalent to the security relationships
between syslog engines as well.

> information sent by multiple senders are "merged".

If the hop-by-hop transport of information checks integrity of the
whole message, then it shouldn't be necessary to check the integrity
of the message contents independently, should it?

If a relay cannot be trusted to not alter the message contents in
undesirable ways, why would an administrator utilize that relay in
their system of relays for message transport? Can you give me an
example of when such an untrustworthy relay would be used?

>   from one relay to the next  (reordering and replay, hop-by-hop)

Let me observe that during the development of SNMPv3, the idea of
having non-secure SNMPv1 engines in the system at all was anathema to
some IAB members, even in the type of migratory scenario you describe.
I personally think such a migratory approach for legacy devices is
critical in the real world.

> > Since syslog and snmp are both IETF standards for network 
> management, I think it would be beneficial to consider the 
> same set of security requirements. The set of requirements in 
> RFC3411 have undergone signficant review within the IETF, and 
> especially within the security community of the IETF. 
> Therefore I recommend that the syslog WG consider the threats 
> described in RFC3411, section 1.4. 
> > 
> > It is possible the requirements will be different for 
> syslog than for snmp, but it would be good to discuss the 
> requirements in similar terms so operators can understand how 
> to balance the security properties, and mitigate the security 
> threats, of the two protocols when used within the same system.
> > 
> > >From RFC3411:

---

From: Carson Gaspar <[email-masked]>
Date: Mon, 30 Jan 2006 19:56:22 -0500

> example of when such an untrustworthy relay would be used?

Simple - a formerly trusted relay becomes compromised. In a perfect world, 
this wouldn't happen. But in the real world, it does. Having the data 
authenticated by the origin reduces the threat to only the origin server.

-- 
Carson

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 31 Jan 2006 09:47:53 +0100

> authenticated by the origin reduces the threat to only the origin server.

And additionally, the syslog infrastructure can be a shared
infrastructure that is managed by a different group in the organization.
So the IT managers of end systems _might_ be interested in having their
own security measures while still using the shared infrastructure.

-- 
Bazsi