draft-ietf-xcon-framework-09.txt   draft-ietf-xcon-framework-10.txt 
XCON Working Group M. Barnes XCON Working Group M. Barnes
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track C. Boulton Intended status: Standards Track C. Boulton
Expires: February 2, 2008 Ubiquity Software Corporation Expires: May 12, 2008 Avaya
O. Levin O. Levin
Microsoft Corporation Microsoft Corporation
November 9, 2007
A Framework for Centralized Conferencing A Framework for Centralized Conferencing
draft-ietf-xcon-framework-09 draft-ietf-xcon-framework-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2008. This Internet-Draft will expire on May 12, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange
media in a centralized unicast conference. The Centralized media in a centralized unicast conference. The Centralized
Conferencing Framework defines logical entities and naming Conferencing Framework defines logical entities and naming
conventions, along with a high level conferencing data model. The conventions. The framework also outlines a set of conferencing
framework also outlines a set of conferencing protocols, which are protocols, which are complementary to the call signaling protocols,
complementary to the call signaling protocols, for building advanced for building advanced conferencing applications. The framework binds
conferencing applications. The framework binds all the defined all the defined components together for the benefit of builders of
components together for the benefit of builders of conferencing conferencing systems.
systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10 4. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
4.1. Conference Information . . . . . . . . . . . . . . . . . . 12 4.1. Conference Information . . . . . . . . . . . . . . . . . . 12
4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12 4.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
5. Centralized Conferencing Constructs and Identifiers . . . . . 13 5. Centralized Conferencing Constructs and Identifiers . . . . . 13
skipping to change at page 3, line 43 skipping to change at page 3, line 43
8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35 8.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37 8.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40 8.5. Floor control using sidebars . . . . . . . . . . . . . . . 40
8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42 8.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
8.7. Conference Announcements and Recordings . . . . . . . . . 44 8.7. Conference Announcements and Recordings . . . . . . . . . 44
8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46 8.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46 8.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
9. Relationships between SIP and Centralized Conferencing 9. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 51 10.1. User Authentication and Authorization . . . . . . . . . . 51
10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52 10.2. Security and Privacy of Identity . . . . . . . . . . . . . 52
10.3. Floor Control Server Authentication . . . . . . . . . . . 52 10.3. Floor Control Server Authentication . . . . . . . . . . . 52
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. Changes since last Version . . . . . . . . . . . . . . . . . . 53 13. Changes since last Version . . . . . . . . . . . . . . . . . . 53
14. Informative References . . . . . . . . . . . . . . . . . . . . 60 14. Informative References . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . . . . 63 Intellectual Property and Copyright Statements . . . . . . . . . . 64
1. Introduction 1. Introduction
This document defines the framework for Centralized Conferencing. This document defines the framework for Centralized Conferencing.
The framework allows participants using various call signaling The framework allows participants using various call signaling
protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange
media in a centralized unicast conference. Other than references to media in a centralized unicast conference. Other than references to
general functionality (e.g., establishment and teardown), details of general functionality (e.g., establishment and teardown), details of
these call signaling protocols are outside the scope of this these call signaling protocols are outside the scope of this
document. document.
The Centralized Conferencing Framework defines logical entities and The Centralized Conferencing Framework defines logical entities and
naming conventions, along with a high level conferencing data model. naming conventions. The framework also outlines a set of
The framework also outlines a set of conferencing protocols, which conferencing protocols, which are complementary to the call signaling
are complementary to the call signaling protocols, for building protocols, for building advanced conferencing applications.
advanced conferencing applications.
The Centralized Conferencing Framework is compatible with the The Centralized Conferencing Framework is compatible with the
functional model presented in the SIP Conferencing Framework [8]. functional model presented in the SIP Conferencing Framework [8].
Section 9 of this document discusses the relationship between the Section 9 of this document discusses the relationship between the
Centralized Conferencing Framework and the SIP Conferencing Centralized Conferencing Framework and the SIP Conferencing
framework, in the context of the Centralized Conferencing model framework, in the context of the Centralized Conferencing model
presented in this document. presented in this document.
2. Terminology 2. Terminology
skipping to change at page 15, line 10 skipping to change at page 15, line 10
| Conferencing | | Conferencing | | Conference | | Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client | | Client | | Client | | Client |
| 1 | | 2 | | X | | 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+ +----------------+ +--------------+ +---------------+
Figure 3: Identifier Relationships for an Active Conference. Figure 3: Identifier Relationships for an Active Conference.
5.2.1. Conference Object Identifier 5.2.1. Conference Object Identifier
In order to make each conference object externally accessible, the In order to make each conference object externally accessible, the
conferencing system allocates a unique URI per distinct conference conferencing system allocates a unique URI per distinct conference
object in the system. The conference object identifier is created object in the system. A conferencing system will allocate a
both by the conferencing system based on internal actions as well as conferencing object identifier for every conference blueprint, for
based on specific conference protocol requests. A conferencing every conference reservation and for every active conference. The
system will allocate a conferencing object identifier for every distribution of the conference object identifier depends upon the
conference blueprint, for every conference reservation and for every specific use case and includes a variety of mechanisms, such as the
active conference. The distribution of the conference object through the conference control protocol mechanism, the data model and
identifier depends upon the specific use case and includes a variety conference package or out of band mechanisms such as E-Mail.
of mechanisms, such as the through the conference control protocol
mechanism, the data model and conference package or out of band
mechanisms such as E-Mail.
When a user wishes to create or join a conference and the user does When a user wishes to create or join a conference and the user does
not have the conference object identifier for the specific not have the conference object identifier for the specific
conference, more general signaling mechanisms apply, such that a user conference, more general signaling mechanisms apply, such that a user
may have a pre-configured conference object identifier to access the may have a pre-configured conference object identifier to access the
conferencing system or other signaling protocols may be used and the conferencing system or other signaling protocols may be used and the
conferencing system maps those to a specific conference object conferencing system maps those to a specific conference object
identifier. Once a conference is established, a conference object identifier. Once a conference is established, a conference object
identifier is required for the user to manipulate any of the identifier is required for the user to manipulate any of the
conferencing data or take advantage of any of the advanced conferencing data or take advantage of any of the advanced
skipping to change at page 51, line 9 skipping to change at page 51, line 9
manipulation and retrieval of confidential information need to manipulation and retrieval of confidential information need to
support a confidentiality and integrity mechanism. Similar support a confidentiality and integrity mechanism. Similar
requirements apply for the floor control protocols. Section 10.3 requirements apply for the floor control protocols. Section 10.3
discusses an approach for client authentication of a floor control discusses an approach for client authentication of a floor control
server. server.
There are also security issues associated with the authorization to There are also security issues associated with the authorization to
perform actions on the conferencing system to invoke specific perform actions on the conferencing system to invoke specific
capabilities. Section 4.2 discusses the policies associated with the capabilities. Section 4.2 discusses the policies associated with the
conference object to ensure that only authorized entities are able to conference object to ensure that only authorized entities are able to
manipulate the data to access the capabilities. The final set of manipulate the data to access the capabilities. Another set of
issues involves the privacy and security of the identity of a user in issues involves the privacy and security of the identity of a user in
the conference, which is discussed in Section 10.2 the conference, which is discussed in Section 10.2.
10.1. Authorization A final issue is related to Denial of Service (DoS) attacks on the
conferencing system itself. In order to minimize the potential for
DoS attacks, it is recommended that conferencing systems require user
authentication and authorization for any client participating in a
conference. It is recommended that the specific signaling and media
protocols include mechanisms to minimize the potential for DoS.
10.1. User Authentication and Authorization
Many policy authorization decisions are based on the identity of the Many policy authorization decisions are based on the identity of the
user or the role that a user may have. There are several ways that a user or the role that a user may have. Conferencing systems
user might authenticate its identity to the system. The conferencing typically require authentication of users to validate their identity.
system may know about specific users and assign passwords to the There are several ways that a user might authenticate its identity to
users. The users may also be authenticated by knowing a particular the system. For users joining a conference using one of the call
conference ID and a PIN for it. Sometimes, a PIN is not required and signaling protocols, the user authentication mechanisms for the
the conference ID is used as a shared secret. The call signaling specific protocol often suffice. The conferencing system may also
means can provide a trusted form of the user identity or it might know (e.g., out of band mechanisms) about specific users and assign
just provide a hint of the possible identity and the user still needs passwords to allow these users to be authorized. In some cases
to provide some authentication to prove it has the identity that was additional authorization may be required to allow the user to
provided as a hint in the call signaling. This may be in the form of participate in the conference. This may be in the form of an
an IVR system or other means. The goal for the conferencing system Interactive Voice Response (IVR) system or other means. The users
is to figure out a user identity and a role for any attempt to send a may also be authorized by knowing a particular conference ID and a
request to the conferencing system. Personal Identification (PIN) for it. Sometimes, a PIN is not
required and the conference ID is used as a shared secret.
When a conferencing system presents the identity of authorized users, When a conferencing system presents the identity of authorized users,
it may choose to provide information about the way the identity was it may choose to provide information about the way the identity was
proven or verified by the system. A user may also come as a proven or verified by the system. A user may also come as a
completely unauthenticated user into the system - this fact needs completely unauthenticated user into the system - this fact needs
also be communicated to interested parties. also be communicated to interested parties.
When guest users interact with the system, it is often in the context When guest users interact with the system, it is often in the context
of a particular conference. In this case, the user may provide a PIN of a particular conference. In this case, the user may provide a PIN
or a password that is specific to the conferences and authenticates or a password that is specific to the conferences and authorizes the
the user to take on a certain role in that conference. The guest user to take on a certain role in that conference. The guest user
user can then perform actions that are allowed to any user with that can then perform actions that are allowed to any user with that role.
role.
The term password is used to mean the usual, that is to say a The term password refers to the usual, reasonable sized and hard to
reasonable sized, in number of bits, hard to predict shared secret. predict shared secret. Today users often have passwords containing
Today users often have passwords with more than 30 bits of randomness up to 30 bits (8-16 characters). PIN is a special password case - a
in them. PIN is a special password case - a shared secret that is shared secret that is only numeric and often contains a fairly small
only numeric and often contains a fairly small number of bits (often number of bits (often as few as 10 bits or 3 digits). When
as few as 10 bits). When conferencing systems are used for audio on conferencing systems are used for audio on the PSTN, there is often a
the PSTN, there is often a need to authenticate using a PIN. need to authenticate using a PIN. Typically if the user fails to
Typically if the user fails to provide the correct PIN a few times in provide the correct PIN a few times in a row, the PSTN call is
a row, the PSTN call is disconnected. The rate of making the calls disconnected. The rate of making the calls and getting to the point
and getting to the point to enter a PIN makes it fairly hard to do an to enter a PIN makes it fairly hard to do an exhaustive search of the
exhaustive search of the PIN space even for 4 digit PINs. When using PIN space even for 4 digit PINs. When using a high speed interface
a high speed interface to connect to a conferencing system, it is to connect to a conferencing system, it is often possible to do
often possible to do thousands of attempts per second and the PIN thousands of attempts per second and the PIN space could quickly be
space could quickly be searched. Because of this, it is not searched. Because of this, it is not appropriate to use PINs for
appropriate to use PINs for authorization on any of the interfaces authorization on any of the interfaces that provide fast queries or
that provide fast queries or many simultaneous queries. many simultaneous queries.
10.2. Security and Privacy of Identity 10.2. Security and Privacy of Identity
This conferencing system has an idea of the identity of a user but This conferencing system has an idea of the identity of a user but
this does not mean it can reveal this identity to other users, due to this does not mean it can reveal this identity to other users, due to
privacy considerations. Users can select various options for privacy considerations. Users can select various options for
revealing their identity to other users. A user can be "hidden" such revealing their identity to other users. A user can be "hidden" such
that other users can not see they are participants in the conference, that other users can not see they are participants in the conference,
or they can be "anonymous" such that users can see that another user or they can be "anonymous" such that users can see that another user
is there, but not see the identity of the user, or they can be is there, but not see the identity of the user, or they can be
skipping to change at page 53, line 10 skipping to change at page 53, line 18
12. Acknowledgements 12. Acknowledgements
This document is a result of architectural discussions among IETF This document is a result of architectural discussions among IETF
XCON working group participants. The authors would like to thank XCON working group participants. The authors would like to thank
Henning Schulzrinne for the "Conference Object Tree" proposal and Henning Schulzrinne for the "Conference Object Tree" proposal and
general feedback, Cullen Jennings for providing input for the general feedback, Cullen Jennings for providing input for the
"Security Considerations" section and Keith Lantz, Dave Morgan, Oscar "Security Considerations" section and Keith Lantz, Dave Morgan, Oscar
Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson, Rohan
Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and Mahy, Brian Rosen, Pierre Tane, Bob Braudes and Gregory Sperounes and
Gonzalo Camarillo for their reviews and constructive input. Gonzalo Camarillo for their reviews and constructive input. In
addition, the authors would like to thank Scott Brim for his gen-art
review comments and Kurt Zeilenga for his secdir review comments.
13. Changes since last Version 13. Changes since last Version
NOTE TO THE RFC-Editor: Please remove this section prior to NOTE TO THE RFC-Editor: Please remove this section prior to
publication as an RFC. publication as an RFC.
Changes from WG 09 to 10 (gen-art, secdir and initial IESG review
comments):
1) Abstract and Section 1: removed "along with a high level
conferencing data model."
2) Section 5.2.1: removed confusing unclear 2nd sentence since it
really added no value(Scott Brim's comment from gen-art review) and
changed the tense of the 3rd sentence (editor's comment)
3) Updates to security section based on secdir (Kurt Zeilenga) and
IESG (Tim Polk) comments
3a) Section 10. Added a fourth paragraph about DoS attacks at the
end of that section just prior to 10.1
3b) Section 10.1. Clarifying Authentication versus Authorization
3bi) Renamed section: OLD: Authorization NEW: User Authentication and
Authorization
3bii) First paragraph: expanded acronyms and clarified text. Added
2nd sentence (removed last sentence) and moved 4th and 5th sentences
to the end
3biii) 3rd paragraph (change "authenticates" to "authorizes")
3biv) 4th paragraph: Reworded to add detail about the number of
digits/characters associated with specific numbers of bits in first
two sentences
4) Updated references (gen-art review comment):
draft-ietf-simple-message-sessions => RFC 4975,
draft-ietf-xcon-bfcp-connection => RFC 5018
5) Updated Chris' affiliation.
Changes from WG 08 to 09 (chair PROTO review comments): Changes from WG 08 to 09 (chair PROTO review comments):
1) Changed Intended Status to standards track. 1) Changed Intended Status to standards track.
2) Updated IANA section per 1). 2) Updated IANA section per 1).
3) Removed normative language (i.e., "must" in CAPS in section 10) 3) Removed normative language (i.e., "must" in CAPS in section 10)
4) Updated section 10.3 (Floor Control authentication) to be more 4) Updated section 10.3 (Floor Control authentication) to be more
general based on changes to the final BFCP authentication mechanism. general based on changes to the final BFCP authentication mechanism.
skipping to change at page 61, line 47 skipping to change at page 62, line 47
[13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control [13] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006. Protocol (BFCP)", RFC 4582, November 2006.
[14] Levin, O. and G. Camarillo, "The Session Description Protocol [14] Levin, O. and G. Camarillo, "The Session Description Protocol
(SDP) Label Attribute", RFC 4574, August 2006. (SDP) Label Attribute", RFC 4574, August 2006.
[15] Camarillo, G., "Session Description Protocol (SDP) Format for [15] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", RFC 4583, Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
November 2006. November 2006.
[16] Novo, O., "Conference Information Data Model for Centralized [16] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference
Conferencing (XCON)", draft-ietf-xcon-common-data-model-05 Information Data Model for Centralized Conferencing (XCON)",
(work in progress), April 2007. draft-ietf-xcon-common-data-model-06 (work in progress),
October 2007.
[17] Campbell, B., "The Message Session Relay Protocol", [17] Campbell, B., Mahy, R., and C. Jennings, "The Message Session
draft-ietf-simple-message-sessions-19 (work in progress), Relay Protocol (MSRP)", RFC 4975, September 2007.
February 2007.
[18] Camarillo, G., "Connection Establishment in the Binary Floor [18] Camarillo, G., "Connection Establishment in the Binary Floor
Control Protocol (BFCP)", draft-ietf-xcon-bfcp-connection-05 Control Protocol (BFCP)", RFC 5018, September 2007.
(work in progress), July 2007.
Authors' Addresses Authors' Addresses
Mary Barnes Mary Barnes
Nortel Nortel
2201 Lakeside Blvd 2201 Lakeside Blvd
Richardson, TX Richardson, TX
Email: mary.barnes@nortel.com Email: mary.barnes@nortel.com
Chris Boulton Chris Boulton
Ubiquity Software Corporation Avaya
Building 3 Building 3
Wern Fawr Lane Wern Fawr Lane
St Mellons St Mellons
Cardiff, South Wales CF3 5EA Cardiff, South Wales CF3 5EA
Email: cboulton@ubiquitysoftware.com Email: cboulton@avaya.com
Orit Levin Orit Levin
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Email: oritl@microsoft.com Email: oritl@microsoft.com
Full Copyright Statement Full Copyright Statement
 End of changes. 23 change blocks. 
76 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/