Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24
Bjoern Hoehrmann <derhoermi@gmx.net> Thu, 31 October 2013 15:05 UTC
Return-Path: <derhoermi@gmx.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 0BBCA21E80DA for <secdir@ietfa.amsl.com>;
Thu, 31 Oct 2013 08:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.742
X-Spam-Level:
X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143,
BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJN8P5dvbOMO for
<secdir@ietfa.amsl.com>; Thu, 31 Oct 2013 08:05:31 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com
(Postfix) with ESMTP id DC91F11E8125 for <secdir@ietf.org>;
Thu, 31 Oct 2013 08:05:30 -0700 (PDT)
Received: from netb.Speedport_W_700V ([84.180.225.225]) by mail.gmx.com
(mrgmx101) with ESMTPA (Nemesis) id 0LhjeH-1VyFzF1G1x-00mpHw for
<secdir@ietf.org>; Thu, 31 Oct 2013 16:05:25 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Julian Reschke <julian.reschke@greenbytes.de>
Date: Thu, 31 Oct 2013 16:05:21 +0100
Message-ID: <hkr4791jflgr33g5gosabbd1d1jfrsor21@hive.bjoern.hoehrmann.de>
References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de>
<omq479p5tt306gress6en7thrh06lr1ge6@hive.bjoern.hoehrmann.de>
<52726DD8.8080800@greenbytes.de>
In-Reply-To: <52726DD8.8080800@greenbytes.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:BTyPCp4jE5MDT5q07dttKl2KOBKoiHupWKNPQRfNcMCZ+XW1pdr
lLnzd0qrNUqSBEmQ2n3ePMYU3CSsNsQerfQVDtRILAi8kUVQo7wGqMKObHEKp8BEO1bNo86
GfLwzGAcgZaLLZx7mTgu5oITkuLU90vkmoeoDPIGR6b5udJYHHLLKF1QdivQVK4etYJUQPR
vB3k7XWig/8xCp5UWghqg==
X-Mailman-Approved-At: Thu, 31 Oct 2013 08:15:22 -0700
Cc: secdir <secdir@ietf.org>, Pete Resnick <presnick@qti.qualcomm.com>, "Mankin,
Allison" <amankin@verisign.com>, HTTP Working Group <ietf-http-wg@w3.org>,
Barry Leiba <barryleiba@computer.org>
Subject: Re: [secdir] additional mechanisms on top of the auth framework,
was: SECDIR review of draft-ietf-httpbis-p7-auth-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>,
<mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>,
<mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2013 15:05:50 -0000
* Julian Reschke wrote: >On 2013-10-31 15:44, Bjoern Hoehrmann wrote: >> I think doing s/encryption/authentication/ instead would be better. >> There is no reason to discuss confidentiality here. Encryption and other >> cryptographic techniques are used in many authentication schemes, like >> with client certificates; that may have been the idea behind the text. > >"authentication on the transport layer"? Applying my suggestion would make the text read, The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification. (The MAY might be better as "can".) >That wouldn't cover Basic auth (plain text passwords) over https:, which >I think this paragraph is hinting at... Transport Layer Security client certificate authentication is an additional authentication mechanism at the transport level that implementations of HTTP actually use. Basic authentication is just the basic application of the challenge-response framework defined in the document, so your interpretation seems unlikely. It might be a good idea to point out that authentication does not imply confidentiality and that TLS can be used for confidentiality, but that should be in a separate paragraph. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
- [secdir] SECDIR review of draft-ietf-httpbis-p7-a… Stephen Kent
- [secdir] RFC2119 vs "ought" etc, was: SECDIR revi… Julian Reschke
- Re: [secdir] SECDIR review of draft-ietf-httpbis-… Julian Reschke
- Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR … Richard Barnes
- Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR … Julian Reschke
- Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR … Stephen Kent
- [secdir] WWW-Authenticate parsing quirks, was: SE… Julian Reschke
- Re: [secdir] SECDIR review of draft-ietf-httpbis-… Stephen Kent
- Re: [secdir] SECDIR review of draft-ietf-httpbis-… Julian Reschke
- Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR … Richard Barnes
- Re: [secdir] RFC2119 vs "ought" etc, was: SECDIR … Barry Leiba
- [secdir] Reuse of credentials per realm, was: SEC… Julian Reschke
- Re: [secdir] Reuse of credentials per realm, was:… Stephen Kent
- Re: [secdir] Reuse of credentials per realm, was:… Julian Reschke
- [secdir] proxies and forwarding of credentials, w… Julian Reschke
- [secdir] additional mechanisms on top of the auth… Julian Reschke
- Re: [secdir] Reuse of credentials per realm, was:… Stephen Kent
- Re: [secdir] additional mechanisms on top of the … Julian Reschke
- Re: [secdir] additional mechanisms on top of the … Nico Williams
- Re: [secdir] proxies and forwarding of credential… Bjoern Hoehrmann
- Re: [secdir] additional mechanisms on top of the … Bjoern Hoehrmann
- Re: [secdir] additional mechanisms on top of the … Bjoern Hoehrmann
- Re: [secdir] additional mechanisms on top of the … Stephen Kent
- Re: [secdir] additional mechanisms on top of the … Julian Reschke
- Re: [secdir] proxies and forwarding of credential… Stephen Kent
- Re: [secdir] proxies and forwarding of credential… Mark Nottingham
- Re: [secdir] additional mechanisms on top of the … Julian Reschke
- Re: [secdir] proxies and forwarding of credential… Stephen Kent