From nobody Wed Feb 4 00:08:13 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3071A6FE9 for ; Wed, 4 Feb 2015 00:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSWmD7Qfvnfh for ; Wed, 4 Feb 2015 00:08:06 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E0D1A6F2D for ; Wed, 4 Feb 2015 00:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=260; q=dns/txt; s=iport; t=1423037285; x=1424246885; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LesyxCvUr9/BbeAT3Nebfa+YXYw/J62nL35fntiMSzU=; b=ZonFQ1/ZvooLPY9v9XNmxivvr+o7Dt5HuAdmpkhOiijJZlI5qbsxbZ3P LdASIgXF9y7umiGx1kVvt9EFALQ4lHJQNkku8HlbdvzKaRSr/r5sowh8k 2CU1eA/3Q8th8M6hUuLumpLOgPw+d4wR3NhIirByHuVAwMzQF6PxvwSbJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAO/S0VStJV2Q/2dsb2JhbABagwaBL8wNQwEBAQEBfYQTOlEBPkInBIhAsAqmKgEBCAIBH5QoBY8MiSaBF4MDjkUig26CM34BAQE X-IronPort-AV: E=Sophos;i="5.09,517,1418083200"; d="scan'208";a="390161285" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP; 04 Feb 2015 08:08:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t14882jU013188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 4 Feb 2015 08:08:02 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.34]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 02:08:02 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: deadline to request a WG session at IETF 92 Thread-Index: AQHQQFGyKZIVxRqk80GlRQKiVG7uIw== Date: Wed, 4 Feb 2015 08:08:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.185.183] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F16C85ECF816D4297CE24EF11BC1BBB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [bfcpbis] deadline to request a WG session at IETF 92 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 08:08:10 -0000 Friday is the deadline to request a session for IETF 92. As of now, we are not planning to submit a request for a session for BFCPBIS. If anyone foresees a need for a session, please contact the chairs so we can discuss in more detail. Cheers, Charles From nobody Wed Feb 4 10:40:24 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7658F1A1AE3 for ; Wed, 4 Feb 2015 10:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwqTr8lEbHB6 for ; Wed, 4 Feb 2015 10:40:18 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573241A1A64 for ; Wed, 4 Feb 2015 10:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32904; q=dns/txt; s=iport; t=1423075218; x=1424284818; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ceoy4fD/s9/r/z36seaNrjvxhgB9Sq2KIe0dGe45mC4=; b=fdqoyVogt9v5oaDXXjUxsXh0Uakhpw1YtDhIvKzkitWgi5cyijEB4xPm q59ZyArWR84aXh+kzEpMNVQd1g8wFOoWJiQLryA2zSzV3zMi2LUqr4xk4 inouc6eUC/03GFgEfuKpIwVT72qwq7Wcg7SFvZ6E0e7BEpUWL5RqwoG+7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BvBQA1Z9JU/5pdJa1agkNDUlkEwj2FcQKBHkMBAQEBAX2EDAEBAQRnASECAQgRAwECFgEKAQYHMhQJCAIEARKILQ3WWQEBAQEBAQQBAQEBAQEBFwSPNjENCwYECAyECwWNHRCBY4NQgVCECYEXgwOCRkmHfYM9IoICHIFQb4EEBxcifgEBAQ X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208,217";a="120563613" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 04 Feb 2015 18:40:17 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t14IeHMY016520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 18:40:17 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.34]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 12:40:16 -0600 From: "Charles Eckel (eckelcu)" To: Alissa Cooper , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 Thread-Index: AQHQPAleDovxcQJAY0eo+YwSl+sRq5zgum0A Date: Wed, 4 Feb 2015 18:40:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.185.183] Content-Type: multipart/alternative; boundary="_000_D0F684B33C625eckelcuciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:40:22 -0000 --_000_D0F684B33C625eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Alissa, Thank you for the review. Please see my thoughts on your comments and quest= ions inline. From: Alissa Cooper > Date: Thursday, January 29, 2015 at 10:19 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 I have reviewed this draft in preparation for IETF LC. Overall the document= appears in good shape. I have a few questions and comments I=92d like to d= iscuss before issuing the IETF last call. I=92ve also included some editori= al nits that should be addressed together with any last call comments. Comments and questions: =3D Section 5.1 =3D "If an endpoint receives a message with an unsupported version field value, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this.=94 This seems a little misleading since RFC 4582 didn=92t specify what to do u= pon receipt of a message with a version other than 1. Implementations that = do not get upgraded to be compliant with 4582bis (which could certainly acc= ount for some of those that will not support version 2) will therefore neve= r send the error specified here. This seems like it should at least be note= d given the MUST-level requirement. The same applies in Section 13.7. Good point. I believe we made this a MUST because we were thinking in terms= of implementations compliant with this bis version. Adding your suggested = note about rfc 4582 implementations here and in section 13.7 seems useful t= o me. =3D Section 7 =3D "BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94 I realize this requirement comes from RFC 4582, but I=92d like to understan= d why it has not been updated to be consistent with more current guidance o= n cipher suite selection (e.g., https://tools.ietf.org/html/draft-ietf-uta-= tls-bcp-08#section-4). How about we keep this minimum requirement, and add a reference to draft-ie= tf-uta-tls-bcp along with a recommendation to adhere to the best practices = it outlines in section 4? =3D Sections 8, 8.1, 8.2 =3D It seems like the transaction ID requirements regarding non-reuse/monotonic= ally increasing IDs are re-stated multiple times across these three section= s, in slightly different ways, to the point where it=92s not clear exactly = what they are. It seems like they are: (1) Reliable transport, server-initiated transaction: ID is 0 (2) Unreliable transport, server-initiated transaction: ID MUST be monotoni= cally increasing (except for wrap-around) (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0 and = MUST NOT be reused in another message from the client until a response from= the server is received for the transaction, but need not be monotonically = increasing (e.g., a lower, recently used ID could be re-used once a respons= e is received) (4) Unreliable transport, client-initiated transaction: ID MUST be monotoni= cally increasing (except for wrap-around) Is (3) the correct interpretation of the text in 8.1? If so, why not just r= equire IDs in all client-initiated transactions to be monotonically increas= ing? Agree we can and should simplify this. Sections 8.1 and 8.2 cover the clien= t behavior and server behavior in detail. As such, the transaction ID relat= ed information at the start of Section 8 is superfluous. I recommend reduci= ng the text in Section 8 to the follow: 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. Server-initiated transactions have different behavior depending on underlying transport: When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger any response. When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. When using BFCP over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. Then in section 8.1, we add the important details removed from section 8. 8.1.1 Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is important to choose a Transaction ID value that lets the receiver distinguish the rec= eption of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable tra= nsport MUST use monotonically increasing Transaction ID values (except for wrap-arou= nd). A client receiving a server-initiated transaction over an unreliable tra= nsport MUST copy the Transaction ID from the request received from the server i= nto the response. [Question: is there a need to copy the Conference ID and User ID, if pre= sent?] 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions. The server uses the Transaction ID value = to match this message with the response from the floor participant or floor chair. =3D Section 9 (impacts Section 14 as well) =3D "BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.=94 What are the cases where clients and servers do not need to be authenticati= ng each other? I know this requirement and the other SHOULD-level requireme= nts around use of TLS/DTLS are carried over from RFC 4582, but I=92m concer= ned that they aren=92t as strong as they should be. For a conference where = the signaling traffic is authenticated and confidentiality and integrity pr= otected, why is it ok for the floor control traffic not to be? Could these = requirements be adjusted to require use of TLS/DTLS at least in cases where= the signaling is also protected? Yes, but again, this would be at the expense of adding a non backward compa= tible change from rfc 4582. How about saying TLS/DTLS MUST be used for BFCP= in such cases, while pointing out the rfc 4582 based implementations may n= ot comply (similar to what we did with the version field). =3D Section 14 =3D See the point above about ciphersuites. =93Non-null encryption=94 is not a = sufficient minimum baseline, and if the requirements change in Section 7 th= ey should be reflected here as well. Yep. Editorial nits to be resolved with LC comments: =3D Section 5.1 =3D =93The version field MUST be set to 1 when using BFCP over a reliable transport, i.e. as in [2].=94 I find it a little odd to reference the spec you=92re obsoleting in this se= ntence, especially since BFCP over a reliable transport is completely speci= fied in this bis document. I would suggest dropping the i.e. clause. Good catch. This is a carry over from before this draft was adopted as a bi= s version of rfc4582. "The version field MUST be set to 2 when using BFCP over an unreliable transport with the extensions specified in this document.=94 The bit about =93with the extensions specified in this document=94 is extra= neous and should be removed. "If an endpoint receives a message with an unsupported version field value, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this.=94 Use of the word =93server=94 here makes it sound as if only servers could r= eceive headers with unsupported versions. Should this be =93the receiving e= ndpoint=94? =3D Section 6.2.4 =3D "[23], Section 6.7 provides useful recommendations =85=94 The links in the references are not quite right. =3D Section 8.3.2 =3D s/when fires/when fired/ =3D Section 14 =3D s/high-jack/hijack/ =3D Section B.1 =3D "situation where multiple different and non-interoperable would co- exist in the market.=94 There is a word missing after =93non-interoperable." This should read =93non-interoperable implementations=94. Earlier in that s= ame sentence, =93BFCP over UDP were already used=94 should read =93BFCP ove= r UDP is already being used=94. Cheers, Charles --_000_D0F684B33C625eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <461D3491EDECBC4A98F0E6DF9EE8336F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
HI Alissa,

Thank you for the review. Please see my thoughts on your comments and quest= ions inline.

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, January 29, 2015 at= 10:19 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD evaluation: d= raft-ietf-bfcpbis-rfc4582bis-12

I have reviewed this draft in preparation for IETF LC. Overall the doc= ument appears in good shape. I have a few questions and comments I=92d like= to discuss before issuing the IETF last call. I=92ve also included some ed= itorial nits that should be addressed together with any last call comments.

Comments and questions:

=3D Section 5.1 =3D
"If an endpoint receives a message with an
     unsupported version field value, the receiving server MUST = send an
     Error message with parameter value 12 (Unsupported Version)= to
     indicate this.=94

This seems a little misleading since RFC 4582 didn=92t specify what to= do upon receipt of a message with a version other than 1. Implementations = that do not get upgraded to be compliant with 4582bis (which could certainl= y account for some of those that will not support version 2) will therefore never send the error specified here.= This seems like it should at least be noted given the MUST-level requireme= nt. The same applies in Section 13.7.

Good point. I believe we made this a MUST because we were thinking in terms= of implementations compliant with this bis version. Adding your suggested = note about rfc 4582 implementations here and in section 13.7 seems useful t= o me.
 


=3D Section 7 =3D
"BFCP entities MUST support, at a minimum, the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94

I realize this requirement comes from RFC 4582, but I=92d like to unde= rstand why it has not been updated to be consistent with more current guida= nce on cipher suite selection (e.g., https://tools.ietf.org/html/draf= t-ietf-uta-tls-bcp-08#section-4).

How about we keep this minimum requirement, and add a reference to dra= ft-ietf-uta-tls-bcp along with a recommendation to adhere to the best pract= ices it outlines in section 4?



=3D Sections 8, 8.1, 8.2 =3D
It seems like the transaction ID requirements regarding non-reuse/mono= tonically increasing IDs are re-stated multiple times across these three se= ctions, in slightly different ways, to the point where it=92s not clear exa= ctly what they are. It seems like they are:

(1) Reliable transport, server-initiated transaction: ID is 0
(2) Unreliable transport, server-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)
(3) Reliable transport, client-initiated transaction: ID MUST NOT be 0= and MUST NOT be reused in another message from the client until a response= from the server is received for the transaction, but need not be monotonic= ally increasing (e.g., a lower, recently used ID could be re-used once a response is received)
(4) Unreliable transport, client-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)

Is (3) the correct interpretation of the text in 8.1? If so, why not j= ust require IDs in all client-initiated transactions to be monotonically in= creasing?

Agree we can and should simplify this. Sections 8.1 and 8.2 cover the clien= t behavior and server behavior in detail. As such, the transaction ID relat= ed information at the start of Section 8 is superfluous. I recommend reduci= ng the text in Section 8 to the follow:

8. Protocol Transactions

   In BFCP, there are two = types of transactions: client-initiated
   transactions and server= -initiated transactions.

   Client-initiated transa= ctions consist of a request from a client to a
   floor control server an= d a response from the floor control server to
   the client.

   Server-initiated transa= ctions have different behavior depending on 
   underly= ing transport:

      When using a re= liable transport, server-initiated transactions
      consist of a si= ngle message from a floor control server to a
      client (notific= ations).  They do not trigger any response.

      When using an u= nreliable transport, server-initiated transactions
      consist of a re= quest from a floor control server to a client and a
      response from t= he client to the floor control server.

   When using BFCP over an= unreliable transport, retransmission timer T1
   (see Section 8.3) MUST = be used for all requests until the transaction
   is completed.

Then in section 8.1, we add the impo= rtant details removed from section 8.

8.1.1 Client Behavior

   A client starting a client-initiated transaction MUST set= the
   Conference ID in the common header of the message to the = Conference
   ID for the conference that the client obtained previously= . 

   The client MUST set the Transaction ID value in the commo= n header to
   a number that is different from 0 and that MUST NOT be re= used in
   another message from the client until a response from the= server is
   received for the transaction.  The client uses the T= ransaction ID
   value to match this message with the response from the fl= oor control
   server. When using BFCP over an unreliable transport, it = is important to
   choose a Transaction ID value that lets the receiver dist= inguish the reception 
   of the next message in a sequence of BFCP messages from a= retransmission 
   of a previous message.  Therefore, BFCP entities usi= ng an unreliable transport MUST
   use monotonically incre= asing Transaction ID values (except for wrap-around).

   A client rece= iving a server-initiated transaction over an unreliable transport
   MUST copy the= Transaction ID from the request received from the server into the
   response.&nbs= p;
   [Question: is= there a need to copy the Conference ID and User ID, if present?]

8.2. Server Behavior

   A floor control server = sending a response within a client-initiated
   transaction MUST copy t= he Conference ID, the Transaction ID, and the
   User ID from the reques= t received from the client into the response.

   Server-initiated transa= ctions MUST contain a Transaction ID equal to
   0 when BFCP is used ove= r a reliable transport.  Over an unreliable
   transport, the Transact= ion ID shall have the same properties as for
   client-initiated transa= ctions. The s= erver uses the Transaction ID value to
   match this message with= the response from the floor participant or
   floor chair.



=3D Section 9 (impacts Section 14 as well) =3D
"BFCP clients SHOULD authenticate the floor control server before=
   sending any BFCP message to it or accepting any BFCP mess= age from it.
   Similarly, floor control servers SHOULD authenticate a cl= ient before
   accepting any BFCP message from it or sending any BFCP me= ssage to it.

   BFCP supports TLS/DTLS mutual authentication between clie= nts and
   floor control servers, as specified in Section 9.1.  = ;This is the
   RECOMMENDED authentication mechanism in BFCP.=94

What are the cases where clients and servers do not need to be authent= icating each other? I know this requirement and the other SHOULD-level requ= irements around use of TLS/DTLS are carried over from RFC 4582, but I=92m c= oncerned that they aren=92t as strong as they should be. For a conference where the signaling traffic is authent= icated and confidentiality and integrity protected, why is it ok for the fl= oor control traffic not to be? Could these requirements be adjusted to requ= ire use of TLS/DTLS at least in cases where the signaling is also protected?

Yes, but again, this would be at the expense of adding a non backward compa= tible change from rfc 4582. How about saying TLS/DTLS MUST be used for BFCP= in such cases, while pointing out the rfc 4582 based implementations may n= ot comply (similar to what we did with the version field).


=3D Section 14 =3D
See the point above about ciphersuites. =93Non-null encryption=94 is n= ot a sufficient minimum baseline, and if the requirements change in Section= 7 they should be reflected here as well.

Yep.



Editorial nits to be resolved with LC comments:

