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

[Tom Kristensen <[e-mail]>]

Inline.

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

> Hi Charles,
>
> Thanks, some responses inline.
>
> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <[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]>
> Date: Thursday, January 29, 2015 at 10:19 PM
> To: "[e-mail]" <[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 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.</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 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]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/