Re: [MMUSIC] RTSP 2.0: Updating HTTP Authentication to RFC7235, RFC7616, and RFC7617

[Magnus Westerlund <[e-mail]>]

Hi,

I have implemented this in the specification text after having reviewed 
the new specifications in detail.

So this means that SHA2-256 is the mandatory hashing algorithm, rather 
than MD5. As RTSP 2.0 already requires support of SHA2-256 the extra 
implementation impact is minimal.

I have also chosen to attempt to point even more on the new RFCs 7235, 
7615, 7616, and 7617. This includes also the ABNF of the field values. 
This is so that RTSP 2.0 will use HTTP authentication as defined, and 
not its own variant.

Cheers

Magnus


Den 2016-09-13 kl. 15:31, skrev Magnus Westerlund:
> WG,
>
> In the Authors48 review of
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ I have
> come to look at the authentication mechanisms used in RTSP 2.0. These
> are basically the HTTP mechanism with some clarifications that are based
> on the ones for SIP.
>
> The draft that was approved by IESG more than 2 years ago pointed to RFC
> 2617. However, since then the updated HTTP specification has been
> approved RFC7230 to RFC7235. So part of preparation for publication we
> have updated references to the current specifications.
>
> This has had relative minor impact as all the headers etc are copied and
> authoritatively specified in the RTSP specification. Then there are
> security considerations that are referencing issues and threats and
> remedies that are generally applicable in the new specification. This
> required some work, and even leaving some references to the obsolete one
> as the new one lacks corresponding text. However, this is not protocol
> specifications.
>
> However, the references to RFC2617 they are however protocol details.
> RFC2617 has been changed to consist of a framework document (RFC7235)
> and the basic (RFC7617) and digest (RFC7616) authentication schemes.
> This will have impact on the actual protocol implementations.
>
> To give you some understanding of what has changed I have below included
> the three RFCs changes section. I think using the latest version rather
> than pointing to the obsoleted versions will mean an improvement in
> clarity, and also modern algorithms. I note that the RTSP 2.0
> specification already mandates support of SHA-256 in the
> Accept-Credentials header.
>
> However, if someone has concerns over these changes, please raise them now.
>
> RFC 7235:
> Appendix A.  Changes from RFCs 2616 and 2617
>
>    The framework for HTTP Authentication is now defined by this
>    document, rather than RFC 2617.
>
>    The "realm" parameter is no longer always required on challenges;
>    consequently, the ABNF allows challenges without any auth parameters.
>    (Section 2)
>
>    The "token68" alternative to auth-param lists has been added for
>    consistency with legacy authentication schemes such as "Basic".
>    (Section 2)
>
>    This specification introduces the Authentication Scheme Registry,
>    along with considerations for new authentication schemes.
>    (Section 5.1)
>
>
> RFC 7616:
> Appendix A.  Changes from RFC 2617
>
>    This document introduces the following changes:
>
>    o  Adds support for two new algorithms, SHA2-256 as mandatory and
>       SHA2-512/256 as a backup, and defines the proper algorithm
>       negotiation.  The document keeps the MD5 algorithm support but
>       only for backward compatibility.
>
>    o  Introduces the username hashing capability and the parameter
>       associated with that, mainly for privacy reasons.
>
>    o  Adds various internationalization considerations that impact the
>       A1 calculation and username and password encoding.
>
>    o  Introduces a new IANA registry, "Hash Algorithms for HTTP Digest
>       Authentication", that lists the hash algorithms that can be used
>       in HTTP Digest Authentication.
>
>    o  Deprecates backward compatibility with RFC 2069.
>
>
> RFC 7617:
> Appendix A.  Changes from RFC 2617
>
>    The scheme definition has been rewritten to be consistent with newer
>    specifications such as [RFC7235].
>
>    The new authentication parameter 'charset' has been added.  It is
>    purely advisory, so existing implementations do not need to change,
>    unless they want to take advantage of the additional information that
>    previously wasn't available.
>


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------