=3D Section 5.1 =3D
=93The version field MUST be set to 1 when using BFCP over a reliable<= /div>
   transport, i.e. as in [2].=94

I find it a little odd to reference the spec you=92re obsoleting in th= is sentence, especially since BFCP over a reliable transport is completely = specified in this bis document. I would suggest dropping the i.e. clause.

Good catch. This is a carry over from before this draft was adopted as a bi= s version of rfc4582.


"The version field MUST be set to 2 when
   using BFCP over an unreliable transport with the extensio= ns specified
   in this document.=94

The bit about =93with the extensions specified in this document=94 is = extraneous and should be removed.

"If an endpoint receives a message with an
    unsupported version field value, the receiving server MUST send an<= span class=3D"Apple-tab-span" style=3D"white-space:pre">
    Error message with parameter value 12 (Unsupported Version) to
    indicate this.=94

Use of the word =93server=94 here makes it sound as if only servers co= uld receive headers with unsupported versions. Should this be =93the receiv= ing endpoint=94?

=3D Section 6.2.4 =3D
"[23], Section 6.7 provides useful recommendations =85=94

The links in the references are not quite right.

=3D Section 8.3.2 =3D
s/when fires/when fired/

=3D Section 14 =3D
s/high-jack/hijack/

=3D Section B.1 =3D
"situation where multiple = different and non-interoperable would co-
   exist in the market.=94

There is a word missing after =93non-interoperable."

This should read =93non-interoperable implementations=94. Earlier in that s= ame sentence, =93BFCP over UDP were already used=94 should read =93BFCP ove= r UDP is already being used=94.

Cheers,
Charles
--_000_D0F684B33C625eckelcuciscocom_-- From nobody Mon Feb 9 15:59:36 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5F01A8AAD for ; Mon, 9 Feb 2015 15:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYoLgyx2LIoA for ; Mon, 9 Feb 2015 15:58:56 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B6D1A6EE8 for ; Mon, 9 Feb 2015 15:58:56 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 797D620DAC for ; Mon, 9 Feb 2015 18:58:55 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 09 Feb 2015 18:58:55 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=mesmtp; bh=uYMzt7iwJuEZWO7A GFJfAWr+Lc0=; b=ZIHTG03q+aGcyNuhsDprHouMBIv9Kz6jPix8ngaSvGxVZ4+9 1FKU9DpwN0gYklNkiCCEK8E5MsaO9dpeesE2SWzDwqRU6DTWiwcJxPHoJAKLvoom Yv5TPPq5jH3lrFqFCpduNid9jmHmfl58ERZfn4H9jHrz4SW8H6JI3D0Pci8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:message-id:references:to; s= smtpout; bh=uYMzt7iwJuEZWO7AGFJfAWr+Lc0=; b=ldo01GK5RHAYFrkh82eR H0I7kTk9n74AiQ0IkPyXQIsbHborUFlTjCTGBMSt7rsUu6QGYaIreFqSAc6AyygS 98LN/UT481bK39Ans6lcVCMyyJrZe6fAYdc54OGDJ1meAe06ldTzbs4Dp1+RdPPh QcKnbHTvA56IxcUfcqG2XhY= X-Sasl-enc: 7T5Httgsqfbdbmx8Rvd0FxMBnmoV5tP49Pej0EsIk5dH 1423526334 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id D56026800DB; Mon, 9 Feb 2015 18:58:53 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_10252BE8-4DCC-44B6-AE9B-AB185B336BD6" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: Date: Mon, 9 Feb 2015 15:58:52 -0800 Message-Id: References: To: "Charles Eckel (eckelcu)" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:59:05 -0000 --Apple-Mail=_10252BE8-4DCC-44B6-AE9B-AB185B336BD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Charles, Thanks, some responses inline. On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) = wrote: > HI Alissa, >=20 > Thank you for the review. Please see my thoughts on your comments and = questions inline. >=20 > From: Alissa Cooper > Date: Thursday, January 29, 2015 at 10:19 PM > To: "bfcpbis@ietf.org" > Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 >=20 >> I have reviewed this draft in preparation for IETF LC. Overall the = document appears in good shape. I have a few questions and comments I=92d = like to discuss before issuing the IETF last call. I=92ve also included = some editorial nits that should be addressed together with any last call = comments. >>=20 >> Comments and questions: >>=20 >> =3D Section 5.1 =3D >> "If an endpoint receives a message with an >> unsupported version field value, the receiving server MUST send = an >> Error message with parameter value 12 (Unsupported Version) to >> indicate this.=94 >>=20 >> This seems a little misleading since RFC 4582 didn=92t specify what = to do upon receipt of a message with a version other than 1. = Implementations that do not get upgraded to be compliant with 4582bis = (which could certainly account for some of those that will not support = version 2) will therefore never send the error specified here. This = seems like it should at least be noted given the MUST-level requirement. = The same applies in Section 13.7. >=20 >=20 > Good point. I believe we made this a MUST because we were thinking in = terms of implementations compliant with this bis version. Adding your = suggested note about rfc 4582 implementations here and in section 13.7 = seems useful to me. Ok > =20 >>=20 >>=20 >> =3D Section 7 =3D >> "BFCP entities MUST support, at a minimum, the >> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94 >>=20 >> I realize this requirement comes from RFC 4582, but I=92d like to = understand why it has not been updated to be consistent with more = current guidance on cipher suite selection (e.g., = https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4). >=20 >=20 > How about we keep this minimum requirement, and add a reference to = draft-ietf-uta-tls-bcp along with a recommendation to adhere to the best = practices it outlines in section 4? I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards = compatibility and SHOULD support the ones listed in the UTA drafts would = be ok. >=20 >>=20 >>=20 >> =3D Sections 8, 8.1, 8.2 =3D >> It seems like the transaction ID requirements regarding = non-reuse/monotonically increasing IDs are re-stated multiple times = across these three sections, in slightly different ways, to the point = where it=92s not clear exactly what they are. It seems like they are: >>=20 >> (1) Reliable transport, server-initiated transaction: ID is 0 >> (2) Unreliable transport, server-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around) >> (3) Reliable transport, client-initiated transaction: ID MUST NOT be = 0 and MUST NOT be reused in another message from the client until a = response from the server is received for the transaction, but need not = be monotonically increasing (e.g., a lower, recently used ID could be = re-used once a response is received) >> (4) Unreliable transport, client-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around) >>=20 >> Is (3) the correct interpretation of the text in 8.1? If so, why not = just require IDs in all client-initiated transactions to be = monotonically increasing? >=20 >=20 > Agree we can and should simplify this. Sections 8.1 and 8.2 cover the = client behavior and server behavior in detail. As such, the transaction = ID related information at the start of Section 8 is superfluous. I = recommend reducing the text in Section 8 to the follow: >=20 > 8. Protocol Transactions >=20 > In BFCP, there are two types of transactions: client-initiated > transactions and server-initiated transactions. >=20 > Client-initiated transactions consist of a request from a client to = a > floor control server and a response from the floor control server = to > the client. >=20 > Server-initiated transactions have different behavior depending on=20= > underlying transport: >=20 > When using a reliable transport, server-initiated transactions > consist of a single message from a floor control server to a > client (notifications). They do not trigger any response. >=20 > When using an unreliable transport, server-initiated = transactions > consist of a request from a floor control server to a client and = a > response from the client to the floor control server. >=20 > When using BFCP over an unreliable transport, retransmission timer = T1 > (see Section 8.3) MUST be used for all requests until the = transaction > is completed. >=20 > Then in section 8.1, we add the important details removed from section = 8. >=20 > 8.1.1 Client Behavior >=20 > A client starting a client-initiated transaction MUST set the > Conference ID in the common header of the message to the Conference > ID for the conference that the client obtained previously.=20 >=20 > The client MUST set the Transaction ID value in the common header = to > a number that is different from 0 and that MUST NOT be reused in > another message from the client until a response from the server is > received for the transaction. The client uses the Transaction ID > value to match this message with the response from the floor = control > server. When using BFCP over an unreliable transport, it is = important to > choose a Transaction ID value that lets the receiver distinguish = the reception=20 > of the next message in a sequence of BFCP messages from a = retransmission=20 > of a previous message. Therefore, BFCP entities using an = unreliable transport MUST > use monotonically increasing Transaction ID values (except for = wrap-around). >=20 > A client receiving a server-initiated transaction over an = unreliable transport > MUST copy the Transaction ID from the request received from the = server into the > response.=20 > [Question: is there a need to copy the Conference ID and User ID, = if present?] >=20 > 8.2. Server Behavior >=20 > A floor control server sending a response within a client-initiated > transaction MUST copy the Conference ID, the Transaction ID, and = the > User ID from the request received from the client into the = response. >=20 > Server-initiated transactions MUST contain a Transaction ID equal = to > 0 when BFCP is used over a reliable transport. Over an unreliable > transport, the Transaction ID shall have the same properties as for > client-initiated transactions. The server uses the Transaction ID = value to > match this message with the response from the floor participant or > floor chair. >=20 Thanks, this is better. >>=20 >>=20 >> =3D Section 9 (impacts Section 14 as well) =3D >> "BFCP clients SHOULD authenticate the floor control server before >> sending any BFCP message to it or accepting any BFCP message from = it. >> Similarly, floor control servers SHOULD authenticate a client = before >> accepting any BFCP message from it or sending any BFCP message to = it. >>=20 >> BFCP supports TLS/DTLS mutual authentication between clients and >> floor control servers, as specified in Section 9.1. This is the >> RECOMMENDED authentication mechanism in BFCP.=94 >>=20 >> What are the cases where clients and servers do not need to be = authenticating each other? I know this requirement and the other = SHOULD-level requirements around use of TLS/DTLS are carried over from = RFC 4582, but I=92m concerned that they aren=92t as strong as they = should be. For a conference where the signaling traffic is authenticated = and confidentiality and integrity protected, why is it ok for the floor = control traffic not to be? Could these requirements be adjusted to = require use of TLS/DTLS at least in cases where the signaling is also = protected? >=20 >=20 > Yes, but again, this would be at the expense of adding a non backward = compatible change from rfc 4582. How about saying TLS/DTLS MUST be used = for BFCP in such cases, while pointing out the rfc 4582 based = implementations may not comply (similar to what we did with the version = field). Works for me. Feel free to make all of these changes and submit a rev and I=92ll issue = the IETF LC. Thanks, Alissa >>=20 >>=20 >> =3D Section 14 =3D >> See the point above about ciphersuites. =93Non-null encryption=94 is = not a sufficient minimum baseline, and if the requirements change in = Section 7 they should be reflected here as well. >=20 >=20 > Yep. >=20 >>=20 >>=20 >> Editorial nits to be resolved with LC comments: >>=20 >> =3D Section 5.1 =3D >> =93The version field MUST be set to 1 when using BFCP over a reliable >> transport, i.e. as in [2].=94 >>=20 >> I find it a little odd to reference the spec you=92re obsoleting in = this sentence, especially since BFCP over a reliable transport is = completely specified in this bis document. I would suggest dropping the = i.e. clause. >=20 >=20 > Good catch. This is a carry over from before this draft was adopted as = a bis version of rfc4582. >=20 >>=20 >> "The version field MUST be set to 2 when >> using BFCP over an unreliable transport with the extensions = specified >> in this document.=94 >>=20 >> The bit about =93with the extensions specified in this document=94 is = extraneous and should be removed. >>=20 >> "If an endpoint receives a message with an >> unsupported version field value, the receiving server MUST send = an >> Error message with parameter value 12 (Unsupported Version) to >> indicate this.=94 >>=20 >> Use of the word =93server=94 here makes it sound as if only servers = could receive headers with unsupported versions. Should this be =93the = receiving endpoint=94? >>=20 >> =3D Section 6.2.4 =3D >> "[23], Section 6.7 provides useful recommendations =85=94 >>=20 >> The links in the references are not quite right. >>=20 >> =3D Section 8.3.2 =3D >> s/when fires/when fired/ >>=20 >> =3D Section 14 =3D >> s/high-jack/hijack/ >>=20 >> =3D Section B.1 =3D >> "situation where multiple different and non-interoperable would co- >> exist in the market.=94 >>=20 >> There is a word missing after =93non-interoperable." >=20 >=20 > This should read =93non-interoperable implementations=94. Earlier in = that same sentence, =93BFCP over UDP were already used=94 should read = =93BFCP over UDP is already being used=94. >=20 > Cheers, > Charles --Apple-Mail=_10252BE8-4DCC-44B6-AE9B-AB185B336BD6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Charles,

Thanks, = some responses inline.

On Feb 4, 2015, at 10:40 = AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> = wrote:

HI Alissa,

Thank you for the review. Please see my thoughts on your comments and = questions inline.

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, January 29, 2015 = at 10:19 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD = evaluation: draft-ietf-bfcpbis-rfc4582bis-12

I have reviewed this draft in preparation for IETF LC. Overall the = document appears in good shape. I have a few questions and comments I=92d = like to discuss before issuing the IETF last call. I=92ve also included = some editorial nits that should be addressed together with any last call comments.

Comments and questions:

=3D Section 5.1 =3D
"If an endpoint receives a message with an
  =    unsupported version field value, the receiving = server MUST send an
  =    Error message with parameter value 12 (Unsupported = Version) to
  =    indicate this.=94

This seems a little misleading since RFC 4582 didn=92t specify what = to do upon receipt of a message with a version other than 1. = Implementations that do not get upgraded to be compliant with 4582bis = (which could certainly account for some of those that will not support version 2) will therefore never send the error specified = here. This seems like it should at least be noted given the MUST-level = requirement. The same applies in Section 13.7.

Good point. I believe we made this a MUST because we were thinking in = terms of implementations compliant with this bis version. Adding your = suggested note about rfc 4582 implementations here and in section 13.7 = seems useful to = me.

Ok

 


=3D Section 7 =3D
"BFCP entities MUST support, at a minimum, the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94

I realize this requirement comes from RFC 4582, but I=92d like to = understand why it has not been updated to be consistent with more = current guidance on cipher suite selection (e.g., h= ttps://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).
=

How about we keep this minimum requirement, and add a reference = to draft-ietf-uta-tls-bcp along with a recommendation to adhere to = the best practices it outlines in section = 4?

I think MUST = support TLS_RSA_WITH_AES_128_CBC_SHA for backwards compatibility = and SHOULD support the ones listed in the UTA drafts would be = ok.




=3D Sections 8, 8.1, 8.2 =3D
It seems like the transaction ID requirements regarding = non-reuse/monotonically increasing IDs are re-stated multiple times = across these three sections, in slightly different ways, to the point = where it=92s not clear exactly what they are. It seems like they are:

(1) Reliable transport, server-initiated transaction: ID is 0
(2) Unreliable transport, server-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around)
(3) Reliable transport, client-initiated transaction: ID MUST NOT = be 0 and MUST NOT be reused in another message from the client until a = response from the server is received for the transaction, but need not = be monotonically increasing (e.g., a lower, recently used ID could be re-used once a response is received)
(4) Unreliable transport, client-initiated transaction: ID MUST be = monotonically increasing (except for wrap-around)

Is (3) the correct interpretation of the text in 8.1? If so, why = not just require IDs in all client-initiated transactions to be = monotonically increasing?

Agree we can and should simplify this. Sections 8.1 and 8.2 cover the = client behavior and server behavior in detail. As such, the transaction = ID related information at the start of Section 8 is superfluous. I = recommend reducing the text in Section 8 to the follow:

8. Protocol = Transactions

   In BFCP, there are = two types of transactions: client-initiated
   transactions and = server-initiated transactions.

   Client-initiated = transactions consist of a request from a client to a
   floor control server = and a response from the floor control server to
   the = client.

   Server-initiated = transactions have different behavior depending on 
  =  underlying transport:

      When using a = reliable transport, server-initiated transactions
      consist of a = single message from a floor control server to a
      client = (notifications).  They do not trigger any response.

      When using = an unreliable transport, server-initiated transactions
      consist of a = request from a floor control server to a client and a
      response = from the client to the floor control server.

   When using BFCP over = an unreliable transport, retransmission timer T1
   (see Section 8.3) = MUST be used for all requests until the transaction
   is = completed.

