[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 ----------------------------------------------------------------------
- [MMUSIC] RTSP 2.0: Updating HTTP Authentication t… Magnus Westerlund
- Re: [MMUSIC] RTSP 2.0: Updating HTTP Authenticati… Magnus Westerlund