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,

Sorry for delay. Please see inline <Ram> for my responses

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Thursday, 19 January 2017 at 5:10 AM
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Charles Eckel (eckelcu)" <[e-mail]>, "[e-mail]" <[e-mail]>, "Charles Eckel (eckelcu)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: 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, 19 January 2017 at 5:10 AM

    Ben Campbell has entered the following ballot position for
    draft-ietf-bfcpbis-bfcp-websocket-14: Discuss
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/
    
    
    
    ----------------------------------------------------------------------
    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 ?
    
    ----------------------------------------------------------------------
    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
   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.”



    -4.2, first paragraph: You talk about how the payload size limit is
    smaller when using websocket. Can you give guidance for actual reasonable
    limits?
<Ram> The para already gives the max limit. I don’t see a real need to give any other limit. The reason for adding this section to explicitly mention
that when BFCP is sent over WS/WSS there should be no fragmentation unlike what is mentioned in WS RFC [ rfc6455 section 5.4].
I think the procedures (like learning the MTU of a path and constructing BFCP msg such that it will not be fragmented] 
of Section 6.2.3 in [draft-ietf-bfcpbis-rfc4582bis-13] are applicable here as well. 
    
    -5, 2nd paragraph: "The BFCP server is a will have a globally routable
    address"
    Is there an implied MUST hiding in there? Also, there's a typo around "is
    will have".
<Ram> I will add a MUST here.
    
    -8, paragraph 8: Is the point that you SHOULD authenticate the client, or
    that if you want to authenticate the client you SHOULD do it this way? I
    suspect the former is intended, but the text implies the latter.
<Ram> Yes it’s the former. I am re-wording the last para of this section to this as per discussion in the thread. Is this making it better ?

NEW:
If the status code received from the server is not 101,
 the WebSocket client stack handles the response per HTTP
  [RFC7230] procedures, in particular the client might perform 
authentication if it receives 401 status code.  The WebSocket clients are 
vulnerable to the attacks of basic authentication (mentioned in Section 4 of [RFC7617]) and
 digest authentication (mentioned in Section 5 of [RFC7616]). To overcome some of these weakness, 
the WebSocket clients for example can use HTTP Origin-Bound Authentication (HOBA)
 mechanism mentioned in [RFC7486].

Regards,
Ram