Re: [Syslog] Re: DISCUSS in draft-ietf-syslog-protocol - congenstion control (fwd)
tom.petch wrote: A second class of applications cannot maintain an RTT estimate for a destination, because the destination does not send return traffic. Such applications SHOULD NOT send more than one UDP message every 3 seconds, and SHOULD consider if they can use an even less aggressive rate when possible. So much for voice multicast? 3 seconds is a vast period of time. SNMP doesn't meet this requirement either. Nor should it. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Syslog-tls-09 draft - suggested change
Miao Fuyou wrote: My perception is logging does not necesarily mean send events over network to syslog server,. Webopedia says log is to record an action. If there is no syslog connection available, it is still possible to log the message in local storage. Right. The issue here, however, is that you've configured an application or a system to use the network and that has failed. What you do next requires a bit of care. That's all I'm saying. Eliot ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] Syslog-tls-09 draft - suggested change
Hi Dave, Does the third paragraph eliminate the need for the first two paragraphs? I think they need to be merged. Key parts are these: * SHOULD close the connection on failed authentication, and attempt to log an error * A discussion of the challenges of logging in such an environment. I think that boils down to this: vv If the hostname does not match the identity in the certificate, clients SHOULD log the error in some form or another (see below), and SHOULD terminate the connection (with a bad certificate error). Clients MAY provide a configuration setting that disables this check but MUST enable it by default. The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. Since this problem will prevent log messages from being transmitted, each device having this program should use whatever means are available to inform the administrator of the problem. This may include producing an error code on a console, returning an error to a user (if there is one), or writing a file to disk, being mindful that such writes should be rate limited in the case of attacks. ^^ So the above eliminates the distinction, and allows the necessary versatility that applications writers will need, given circumstances. I could envision a printer flashing the occasional E184 or some such. Please also note that I changed the setting text, the reason for that being that if there is a configuration knob to disable a check it only follows that there will be something enabled already ;-) You might disagree. Eliot David Harrington wrote: Hi, I am a bit concerned that most people will look at syslog as being an automated client and not a user-oriented client, and the paragraph from rfc2818 can be confusing if one does not consider the few exceptions. I recognized that my suggested text did exclude consideration of the few user-oriented cases, so I do not have a problem with my text being rejected on that point. But leaving the text from rfc2818 as is still has the same problem. I would be much more accepting of the text from rfc2818 if the automated client was discussed before the user-oriented client discussion: If the hostname does not match the identity in the certificate, automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. User oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. The application developer must take some care to consider the case when, for whatever reason, there is a problem with authenticating the other end of the connection. The connection SHOULD be closed and an error logged indicating the problem. Since this problem will prevent log messages from being transmitted, each device having this problem should use whatever means are available to inform the administrator of the problem. This may include producing a message on a console, returning an error to a user (if there is one), or writing a file to disk, if possible. Does the third paragraph eliminate the need for the first two paragraphs? dbh -Original Message- From: Eliot Lear [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 3:43 AM To: Miao Fuyou Cc: 'David Harrington'; [EMAIL PROTECTED] Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change Miao, TLS is still duplex even if syslog is simplex. In the same time, authenticaiton happens in the handshaking phase of TLS when syslog message transfering does not begin . So, simplex or duplex does not matter for authentication. I personally haven't liked those terms since 300 baud modems and 3270s went out of style ;-) I had persuaded myself that syslog sender is always hosted on automated application/appliance, such as web daemon or printer, this make it impossible for an user to check interactively whether umatched hostname/IP address is acceptable. However, I am suspecting the perception is wrong. It is possible to host syslog sender on a interactive application, such as database administration tool. This is not as simple a decision as may first appear. On the one hand, while you can come up with examples such as the above, and they really do exist (another good one is when you have some sort of Windows Watcher(*) that you want to log back to a central source), the two problems with reporting to the user are (a) the cases where there is no user and (b) the fact that operational experience has
Re: [Syslog] New -transport-tls ID - Need Reviews NOW
Hi Chris, I've taken a look at this document, and I have just two comments. In section 4.2.2: A client's certificate must be associated with a unique private key . Private keys MUST NOT be shared between clients. This is not part of the protocol, often beyond the control of the syslog implementor, and hence should be stricken. If you want to have a discussion about the shared use of private keys, please move it into Security Considerations with non-normative text. Similarly, Section 4.2.3 overreaches: Syslog applications MUST be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire. While I understand the desire for algorithm agility, this may not be possible in embedded applications. I would state this as a SHOULD. Eliot ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls
This is precisely the sort of thing that RFC 3195 attempted. You want authenticated source? You can have it. You want authenticated server? You can have that too. You can even have unauthenticated server with authenticated client. As we've just released a revision draft, I suggest people look that over. My guess is that the security considerations and the choices made here will require at least some additional review. Please draft-lear-ietf-syslog-rfc3195bis-00.txt. And that leads to my other question. Why are we implementing a separate TLS protocol when 3195 and its successor both exists and has been implemented? That seems to me rather redundant, and violates a tenant that we really should observe more: don't reinvent the wheel. Eliot [EMAIL PROTECTED] wrote: transport-tls should be designed to enable policy decisions. This group is not able to make policy decisions. Some of this discussion is really policy making. Policy discussions within syslog should be oriented towards ensuring that any reasonable policy can be properly supported. For example, in my real world situations, the primary policy concern is disclosure of audit information to unauthorized recipients. This means that the encryption aspect is most important, not the authentications. I can deal with a degree of uncertainty about the source and destination authentications. If you look inside what authentication really means to us you find several kinds of authentication to manage: - Is the source machine authenticated and authorized to be on the network? - Is the source machine/process authenticated and authorized to be a source of audit information? - The symetric questions for the destination machine. My destination accepts all connections and has different processing policies for incoming syslog information for the categories: - unauthenticated machine source - authenticated machine source, unauthenticated process - authenticated machine source and process The differences are a degree of confidence about various source characteristics. No authentication ensures complete confidence, because it is possible that both the source machine and process have been penetrated by a hostile attacker. The chain of trust to the various root certificate authorities is not important. Suppose I get a good certificate signed by the ABA. What does that mean? Does the ABA know what machines are authorized to be on my network? no. It means that someone with good credentials paid the ABA money to get a certificate for that identity. I will treat is as an unauthenticated machine. Suppose I get a certificate with a chain of signatures, the last of which is my local hospital administration. All those earlier signatures mean as little as the ABA signature. But that signature from the local hospital administration means something. Now I will consider this machine to be an authenticated machine source. (Process might still be unclear.) I don't need the rest of the chain. A self-signed hospital administration CA is good enough. This can save money and bother. The source side rule gets even stricter. A hospital administration CA signature is not enough. They sign all the internal machine certificates. I need the cert contents to be right. Or, (more commonly) I demand that the destination certificate match the single public cert that I provide to authenticated source processes for logging. This cert is self-signed by the syslog destination machine. The authorized internal machines and processes use this to ensure that they have connected to the right destination. Now I have all three different categories that derive from my policies. The chain of trust back to root CAs was not used much. What I really need is just the portion to the CA for the hospital. It might happen to be traceable to a root CA, but that doesn't matter in this situation. I can even live without it on a small network, by inverting the relationship and copying the self-signed public certs of the authorized source systems over to the destination server. This doesn't scale well, but for small networks it can be easier than setting up the local CA. R Horn ___ 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
[Syslog] Re: Why we're doing TLS
Sam, I got involved recently because both chairs asked me to submit a draft to revise 3195 to reflect the work of -protocol-19. I have done so. And so perhaps you can help me. The charter calls for a secure transport. The milestones say TLS (something that could easily be changed without community review, mind you). A reasonable person could believe that perhaps we might actually *build* on the work that was already done with SYSLOG/BEEP/TLS. As I'm relatively new to the party, I'll accept a pointer to the logic of the choice. There being an IPR claim against the new work, and the fact that multiple interoperable implementations of a proposed standard that could easily go to draft exist, I am hoping that pointer explains why this group is has put aside both interoperability and basic engineering principles of reuse. Eliot ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
Re: [Syslog] RFC3195bis
David Harrington wrote: Hi Eliot, Having discussed this further with you and Rainer, I tend to agree the changes are smaller than I originally thought. So that the WG can properly assess this, can you produce an individual draft with the proposed changes, so the WG can discuss the changes and their impact, and decide whether to accept the draft as a WG item at this point? Our pleasure. Look for one this week. Eliot ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
