[Syslog] Notes on TLS transport
Eric Rescorla <ekr@networkresonance.com> Mon, 07 August 2006 03:37 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvy-0004e8-Uj; Sun, 06 Aug 2006 23:37:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9vvx-0004dz-2o for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400
Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9vvw-0006GW-Ac for syslog@ietf.org; Sun, 06 Aug 2006 23:37:41 -0400
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 13121222425 for <syslog@ietf.org>; Sun, 6 Aug 2006 20:45:41 -0700 (PDT)
To: syslog@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Sun, 06 Aug 2006 20:37:39 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060807034541.13121222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955
Cc:
Subject: [Syslog] Notes on TLS transport
X-BeenThere: syslog@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@lists.ietf.org>
List-Help: <mailto:syslog-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@lists.ietf.org?subject=subscribe>
Errors-To: syslog-bounces@lists.ietf.org
I just finished reading: draft-ietf-syslog-transport-tls-02.txt draft-petch-gerhards-syslog-transport-dtls-00.txt Comments below. It seems like it would be nice to have a consistent approach to the generic question of who is the TLS client and who is the TLS server and client. The TLS draft specifies that the receiver is the TLS server but the DTLS draft can work either way. As I understand draft-petch-gerhards-syslog-transport-dtls, the argument for allowing the sender to be the server is: (a) authentication for the sender is what's important. (b) concerns about performance on the syslog device/sender I don't think (b) turns into an argument for reversing the client/server roles. The expensive step is the RSA signature or decryption and that needs to be performed by the authenticating party. Moreover, it's really not *that* expensive. I would expect it to take a second or so on all but the lowest power devices--though there used to be reports that the Dragonball processors in palms had particularly bad bignum performance. My suggestion would be to stick with standard TLS practice here and have the sender be the server. Having the server have a certificate isn't that big an obstacle, especially if it's self-signed. draft-ietf-syslog-transport-tls-02 ---------------------------------- S 3.1: report errors. Then, there is an ongoing layered record protocol that handles encryption, compression, and reassembly for the I would say, "encryption and message integrity" rather than "encryption, compression, and reassembly" S 3.2: Confidentiality is provided using symmetric cryptography for data encryption. TLS supports both stream cipher and block cipher. The key for encryption is derived from a secret established by the handshake protocol. The secret is kept private even if there is an eavesdropper in the middle. This only obtains if at least one sid ie authenticated. Integrity is provided by using HMAC [6] (computed with a secure hash function) to check the integrity of a message. Modification without the appropriate key is detectable. I would just say "a Message Authentication Code (MAC)". Future versions of TLS may not use HMAC. Authentication is provided by a handshake protocol. The peer's identity is authenticated using a certificate and signature, based on asymmetric cryptography. TLS server auth is often done by proving possession of the private exponent by doing an RSA decryption rather than a signature. TLS client auth is typically with a signature. S 5.2: TLS uses certificate [5] to authenticate the peers. When a sender authenticates a receiver it MUST validate the certificate. It SHOULD check the common name(CN) of the certificate against the host name of the receiver if it has knowledge of a common name/host name mapping. If the common name does not match the host name, the sender SHOULD send an "access_denied" error alert using the TLS alert protocol to terminate the handshake, and then it SHOULD close the connection. Do you want to cite RFC 2818 here? Also, some clarity about whether the sender is expected to validate the receiver's cert would be helpful. Similarly, is sender auth required? another active session when a new session is requested, in order to save the expense of another TLS handshake. The security parameters of the resumed session are reused for the requested session. The certificate MUST be checked when resuming a session. If the resumed session and current session use different certificates, resumption MUST not happen. The security parameters SHOULD be checked against security requirement of requested session to make sure the resumed session provides proper security. Resumed sessions do not involve a certificate exchange, so there's no way the certificate could be different. Similarly, the security parameters are always the same. 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. S 6.1: TLS authentication and the establishment of secrets is based on certificates and asymmetric cryptography. This makes TLS transport much more expensive than UDP transport. An attacker may initialize many TLS connections to a receiver as a denial of service attack. Since a receiver may act upon received data, for Syslog over TLS, the receiver SHOULD authenticate the sender to ensure that information received is authentic. TLS is more expensive than non-TLS. The issue of TCP vs. UDP is kind of orthogonal. S 6.2: 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. Any communication that is bound to the certificate is at risk. It depends what you mean "at risk". Say you have two clients who share the same cert. If client A is compromised, then the attacker can impersonate client B, but it can't view data on or tamper with a channel that client B actually established. The situation is a bit more complicated for servers and depends on which cipher suite you're using (PFS of not). S 6.3: Different applications in the same host may have different security levels (e.g., the kernel may have higher a security level than a document editor application). If a requested session resumes an existing session, then the requesting application can decrypt the Syslog messages of the resumed session using same cipher parameters as defined for the resumed session. When a session is being resumed from an application with a different security level, care must be taken to avoid disclosing sensitive data to an unauthorized application. A sensitive session must not be resumable. This isn't clear to me. It depends a lot on how the keying material is handled. You need to explain the threat model a lot more clearly here.. draft-petch-gerhards-syslog-transport-dtls-00 --------------------------------------------- S 1.4: connections - which may not be suitable for the application; DTLS offers the option of TLS over UDP, adding reliability to UDP but without all the additional features that TCP brings. As such, it offers an attractive security option for UDP-based applications. Reliability is added *only* for the handshake, not data transport. S 1.6: Most applications which now run over TLS were previously running over TCP and as such already had an application level dialog. In order to invoke TLS, these applications could then change their start command (eg STARTTLS) or, having established a TCP connection, invoke TLS (eg AUTH) to make the connection secure. I'm not sure I agree with this characterization. E.g., neither HTTP [2818] nor SIP [3261] behaves this way. You just have a separate port. S 2.1: A consequence of this mapping, of DTLS client to syslog server, is that where certificates are used for server authentication, then the syslog server is the one that has to verify the syslog client's certificates (something that it is likely to have the greater resources to do). The syslog client must have a certificate; the syslog server certificate remains optional. Cert verification is actually fast. It's being the authenticating party that's slow. S 2.8: This probably isn't necessary. -Ekr _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
- [Syslog] Notes on TLS transport Eric Rescorla
- Re: [Syslog] Notes on TLS transport Eric Rescorla
- RE: [Syslog] Notes on TLS transport Miao Fuyou
- RE: [Syslog] Notes on TLS transport Miao Fuyou
- RE: [Syslog] Notes on TLS transport Miao Fuyou
- Re: [Syslog] Notes on TLS transport Eric Rescorla