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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Sep 2016 15:31:40 +0200

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Sep 2016 16:22:18 +0200

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

-- 

Magnus Westerlund