RE: [Syslog] Syslog-tls-09 draft - suggested change
I think the working group had discussed the issue and actually the draft is written with: trusted mechanism such as a preconfigured hosts table or DNSSEC Regards, Miao -Original Message- From: Carson Gaspar [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 3:47 PM To: [EMAIL PROTECTED] Subject: Re: [Syslog] Syslog-tls-09 draft - suggested change [ re: DNS reverse mapping ] DNS is not secure, and isn't likely to be any time soon. Using DNS as any sort of security measure is just plain stupid. Either the other party possesses the private key material that matches their public key or they don't. If they don't, SSL will fail. If they do, then they're exactly who they say they are (or the private key material has leaked, at which point it's game over anyway). DNS should have nothing whatsoever to do with it. Any modern RFC that makes references to doing reverse lookups in a security context should be laughed out of the IETF. -- Carson ___ 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] Syslog-tls-09 draft - suggested change
There is also a matter of what an application is supposed to do when logging fails. Some applications should proceed uninterrupted. Others may need to block. I don't know whether text is appropriate. It's not part of the protocol, but it does fall under common modes of failure. The reason this would be an issue with TLS (or BEEP for that matter) and not with UDP is that one doesn't block with UDP. I think Eliot is on the right track. However, I wouldn't differentiate between the actions that a sender or receiver is to take when authentication fails - both cases should have a recommendation that the device log the failure _and_ attempt to inform the administrator of the problem. This might be pop-ups to the unsuspecting user who won't know what to do about it, it might be messages printed on the console, it might be a blinky light on the printer, etc. (Most networked printers that I'm seeing these days have nice displays that are starting to give informative messages.) 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. I just checked the printer in my office, it does log events locally. It is reckoned the buffer for log is very small because there are only 50 records, acutally the printer fails from time to time:-( Thanks, Miao ___ 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, On Tue, 24 Apr 2007, Eliot Lear wrote: 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 shown that the user really doesn't know what to do when there is a problem. On the other hand, we have another little problem in this specific case. What do we normally say when something goes wrong in one of our protocols? Log an error. Here that poses a little bit of a problem ;-) I would suggest text along the lines of the following: 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. In the case of a receiving relay or a receiver, the connection SHOULD be closed and an error logged, indicating the problem. In the case of a syslog sender or a transmitting relay, the situation requires more care. Here the application SHOULD also close the connection and also use whatever other means are available to it to inform the administrator of the problem. This may include producing a message on a console, returning an error to the user, or writing a file to disk, if possible. There is also a matter of what an application is supposed to do when logging fails. Some applications should proceed uninterrupted. Others may need to block. I don't know whether text is appropriate. It's not part of the protocol, but it does fall under common modes of failure. The reason this would be an issue with TLS (or BEEP for that matter) and not with UDP is that one doesn't block with UDP. I think Eliot is on the right track. However, I wouldn't differentiate between the actions that a sender or receiver is to take when authentication fails - both cases should have a recommendation that the device log the failure _and_ attempt to inform the administrator of the problem. This might be pop-ups to the unsuspecting user who won't know what to do about it, it might be messages printed on the console, it might be a blinky light on the printer, etc. (Most networked printers that I'm seeing these days have nice displays that are starting to give informative messages.) Perhaps this text: 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. In addition, you have another problem in the text: If the client is configured with IP address of the server, the hostname should be got first through a trusted mechanism such as a preconfigured hosts table or DNSSEC [8]. It is often the case that a reverse map does not match a forward map. For example, often times a service provider might allocate IP address space and route that space to a customer but not delegate the reverse mapping. This is particularly true in consumer environments. I would suggest that if the client is configured with an IP address, that it is what should be present in the certificate, as the name has no meaning at all to the client. I think that's an operational issue that we're not going to deal with. We're talking about a domain of administration here. We're not going to be able to write enough text into this document to cover the case where the administrators cannot line up dNSName with an IP address within their own purview. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org
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] Syslog-tls-09 draft - suggested change
Hi, I'm OK with this proposal with two minor changes. - rather than (see below) it should have (see next paragraph) - remove parenthasis from (with a bad certificate error) as that text is normative. 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. ^^ Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