Then in section 8.1, we add the = important details removed from section 8.

8.1.1 Client Behavior

   A client starting a client-initiated transaction MUST = set the
   Conference ID in the common header of the message to = the Conference
   ID for the conference that the client obtained = previously. 

   The client MUST set the Transaction ID value in the = common header to
   a number that is different from 0 and that MUST NOT be = reused in
   another message from the client until a response from = the server is
   received for the transaction.  The client uses = the Transaction ID
   value to match this message with the response from the = floor control
   server. When using BFCP over an unreliable transport, = it is important to
   choose a Transaction ID value that lets the receiver = distinguish the reception 
   of the next message in a sequence of BFCP messages = from a retransmission 
   of a previous message.  Therefore, BFCP entities = using an unreliable transport MUST
   use monotonically = increasing Transaction ID values (except for wrap-around).

   A client = receiving a server-initiated transaction over an unreliable = transport
   MUST copy = the Transaction ID from the request received from the server into = the
  =  response. 
   [Question: = is there a need to copy the Conference ID and User ID, if = present?]

8.2. Server Behavior

   A floor control = server sending a response within a client-initiated
   transaction MUST = copy the Conference ID, the Transaction ID, and the
   User ID from the = request received from the client into the response.

   Server-initiated = transactions MUST contain a Transaction ID equal to
   0 when BFCP is used = over a reliable transport.  Over an unreliable
   transport, the = Transaction ID shall have the same properties as for
   client-initiated = transactions. The server uses the Transaction ID value to
   match this message = with the response from the floor participant or
   floor = chair.


Thanks, this is = better.



=3D Section 9 (impacts Section 14 as well) =3D
"BFCP clients SHOULD authenticate the floor control server = before
   sending any BFCP message to it or accepting any BFCP = message from it.
   Similarly, floor control servers SHOULD authenticate a = client before
   accepting any BFCP message from it or sending any BFCP = message to it.

   BFCP supports TLS/DTLS mutual authentication between = clients and
   floor control servers, as specified in Section 9.1. =  This is the
   RECOMMENDED authentication mechanism in BFCP.=94

What are the cases where clients and servers do not need to be = authenticating each other? I know this requirement and the other = SHOULD-level requirements around use of TLS/DTLS are carried over from = RFC 4582, but I=92m concerned that they aren=92t as strong as they should be. For a conference where the signaling traffic is = authenticated and confidentiality and integrity protected, why is it ok = for the floor control traffic not to be? Could these requirements be = adjusted to require use of TLS/DTLS at least in cases where the signaling is also protected?

Yes, but again, this would be at the expense of adding a non backward = compatible change from rfc 4582. How about saying TLS/DTLS MUST be used = for BFCP in such cases, while pointing out the rfc 4582 based = implementations may not comply (similar to what we did with the version = field).

Works for = me.

Feel free to make all of these changes and = submit a rev and I=92ll issue the IETF = LC.

Thanks,
Alissa



=3D Section 14 =3D
See the point above about ciphersuites. =93Non-null encryption=94 = is not a sufficient minimum baseline, and if the requirements change in = Section 7 they should be reflected here as well.

Yep.



Editorial nits to be resolved with LC comments:

=3D Section 5.1 =3D
=93The version field MUST be set to 1 when using BFCP over a = reliable
   transport, i.e. as in [2].=94

I find it a little odd to reference the spec you=92re obsoleting in = this sentence, especially since BFCP over a reliable transport is = completely specified in this bis document. I would suggest dropping the = i.e. clause.

Good catch. This is a carry over from before this draft was adopted as a = bis version of rfc4582.


"The version field MUST be set to 2 when
   using BFCP over an unreliable transport with the = extensions specified
   in this document.=94

The bit about =93with the extensions specified in this document=94 = is extraneous and should be removed.

"If an endpoint receives a message with an
  =   unsupported version field value, the receiving server MUST = send an
  =   Error message with parameter value 12 (Unsupported = Version) to
  =   indicate this.=94

Use of the word =93server=94 here makes it sound as if only servers = could receive headers with unsupported versions. Should this be =93the = receiving endpoint=94?

=3D Section 6.2.4 =3D
"[23], Section 6.7 provides useful recommendations =85=94

The links in the references are not quite right.

=3D Section 8.3.2 =3D
s/when fires/when = fired/

=3D Section 14 =3D
s/high-jack/hijack/

=3D Section B.1 =3D
"situation where multiple = different and non-interoperable would co-
   exist in the market.=94

There is a word missing after =93non-interoperable."

This should read =93non-interoperable implementations=94. Earlier in = that same sentence, =93BFCP over UDP were already used=94 should read = =93BFCP over UDP is already being used=94.

Cheers,
Charles

= --Apple-Mail=_10252BE8-4DCC-44B6-AE9B-AB185B336BD6-- From nobody Thu Feb 19 05:54:37 2015 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147571A878A for ; Thu, 19 Feb 2015 05:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE5mtITUCF0Q for ; Thu, 19 Feb 2015 05:54:29 -0800 (PST) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA3D1A8774 for ; Thu, 19 Feb 2015 05:54:28 -0800 (PST) Received: by labgq15 with SMTP id gq15so7780218lab.6 for ; Thu, 19 Feb 2015 05:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qoMeSAhCAbeEVW4E9Xo9Jokj7R3F8qmwb2om2XA9BLk=; b=orCTytaKM+4bGV+CLOa1IFtJIhgcOIdgPgsenSZzhJdHBcTJvK5NkUGBeOHIciOP/j uF+jX4ym8m8qjB5Mf7n+sBqykfuHAVr5V6ObZxIkQI9NHXWhreeZuIdOUPn9lDvaOOYH PjHVqVSCuNCB1BS1v2wdepA656aImEMSbMZNcz7hIIuyzQsJtHnqmgiYMTYKqohTGvZM U62aOhowKjQf0UUJHCm6QzKOJdf9YjyyifCqPVubi2fCTXVUkj2V3C40oDNtxI2UQM6x gZ19Ik05op2NAA84hY+7NYP3F1kgPeVW+fLUA6yO9thpcSJ1fK41hjLmfTHA3y6cGSYR Qqiw== MIME-Version: 1.0 X-Received: by 10.152.88.49 with SMTP id bd17mr1900432lab.43.1424354066841; Thu, 19 Feb 2015 05:54:26 -0800 (PST) Received: by 10.25.88.198 with HTTP; Thu, 19 Feb 2015 05:54:26 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2015 14:54:26 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a11c355da30477d050f714623 Archived-At: Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 13:54:35 -0000 --001a11c355da30477d050f714623 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline. On 10 February 2015 at 00:58, Alissa Cooper wrote: > Hi Charles, > > Thanks, some responses inline. > > On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) > wrote: > > HI Alissa, > > Thank you for the review. Please see my thoughts on your comments and > questions inline. > > From: Alissa Cooper > Date: Thursday, January 29, 2015 at 10:19 PM > To: "bfcpbis@ietf.org" > Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 > > I have reviewed this draft in preparation for IETF LC. Overall the > document appears in good shape. I have a few questions and comments I=E2= =80=99d > like to discuss before issuing the IETF last call. I=E2=80=99ve also incl= uded some > editorial nits that should be addressed together with any last call > comments. > > Comments and questions: > > =3D Section 5.1 =3D > "If an endpoint receives a message with an > unsupported version field value, the receiving server MUST send an > Error message with parameter value 12 (Unsupported Version) to > indicate this.=E2=80=9D > > This seems a little misleading since RFC 4582 didn=E2=80=99t specify wha= t to do > upon receipt of a message with a version other than 1. Implementations th= at > do not get upgraded to be compliant with 4582bis (which could certainly > account for some of those that will not support version 2) will therefore > never send the error specified here. This seems like it should at least b= e > noted given the MUST-level requirement. The same applies in Section 13.7. > > > Good point. I believe we made this a MUST because we were thinking in > terms of implementations compliant with this bis version. Adding your > suggested note about rfc 4582 implementations here and in section 13.7 > seems useful to me. > > > Ok > Fine. Added text in 5.1 and 13.7 stating quite similarly this: Text: "If an endpoint receives a message with an unsupported version field value, and the extensions in this document is supported, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this. Note that endpoints supporting only the RFC 4582 subset will not support this parameter value." =3D Section 7 =3D > "BFCP entities MUST support, at a minimum, the > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=E2=80=9D > > I realize this requirement comes from RFC 4582, but I=E2=80=99d like to > understand why it has not been updated to be consistent with more current > guidance on cipher suite selection (e.g., > https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4). > > > How about we keep this minimum requirement, and add a reference > to draft-ietf-uta-tls-bcp along with a recommendation to adhere to the be= st > practices it outlines in section 4? > > > I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards > compatibility and SHOULD support the ones listed in the UTA drafts would = be > ok. > Hopefully, this is what new implementations will do. But of course, adding this as SHOULD requirements are just fine - even though the reference is an internet-draft and not an RFC yet. Text: "BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in , BFCP entities SHOULD support the followi= ng cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 " =3D Sections 8, 8.1, 8.2 =3D > It seems like the transaction ID requirements regarding > non-reuse/monotonically increasing IDs are re-stated multiple times acros= s > these three sections, in slightly different ways, to the point where it= =E2=80=99s > not clear exactly what they are. It seems like they are: > > (1) Reliable transport, server-initiated transaction: ID is 0 > (2) Unreliable transport, server-initiated transaction: ID MUST be > monotonically increasing (except for wrap-around) > (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0 > and MUST NOT be reused in another message from the client until a respons= e > from the server is received for the transaction, but need not be > monotonically increasing (e.g., a lower, recently used ID could be re-use= d > once a response is received) > (4) Unreliable transport, client-initiated transaction: ID MUST be > monotonically increasing (except for wrap-around) > > Is (3) the correct interpretation of the text in 8.1? If so, why not > just require IDs in all client-initiated transactions to be monotonically > increasing? > > > Agree we can and should simplify this. Sections 8.1 and 8.2 cover the > client behavior and server behavior in detail. As such, the transaction I= D > related information at the start of Section 8 is superfluous. I recommend > reducing the text in Section 8 to the follow: > > 8. Protocol Transactions > > In BFCP, there are two types of transactions: client-initiated > transactions and server-initiated transactions. > > Client-initiated transactions consist of a request from a client to a > floor control server and a response from the floor control server to > the client. > > Server-initiated transactions have different behavior depending on > underlying transport: > > When using a reliable transport, server-initiated transactions > consist of a single message from a floor control server to a > client (notifications). They do not trigger any response. > > When using an unreliable transport, server-initiated transactions > consist of a request from a floor control server to a client and a > response from the client to the floor control server. > > When using BFCP over an unreliable transport, retransmission timer T1 > (see Section 8.3) MUST be used for all requests until the transaction > is completed. > > Then in section 8.1, we add the important details removed from section 8= . > > 8.1.1 Client Behavior > > A client starting a client-initiated transaction MUST set the > Conference ID in the common header of the message to the Conference > ID for the conference that the client obtained previously. > > The client MUST set the Transaction ID value in the common header to > a number that is different from 0 and that MUST NOT be reused in > another message from the client until a response from the server is > received for the transaction. The client uses the Transaction ID > value to match this message with the response from the floor control > server. When using BFCP over an unreliable transport, it is important = to > choose a Transaction ID value that lets the receiver distinguish the > reception > of the next message in a sequence of BFCP messages from a > retransmission > of a previous message. Therefore, BFCP entities using an unreliable > transport MUST > use monotonically increasing Transaction ID values (except for wrap- > around). > > A client receiving a server-initiated transaction over an unreliable > transport > MUST copy the Transaction ID from the request received from the server > into the > response. > > > [Question: is there a need to copy the Conference ID and User ID, if > present?] > > Shouldn't be necessary for this message direction! 8.2. Server Behavior > > A floor control server sending a response within a client-initiated > transaction MUST copy the Conference ID, the Transaction ID, and the > User ID from the request received from the client into the response. > > Server-initiated transactions MUST contain a Transaction ID equal to > 0 when BFCP is used over a reliable transport. Over an unreliable > transport, the Transaction ID shall have the same properties as for > client-initiated transactions. The server uses the Transaction ID > value to > match this message with the response from the floor participant or > floor chair. > > > Thanks, this is better. > Charles' trimmed text adopted. The duplication of descriptions probably stems from our reshuffling and restructuring of text and later rounds of clarifications of text pieces. =3D Section 9 (impacts Section 14 as well) =3D > "BFCP clients SHOULD authenticate the floor control server before > sending any BFCP message to it or accepting any BFCP message from it. > Similarly, floor control servers SHOULD authenticate a client before > accepting any BFCP message from it or sending any BFCP message to it. > > BFCP supports TLS/DTLS mutual authentication between clients and > floor control servers, as specified in Section 9.1. This is the > RECOMMENDED authentication mechanism in BFCP.=E2=80=9D > > What are the cases where clients and servers do not need to be > authenticating each other? I know this requirement and the other > SHOULD-level requirements around use of TLS/DTLS are carried over from RF= C > 4582, but I=E2=80=99m concerned that they aren=E2=80=99t as strong as the= y should be. For a > conference where the signaling traffic is authenticated and confidentiali= ty > and integrity protected, why is it ok for the floor control traffic not t= o > be? Could these requirements be adjusted to require use of TLS/DTLS at > least in cases where the signaling is also protected? > > > Yes, but again, this would be at the expense of adding a non backward > compatible change from rfc 4582. How about saying TLS/DTLS MUST be used f= or > BFCP in such cases, while pointing out the rfc 4582 based implementations > may not comply (similar to what we did with the version field). > > > Works for me. > Text in Section 9: "BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, and the extensions in this document is supported, the BFCP clients MUST authenticate the floor control server and the floor control servers MUST authenticate a client before communicating as described above. Note that endpoints supporting only the RFC 4582 subset may not comply with this mandatory authentication requirement. Text first in Section 14: "BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to always be used and in cases where signaling/control traffic is properly protected, as described in it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms as long as they provide similar security properties." Text last in Section 14: "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/DTLS confidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm according to ." Feel free to make all of these changes and submit a rev and I=E2=80=99ll is= sue the > IETF LC. > > Thanks, > Alissa > > > > =3D Section 14 =3D > See the point above about ciphersuites. =E2=80=9CNon-null encryption=E2= =80=9D is not a > sufficient minimum baseline, and if the requirements change in Section 7 > they should be reflected here as well. > > > Yep. > > Section 14 polished a bit, as indicated above. > Editorial nits to be resolved with LC comments: > > =3D Section 5.1 =3D > =E2=80=9CThe version field MUST be set to 1 when using BFCP over a reliab= le > transport, i.e. as in [2].=E2=80=9D > > I find it a little odd to reference the spec you=E2=80=99re obsoleting i= n this > sentence, especially since BFCP over a reliable transport is completely > specified in this bis document. I would suggest dropping the i.e. clause. > > > Good catch. This is a carry over from before this draft was adopted as a > bis version of rfc4582. > > Fixed. "The version field MUST be set to 2 when > using BFCP over an unreliable transport with the extensions specified > in this document.=E2=80=9D > > The bit about =E2=80=9Cwith the extensions specified in this document=E2= =80=9D is > extraneous and should be removed. > > Done "If an endpoint receives a message with an > unsupported version field value, the receiving server MUST send an > Error message with parameter value 12 (Unsupported Version) to > indicate this.=E2=80=9D > > Use of the word =E2=80=9Cserver=E2=80=9D here makes it sound as if only = servers could > receive headers with unsupported versions. Should this be =E2=80=9Cthe re= ceiving > endpoint=E2=80=9D? > > Well, only floor control servers may issue an Error message so this is fixed by stating that. "If a floor control server receives...". =3D Section 6.2.4 =3D > "[23], Section 6.7 provides useful recommendations =E2=80=A6=E2=80=9D > > The links in the references are not quite right. > > No way to fix with my current version of xml2rfc! > =3D Section 8.3.2 =3D > s/when fires/when fired/ > > Fixed. =3D Section 14 =3D > s/high-jack/hijack/ > > Fixed. =3D Section B.1 =3D > "situation where multiple different and non-interoperable would co- > exist in the market.=E2=80=9D > > There is a word missing after =E2=80=9Cnon-interoperable." > > > This should read =E2=80=9Cnon-interoperable implementations=E2=80=9D. Ea= rlier in that > same sentence, =E2=80=9CBFCP over UDP were already used=E2=80=9D should r= ead =E2=80=9CBFCP over UDP > is already being used=E2=80=9D. > > Both fixed. Will submit the new version ASAP if no reactions are triggered here! -- Tom --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a11c355da30477d050f714623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline.

On 10 February 2015 at 00:58, Alissa Cooper &l= t;alissa@cooperw.in<= /a>> wrote:
Hi Charles,

Thanks, some responses inline.=


HI Alissa,

Thank you for the review. Please see my thoughts on your comments and quest= ions inline.

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, January 29, 2015 at= 10:19 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD evaluation: d= raft-ietf-bfcpbis-rfc4582bis-12

I have reviewed this draft in preparation for IETF LC. Overall the doc= ument appears in good shape. I have a few questions and comments I=E2=80=99= d like to discuss before issuing the IETF last call. I=E2=80=99ve also incl= uded some editorial nits that should be addressed together with any last call comments.

Comments and questions:

=3D Section 5.1 =3D
"If an endpoint receives a message with an
=C2=A0 =C2=A0=C2=A0 unsupp= orted version field value, the receiving server MUST send an
=C2=A0 =C2=A0=C2=A0 Error = message with parameter value 12 (Unsupported Version) to
=C2=A0 =C2=A0=C2=A0 indica= te this.=E2=80=9D

This seems a little misleading since RFC 4582 didn=E2=80=99t specify w= hat to do upon receipt of a message with a version other than 1. Implementa= tions that do not get upgraded to be compliant with 4582bis (which could ce= rtainly account for some of those that will not support version 2) will therefore never send the error specified here.= This seems like it should at least be noted given the MUST-level requireme= nt. The same applies in Section 13.7.

Good point. I believe we made this a MUST because we were thinking in terms= of implementations compliant with this bis version. Adding your suggested = note about rfc 4582 implementations here and in section 13.7 seems useful t= o me.

Ok

Fine. Added text in 5.1 and = 13.7 stating quite similarly this:

Tex= t:
"If an endpoint receives a message with an unsuppor= ted version field value, and the extensions in this document is supported, = the receiving server MUST send an Error message with parameter value 12 (Un= supported Version) to indicate this. Note that endpoints supporting only th= e RFC 4582 subset will not support this parameter value."

=3D Section 7 =3D
"BFCP entities MUST support, at a minimum, the
=C2=A0 =C2=A0TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=E2=80=9D

I realize this requirement comes from RFC 4582, but I=E2=80=99d like t= o understand why it has not been updated to be consistent with more current= guidance on cipher suite selection (e.g.,=C2=A0https://= tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).

How about we keep this minimum requirement, and add a reference to=C2=A0dra= ft-ietf-uta-tls-bcp along with a recommendation to adhere to the best pract= ices it outlines in section 4?

I think MUST support=C2=A0TLS_RSA_WITH_AES_128_CBC_SHA for backwards= compatibility and SHOULD support the ones listed in the UTA drafts would b= e ok.

Hopefully, th= is is what new implementations will do. But of course, adding this as SHOUL= D requirements are just fine - even though the reference is an internet-dra= ft and not an RFC yet.=C2=A0

Text:
"<t>BFCP entities MUST support, at a minimum, the TL= S_RSA_WITH_AES_128_CBC_SHA ciphersuite <xref target=3D"RFC5246"= ;/> for backwards compatibility with existing implementations of RFC 458= 2. In accordance with the recommendations and guidelines in <xref target= =3D"I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the = following cipher suites:</t>
=C2=A0 =C2=A0 <t><lis= t style=3D"symbols">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t>
=C2=A0 =C2=A0= =C2=A0 =C2=A0 <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_DHE_RSA_WITH_AES_256_GCM_SH= A384</t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_ECDHE_RSA= _WITH_AES_256_GCM_SHA384</t>
=C2=A0 =C2=A0 </list><= ;/t>"

=3D Sections 8, 8.1, 8.2 =3D
It seems like the transaction ID requirements regarding non-reuse/mono= tonically increasing IDs are re-stated multiple times across these three se= ctions, in slightly different ways, to the point where it=E2=80=99s not cle= ar exactly what they are. It seems like they are:

(1) Reliable transport, server-initiated transaction: ID is 0
(2) Unreliable transport, server-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)
(3) Reliable transport, client-initiated transaction: ID MUST NOT be 0= and MUST NOT be reused in another message from the client until a response= from the server is received for the transaction, but need not be monotonic= ally increasing (e.g., a lower, recently used ID could be re-used once a response is received)
(4) Unreliable transport, client-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)

