Last Call Review of draft-ietf-xcon-ccmp-
review-ietf-xcon-ccmp-secdir-lc-kent-2011-02-26-00

Title: 

review of
draft-ietf-xcon-ccmp-12




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.