[Syslog] Document shepherd report of AD concerns
"David Harrington" <ietfdbh@comcast.net> Thu, 15 May 2008 18:02 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 530CF3A6970; Thu, 15 May 2008 11:02:26 -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 549703A693C for <syslog@core3.amsl.com>; Thu, 15 May 2008 11:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599]
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 3KyyHfVo52-v for <syslog@core3.amsl.com>; Thu, 15 May 2008 11:02:20 -0700 (PDT)
Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id BA94C3A6888 for <syslog@ietf.org>; Thu, 15 May 2008 11:02:20 -0700 (PDT)
Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id Rs1g1Z0071GXsucAA09400; Thu, 15 May 2008 18:02:15 +0000
Received: from Harrington73653 ([24.128.66.199]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id Ru2B1Z0024HwxpC8T00000; Thu, 15 May 2008 18:02:13 +0000
X-Authority-Analysis: v=1.0 c=1 a=BADePFR4w3MA:10 a=_FMh2nk8A7-pj9NjLREA:9 a=WmpYkHaHJySgUQxV94AA:7 a=P2R5pV__3fkTAXNCv5WVamCAad0A:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10
From: David Harrington <ietfdbh@comcast.net>
To: syslog@ietf.org
Date: Thu, 15 May 2008 14:02:10 -0400
Message-ID: <07c101c8b6b5$cd5bcb20$0600a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Aci2tcvqceaP6oScSc+DZiE7D64PrA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Subject: [Syslog] Document shepherd report of AD concerns
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
Hi, Tom asked for a review of the IESG concerns. As document shepherd, let me address that question. This email shows the AD comments as the draft progressed since -11-. Some WG input was also taken into consideration during the document revisions. Following the publication of -11-, Sam Hartman said: "Dave, the syslog tls document is much clearer and I think it does a good job of specifying what implementations need to do. I think this is a huge improvement. However I have two major problems. 1) The default/recommended configuration requires managed trust anchors, a working DNS deployment and certificates provisioned to syslog servers. I do not find it plausible that operators will actually do this and so I do not find the specification credible. 2) The spec talks about caching of certificates in a manner similar to ssh, but does not discuss operational concerns such as key rollover. Jeff, any chance you could help the syslog working group understand the tradeoffs around leap of faith? " Jeff Hutzelman provided expert advice on behalf of Sam: "I can try. It may be worth noting that I don't think ssh talks much about server key rollover, and it certainly isn't done much in practice. What does happen is server keys changing because of a machine being reinstalled or some similar event. The approaches open to SSH in that case (prompt the user, or just notify them and fail so they can fix it and try again) don't work so well with syslog, where the originator of a message likely can't fix the problem, and the way to notify the person who can is to send a syslog message!" Then the AD token passed from Sam to Pasi, who suggested: "Here's one idea how to handle certificates for TLS in order to make it reasonably secure (in most cases), yet also deployable: - When a tranport sender configures the address of transport receiver, and enables TLS, allow the following choices: 1) configure set of trust anchors, and a name to be matched against the cert. If the transport receiver address is configured as DNS name, this name would usually be the same one. If the transport receiver address is configured as IP address, this one could be IP address (but could be also a domain name). (Note: in no situation, the result of A/AAAA or PTR lookup would be used when checking the certificate. This part of the current spec isn't correct.) 2) configure the "certificate fingerprint" of the peer (typically a 40-digit hex string). Cut-and-pasting that from one SSH window to another isn't the world's friendliest UI, but would be doable by admins, and is couple of orders of magnitude less work than setting up a real PKI. 3) configure "anything goes, don't verify the cert" (obviously, not very secure; SHOULD NOT be done) - A transport receiver would have similar choices: 1) configure set of trust anchors, and a list of names (or wildcards matching names) to be matched against the certificates; everyone listed here would be OK. 2) configure list of certificate fingerprints that are OK. 3) configure list of transport (IP) addresses/netmasks that are allowed to send messages regardless of the certificate (obviously, not very secure; SHOULD NOT be done) - I've intentionally omitted "SSH style leap of faith" (called "MAY cache the certificate presented by its peer so it can compare the certificate with what is presented in subsequent connections" in current spec). . It could be added (but has some operational issues); or we could specify slightly similar (but not quite) functionality where instead of typing in the 40-digit fingerprint, the management interface would fetch the fingerprint from the peer, show it to the administrator, and the admin would then compare it against something (e.g., what he/she sees in some other SSH window), and confirm that they match. There are some issues with this, though.... (user studies made with similar approaches show that most users click "yes, they match" even when shown two totally different values). - We probably need to require that everyone must be able to generate a keypair and self-signed certificate, and calculate/display the fingerprint of the certificate (in some management interface). Has something like this (in particular, using the fingerprint in cases where deploying PKI isn't feasible) suggested before? Do you think it would be operationally workable? If you think this might make sense, I can post something on the mailing list, too. But this is just one preliminary idea -- if there are other ideas that would solve the issues, I'm in no way saying it must be done this way." Joe did a revision which Paso reviewed, and commented: "Joe: thanks for working on this; I think we're making good progress, and I'm optimistic that we could get this draft done soon. However, some of the TLS/certificate related text in version -11 was *really*...err... unclear, so I think we need to rewrite it to some extent before taking it to the WG list (fortunately, the whole text is only two pages, so this shouldn't be too much effort). We also have an option (fingerprints) that wasn't present before, so we need to recheck the WG consensus anyway. Some proposed text fragments from me (Joe, please feel free to edit as you like): 4.2 TLS typically uses certificates to authenticate peers. Authentication and authorization of the TLS server (transport receiver) is described in Section 4.2.1; authentication and authorization of the TLS client (transport sender) is described in Section 4.2.2. 4.2.1 Server authentication/authorization The transport sender (TLS client) has three different options for authenticating and authorizing the transport receiver (TLS server): (Pasi's note: it could be sufficient is one of the following two is a MUST, and the other one is a SHOULD.) o Certification path validation and subject name verification: the client is configured with one or more trust anchors, and for each transport receiver, the name to be matched against the certificate. This option MUST be supported. o Certificate fingerprints: For each transport receiver, the client is configured with a fingerprint of the server's certificate (which can be self-signed). This option MUST be supported. o No server authentication/authorization: The client is configured to accept any certificate from the server. This option MAY be supported, but MUST NOT be enabled by default. For certification path validation, client implementations MUST provide a mechanism for configuring one or more trust anchors, and MUST perform certification path validation as specified in [RFC3280bis]. For subject name verification, client implementations MUST support configuring, for each transport receiver, the name to be matched against the certificate. This name may be the host name or IP address used when opening the TCP connection, or a distinct host name (...details of name matching...MUST support DNS names, probably others can be MAY...) To support certificate fingerprints, client implementations MUST support configuring, for each transport receiver, a fingerprint of the server certificate. See Section 4.2.3 for details. If server authentication/authorization fails, the client SHOULD log the error in some form or another (...more text...) 4.2.2 Client authentication/authorization The transport receiver (TLS server) has three different options for authenticating and authorizing the transport sender (TLS client). (Pasi's note: it could be sufficient is one of the following two is a MUST, and the other one is a SHOULD.) o Certification path validation and subject name verification: the server is configured with one or more trust anchors, and a set of names (or wildcard patterns) to be matched against the certificates. This option MUST be supported. o Certificate fingerprints: The server is configured with the fingerprints of client certificates. This option MUST be supported. o No client authentication/authorization (or authorization based only on connection source IP address): This option MAY be supported, but MUST NOT be enabled by default. Certification path validation and subject name verification work as described in Section 4.2.1 above, with following addition: (...locally configured client name can be a wildcard; different from wildcard-in-cert case...) To support certificate fingerprints, server implementations MUST support configuring with a list of fingerprints of authorized certificates. See Section 4.2.3 cor details. 4.2.3 Certificate fingerprints Both client and server implementations MUST make the certificate fingerprint available through a management interface. If no other certificate is configured, both client and server implementations MUST support generating a key pair and self-signed certificate. <describe details of certificate fingerprint calculation here. this should be compatible with the way e.g. current web browsers calculate fingerprints> " and after Joe did some additioon revising, Pasi said: "I'd be interested in getting the WG's opinion on this (in particular, the fingerprint stuff) as soon as possible." At this point, Joe revised and published the draft and we brought it to the WG for comment. Hope this helps David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog
- [Syslog] Document shepherd report of AD concerns David Harrington
- Re: [Syslog] Document shepherd report of AD conce… Pasi.Eronen
- Re: [Syslog] Document shepherd report of AD conce… Rainer Gerhards
- [Syslog] Terminology was Re: Document shepherd re… tom.petch
- Re: [Syslog] Document shepherd report of AD conce… tom.petch
- Re: [Syslog] Document shepherd report of AD conce… robert.horn
- [Syslog] MUST is for implementers, not users. David Harrington
- Re: [Syslog] Document shepherd report of AD conce… Pasi.Eronen
- Re: [Syslog] Document shepherd report of AD conce… Pasi.Eronen