Is (3) the correct interpretation of the text in 8.1? If so, why not j= ust require IDs in all client-initiated transactions to be monotonically in= creasing?

Agree we can and should simplify this. Sections 8.1 and 8.2 cover the clien= t behavior and server behavior in detail. As such, the transaction ID relat= ed information at the start of Section 8 is superfluous. I recommend reduci= ng the text in Section 8 to the follow:

8. Protocol Transactions

=C2=A0 =C2=A0In BFCP, there are two = types of transactions: client-initiated
=C2=A0 =C2=A0transactions and server= -initiated transactions.

=C2=A0 =C2=A0Client-initiated transa= ctions consist of a request from a client to a
=C2=A0 =C2=A0floor control server an= d a response from the floor control server to
=C2=A0 =C2=A0the client.

=C2=A0 =C2=A0Server-initiated transa= ctions have different=C2=A0behavior depending on=C2=A0
=C2=A0 =C2=A0underlying= transport:

=C2=A0 =C2=A0 =C2=A0 When using a re= liable transport, server-initiated transactions
=C2=A0 =C2=A0 =C2=A0 consist of a si= ngle message from a floor control server to a
=C2=A0 =C2=A0 =C2=A0 client (notific= ations).=C2=A0 They do not trigger any response.

=C2=A0 =C2=A0 =C2=A0 When using an u= nreliable transport, server-initiated transactions
=C2=A0 =C2=A0 =C2=A0 consist of a re= quest from a floor control server to a client and a
=C2=A0 =C2=A0 =C2=A0 response from t= he client to the floor control server.

=C2=A0 =C2=A0When using BFCP over an= unreliable transport, retransmission timer T1
=C2=A0 =C2=A0(see Section 8.3) MUST = be used for all requests until the transaction
=C2=A0 =C2=A0is completed.

Then in section 8.1, we add the impo= rtant details removed from section 8.

8.1.1 Client Behavior

=C2=A0 =C2=A0A client starting a client-initiated transaction MUST set= the
=C2=A0 =C2=A0Conference ID in the common header of the message to the = Conference
=C2=A0 =C2=A0ID for the conference that the client obtained previously= .=C2=A0

=C2=A0 =C2=A0The client MUST set the Transaction ID value in the commo= n header to
=C2=A0 =C2=A0a number that is different from 0 and that MUST NOT be re= used in
=C2=A0 =C2=A0another message from the client until a response from the= server is
=C2=A0 =C2=A0received for the transaction.=C2=A0 The client uses the T= ransaction ID
=C2=A0 =C2=A0value to match this message with the response from the fl= oor control
=C2=A0 =C2=A0server. When using BFCP over an unreliable transport, it = is important to
=C2=A0 =C2=A0choose a Transaction ID value that lets the receiver dist= inguish the reception=C2=A0
=C2=A0 =C2=A0of the next message in a sequence of BFCP messages from a= retransmission=C2=A0
=C2=A0 =C2=A0of a previous message.=C2=A0 Therefore, BFCP entities usi= ng an unreliable transport MUST
=C2=A0 =C2=A0use monotonically incre= asing Transaction ID values (except for wrap-around).

=C2=A0 =C2=A0A client receivi= ng a server-initiated transaction over an unreliable transport
=C2=A0 =C2=A0MUST copy the Tr= ansaction ID from the request received from the server into the
=C2=A0 =C2=A0response.=C2=A0<= /div>
=C2=A0
=C2=A0 =C2=A0[Question: is th= ere a need to copy the Conference ID and User ID, if present?]
<= /div>
Sho= uldn't be necessary for this message direction!=C2=A0
<= br>
8.2. Server Behavior

=C2=A0 =C2=A0A floor control server = sending a response within a client-initiated
=C2=A0 =C2=A0transaction MUST copy t= he Conference ID, the Transaction ID, and the
=C2=A0 =C2=A0User ID from the reques= t received from the client into the response.

=C2=A0 =C2=A0Server-initiated transa= ctions MUST contain a Transaction ID equal to
=C2=A0 =C2=A00 when BFCP is used ove= r a reliable transport.=C2=A0 Over an unreliable
=C2=A0 =C2=A0transport, the Transact= ion ID shall have the same properties as for
=C2=A0 =C2=A0client-initiated transa= ctions.=C2=A0The serv= er uses the Transaction ID value to
=C2=A0 =C2=A0match this message with= the response from the floor participant or
=C2=A0 =C2=A0floor chair.


Thanks, this i= s better.

Charles&#= 39; trimmed text adopted. The duplication of descriptions probably stems fr= om our reshuffling and restructuring of text and later rounds of clarificat= ions of text pieces.=C2=A0

=3D Section 9 (impacts Section 14 as well) =3D
"BFCP clients SHOULD authenticate the floor control server before=
=C2=A0 =C2=A0sending any BFCP message to it or accepting any BFCP mess= age from it.
=C2=A0 =C2=A0Similarly, floor control servers SHOULD authenticate a cl= ient before
=C2=A0 =C2=A0accepting any BFCP message from it or sending any BFCP me= ssage to it.

=C2=A0 =C2=A0BFCP supports TLS/DTLS mutual authentication between clie= nts and
=C2=A0 =C2=A0floor control servers, as specified in Section 9.1.=C2=A0= This is the
=C2=A0 =C2=A0RECOMMENDED authentication mechanism in BFCP.=E2=80=9D

What are the cases where clients and servers do not need to be authent= icating each other? I know this requirement and the other SHOULD-level requ= irements around use of TLS/DTLS are carried over from RFC 4582, but I=E2=80= =99m concerned that they aren=E2=80=99t as strong as they should be. For a conference where the signaling traffic is authent= icated and confidentiality and integrity protected, why is it ok for the fl= oor control traffic not to be? Could these requirements be adjusted to requ= ire use of TLS/DTLS at least in cases where the signaling is also protected?

Yes, but again, this would be at the expense of adding a non backward compa= tible change from rfc 4582. How about saying TLS/DTLS MUST be used for BFCP= in such cases, while pointing out the rfc 4582 based implementations may n= ot comply (similar to what we did with the version field).

Works for me.

Text in S= ection 9:
"<t>BFCP clients SHOULD authenticat= e the floor control server before sending any BFCP message to it or accepti= ng any BFCP message from it. Similarly, floor control servers SHOULD authen= ticate a client before accepting any BFCP message from it or sending any BF= CP message to it.</t>
=C2=A0 =C2=A0 <t>If the signali= ng or control protocol traffic used to set up the conference is authenticat= ed and confidentiality and integrity protected, and the extensions in this = document is supported, the BFCP clients MUST authenticate the floor control= server and the floor control servers MUST authenticate a client before com= municating as described above. Note that endpoints supporting only the RFC = 4582 subset may not comply with this mandatory authentication requirement.&= lt;/t>

Text first in Section 14:
"<t>BFCP uses TLS/DTLS to provide mutual authentication betwee= n clients and servers. TLS/DTLS also provides replay and integrity protecti= on and confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption = algorithm according to <xref target=3D"sec:lower-security"/>= ; always be used and in cases where signaling/control traffic is properly p= rotected, as described in <xref target=3D"sec:auth"/> it is= REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use oth= er security mechanisms as long as they provide similar security properties.= </t>"
=C2=A0
Text last in Section 14:<= /div>
"<t>Attackers may attempt to pick messages from = the network to get access to confidential information between the floor con= trol server and a client (e.g., why a floor request was denied). TLS/DTLS c= onfidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTL= S be used with an encryption algorithm according to <a href=3D"sec:= lower-security"/>.</t>"

<= br>
Feel free to make all of these changes and submit a rev and I=E2=80= =99ll issue the IETF LC.

Thanks,
Alissa<= /div>



=3D Section 14 =3D
See the point above about ciphersuites. =E2=80=9CNon-null encryption= =E2=80=9D is not a sufficient minimum baseline, and if the requirements cha= nge in Section 7 they should be reflected here as well.

Yep.
Section 14 polished a bit, as indicated above.
=C2=A0
Editorial nits to be resolved with LC comments:

=3D Section 5.1 =3D
=E2=80=9CThe version field MUST be set to 1 when using BFCP over a rel= iable
=C2=A0 =C2=A0transport, i.e. as in [2].=E2=80=9D

I find it a little odd to reference the spec you=E2=80=99re obsoleting= in this sentence, especially since BFCP over a reliable transport is compl= etely specified in this bis document. I would suggest dropping the i.e. cla= use.

Good catch. This is a carry over from before this draft was adopted as a bi= s version of rfc4582.
Fixed.=C2=A0

=
"The version field MUST be set to 2 when
=C2=A0 =C2=A0using BFCP over an unreliable transport with the extensio= ns specified
=C2=A0 =C2=A0in this document.=E2=80=9D

The bit about =E2=80=9Cwith the extensions specified in this document= =E2=80=9D is extraneous and should be removed.
Done=C2=A0

"If an endpoint receives a message with an
=C2=A0 =C2=A0 unsupported = version field value, the receiving server MUST send an
=C2=A0 =C2=A0 Error messag= e with parameter value 12 (Unsupported Version) to
=C2=A0 =C2=A0 indicate thi= s.=E2=80=9D

Use of the word =E2=80=9Cserver=E2=80=9D here makes it sound as if onl= y servers could receive headers with unsupported versions. Should this be = =E2=80=9Cthe receiving endpoint=E2=80=9D?
Well= , only floor control servers may issue an Error message so this is fixed by= stating that. "If a floor control server receives...".

=
=3D Section 6.2.4 =3D
"[23], Section 6.7 provides useful recommendations =E2=80=A6=E2= =80=9D

The links in the references are not quite right.
No way to fix with my current version of xml2rfc!
=3D Section 8.3.2 =3D
s/when fires/when fired/
Fixed.=C2=A0

=3D Section 14 =3D
s/high-jack/hijack/
Fixed.=C2=A0

=3D Section B.1 =3D
"situation where multiple di= fferent and non-interoperable would co-
=C2=A0 =C2=A0exist in the market.=E2=80=9D

There is a word missing after =E2=80=9Cnon-interoperable."

This should read =E2=80=9Cnon-interoperable implementations=E2=80=9D. Earli= er in that same sentence, =E2=80=9CBFCP over UDP were already used=E2=80=9D= should read =E2=80=9CBFCP over UDP is already being used=E2=80=9D.
Both fixed= .=C2=A0


Will submit the new v= ersion ASAP if no reactions are triggered here!

<= div style>-- Tom=C2=A0



