draft-ietf-xcon-floor-control-req-02.txt   draft-ietf-xcon-floor-control-req-03.txt 
Transport Area P. Koskelainen Transport Area P. Koskelainen
Internet-Draft Nokia Internet-Draft Nokia
Expires: April 23, 2005 J. Ott Expires: July 3, 2005 J. Ott
Uni Bremen TZI Uni Bremen TZI
H. Schulzrinne H. Schulzrinne
X. Wu X. Wu
Columbia University Columbia University
October 23, 2004 January 2, 2005
Requirements for Floor Control Protocol Requirements for Floor Control Protocol
draft-ietf-xcon-floor-control-req-02.txt draft-ietf-xcon-floor-control-req-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 40
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 April 23, 2005. This Internet-Draft will expire on July 3, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resource in a (multiparty) conferencing environment. Thereby, shared resource in a (multiparty) conferencing environment. Thereby,
floor control complements other functions -- such as conference and floor control complements other functions -- such as conference and
media session setup, conference policy manipulation, and media media session setup, conference policy manipulation, and media
control -- that are realized by other protocols. This document control -- that are realized by other protocols. This document
defines the requirements for a floor control protocol for multiparty defines the requirements for a floor control protocol for multiparty
conferences in the context of an existing framework. conferences in the context of an existing framework.
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7
6. Assumptions about a Conference Policy . . . . . . . . . . . . 8 6. Assumptions about a Conference Policy . . . . . . . . . . . . 8
7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10 7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10
7.1 Communication between Participant and Server . . . . . . . 10 7.1 Communication between Participant and Server . . . . . . . 10
7.2 Communicaton between Chair and Server . . . . . . . . . . 11 7.2 Communicaton between Chair and Server . . . . . . . . . . 11
7.3 General Protocol Requirements . . . . . . . . . . . . . . 12 7.3 General Protocol Requirements . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2 Informative References . . . . . . . . . . . . . . . . . . . 14 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
1. Introduction 1. Introduction
Conference applications often have shared resources such as the right Conference applications often have shared resources such as the right
to talk, input access to a limited-bandwidth video channel, or a to talk, input access to a limited-bandwidth video channel, or a
pointer or input focus in a shared application. pointer or input focus in a shared application.
In many cases, it is desirable to be able to control who can provide In many cases, it is desirable to be able to control who can provide
input (send/write/control, depending on the application) to the input (send/write/control, depending on the application) to the
shared resource. shared resource.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
REQ-GEN-4: It MUST be possible for the participants and chairs to REQ-GEN-4: It MUST be possible for the participants and chairs to
authenticate the server. authenticate the server.
REQ-GEN-5: It MUST be possible to ensure message integrity between REQ-GEN-5: It MUST be possible to ensure message integrity between
participants and chairs and the floor control server. participants and chairs and the floor control server.
REQ-GEN-6: It MUST be possible to ensure privacy of messages REQ-GEN-6: It MUST be possible to ensure privacy of messages
exchanged between participants and chairs and the floor control exchanged between participants and chairs and the floor control
server. server.
8. Acknowledgements 8. Security Considerations
Floor control messages are exchanged on one hand between regular
participants and the floor control server and on the other hand
between the floor control server and the floor chair(s).
If enabled, floor control mechanisms are used to control who may
contribute to a conference in arbitrary ways (speak, be seen, write,
etc. as supported by the conferencing applications). It is
important that floor control messages be protected because otherwise
an attacker could prevent participants from being "heard" in the
conference (e.g., in scenarios where silence is considered consent)
or make participants be heard in a conference without their knowledge
(e.g., eavesdropping on the participant's mike). Such considerations
are particularly relevant when floor control is used in conjunction
with one or more (central) entities (e.g., a media mixer) controlled
by the floor control server to enforce floor control decisions which
may allow an attacker to completely "mute" a participant.
Communications between a conference participant and the floor control
server are vulnerable to all kinds of masquerading attacks. If an
attacker can spoof the identity of the participant or inject messages
on its behalf, it may generate floor requests (e.g. floor release)
and prevent proper participation of the participant. If an attacker
can inject messages to the participant, it may generate arbitrary
responses and false status information. If an attacker can
impersonate the floor control server, a participant's requests may
never reach the actual floor control server. If an attacker can
intercept either side's messages (and hence become a man in the
middle) it may suppress, alter, or inject messages and thus
manipulate a participant's view of the conference floor status as
well as the floor control server's view of a participant.
Similar considerations apply to the communications between the floor
control server and the floor chair(s). If an attacker can intercept
messages from either side, it may defer or prevent responses to floor
control requests (from a particular floor chair). If it can inject
messages (particularly in the direction from the floor chair to the
floor control server), it may steer the assigment of conference
floors. If interception and injection is possible (man in the middle
scenario), an attacker can create an arbitrary image of the
conference for the floor chair. If an attacker can impersonate a
floor chair, it may rule the conference floor assignment (if there is
only a single chair) or disrupt the conference course by means of
arbitrary and potentially conflicting requests/responses/assignments
(if there are multiple floor chairs). In the latter case, the amount
of damage a single attacker can do depends on the floor control
policy.
Finally, attackers may eavesdrop on the floor control communications
and learn which participants are present, how active they are, who
are the floor chairs, etc.
To mitigate the above threats, conference participants, floor control
servers, and floor chairs SHOULD be authenticated upon initial
contact. All floor control messages SHOULD be authenticated and
integrity-protected to prevent third-party intervention and MITM
attacks. Floor control messages SHOULD be encrypted to prevent
eavesdropping.
9. Acknowledgements
The authors would like to thank IETF conferencing design team and The authors would like to thank IETF conferencing design team and
Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen,
and Nermeen Ismail for their feedback. and Nermeen Ismail for their feedback.
9. References 10. References
9.1 Normative References 10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCD 14, March 1997. Levels", RFC 2119, BCD 14, March 1997.
[2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC
3261, June 2002. 3261, June 2002.
10.2 Informative References
[3] Rosenberg, J., "A Framework for Conferencing with the Session [3] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02.txt (work in draft-ietf-sipping-conferencing-framework-02.txt (work in
progress), June 2004. progress), June 2004.
9.2 Informative References
[4] Koskelainen, P. and H. Khartabil, "Additional Requirements to [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to
Conferencing", August 2004. Conferencing", August 2004.
[5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP
for conference floor control", January 2003. for conference floor control", January 2003.
[6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based [6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based
conference control framework", Nossdav'2002 Miami Beach, May conference control framework", Nossdav'2002 Miami Beach, May
2002. 2002.
skipping to change at page 16, line 41 skipping to change at page 18, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/