Re: [bfcpbis] Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

This all looks good to me. I will release the DISCUSS when you submit 
the revision with the changes.

Thanks!

Ben.

On 8 Feb 2017, at 19:55, Ram Mohan R (rmohanr) wrote:

> Hi Ben,
>
> Thanks for your feedback. Please see inline <Ram>
>
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Date: Thursday, 9 February 2017 at 5:02 AM
> To: "Ram Mohan R (rmohanr)" <[e-mail]>
> Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, 
> "[e-mail]" 
> <[e-mail]>, "Charles Eckel 
> (eckelcu)" <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> Subject: Re: Ben Campbell's Discuss on 
> draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)
> Resent-From: <[e-mail]>
> Resent-To: <[e-mail]>, <[e-mail]>, 
> <[e-mail]>, <[e-mail]>, 
> <[e-mail]>, <[e-mail]>
> Resent-Date: Thursday, 9 February 2017 at 5:02 AM
>
>     Thanks for the response. Please see comments inline. I will delete
>     sections that seem to be resolved. (Consider my responses to them 
> as
>     "Okay").
>
>     Thanks!
>
>     Ben.
>
>     On 7 Feb 2017, at 10:20, Ram Mohan R (rmohanr) wrote:
>
>     > Hi Ben,
>     >
>     > Sorry for delay. Please see inline <Ram> for my responses
>     >
>     > -----Original Message-----
>     > From: Ben Campbell <[e-mail]>
>
>     [...]
>
>     >
>     >
>     >     
> ----------------------------------------------------------------------
>     >     DISCUSS:
>     >     
> ----------------------------------------------------------------------
>     >
>     >     I plan to ballot "yes" for this document, but I have some 
> concerns
>     > about
>     >     the security properties that I think need to be resolved 
> first. I
>     > have
>     >     followed the discussion resulting from Robert's Gen-ART 
> review
>     > (and will
>     >     have comments about that in the "COMMENTS section", but I 
> think I
>     > see an
>     >     additional issue that hasn't been covered in that 
> discussion.
>     >
>     >     draft-ietf-bfcpbis-rfc4582bis (currently in the RFC Editors 
> queue)
>     >     defines some situations where TLS and client authentication 
> are
>     >     normatively required. Specifically, section 9 of that draft 
> says
>     > that, if
>     >     the signaling channel is authenticated and has 
> confidentiality and
>     >     integrity protection, the BFCP client MUST be authenticated.
>     > Section 14
>     >     additionally says that under those circumstances, BFCP is 
> REQUIRED
>     > to use
>     >     the mandated cryptographic algorithm. But bfcp-websocket 
> only says
>     > that
>     >     WSS and client authentication are RECOMMENDED.
>     >
>     > <Ram> Agree. That’s a reasonable ask.
>     >
>     >     I think this could be fixed by requiring WSS, and the 
> web-based
>     > client
>     >     authentication techniques described in this draft whenever 
> the
>     > signaling
>     >     protocol is secured. The simplest way to describe that might 
> be to
>     > say
>     >     that BFCP-websocket must use at least as strong protections 
> as the
>     >     signaling channel.
>     >   <Ram> I will add the following line to the security 
> consideration
>     > section
>     > NEW:
>     > “Secure WebSocket (WSS) MUST be used for BCP when the 
> signalling
>     > channel used to exchange the BFCP parameters is secured. “
>     >
>     > Is this ok ?
>
>     That's moving in the right direction. However, the second 
> paragraph of
>     section 9 of draft-ietf-bfcpbis-rfc4582bis offers a little more
>     precision. Perhaps something like the following:
>
>     "If the signaling or control protocol traffic used to set up the
>     conference is authenticated and confidentiality and integrity 
> protected,
>     Secure WebSocket (WSS) MUST be used, and the floor control server 
> MUST
>     authenticate the client."
>
> <Ram> Proposed text looks good to me. I will use this.
>
>     >
>     >     
> ----------------------------------------------------------------------
>     >     COMMENT:
>     >     
> ----------------------------------------------------------------------
>     >
>     >     I appreciate the author's efforts in resolving the security
>     >     considerations issues from Robert's Gen-ART review, but I 
> don't
>     > think the
>     >     current text is quite there yet. Version 14 added the text 
> to say
>     > that,
>     >     when using websockets, the websocket security mechanisms are 
> used
>     > instead
>     >     of those from draft-ietf-bfcpbis-rfc4582bis. But Robert also 
> asked
>     > for
>     >     the draft to describe how that change impacts the security
>     > analysis in
>     >     draft-ietf-bfcpbis-rfc4582bis. I don't see text that does 
> that.
>     > I'd like
>     >     to see, for each of the attacks described in
>     >     draft-ietf-bfcpbis-rfc4582bis, text that says describes how 
> (or
>     > if) a
>     >     similar attack would be mitigated using websocket.
>     > <Ram> Here is the text I plan to add the security considerations 
> as a
>     > separate paragraph
>     >
>     > EXISTING:
>     > When using BFCP over websockets, the security mechanisms defined 
> in
>     >     [draft-ietf-bfcpbis-rfc4592bis] are *not used*. Instead, the
>     > application
>     >     is required to build and rely on the security mechanisms in
>     > [RFC6455]
>     >
>     > NEW:
>     > “When using BFCP over websockets, the security mechanisms 
> defined in
>     >     [draft-ietf-bfcpbis-rfc4592bis] are *not used*. Instead, the
>     > application
>     >     is required to build and rely on the security mechanisms in
>     > [RFC6455]
>     >
>     > This section analyses the threats described in Section 14 of
>     > [draft-ietf-bfcpbis-rfc4582bis] when WebSocket is
>     > used as transport protocol for BFCP.
>     >
>     > An attacker attempting to impersonate a floor control server is
>     > avoided by having servers accept BFCP messages over
>     > Secure WebSocket (WSS) only. As with any other web connection, 
> the
>     > clients will verify the servers certificate.
>     > The floor control WebSocket client MUST follow the procedures in
>     > [RFC7525] (including hostname verification
>     > as per section 6.1 in [RFC7525]) while setting up TLS connection 
> with
>     > floor control webSocket server.
>     >
>     > An attacker attempting to impersonate a floor control client is
>     > avoided by having servers accept BFCP messages
>     > over WSS only. As described in Section 10.5 of [RFC6455] the 
> floor
>     > control server can use any client authentication
>     > mechanism and follow the steps in Section 8 of this document.
>     >
>     > Attackers may attempt to modify messages exchanged by a client 
> and a
>     >    floor control server. This can be prevented by having WSS 
> between
>     > client and server.
>     >
>     > An attacker trying to replay the messages is prevented by
>     >    having floor control servers check that messages arriving 
> over a
>     >    given WSS connection use an authorized user ID.
>     >
>     > Attackers may attempt to pick messages from the network to get 
> access
>
>     I'm not sure what you mean by "pick messages". Are we talking 
> about
>     eavesdropping?
> Yes.  It is eavesdropping. How about this:
>
> NEW:
> Attackers may eavesdrop on the network to get access to confidential 
> information between the floor control server and a
> [………]
>
> Regards,
> Ram
>
>     >    to confidential information between the floor control server 
> and a
>     >    client (e.g., why a floor request was denied).  In order to 
> ensure
>     > that
>     > BFCP users are getting the level of protection that they would 
> get
>     > using
>     > the BFCP protocol directly, applications need to have a way to
>     > control the websocket libraries to use encryption algorithms 
> specified
>     > in Section 7
>     > of [draft-ietf-bfcpbis-rfc4582bis. Since  the WebSocket API does 
> not
>     > have a way to
>     > allow an application to select the encryption algorithm to be 
> used,
>     > the protection
>     > level provided when WSS is used is limited to the underlying TLS
>     > algorithm used by WebSocket library.”
>     >
>     >
>
>     Other than the minor comment above, that looks good to me.
>
>     [...]