One document matched: draft-ietf-xcon-bfcp-connection-00.txt
XCON Working Group G. Camarillo
Internet-Draft Ericsson
Expires: June 3, 2006 November 30, 2005
Connection Establishment in the Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-connection-00.txt
Status of this Memo
By submitting this Internet-Draft, each 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 3, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies how a Binary Floor Control Protocol (BFCP)
client establishes a connection to a BFCP floor control server
outside the context of an offer/answer exchange. This document also
specifies a digest authentication mechanism for BFCP based on shared
secrets.
Camarillo Expires June 3, 2006 [Page 1]
Internet-Draft BFCP November 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TCP Connection Establishment . . . . . . . . . . . . . . . . . 3
4. TLS Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Certificate-based Mutual Authentication . . . . . . . . . 4
5.2. Digest-based Client Authentication . . . . . . . . . . . . 5
5.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 5
5.2.2. Floor Control Server Behavior . . . . . . . . . . . . 6
5.3. Attribute Definitions . . . . . . . . . . . . . . . . . . 7
5.3.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.2. DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Error Code Definitions . . . . . . . . . . . . . . . . . . 9
5.5. Security Considerations . . . . . . . . . . . . . . . . . 9
5.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 11
5.6.1. Attribute Registration . . . . . . . . . . . . . . . . 11
5.6.2. Error Code Registration . . . . . . . . . . . . . . . 11
5.6.3. Digest Algorithm Subregistry . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Camarillo Expires June 3, 2006 [Page 2]
Internet-Draft BFCP November 2005
1. Introduction
As discussed in the BFCP (Binary Floor Control Protocol)
specification [6], a given BFCP client needs a set of data in order
to establish a BFCP connection to a floor control server. These data
include the transport address of the server, the conference
identifier, and the user identifier.
Once a client obtains this information, it needs to establish a BFCP
connection to the floor control server. The way this connection is
established depends on the context of the client and the floor
control server. How to establish such a connection in the context of
an offer/answer [4] exchange between a client and a floor control
server is specified in [7]. This document specifies how a client
establishes a connection to a floor control server outside the
context of an offer/answer exchange.
BFCP entities establishing a connection outside an offer/answer
exchange need different authentication mechanisms than entities using
offer/answer exchanges. This is because offer/answer exchanges
provide parties with an initial integrity-protected channel that
clients and floor control servers can use to exchange the
fingerprints of their self-signed certificates. Outside the offer/
answer model, such a channel is not typically available. This
document defines a digest mechanism for BFCP that is based on shared
secrets.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels for
compliant implementations.
3. TCP Connection Establishment
A given BFCP client needs a set of data in order to establish a BFCP
connection to a floor control server. These data include the
transport address of the server, the conference identifier, and the
user identifier. It is outside the scope of this document to specify
how a client obtains this information. This document assumes that
the client obtains this information using an out-of-band method.
Once the client has the transport address of the floor control
server, it initiates a TCP connection towards it. That is, the
Camarillo Expires June 3, 2006 [Page 3]
Internet-Draft BFCP November 2005
client performs an active TCP open.
OPEN ISSUE: do we want to define DNS procedures here? If so, do we
want to define SRV procedures or are A and AAAA RRs enough?
The BFCP specification [6] describes a number of situations when the
TCP connection between a client and the floor control server needs to
be reestablished. However, that specification does not describe the
reestablishment process because this process depends on how the
connection was established in the first place.
When the existing TCP connection is reseted following the rules in
[6], the client SHOULD reestablish the connection towards the floor
control server. If a TCP connection cannot deliver a BFCP message
from the client to the floor control server and times out, the client
SHOULD reestablish the TCP connection.
OPEN ISSUE: do we want to have floor control servers reestablish
connections as well?
4. TLS Usage
All BFCP entities implement TLS and SHOULD use it in all their
connections. TLS provides integrity and replay protection, and
optional confidentiality. The floor control server MUST always act
as the TLS server.
A floor control server that receives a BFCP message over TCP (no TLS)
can request the use of TLS by generating an Error message with an
Error code with a value of 9 (Use TLS)
5. Authentication
BFCP supports certificate-based mutual authentication between clients
and floor control servers, as specified in Section 5.1.
Additionally, BFCP also provides a digest mechanism based on a shared
secret to provide client authentication for clients without
certificates. This digest mechanism is described in Section 5.2.
5.1. Certificate-based Mutual Authentication
At TLS connection establishment, the floor control server MUST
present its certificate to the client. Clients with certificates
SHOULD also present their certificates to the floor control server.
The certificates provided at the TLS-level MUST either be directly
Camarillo Expires June 3, 2006 [Page 4]
Internet-Draft BFCP November 2005
signed by one of the other party's trust anchors or be validated
using a certification path that terminates at one of the other
party's trust anchors [5].
5.2. Digest-based Client Authentication
Clients without certificates can authenticate themselves to the floor
control servers using a digest-based mechanism instead. BFCP
supports digest-based client authentication based on a shared secret
between a client and the floor control server. The floor control
server of a conference shares a secret with each of the participants
in the conference and can request them to sign their messages using
that shared secret. Consequently, there is a need for a mechanism to
generate such a shared secret. However, such mechanism is outside
the scope of this document. This document assumes that shared
secrets are generated and exchanged using out-of-band means.
Digest-based client authentication in BFCP is based on the DIGEST
attribute, which is defined in Section 5.3.2. This attribute, which
always appears as the last attribute in a message, contains an
algorithm identifier and a keyed digest of the BFCP message using
that algorithm. The text used as input to the digest algorithm is
the BFCP message, including the common header, up to and including
the attribute preceding the DIGEST attribute. Depending on the
algorithm, this text may need to be padded with zeroes.
Section 5.3.2 lists the algorithms specified in BFCP.
The key used as input to the keyed digest is the secret shared
between the server and the user identified by the User ID in the
common header of the message.
Section 5.2.1 and Section 5.2.2 discuss how to achieve client
authentication using the DIGEST attribute.
5.2.1. Client Behavior
To achieve client authentication, a client needs to prove to the
floor control server that the client can produce a DIGEST attribute
for a message using their shared secret and that the message is fresh
(to avoid replay attacks). Clients prove the freshness of a message
by including a NONCE attribute in the message.
Clients can obtain the digest algorithms supported by the floor
control server in an Error response from the floor control server
with Error Code 10 (DIGEST Attribute Required). A client SHOULD use
the first digest algorithm in the list that it supports.
The nonce to be placed in the NONCE attribute by the client is
Camarillo Expires June 3, 2006 [Page 5]
Internet-Draft BFCP November 2005
typically provided by the floor control server in an Error response
-- typically with Error Code 10 (DIGEST Attribute Required) or 6
(Invalid Nonce). If a client generates a message without a DIGEST
attribute and receives an Error response with Error Code 10 (DIGEST
Attribute Required), the client SHOULD re-send the message with a
DIGEST attribute and a NONCE attribute with the nonce received in the
Error response.
If after sending a message with a DIGEST attribute, a client receives
an Error response with Error Code 11 (Invalid Nonce), the client
SHOULD re-send the message using the new nonce received in the Error
response. If the Error Code is 12 (Authentication Failed) instead,
the client MUST NOT send further messages to the floor control server
until it has obtained a different (hopefully valid) shared secret
than the one used in the original message.
If a client receives a nonce in a message from the floor control
server, the client SHOULD add a NONCE attribute with this nonce and a
DIGEST attribute to its next message to the floor control server.
5.2.2. Floor Control Server Behavior
If the floor control server receives a message without DIGEST
attribute from an unauthenticated client, the floor control server
responds with an Error message with Error Code 10 (DIGEST Attribute
Required). The floor control message MUST include a list with the
digest algorithms supported by the floor control server in order of
preference (i.e., the first algorithm is the most preferred) and a
NONCE attribute with a nonce value that is unguessable by attackers.
When a floor control server receives a BFCP message with a DIGEST
attribute, it checks whether the Algorithm identifier in the DIGEST
attribute corresponds to an algorithm that is supported by the floor
control server. If it does not, the floor control server SHOULD
return an Error message with Error Code 10 (DIGEST Attribute
Required) with a list with the digest algorithms supported by the
floor control server.
If the algorithm identifier is valid, the floor control server checks
whether the NONCE attribute carries a nonce which was generated by
the floor control server for this client and which still has not
expired. If the nonce is not valid, authentication is considered to
have failed, in which case the floor control server SHOULD return an
Error message with Error Code 11 (Invalid Nonce) with a new nonce in
a NONCE attribute.
If the nonce is valid, the floor control server calculates the keyed
digest of the message using the algorithm identified by the DIGEST
Camarillo Expires June 3, 2006 [Page 6]
Internet-Draft BFCP November 2005
attribute. The key used as input to the keyed digest is the secret
shared between the server and the user identified by the User ID in
the common header of the message. If the resulting value is the same
as the one in the DIGEST attribute, authentication is considered
successful.
If the resulting value is different than the one in the DIGEST
attribute, authentication is considered to have failed, in which case
the server SHOULD return an Error message with Error Code 12
(Authentication Failed). Messages from a client that cannot be
authenticated MUST NOT be processed further.
Floor control servers MAY include a NONCE attribute in their
responses to provide the nonce to be used in the next message by the
client. However, when TLS is used, floor control servers typically
authenticate only the first message sent over the TLS connection.
OPEN ISSUE: do we want to state that servers typically authenticate
only the first message sent over the TLS connection?
5.3. Attribute Definitions
The following new attribute types are defined:
+------+-----------+-------------+
| Type | Attribute | Format |
+------+-----------+-------------+
| 17 | NONCE | Unsigned16 |
| 18 | DIGEST | OctetString |
+------+-----------+-------------+
Table 1: BFCP attributes
Both are EXTENSION-ATTRIBUTES are specified in [6].
5.3.1. NONCE
The NONCE attribute can appear in any message. The following is the
format of the NONCE attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M|0 0 0 0 0 1 0 0| Nonce Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NONCE format
Camarillo Expires June 3, 2006 [Page 7]
Internet-Draft BFCP November 2005
Nonce Value: this 16-bit field contains a nonce.
5.3.2. DIGEST
The DIGEST attribute can only appear in messages sent by clients.
The DIGEST attribute MUST be the last attribute of the message in
which it appears. The following is the format of the DIGEST
attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M|0 0 0 1 1 0 0 0| Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
| |
/ Digest /
/ /
| |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DIGEST format
Algorithm: this 8-bit field contains the identifier of the algorithm
used to calculate the keyed digest. The following are the algorithm
identifiers defined:
+------------+-----------+---------------+--------------+
| Identifier | Algorithm | Digest Length | Reference |
+------------+-----------+---------------+--------------+
| 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] |
+------------+-----------+---------------+--------------+
Table 2: Digest algorithms
The text used as input to the digest algorithm is the BFCP
message, including the common header, up to and including the
attribute preceding the DIGEST attribute. Depending on the
algorithm, this text may need to be padded with zeroes. When
HMAC-SHA1 is used, the input text needs to be padded so as to be a
multiple of 64 bytes.
Camarillo Expires June 3, 2006 [Page 8]
Internet-Draft BFCP November 2005
The key used as input to the keyed digest is the secret shared
between the server and the user identified by the User ID in the
common header of the message.
Digest: this field contains a keyed digest of the BFCP message. Its
calculation is described in Section 5.2.
Padding: padding added so that the contents of the DIGEST attribute
is 32-bit aligned. The Padding bits SHOULD be set to zero by the
sender and MUST be ignored by the receiver.
5.4. Error Code Definitions
+-------+---------------------------+
| Value | Meaning |
+-------+---------------------------+
| 10 | DIGEST Attribute Required |
| 11 | Invalid Nonce |
| 12 | Authentication Failed |
+-------+---------------------------+
Table 3: Error Code meaning
The following is the definition of Error Specific Details for Error
Code 10 (DIGEST Attribute Needed)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Digest algorithms format
Algorithm ID: these 8-bit fields contain the identifiers of the
digest algorithms supported by the floor control server in order of
preference (i.e., the first algorithm is the most preferred).
5.5. Security Considerations
BFCP can use TLS or message signatures to provide client
Camarillo Expires June 3, 2006 [Page 9]
Internet-Draft BFCP November 2005
authentication. Floor control server authentication is based on TLS,
which also provides replay and integrity protection, and
confidentiality. It is RECOMMENDED that TLS with non-null encryption
is always used and that the first message from an unauthenticated
client over a given TLS connection is signed using the DIGEST
attribute. Clients and floor control servers MAY use other security
mechanisms as long as they provide similar security properties.
OPEN ISSUE: same as before. Do we want to say that we recommend to
sign only the first message over a TLS connection?
The remainder of this Section analyzes some of the threats against
BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is
avoided by having clients sign their messages. A nonce is included
in the signature to ensure the freshness of the message. If the
client is using a TLS connection to communicate with the floor
control server, it is enough that the client signs its first message
over the TLS connection. The floor control server assumes that
attackers cannot hickjack the TLS connection and, therefore, that
subsequent messages over the TLS connection come from the client that
was initially authenticated. If TLS-based client authentication is
used, there is not need for the client to sign BFCP messages over the
connection.
An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having floor control
servers present their server certificates at TLS connection
establishment time.
Attackers may attempt to modify messages exchanged by a client and a
floor control server. The integrity protection provided by TLS
connections prevents this attack.
An attacker may attempt to fetch a valid message sent by a client to
a floor control server and replay it at a later point. If the
message was signed, the attacker may attempt to establish a new TLS
connection with the floor control server and replay the message over
the new connection. Using TLS confidentiality prevents this attack
because the attacker cannot access the contents of the message in the
first place. Additionally, TLS provides replay protection for a
given connection. Therefore, it is strongly RECOMMENDED that TLS is
Camarillo Expires June 3, 2006 [Page 10]
Internet-Draft BFCP November 2005
used with a non-null encryption algorithm.
Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS confidentiality
prevents this attack.
5.6. IANA Considerations
The following sections instruct the IANA to perform a set of actions.
5.6.1. Attribute Registration
The IANA is instructed to register the following new values under the
Attribute subregistry under the BFCP Parameters registry.
+------+-----------+------------+
| Type | Attribute | Reference |
+------+-----------+------------+
| 17 | NONCE | [RFC XXXX] |
| 18 | DIGEST | [RFC XXXX] |
+------+-----------+------------+
Table 4: New values of the BFCP Attribute subregistry
5.6.2. Error Code Registration
The IANA is instructed to register the following new values under the
Error Code subregistry under the BFCP Parameters registry.
+-------+---------------------------+------------+
| Value | Meaning | Reference |
+-------+---------------------------+------------+
| 10 | DIGEST Attribute Required | [RFC XXXX] |
| 11 | Invalid Nonce | [RFC XXXX] |
| 12 | Authentication Failed | [RFC XXXX] |
+-------+---------------------------+------------+
Table 5: New Values of the Error Code subregistry
5.6.3. Digest Algorithm Subregistry
This Section establishes the Digest Algorithm subregistry under the
BFCP Parameters registry. As per the terminology in RFC 2434 [3],
the registration policy for BFCP digest algorithms shall be
"Specification Required". For the purposes of this subregistry, the
BFCP error codes for which IANA registration is requested MUST be
defined by a standards-track RFC. Such RFC MUST specify the value
Camarillo Expires June 3, 2006 [Page 11]
Internet-Draft BFCP November 2005
and the semantics of the error code, and any Error Specific Details
that apply to it.
For each BFCP digest algorithm, the IANA registers its numeric
identifier, its name, and the reference to the RFC where the
algorithm is defined. The following table contains the initial
values of this subregistry.
+------------+-----------+-----------+
| Identifier | Algorithm | Reference |
+------------+-----------+-----------+
| 0 | HMAC-SHA1 | RFC 2104 |
+------------+-----------+-----------+
Table 6: Initial values of the Digest Algorithms subregistry
6. Acknowledgments
Sam Hartman provided useful comments on this document.
7. Normative References
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3280, April 2002.
[6] Camarillo, G., "The Binary Floor Control Protocol (BFCP)",
draft-ietf-xcon-bfcp-05 (work in progress), July 2005.
[7] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005.
Camarillo Expires June 3, 2006 [Page 12]
Internet-Draft BFCP November 2005
Author's Address
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Camarillo Expires June 3, 2006 [Page 13]
Internet-Draft BFCP November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Camarillo Expires June 3, 2006 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-23 05:08:59 |