Transport Layer Security (TLS) Transport Mapping for Syslog
updated by
- rfc-9662 — Updates to the Cipher Suites in Secure Syslog
Extracted elements (23)
End-entity certificate matching (including self-signed certificates) is supported as an alternative to PKI to provide a simple-to-deploy option that still maintains a reasonable level of security, making the protocol accessible in environments without a full PKI deployment.
TLS secures syslog transport only on a hop-by-hop basis and does not address the contents of syslog messages. The authenticated identity of the transport sender (e.g., subject name in the certificate) is not necessarily related to the HOSTNAME field in the syslog message; end-to-end message origin authentication requires a separate mechanism such as signed syslog.
To establish a baseline for interoperability, transport receivers MUST be able to process syslog messages up to 2048 octets and SHOULD support up to 8192 octets; there is no per-specification upper bound on message length.
A transport receiver MUST use the message length field to delimit syslog messages. A transport receiver MUST be able to process messages up to and including 2048 octets; SHOULD be able to process messages up to and including 8192 octets.
A transport sender MUST close the TLS connection and MUST send a TLS close_notify alert before closing if no further syslog messages are expected. The transport receiver MUST reply with a close_notify unless it knows the connection is already closed.
Both client and server implementations MUST make certificate fingerprints available through a management interface. Implementations MUST support SHA-1 as the hash algorithm with the ASCII label 'sha-1'; a SHA-1 fingerprint string is 65 characters long.
Both syslog transport sender and receiver MUST implement certificate-based authentication using either certification path validation (PKI) or end-entity certificate matching (including self-signed certificates).
Both transport receiver and transport sender implementations MUST provide means to generate a key pair and self-signed certificate in the case that a key pair and certificate are not available through another mechanism.
If a locally configured name is an internationalized domain name, conforming implementations MUST convert it to ASCII Compatible Encoding (ACE) format before performing comparisons, as specified in RFC 5280 Section 7.
If a peer does not meet the requirements of the configured security policy, the TLS handshake MUST be aborted with an appropriate TLS alert.
Implementations MUST support certification path validation and MUST support matching a locally configured host name against a dNSName in the subjectAltName extension. Wildcard certificates (left-most label only) MUST be supported but MAY be disabled via configuration.
Implementations MUST support end-entity certificate based authorization by specifying authorized peers using certificate fingerprints as described in Sections 4.2.1 and 4.2.2.
Implementations MUST support TLS 1.2 and are REQUIRED to support the mandatory cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. Future TLS versions' mandatory cipher suites MUST also be supported.
Syslog applications SHOULD be implemented to permit administrators to select the cryptographic level and authentication options as a matter of local policy. Security parameters of a resumed TLS session SHOULD be checked against the requirements of the new session.
A syslog transport sender is always a TLS client and a transport receiver is always a TLS server. TCP port 6514 is the default port for syslog over TLS.
Certificate fingerprints are computed by hashing the DER-encoded certificate with a cryptographically strong algorithm and encoding the result as colon-separated uppercase hexadecimal bytes prepended with the hash algorithm label (e.g., 'sha-1:E1:2D:...'). Implementations MUST support SHA-1 fingerprints.
IANA assigned TCP port number 6514 in the 'Registered Port Numbers' range with the keyword 'syslog-tls' as the default port for syslog over TLS as defined in this document.
Mutual authentication of transport sender and receiver (Sections 5.1 and 5.2) are the RECOMMENDED default policy configurations. Unauthenticated configurations risk accepting attacker data, disclosing sensitive log content, or enabling denial-of-service and resource consumption attacks.
Operating with an unauthenticated transport sender does not protect against sender masquerade, and operating with an unauthenticated transport receiver exposes data to disclosure and modification. Both unauthenticated configurations are NOT RECOMMENDED; running without any authentication is especially NOT RECOMMENDED as it enables man-in-the-middle and masquerade attacks.
The primary threats addressed by this specification are masquerade, message modification, and disclosure. TLS counters these through mutual authentication, integrity checking, and confidentiality. A secondary threat is message stream modification (deletion, replay, reordering), which is partially mitigated by TCP but not fully by TLS alone.
The syslog TLS transport uses no application-layer acknowledgments. If the TLS session or TCP connection breaks, the transport sender cannot determine which messages were successfully delivered to the syslog application.
When using subject name authorization, the authorized name SHOULD be locally configured and SHOULD NOT be obtained via DNS lookup, as DNS lookup introduces additional security vulnerabilities into the certificate validation chain.
All syslog messages MUST be sent as TLS 'application data' framed as SYSLOG-FRAME = MSG-LEN SP SYSLOG-MSG, where MSG-LEN is a decimal octet count (NONZERO-DIGIT *DIGIT) and SYSLOG-MSG is the syslog message per RFC 5424. Multiple messages may share one TLS record or span multiple records.