RE: [Syslog] transport-tls-11 review
Thanks for your comments! Response inline. -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 9:13 AM To: Miao Fuyou; 'Rainer Gerhards'; [EMAIL PROTECTED] Subject: Re: [Syslog] transport-tls-11 review snip === The server MUST be implemented to support certificate and certificate generation, === I do not think it is a MUST that a server must contain code to generate certificates. This should be left to the implementation. There is already the requirement to use certificates, so IMHO it is not the business of an IETF document to specify how they are provided. For example, I would provide a helper app with my syslog implementations, but not include it in the core app - it doesn't belong there. Need more opinion from the working group. I agree with Rainer OK, to be updated in new revision. And I see some idiosynchratic wordings that MIGHT be changed. 2. Security Requirements for Syslog syslog messages may pass several hops ** not really pass, suggest transit It is recommended to use dNSName in the certificate rather than any other type subjectAltName for certificate verification, such as ipAddress. **suggest iPAddress (ie PKI not SNMP) Ok, thanks! 4.2.2. Client Identity If a server authenticates a client and the client presents a certificate to the server, the server MUST validate the certificate. Validation includes constructing a certificate path to one of the configured trust anchors and validating that path. However, identity check is not required even if subjectAltName is presented in the certificate. **I do not understand how failing to check the identity provides protection against Masquerade, as we claim in s.2 SubjectAltName is not necessarily unique for different certificates. ** suggest The subjectAltName OK, thanks! 5.1. Authentication and Certificates Mutual authentication means the TLS client and server are provisioned with necessary trust roots **suggest trust anchors as in the next paragraph OK, thanks! . If a server does not have a certificate and key/pair configured **unclear what the solidus is doing - '/' usually means either/or Typo, should be key pair. The server MUST be implemented to support certificate and certificate generation, and certificate validation MUST be implemented for all clients. The Syslog client SHOULD be implementated to support **implemented certificate and certificate generation, and certificate validation SHOULD be inplemented for Syslog server. **These both read oddly to me - what is the support for certificate (certificates?) as distinct from support for certificate generation and certificate validation? If I support certificate (without qualification), then I expect that to convey support for every aspect thereof so the validation and generation is redundant but, as I agreed with Rainer above, I think that generation should not be a MUST. There are two way for a server to have a certificate: be configured with one, or generate one by itself. The support certificate is actually to cover the first case. I agree that is not a exact terminology. What is your suggestion? Since a receiver may act upon received data, for syslog over TLS, it is recommended that the server authenticate the client to ensure that information received is authentic. **this seems to weaken the claim earlier that TLS defends against the listed threats - by now I am feeling confused about what protection is being offered by what. To meet the claims of s.2, I think we need both server and client to check certificates for suitable identities and to follow a chain to a trust anchor - I have no problem with describing other scenarios but think that each such scenario should then be qualified with a comment to the effect that this MAY not defend against threats ... as identified in s.2 Perhaps authentic is not an exact term, how about it is recommended that the server authenticate the client to ensure that information received is from trusted client. 5.2. Cipher Suites Operators MAY choose to disable older/weaker cipher suites for TLS despite the tradeoff of interoperability, for example, if the cipher suite specified in the specification is found weak in the future. **suggest Operators MAY choose to disable cipher suites for TLS that are regarded as too weak for the environment in which this specification is being used, especially older cipher suites. This MAY lead to a reduction of interoperability. It is likely that, in time, the cipher suite specified here will become subject to attack and the use of it will too be deprecated. OK, thanks! ___ Syslog mailing list Syslog
RE: [Syslog] Authentication, certificates, trust anchor, cipher suite and deployability for syslog/tls
Hi Anton, Thanks for your feedback! Environment where active attack is concern: The server is configured with certificate, but the client is not to be required to be configured with a certificate. The client can generate a selt-signed certificate by itself. Why do you need a self-signed certificate here? What purpose does it serve? The client MAY use a self-signed certificate. You are not proposing using it for client authentication here, are you? Not exactly. This is to explore various possible options with regard to certificate, perhaps it is not necessary to appear in the specification. What is that? Let's be more specific if you intend to put this in the doc (same goes for names of these 3 scenarios). I think this configuration does two things: encryption and server authentication. Active attack involves an attempts to change information by contrast with passive attack. To be more specific, it is man-in-the-middle attack is this case. but is vulnerable to client spoof. Security insensitive environment: Both the client and server are not required to be configured with certificate and trust anchor. They generate self-signed certificates. Again, why do you need client self-signed certificate here? It is very easy for deployment because almost there is no configuration required. Note this configuration is vulnerable to active attack. More specifically, this configuration provides only encryption, but no authentication. Which configuration should be mandatory? I seems we need not a mandatory configuration from the PoV of implementation, right? However, we do need to mandate the implementation (both client and server) to support certificate configuration, trust anchor configuration, and self-signed certificate. Let's separate what is required for implementation, and what is required for deployment. I think server MUST implement be deployed with a server-based certificates for this transport. Whether it is self-signed or CA-signed can probably be left to a deployment choice. If it is self-signed, then effectively no server authentication is done, just encryption. The other part is client authentication. I think the server MUST support authenticating clients with certificates and client authentication is OPTIONAL for deployment. The minimum authentication that server MUST support is validating the client certificate against trusted CA. OK. A more secure server MAY also want to implement a mechanism which prevents an authenticated client from masquerading as something else in the messages that it emits. For example, 1mln certs may be signed by the same CA, but we don't want one client with one such cert to be able to masquerade as any of the 1mln other clients. To accomplish this, the server need to take client identity from CN field of the certificate and either validate it against some field in syslog message, or at least plug the CN value into the syslog message structured data, so that admin can do whatever validation he/she desires when needed. I think it is good to describe this additional client authentication consideration, but leave it as OPTIONAL. I think we discussed standardizing a unique CN field value before and it was not fruitful. Standard syslog structured field name for CN value would be a good idea. Good idea, but I tend to not mix the content with its tranport. BTW, TLS transport is hop-by-hop protocol rather than an end-to-end protocol, so it will have difficulties to decide the content when the client is just a relay. We will need to specify a cipher suite (probably RSA-AES-CBC) for inter-operatability, We need to specify at least 2 because one of them may become vulnerable after standard is released and software is deployed. The client MUST advertise support of cipher suite X Y. Server will select the appropriate one based on its configuration for the TLS session. Server should not be forced to select one of those two. I don't think there is any server requirement here. As for specific cipher suites, it will probably be a religious debate. Maybe IETF has a policy on this? I have seen one other standard require these two: * RSA_WITH_3DES_EDE_CBC_SHA * RSA_WITH_RC4_128_SHA RC4 is for stream application, does it apply to Syslog/TLS? RFC4346 mandates TLS_RSA_WITH_3DES_EDE_CBC_SHA, however, I think 3DES is a interim algorithm. Actually TLS 1.2 draft mandates TLS_RSA_WITH_AES_128_CBC_SHA. My only concern would be that at least one of them (or better both) is popular enough to be in most of today's major TLS implementations. Regards, Anton. but probably we don't need to specify different cipher suites for 3 various ssenarios because all the scenarios above requires certificate for key pair generation. Regards, Miao
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] I-D ACTION:draft-ietf-syslog-transport-tls-08.txt
Hi, As Chris pointted out, a new draft will be published in one or two days to replace this one because of rectification of an error. Sorry for your inconvenience! Thanks, Miao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, April 21, 2007 3:50 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Syslog] I-D ACTION:draft-ietf-syslog-transport-tls-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : TLS Transport Mapping for Syslog Author(s) : F. Miao, M. Yuzhi Filename: draft-ietf-syslog-transport-tls-08.txt Pages : 11 Date: 2007-4-20 This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of Syslog messages. This document describes the security threats to Syslog and how TLS can be used to counter such threats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpor t-tls-08.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-syslog-transport-tls-08.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-syslog-transport-tls-08.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Note to editors
Hi, I reckon this happens because the date in the front part of the XML file is not updated. date day=28 month=February year=2007 / Or you could use the web to do the conversion: xml.resource.org. Regards, Miao -Original Message- From: Alexander Clemm (alex) [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 14, 2007 2:18 AM To: David Harrington; [EMAIL PROTECTED] Subject: RE: [Syslog] Note to editors David, I am using the xml2rfc tool, which inserts these automatically. However, the copyright statement does show 2006, not 2007, when I generate the draft now. What would you like to do? It seems preferrable that IETF should get xml2rfc updated. Thanks --- Alex -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, March 12, 2007 9:30 PM To: [EMAIL PROTECTED] Subject: [Syslog] Note to editors Hi, We have crossed into 2007. Please make sure any copyrights in your document reflect 2007, not 2006. This includes the standard copyright, but also internal copyrights in MIB modules, etc. Please make sure the IPR boilerplate and any other copyrights have been updated to RFC 4748, which recognizes the IETF Trust. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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 mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
Yes, peer entity authentication is seperate from integrity, this is addressed in section 3 of the current document. Client only authenticaiton is not available in TLS, so I think it is safe to say peer entity authention instead of sender authenticaiton. Probably it is appropriate to say something in section 3 of the document like Secure transport only secures syslog in a hop by hop manner, end to end message stream modificationis threat is not addressed in this document. Thanks, Miao -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 11:56 PM To: Miao Fuyou Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls I recommend that you drop message stream modification if my analysis [At this point, we're still figuring out what we want to say. I'm speaking as an individual not an AD.] of the charter is a correct analysis and we meant for that to apply to syslog-sign. I recommend you split out peer entity authentication as a separate service from integrity. And point out that by integrity, you mean that the sender knows that the data is not modified between the sender and the receiver; by peer entity authentication in this case we want to focus on whether the receiver knows who its peer is. So, perhaps we should cll that sender authentication. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
Sam, The following paragraphs are on how well different authentications address the security threats for syslog. Masquerade, modification and disclosure are identified in the draft as primary threats and message stream modification as secondary threat. Mutual Authentication: Masquerade: fully addressed Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed Server Authenticaiton Only: Masquerade: partly addressed, the client is left without being authenticated Modification: fully addressed Disclosure: fully addressed Message Stream Modification: fully addressed No Authentication: Masquerade: not addessed Modification: not well addressed because of MITM Disclosure: not well addressed because of MITM Message Stream Modification: not well addressed because of MITM Thanks, Miao -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 5:37 PM To: Miao Fuyou Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls I'll get back to you on the generic certificates issue. For now, I recommend you read RFC 4107. Also note that each device needs a unique MAC address so the manufacturing process tends to have a step for making a device unique. So, it sounds like all forms of authentication are optional in this spec. You need a clear table describing what attacks are protected against given each authentication choice. Wording that table so that man-in-the-middle issues are dealt with correctly and it is still informative will be tricky. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls
Hi, I think there are other things to consider to decide SHOULD or MUST an authentication:: 1, From deployment perspective, it is not very difficult to enable server authentication because the population of servers is usually not as many as that of clients, the certificates are only required to be created for the server rather than plenty of clients: printers, routers and hosts. So, I think server authentication is not a major reason for the operator to not deploy TLS. However, client authentication is highly possible the reason because the considerable effort for device certificate deployment. 2, If no authentication exists, it is possible for an adversary to launch a MITM attack when TLS connection initializes, it talks with server pretending to be client and client to server. In this case, no confidentiality and integrity is conserved. So, I would like server authenticaiton to be a MUST rather than SHOULD. For client authentication, it may be SHOULD, even MAY. Thanks, Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 12:32 AM To: David Harrington; tom.petch; Miao Fuyou; Sam Hartman; [EMAIL PROTECTED] Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog-transport-tls David, let me start with the relays: given the recent discussion, I think it would be much more advisible to add a few sentences to -protocol (I already made a proposal) that clarifies the situation. It is not much that needs to be added. It would resolve all those other issues. Regarding generic certificates, I do not see an overwhelming reason to have them (and I was one of them who liked them). I agree with Sam that there can be placed unique certificates on the device during the manufacturing process. Another story, however, is the need to authenticate/verify a device. Without any doubt, there is more than one scenario where authentication based on the device is mandatory. However, syslog is also often deployed in (low end) scenarios where the (part-time) operator is simply interested receiving log messages from his 5 or so routers. This admin is often not very knowledgable. If we now require that admin to either a) configure access rules for all (though few) devices or b) use unencrypted UDP syslog I am sure many of these admins will resort to b) because a) requires too much learning. In the essence, strong security/authentication would bring us less real-world security (pretty much the same thing with strong passwords ... so strong that they are stored on post-it notes under the keyboard). So I would not like to see client and server authentication to be a MUST. Well ... a MUST for an implementation to have that capability would be OK. But an admin must be capable to configure sender and/or receiver to work without authentication. No matter what we specify in -protocol, that capability will be available in all implementations that I foresee. IMHO an uncoditional MUST would create a false sense of security ... and the most insecure thing is false sense of security. Rainer -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 5:14 PM To: 'tom.petch'; 'Miao Fuyou'; 'Sam Hartman'; [EMAIL PROTECTED] Subject: RE: Relays was Re: [Syslog] AD Review fordraft-ietf-syslog- transport-tls Hi WG, [speaking as co-chair] As co-chair, I will need to advise Miao to remove support for generic certificates unless there is overwhelming WG consensus to keep them, and the explanation of why reuse of private keys is necessary will need to be compelling. Please read RFC4107 (which is short). There are ambiguities in the TLS document regarding who MUST authenticate that will need to be tightened up. As the email from Tom reflects, part of the problem is the ambiguity in the definition of relay; I think it needs to be made clearer in the -protocol- document that a relay is a receiver and is a sender, and clearer in the -tls- document that authentication is hop-by-hop. Personally, I think we should make authentication more mandatory than is currently described, but the WG needs to reach such a consensus. If we keep the optional authentication(s), then the WG should justify in the document why it makes protocol sense for the authentication(s) to be optional. The WG needs to develop the table showing how the various authentication options mitigate threats, especially MITM threats, and we should have text that describes this as well. Please work with Miao to address these issues. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 12:53 PM To: Miao
RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
Section 2 identifies masquerade as a major security threat for syslog. In the draft, client authentication and server authentication are SHOULDs(server authenticaiton may be not spelled out explicitly). After reading RFC2818 once again, I think the server authentication may have to be a MUST for the specification to mitigate the MITM, while client authentication (mutual authentication actually) may still be kept SHOULD. If generic certificate is not right to be reccomended in an IETF specification, probably we have to remove it from the draft. Thanks! Miao -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 5:37 PM To: Miao Fuyou Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] AD Review for draft-ietf-syslog-transport-tls I'll get back to you on the generic certificates issue. For now, I recommend you read RFC 4107. Also note that each device needs a unique MAC address so the manufacturing process tends to have a step for making a device unique. So, it sounds like all forms of authentication are optional in this spec. You need a clear table describing what attacks are protected against given each authentication choice. Wording that table so that man-in-the-middle issues are dealt with correctly and it is still informative will be tricky. --Sam ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] AD Review for draft-ietf-syslog-transport-tls
Hi Sam, Thanks for the review! My response is inline. Regards, Miao -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 31, 2007 7:23 AM To: [EMAIL PROTECTED] Subject: [Syslog] AD Review for draft-ietf-syslog-transport-tls Hi, folks. I had no comments on the UDP draft or the main protocol draft so I have forwarded them to IETF last call. I do have some concerns with the TLS draft. First, I think the idea of generic certificates will not meet with consensus of the security community. It may be OK to use the same Subject name for all cable modems from a given vendor, but reuse of private keys is not something we should recommend in an IETF standard. The working group discussed the issue of generic certificate, and one paragraph is included in security consideration to remind the risk of using generic certificate. Syslog client may be implemented on mass device, such as set top box, cable modems. In such case, provisioning unique certificate (basically keys) is a huge cost for the operator, and the generic certificate is preferred by operator. That is why it is introduced into this document. In general, preferring dnsname subjectAlternativeName to CN in the subject field seems preferable. Why does this specification use cn rather than either always using dnsname or using a procedure similar to that in RFC 2818. I checked rfc3280, dNSName subjectAltName is preferrable to common name. Thanks for correcting it! The text seems confused about what authentication is required when. Section 5.1 implies that authentication of receivers is optional but the text requires it. Yes, authentication of receiver is optional. Probably one more sentence in section 4.2 is required to spell out it explicitly. Are senders and relays required to have a certificate and to use that certificate? It is not required, but it is preferrable for some deployment where malicious senders may send lots of messages to overwhelm the receiver. --Sam ___ 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] RFC 3164 in syslog-sign?
Option 2 may be a better choice for a cohesive set of Syslog specifications. And, a seperated informational document can be included as work item when rechartering to address the 3164 signature issue. Is it possible? The drawback is the implementer has to do something different for -protocol and 3164. Thanks, Miao -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, December 21, 2006 10:20 AM To: [EMAIL PROTECTED] Subject: [Syslog] RFC 3164 in syslog-sign? Hi, We started syslog-sign before we had Structured Data, and the original author was creating a mechanism that could be used within the RFC 3164 framework. However, times have changed. We now have syslog-protocol with SDs. Does the WG feel that syslog-sign should contain normative information on how to utilize the syslog-sign mechanism in the RFC 3164 format? Answers can be: __ Yes - leave it, it forms a bridge for transition, __ No - take it out, we need to move the world along, __ Maybe - move it to a non-normative appendix Thanks, Chris -- Forwarded message -- Date: Wed, 20 Dec 2006 15:51:25 +0100 From: Rainer Gerhards [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt Chris, -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 20, 2006 3:37 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt ---some elided for brevity--- With RFC 3164 syslog, we obviously can not totally be assured that the SD-ID will be valid. But we should keep in mind that we most probably will try to obsolete 3164 either via -protocol or a follow-up RFC. I already questioned the point in supporting this (informational!) document in a new standard. Is this really a wise idea? Rainer ---remainder elided for brevity--- ___ 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: Framing...
Yes, exactly.
Thanks,
Miao
-Original Message-
From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 12:58 AM
To: David Harrington
Cc: 'Rainer Gerhards'; 'Chris Lonvick'; 'Miao Fuyou'; [EMAIL PROTECTED]
Subject: Re: [Syslog] RE: Framing...
On Mon, Dec 18, 2006 at 11:18:56AM -0500, David Harrington wrote:
The chairs believe there is consensus, and will ask Miao to
change the
-tls- document to say that FRAME-LEN is the count of the
octets of the
SYSLOG-MSG.
Perhaps also consider to change FRAME-LEN to MSG-LEN to
better reflect the purpose of the value.
/js
--
Juergen Schoenwaelder {International|Jacobs}
University Bremen
http://www.eecs.iu-bremen.de/P.O. Box 750 561,
28725 Bremen, Germany
___
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Framing in syslog-transport-tls
Hi, My co-workers in university also encountered this issue when implementing syslog-tls, and used a mechanism similiar to the one of Rainer to overcome it. As I am aware of, currently there are two syslog framing implementation and both the implementaters considered this boundary condition. So, my perception is careful implementater would have no problem, and a note for reminding is enough. Regards, Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 4:34 PM To: syslog@lists.ietf.org Subject: [Syslog] Framing in syslog-transport-tls Miao, WG, I have partially implemented syslog-transport-tls in two different programs (MonitorWare Agent and rsyslog). My focus was the framing, not tls itself (I needed the new framing for some other functionality, but that is a separate story). I would like to share my experience during that implementation. This is *not* necessarily a request for change. I just though that might also come up during IETF last call, so I think the information is useful. FRAME-LEN is a variable length field. It specifies the length of the frame including the length of FRAME-LEN itself. This is no real problem for the receiver. On the sender side, however, it is a bit tricky. I need to obtain the length of the ASCII-encoded field including the (potentially changing) size of itself. Let's look at a sample. We have a message with 996 octets. Now I obtain the information that I need 4 octets to encode this (996 ). I need to add that to the total message length, bringing me up to 1000 octets. Now, I need to re-check my buffer requirements. I now learn that I need a 5 octect encoding. This I need to add to the previous length of the message (996), resulting in a total frame length of 1001 octets. If we would just count the MSG part of the frame, there would be no such ambiguity, because I would set FRAME-LEN to whatever size I know the MSG part has. It would be 996 in this case. However, that would mean we have two different framing mechanisms inside the frame - octet stuffing (the SP) after the count and then octet counting for the rest of the message (I think http uses such a mechanism, but have not verified). On the other hand, I can easily implement the current specification with few lines of code. Here is a C sample of the code I actually use in rsyslog: iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), %d , len); iLenBuf = snprintf(szLenBuf, sizeof(szLenBuf)/sizeof(char), %d , len + iLenBuf); Where len is the length of SYSLOG-MSG and iLenBuf the total frame length. For context, see http://rsyslog.cvs.sourceforge.net/rsyslog/rsyslog/syslogd.c?r evision=1. 159view=markup and scroll down to line 1766. Initially, I was of the view that it would be advisable to think about changing -transport-tls so that the octet count is just the length of SYSLOG-MSG. After some thinking, I now believe that it is fine as it currently is specified. I suggest a sentence warning to implementors to point to the potential mis-implementation. On the other hand, a receiver must rely on the octet-stuffing in any case. Because it needs to find the SP in order to find the end of the octet count. That would be an argument to contain only the size of SYSLOG-MSG in the counter. Given the fact that -transport-tls is already submitted to the IESG AND there is no real problem with the current specification, I propose not to change it (except for adding a warning as outlined above). Sorry for the late catch, but these things seem to only appear when you actually implement... I would appreciate comments on the issue. Rainer ___ 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] Near Final Shepherding Document fordraft-ietf-syslog-transport-tls-05.txt
The references are split into normative and informational references. The document is dependant upon There is no informative reference any longer because we removed RFC3164 sentences from the document. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
I am changing the sentence to: For the deployment where confidentiality is a concern, receiver authentication is required for sender/relay to make sure it is talking to the right peer. It is up to the operator to decide whether confidentiality is a concern for a specific deployment. This sentence serves as a tip for deployer rather than something about on-the-wire protocol. Thanks, Miao -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 8:27 AM To: 'Rainer Gerhards'; 'Miao Fuyou'; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 2:48 AM To: Miao Fuyou; [EMAIL PROTECTED] Subject: RE: [Syslog] Updated Syslog-tls Document - 5.1 == When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. == I do not find the MUST is appropriate here: when confidentiality is a concern is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of when confidentiality is a concern. Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. Probably lower case. The point is confidentility is meaningless without authenticaion. Well... maybe it is just a wording issue. Are we actually REQUIREING a sender to authenticate the receiver in all cases? If so, we should state that. My impression so far is that this is something that is optional and at the discretion of the sender or the operator configuring it. If so, we should state that clearly too. As an implementor, I am unsure what to do if I use the above text as a guideline. Standards do not typically require an operator to use the technology in a specific manner; Standards do typically require implementers to implement in a way so that operators CAN configure the technology in the preferred (interoperable) manner. MUST is used when the on-the-wire format/information/etc. must be interoperable for the protocol to work properly. I do not like seeing must in a document; either it deserves to be a MUST, i.e. it impacts on-the-wire interoperability, or it is an implementation/usage decision and we should not mandate it. If you use a lower case must, then you'll need to convince me as co-chair that the usage is justifed before I send it to the IESG. Dbh ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Towards closure of syslog-tls issues
Hi, Unfortunately (or fortunately), there are several issues raised after the chair start shepherding process. As the editor, I would like close the issues as soon as possible, and get the doucment updated. 1, Version. The wg seems have concensus on removing version from the transport mapping this time. If there is a objection, please reply. If no, I would remove it. 2, RFC3164. There is a proposal to remove RFC3164 support from the draft. I tend to accept the proposal. Please comment if you have a different idea! 3, Ciphersuite. Tom proposed to specify cipher suite in the transport document, but I still don't find necessity to do so. I tend to agree to Rainer's proposal: http://www1.ietf.org/mail-archive/web/syslog/current/msg01305.html 4, ABNF issues. I will change format back to %d format. 5, Receiver authentication when confidentiality is concern, from MUST to must, and probably some more sentences about receiver authentication is required. Please feedback if you have different ideas to the proposals above! Thanks! Regards, Miao ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
I questioned the need for a version number for the TLS transport in private conversation and now I bring this up again here. Was that private? I thought it was on-list. Anyhow... I The public messege can be found at: http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html It seems there was a rough concensus that the version number was welcomed to save port resource when we discussed this issue on the mailing list. That is the reason why a version number is there. This does not at all sound very convincing to me (and I assume what the author wanted to say is not well said because I believe the trigger for not trying again would be a close after sending the first syslog message and not after the successful TLS handshake). I, too, assume this was meant... Yeah, this sentence should be improved if version number is kept there. But my suggestion is to remove the version as well as this text. So do I now... ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
The public messege can be found at: http://www1.ietf.org/mail-archive/web/syslog/current/msg01273.html It seems there was a rough concensus that the version number was welcomed to save port resource when we discussed this issue on the mailing list. That is the reason why a version number is there. Agreed, I am guilty of not saying I agree on the mailing list. But to me that did not look like consensus but simply an overlooked message (there were no responses at all...). Don't feel guilty because you did say I applaude:-) http://www1.ietf.org/mail-archive/web/syslog/current/msg01198.html I also found support from other active WG members. Anyway, let's reconsider the decision and make it right! Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Updated Syslog-tls Document
Hi, Rainer, Thanks for your thorough review! Some responses are inline. - 3.0 == The security service is also applicable to BSD Syslog defined in RFC3164 [7]. But, it is not ensured that the protocol specification defined in this document is applicable to BSD Syslog. == Do we really intend to support RFC 3164-style syslog (read: nothing known about the message format) over this transport? If so, the consequence is that implementations of -transport-tls must check for 3164 format and eventually be able to handle it. I suggest removing these two sentence, as it looks we encourage that case. If they stay, we should clearly state that a receiver is NOT REQUIRED to implement this. Agreed. More comments from WG is welcome! - Section 4.3, inside the ABNF: SP = I think this is problematic in respect to 2.4 of RFC 4234. I suggest replacing by SP = %d32 I checked the ABNF with: http://rtg.ietf.org/~fenner/abnf.cgi It seems the tools suggest to use rather than %d32. I checked RFC4234, it says that it permits the specification of literal text strings directly, enclosed in quotation-marks. I will changed it back to %d32 to keep it consitent with the syslog protocol. - 5.1 == When confidentiality is a concern, a sender/relay MUST authenticate the receiver to make sure it is talking to the right peer. == I do not find the MUST is appropriate here: when confidentiality is a concern is not a hard fact. What does it mean? When MUST I implement authentication. Is my Implementation not compliant to this doc if I have the wrong understanding of when confidentiality is a concern. Or MUST I always implement it, because confidentiality is probably very often a concern? I think this is a operator-issue not to be dealt with in the protocol. I suggest dropping this sentence or at last spell MUST in lower case. Probably lower case. The point is confidentility is meaningless without authenticaion. - 5.2 Isn't that a security consideration (and belongs to that secition)? RFC3552 request the residual risk should be descripted in the security consideration section. The section is about residual risk of generic certificate. - 6.2 IANA registry names must be suggested (of course this comment is irrelevant if we drop VERSION). - Consistent Spelling Both version and VERSION is used for the respectively-named field. I suggest to resort to a single spelling. This also removes some ambiguities if the version field or the concept of a version is meant in some parts of the text. I suggest using VERSION consistently for the respective field. Agreed. - Security Considerations is missing I wonder I didn't spot this earlier. IMHO any document must have a Security Considerations section. Of course, the whole document talks about security, but does that obsolete the section showing the weaknesses of the protocol? Section 5 is Security Consideration, but maybe I should add a S to it (Security Considerations):-) For example, I have at least three candiates to be included: - Problems in relay scenario A relay may receive data via traditional syslog and forward it via a tls-encrypted channel to its next destination. In this case, the channel to the next hop is secured, but the trust level of the message is considerably lower. - there is no rule that a sender must use the same host name inside the -protocol HOSTNAME field as it uses in the certificate's common name. I think that has some security implications. TLS transport does not check HOSTNAME in syslog message because transport must not depend on content of the payload (or else a relay must check the content of each message). - cipher suites and such are left to the operator. We should indicate the (serious) consequences of this selection - One note on the cipher suites: I know there has been some discussion previously, but I wasn't able to find the post in question in the archive. Probably you can help me out. Question: how do we guarantee a minimum interoperability of implementations of this document if we do not specify any cipher suite? Tom and I discussed this issue on the mailing list. TLS protocol has its mandatory suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA), and TLS specification says that if application profile(syslog-tls in this case) does not specify a mandatory cipher suite, TLS mandatory suite will apply. So, no need to specify one in this specification. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Draft Shepherding documentfordraft-ietf-syslog-protocol-18.txt
Some implementation information about syslog-tls: I asked some graduate students in an university to implement the specification. The implementation is based on openssl and rsyslog. The implementation was finished on October and proved it works. The implementation implemented version number and use user_canceled TLS alert to indicate a unsupported version number. === Having passed a WG Last Call, draft-ietf-syslog-transport-tls-04.txt is ready for AD review. -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 11:28 PM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] Draft Shepherding documentfordraft-ietf-syslog-protocol-18.txt Chris, Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No one has come forth to claim that they have an existing implementation of this protocol at this time. No vendors have announced that they will utilize this protocol. Some vendors have indicated interest in supporting this document. The above named reviewers did an outstanding and thorough job. Though not a major application, I have implemented syslog-protocol-15 in rsyslog. Please see: http://www.rsyslog.com/index.php?module=Static_Docsfunc=view; f=/syslog- protocol.html at least, it is open source and other can have a look at it. I plan to update the implementation as soon as I have the impression the draft will move on without any futher changes or discussion. -transport-tls is not yet implemented but will probably happen within the same timeframe (also based on the impression that there won't be any major change). Rainer ___ 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] Updated Syslog-tls Document
to the right peer. 5.2. Generic Certificate When a certificate is issued to a class of device or application, the certificate may be shared by multiple hosts. Multiple hosts know the private key of the certificate. When the certificate in one host is compromised, then the certificate for all hosts that share the certificate is compromised. An attacker may impersonate a legitimate sender to send Syslog message to a receiver. 6. IANA Consideration 6.1. Port Number IANA is requested to assign a TCP port number in the range 1..1023 in the http://www.iana.org/assignments/port-numbers registry which will be the default port for Syslog over TLS, as defined in this document. 6.2. VERSION IANA must maintain a registry of VERSION values as described in Section 4.3.2. Version numbers MUST be incremented for any new Syslog TLS transport mapping specification that changes any part of the frame or other parts. Changes include addition or removal of fields or a change of syntax or semantics of existing fields. VERSION numbers must be registered via the Standards Action method as described in RFC2434 [3]. IANA must register the VERSIONs shown in table 1. +-+-+ | VERSION | FORMAT | +-+-+ | 1 | According to this specification | +-+-+ Table 1: Version Number Miao Yuzhi Expires May 25, 2007 [Page 8] Internet-Draft TLS Transport Mapping for Syslog November 2006 7. Acknowledgments Authors appreciate Eric Rescorla, Anton Okmianski, Rainer Gerhards, Balazs Scheidler and Chris Lonvick for their effort on issues resolving discussion. Authors would also like to appreciate Balazs Scheidler, Tom Petch and other persons for their input on security threats of Syslog. The author would like to acknowledge David Harrington for his detailed reviews of the content and grammar of the document. 8. References 8.1. Normative References [1] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [2] Gerhards, R., The syslog Protocol, draft-ietf-syslog-protocol-17 (work in progress), June 2006. [3] Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998. [4] Housley, R., Polk, W., Ford, W., and D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April 2002. [5] Crocker, D., Ed. and P. Overell, Augmented BNF for Syntax Specifications: ABNF, RFC 4234, October 2005. [6] Dierks, T. and E. Rescorla, The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346, April 2006. 8.2. Informative References [7] Lonvick, C., The BSD Syslog Protocol, RFC 3164, August 2001. Miao Yuzhi Expires May 25, 2007 [Page 9] Internet-Draft TLS Transport Mapping for Syslog November 2006 Authors' Addresses Miao Fuyou Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: [EMAIL PROTECTED] URI: www.huawei.com Ma Yuzhi Huawei Technologies No. 3, Xinxi Rd Shangdi Information Industry Base Haidian District, Beijing 100085 P. R. China Phone: +86 10 8288 2008 Email: [EMAIL PROTECTED] URI: www.huawei.com Miao Yuzhi Expires May 25, 2007 [Page 10] Internet-Draft TLS Transport Mapping for Syslog November 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an AS IS basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might
[Syslog] RE: syslog/tls - how to abort because of inconsistent versions
Hi, There are several possible options to solve this issue: 1, Using a TLS alert to signal the inconsistent versions as the current draft does. The drawback is it violate the layer, using TLS alert to notify an application event seems ugly. 2, Saving the data (TLS app-data, not syslog message, different to UDP transport) no matter what the version is. This may mean a receiver should be able to save a stream without any knowledge about the structure of the stream. The data can not be stored in the same file/database to the one for syslog messages, because it has no way to delimit frames. 3, Change the simplex of syslog, add an application level notification from receiver to sender, this may increase the effort of implementation greatly, 4, Do nothing, the sender may keep connecting the receiver. But, we can recommend in that specification like if connections are closed just after successful TLS handshake for three times with same transport mapping version, the sender SHOULD not connect the receiver again with the same transport version. Does it work? My preference is 4 1 2 3. Miao -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Saturday, October 21, 2006 2:55 AM To: Miao Fuyou Cc: 'David Harrington'; [EMAIL PROTECTED] Subject: RE: syslog/tls - how to abort because of inconsistent versions Hi Miao, We need this issue resolved in the WG. Please bring up the discussion on the list with a proposal. I suggest that we not use TLS to signal a failure in the upper level. Thanks, Chris On Thu, 19 Oct 2006, Miao Fuyou wrote: Hi, Eric, One clarification to version #: syslog/tls version is the one for syslog/tls transport mapping, but syslog version # is the one for syslog-protocol, they are diffirent numbers. When a receiver gets a message with a **syslog version number** it does not understand, it could save the message in local storage or forward to other receiver because it know exact the boundary of the message (actually a receiver does not have to understand the version of syslog protocol in most cases, because the only task for receiver is to store or forward). But, this may not apply to syslog/tls transport mapping. Diffirent **syslog/tls version number** may mean diffirent APP-DATA format. A receiver with a diffrent version may not be able to parse the stream or delimit syslog messages, the only thing that it can do is to save the tls stream in local storage if it is linient. But, saving stream seems ugly, maybe more ugly than making tls alert to serve application:-) Thanks! Miao -Original Message- From: EKR [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 10:02 AM To: Miao Fuyou Cc: 'David Harrington'; [EMAIL PROTECTED]; 'Chris Lonvick' Subject: Re: syslog/tls - how to abort because of inconsistent versions Miao Fuyou [EMAIL PROTECTED] wrote: Hi, Eric, The primary reason to use a TLS level notification to notify an event for application level is to keep Syslog still simplex, but it seem violative to clear layership. An application notification will change that simplex of syslog, which is alien to syslog. The wg is in the dilemma to process this issue. Your sugestion? Well, I see that draft-ietf-syslog-protocol-17.txt contains a version #. What do you do if that is something you don't understand? -Ekr ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Diffs on -protocol and -transport-udp
I had reviewed -protocol, -udp and -signing, and with several minor comments on -protocol and -signing. I believe the documents are in good quality for being published as RFCs. Thanks! Miao -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Thursday, September 14, 2006 4:35 AM To: [EMAIL PROTECTED] Subject: [Syslog] Diffs on -protocol and -transport-udp Hi Folks, We need some more reviews of our documents. There has been some discussion that the documents havn't changed much since the last time we went through a WGLC. I've made some diffs of -protocol and of -transport-udp so you can see what changes have been made. Diff from protocol-14 and protocol-17 http://www.employees.org/~lonvick/diff-14-17.html Diff from transport-udp-05 and transport-udp-07 http://www.employees.org/~lonvick/diff-udp-07-05.html Please look these over and comment to the WG list that you have done so. At a minimum your review to the group should be that you have read the document and are satisfied with its quality and content that it can become an RFC. 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: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document
Starting from TCP and then upgrading to tls is quite different to current tls transport mapping document. If we decide to do UPGRADING, we may first need a TCP transport mapping for Syslog, and then define a specific string to indicate the other side to upgrade to TLS. We currently assume Syslog has a IANA allocated port for tls transport mapping, we may not need such complexity on upgrading. FYI, HTTP has two tls mechansims: RFC2818(standards track) is similiar to this draft, RFC2817(Informational) is on upgrading. -Original Message- From: tom.petch [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 06, 2006 2:51 AM To: Balazs Scheidler; Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLastCall: syslog-tls document - Original Message - From: Balazs Scheidler [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 9:18 AM Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working GroupLast Call: syslog-tls document On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: Hi All, Please do consider the version field. If we don't have one, we would have to live forever with the decisions we are making now. Having a version number in there would allow a future group to re-decide things (like byte-count v. special character) and to just change the version number rather than go asking for a new port number - or have a flag day. Please review the document and send in your thoughts on this. Sending the version field is a good idea in general, however I feel that adding it to _every single_ message in a conversation is too redundant, apart from the extra bandwidth used, it causes ambiguities what to do when different messages use a different version number. The version should be associated with the channel, and not individual messages. Having a simple negotiation at the start would IMHO be way better. Something like: HELLO capabilities OK capabilities START OK message stream I too like starting with a simple negotiation. I notice that other applications that started with TCP and then added security have used character strings such as AUTH TLS which has the advantage of readily adding in SSH (or anything else) in the future. I also like being able to add later a choice as to which end is client and which server since I foresee problems here with security credentials (most other applications have the server on a well-connected device well able to verify secuirty credentials, something a remote network box is less well able to do). Tom Petch -- 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 ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: version field in syslog-tls - was: RE: [Syslog] Working Group Last Call: syslog-tls document
Good point. I am considering make the version only available at the beginning of Syslog messages stream to reduce redundency. But, I don't like capabilies negotiation here because it adds extra complexity to implementation. Thanks! MIao -Original Message- From: Balazs Scheidler [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 3:19 PM To: Chris Lonvick Cc: [EMAIL PROTECTED] Subject: Re: version field in syslog-tls - was: RE: [Syslog] Working Group Last Call: syslog-tls document On Mon, 2006-09-04 at 15:49 -0700, Chris Lonvick wrote: Hi All, Please do consider the version field. If we don't have one, we would have to live forever with the decisions we are making now. Having a version number in there would allow a future group to re-decide things (like byte-count v. special character) and to just change the version number rather than go asking for a new port number - or have a flag day. Please review the document and send in your thoughts on this. Sending the version field is a good idea in general, however I feel that adding it to _every single_ message in a conversation is too redundant, apart from the extra bandwidth used, it causes ambiguities what to do when different messages use a different version number. The version should be associated with the channel, and not individual messages. Having a simple negotiation at the start would IMHO be way better. Something like: HELLO capabilities OK capabilities START OK message stream -- 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] Working Group Last Call: syslog-tls document
Hi, One major change to the document is a version field for Syslog TLS transport is added to the frame header. The field is to make port reusing possible if the transport mapping document is updated in the future. An IANA paragraph is added accordingly. Another change is about frame length bounding, Min-max values(MUST, SHOULD) are added to the document. The two changed was made after discussion between editors and chairs. Discussion and feedback is welcome! Thanks! Miao -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 5:48 AM To: [EMAIL PROTECTED] Subject: [Syslog] Working Group Last Call: syslog-tls document Hi, This message officially starts the Syslog Working Group Last Call for the following document: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-03 .txt The Working Group Last Call for this document will end September 12. To help get these document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, if it does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG ___ 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 mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Working Group Last Calls
Sorry, the comments are for syslog-protocol. Thanks! -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 5:10 PM To: '[EMAIL PROTECTED]' Subject: RE: [Syslog] Working Group Last Calls Hi, Some my review finding: 1, originator is used twice in the document without terminology definition, original sender is used in other paragraphs for the same entity, replace originator with original sender? 2, Section 8.4,Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.', Signature is only one option for message integrity. My suggestion is to change it to Message or transport integrity mechansim could be used to prevent the alteration TIMESTAMP of the message or message delivery sequence. 3, TimeStamp: when timestamp is set, by whom? An originator or relay? I can not find in the doc. BTW, TIMESTAMP can be utilized to avoid a forward loop descripted in section 8.9, if it is set by originator. Thanks! Miao -Original Message- From: David Harrington [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 2:35 AM To: [EMAIL PROTECTED] Subject: [Syslog] Working Group Last Calls Hi, The WGLC for -protocol-17 and -udp-07 documents will end later today. Please review and comment on these documents today. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] timeline
Rainer, Stunnel is a secure wrapper for TCP stream. Actually delimiting Syslog is done in the TCP part rather than TLS (or stunnel) part in Syslog-ng with stunnel. One can use stunnel to secure any Syslog TCP transport, such as rsyslog and kiwisyslog, and kiwisyslog does use CRLF for delimiting (http://www.kiwisyslog.com/whats_new_syslog.htm). Stunnel implementation is different from Syslog TLS transport, and I don' t think it is the exact implementation of Syslog TLS transport. I have not been aware of a Syslog implementation in TLS-transport style till now. So, most of the implementation may be modified, slightly or heavily, to existing code to get it comply to the specification. Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 12:41 PM To: Miao Fuyou Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] timeline Miao, I am actually concerned about backward compatibility with existing code *without* the need to upgrade any of that code. As you know, deployed software tends to stick. If we use just LF, existing, deployed technology (e.g. syslog-ng with stunnel) would be able to understand a message sent from a new style syslogd. Having the octet count in front of the message removes that ability, as the old syslogd will no longer see the pri at the start of the message. I agree that it is trivial to modify code to take care for the octet counter. But this is not my concern. My concern is that I would like to achive as good as possible compatibility with existing deployed (aka unmodified) technology. I should have been more specific on that. Sorry for the omission... I am also unaware of any implementation that mandates CR LF over just LF. Could you let me know which ones are these? Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 7:07 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] timeline Hi, Rainer, A new implementation could rely on byte-counting only and then delete LF from the frame(appplication knows exactly where the LF is), it may not force us to use escapes. For LF, I think it is difficult to get 100% compatibility for a legacy implementation to comply TLS-transport without any change to the code. At least, some imlementation may need to change CR LF to LF because some implementations use CR LF rather than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP from the frame. I still prefer byte-counting only to byte-counting+LF even if it is a feasible tradeoff. Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 10:18 PM To: Miao Fuyou Subject: RE: [Syslog] timeline We should not go byte-counting + LF. This is the worst choice: it A) breaks compatibility B) Forces us to use escapes So we get the bad of both worlds, without any benefits. Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 12:58 AM To: 'Anton Okmianski (aokmians)'; 'David Harrington'; [EMAIL PROTECTED] Subject: RE: [Syslog] timeline My vote: byte-counting only byte-counting + LF LF ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] timeline
Hi, Rainer, A new implementation could rely on byte-counting only and then delete LF from the frame(appplication knows exactly where the LF is), it may not force us to use escapes. For LF, I think it is difficult to get 100% compatibility for a legacy implementation to comply TLS-transport without any change to the code. At least, some imlementation may need to change CR LF to LF because some implementations use CR LF rather than LF. So, it may be ok to add several LOC to delete FRAME-LEN SP from the frame. I still prefer byte-counting only to byte-counting+LF even if it is a feasible tradeoff. Miao -Original Message- From: Rainer Gerhards [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 10:18 PM To: Miao Fuyou Subject: RE: [Syslog] timeline We should not go byte-counting + LF. This is the worst choice: it A) breaks compatibility B) Forces us to use escapes So we get the bad of both worlds, without any benefits. Rainer -Original Message- From: Miao Fuyou [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 12:58 AM To: 'Anton Okmianski (aokmians)'; 'David Harrington'; [EMAIL PROTECTED] Subject: RE: [Syslog] timeline My vote: byte-counting only byte-counting + LF LF ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Notes on TLS transport
S 5.3: All Syslog messages MUST be sent as TLS application data. There MAY be multiple Syslog message in the same TLS record. The application data is defined with the following ABNF [3] expression: TLS's abstraction is as a stream, so this isn't really the business of htis spec. I agree to Eric's opinion. If syslog procotol has a mechanism to delimit message, we will never need to address same issue across different documents: syslog-tls, syslog-ssh, or syslog-tcp etc (perhaps with different mechanisms). ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Notes on TLS transport
My suggestion would be to stick with standard TLS practice here and have the sender be the server. This sentence confused me, is the sender should be receiver? Thanks! ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Other syslog-tls Issues---Issue 1 and 2
[Issue 1]: Is it possible to use generic certificate for different host? The generic certificate is for specific application type. [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- NAME(generic certificate)? APP-NAME binding makes authentication/ access control happens both in TLS handshake and Syslog message processing, is efficiency a problem? ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Other syslog-tls Issues---Issue 4
[Issue 4]: Shall we mandate the sender MUST be authenticated? Most of the Syslogd accepts messages only from configured address. ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Preliminary syslog-transport-tls document
Hi, The TLS transport draft now is ready for your comments and recommodations. Some issues are identified in the documents, which should be discussed in the mailing list. I list the issues here. [Issue 0]: Do we need a Syslog TCP port for TLS transport? The security community had debates about whether using special ports is desirable. [Issue 1]: Is it possible to use generic certificate for different host? The generic certificate is for specific application type. [Issue 2]: What to bind to a certificate? Hostname, Syslog APP- NAME(generic certificate)? APP-NAME binding makes authentication/ access control happens both in TLS handshake and Syslog message processing, is efficiency a problem? [Issue 3] The problem of CR LF is it can not process binary data well. How to process Syslog signature/certificate message? [Issue 4]: Shall we mandate the sender MUST be authenticated? Most of the Syslogd accepts messages only from configured address. Sorry for attaching, once IETF lifts the limitation of internet-draft publish after IETF conference #65 , I will get it published. Regards Miao SYSLOG Working Group F. Miao Internet-Draft M. Yuzhi Expires: September 16, 2006 Huawei Technologies March 15, 2006 TLS Transport Mapping for SYSLOG draft-miao-syslog-transport-tls-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 16, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the security threats to Syslog and counter measures of using Transport Layer Security(TLS) protocol for such threats. Different phases are defined for using TLS to secure Syslog, such as initiation, sending data and closure phase. Miao Yuzhi Expires September 16, 2006 [Page 1] Internet-Draft TLS Transport Mapping for SYSLOG March 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Requirement of Syslog . . . . . . . . . . . . . . . . 3 3. Introduction of TLS . . . . . . . . . . . . . . . . . . . . . 4 3.1. How TLS works . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Security Properties . . . . . . . . . . . . . . . . . . . 4 4. TLS to secure Syslog . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5 5.1. protocol Port . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Sending data . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7 6.1. TLS and Syslog Signature . . . . . . . . . . . . . . . . . 7 6.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 8 6.3. TLS Session Resumption . . . . . . . . . . . . . . . . . . 8 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Miao Yuzhi Expires September 16, 2006 [Page 2] Internet-Draft TLS Transport Mapping for SYSLOG March 2006 1. Terminology The following definitions are used in this document: o A sender is an application that can generate and send or forward a
