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

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 13 September 2016 13:57 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA5E12B669 for <mmusic@ietfa.amsl.com>; Tue, 13 Sep 2016 06:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHAsOP1Px-Cj for <mmusic@ietfa.amsl.com>; Tue, 13 Sep 2016 06:57:47 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DDB12B67E for <mmusic@ietf.org>; Tue, 13 Sep 2016 06:31:45 -0700 (PDT)
X-AuditID: c1b4fb25-14bff7000000793b-6f-57d7ffbeda84
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id E8.A5.31035.EBFF7D75; Tue, 13 Sep 2016 15:31:44 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.301.0; Tue, 13 Sep 2016 15:31:42 +0200
To: "mmusic (E-mail)" <mmusic@ietf.org>, "draft-ietf-mmusic-rfc2326bis@tools.ietf.org" <draft-ietf-mmusic-rfc2326bis@tools.ietf.org>, Alissa Cooper <alissa@cooperw.in>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <63711049-a3e7-4e62-4bb4-f59560d07296@ericsson.com>
Date: Tue, 13 Sep 2016 15:31:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM2K7iu6B/9fDDd4uULKYfuYvo8W13VOY LKYuf8ziwOzx5clLJo8lS34yeXy5/JktgDmKyyYlNSezLLVI3y6BK+PNq7+sBbsVKiZ/PcHa wHhZsouRk0NCwERizeo7bF2MXBxCAusZJZZv/8EK4SxnlNh3bgYjiCMisJZR4tPWtWwgLWwC FhI3fzSC2cICQRL/m3awg9i8AvYSvb+mM4PYLAKqEuu+/QFq5uAQFYiRWN+XAFEiKHFy5hMW kDAzUPmDrWUgYWYBeYnmrbPBOoUEtCUamjpYJzDyzkLSMQuhYxaSjgWMzKsYRYtTi5Ny042M 9VKLMpOLi/Pz9PJSSzYxAgPs4JbfqjsYL79xPMQowMGoxMP7YMu1cCHWxLLiytxDjBIczEoi vCn/rocL8aYkVlalFuXHF5XmpBYfYpTmYFES5/13FiglkJ5YkpqdmlqQWgSTZeLglGpgNJ0k Gi59+eRNzY8n5j2RuK6RlvFU7/OLyzrNs3/md9sx2rV96mwqKHr7Tmn2DtsMo7eJnVbnzTre 75+rPflx73WPmhd/9x26WLKitTxVMFQw0Osyl96JkjV+oj33+Thb7TXM5/FsWtJaf+mh44Xy t8yFgfNkTU2tQ828Sq//9Jnrfjvq5veNSizFGYmGWsxFxYkAgpKYNSwCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oBBJhmDvlm5xM8jHNFjYjv01XOE>
Subject: [MMUSIC] RTSP 2.0: Updating HTTP Authentication to RFC7235, RFC7616, and RFC7617
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 13:57:52 -0000

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------