Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12

["Charles Eckel (eckelcu)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 19, 2015 at 5:54 AM
To: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Cc: Charles Eckel <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12

Inline.

On 10 February 2015 at 00:58, Alissa Cooper <[e-mail]<mailto:[e-mail]>> wrote:
Hi Charles,

Thanks, some responses inline.

On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <[e-mail]<mailto:[e-mail]>> wrote:

HI Alissa,

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

From: Alissa Cooper <[e-mail]<mailto:[e-mail]>>
Date: Thursday, January 29, 2015 at 10:19 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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’d like to discuss before issuing the IETF last call. I’ve also included some editorial nits that should be addressed together with any last call comments.

Comments and questions:

= Section 5.1 =
"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.”

This seems a little misleading since RFC 4582 didn’t 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

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

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

I realize this requirement comes from RFC 4582, but I’d 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 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.

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_WITH_AES_128_CBC_SHA ciphersuite <xref target="RFC5246"/> for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in <xref target="I-D.ietf-uta-tls-bcp"/>, BFCP entities SHOULD support the following cipher suites:</t>
    <t><list style="symbols">
        <t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t>
        <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
        <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</t>
        <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</t>
    </list></t>"

= Sections 8, 8.1, 8.2 =
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’s 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?]
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.

= Section 9 (impacts Section 14 as well) =
"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.”

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’m concerned that they aren’t 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.

Text in Section 9:
"<t>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.</t>
    <t>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.</t>

Text first in Section 14:
"<t>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 <xref target="sec:lower-security"/> 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 <xref target="sec:auth"/> it is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use other security mechanisms 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 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 <a href="sec:lower-security"/>.</t>"


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

Thanks,
Alissa



= Section 14 =
See the point above about ciphersuites. “Non-null encryption” 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:

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

I find it a little odd to reference the spec you’re 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.”

The bit about “with the extensions specified in this document” 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.”

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

= Section 6.2.4 =
"[23], Section 6.7 provides useful recommendations …”

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

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

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

There is a word missing after “non-interoperable."

This should read “non-interoperable implementations”. Earlier in that same sentence, “BFCP over UDP were already used” should read “BFCP over UDP is already being used”.
Both fixed.


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

-- Tom



--
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]<mailto:[e-mail]>  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/