Re: [secdir] review of draft-ietf-xcon-ccmp-12

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 11 March 2011 14:19 UTC

Return-Path: <mary.ietf.barnes@gmail.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 C05223A6C23 for <secdir@core3.amsl.com>; Fri, 11 Mar 2011 06:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.448
X-Spam-Level:
X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 kCwbX+-MU1Yn for <secdir@core3.amsl.com>; Fri, 11 Mar 2011 06:19:21 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E20C53A6BD9 for <secdir@ietf.org>; Fri, 11 Mar 2011 06:19:20 -0800 (PST)
Received: by vws12 with SMTP id 12so740891vws.31 for <secdir@ietf.org>; Fri, 11 Mar 2011 06:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ww+QG6FsJQPm3tEg1cZksQ/0RGwhOEqoQhLQ0kUvECI=; b=pzUSoGvITffVTk3gXKETDy+nxYyAQRlb4LR4rQJ7dKw0/W9kOX9UZbbpb18dnEMc/9 9gCI3m7TmxZrFM5wxE2FmuihgH9VMvyDXVs8o3m+wSvrRKRxeqF6OMk3JTk2HO+PWZ0H iVwfy+SRxgp+HURoacbLiglKo6qyR280tc33I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sMKo8Gx+P9cuwCx181zJnlDmHts7WEgNEorGEOUO4wVi+IvOFbqX7gLzpc/GU8T55Y 9wDbx+DisF/6gP6dQ0kBfSp5xv71OvLtmmsaQ8g11+Opj06uN5YKZ+913VclJ0wHnolJ +YE12vdzHST+riSuFjjFymhQGNtZVmpG4XNCE=
MIME-Version: 1.0
Received: by 10.52.179.169 with SMTP id dh9mr8861749vdc.23.1299853239386; Fri, 11 Mar 2011 06:20:39 -0800 (PST)
Received: by 10.52.162.202 with HTTP; Fri, 11 Mar 2011 06:20:39 -0800 (PST)
In-Reply-To: <p06240801c98a333301a6@128.89.89.244>
References: <p06240801c98a333301a6@128.89.89.244>
Date: Fri, 11 Mar 2011 08:20:39 -0600
Message-ID: <AANLkTi=uFaMc4E=2kb+wOx352JhjQyVTuJLRtGc8B4AR@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary=bcaec5171de59802e0049e35aa08
X-Mailman-Approved-At: Fri, 11 Mar 2011 08:19:10 -0800
Cc: secdir@ietf.org, spromano@unina.it, chris@ns-technologies.com, xcon-chairs@tools.ietf.org, hgs+xcon@cs.columbia.edu, rjsparks@nostrum.com
Subject: Re: [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: Fri, 11 Mar 2011 14:19:23 -0000

Hi Stephen,

Thank you for the very thorough review.  Responses are inline below [MB].

Mary.

On Tue, Feb 22, 2011 at 9:50 PM, Stephen Kent <kent@bbn.com>; wrote:

>  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.
>
[MB] I'm not entirely clear on the concern here.  Is the concern that the
mechanisms to fulfill the requirements are within the security section
rather than in the detailed protocol section?   I think the approach was
that in cases where it seemed to naturally fit, we included the text in the
protocol section, whereas in others when we were reviewing security
considerations we found gaps and thus included the details in the security
section. Perhaps if we re-iterated such - i.e., add a statement something
like the following at the end of section 10:
     " Of the considerations listed above, items 1 and 3 are addressed
within
       the referenced sections earlier in this document. The remaining
security
       considerations are addressed in detail in the following sections."

An alternative, of course, is to move the details into the appropriate
sections.
[/MB]


> 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.
>
[MB]  I agree.  We should move the last three sentences to either the last
paragraph of section 4.4 or to the paragraph in section 5 and replace the
text in requirement 6 with something like the following:
       " Section x describes the use of a timer mechanism to alleviate the
         situation whereby CCMP commands pend indefinitely,
         which would increase the
         potential that pending requests can continue to increase when a
         server is receiving more requests than it can process within a
         specific time period."
[/MB]



>
> 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?
>
[MB] "these checks" is referring to TLS in general and isn't prescribing
behavior for TLS, but rather noting that if the client has other information
(e.g., preconfigured)  that provides assurance that the proper conference
server has been contacted then there is no need for the conference server to
authenticate its identity using TLS.  [/MB]


>  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.
>

[MB] The *this* in the text related to the statement above ("With the use of
HTTP as a transport for CCMP, *this* is exactly....") is referring to the
following text RFC 2818:

" If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity."

I almost think we could just delete that sentence entirely.

[/MB]



> 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.
>

[MB] The server to contact in the first place is described in section 7 and
is referenced in the first item in the list of considrations - perhaps a
reference to such would be helpful. [/MB]


> This text needs to be expanded upon to provide an unambiguous
> characterization of the intended security requirement.
>

[MB] Agreed - hopefully the responses above address this concern.
[/MB]

>
> 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?)
>
[MB] While, an IP address isn't preferred, it is unfortunately a very common
mechanism with existing systems, some of which could be upgraded to support
CCMP without changes to the server discovery/authentication mechanisms.
[/MB]


> 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).
>
[MB] Okay. [/MB]