= --
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/= telepresence/
## tomkrist@cisco.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/
--001a11c355da30477d050f714623-- From nobody Thu Feb 19 06:13:48 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC9B1A878A; Thu, 19 Feb 2015 06:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSwQVmTFx_-o; Thu, 19 Feb 2015 06:13:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D4E1A1A9A; Thu, 19 Feb 2015 06:13:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219141345.1338.29144.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:13:45 -0800 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:13:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Authors : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-13.txt Pages : 90 Date : 2015-02-19 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 06:13:57 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552DB1A878A; Thu, 19 Feb 2015 06:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg7X1yBu-mPh; Thu, 19 Feb 2015 06:13:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EAE1A874E; Thu, 19 Feb 2015 06:13:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219141345.1338.85499.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:13:45 -0800 Archived-At: Subject: [bfcpbis] New Version Notification - draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:13:49 -0000 A new version (-13) has been submitted for draft-ietf-bfcpbis-rfc4582bis: http://www.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4582bis-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Feb 19 06:13:59 2015 Return-Path: X-Original-To: expand-draft-ietf-bfcpbis-rfc4582bis.all@virtual.ietf.org Delivered-To: bfcpbis@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7068B1A87AD; Thu, 19 Feb 2015 06:13:49 -0800 (PST) X-Original-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-bfcpbis-rfc4582bis.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552DB1A878A; Thu, 19 Feb 2015 06:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg7X1yBu-mPh; Thu, 19 Feb 2015 06:13:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EAE1A874E; Thu, 19 Feb 2015 06:13:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219141345.1338.85499.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:13:45 -0800 Archived-At: Subject: [bfcpbis] New Version Notification - draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:13:49 -0000 A new version (-13) has been submitted for draft-ietf-bfcpbis-rfc4582bis: http://www.ietf.org/internet-drafts/draft-ietf-bfcpbis-rfc4582bis-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Feb 19 06:21:39 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7301A8795 for ; Thu, 19 Feb 2015 06:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cisi2HLHCliT for ; Thu, 19 Feb 2015 06:21:36 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20911A8784 for ; Thu, 19 Feb 2015 06:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1782; q=dns/txt; s=iport; t=1424355696; x=1425565296; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bAN5W9TS9+5X2wEvJ0b6kYXyxLPfelN5V/bM9Ta6Pi8=; b=ROS04GP1vcxdqcpktv9HNuuPBrg0z5qnvvd/sbgn0d7r0VPkgoJVPbf+ SHJx8hgeEbwg5q2sfgnWKhs/6e6J1aIOwjpYSq8ZHuX3dV5vh1aBGm7uE Eiry42zteEvYoAfxU0vAwp+B2DJesWNKd0TLmkZ5rnvW12LJ18IqjbuNk 8=; X-IronPort-AV: E=Sophos;i="5.09,608,1418083200"; d="scan'208";a="354772746" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 19 Feb 2015 14:21:34 +0000 Received: from [10.54.90.39] (dhcp-10-54-90-39.cisco.com [10.54.90.39]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1JELX6h005763; Thu, 19 Feb 2015 14:21:33 GMT Message-ID: <54E5F16D.4030607@cisco.com> Date: Thu, 19 Feb 2015 15:21:33 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" , Alissa Cooper , "BFCPbis WG" References: <20150219141345.1338.29144.idtracker@ietfa.amsl.com> In-Reply-To: <20150219141345.1338.29144.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-13.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:21:38 -0000 On 02/19/2015 03:13 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. > > Title : The Binary Floor Control Protocol (BFCP) > Authors : Gonzalo Camarillo > Keith Drage > Tom Kristensen > Joerg Ott > Charles Eckel > Filename : draft-ietf-bfcpbis-rfc4582bis-13.txt > Pages : 90 > Date : 2015-02-19 > > Abstract: > Floor control is a means to manage joint or exclusive access to > shared resources in a (multiparty) conferencing environment. > Thereby, floor control complements other functions -- such as > conference and media session setup, conference policy manipulation, > and media control -- that are realized by other protocols. > > This document specifies the Binary Floor Control Protocol (BFCP). > BFCP is used between floor participants and floor control servers, > and between floor chairs (i.e., moderators) and floor control > servers. > > This document obsoletes RFC 4582. Changes from RFC 4582 are > summarized in Section 16. > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-13 > Changes after AD review and discussion on the list, refer to that mail thread for details. Thanks to Alissa and Charles for both review and input. Hopefully, this draft is ready for LC. Fixes for the SDP companion rfc4583bis is upcoming, expected submission tomorrow. -- Tom From nobody Thu Feb 19 09:42:19 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3A61A0636; Thu, 19 Feb 2015 09:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc2LYlypt1OL; Thu, 19 Feb 2015 09:42:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AD1A1AC6; Thu, 19 Feb 2015 09:42:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150219174215.4401.42562.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 09:42:15 -0800 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] Last Call: (The Binary Floor Control Protocol (BFCP)) to Proposed Standard X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:42:16 -0000 The IESG has received a request from the Binary Floor Control Protocol Bis WG (bfcpbis) to consider the following document: - 'The Binary Floor Control Protocol (BFCP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Feb 20 04:32:59 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF19D1A86E4 for ; Fri, 20 Feb 2015 04:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBBt0QF92OzZ for ; Fri, 20 Feb 2015 04:32:57 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055E81A6FE6 for ; Fri, 20 Feb 2015 04:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=980; q=dns/txt; s=iport; t=1424435577; x=1425645177; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=b/ZvlvAZUF5G8sb7wq9iMFyL8xR6+6NpsnAeE2BIxWI=; b=Ib53gi9Gkc0VsnRFqph2lvK6QZNF59kHlGEHa1aRStxhID5nY+01dE/S InmazMCdhj3nAb8NsjRAf/Gx05uGn8lqhx89FWoldml3BlqyGIlpqABql keQb8x+aXt8RXYL9t7hnjMGBlHk6eJS91fc9BAeW/UUN0grCUd7lCKPFL 4=; X-IronPort-AV: E=Sophos;i="5.09,614,1418083200"; d="scan'208";a="354914488" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 20 Feb 2015 12:32:55 +0000 Received: from [10.54.90.39] (dhcp-10-54-90-39.cisco.com [10.54.90.39]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1KCWtID005967; Fri, 20 Feb 2015 12:32:55 GMT Message-ID: <54E72975.4020505@cisco.com> Date: Fri, 20 Feb 2015 13:32:53 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Christer Holmberg , "Charles Eckel (eckelcu)" References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D58BE5C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58BE5C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "bfcpbis@ietf.org" , 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:32:59 -0000 A new version of the draft is submitted. Just to summarize the changes that stems from this mail thread: Q1: Existing definitions kept. Q2: Separate sections/subsections for the SDP attributes. Q3: A separate offer/answer section, as a guidance to the implementers, is added. Very very much based on Christer's good input here. Q3b: Existing text kept. If you choose not to add a 'floorctrl' attribute, well, feel the pain... And mandatory curses in the section above should be sufficient. Q4: Added a separate subsection to summarize DTLS role signalling and offer/answer. Again, very very much based on Christer's input. (In parentheses, I don't really see that this portion of text is really needed. But might provide guidance to implementers). Q5: BUNDLE is still a draft, so I propose we leave it to the ones that will eventually need BFCP in a BUNDLE group to specify what is needed of BUNDLE specifics, mux-details and so on. -- Tom From nobody Fri Feb 20 04:35:11 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD42E1A88B9; Fri, 20 Feb 2015 04:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaeViLhvGOHL; Fri, 20 Feb 2015 04:35:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4317C1A1A2E; Fri, 20 Feb 2015 04:35:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220123508.6381.71711.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 04:35:08 -0800 Archived-At: Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-11.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:35:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams Authors : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-11.txt Pages : 21 Date : 2015-02-20 Abstract: This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 20 04:44:07 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029CF1A8785 for ; Fri, 20 Feb 2015 04:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7_C26nADZwj for ; Fri, 20 Feb 2015 04:44:03 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134F41A702D for ; Fri, 20 Feb 2015 04:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1468; q=dns/txt; s=iport; t=1424436243; x=1425645843; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NeHHN2nOWbR3ohsMTryV+hORgv1it3vUN3GblOGBWWg=; b=ief9kfMFlhF/UHKHtUpp7ZPMFxtyCgr5bV140WB9xgPgyIjmqP5kUZoR 5S7+43NqDFCywxGk8tsnePugBzlvfoVR/dM2OLkbuepcNyCqNktmuMJRb +t0YQT73IzR+7pFWMZVtRITO6w8NmkJq1Ou8sKOD2KZZO/QHIPJ/lmFaV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DuBAAqK+dU/xbLJq1bg1hVBcJ0hXECgVoBAQEBAQF8hBABAQQ4PAQBEAsYCRYPCQMCAQIBRRMBBQIBAQWIJggF03wBAQEBAQEBAwEBAQEBHYsPhB0BAU8HFoQUAQSZD4EZgxOCLoxRIoNvPTGBBAcXBoEbAQEB X-IronPort-AV: E=Sophos;i="5.09,614,1418083200"; d="scan'208";a="350836092" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 20 Feb 2015 12:44:01 +0000 Received: from [10.54.90.39] (dhcp-10-54-90-39.cisco.com [10.54.90.39]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1KCi1Ju025646; Fri, 20 Feb 2015 12:44:01 GMT Message-ID: <54E72C10.6010204@cisco.com> Date: Fri, 20 Feb 2015 13:44:00 +0100 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: bfcpbis@ietf.org References: <20150220123508.6381.71711.idtracker@ietfa.amsl.com> In-Reply-To: <20150220123508.6381.71711.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Tom Kristensen' <2mkristensen@gmail.com> Subject: Re: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-11.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 12:44:06 -0000 On 02/20/2015 01:35 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. > > Title : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams > Authors : Gonzalo Camarillo > Tom Kristensen > Filename : draft-ietf-bfcpbis-rfc4583bis-11.txt > Pages : 21 > Date : 2015-02-20 > > Abstract: > This document specifies how to describe Binary Floor Control Protocol > (BFCP) streams in Session Description Protocol (SDP) descriptions. > User agents using the offer/answer model to establish BFCP streams > use this format in their offers and answers. > > This document obsoletes RFC 4583. Changes from RFC 4583 are > summarized in Section 14. > Changes: - A small dash of polish - ABNF fixes to please the BNF validator - Changes according to separate mail thread, i.e. Christer Holmbergs issues (Q1 - Q5). Please have a look at the changes, review and comment if anything is unclear or even wrong: > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-11 > If not, this should be ready for the next stages where rfc4582bis is now headed. -- Tom From nobody Fri Feb 20 15:45:47 2015 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4551A0379 for ; Fri, 20 Feb 2015 15:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWTXYnbTHwTK for ; Fri, 20 Feb 2015 15:45:41 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4FC1A01EA for ; Fri, 20 Feb 2015 15:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51981; q=dns/txt; s=iport; t=1424475941; x=1425685541; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SPLF7+W+dYMMgbMZy2+bxgUCukVUpTIS8PNKEShgCZE=; b=MBVCfi0Di5ekJ3MwrPt3C5ZiY/MTAfANhioGQcDkDJ7KW2Au79QW3qoX mqN/pg3IV+MG7a7hmVHwCbRhW2+ZG6DuSZDQubx4wSs933BOWpTncw01r b6K0xlx3DzsGmdQTvt6FL7tHnqOgILwULdL5eujcCeLPs5EU/PZIjdGFe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DKBgBBxudU/49dJa1bgkNDUl7BGoFuhXECgRlDAQEBAQEBfIQPAQEBBBo7EgEREAIBCA4DAwECFgEKAQYHIREUCQgCBAENBYgbAxENzjkNhSwBAQEBAQEBAwEBAQEBAQEBAQEBF4oRfoJEgWgxDQQHBgMBCAyEDQWNThCBcYNdgVeCSIFGgRs4gl2CT0uFYAOCRoM+IoICHIFQb4EEBxcifwEBAQ X-IronPort-AV: E=Sophos;i="5.09,617,1418083200"; d="scan'208,217";a="125568504" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP; 20 Feb 2015 23:45:40 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1KNjdCv002627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Feb 2015 23:45:39 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Fri, 20 Feb 2015 17:45:39 -0600 From: "Charles Eckel (eckelcu)" To: Tom Kristensen <2mkristensen@gmail.com>, Alissa Cooper Thread-Topic: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 Thread-Index: AQHQPAleDovxcQJAY0eo+YwSl+sRq5zgum0AgAi6ygCADw5wAIABsWQA Date: Fri, 20 Feb 2015 23:45:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.22.81] Content-Type: multipart/alternative; boundary="_000_D10D05913E07Eeckelcuciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 23:45:46 -0000 --_000_D10D05913E07Eeckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All look great Tom, except for a couple nits (inline) that would be good to= fix if/when we have another version of the document. From: Tom Kristensen <2mkristensen@gmail.com= > Date: Thursday, February 19, 2015 at 5:54 AM To: Alissa Cooper > Cc: Charles Eckel >, "bfcpbis@i= etf.org" > Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 Inline. On 10 February 2015 at 00:58, Alissa Cooper > wrote: Hi Charles, Thanks, some responses inline. On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) > wrote: HI Alissa, Thank you for the review. Please see my thoughts on your comments and quest= ions inline. From: Alissa Cooper > Date: Thursday, January 29, 2015 at 10:19 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 I have reviewed this draft in preparation for IETF LC. Overall the document= appears in good shape. I have a few questions and comments I=92d like to d= iscuss before issuing the IETF last call. I=92ve also included some editori= al nits that should be addressed together with any last call comments. Comments and questions: =3D Section 5.1 =3D "If an endpoint receives a message with an unsupported version field value, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this.=94 This seems a little misleading since RFC 4582 didn=92t specify what to do u= pon receipt of a message with a version other than 1. Implementations that = do not get upgraded to be compliant with 4582bis (which could certainly acc= ount for some of those that will not support version 2) will therefore neve= r send the error specified here. This seems like it should at least be note= d given the MUST-level requirement. The same applies in Section 13.7. Good point. I believe we made this a MUST because we were thinking in terms= of implementations compliant with this bis version. Adding your suggested = note about rfc 4582 implementations here and in section 13.7 seems useful t= o me. Ok Fine. Added text in 5.1 and 13.7 stating quite similarly this: Text: "If an endpoint receives a message with an unsupported version field value,= and the extensions in this document is supported, the receiving server MUS= T send an Error message with parameter value 12 (Unsupported Version) to in= dicate this. Note that endpoints supporting only the RFC 4582 subset will n= ot support this parameter value." =3D Section 7 =3D "BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94 I realize this requirement comes from RFC 4582, but I=92d like to understan= d why it has not been updated to be consistent with more current guidance o= n cipher suite selection (e.g., https://tools.ietf.org/html/draft-ietf-uta-= tls-bcp-08#section-4). How about we keep this minimum requirement, and add a reference to draft-ie= tf-uta-tls-bcp along with a recommendation to adhere to the best practices = it outlines in section 4? I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards compatibili= ty and SHOULD support the ones listed in the UTA drafts would be ok. Hopefully, this is what new implementations will do. But of course, adding = this as SHOULD requirements are just fine - even though the reference is an= internet-draft and not an RFC yet. Text: "BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_= SHA ciphersuite for backwards compatibility with= existing implementations of RFC 4582. In accordance with the recommendatio= ns and guidelines in , BFCP entities= SHOULD support the following cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 " =3D Sections 8, 8.1, 8.2 =3D It seems like the transaction ID requirements regarding non-reuse/monotonic= ally increasing IDs are re-stated multiple times across these three section= s, in slightly different ways, to the point where it=92s not clear exactly = what they are. It seems like they are: (1) Reliable transport, server-initiated transaction: ID is 0 (2) Unreliable transport, server-initiated transaction: ID MUST be monotoni= cally increasing (except for wrap-around) (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0 and = MUST NOT be reused in another message from the client until a response from= the server is received for the transaction, but need not be monotonically = increasing (e.g., a lower, recently used ID could be re-used once a respons= e is received) (4) Unreliable transport, client-initiated transaction: ID MUST be monotoni= cally increasing (except for wrap-around) Is (3) the correct interpretation of the text in 8.1? If so, why not just r= equire IDs in all client-initiated transactions to be monotonically increas= ing? Agree we can and should simplify this. Sections 8.1 and 8.2 cover the clien= t behavior and server behavior in detail. As such, the transaction ID relat= ed information at the start of Section 8 is superfluous. I recommend reduci= ng the text in Section 8 to the follow: 8. Protocol Transactions In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions. Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client. Server-initiated transactions have different behavior depending on underlying transport: When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger any response. When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor control server. When using BFCP over an unreliable transport, retransmission timer T1 (see Section 8.3) MUST be used for all requests until the transaction is completed. Then in section 8.1, we add the important details removed from section 8. 8.1.1 Client Behavior A client starting a client-initiated transaction MUST set the Conference ID in the common header of the message to the Conference ID for the conference that the client obtained previously. The client MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is important to choose a Transaction ID value that lets the receiver distinguish the rec= eption of the next message in a sequence of BFCP messages from a retransmission of a previous message. Therefore, BFCP entities using an unreliable tra= nsport MUST use monotonically increasing Transaction ID values (except for wrap-arou= nd). A client receiving a server-initiated transaction over an unreliable tra= nsport MUST copy the Transaction ID from the request received from the server i= nto the response. [Question: is there a need to copy the Conference ID and User ID, if pre= sent?] Shouldn't be necessary for this message direction! 8.2. Server Behavior A floor control server sending a response within a client-initiated transaction MUST copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response. Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions. The server uses the Transaction ID value = to match this message with the response from the floor participant or floor chair. Thanks, this is better. Charles' trimmed text adopted. The duplication of descriptions probably ste= ms from our reshuffling and restructuring of text and later rounds of clari= fications of text pieces. =3D Section 9 (impacts Section 14 as well) =3D "BFCP clients SHOULD authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control servers SHOULD authenticate a client before accepting any BFCP message from it or sending any BFCP message to it. BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in Section 9.1. This is the RECOMMENDED authentication mechanism in BFCP.=94 What are the cases where clients and servers do not need to be authenticati= ng each other? I know this requirement and the other SHOULD-level requireme= nts around use of TLS/DTLS are carried over from RFC 4582, but I=92m concer= ned that they aren=92t as strong as they should be. For a conference where = the signaling traffic is authenticated and confidentiality and integrity pr= otected, why is it ok for the floor control traffic not to be? Could these = requirements be adjusted to require use of TLS/DTLS at least in cases where= the signaling is also protected? Yes, but again, this would be at the expense of adding a non backward compa= tible change from rfc 4582. How about saying TLS/DTLS MUST be used for BFCP= in such cases, while pointing out the rfc 4582 based implementations may n= ot comply (similar to what we did with the version field). Works for me. Text in Section 9: "BFCP clients SHOULD authenticate the floor control server before sendin= g any BFCP message to it or accepting any BFCP message from it. Similarly, = floor control servers SHOULD authenticate a client before accepting any BFC= P message from it or sending any BFCP message to it. If the signaling or control protocol traffic used to set up the conf= erence is authenticated and confidentiality and integrity protected, and th= e extensions in this document is supported, the BFCP clients MUST authentic= ate the floor control s/is supported/are supported server and the floor control servers MUST authenticate a client before comm= unicating as described above. Note that s/a client/the client endpoints supporting only the RFC 4582 subset may not comply with this mand= atory authentication requirement. Text first in Section 14: "BFCP uses TLS/DTLS to provide mutual authentication between clients and= servers. TLS/DTLS also provides replay and integrity protection and confid= entiality. It is RECOMMENDED that TLS/DTLS with an encryption algorithm acc= ording to always be used and in cases= where signaling/control traffic is properly protected, as described s/be used and in cases/be used. In cases Cheers, Charles in it is REQUIRED to use a mandated encryption = algorithm. BFCP entities MAY use other security mechanisms as long as they = provide similar security properties." Text last in Section 14: "Attackers may attempt to pick messages from the network to get access t= o confidential information between the floor control server and a client (e= .g., why a floor request was denied). TLS/DTLS confidentiality prevents thi= s attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryptio= n algorithm according to ." Feel free to make all of these changes and submit a rev and I=92ll issue th= e IETF LC. Thanks, Alissa =3D Section 14 =3D See the point above about ciphersuites. =93Non-null encryption=94 is not a = sufficient minimum baseline, and if the requirements change in Section 7 th= ey should be reflected here as well. Yep. Section 14 polished a bit, as indicated above. Editorial nits to be resolved with LC comments: =3D Section 5.1 =3D =93The version field MUST be set to 1 when using BFCP over a reliable transport, i.e. as in [2].=94 I find it a little odd to reference the spec you=92re obsoleting in this se= ntence, especially since BFCP over a reliable transport is completely speci= fied in this bis document. I would suggest dropping the i.e. clause. Good catch. This is a carry over from before this draft was adopted as a bi= s version of rfc4582. Fixed. "The version field MUST be set to 2 when using BFCP over an unreliable transport with the extensions specified in this document.=94 The bit about =93with the extensions specified in this document=94 is extra= neous and should be removed. Done "If an endpoint receives a message with an unsupported version field value, the receiving server MUST send an Error message with parameter value 12 (Unsupported Version) to indicate this.=94 Use of the word =93server=94 here makes it sound as if only servers could r= eceive headers with unsupported versions. Should this be =93the receiving e= ndpoint=94? Well, only floor control servers may issue an Error message so this is fixe= d by stating that. "If a floor control server receives...". =3D Section 6.2.4 =3D "[23], Section 6.7 provides useful recommendations =85=94 The links in the references are not quite right. No way to fix with my current version of xml2rfc! =3D Section 8.3.2 =3D s/when fires/when fired/ Fixed. =3D Section 14 =3D s/high-jack/hijack/ Fixed. =3D Section B.1 =3D "situation where multiple different and non-interoperable would co- exist in the market.=94 There is a word missing after =93non-interoperable." This should read =93non-interoperable implementations=94. Earlier in that s= ame sentence, =93BFCP over UDP were already used=94 should read =93BFCP ove= r UDP is already being used=94. Both fixed. Will submit the new version ASAP if no reactions are triggered here! -- Tom -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_D10D05913E07Eeckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <84DA0025957BB84997401704A54D9F38@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
All look great Tom, except for a couple nits (inline) that would be go= od to fix if/when we have another version of the document.

