XCON Working Group                                          G. Camarillo
Internet-Draft                                                  Ericsson
Expires: March 19, July 16, 2007                                  January 12, 2007                               September 15, 2006

  Connection Establishment in the Binary Floor Control Protocol (BFCP)
                 draft-ietf-xcon-bfcp-connection-02.txt
                 draft-ietf-xcon-bfcp-connection-03.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 March 19, July 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006). IETF Trust (2007).

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  Client and server
   authentication mechanism for BFCP are based on shared
   secrets. Transport Layer Security (TLS).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  TCP Connection Establishment . . . . . . . . . . . . . . . . .  3
   4.  TLS Usage  . . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   5.  Authentication . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Certificate-based Mutual Server Authentication  . . . . . . . . .  5
     5.2.  Digest-based  Client Authentication . . . . . . . . . . . .  5
       5.2.1.  Client Behavior  . . . . . . . . . . . . . . . based on a Pre-shared Secret . . . .  6
       5.2.2.  Floor Control Server Behavior  . . . . . . . . . . . .  7
     5.3.  Attribute Definitions  . . . . . . . . . . . . . . . . . .  8
       5.3.1.  NONCE  . . . . . . . . . . . . . . . . . . . . . . . .  8
       5.3.2.  DIGEST . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.4.  Error Code Definitions . . . . . . . . . . . . . . . . . . 10
     5.5.
   6.  Security Considerations  . . . . . . . . . . . . . . . . . 10
     5.6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . 12
       5.6.1.  Attribute Registration . . . . . . . . . . . . . . . . 12
       5.6.2.  Error Code Registration  . . . . . . .  6
   7.  IANA Considerations  . . . . . . . . 12
       5.6.3.  Digest Algorithm Subregistry . . . . . . . . . . . . . 12
   6.  7
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  8
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 16 10

1.  Introduction

   As discussed in the BFCP (Binary Floor Control Protocol)
   specification [9], [10], 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 SDP [8] (Session Description Protocol) [9] offer/answer [4] exchange
   between a client and a floor control server is specified in [10]. RFC 4583
   [11].  This document specifies how a client establishes a connection
   to a floor control server outside the context of an SDP offer/answer
   exchange.

   BFCP entities establishing a connection outside an SDP 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. specifies how to authenticate clients using PSK (Pre-Shared
   Key)-TLS (Transport Layer Security) [7] and how to authenticate
   servers using server certificates.

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] [1] and indicate requirement levels for
   compliant implementations.

3.  TCP Connection Establishment

   As stated in Section 1, 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 (i.e., IP address and port)
   of the floor control server, it initiates a TCP connection towards
   it.  That is, the client performs an active TCP open.

   If the client is provided with the floor control server's host name
   instead of with its IP address, the client MUST perform a DNS lookup
   in order to resolve the host name into an IP address.  Clients
   eventually perform an A or AAAA DNS lookup (or both) on the host
   name.

   In order to translate the host name target to the corresponding set of IP
   addresses, IPv6-only or dual-stack clients MUST use the newer
   getaddrinfo() name lookup function, instead of gethostbyname() [7].
   The new function implements resolution
   functions that implement the Source and Destination Address Selection
   algorithms specified in [12], RFC3484 [6] (on many hosts that support IPv6,
   APIs like getaddrinfo() provide this functionality and is expected to be
   supported by all IPv6 hosts. subsume
   existing APIs like gethostbyname().)

   The advantage of the additional complexity is that this technique
   will output an ordered list of IPv6/IPv4 destination addresses based
   on the relative merits of the corresponding source/destination pairs.
   This will guarantee optimal routing.  However, the Source and
   Destination Selection algorithms of [6] are dependent on broad
   operating system support and uniform implementation of the
   application programming interfaces that implement this behavior.

      Developers should carefully consider the issues described by Roy
      et al. [11] [13] with respect to address resolution delays and address
      selection rules.  For example, implementations of getaddrinfo()
      may return address lists containing IPv6 global addresses at the
      top of the list and IPv4 addresses at the bottom, even when the
      host is only configured with an IPv6 local scope (e.g., link-
      local) and an IPv4 address.  This will, of course, introduce a
      delay in completing the connection.

   The BFCP specification [9] [10] 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 closed following the rules in
   [9], RFC
   4582 [10], 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.

4.  TLS Usage

   All BFCP entities implement TLS [8] 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 client 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 pre-shared secrets and
   server authentication for clients without based on server certificates.  This digest mechanism is described in Section 5.2.

