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

["Ram Mohan R (rmohanr)" <[e-mail]>]

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.
    >
    >     [...]