Re: [Syslog] Some revised text for syslog TLS

["tom.petch" <[e-mail]>]

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)" <[e-mail]>
To: <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog