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

[Kathleen Moriarty <[e-mail]>]

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