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

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

Thanks! I just cleared the DISCUSS.

Ben.

On 8 Feb 2017, at 21:15, Ram Mohan R (rmohanr) wrote:

> Thanks Ben.
>
> I just submitted a new revision - 
> https://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-15
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-15
>
> Regards,
> Ram
>
> -----Original Message-----
> From: Ben Campbell <[e-mail]>
> Date: Thursday, 9 February 2017 at 7:52 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)
>
>     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.
>     >
>     >     [...]