Re: [Syslog] Sec 6.1: Truncation
Anton and all, I have now changed section 6.1 to: ### 6.1. Message Length .. Well written and very sensible. Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Sec 6.1: Truncation
On Wed, 2006-01-11 at 22:38 +1100, Darren Reed wrote: Anton and all, I have now changed section 6.1 to: ### 6.1. Message Length .. Well written and very sensible. I like it too :) -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
Hi, I was thinking that if we have to do authentication then we could try to get consensus on a simple authentication mechanism - a shared secret. Essentially, each sender would have to be configured with a shared secret before it could use TLS. The receivers and relays would also have that information. When a sender prepares a message, it would hash the shared secret with the formed message. That hash could be placed in an SD element ( [tlsAuthChk=12345678...] ). The recipient could extract the value, and then re-run the hash. If the received hash is the same as the calculated hash then both the sender and the receiver must be using the same shared secret. The caveat to this is in choosing the right hash algorithm. This mechanism and shared secret authentication has been well defined in many prior RFCs. A lot of those RFCs used MD5 which is now going out of favor. Check out RFC 1305 (NTP - appendix D) and RFC 2385 (authentication for BGP). This suggestion tries to keep the ease-of-use of syslog. Using credentials stored in an X.505 certificate (of the recipient) would provide a higher degree of authentication - shared secrets can be much more easily compromised (found, guessed, brute-forced, etc.) than the validated credentials contained in a certificate. If we can get consensus that an in-packet authentication mechanism like this is sufficient to meet our threat model, then we can decide if the shared secret is sufficient (the REQUIRED mechanism), and/or if we want to RECOMMEND a similar X.509 mechanism. That would require having each syslog sender to have an X.509 certificate, and have those signed and available. That just seems to me to be getting a bit far away from the ease-of-use that makes syslog so easy to deploy. Thoughts? Thanks, Chris On Wed, 11 Jan 2006, Balazs Scheidler wrote: On Wed, 2006-01-11 at 10:37 +0100, Rainer Gerhards wrote: Chris, However, it *is* possible to authenticate the peers via X.509 certificates. Any TLS implementation can do client and server certificate verification as part of the session setup process. To the best of my knowledge, some folks use this feature with stunnel. So the server accepts messages only from clients which are authenticated via their certificate (their certificate-based names are configured at the server side). I basically agree with you, one minor addition that this X.509 certificate based authentication is a hop-by-hop authentication and provided the operator trusts all devices on the message path and requires authentication on each hop, then message authenticity can be ensured. There's no per-message signature, thus it is not proovable that a message was generated by a given device after it has been received and stored. A parallel example: It is in a sense similar to client authentication in HTTPS: if you upload a file using HTTPS where client certificate was required and validated, then the file on the server can be trusted to a certain extent (as much as the HTTPS server can be trusted), however there's no means to prove that the file has not been tampered with after it has been received. There was no signature _stored_ along the file and no such signature exists in the HTTPS protocol itself, to do this the HTTPS client would need to generate a signature before transmission and upload the signature along with the file itself. Back to syslog: TLS and X.509 certificate authentication is hop-by-hop and authenticates the infrastructure and network transmission (like HTTPS itself), syslog-sign is a per-message authentication similar to the client-side-sign-and-upload-along-with-file example in HTTPS as described above. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
On Wed, 2006-01-11 at 06:19 -0800, Chris Lonvick wrote: Hi, If we can get consensus that an in-packet authentication mechanism like this is sufficient to meet our threat model, then we can decide if the shared secret is sufficient (the REQUIRED mechanism), and/or if we want to RECOMMEND a similar X.509 mechanism. That would require having each syslog sender to have an X.509 certificate, and have those signed and available. That just seems to me to be getting a bit far away from the ease-of-use that makes syslog so easy to deploy. I don't like this approach as this check does not prove authenticity as each device in the chain can regenerate the same checksum. So I fail to see how this adds to security compared to using hop-by-hop TLS with x.509 certificate checking as it requires the same trust in the involved devices. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
SSH - RE: [Syslog] Re: Threat model and charter
Hi, I forgot to address the use of SSH for authentication. The isms WG is trying to use SSH to provide security for SNMPv3. This can be done by having the devices authenticate by having a username and credential (password, public key, etc.). Again, this sounds to me like it's getting further away from the ease of deployment for syslog than we'd like. However, Rainer mentioned that he thought some people were already using SSH to transport syslog. I need to ask: How many people have implementations that use SSH, and how many are planning this? Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: SSH - RE: [Syslog] Re: Threat model and charter
Just for the records, we (Adiscon - WinSyslog, MonitorWare, rsyslog) do not plan to support SSH either. We plan native TLS first in rsyslog and later in the Windows product. I guess we'll try to make it compatible to syslog-ng no matter if this will be an IETF or industry standard. I expect this to be fairly easy (AFIK our products interoperate via the stunnel hack over SSL). Rainer -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:40 PM To: Chris Lonvick Cc: Rainer Gerhards; [EMAIL PROTECTED] Subject: Re: SSH - RE: [Syslog] Re: Threat model and charter On Wed, 2006-01-11 at 06:29 -0800, Chris Lonvick wrote: Hi, I forgot to address the use of SSH for authentication. The isms WG is trying to use SSH to provide security for SNMPv3. This can be done by having the devices authenticate by having a username and credential (password, public key, etc.). Again, this sounds to me like it's getting further away from the ease of deployment for syslog than we'd like. However, Rainer mentioned that he thought some people were already using SSH to transport syslog. I need to ask: How many people have implementations that use SSH, and how many are planning this? I for one (syslog-ng) don't plan to add native support to SSH, although SSH can be integrated into syslog-ng by using the program destination, something like this: program(ssh -i /etc/syslog-ng/ssh.key [EMAIL PROTECTED] /usr/bin/logger -f); However I don't see this as a very good solution. On the other hand I'm planning on adding TLS natively (instead of using stunnel style hacks). -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
I'm concerned that your analysis seems to be based on what is easy to implement. Well, I have to admit that in the world of syslog people vote with their feet. If it is not easy to implement (better said: deploy), the majority will not deploy it. Maybe I have a false impression, but I think I am not totally wrong. Security is only as secure as people actually use it. Just think about the nice yellow post it notes below the keyboards where all these strong passwords that nobody can remember are being kept. Is it really a good thing to have a multitude of strong passwords that leads to people resort to easily accessible, totally insecure paper notes? Wouldn't it be better to have fewer and not so totally strong passwords, but ones that are actually used as designed? I know there can be a lot said in this regard - I do not want to go into the specifics here. My point is that security is only as good as it is being accepted by the typical user. Stronger security might actually turn out to be weaker when you look at how it is actually *used*. We also need to do the analysis of what security is actually required by syslog deployments. If the ansers are different, we'll have to deal with that. I thought we are doing this by refering to the sections in RFC 3164 and syslog-protocol-16. Do you think we need to elaborate more on the potential threats? If so, we definitely would need to reconsider that part of the work (also in -protocol, because it should mention at least all transport-independant threats). But e are in a different situation if we decide to do something because we don't know how to do better than if we meet what we believe the security requirements are. I think with TLS and certificates we can address the security threads I mentioned. Making the use of certificates optional for operators is in the spirit of what I said above. I don't see any unnecessary evil in that. After all, even seat belts are somewhat optional. So far, cars don't force their drivers to wear them (all attempts to actually force the driver have been circumvented by the user). Please advise. Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: I'm concerned that your analysis seems to be based on what is easy to implement. Rainer Well, I have to admit that in the world of syslog people Rainer vote with their feet. If it is not easy to implement Rainer (better said: deploy), the majority will not deploy Rainer it. Maybe I have a false impression, but I think I am not Rainer totally wrong. I completely agree with you here. It is however important for us to understand the gap between what we can implement and what we believe people need. If that gap exists, we'll need to consider what to do about it. Document it, may well be what we decide. We also need to do the analysis of what security is actually required by syslog deployments. If the ansers are different, we'll have to deal with that. Rainer I thought we are doing this by refering to the sections in Rainer RFC 3164 and syslog-protocol-16. Do you think we need to Rainer elaborate more on the potential threats? If so, we Rainer definitely would need to reconsider that part of the work Rainer (also in -protocol, because it should mention at least all Rainer transport-independant threats). no, that documents all the threats. It doesn't actually make a call as to wether a particular threat is important to solve. As an example, if integrity is not important to the way people use syslog, we might not consider it important to provide integrity. On the other hand if integrity is important to how syslog is used but we cannot find a way to deliver integrity in a manner that is useful to people, we have to carefully consider what to do. But e are in a different situation if we decide to do something because we don't know how to do better than if we meet what we believe the security requirements are. Rainer I think with TLS and certificates we can address the Rainer security threads I mentioned. Making the use of Rainer certificates optional for operators is in the spirit of Rainer what I said above. I don't see any unnecessary evil in Rainer that. After all, even seat belts are somewhat optional. So Rainer far, cars don't force their drivers to wear them (all Rainer attempts to actually force the driver have been Rainer circumvented by the user). Security is completely optional. We understand that many people will deploy syslog-udp without security. That's fine. The IESG has charged us with delivering a solution that has a mandatory to implement mode meeting the following two criteria: 1) Meets the security requirements implied by how people use syslog. 2) Is sufficiently easy to use that it does not in practice provide weaker security than some other option. For example, TLS with mandatory certificate authentication on both sides is more secure than anonymous TLS. However it's sufficiently hard to use that many people will choose insecure UDP over certificates and TLS. Some of those same people would have chosen anonymous TLS over secure UDP. So, you and Chris have made an argument that we cannot provide integrity without decreasing the utility of our security solution. we now need to answer the question of whether integrity should be a security requirement. If it should, then we need to go back to the IESG and say we can't do what they want in an ideal world. This is all part of the standard closed loop between requirements analysis and design. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Sec 6.1: Truncation
Rainer: Thanks for the update. Comments below. I have now changed section 6.1 to: ### 6.1. Message Length Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. These two sentences are contradictory. I'd remove the last one. The maximum limit can be dictated by a transport mapping, like in the case of UDP. Each transport mapping MUST define the minimum required message length support. Any syslog transport mapping MUST support messages of up to and including 480 octets in length. Any syslog receiver MUST be able to accept messages of up to and including 480 octets in length. All receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Receivers MAY receive messages larger than 2048 octets in length. If a receiver receives a message with a length larger than it supports, the receiver MAY discard the message or truncate the payload. If a receiver truncates messages, the truncation MUST occur at the end of the message. UTF-8 encoding and STRUCTURED-DATA MUST be kept valid during truncation. You need to be clear what you mean by keeping the UTF-8 encoding. Do you mean that octets should not be truncated in a way which corrupts the last character (which may have multiple octets)? It is probably possible to detect such corruption by looking at the first bit of the last character and making sure it is not 1, if I recall UTF-8 encoding correctly. If it is 1, drop the last octet. Check the new last one and do the same until you find one with first bit set to 0. It seems that to ensure that the receiver would need to be pretty smart. I wonder if it is a problem. Another question is whether or not validation like this is more appropriate at the higher layer, where every UTF character may be validated anyway. SD-ELEMENTs MUST NOT partly be truncated. If an SD-ELEMENT is to be truncated, the whole SD-ELEMENT MUST be deleted. If the last SD-ELEMENT of a message is deleted, the STRUCTURED-DATA field MUST be changed to NILVALUE. ### I thought the last train of thought was to do a dumb cutover of octets at the end. Darren mentioned this is what you will likely get at the application layer. Proposed rules (although simpler than before) would still demand quite a bit of handling for messages that exceed the max size supported by receiver. I now wonder if implementors would really bother to implement all that logic for the case of messages of sizes they are not configured to handle. After all the trouble of validating and fixing the message which exceeds normative size for receiver, all you'd get is a truncated message, which will be well-formed syslog message after truncation, but may not be well-formed as far as consuming application is concerned. What do you guys think? Thanks, Anton. I have explicitly stated that there is no intrinsic upper size limit. I did this, because we had so much confusion/misunderstanding on that fact in the past. I've also added some details on truncation. The rest is as suggested by Anton :) Please review and comment. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Monday, January 09, 2006 4:49 PM To: Anton Okmianski (aokmians) Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Sec 6.1: Truncation Rainer: I agree - this is better than a convoluted rule. I think we only have any business in defining truncation for relays. For collectors, we have tried to stay away from describing how messages are stored. For relays, I think it would be useful to state that relay can't just drop arbitrary message parts. Your statements about some parts ... are lost may be interpreted that way. Actually, this was what I meant ;) [I saw a number of use cases where it would make sense to strip some known-not-so-relavant SD-IDs to be strippedd], but ... I would recommend that we state that any truncation must happen at the end of the message, which I think is what truncation means to a lot of people anyway. This would prevent an implementation which prefers to throw out STRUCTURED-DATA before the MSG content. A consistent behavior is useful for interop and, in particular, may help in dealing with security issues. ^^^ ... this is more important. I now agree with your point. As a side-note, we had the idea that relay operations may become a separate document, so I would prefer not to dig too deep into relay behaviour. To specify what you recommend, this is not necessary, so this is not really a discussion topic here. Rainer Thanks, Anton. -Original Message- From: Rainer Gerhards [mailto:[EMAIL
Re: [Syslog] Re: Threat model and charter
Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: Rainer I now understand. But wouldn't it then make sense to Rainer create a separate document for it? I have the feeling that Rainer would focus us better than when the discussion is split Rainer among different places/documents. And if I understood Eric Rainer Hibbard right, we may even have a volunteer to put it Rainer together. I'm not sure this needs to be in a document although documenting it is certainly not harmful. It does need to be decided by the WG and the WG does need to justify that decision. The protocol document will naturally describe all the threats (possibly by referring to 3164 for some of them) and will describe which threats are handled by the mandatory to implement transport. This can be split across documents as desired provided there is a reference. Rainer Or would it be better to put all of this into -protocol's Rainer inside a RFC. My intension is to mandate in -transport-tls Rainer that the implementation MUST support anonymous and Rainer authenticated TLS (its even easy to do), but that it must Rainer be possible that that the operator decides which to Rainer use. Now that I have written this sentence, it probably is Rainer already the solution. -transport-tls mandates both as two Rainer separate modes. So either mode could be configured by the Rainer operator. Then, it's security considerations section could Rainer document the implications of mode selection. You can certainly do this. It's even a reasonable solution if: 1) The people who need integrity are willing to deploy some sort of credential to the senders. (This is more or less given; without it, I think you can prove no solution exists). 2) That credential is a valid TLS credential. In particular note that TLS would not be useful in a Kerberos environment,an environment where people had ssh public keys, etc. So, from a theoretical standpoint, your proposed solution works. The WG needs to consider whether it meets the needs of operators in practice. If so, then that's a fine direction. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
On Wed, 2006-01-11 at 13:09 -0500, Sam Hartman wrote: Rainer == Rainer Gerhards [EMAIL PROTECTED] writes: You can certainly do this. It's even a reasonable solution if: 1) The people who need integrity are willing to deploy some sort of credential to the senders. (This is more or less given; without it, I think you can prove no solution exists). 2) That credential is a valid TLS credential. In particular note that TLS would not be useful in a Kerberos environment,an environment where people had ssh public keys, etc. Although not strictly related to this discussion, but TLS does support kerberos based authentication, see RFC 2712 So, from a theoretical standpoint, your proposed solution works. The WG needs to consider whether it meets the needs of operators in practice. If so, then that's a fine direction. How to decide? Are there operators on this mailing list who we could poll, or is it enough that at least three implementors are on the list were involved in the discussions and seem to agree? -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