5.1.  Certificate-based Mutual Server 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 certificate provided at
   the TLS-level MUST either be directly 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 server using a digest-based mechanism instead.  BFCP supports
   digest-based

   A client authentication based on establishing a shared secret between connection to a server knows the server's
   hostname or IP address.  If the client and knows the floor control server.  The floor control server of a
   conference shares a secret with each of server's hostname,
   the client MUST check it against the participants server's identity as presented
   in the
   conference and can request them to sign their messages using that
   shared secret.  Consequently, there is a need for a mechanism server's Certificate message, in order to
   generate such prevent man-in-the-
   middle attacks.

   If a shared secret.  However, such mechanism is outside
   the scope subjectAltName extension of this document.  This document assumes type dNSName is present, that shared
   secrets are generated and exchanged using out-of-band means.
   However, shared secrets MUST
   be at least as long used as the length identity.  Otherwise, the (most specific) Common Name
   field in the Subject field of the
   output certificate MUST be used.  Although
   the use of the digest algorithm used, as recommended in [1].

   Digest-based client authentication in BFCP Common Name is based on the DIGEST
   attribute, which existing practice, it is defined in Section 5.3.2.  This attribute, which
   always appears as the last attribute in a message, contains an
   algorithm identifier deprecated and a keyed digest of the BFCP message using
   that algorithm.  The text used as input
   Certification Authorities are encouraged to use the digest algorithm dNSName instead.

   Matching is performed using 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
   typically provided by the floor control server in an Error response
   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 resend 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 resend 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.  Floor control servers MUST NOT
   use the same nonce for the same shared secret more than once.

   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
   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 MAY choose
   to only authenticate the first message sent over the TLS connection.
   This way, the client does not need to sign every message it sends
   (message signatures can be long when compared with BFCP messages).
   Reducing the size of BFCP messages can considerably reduce
   transmission times over low-bandwidth links.

5.3.  Attribute Definitions

   The following new attribute types are defined:

                    +------+-----------+-------------+
                    | Type | Attribute | Format      |
                    +------+-----------+-------------+
                    |  19  | NONCE     | Unsigned16  |
                    |  20  | DIGEST    | OctetString |
                    +------+-----------+-------------+

                         Table 1: BFCP attributes

   Both are EXTENSION-ATTRIBUTES as matching rules specified in [9].

5.3.1.  NONCE

   The NONCE attribute can appear in any message.  The NONCE attribute
   MUST be the last attribute of messages that do not contain a DIGEST
   attribute and the second to last attribute by RFC 2459
   [2].  If more than one identity of messages that contain a
   DIGEST attribute (the DIGEST attribute is always the last).  The
   following given type 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 1 1|M|0 0 0 0 0 1 0 0|          Nonce Value          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: NONCE format

   Nonce Value: this 16-bit field contains a nonce.

5.3.2.  DIGEST

   The DIGEST attribute can only appear present in messages sent by clients.
   The DIGEST attribute MUST be the last attribute of the message
   certificate (e.g., more than one dNSName name, a match 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 1 0 0|M|    Length     |   Algorithm   |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                                                               |
     |                                                               |
     /                           Digest                              /
     /                                                               /
     |                                                               |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: DIGEST format

   Algorithm: this 8-bit field contains the identifier any one 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 set is the BFCP
      message, including the common header, up to and including the
      attribute preceding the DIGEST attribute.  Depending on the
      algorithm, this text considered acceptable).  Names may need to be padded with zeroes.

      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 contain the DIGEST attribute wildcard
   character * which is 32-bit aligned.  The Padding bits SHOULD be set considered to zero by the
      sender and MUST be ignored by match any single domain name
   component or component fragment (e.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com).

   If the receiver.

5.4.  Error Code Definitions

   This specification defines client knows the following new BFCP Error Codes:

                   +-------+---------------------------+
                   | Value | Meaning                   |
                   +-------+---------------------------+
                   |   10  | DIGEST Attribute Required |
                   |   11  | Invalid Nonce             |
                   |   12  | Authentication Failed     |
                   +-------+---------------------------+

                        Table 3: Error Code meaning

   The following is server's IP address, 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 iPAddress
   subjectAltName must be present in the identifiers of certificate and must exactly
   match the
      digest algorithms supported by IP address known to the floor control server client.

   If the hostname or IP address known to the client does not match the
   identity in order
      of preference (i.e., the first algorithm is certificate, user oriented clients MUST either notify
   the most preferred).

5.5.  Security Considerations

   BFCP can use TLS user (clients MAY give the user the opportunity to continue with
   the connection in any case) or message signatures terminate the connection with a bad
   certificate error.  Automated clients MUST log the error to an
   appropriate audit log (if available) and SHOULD terminate the
   connection (with a bad certificate error).  Automated clients MAY
   provide client
   authentication.  Floor control server a configuration setting that disables this check, but MUST
   provide a setting which enables it.

5.2.  Client Authentication based on a Pre-shared Secret

   Client authentication is based on TLS,
   which also provides replay a pre-shared secret between client
   and integrity protection, server.  Authentication is performed using PSK-TLS [7].

   The BFCP specification mandates support for the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.  Additionally, clients and
   confidentiality.  It
   servers supporting this specification MUST support the
   TLS_RSA_PSK_WITH_AES_128_CBC_SHA ciphersuite as well.