>
> 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.
>
[MB] Agreed. We can add some text with SIP as an example of a call signaling
protocol and include references.  "associates" is likely a better verb than
"correlate" and the former is used in a subsequent paragraph in the same
context, so we'll change that. [/MB]

>
> 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.
>
[MB] Agreed.  The recommendation is for the former as the protocol itself
has a mechanism for the user to include a password in the CCMP requests.

>
> 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.
>
[MB]  Yeah - I can see the lack of precision.  The XCON framework introduced
the term XCON-Userid as a fundamental identifier in the framework.  We did
have more information on the XCON-Userid in section 3.2 but it was moved to
the XCON data model as that provides the XML schema and the representation
of the XCON-UserID in the conference objects carried in the CCMP messages.
In addition, the IANA registration is included in the XCON data model. The
XCON-UserID is represented by the 'entity' attribute in the <user> element
in the XML schema.  In addition, the XCON-Userid is reflected in the
confUserID in the CCMP Request messages.  I can see that this isn't at all
clear in the current text.  I will update section 3.2 to clarify this.
 [/MB]

>
> 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.
>
[MB] The intent of the current text is to note that elements in the XCON
data model can be mapped directly to the RBAC elements (users, roles,
objects and permissions) and that CCMP operations provide the necessary
mechanisms to support the RBAC operations.  The policy mechanisms
(configuration and application of such) are out of scope, but the XCON data
model provides the necessary data elements that are required to implement
policy.  The policy would be applied using the configured policy data based
upon the specific data in the CCMP operation - e.g., setting roles using the
"so-called role-assignment policies".     I agree it could be stated more
clearly.  On your last point, the Users aspect of RBAC is represented in
XCON with the "users" portion of an XCON conference object.  The UserID is
one element in a "user" element in the conference object.  The  the "users"
element in the XCON data model is comprised of one or more "user" elements.
 The "user" element within the XCON data model also has a "role" element, so
I don't think the sentence above "The user ID..." is how that would be
stated. [/MB]


>
>  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.
>
[MB] I think this section could be improved if we re-arrange the text such
that it describes how a client can request levels of anonymity and then how
the server handles the specific data elements used to reflect the level of
anonymity for the user. As far as the conference server having visibility to
all the information, that's obviously necessary, but as noted policy can
control whether humans/an administrator has visibility to that information.
 I can add a statement clarifying that. As far as whether users know that
they are anonymous, that is reflected in the conference data to which the
client has access which is included in responses and in conference event
package notifications. I can add text around that, as well.
[/MB]