From: Tom Kristensen <2mkristensen@gmail.com>
Date: Thursday, February 19, 2015 a= t 5:54 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: Charles Eckel <eckelcu@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbis] AD evaluatio= n: draft-ietf-bfcpbis-rfc4582bis-12

Inline.

On 10 February 2015 at 00:58, Alissa Cooper <alissa@cooperw.i= n> wrote:
Hi Charles,

Thanks, some responses inline.

On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:<= /div>
HI Alissa,

Thank you for = the review. Please see my thoughts on your comments and questions inline.

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, January 29, 2015 at= 10:19 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD evaluation: d= raft-ietf-bfcpbis-rfc4582bis-12

I have reviewed this draft in preparation for IETF LC. Overall the doc= ument appears in good shape. I have a few questions and comments I=92d like= to discuss before issuing the IETF last call. I=92ve also included some ed= itorial nits that should be addressed together with any last call comments.

Comments and questions:

=3D Section 5.1 =3D
"If an endpoint receives a message with an
     unsupp= orted version field value, the receiving server MUST send an
     Error = message with parameter value 12 (Unsupported Version) to
     indica= te this.=94

This seems a little misleading since RFC 4582 didn=92t specify what to= do upon receipt of a message with a version other than 1. Implementations = that do not get upgraded to be compliant with 4582bis (which could certainl= y account for some of those that will not support version 2) will therefore never send the error specified here.= This seems like it should at least be noted given the MUST-level requireme= nt. The same applies in Section 13.7.

Good point. I = believe we made this a MUST because we were thinking in terms of implementa= tions compliant with this bis version. Adding your suggested note about rfc= 4582 implementations here and in section 13.7 seems useful to me.

Ok

Fine. Added text in 5.1 and 13.7 stating quite similarly th= is:

Text:
"If an endpoint receives a message with an unsupported= version field value, and the extensions in this document is supported, the= receiving server MUST send an Error message with parameter value 12 (Unsup= ported Version) to indicate this. Note that endpoints supporting only the RFC 4582 subset will not support this p= arameter value."

=3D Section 7 =3D
"BFCP entities MUST support, at a minimum, the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=94

I realize this requirement comes from RFC 4582, but I=92d like to unde= rstand why it has not been updated to be consistent with more current guida= nce on cipher suite selection (e.g., https://tools.= ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).

How about we k= eep this minimum requirement, and add a reference to draft-ietf-uta-tl= s-bcp along with a recommendation to adhere to the best practices it outlin= es in section 4?
I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards c= ompatibility and SHOULD support the ones listed in the UTA drafts would be = ok.

Hopefully, this is what new implementations will do. But of= course, adding this as SHOULD requirements are just fine - even though the= reference is an internet-draft and not an RFC yet. 

Text:
"<t>BFCP entities MUST support, at a minimum, the TLS_RSA_W= ITH_AES_128_CBC_SHA ciphersuite <xref target=3D"RFC5246"/> = for backwards compatibility with existing implementations of RFC 4582. In a= ccordance with the recommendations and guidelines in <xref target=3D&quo= t;I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the following cipher suites:</t>
    <t><list style=3D"symbols">
        <t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA2= 56</t>
        <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SH= A256</t>
        <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA3= 84</t>
        <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SH= A384</t>
    </list></t>"

=3D Sections 8, 8.1, 8.2 =3D
It seems like the transaction ID requirements regarding non-reuse/mono= tonically increasing IDs are re-stated multiple times across these three se= ctions, in slightly different ways, to the point where it=92s not clear exa= ctly what they are. It seems like they are:

(1) Reliable transport, server-initiated transaction: ID is 0
(2) Unreliable transport, server-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)
(3) Reliable transport, client-initiated transaction: ID MUST NOT be 0= and MUST NOT be reused in another message from the client until a response= from the server is received for the transaction, but need not be monotonic= ally increasing (e.g., a lower, recently used ID could be re-used once a response is received)
(4) Unreliable transport, client-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)

Is (3) the correct interpretation of the text in 8.1? If so, why not j= ust require IDs in all client-initiated transactions to be monotonically in= creasing?

Agree we can a= nd should simplify this. Sections 8.1 and 8.2 cover the client behavior and= server behavior in detail. As such, the transaction ID related information= at the start of Section 8 is superfluous. I recommend reducing the text in Section 8 to the follow:

8. Protocol Transactions

   In BFCP, there are two = types of transactions: client-initiated
   transactions and server= -initiated transactions.

   Client-initiated transa= ctions consist of a request from a client to a
   floor control server an= d a response from the floor control server to
   the client.

   Server-initiated transa= ctions have different behavior depending on 
   underly= ing transport:

      When using a re= liable transport, server-initiated transactions
      consist of a si= ngle message from a floor control server to a
      client (notific= ations).  They do not trigger any response.

      When using an u= nreliable transport, server-initiated transactions
      consist of a re= quest from a floor control server to a client and a
      response from t= he client to the floor control server.

   When using BFCP over an= unreliable transport, retransmission timer T1
   (see Section 8.3) MUST = be used for all requests until the transaction
   is completed.

Then in section 8.1, we add the impo= rtant details removed from section 8.

8.1.1 Client Behavior

   A client starting a client-initiated transaction MUST set= the
   Conference ID in the common header of the message to the = Conference
   ID for the conference that the client obtained previously= . 

   The client MUST set the Transaction ID value in the commo= n header to
   a number that is different from 0 and that MUST NOT be re= used in
   another message from the client until a response from the= server is
   received for the transaction.  The client uses the T= ransaction ID
   value to match this message with the response from the fl= oor control
   server. When using BFCP over an unreliable transport, it = is important to
   choose a Transaction ID value that lets the receiver dist= inguish the reception 
   of the next message in a sequence of BFCP messages from a= retransmission 
   of a previous message.  Therefore, BFCP entities usi= ng an unreliable transport MUST
   use monotonically incre= asing Transaction ID values (except for wrap-around).

   A client receivi= ng a server-initiated transaction over an unreliable transport
   MUST copy the Tr= ansaction ID from the request received from the server into the
   response. <= /div>
 
   [Question: is th= ere a need to copy the Conference ID and User ID, if present?]
Shouldn't be necessary for this message direction! 

8.2. Server Behavior

   A floor control server = sending a response within a client-initiated
   transaction MUST copy t= he Conference ID, the Transaction ID, and the
   User ID from the reques= t received from the client into the response.

   Server-initiated transa= ctions MUST contain a Transaction ID equal to
   0 when BFCP is used ove= r a reliable transport.  Over an unreliable
   transport, the Transact= ion ID shall have the same properties as for
   client-initiated transa= ctions. The s= erver uses the Transaction ID value to
   match this message with= the response from the floor participant or
   floor chair.


Thanks, this is better.

Charles' trimmed text adopted. The duplication of descripti= ons probably stems from our reshuffling and restructuring of text and later= rounds of clarifications of text pieces. 

=3D Section 9 (impacts Section 14 as well) =3D
"BFCP clients SHOULD authenticate the floor control server before=
   sending any BFCP message to it or accepting any BFCP mess= age from it.
   Similarly, floor control servers SHOULD authenticate a cl= ient before
   accepting any BFCP message from it or sending any BFCP me= ssage to it.

   BFCP supports TLS/DTLS mutual authentication between clie= nts and
   floor control servers, as specified in Section 9.1. = This is the
   RECOMMENDED authentication mechanism in BFCP.=94

What are the cases where clients and servers do not need to be authent= icating each other? I know this requirement and the other SHOULD-level requ= irements around use of TLS/DTLS are carried over from RFC 4582, but I=92m c= oncerned that they aren=92t as strong as they should be. For a conference where the signaling traffic is authent= icated and confidentiality and integrity protected, why is it ok for the fl= oor control traffic not to be? Could these requirements be adjusted to requ= ire use of TLS/DTLS at least in cases where the signaling is also protected?

Yes, but again= , this would be at the expense of adding a non backward compatible change f= rom rfc 4582. How about saying TLS/DTLS MUST be used for BFCP in such cases= , while pointing out the rfc 4582 based implementations may not comply (similar to what we did with the vers= ion field).
Works for me.

Text in Section 9:
"<t>BFCP clients SHOULD authenticate the floor control serv= er before sending any BFCP message to it or accepting any BFCP message from= it. Similarly, floor control servers SHOULD authenticate a client before a= ccepting any BFCP message from it or sending any BFCP message to it.</t>
    <t>If the signaling or control protocol traffic us= ed to set up the conference is authenticated and confidentiality and integr= ity protected, and the extensions in this document is supported, the BFCP c= lients MUST authenticate the floor control

s/is supported/are supported

server and the floor control servers MUST authenticate a client before= communicating as described above. Note that

s/a client/the client

endpoints supporting only the RFC 4582 subset may not comply with this= mandatory authentication requirement.</t>

Text first in Section 14:
"<t>BFCP uses TLS/DTLS to provide mutual authentication bet= ween clients and servers. TLS/DTLS also provides replay and integrity prote= ction and confidentiality. It is RECOMMENDED that TLS/DTLS with an encrypti= on algorithm according to <xref target=3D"sec:lower-security"/= > always be used and in cases where signaling/control traffic is properly pr= otected, as described

s/be used and in cases/be used. In cases

Cheers,
Charles

in <xref target=3D"sec:auth"/> it is REQUIRED to use a= mandated encryption algorithm. BFCP entities MAY use other security mechan= isms as long as they provide similar security properties.</t>"
 
Text last in Section 14:
"<t>Attackers may attempt to pick messages from = the network to get access to confidential information between the floor con= trol server and a client (e.g., why a floor request was denied). TLS/DTLS c= onfidentiality prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm accordin= g to <a href=3D"sec:lower-security"/>.</t>"


Feel free to make all of these changes and submit a rev and I=92ll iss= ue the IETF LC.

Thanks,
Alissa



=3D Section 14 =3D
See the point above about ciphersuites. =93Non-null encryption=94 is n= ot a sufficient minimum baseline, and if the requirements change in Section= 7 they should be reflected here as well.

Yep.
Section 14 polished a bit, as indicated above.
 
Editorial nits to be resolved with LC comments:

=3D Section 5.1 =3D
=93The version field MUST be set to 1 when using BFCP over a reliable<= /div>
   transport, i.e. as in [2].=94

I find it a little odd to reference the spec you=92re obsoleting in th= is sentence, especially since BFCP over a reliable transport is completely = specified in this bis document. I would suggest dropping the i.e. clause.

