Chris Lonvick wrote:
>
> At 10:35 PM 10/8/00 -0400, Alex Brown wrote:
> ---remainder deleted for brevity---
>
> Hi Alex and group,
>
> I have some additional thoughts about this. In no particular order:
>
> - You assume that this will be an extension of the existing syslog protocol
> rather than defining a new format (with new udp port). I support this
> but I'd like to see it articulated in the ID. I'll also accept any
> discussion of this on the list if anyone sees any problems with this.
I think it's clear enough, but I'll add a few words to that effect.
> - We discussed the length field and I think that we all have found that
> current versions will only accept 1024-bytes of the message. That is
> defined in the current syslog ID but it may be that this can be changed
> with this ID. I would still like to see a maximum length described in
> this ID for this new-style message format.
The discussion here doesn't deal with the small length limit, which
should be evident in any UDP protocol; again, I can add some words.
> - I'd like to see a discussion of the acceptable behaviors of the
> receiver. I think that there will be some cases which need exploring.
> A new style receiver may accept old-style or new-style messages or both.
> It may reject new-style messages that don't have a correct MAC or it
> may accept them for later study but not place them in the repository
> with other acceptable messages. (It may place incorrect messages in a
> lifo file with a fixed and unexpandable size.)
The log server really should be able to capture anything in the text
message, as always. Any other behavior, including bogus-discards,
probably should be configurable but this is really up to the implementor
and out of scope of this draft.
> - The thought of using the chain works well in a system with sequenced
> delivery. However UDP won't ever provide that so we may see a behavior
> of the following:
> msg1 --------------------> received as A
> msg2 --------\ /---------> received as B
> msg3 --------/ \---------> received as C
> msg4 --------------------> received as D
> The receiver would find the "chain" for A and cache it. It would find
> B but find that the "chain" indicates that it did not come immediately
> after A. It would cache the "chain" value from B and then receive C.
> If would find that the "chain" value indicates that C did not come
> after B but it would cache the "chain" value for C and then receive D.
> Again, D did not come after C. This could be re-ordered with a bunch
> of post processing. However, let's take this case:
> msg1 --------------------> received as A
> msg2 --------------------> received as B
> msg3 ----X-dropped
> msg4 --------------------> received as C
> msg5 ----X-dropped
> msg6 --------------------> received as D
> msg7 ----X-dropped
> msg8 --------------------> received as E
> msg9 --------------------> received as F
> There would be nothing to confirm the order of C relative to D. The
> indication would be that there were gaps between B and F and that
> both C and D were received in that time period however, it could not
> be reliably said that C was generated before D. Your note about the
> sequence number could change this behavior and I'd like to see that
> explored.
Yes, there's no way to sequence single-packet segments. This is not
intended to provide reliable transport or even reliable characterization
of corruption. It will detect bogus packets and sequence corruption;
that's about it.
> - The names that you have in the extended format will probably collide
> with values found in normal Syslog messages. Such as:
> Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
> the values of chain=link md5=type_5_molybdenum \
> chain=a6739e57964c9dec7613d663f049c0f7 \
> md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
> Is it important that the names don't collide or should it be specified
> that the processing of the extended format be done from R->L and the
> last field must be md5=* and the prior field must be chain=*? Or
> should a delimiter be placed after the end of the traditional message
> but before the beginning of the extended fields? If we don't use
> a delimiter, then what might happen to the receipt of a traditional
> syslog message such as:
> Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
> the values of chain=link md5=type_5_molybdenum
> Would it be interpreted to have a bad MAC?
I think this all is up to the implementor; confusion in message text is
his own fault.
> - Would it be acceptable to use some of the unused or reserved values of
> the current syslog priority values to differentiate between this "new"
> format and the "traditional" format?
I don't see the point. This is intended to provide some limited
authentication for the whole log stream, not just for certain
facilities/priorities, etc.
> - Is this going to be limited to md5 or are other hash algorithms going
> to be accepted?
Again, that's up to the implementor. This is just an indication of a
general method.
> - You note that the FQDM or IP address should be used in the message
> but your example only lists it in hostname format. Would it be
> better to just rely upon whatever current information is held
> within the traditional message, or would it be better to have this
> as an additional field in the extended format? For example:
> Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
> the values of chain=link md5=type_5_molybdenum \
> FQDM=zorilla.example.com \ chain=a6739e57964c9dec7613d663f049c0f7 \
> md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
> or
> Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
> the values of chain=link md5=type_5_molybdenum |
> IPV4=10.1.1.1 \ chain=a6739e57964c9dec7613d663f049c0f7 \
> md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
> or
> Nov 5 14:14:55 zorilla PAM_build[509] (construct) Im going to use \
> the values of chain=link md5=type_5_molybdenum |
> IPV6=bigaddressstuff \ chain=a6739e57964c9dec7613d663f049c0f7 \
> md5=cbce1c7ced9cfdc1fb86ba8ef365d8eb
Well, I probably should have illustrated a FQDN, but "zorilla" was a
hostname in my world at 3Com, not a FQDN. I would try to make sure the
syslog library uses the full name. I'll add words on this.
> - Should the ID note that any attempt to perform NAT address conversions
> in the extended format fields will mess up the md5 value. It would be
> a good practice to not share the key with any NATificators.
The MAC is computed over message text only, and is completely
independent of the IP header. NAT translation will not affect it.
> - All of this may be somewhat interesting (which may or may not be a
> problem but should be discussed in the ID ;-). Let's say that Device
> A is configured as follows:
> *.emerg @server1
> *.alert @server1
> *.alert;auth.warning @auth-server
> So let's say that daemon fires off an emergency level message to
> server1 and then lpr also sends an emergency message to server1.
> To further complicate things, let's say that server1 was configured
> as such:
> lpr.emerg /var/log/lpr-emerg
> *.emerg /var/log/real-emerg
> The messages will be sent to their order but not filed in the same
> file. Post processing will not be able to sequence them correctly
> unless the two files are merged. Is this OK? If so, then it would
> be good to note that.
This is just life with syslog. I don't think it's affected by the
authentication mechanism.
> - From that, what happens in this case. Machine A has the following
> configuration:
> *.emerg @server1
> And the machine server1 has the following configuration:
> *.emerg @server2
> Should an additional chain and md5 be placed at the end of the
> whole message which already has the chain and md5 from machine A?
> I would vote that server1 should discard the chain and md5 received
> from machine A and append its own chain and md5. Both the chain
> and MD5 seem to have local significance only. It should be noted
> that received messages that don't authenticate properly should not
> be forwarded as if they were received with proper authentication.
Right, if the log server is coded and configured for discarding bogus
packets. Again, this is up to the implementer.
> Some of these questions come from parts of the discussions in RFCs 2082
> - RIP-2 MD5 Authentication - 2328 - OSPF Version 2 - and 2385 - Protection
> of BGP Sessions via the TCP MD5 Signature Option.
> ftp://ftp.isi.edu/in-notes/rfc2082.txt
> ftp://ftp.isi.edu/in-notes/rfc2328.txt
> ftp://ftp.isi.edu/in-notes/rfc2385.txt
> The RIPv2 messages are somewhat similar to this case of trying to
> authenticate the messages without verification of receipt. From these
> works, I'd ask if it would be better to use a "chain" or to have a
> "sequence number"?
Well, these discussions are all about much more serious protocols and
security problems. John Kelsey wrote to me to recommend adding a higher
resolution wall clock value at the source and each forwarder, but I
think tiny but managed devices may not have clocks or even a boot
count. He recommended a sequence number from boot as an alternative,
noting that an initial value can be used as a shared secret to validate
the whole sequence, so that no secret needs to be hashed with each
message. (This is the approach of [PEO95]; "PEO" stands for "Primer
Estado Oculto", "first state hidden".) Unfortunately, the device's
reboot may not be observed by the log server, so the sequence's origin
may be unknown and therefore the whole sequence is unauthenticated. So
I think it's simplest just to authenticate each message with a shared
secret, and use the previous MAC only as a chain value and nonce in the
message. This means that the authentication only verifies that the
sender is known, and that nothing was sent or lost between the previous
message and the current one. A segment can thus begin anywhere and end
anywhere.
I'll add some clarification on this.
> I've reformatted your draft to text-only and have added some other
> comments below. All replies and additional comments will be
> graciously received. I've also changed my "reply to:" address to
> be this list. If anyone wants to communicate directly with me,
> please use my real address of [EMAIL PROTECTED]
>
> Thanks,
> Chris
>
Thank you, Chris. I'll reflect your comments in the final writeup,
which will be in standard form. As you know, no-one is currently
supporting my work on this draft, so I'll have to keep it simple. Let's
pay more attention to the syslog replacement problem.
Alex
--
Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761
