Joe Looks good. Once we have sorted out the technicalities eg fingerprints and iPAddress, you might consider some polishing of the text, in two regards.
In places, I have a sense of a security expert (which you are) talking to a security expert (which I am not) and think the text needs clarifying. eg "This consists validating proof of possession of the private key corresponding to the public key in the certificate". If this sentence were absent, I would not have noticed it; being there, I stop and think, what is it telling me, am I missing something? Or "Certificate path validation: the client is configured with one or more trust anchors"; ditto, if that were absent, I would not have noticed. And, as in the first sentence I quote, there seem to be some words or phrases missing; as I say, let's sort out any technical changes and then I will revisit the wording Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, May 23, 2008 8:40 PM Subject: [Syslog] Some revised text for syslog TLS > 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] > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
