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

[Stephen Kent <[e-mail]>]

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.