Re: [secdir] additional mechanisms on top of the auth framework, was: SECDIR review of draft-ietf-httpbis-p7-auth-24

Julian Reschke <julian.reschke@gmx.de> Thu, 31 October 2013 15:18 UTC

Return-Path: <julian.reschke@gmx.de>
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 7D54311E8171 for <secdir@ietfa.amsl.com>; Thu, 31 Oct 2013 08:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.233
X-Spam-Level:
X-Spam-Status: No, score=-104.233 tagged_above=-999 required=5 tests=[AWL=-1.634, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 iCNAh7s4jBmb for <secdir@ietfa.amsl.com>; Thu, 31 Oct 2013 08:18:02 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5BABA11E8221 for <secdir@ietf.org>; Thu, 31 Oct 2013 08:18:02 -0700 (PDT)
Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDFB2-1VRxJM2oto-00GcRD for <secdir@ietf.org>; Thu, 31 Oct 2013 16:18:01 +0100
Message-ID: <527274A5.9030009@gmx.de>
Date: Thu, 31 Oct 2013 16:17:57 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>, Julian Reschke <julian.reschke@greenbytes.de>
References: <52700DE4.8020208@bbn.com> <52726125.1000802@greenbytes.de> <omq479p5tt306gress6en7thrh06lr1ge6@hive.bjoern.hoehrmann.de> <52726DD8.8080800@greenbytes.de> <hkr4791jflgr33g5gosabbd1d1jfrsor21@hive.bjoern.hoehrmann.de>
In-Reply-To: <hkr4791jflgr33g5gosabbd1d1jfrsor21@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:1S5960Sv8BOzgl+fTf3NrDTVVxIwG7EH4MoSYKbra/v2FpQCZ70 PsII/5rNbxxCLB4Lxni1wihrpOakSjS39OzAofZrGszYyvDM2D8/V+I0SZNiVHPzJ1X395V sm4E+2VPelGaPNQbOzU/V+fDilbI4C/7PjPoH2WcpwfvdaIPOuVb0ExDucVsnFxiFv+tJUG JiRIE6WEBh0TQJK4be0gA==
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:18:08 -0000

On 2013-10-31 16:05, Bjoern Hoehrmann wrote:
> * 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".)

"HTTP does not restrict applications to this simple challenge-response 
framework for access authentication. Additional mechanisms can 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."

WFM.

>> 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

Indeed.

> 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.

Maybe. Text welcome :-)

Best regards, Julian