[Syslog] Some revised text for syslog TLS
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 23 May 2008 18:40 UTC
Return-Path: <syslog-bounces@ietf.org>
X-Original-To: syslog-archive@megatron.ietf.org
Delivered-To: ietfarch-syslog-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BCE28C2ED; Fri, 23 May 2008 11:40:09 -0700 (PDT)
X-Original-To: syslog@core3.amsl.com
Delivered-To: syslog@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB2523A6BBC for <syslog@core3.amsl.com>; Fri, 23 May 2008 11:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7fhTcSKLHZ9 for <syslog@core3.amsl.com>; Fri, 23 May 2008 11:40:07 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 93B3F3A6BD1 for <syslog@ietf.org>; Fri, 23 May 2008 11:40:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,531,1204531200"; d="scan'208";a="71796555"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 May 2008 11:40:06 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4NIe65q008517 for <syslog@ietf.org>; Fri, 23 May 2008 11:40:06 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4NIe6K0008764 for <syslog@ietf.org>; Fri, 23 May 2008 18:40:06 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 11:40:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 23 May 2008 11:40:52 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE505DFD90C@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Some revised text for syslog TLS
Thread-Index: Aci9BIbqo/w6J1eNRCCueVc7JY86Vg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: syslog@ietf.org
X-OriginalArrivalTime: 23 May 2008 18:40:06.0002 (UTC) FILETIME=[6B6F1520:01C8BD04]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10124; t=1211568006; x=1212432006; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Some=20revised=20text=20for=20syslog=20TLS |Sender:=20; bh=+/+Bjd2R6y1WOcE6JxvbEtbj5NFy99zmcDus6rG0MIQ=; b=JZKKwbj15ye8WKWCyW8g5C2urRrxCcCTHlpkgr3gCxFivVRnxALdoAZzHk toQ5KdzCdPTzKThKoy4Js/pNs2l2SWD5tNYicuhV/pSo4EvwFgUIx7TmYWJ/ 7dJX/wtwHLpj96d33j5Gzs1fBXC3nDAvofkKP9kmdKSh0YrdZL9D4=;
Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Subject: [Syslog] Some revised text for syslog TLS
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org
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 Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- [Syslog] Some revised text for syslog TLS Joseph Salowey (jsalowey)
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte
- Re: [Syslog] Some revised text for syslog TLS Moehrke, John (GE Healthcare)
- Re: [Syslog] Some revised text for syslog TLS Anton Okmyanskiy (aokmians)
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS robert.horn
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS robert.horn
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte