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

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

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