Re: [bfcpbis] Kathleen Moriarty's No Objection on draft-ietf-bfcpbis-bfcp-websocket-14: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

Thank you, Ram.

On Mon, Jan 30, 2017 at 11:42 AM, Ram Mohan R (rmohanr)
<[e-mail]> wrote:
> HI Kathleen,
>
> I will add the text “as an example” to the sentence.
>
> Thanks,
> Ram
>
> -----Original Message-----
> From: Kathleen Moriarty <[e-mail]>
> Date: Monday, 30 January 2017 at 9:54 PM
> To: "Ram Mohan R (rmohanr)" <[e-mail]>
> Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "Charles Eckel (eckelcu)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: Kathleen Moriarty's No Objection on draft-ietf-bfcpbis-bfcp-websocket-14: (with COMMENT)
>
>     Hi Ram,
>
>     On Mon, Jan 30, 2017 at 10:12 AM, Ram Mohan R (rmohanr)
>     <[e-mail]> wrote:
>     > Hi Kathleen,
>     >
>     > Please see inline
>     >
>     > -----Original Message-----
>     > From: Kathleen Moriarty <[e-mail]>
>     > Date: Thursday, 19 January 2017 at 1: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: Kathleen Moriarty's No Objection on draft-ietf-bfcpbis-bfcp-websocket-14: (with 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 1:10 AM
>     >
>     >     Kathleen Moriarty has entered the following ballot position for
>     >     draft-ietf-bfcpbis-bfcp-websocket-14: No Objection
>     >
>     >     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/
>     >
>     >
>     >
>     >     ----------------------------------------------------------------------
>     >     COMMENT:
>     >     ----------------------------------------------------------------------
>     >
>     >     I agree with Alexey's comment on section 8.  If fallback to HTTP
>     >     authentication happens, the implementer should be aware of the weaknesses
>     >     in HTTP basic [RFC7617] and digest [RFC7616] spelled out in the
>     >     respective security considerations sections.  The HTTPAuth WG put out a
>     >     few experimental RFCs with methods to eliminate some of the weaknesses,
>     >     like HOBA [RFC7486] that gets rid of the need for passwords.  Adding this
>     >     detail would be helpful.
>     >
>     > <Ram> Does this text looks ok ?
>     >
>     > EXISTING:
>     >          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.
>     > 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 can use HTTP Origin-Bound Authentication (HOBA)
>     >         mechanism mentioned in [RFC7486].
>
>     This looks good, but HOBA is just one of 3 experimental options to
>     improve HTTPAuth.  SCRAM, RFC7804, is one of the other options, then
>     the third is in 3 RFCs that are int he RFC editor queue.  You could
>     list one as an example or maybe add in SCRAM too.
>
>     Thank you,
>     Kathleen
>     >
>     >
>     >
>     >
>
>
>
>     --
>
>     Best regards,
>     Kathleen
>
>



-- 

Best regards,
Kathleen