RE: [Syslog] Re: Threat model and charter
Chris, I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
Hi Rainer, I'm still not seeing too many responses about how TLS is authenticated. Only Baszi has said that full X.509 certificates should be used - similar to how they are used in stunnel. Is this acceptable to the WG? Should the WG also consider using PSKs as proposed in RFC 4279? Having authenticated TLS will address many of the threats described in RFC 3164. Is this how the Working Group wants to proceed? I'd like to hear from more people on this. Thanks, Chris On Wed, 18 Jan 2006, Rainer Gerhards wrote: Chris, I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
Hi Rainer, I'm still not seeing too many responses about how TLS is authenticated. I guess you do not see them because most often it is used anonymous... As of my experience, people are concerend about message observation. Authentication is not their prime concern (my previous post detailled why it isn't - hint: Intranet, authentication via sender IP address). Only Baszi has said that full X.509 certificates should be used - similar to how they are used in stunnel. Is this acceptable to the WG? Anyhow, TLS authentication is pretty easy. If you do it as in stunnel (and that's always an option), you do not necessarily need to set up a full PKI. Files with the private keys do well. Distributing them to the senders should not be more hassle than distributing shared secrets. Should the WG also consider using PSKs as proposed in RFC 4279? Having authenticated TLS will address many of the threats described in RFC 3164. Is this how the Working Group wants to proceed? I'd like to hear from more people on this. I recommend -transport-tls with two modes: - unauthenticated TLS - authenticatated TLS both are mandatory to implement but the user can choose which one he needs (that means that nobody is forced to distribute certs or PKI if only message observation shall be mitigated). Rainer Thanks, Chris On Wed, 18 Jan 2006, Rainer Gerhards wrote: Chris, I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) I thought that these postings pointed out what is done: http://www.mail-archive.com/syslog%40lists.ietf.org/msg00421.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00420.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00432.html http://www.mail-archive.com/syslog%40lists.ietf.org/msg00411.html You might also want to review some of these documents: http://www.stunnel.org/examples/syslog-ng.html http://freshmeat.net/articles/view/1781/ Rainer ___ 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-18 at 06:24 -0800, Chris Lonvick wrote: Hi Rainer, I'm still not seeing too many responses about how TLS is authenticated. Only Baszi has said that full X.509 certificates should be used - similar to how they are used in stunnel. Is this acceptable to the WG? Should the WG also consider using PSKs as proposed in RFC 4279? Having authenticated TLS will address many of the threats described in RFC 3164. Is this how the Working Group wants to proceed? I'd like to hear from more people on this. Maybe I was not completely clear. I think we should go the TLS route and let the operator decide whether he wants authenticated or unauthenticated TLS (or asymmetric authentication, e.g. the server is authenticated but the client is not just like in HTTPS) So I fully agree with Rainer on this one. -- Bazsi ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
- Original Message - From: Anton Okmianski (aokmians) [EMAIL PROTECTED] To: Sam Hartman [EMAIL PROTECTED] Cc: Chris Lonvick (clonvick) [EMAIL PROTECTED]; Tom Petch [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 10:54 PM Subject: RE: [Syslog] Re: Threat model and charter Sam: May I recommend TLS PSK Interesting option. Probably not as mature as just using HMAC message digests. Is there some document which compares and contrasts TLS and SSH? It seems recent RFCs surrounding both have put them on a redundancy path. I'd really like to learn why IETF is pursuing both of those at the same time. [tp] As I said previously, I think that transport level security is a topic for 2007 and not 2006, but if and when we do go down that route, then I think the choice of which needs careful consideration. SSL, and to some extent TLS, is stated to be the most widely used security system on the Internet but then it is used with that most widely used protocol HTTP, to access (Enterprise) web servers. Look at network operators and a different picture emerges. The survey that was required before isms came into being showed that ssh was the most widely used system; TLS did not figure, appearing less often than Windows Active Directory, while local accounts scored higher than RADIUS/.TACACS+ (this is also the picture I get from looking at network products on websites). This set the direction for isms. Whatever the issues are of distributing security credentials, they have been accommodated, else these systems would not be in use (although I suspect the quality of key management might not meet the standards wanted by the IETF).. So for me the choice should is one of the marketplace. Enterprise web servers and SSL(TLS) is in place and should give good leverage. Network Operators and the answer is SSH. Tom Petch ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
I think having a lightweight secure transport option without requiring PKI is good. If one were to use PKI, no doubt TLS beats SSH as an established standard. But using PKI is not trivial and should not be a requirement IMO. Based my experience with SSL/TLS on an unrelated product, private key configuration is a very frequent support issue. Of course, some of it could be streamlined with better tools and documentation, but whatever you do it is not as easy as a setting shared secrets. So, I'd prefer to have a basic secure transport option that allows for using a shared secret. If that transport does not provide for privacy, I am fine with that. The added benefit thought is that it is transport-agnostic and adds no overhead on proxies. The validation on receiver end can also be delayed until message is actually used (if at all). Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick (clonvick) Sent: Tuesday, January 17, 2006 3:21 PM To: Tom Petch Cc: [EMAIL PROTECTED]; Sam Hartman Subject: Re: [Syslog] Re: Threat model and charter Hi Tom, On Fri, 13 Jan 2006, Tom Petch wrote: Replying to no-one specifically, I think one significant consideration is being missed. Basing security on a secure transport may already exist as an implementation but not as an I-D. I expect it to take at least 6 months, more like 12, to produce an IESG ready I-D. By that time, our long-suffering editor of syslog-protocol says he will have had to stand down. I believe that means we will never produce the two I-Ds needed for advancement and that the WG will shut down with nothing done. More hopefully, I do believe that the threats can be met by syslog-sign. Almost every user I talk to about security wants encryption. I have to work very hard to do so, but mostly succeed, in demonstrating to them that what they need is message origin authentication and integrity and it just so happens that that is what most IPS protocols offer, and, even better, it is much cheaper than encryption. I believe syslog falls into this category for most users, and that the aims of syslog-sign will meet most requirements. I hear it criticised for having the wrong algorithms. Fine, we must change that since every security system nowadays should be algorithm agnostic. MD5 got busted, fine we switch to SHA-1. SHA-1 under threat, no problem, roll on SHA-256. This process will go on for ever so we must incorporate it in anything we produce - like syslog-sign. And, given the state of syslog-sign, current editors still willing, I believe we can get those two I-Ds ready inside four monhts. The only realistic alternative would be to incorporate signature blocks in the style of syslog-sign in the structured data of the message being authenticated. Your suggestion has good reasoning behind it. I have not heard back from anyone about how SSL is currently being implemented for syslog. From that, I might conclude that message confidentiality is not a priority for the community. (Responses to that would be welcome.) If origin authentication, and loss detection are important then syslog-sign is a fit. Can we get some discussion on this? Thanks, Chris ___ 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
May I recommend TLS PSK or TLS in anonymous DH mode in preference to inventing your own transport that does not use PKI? Also, before doing something based on shared secrets carefully consider the requirements of RFC 4107. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
Replying to no-one specifically, I think one significant consideration is being missed. Basing security on a secure transport may already exist as an implementation but not as an I-D. I expect it to take at least 6 months, more like 12, to produce an IESG ready I-D. By that time, our long-suffering editor of syslog-protocol says he will have had to stand down. I believe that means we will never produce the two I-Ds needed for advancement and that the WG will shut down with nothing done. More hopefully, I do believe that the threats can be met by syslog-sign. Almost every user I talk to about security wants encryption. I have to work very hard to do so, but mostly succeed, in demonstrating to them that what they need is message origin authentication and integrity and it just so happens that that is what most IPS protocols offer, and, even better, it is much cheaper than encryption. I believe syslog falls into this category for most users, and that the aims of syslog-sign will meet most requirements. I hear it criticised for having the wrong algorithms. Fine, we must change that since every security system nowadays should be algorithm agnostic. MD5 got busted, fine we switch to SHA-1. SHA-1 under threat, no problem, roll on SHA-256. This process will go on for ever so we must incorporate it in anything we produce - like syslog-sign. And, given the state of syslog-sign, current editors still willing, I believe we can get those two I-Ds ready inside four monhts. The only realistic alternative would be to incorporate signature blocks in the style of syslog-sign in the structured data of the message being authenticated. Tom Petch ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Re: Threat model and charter
Hi Sam, I also have a concern that we may try to craft an answer that provides good security but that won't actually be deployed. As an analogy, snmp has similar characteristics to syslog. usm has good security properties but has not been widely deployed. isms is trying to redress that and is also getting bogged down in transport issues. RFC 3562 (Key Management Considerations for the TCP MD5 Signature Option) indicates that shared secrets don't get deployed unless there is a real threat. Even then, it takes a lot of effort to maintain those credentials across a very large network. Utilizing X.509 credentials has much better security properties but are the operations groups of large networks going to be willing to implement that? I would like to hear more discussion from developers, operators and network managers before we draw conclusions. Thanks, Chris On Wed, 11 Jan 2006, Sam Hartman wrote: I'm concerned that your analysis seems to be based on what is easy to implement. 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. 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. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Re: Threat model and charter
I think that you are leaping too soon into implementation space. That is why the threat model is requested first. Off the top of my head here are some components of the threat model. I organize these in terms of Asset, Threat, Mitigation. There are certainly more threats because I know I have left off all the environmental threats like fire, earthquake, backhoe, etc. There are probably more assets to consider. And each of these descriptions is very incomplete. Asset: Secrecy of message contents Threat: Network eavesdropping Mitigation: Encrypted transport or encrypted message Asset: Operational Characteristics of the network Threat: Traffic Analysis Mitigations: a) Encryption of identifying header contents (e.g., source identification) b) Encryption of transport c) blinding with random meaningless traffic between genuine end-points d) blinding with random meaningless traffic between falsified end-points Asset: Proper functioning of syslog receivers (data sinks) Threat: DoS attack (there are actually many) Mitigation: need to be enumerated. Asset: Messages reaching desired receivers Threat: Bogus masquerading receivers Mitigation: Transport with node identification. Note that message encryption prevents the receiver from reading the message, but it does not mitigate the issue that the message is lost because it goes to the wrong destination. Asset: Message integrity Threat: Message modification Mitigation: Digital checksums/ hash codes; digital signatures. and so forth. R Horn ___ 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] 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
