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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 7 Feb 2017 16:20:27 +0000

Hi Ben,

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

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Thursday, 19 January 2017 at 5:10 AM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Feb 2017 17:32:35 -0600

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.

> From: Ben Campbell <[email-masked]>

[...]

> “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."

> This section analyses the threats described in Section 14 of 
> [draft-ietf-bfcpbis-rfc4582bis] when WebSocket is
> 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
> 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

I'm not sure what you mean by "pick messages". Are we talking about 
eavesdropping?

> algorithm used by WebSocket library.”

Other than the minor comment above, that looks good to me.

[...]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 9 Feb 2017 01:55:25 +0000

Hi Ben,

Thanks for your feedback. Please see inline <Ram>

-----Original Message-----
From: Ben Campbell <[email-masked]>
Date: Thursday, 9 February 2017 at 5:02 AM
To: "Ram Mohan R (rmohanr)" <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, 9 February 2017 at 5:02 AM

    Thanks!
    
    Ben.

    
    [...]

    

<Ram> Proposed text looks good to me. I will use this.

    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

    
    [...]

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Feb 2017 20:22:57 -0600

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:

> Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, "Charles Eckel 
> (eckelcu)" <[email-masked]>, "[email-masked]" 
> <[email-masked]>
> Subject: Re: Ben Campbell's Discuss on 
> draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)
> Resent-To: <[email-masked]>, <[email-masked]>, 
> <[email-masked]>, <[email-masked]>, 
> <[email-masked]>, <[email-masked]>
>     >     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
>     >     normatively required. Specifically, section 9 of that draft 
> says
>     > that, if
>     >     additionally says that under those circumstances, BFCP is 
> REQUIRED
>     > to use
>     >     the mandated cryptographic algorithm. But bfcp-websocket 
> only says
>     > that
>     >     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
>     >   <Ram> I will add the following line to the security 
> consideration
>     > section
>     > NEW:
>     >     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
>     >     draft-ietf-bfcpbis-rfc4582bis. I don't see text that does 
> that.
>     > I'd like
>     >     draft-ietf-bfcpbis-rfc4582bis, text that says describes how 
> (or
>     > if) a
>     > <Ram> Here is the text I plan to add the security considerations 
> as a
>     > separate paragraph
>     >
>     > EXISTING:
>     > as per section 6.1 in [RFC7525]) while setting up TLS connection 
> with
>     > floor control webSocket server.
>     >
>     >    floor control server. This can be prevented by having WSS 
> between
>     > client and server.
>     >
> Attackers may eavesdrop on the network to get access to confidential 
> information between the floor control server and a
> [………]
>
> Regards,
> Ram
>
>     >    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
>     > 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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 9 Feb 2017 03:15:06 +0000

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 <[email-masked]>
Date: Thursday, 9 February 2017 at 7:52 AM
To: "Ram Mohan R (rmohanr)" <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Ben Campbell's Discuss on draft-ietf-bfcpbis-bfcp-websocket-14: (with DISCUSS and COMMENT)

    Thanks!
    
    Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Feb 2017 21:18:35 -0600

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
>
>     >     sections that seem to be resolved. (Consider my responses to 
> them
>     > as
>     >     "Okay").
>     >
>     >     Thanks!
>     >
>     >     Ben.
>     >
>     >     >     draft-ietf-bfcpbis-rfc4582bis (currently in the RFC 
> Editors
>     > queue)
>     >     >     defines some situations where TLS and client 
> authentication
>     > are
>     >     >     integrity protection, the BFCP client MUST be 
> authenticated.
>     >     > Section 14
>     >     >     that BFCP-websocket must use at least as strong 
> protections
>     > as the
>     >     >     signaling channel.
>     >     conference is authenticated and confidentiality and 
> integrity
>     > protected,
>     >     Secure WebSocket (WSS) MUST be used, and the floor control 
> server
>     > MUST
>     >     >     the draft to describe how that change impacts the 
> security
>     >     > analysis in
>     >     > 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]
>     >     >
>     >     > Secure WebSocket (WSS) only. As with any other web 
> connection,
>     > the
>     >     > over WSS only. As described in Section 10.5 of [RFC6455] 
> the
>     > floor
>     >     > Attackers may attempt to modify messages exchanged by a 
> client
>     > and a
>     >     >    having floor control servers check that messages 
> arriving
>     > over a
>     >     > 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?
>     >     >    to confidential information between the floor control 
> server
>     > and a
>     >     > level provided when WSS is used is limited to the 
> underlying TLS
>     >     > algorithm used by WebSocket library.”
>     >     >
>     >     >
>     >