[secdir] review of draft-ietf-xcon-ccmp-12
Stephen Kent <kent@bbn.com> Wed, 23 February 2011 04:10 UTC
Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF363A69B8 for <secdir@core3.amsl.com>; Tue, 22 Feb 2011 20:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.54
X-Spam-Level:
X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 5FSdlxrQpOaa for <secdir@core3.amsl.com>; Tue, 22 Feb 2011 20:10:00 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7F6C13A69B7 for <secdir@ietf.org>; Tue, 22 Feb 2011 20:10:00 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:53507 helo=[169.223.148.236]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Ps63o-000FCE-5w; Tue, 22 Feb 2011 23:10:46 -0500
Mime-Version: 1.0
Message-Id: <p06240801c98a333301a6@[128.89.89.244]>
Date: Tue, 22 Feb 2011 22:50:15 -0500
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-913688253==_ma============"
Cc: mary.ietf.barnes@gmail.com, spromano@unina.it, hgs+xcon@cs.columbia.edu, chris@ns-technologies.com, rjsparks@nostrum.com
Subject: [secdir] review of draft-ietf-xcon-ccmp-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Feb 2011 04:10:02 -0000
I reviewed this document (draft-ietf-xcon-ccmp-12) as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This long (111 page) document defines a protocol (CCMP) to manage centralized conferencing consistent with the XCON framework. It enables users who are "authenticated and authorized" to "create, manipulate, and delete conference objects." I did not read the whole document. I focused on the security considerations section and sections referenced by it. The security considerations section is about 4 pages long, a pleasant change from the one sentence or one paragraph SC sections I often encounter. The SC section begins with a list of six security requirements posited for CCMP. Each requirement cites the relevant section of the document where the mechanisms needed to fulfill the requirement are described. This is a nice organizational approach, but half of the requirements are addressed in later subsections of the SC section, not in the CCMP definition that forms the bulk of this document. Also, requirement #6 strays from the "requirement/reference" model, and provides an inline description of RECOMMENDED DoS mitigation strategies. It might be better if some of the text associated with this requirement (e.g., dealing with long request pending times) were moved to the relevant section(s) of the document. The remainder of the SC section is divided into 3 subsections, dealing with a client contacting the "proper" conference server, user authentication and authorization, and the security and privacy of user identities. The first subsection (10.1) cites use of TLS (with server certificates) as a secure transport, to enable a user (as a client) to authenticate the identity of the server to which the user is connecting. The text calls for the server certificate to attest to the IP address or DNS name for the CMPP server, via a Subject Alternative Name (SAN). However, the discussion includes an odd sentence: "If the client has external information as to the expected identity or credentials of the proper conference server (e.g., a certificate fingerprint), these checks MAY be omitted." It is not clear what the phrase "these checks" refers to with respect to TLS checks on server certificate validity. For example, does this mean that the TLS implementation is supposed to allow the user to provide a certificate fingerprint as an input in lieu of the more common check of the FQDN portion of a URI against selected fields from the server certificate? The HTTPS RFC (2818) makes no mention of such a facility, and it is outside the scope of the TLS RFC (5246). This text needs to be clarified. A client would normally be expected to have a priori knowledge of some form of server identity, e.g., a FQDN. If the client is able to contact the server it needs this info, and it needs this info to be able to interpret the server certificate as evidence of having contacted the "proper" server. So the fist part of the sentence above "If the client has external information as to the expected identity of the proper conference server " seems odd. The second option here " (e.g., a certificate fingerprint)" is a different way of confirming that the proper server has been contacted, but it would not be a way of determining which server to contact in the first place. This text needs to be expanded upon to provide an unambiguous characterization of the intended security requirement. Section 7 of the document describes how to determine the proper server (fulfilling requirement #1 from the SC section), if it is not pre-configured. That section calls for use of the DNS (via U-NAPTR resolution) to acquire a URI for the server. If a URI is the server ID, then it makes sense to requires use of a FQDN SAN in a server certificate. (I am surprised that the document suggests an IP address SAN as an option for the server certificate; who prefers hard-wired addresses over DNS names?) There is no mention in Section 7 of a certificate fingerprint, so I suggest removing this text. Also, there should be some discussion of the role of DNSSEC here, i.e., if one is relying on NAPTR resolution to locate the proper CMPP server, a spoofed DNS reply can lead the user to the wrong server (even if the user can authenticate that server, via TLS). Section 10.2 describes the need for a user to authenticate to a conference server, and it RECOMMENDs use of TLS, or use of a call signaling protocol. This text is a bit vague, as it does not cite any specific call signaling protocols. It says "In the cases where a user is authorized via multiple mechanisms, it is RECOMMENDED that the conference server correlate the authorization of the CCMP interface with other authorization mechanisms - e.g., PSTN users that join with a PIN and control the conference using CCMP." The term "correlate" is ambiguous in this context. For a user employing CMPP, the text does not indicate whether the RECOMMENDATION is for TLS to be used to protect a password sent to a CMPP server, or whether a user certificate is the goal. This text needs further clarification. The discussion of a "conference user identifier" in Section 3.2 (and in other sections) is not precise. Perhaps the XCON framework doc makes this concept clear, but it should be restated here for completeness. There is a paragraph in this section discussing Role-based access control. It is unnecessarily vague. In an RBAC context The user ID would be a role that is occupied by an authorized user. The text here does not make this as clear as it could (should) be. The final subsection of this document (10.3) deals with security and privacy for user identities. The writing in this subsection needs help as there are a number of indefinite antecedents for pronouns scattered throughout (and mismatches in number). Nonetheless, the privacy requirements put forth seem fairly simple. However, the text does not note that the CMPP server will know the identity of each participant (in order to implement the authorization functions in 10.2) and thus user anonymity needs to be interpreted in that context. (If the user authenticates in the context of a role some additional privacy may be offered, but that too is not discussed.) I saw no mention of whether CMPP provides a way for participants in a conference to be made aware of whether they may be anonymous or invisible participants on a call. It seems that this might be a reasonable feature to offer, if one offers the privacy features discussed here.
- [secdir] review of draft-ietf-xcon-ccmp-12 Stephen Kent
- Re: [secdir] review of draft-ietf-xcon-ccmp-12 Mary Barnes