Good catch. Th= is is a carry over from before this draft was adopted as a bis version of r= fc4582.
Fixed. 

"The version field MUST be set to 2 when
   using BFCP over an unreliable transport with the extensio= ns specified
   in this document.=94

The bit about =93with the extensions specified in this document=94 is = extraneous and should be removed.
Done 

"If an endpoint receives a message with an
    unsupported = version field value, the receiving server MUST send an
    Error messag= e with parameter value 12 (Unsupported Version) to
    indicate thi= s.=94

Use of the word =93server=94 here makes it sound as if only servers co= uld receive headers with unsupported versions. Should this be =93the receiv= ing endpoint=94?
Well, only floor control servers may issue an Error message= so this is fixed by stating that. "If a floor control server receives= ...".

=3D Section 6.2.4 =3D
"[23], Section 6.7 provides useful recommendations =85=94

The links in the references are not quite right.
No way to fix with my current version of xml2rfc!
=3D Section 8.3.2 =3D
s/when fires/when fired/
Fixed. 

=3D Section 14 =3D
s/high-jack/hijack/
Fixed. 

=3D Section B.1 =3D
"situation where multiple di= fferent and non-interoperable would co-
   exist in the market.=94

There is a word missing after =93non-interoperable."

This should re= ad =93non-interoperable implementations=94. Earlier in that same sentence, = =93BFCP over UDP were already used=94 should read =93BFCP over UDP is alrea= dy being used=94.
Both fixed. 


Will submit the new version ASAP if no reactions are trigge= red here!

-- Tom 



--
# Cisco           &= nbsp;             |  http://www.cisco.com/telepres= ence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/
 --_000_D10D05913E07Eeckelcuciscocom_-- From nobody Mon Feb 23 06:34:16 2015 Return-Path: <2mkristensen@gmail.com> X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98A41A1AA0 for ; Mon, 23 Feb 2015 06:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJYbOzYsj-h for ; Mon, 23 Feb 2015 06:34:10 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D331A1B1F for ; Mon, 23 Feb 2015 06:34:04 -0800 (PST) Received: by labgq15 with SMTP id gq15so18810028lab.6 for ; Mon, 23 Feb 2015 06:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6n1vy4M/jGcJ+wwN/r5c2EJpk5f8drjJ+i38xNjSQOk=; b=e5V35gAML9/hmv/0o4egDxqLuap5ezH0lz74UTYqqtuR5oxgLGJkErgdT9LW2jzwPa tgzMvw5N+2uUpAlWzY+x6bSRrqk7b1u7iHnrvVyb8RUA4meItqMqpu3JDOmu8A3Mvtss FvPAH7gruLyC2c7b4nseFNrO3tAtlGgR4N1PRNuCKN84dgUKajjMUh6gZ1UltgjON1TN 2aBX8oWdeGjDcuIzL6/16d0VjTRn3Mx6td5w302gOTBasvJ/vVeJTt981mV5caQWvNax lesxeufUrDtrmGlbaKc7ZyyUW+8WyuXYtqQtbRGiptSxAbZNks/7R8uKTHv+7M8hInCP xvUw== MIME-Version: 1.0 X-Received: by 10.112.14.196 with SMTP id r4mr10104955lbc.86.1424702042483; Mon, 23 Feb 2015 06:34:02 -0800 (PST) Received: by 10.25.88.198 with HTTP; Mon, 23 Feb 2015 06:34:02 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Feb 2015 15:34:02 +0100 Message-ID: From: Tom Kristensen <2mkristensen@gmail.com> To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a1133161a2731f8050fc24ba3 Archived-At: Cc: "bfcpbis@ietf.org" , Alissa Cooper Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:34:16 -0000 --001a1133161a2731f8050fc24ba3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Charles, will do the nit fixing locally and keep it until the next version in some later stage. -- Tom On 21 February 2015 at 00:45, Charles Eckel (eckelcu) wrote: > All look great Tom, except for a couple nits (inline) that would be good > to fix if/when we have another version of the document. > > From: Tom Kristensen <2mkristensen@gmail.com> > Date: Thursday, February 19, 2015 at 5:54 AM > To: Alissa Cooper > Cc: Charles Eckel , "bfcpbis@ietf.org" < > bfcpbis@ietf.org> > Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 > > Inline. > > On 10 February 2015 at 00:58, Alissa Cooper wrote: > >> Hi Charles, >> >> Thanks, some responses inline. >> >> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) >> wrote: >> >> HI Alissa, >> >> Thank you for the review. Please see my thoughts on your comments and >> questions inline. >> >> From: Alissa Cooper >> Date: Thursday, January 29, 2015 at 10:19 PM >> To: "bfcpbis@ietf.org" >> Subject: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12 >> >> I have reviewed this draft in preparation for IETF LC. Overall the >> document appears in good shape. I have a few questions and comments I=E2= =80=99d >> like to discuss before issuing the IETF last call. I=E2=80=99ve also inc= luded some >> editorial nits that should be addressed together with any last call >> comments. >> >> Comments and questions: >> >> =3D Section 5.1 =3D >> "If an endpoint receives a message with an >> unsupported version field value, the receiving server MUST send an >> Error message with parameter value 12 (Unsupported Version) to >> indicate this.=E2=80=9D >> >> This seems a little misleading since RFC 4582 didn=E2=80=99t specify wh= at to do >> upon receipt of a message with a version other than 1. Implementations t= hat >> do not get upgraded to be compliant with 4582bis (which could certainly >> account for some of those that will not support version 2) will therefor= e >> never send the error specified here. This seems like it should at least = be >> noted given the MUST-level requirement. The same applies in Section 13.7= . >> >> >> Good point. I believe we made this a MUST because we were thinking in >> terms of implementations compliant with this bis version. Adding your >> suggested note about rfc 4582 implementations here and in section 13.7 >> seems useful to me. >> >> >> Ok >> > > Fine. Added text in 5.1 and 13.7 stating quite similarly this: > > Text: > "If an endpoint receives a message with an unsupported version field > value, and the extensions in this document is supported, the receiving > server MUST send an Error message with parameter value 12 (Unsupported > Version) to indicate this. Note that endpoints supporting only the RFC 45= 82 > subset will not support this parameter value." > > =3D Section 7 =3D >> "BFCP entities MUST support, at a minimum, the >> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=E2=80=9D >> >> I realize this requirement comes from RFC 4582, but I=E2=80=99d like to >> understand why it has not been updated to be consistent with more curren= t >> guidance on cipher suite selection (e.g., >> https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4). >> >> >> How about we keep this minimum requirement, and add a reference >> to draft-ietf-uta-tls-bcp along with a recommendation to adhere to the b= est >> practices it outlines in section 4? >> >> >> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for backwards >> compatibility and SHOULD support the ones listed in the UTA drafts would= be >> ok. >> > > Hopefully, this is what new implementations will do. But of course, > adding this as SHOULD requirements are just fine - even though the > reference is an internet-draft and not an RFC yet. > > Text: > "BFCP entities MUST support, at a minimum, the > TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite for > backwards compatibility with existing implementations of RFC 4582. In > accordance with the recommendations and guidelines in target=3D"I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the follo= wing > cipher suites: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > " > > =3D Sections 8, 8.1, 8.2 =3D >> It seems like the transaction ID requirements regarding >> non-reuse/monotonically increasing IDs are re-stated multiple times acro= ss >> these three sections, in slightly different ways, to the point where it= =E2=80=99s >> not clear exactly what they are. It seems like they are: >> >> (1) Reliable transport, server-initiated transaction: ID is 0 >> (2) Unreliable transport, server-initiated transaction: ID MUST be >> monotonically increasing (except for wrap-around) >> (3) Reliable transport, client-initiated transaction: ID MUST NOT be 0 >> and MUST NOT be reused in another message from the client until a respon= se >> from the server is received for the transaction, but need not be >> monotonically increasing (e.g., a lower, recently used ID could be re-us= ed >> once a response is received) >> (4) Unreliable transport, client-initiated transaction: ID MUST be >> monotonically increasing (except for wrap-around) >> >> Is (3) the correct interpretation of the text in 8.1? If so, why not >> just require IDs in all client-initiated transactions to be monotonicall= y >> increasing? >> >> >> Agree we can and should simplify this. Sections 8.1 and 8.2 cover the >> client behavior and server behavior in detail. As such, the transaction = ID >> related information at the start of Section 8 is superfluous. I recommen= d >> reducing the text in Section 8 to the follow: >> >> 8. Protocol Transactions >> >> In BFCP, there are two types of transactions: client-initiated >> transactions and server-initiated transactions. >> >> Client-initiated transactions consist of a request from a client to = a >> floor control server and a response from the floor control server to >> the client. >> >> Server-initiated transactions have different behavior depending on >> underlying transport: >> >> When using a reliable transport, server-initiated transactions >> consist of a single message from a floor control server to a >> client (notifications). They do not trigger any response. >> >> When using an unreliable transport, server-initiated transactions >> consist of a request from a floor control server to a client and a >> response from the client to the floor control server. >> >> When using BFCP over an unreliable transport, retransmission timer T= 1 >> (see Section 8.3) MUST be used for all requests until the transaction >> is completed. >> >> Then in section 8.1, we add the important details removed from section >> 8. >> >> 8.1.1 Client Behavior >> >> A client starting a client-initiated transaction MUST set the >> Conference ID in the common header of the message to the Conference >> ID for the conference that the client obtained previously. >> >> The client MUST set the Transaction ID value in the common header to >> a number that is different from 0 and that MUST NOT be reused in >> another message from the client until a response from the server is >> received for the transaction. The client uses the Transaction ID >> value to match this message with the response from the floor control >> server. When using BFCP over an unreliable transport, it is important >> to >> choose a Transaction ID value that lets the receiver distinguish the >> reception >> of the next message in a sequence of BFCP messages from a >> retransmission >> of a previous message. Therefore, BFCP entities using an unreliable >> transport MUST >> use monotonically increasing Transaction ID values (except for wrap- >> around). >> >> A client receiving a server-initiated transaction over an unreliable >> transport >> MUST copy the Transaction ID from the request received from the serve= r >> into the >> response. >> >> > >> [Question: is there a need to copy the Conference ID and User ID, >> if present?] >> >> Shouldn't be necessary for this message direction! > > 8.2. Server Behavior >> >> A floor control server sending a response within a client-initiated >> transaction MUST copy the Conference ID, the Transaction ID, and the >> User ID from the request received from the client into the response. >> >> Server-initiated transactions MUST contain a Transaction ID equal to >> 0 when BFCP is used over a reliable transport. Over an unreliable >> transport, the Transaction ID shall have the same properties as for >> client-initiated transactions. The server uses the Transaction ID >> value to >> match this message with the response from the floor participant or >> floor chair. >> >> >> Thanks, this is better. >> > > Charles' trimmed text adopted. The duplication of descriptions probably > stems from our reshuffling and restructuring of text and later rounds of > clarifications of text pieces. > > =3D Section 9 (impacts Section 14 as well) =3D >> "BFCP clients SHOULD authenticate the floor control server before >> sending any BFCP message to it or accepting any BFCP message from it. >> Similarly, floor control servers SHOULD authenticate a client before >> accepting any BFCP message from it or sending any BFCP message to it. >> >> BFCP supports TLS/DTLS mutual authentication between clients and >> floor control servers, as specified in Section 9.1. This is the >> RECOMMENDED authentication mechanism in BFCP.=E2=80=9D >> >> What are the cases where clients and servers do not need to be >> authenticating each other? I know this requirement and the other >> SHOULD-level requirements around use of TLS/DTLS are carried over from R= FC >> 4582, but I=E2=80=99m concerned that they aren=E2=80=99t as strong as th= ey should be. For a >> conference where the signaling traffic is authenticated and confidential= ity >> and integrity protected, why is it ok for the floor control traffic not = to >> be? Could these requirements be adjusted to require use of TLS/DTLS at >> least in cases where the signaling is also protected? >> >> >> Yes, but again, this would be at the expense of adding a non backward >> compatible change from rfc 4582. How about saying TLS/DTLS MUST be used = for >> BFCP in such cases, while pointing out the rfc 4582 based implementation= s >> may not comply (similar to what we did with the version field). >> >> >> Works for me. >> > > Text in Section 9: > "BFCP clients SHOULD authenticate the floor control server before > sending any BFCP message to it or accepting any BFCP message from it. > Similarly, floor control servers SHOULD authenticate a client before > accepting any BFCP message from it or sending any BFCP message to it. > If the signaling or control protocol traffic used to set up the > conference is authenticated and confidentiality and integrity protected, > and the extensions in this document is supported, the BFCP clients MUST > authenticate the floor control > > > s/is supported/are supported > > server and the floor control servers MUST authenticate a client > before communicating as described above. Note that > > > s/a client/the client > > endpoints supporting only the RFC 4582 subset may not comply with > this mandatory authentication requirement. > > > Text first in Section 14: > "BFCP uses TLS/DTLS to provide mutual authentication between clients > and servers. TLS/DTLS also provides replay and integrity protection and > confidentiality. It is RECOMMENDED that TLS/DTLS with an encryption > algorithm according to always be us= ed > and in cases where signaling/control traffic is properly protected, as > described > > > s/be used and in cases/be used. In cases > > Cheers, > Charles > > in it is REQUIRED to use a mandated > encryption algorithm. BFCP entities MAY use other security mechanisms as > long as they provide similar security properties." > > Text last in Section 14: > "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/DTLS confidentiality prevents > this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an > encryption algorithm according to ." > > > Feel free to make all of these changes and submit a rev and I=E2=80=99= ll issue >> the IETF LC. >> >> Thanks, >> Alissa >> >> >> >> =3D Section 14 =3D >> See the point above about ciphersuites. =E2=80=9CNon-null encryption=E2= =80=9D is not a >> sufficient minimum baseline, and if the requirements change in Section 7 >> they should be reflected here as well. >> >> >> Yep. >> >> Section 14 polished a bit, as indicated above. > > >> Editorial nits to be resolved with LC comments: >> >> =3D Section 5.1 =3D >> =E2=80=9CThe version field MUST be set to 1 when using BFCP over a relia= ble >> transport, i.e. as in [2].=E2=80=9D >> >> I find it a little odd to reference the spec you=E2=80=99re obsoleting = in this >> sentence, especially since BFCP over a reliable transport is completely >> specified in this bis document. I would suggest dropping the i.e. clause= . >> >> >> Good catch. This is a carry over from before this draft was adopted as >> a bis version of rfc4582. >> >> Fixed. > > "The version field MUST be set to 2 when >> using BFCP over an unreliable transport with the extensions specified >> in this document.=E2=80=9D >> >> The bit about =E2=80=9Cwith the extensions specified in this document= =E2=80=9D is >> extraneous and should be removed. >> >> Done > > "If an endpoint receives a message with an >> unsupported version field value, the receiving server MUST send an >> Error message with parameter value 12 (Unsupported Version) to >> indicate this.=E2=80=9D >> >> Use of the word =E2=80=9Cserver=E2=80=9D here makes it sound as if only= servers could >> receive headers with unsupported versions. Should this be =E2=80=9Cthe r= eceiving >> endpoint=E2=80=9D? >> >> Well, only floor control servers may issue an Error message so this > is fixed by stating that. "If a floor control server receives...". > > =3D Section 6.2.4 =3D >> "[23], Section 6.7 provides useful recommendations =E2=80=A6=E2=80=9D >> >> The links in the references are not quite right. >> >> No way to fix with my current version of xml2rfc! > >> =3D Section 8.3.2 =3D >> s/when fires/when fired/ >> >> Fixed. > > =3D Section 14 =3D >> s/high-jack/hijack/ >> >> Fixed. > > =3D Section B.1 =3D >> "situation where multiple different and non-interoperable would co- >> exist in the market.=E2=80=9D >> >> There is a word missing after =E2=80=9Cnon-interoperable." >> >> >> This should read =E2=80=9Cnon-interoperable implementations=E2=80=9D. E= arlier in that >> same sentence, =E2=80=9CBFCP over UDP were already used=E2=80=9D should = read =E2=80=9CBFCP over UDP >> is already being used=E2=80=9D. >> >> Both fixed. > > > Will submit the new version ASAP if no reactions are triggered here! > > -- Tom > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > --=20 # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/ --001a1133161a2731f8050fc24ba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Charles, will do the nit fixing locally and keep it= until the next version in some later stage.

