Re: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24

Julian Reschke <julian.reschke@gmx.de> Wed, 30 October 2013 13:41 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 8E35021F9E99 for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 06:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.958
X-Spam-Level:
X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-1.359, 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 Y1lg1sfFPj1o for <secdir@ietfa.amsl.com>; Wed, 30 Oct 2013 06:41:02 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6421F9928 for <secdir@ietf.org>; Wed, 30 Oct 2013 06:40:52 -0700 (PDT)
Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LpsmR-1W7qHr2zJP-00ffoL for <secdir@ietf.org>; Wed, 30 Oct 2013 14:40:47 +0100
Message-ID: <52710C5A.9040705@gmx.de>
Date: Wed, 30 Oct 2013 14:40:42 +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: Stephen Kent <kent@bbn.com>, secdir <secdir@ietf.org>, fielding@gbiv.com, mnot@pobox.com, Barry Leiba <barryleiba@computer.org>, Pete Resnick <presnick@qti.qualcomm.com>, "Mankin, Allison" <amankin@verisign.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <52700DE4.8020208@bbn.com>
In-Reply-To: <52700DE4.8020208@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:WBN8v9K3gQS+fmtN0TAj06+D1HRI1gDPAW/AdgbtQaErN8pV2c2 MhA4pzZlzsOkVbYBKpxlXu3/hMNaasuzE/cyDdhsOA5jYz1xulQ8FO1C1V9fUnmh0nvzO0L fWkUFhmBwUiBZxbXeOMB9GBtQFx7W8HVOxpwBg+eNHeLRXS+CKVq55xnSGLRishDTBvVKa/ vfuYFWFs2hkSEldGamZuA==
Subject: Re: [secdir] 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: Wed, 30 Oct 2013 13:41:07 -0000

Stephen,

On 2013-10-29 20:35, Stephen Kent wrote:
> ...
> The Security Considerations section (6) is about one page in length. It
> references the SC sections in two in I-Ds:
> draft-ietf-httpbis-p1-messaging-24 and
> draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial
> SC sections, but one cannot say that this document has an acceptable SC
> section until those documents are finalized. They are both normative
> references, so this doc will nor progress independently, but there will
> still be a need to revisit this SC when those SCs are finalized.

These two other documents are in IETF LC as well.

> The SC section here addresses only two issues: purging credentials in
> clients and user agents, and protection spaces. The discussion of the
> former topic does not discuss how credential purging applies to proxies.

As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a 
program that establishes a connection to a server for the purpose of 
sending one or more HTTP requests.' -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.2.1>). 
Does this address your comment?

> Also, it is not clear that a user control for credential purging will
> have the desired effect given a potentially complex GUI environment. The

Any proposal for enhancing the text?

> discussion of protection spaces provides useful suggestions on how to
> minimize credential exposure.
>
> I was a bit surprised that there was no advice deprecating the use of
> passwords as credentials, if only to make a statement on this topic.

This document just defines the HTTP authentication framework. It's not 
intended to give general guidelines about the security of new 
authentication schemes. But then, if you have some concrete proposal for 
additional text, we're all ears.

Best regards, Julian