Hi, Comments inline
David Harrington [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Balazs Scheidler > Sent: Monday, January 30, 2006 6:15 AM > To: HarringtonDavid 73653 > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] Threat model requirements discussion > > 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. 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. > > 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) 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? > * 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. 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. > > 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. > > On Thu, 2006-01-26 at 09:46 -0500, HarringtonDavid 73653 wrote: > > 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. > > -- > Bazsi > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
