Joe, the current editor of -transport-tls, provided some suggested new text. I’ll call it 12+ and post it here for easy reference (I’ve too often searched the mail archive to pull it up, so I think it is time to post it at some easier place). Other than an aid to me, you may also be interested to see how things are progressing. All in all, I’d say we are on the right path. Also, rsyslog does now everythig mandated in 12+. I am currently looking into wildcards, this seems to be neat for easy authentication of many senders.
Here comes Joe’s text and the message that went along with it:
I reworked some of the text to try to capture the discussions in the
working group. I broke out the mechanical part of the validation from
the policy. There is some redundancy between the security
considerations section and the new policy section. I tried to focus the
requirements language on implementation requirements to enable secure
interoperability vs. deployment options. We are not finished yet, but I
think it is a step in the right direction.
Cheers,
Joe
4.2.1 Certificate-Based Authentication
Both syslog transport sender (TLS Client) and syslog transport receiver
(TLS server) MUST implement certificate-based authentication. This
consists validating proof of possession of the private key corresponding
to the public key in the certificate. To ensure interoperability
between clients and servers, the following methods for certificate
validation are mandatory to implement:
o Certificate path validation: the client is configured with one or
more trust anchors. Additional policy controls needed for authorizing
the syslog transport sender and syslog transport receiver are described
in Section 5. This method is useful where there is a PKI deployment.
o End-Entity Certificate Matching: The transport receiver or
transport sender is configured with information necessary to match the
end-entity certificates of its authorized peers (which can be
self-signed). Implementations MUST support certificate fingerprints in
section 4.2.3 and MAY allow other formats for end-entity certificates
such as a DER encoded certificate. This method provides an alternative
to a PKI that is simpler to deploy and still maintains a reasonable
level of security.
Both transport receiver and transport sender implementations MUST
provide a 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.
4.2.2 Certificate Fingerprints
Both client and server implementations MUST make the certificate
fingerprint for their certificates available through a management
interface.
The mechanism to generate a fingerprint is to take the hash of the
certificate using a cryptographically strong algorithm and convert the
result into colon separated, hexadecimal bytes, each represented by 2
uppercase ASCII characters. When a fingerprint value is displayed or
configured the fingerprint is prepended with an ASCII label identifying
the hash function followed by a colon. Implementations MUST support
SHA-1 as the hash algorithm and use the ASCII label “SHA1” to identify
the SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the
length of the corresponding fingerprint string is 64 characters. An
example certificate fingerprint is:
SHA1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D
During validation the hash is extracted from the fingerprint and
compared against the hash calculated over the received certificate.
[sections skipped]
5. Security Policies
Different environments have different security requirements and
therefore would deploy different security policies. This section
provides discusses some of the security policies that may be implemented
by syslog transport receivers and syslog transport senders. The
security policies describe the requirements for authentication,
credential validation and authorization. The list of policies in this
section is not exhaustive and other policies may be implemented.
5.1 Recommended Security Policy
The recommended security policy provides protection against the threats
in section 2. This policy requires authentication, certificate
validation and authorization of both the syslog transport sender and
syslog transport receiver. If there is a failure in the
authentication, certificate validation or authorization then the
connection is closed.
Authorization requires the capability to authorize individual hosts as
transport receivers and transport senders. When end-entity certificate
matching is used, authentication and certificate validation are
sufficient to authorize and entity. When certificate path validation
MUST support the following authorization mechanisms:
o Host-name-based authorization where the host name of the
authorized peer is compared against the subject fields in the
certificate. For the purpose of interoperability, implementations MUST
support matching the host name against a SubjectAltName field with a
type of dNSName and SHOULD support checking hostname against the Common
Name portion of the Subject Distinguished Name. Matching for
certificate credentials is performed using the matching rules specified
by [3]. If more than one host name identity is present in the
certificate a match in any one of the set is considered acceptable.
Implementations also MAY support wildcards to match a range of values.
For example, names to be matched against a certificate may contain the
wildcard character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com. Wildcards
make it possible to deploy trust-root-based authorization where all
credentials issued by a particular CA trust root are authorized.
o IP-address-based authorization where the IP address configured
for the authorized peer is compared against the subject fields in the
certificate. Implementations MUST support matching the IP address
against a SubjectAltName field of type iPAddress and MAY support
checking the configured IP address against the Common Name portion of
the Subject Distinguished Name. Matching for certificate credentials is
performed using the matching rules specified by [3]. If more than one
IP Address identity is present in the certificate a match in any one of
the set is considered acceptable.
Implementations MAY also support authorization based on other
attributes. For example, the authorization of a device Serial Number
against the SerialNumber portion of the Subject Distinguished Name or
restrictions on the depth of a certificate chain.
Implementations MUST support this policy and it is recommended that this
be the default policy.
5.2 Liberal Validation of a Syslog Transport Sender
In some environments, the authenticity of syslog data is not important
or it is verifiable by other means, so transport receivers may accept
data from any transport sender. To achieve this, the transport receiver
performs authentication and certificate consistency checks and forgoes
the validation of the certificate chain and authorization. In this
case, the transport receiver is authorized, however this policy does not
protect against the threat of transport sender masquerade described in
Section 2. The use of this policy is generally not recommended for this
reason. If this policy is used, the transport receiver SHOULD record
the end-entity certificate for the purpose of correlating it with the
sent data.
5.3 Liberal Validation of a Syslog Transport Receiver
In some environments the confidentiality syslog data is not important so
data may be sent to any transport receiver. To achieve this the
transport sender performs authentication certificate consistency checks
and forgoes validation of the certificate chain and authorization.
While this policy does authorize the transport sender, it does not
protect against the threat of transport receiver masquerade described in
Section 2, leaving the data sent vulnerable to disclosure and
modification. The use of this policy is generally not recommended for
this reason.
5.4 Liberal Syslog Transport Receiver and Sender Validation
In environments where security is not a concern at all the transport
receiver and transport sender authenticate each other and perform
certificate consistency checks and may forgo validation of the
certificate chain and authorization. This policy does not protect
against any of the threats described in section 2 and is therefore not
recommended.
6. Security Considerations
6.1 Deployment Issues
Section 5 discusses various security policies that may be deployed. The
only configuration that mitigates the threats described in Section 2 is
the recommended policy defined in section 5.1. This is the recommended
configuration for deployments.
If the transport receiver chooses not to fully authenticate, validate
and authorize the transport sender it may receive data from an attacker.
Unless it has another way of authenticating the source of the data, the
data should not be trusted. This is especially important if the syslog
data is going to be used to detect and react to security incidents. The
transport receiver may also increase its vulnerability to denial of
service, resource consumption and other attacks if it does not
authenticate the transport sender. Because of the increased
vulnerability to attack, this type of configuration is not recommended.
If the transport sender chooses not to fully authenticate, validate and
authorize the syslog transport receiver then it may send data to an
attacker. This may disclose sensitive data within the log information
that is useful to an attacker resulting in further compromises within
the system. If a transport sender operates in this mode it should limit
the data it sends to data that is not valuable to an attacker. In
practice this is very difficult to achieve, so this type of
configuration is not recommended.
Forgoing authentication, validation and/or authorization on both sides
allows for man-in-the-middle, masquerade and other types of attacks that
can completely compromise integrity and confidentiality of the data.
This type of configuration is not recommended.
6.2 Cipher Suites
[I think the mandatory to implement algorithm should be defined in
section 4.2 instead of the security considerations section]