6.  Security Considerations

   Client and server authentication as specified in this document are
   based on the use of TLS.  Therefore, it is strongly 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 challenged by the floor control
   server. used.  Clients and floor
   control servers MAY use other security mechanisms as long as they
   provide similar security properties (i.e., replay and integrity protection, confidentiality, integrity
   protection, confidentiality, and client and server authentication).

   TLS PSK mode is subject to offline dictionary attacks.  In DHE and
   RSA modes, an attacker who can mount a single man-in-the-middle
   attack on a client/server pair can then mount a dictionary attack on
   the password.  In modes without DHE or RSA, an attacker who can
   record communications between a client/server pair can mount a
   dictionary attack on the password.  Accordingly, it is RECOMMENDED
   that where possible clients use certificate-based server
   authentication ciphersuites with PSK in order to defend against
   dictionary attacks.

   In addition, passwords SHOULD be chosen with enough entropy to
   provide some protection against dictionary attacks.  Because the
   entropy of text varies dramatically and is generally far less than
   that of an equivalent random bitstring, no hard and fast rules about
   password length are possible.  However, in general passwords SHOULD
   be chosen to be at least 8 characters and selected from a pool
   containing both upper and lower case, numbers, and special keyboard
   characters (note that an 8-character ASCII password has a maximum
   entropy of 56 bits and in general far lower).  FIPS PUB 112 [12]
   provides some guidance on the relevant issues.  If possible,
   passphrases are preferable to passwords.  In addition, a cooperating
   client and server
   authentication). pair MAY choose to derive the TLS PSK shared key
   from the passphrase via a password-based key derivation function such
   as PBKDF2 [3].

   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. TLS.  The floor control server assumes that
   attackers cannot hickjack the TLS connection and, therefore, that
   subsequent messages over the TLS connection come connections 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. authenticated clients.

   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.  Clients MUST NOT send any signed BFCP message to
   an unauthenticated floor control server in order to prevent man-in-
   the-middle attacks.

   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.  The use of nonces avoids this type of attack.
   As stated in Section 5.2.2, floor control servers do not use the same
   nonce for the same shared secret more than once.

   Using TLS confidentiality also prevents that attack because the
   attacker cannot they would try to access the contents of the message in the first
   place.  Additionally, TLS provides replay protection within a given
   connection.  Therefore, it resource
   (e.g., sending media) without having legitimate rights to access it.
   Floor control server impersonation is RECOMMENDED that avoided by having floor control
   servers present their server certificates at TLS is used with connection
   establishment time.

   Attackers may attempt to modify messages exchanged by a
   non-null encryption algorithm. client and a
   floor control server.  The integrity protection provided by TLS
   connections prevents this attack.

   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  Therefore, it is instructed to register the following new values under the
   Attribute subregistry under the BFCP Parameters registry.

                     +------+-----------+------------+
                     | Type | Attribute | Reference  |
                     +------+-----------+------------+
                     |  19  | NONCE     | [RFC XXXX] |
                     |  20  | DIGEST    | [RFC XXXX] |
                     +------+-----------+------------+

           Table 4: New values of the BFCP Attribute subregistry

   [Note to the RFC editor: please, replace RFCxxxx with the RFC number RECOMMENDED that will be assigned to this document.]

5.6.2.  Error Code Registration

   The IANA TLS 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

   [Note to the RFC editor: please, replace RFCxxxx used
   with the RFC number
   that will be assigned to this document.]

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 each BFCP digest algorithm, the a non-null encryption algorithm.

7.  IANA registers its numeric
   identifier, its name, and the reference to the Considerations

   This specification 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 does not contain any actions for the Digest Algorithms subregistry

6. IANA.

8.  Acknowledgments

   Sam Hartman and Hartman, Karim El Malki Malki, and Vijay Gurbani provided useful
   comments on this document.

7.  Eric Rescorla performed a detailed
   security analysis of this document.

9.  References

7.1.

9.1.  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.

   [2]   Housley, R., Ford, W., Polk, T., and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and CRL Profile",
         RFC 2459, January 1999.

   [3]   Kaliski, B., "PKCS #5: Password-Based Cryptography
         Specification Version 2.0", RFC 2434,
         October 1998. 2898, September 2000.

   [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]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [7]   Shin, M-K., Hong, Y-G., Hagino, J., Savola, P.,   Eronen, P. and E. Castro,
         "Application Aspects of IPv6 Transition", H. Tschofenig, "Pre-Shared Key Ciphersuites for
         Transport Layer Security (TLS)", RFC 4038, March 4279, December 2005.

   [8]   Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

   [9]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", RFC 4566, July 2006.

   [9]

   [10]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
         Protocol (BFCP)",
         draft-ietf-xcon-bfcp-06 (work in progress), December 2005.

   [10] RFC 4582, November 2006.

   [11]  Camarillo, G., "Session Description Protocol (SDP) Format for
         Binary Floor Control Protocol (BFCP) Streams",
         draft-ietf-mmusic-sdp-bfcp-03 (work in progress),
         December 2005.

7.2. RFC 4583,
         November 2006.

   [12]  National Institute of Standards and Technology (NIST),
         "Password Usage", FIPS PUB 112, May 1985.

9.2.  Informative References

   [11]

   [13]  Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered
         Harmful", draft-ietf-v6ops-onlinkassumption-04 (work in
         progress), January 2006.

Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.

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 (2006).  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. IETF
   Administrative Support Activity (IASA).