-- To= m

On 2= 1 February 2015 at 00:45, Charles Eckel (eckelcu) <eckelcu@cisco.com&g= t; wrote:
All look great Tom, except for a couple nits (inline) that would be go= od to fix if/when we have another version of the document.

From: Tom Kristensen <2mkristensen@gmail.com>
Date: Thursday, February 19, 2015 a= t 5:54 AM
To: Alissa Cooper <alissa@cooperw.in>
Cc: Charles Eckel <eckelcu@cisco.com>, "= bfcpbis@ietf.org&= quot; <bfcpbis@iet= f.org>
Subject: Re: [bfcpbis] AD evaluatio= n: draft-ietf-bfcpbis-rfc4582bis-12

Inline.

On 10 February 2015 at 00:58, Alissa Cooper <alissa@cooperw.i= n> wrote:
Hi Charles,

Thanks, some responses inline.

On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:<= /div>
HI Alissa,

Thank you for = the review. Please see my thoughts on your comments and questions inline.

From: Alissa Cooper <alissa@cooperw.in>
Date: Thursday, January 29, 2015 at= 10:19 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] AD evaluation: d= raft-ietf-bfcpbis-rfc4582bis-12

I have reviewed this draft in preparation for IETF LC. Overall the doc= ument appears in good shape. I have a few questions and comments I=E2=80=99= d like to discuss before issuing the IETF last call. I=E2=80=99ve also incl= uded some editorial nits that should be addressed together with any last call comments.

Comments and questions:

=3D Section 5.1 =3D
"If an endpoint receives a message with an
=C2=A0 =C2=A0=C2=A0 unsupp= orted version field value, the receiving server MUST send an
=C2=A0 =C2=A0=C2=A0 Error = message with parameter value 12 (Unsupported Version) to
=C2=A0 =C2=A0=C2=A0 indica= te this.=E2=80=9D

This seems a little misleading since RFC 4582 didn=E2=80=99t specify w= hat to do upon receipt of a message with a version other than 1. Implementa= tions that do not get upgraded to be compliant with 4582bis (which could ce= rtainly account for some of those that will not support version 2) will therefore never send the error specified here.= This seems like it should at least be noted given the MUST-level requireme= nt. The same applies in Section 13.7.

Good point. I = believe we made this a MUST because we were thinking in terms of implementa= tions compliant with this bis version. Adding your suggested note about rfc= 4582 implementations here and in section 13.7 seems useful to me.

Ok

Fine. Added text in 5.1 and 13.7 stating quite similarly this:

Text:
"If an endpoint receives a message with an unsupported version fi= eld value, and the extensions in this document is supported, the receiving = server MUST send an Error message with parameter value 12 (Unsupported Vers= ion) to indicate this. Note that endpoints supporting only the RFC 4582 subset will not support this p= arameter value."

=3D Section 7 =3D
"BFCP entities MUST support, at a minimum, the
=C2=A0 =C2=A0TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].=E2=80=9D

I realize this requirement comes from RFC 4582, but I=E2=80=99d like t= o understand why it has not been updated to be consistent with more current= guidance on cipher suite selection (e.g.,=C2=A0https://= tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section-4).

How about we k= eep this minimum requirement, and add a reference to=C2=A0draft-ietf-uta-tl= s-bcp along with a recommendation to adhere to the best practices it outlin= es in section 4?
I think MUST support=C2=A0TLS_RSA_WITH_AES_128_CBC_SHA for backwards c= ompatibility and SHOULD support the ones listed in the UTA drafts would be = ok.

Hopefully, this is what new implementations will do. But of course, ad= ding this as SHOULD requirements are just fine - even though the reference = is an internet-draft and not an RFC yet.=C2=A0

Text:
"<t>BFCP entities MUST support, at a minimum, the TLS_RSA_W= ITH_AES_128_CBC_SHA ciphersuite <xref target=3D"RFC5246"/> = for backwards compatibility with existing implementations of RFC 4582. In a= ccordance with the recommendations and guidelines in <xref target=3D&quo= t;I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the following cipher suites:</t>
=C2=A0 =C2=A0 <t><list style=3D"symbols">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA2= 56</t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SH= A256</t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA3= 84</t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SH= A384</t>
=C2=A0 =C2=A0 </list></t>"

=3D Sections 8, 8.1, 8.2 =3D
It seems like the transaction ID requirements regarding non-reuse/mono= tonically increasing IDs are re-stated multiple times across these three se= ctions, in slightly different ways, to the point where it=E2=80=99s not cle= ar exactly what they are. It seems like they are:

(1) Reliable transport, server-initiated transaction: ID is 0
(2) Unreliable transport, server-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)
(3) Reliable transport, client-initiated transaction: ID MUST NOT be 0= and MUST NOT be reused in another message from the client until a response= from the server is received for the transaction, but need not be monotonic= ally increasing (e.g., a lower, recently used ID could be re-used once a response is received)
(4) Unreliable transport, client-initiated transaction: ID MUST be mon= otonically increasing (except for wrap-around)

Is (3) the correct interpretation of the text in 8.1? If so, why not j= ust require IDs in all client-initiated transactions to be monotonically in= creasing?

Agree we can a= nd should simplify this. Sections 8.1 and 8.2 cover the client behavior and= server behavior in detail. As such, the transaction ID related information= at the start of Section 8 is superfluous. I recommend reducing the text in Section 8 to the follow:

8. Protocol Transactions

=C2=A0 =C2=A0In BFCP, there are two = types of transactions: client-initiated
=C2=A0 =C2=A0transactions and server= -initiated transactions.

=C2=A0 =C2=A0Client-initiated transa= ctions consist of a request from a client to a
=C2=A0 =C2=A0floor control server an= d a response from the floor control server to
=C2=A0 =C2=A0the client.

=C2=A0 =C2=A0Server-initiated transa= ctions have different=C2=A0behavior depending on=C2=A0
=C2=A0 =C2=A0underlying= transport:

=C2=A0 =C2=A0 =C2=A0 When using a re= liable transport, server-initiated transactions
=C2=A0 =C2=A0 =C2=A0 consist of a si= ngle message from a floor control server to a
=C2=A0 =C2=A0 =C2=A0 client (notific= ations).=C2=A0 They do not trigger any response.

=C2=A0 =C2=A0 =C2=A0 When using an u= nreliable transport, server-initiated transactions
=C2=A0 =C2=A0 =C2=A0 consist of a re= quest from a floor control server to a client and a
=C2=A0 =C2=A0 =C2=A0 response from t= he client to the floor control server.

=C2=A0 =C2=A0When using BFCP over an= unreliable transport, retransmission timer T1
=C2=A0 =C2=A0(see Section 8.3) MUST = be used for all requests until the transaction
=C2=A0 =C2=A0is completed.

Then in section 8.1, we add the impo= rtant details removed from section 8.

8.1.1 Client Behavior

=C2=A0 =C2=A0A client starting a client-initiated transaction MUST set= the
=C2=A0 =C2=A0Conference ID in the common header of the message to the = Conference
=C2=A0 =C2=A0ID for the conference that the client obtained previously= .=C2=A0

=C2=A0 =C2=A0The client MUST set the Transaction ID value in the commo= n header to
=C2=A0 =C2=A0a number that is different from 0 and that MUST NOT be re= used in
=C2=A0 =C2=A0another message from the client until a response from the= server is
=C2=A0 =C2=A0received for the transaction.=C2=A0 The client uses the T= ransaction ID
=C2=A0 =C2=A0value to match this message with the response from the fl= oor control
=C2=A0 =C2=A0server. When using BFCP over an unreliable transport, it = is important to
=C2=A0 =C2=A0choose a Transaction ID value that lets the receiver dist= inguish the reception=C2=A0
=C2=A0 =C2=A0of the next message in a sequence of BFCP messages from a= retransmission=C2=A0
=C2=A0 =C2=A0of a previous message.=C2=A0 Therefore, BFCP entities usi= ng an unreliable transport MUST
=C2=A0 =C2=A0use monotonically incre= asing Transaction ID values (except for wrap-around).

=C2=A0 =C2=A0A client receivi= ng a server-initiated transaction over an unreliable transport
=C2=A0 =C2=A0MUST copy the Tr= ansaction ID from the request received from the server into the
=C2=A0 =C2=A0response.=C2=A0<= /div>
=C2=A0
=C2=A0 =C2=A0[Question: is th= ere a need to copy the Conference ID and User ID, if present?]
Shouldn't be necessary for this message direction!=C2=A0

8.2. Server Behavior

=C2=A0 =C2=A0A floor control server = sending a response within a client-initiated
=C2=A0 =C2=A0transaction MUST copy t= he Conference ID, the Transaction ID, and the
=C2=A0 =C2=A0User ID from the reques= t received from the client into the response.

=C2=A0 =C2=A0Server-initiated transa= ctions MUST contain a Transaction ID equal to
=C2=A0 =C2=A00 when BFCP is used ove= r a reliable transport.=C2=A0 Over an unreliable
=C2=A0 =C2=A0transport, the Transact= ion ID shall have the same properties as for
=C2=A0 =C2=A0client-initiated transa= ctions.=C2=A0The serv= er uses the Transaction ID value to
=C2=A0 =C2=A0match this message with= the response from the floor participant or
=C2=A0 =C2=A0floor chair.


Thanks, this is better.

Charles' trimmed text adopted. The duplication of descriptions pro= bably stems from our reshuffling and restructuring of text and later rounds= of clarifications of text pieces.=C2=A0

=3D Section 9 (impacts Section 14 as well) =3D
"BFCP clients SHOULD authenticate the floor control server before=
=C2=A0 =C2=A0sending any BFCP message to it or accepting any BFCP mess= age from it.
=C2=A0 =C2=A0Similarly, floor control servers SHOULD authenticate a cl= ient before
=C2=A0 =C2=A0accepting any BFCP message from it or sending any BFCP me= ssage to it.

=C2=A0 =C2=A0BFCP supports TLS/DTLS mutual authentication between clie= nts and
=C2=A0 =C2=A0floor control servers, as specified in Section 9.1.=C2=A0= This is the
=C2=A0 =C2=A0RECOMMENDED authentication mechanism in BFCP.=E2=80=9D

What are the cases where clients and servers do not need to be authent= icating each other? I know this requirement and the other SHOULD-level requ= irements around use of TLS/DTLS are carried over from RFC 4582, but I=E2=80= =99m concerned that they aren=E2=80=99t as strong as they should be. For a conference where the signaling traffic is authent= icated and confidentiality and integrity protected, why is it ok for the fl= oor control traffic not to be? Could these requirements be adjusted to requ= ire use of TLS/DTLS at least in cases where the signaling is also protected?

Yes, but again= , this would be at the expense of adding a non backward compatible change f= rom rfc 4582. How about saying TLS/DTLS MUST be used for BFCP in such cases= , while pointing out the rfc 4582 based implementations may not comply (similar to what we did with the vers= ion field).
Works for me.

Text in Section 9:
"<t>BFCP clients SHOULD authenticate the floor control serv= er before sending any BFCP message to it or accepting any BFCP message from= it. Similarly, floor control servers SHOULD authenticate a client before a= ccepting any BFCP message from it or sending any BFCP message to it.</t>
=C2=A0 =C2=A0 <t>If the signaling or control protocol traffic us= ed to set up the conference is authenticated and confidentiality and integr= ity protected, and the extensions in this document is supported, the BFCP c= lients MUST authenticate the floor control

s/is supported/are supported

server and the floor control servers MUST authenticate a client before= communicating as described above. Note that

s/a client/the client

endpoints supporting only the RFC 4582 subset may not comply with this= mandatory authentication requirement.</t>

Text first in Section 14:
"<t>BFCP uses TLS/DTLS to provide mutual authentication bet= ween clients and servers. TLS/DTLS also provides replay and integrity prote= ction and confidentiality. It is RECOMMENDED that TLS/DTLS with an encrypti= on algorithm according to <xref target=3D"sec:lower-security"/= > always be used and in cases where signaling/control traffic is properly pr= otected, as described

s/be used and in cases/be used. In cases

Cheers,
Charles

in <xref target=3D"sec:auth"/> it is REQUIRED to use a= mandated encryption algorithm. BFCP entities MAY use other security mechan= isms as long as they provide similar security properties.</t>"
=C2=A0
Text last in Section 14:
"<t>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/DTLS confidential= ity prevents this attack. Therefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm accordin= g to <a href=3D"sec:lower-security"/>.</t>"


Feel free to make all of these changes and submit a rev and I=E2=80=99= ll issue the IETF LC.

Thanks,
Alissa



=3D Section 14 =3D
See the point above about ciphersuites. =E2=80=9CNon-null encryption= =E2=80=9D is not a sufficient minimum baseline, and if the requirements cha= nge in Section 7 they should be reflected here as well.

Yep.
Section 14 polished a bit, as indicated above.
=C2=A0
Editorial nits to be resolved with LC comments:

=3D Section 5.1 =3D
=E2=80=9CThe version field MUST be set to 1 when using BFCP over a rel= iable
=C2=A0 =C2=A0transport, i.e. as in [2].=E2=80=9D

I find it a little odd to reference the spec you=E2=80=99re obsoleting= in this sentence, especially since BFCP over a reliable transport is compl= etely specified in this bis document. I would suggest dropping the i.e. cla= use.

Good catch. Th= is is a carry over from before this draft was adopted as a bis version of r= fc4582.
Fixed.=C2=A0

"The version field MUST be set to 2 when
=C2=A0 =C2=A0using BFCP over an unreliable transport with the extensio= ns specified
=C2=A0 =C2=A0in this document.=E2=80=9D

The bit about =E2=80=9Cwith the extensions specified in this document= =E2=80=9D is extraneous and should be removed.
Done=C2=A0

"If an endpoint receives a message with an
=C2=A0 =C2=A0 unsupported = version field value, the receiving server MUST send an
=C2=A0 =C2=A0 Error messag= e with parameter value 12 (Unsupported Version) to
=C2=A0 =C2=A0 indicate thi= s.=E2=80=9D

Use of the word =E2=80=9Cserver=E2=80=9D here makes it sound as if onl= y servers could receive headers with unsupported versions. Should this be = =E2=80=9Cthe receiving endpoint=E2=80=9D?
Well, only floor control servers may issue an Error message so this is= fixed by stating that. "If a floor control server receives...".<= /div>

=3D Section 6.2.4 =3D
"[23], Section 6.7 provides useful recommendations =E2=80=A6=E2= =80=9D

The links in the references are not quite right.
No way to fix with my current version of xml2rfc!
=3D Section 8.3.2 =3D
s/when fires/when fired/
Fixed.=C2=A0

=3D Section 14 =3D
s/high-jack/hijack/
Fixed.=C2=A0

=3D Section B.1 =3D
"situation where multiple di= fferent and non-interoperable would co-
=C2=A0 =C2=A0exist in the market.=E2=80=9D

There is a word missing after =E2=80=9Cnon-interoperable."

This should re= ad =E2=80=9Cnon-interoperable implementations=E2=80=9D. Earlier in that sam= e sentence, =E2=80=9CBFCP over UDP were already used=E2=80=9D should read = =E2=80=9CBFCP over UDP is already being used=E2=80=9D.
Both fixed.=C2=A0


Will submit the new version ASAP if no reactions are triggered here!

-- Tom=C2=A0



--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om =C2=A0| =C2=A0= http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://folk.uio.no/tomkri/



--
# Cisco =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0http://www.cisco.com/telepresence/=
## tomkrist@cis= co.com =C2=A0| =C2=A0http://www.tandberg.com
### =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0http://folk.uio= .no/tomkri/
--001a1133161a2731f8050fc24ba3--