Chis, > The purpose of the reboot counter is to prevent replay. I can see the > inclusion of the process id and/or name with the certificate block > messages to identify the sender. (I'm still a little > doubtful about the > concept of multiple syslog processes from a single device but I'll go > along for the discussion. :) Can you explain how this will prevent a > replay? > > In which environments is this challenging? To utilize a timestamp, > devices will require a TOY (Time of Year chipset). To > utilize a reboot > counter, a device just needs some memory that will persist > over a reboot. > I believe that the latter is more common and that this was > discussed in > the SNMP mailing list prior to coming up with SNMPv3, which > came to the > conclusion that a reboot couter was preferred.
I read those sections of http://www.ietf.org/rfc/rfc2574.txt dealing with the reboot id. Actually, I find that there is a big difference between the way it is utilized in -sign-12 and RFC2574. 2574 specifies that it must be *INCREMENTED* on each reboot. That means it must go up by exactly ONE. In sign-12, we just say it must be advancing. Also, in 2574 the reboot ID is used together with a timestamp (and time window). This & especially the increment is the key to the secure reboot session ID. Look at e.g. Albert's implementation of -sign. As suggested, he is using the actual timestamp to generate the reboot session ID. I intend to do it in a similar way in my code. So if I look at code (easy thanks open source), I can guess upcoming rebooot session ids easily. As such, I can use them to construct messages with valid reboot session IDs of e.g. next monday. In the context of -sign, this is NO issue at all, because the reboot session ID will be signed and thus an attacker would need to be in the posession of the emitor's private key. If he is, he can do all sorts of nasty things, so we don't need to worry about this specific case. However, in the light of -international, things are quite different. If we carry over the exact same reboot session id definition, we have two security issues. Before I go into them, let me point out the root cause: we now do not sign the messages (that's only done in -sign and even there not for the actual message [in real-time, in-message]). So it is easy for an attacker to generate a fake syslog message. This is mitigated by using 3195 with proper tuning profiles, but as -international should run over all transports, we must assume plain UDP when it comes to security issues (an attacker would always use the easiest target). So these are the two issues: #1 replay of message done by simply incrementing the reboot id to some value that the emitor normally does not yet emit #2 DoS or confusion of the collector by sending a message with reboot session ID 9999999999 (the highest) Using a timestamp has advantages in both cases. Given a properly time-synced network, #1 can be detected by the collector. We could use some mechanism like the kerberos time window. Granted, if time is not synced, that doesn't help - but then we are back to what the reboot id provides (or not provides)... #2 can totally be avoided, because there is no upper value for the timestamp (well, 2037 may give us some headaches, but that is an implementation issue, not a protocol one. Year 10000 may also give our parsers a bad time, but I assume there will be some new versions available by then...) So in short, I think we should actually stay away from the reboot session ID for -international. OR - eventually it would be better to implement it as in 2574, requiring that the reboot id is INCREMENTED not just ADVANCING. That would definitely add complexity to the implementations. On the other hand this, together with an incrementing message ID, actually guards against reply attacks. Well, it would guard against most of them. If an attacker manages to compromise a log emitor, shut it down and then begin sending faked messages in its name, that wouldn't be detected, but I don't know how we could detect this running over UDP without signatures... (Hint for security considerations: recommend 3195 w/ TLS as transport). The question is now: are we prepared to go with the timestamp-like limited reply protection (easy to break, but simple to implement) or would we go for a real reboot session ID (hard to break, but not-so-simple to implement). While I think the later adds only reasonable work to the implementor, I am not sure if it is in the spirit of syslog. Remeber, it is better to have weak protection done by everyone than strong protection done by only a few. Even the weak protection can be hardened by using proper transport, so there is a way to secure things for those that understand the needs.... Well, I think its time to turn over this question to the list. Any comments? ;-) Rainer
