Hi Albert, sorry for the slow response, as I wrote I was out of office ... and the Internet connection was so bad that it was virtually non existant.
I am trying to address all issues you raise. But first of all, by going through the mail archives, I have noticed that you may find I had picked on your code. Honestly, this is not the case, but the impression may be created by not following the full sequence of my postings. My apologies for this. I quoted your name when it came to reboot session IDs (in -sign) because I wanted to give proper credits to the first one who actually implemented it. Besides being the first one, I also like your approach, as I think it fits well with -sign and solves a lot of issues. As I pointed out both on- and off-list, I will probably follow your approach when I am ready to implement -sign. Once again, my sincere apologies if I somehow created the impression to "attack" your way of doing things - this was not my intention. > Some quotes of several messages (reformated) > > > 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. > > > In the context of -sign, this is NO issue at all,[...] However, in > > the light of -international, things are quite different. > > This line is important. > It means (to me:) > -sign is about security > -international is about functionality, NOT about security! I already commented on this one. While I think that -sign is on the core of security, I think -international (and all hopefully all other protocols) should try to do their best to secure what they are doing. So in this way, everything needs to have security put on the agenda. I think this is why IETF demands a "Security Considerations" section in the newer RFCs. But I think you did not get the spirit of my post. I can see this because you snipped out the most important part. [...] reads as follows: > (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. I am just pointing this out because I find it is important to keep in mind that security in -sign does not come from just the reboot session ID but it comes from the fact that it is cryptographically signed. > > -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). > > That is wrong. -international isn't (about) security. I do not fully agree here, see above. > When security is > needed, -international should be used over a secure transport > "layer". Like -sign, -reliable, of even a non-standard transport. Here, I fully agree, in fact this is what I recommended in several postings. > > All -international should do about security is: > a) make sure it can be used over a "secure syslog transport" > b) make sure no (new) insecure features are introduced. > This sounds very good ... > So, a "counter to increase security", but not needed is useless, and > can be counter productive. ... actually, we are very close together: this counter was not introduced because of security, it was introduced because it was needed for fragmentation (oversize messages). In fact, it is not always present, only in when the message is oversized and needs to be fragmented. Please see the ABNF posted: http://www.mail-archive.com/syslog-sec%40employees.org/msg01262.html It is a good thing that you remind me that the reboot ID will most probably not be present in 99% of the -international enhanced syslog messages (at least this is what I feel). This is because it is a purely OPTIONAL part. A question to the WG is if it is concensus that it should stay that way (I would prefer this). Then, I was thinking about replay attacks, because I eventually misunderstood a comment from Chris http://www.mail-archive.com/syslog-sec%40employees.org/msg01290.html He said that the reboot session ID could also be helpful in detecting replay attacks. That made me look deeper and deeper into this use. However, as you (Albert) correctly point out, the reboot session ID is not really that important for -international because it will most probably not be present in the majority of messages. I guess some confusion was caused because I moved over the reboot session ID & related things from -sign to -international. The root reason for this is that I need a unique message ID for -international - and I thought I use those things that were actually agreed upon. Well, wrong move, because there are obviously some little differences. I now don't think it pays to save some coding by re-using what is already there. And now I think Chris, too, was more or less refering to reboot ID as in -sign (different use) [Chris: is this right?] I still need a message ID. This discussion - I think - shows that it will probably best to use > - TIMESTAMP (should be at least in millisecond resolution) > - TAG (should include process id) > - HOSTNAME together to form the ID and drop the reboot session ID. If nobody comes up with another opinion, I will change the fragmentation description I posted to reflect this as well as some other changes that Anton suggested and that I posted messages on. > > As I understand -international it needs a kind of "super messages > (longer that fit in a transport syslog message). I'm not aware of > details, but ... > > Please just specify how to fit "long messages" in serveral transport > packages. (That is done before: "fragmenting", maybe reuse that > knowledge:-) well... I tried to reuse what was done in -sign in this regard. Now, it doesn't look like a real clever idea ;-) > And asume the tarnsport layer works (most of the time). > > Then, it will be simple and working. even for UDP-syslog. Make sure > the algorithm doens't break when a UDP message is lost, but live with > the lost-data! If a system(admin) can't live with it, he will use > syslog-reliable as transport anyhow! > When the system/network is small, and logging not top-priority UDP > syslog will be fine. > > For small networks, UDP is fine: Just set-up a centrall (UDP) > collector, and add host (physically) at will. As long they use a UDP > syslog (traditional, rfc3164, -sign, -international, -fragmented, ...) > all log can be read. And "complex" fragmented messages are still > reasble, without tools! > (<<See this as ... (1/2)>> <<... an example(2/2)>>) Yes, this *is* the spirit of the ABNFs (see above and archive) I posted. I am glad to hear it is a workable approach - as I said, I will update the ABNF. There is still a lot of work sitting on my desk, but I hope to post a message some time later this week. > > The important thing is that I think the reboot ID - as you > describe it - > > works for -sign. I was arguing that it does NOT provide > reply attack for > > -international > > You correct, it will NEVER work for -international, I think. And It > should!# > > > So these are the two issues: > > There are a lot more, if -international doesn't use -sign or -reliable > as "transport" Just don't fix them:-) Sure - but that was a little out of context. I was just talking about the reboot session ID ;-). In fact, there are tons of things that need to go into the security considerations. And on top of this, add the transport security considerations (see 3164 for a good picture... ;)). > > Note: > Maybe we should make a syslog-fragment (or syslog-long) RFC, which > describes how to send "long (MSG/CONTENT)", by fragmenting. And > provides ("to above") the functionality to send unlimmited long > messages over another syslog-transport. > > Then -international can use that one to add localization, i18n, or > whatever. > However, then it shoud be possible to use those long messages for > other features to? > > Just an idea. Well, in my point of view this would be the best idea. I, too, suggested this in August: http://www.mail-archive.com/syslog-sec%40employees.org/msg01204.html As it turned out, there was not much support for it. I hold back work on -international for a while and resumed after I felt that concensus was that -international should re-specify the format (as does -sign). Actually, it would not be a big deal to move the general format specification to a separate ID, but on the other hand it does not really hurt if -international contains it. So far, I have tried to keep the overhead of -international very low and most things optional. In fact, the ABNFs I am posting to the list do not even demand an -international cookie to be present. So it will be possible to follow the message format layed out in -international without supporting any -international features. The only drawback is that if you want to support fragmentation, you must also support the rest of the international header (THIS IS part of the -international cookie). Again, I think this is not a big deal, as it doesn't hurt to add this. Especially, as I assume that you must be writing new code if you intend to support fragmentation... I am happy that your kind of digest message helped me to go back to the big picture and not be lost in not-so-important details. I would also appreciate any additional comments form the WG, especially on the unique message ID and the idea of having its own ID/RFC for the message format. If I don't hear otherwise, I will continue with -international as discussed and will change the fragmentation as outlined above. Rainer
