[secdir] review of draft-ietf-httpbis-p7-auth-20

Stephen Kent <kent@bbn.com> Fri, 24 August 2012 05:42 UTC

Return-Path: <kent@bbn.com>
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 195DA21F847C for <secdir@ietfa.amsl.com>; Thu, 23 Aug 2012 22:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.521
X-Spam-Level:
X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Jtyau4WH8r9 for <secdir@ietfa.amsl.com>; Thu, 23 Aug 2012 22:42:27 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 14ACD21F847A for <secdir@ietf.org>; Thu, 23 Aug 2012 22:42:27 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:48681 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1T4mf2-000Ig7-RW for secdir@ietf.org; Fri, 24 Aug 2012 01:42:25 -0400
Message-ID: <503709BF.1080307@bbn.com>
Date: Fri, 24 Aug 2012 00:57:35 -0400
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: secdir <secdir@ietf.org>
References: <alpine.BSF.2.00.1208211110450.74244@fledge.watson.org>
In-Reply-To: <alpine.BSF.2.00.1208211110450.74244@fledge.watson.org>
Content-Type: multipart/alternative; boundary="------------070800090302070005010305"
Subject: [secdir] review of draft-ietf-httpbis-p7-auth-20
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: Fri, 24 Aug 2012 05:42:29 -0000

I reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.These 
comments were written primarily for the benefit of the security area 
directors.Document editors and WG chairs should treat these comments 
just like any other last call comments.

This is a fairly brief document: 18 pages including appendices. The 
Abstract says that this document "...defines the HTTP Authentication 
framework" but the Introduction expands the description, saying that it 
" describes HTTP/1.1 access control and authentication." I suggest the 
introduction be changed to match the abstract, especially since the 
principal focus of the document is authentication. There are several 
places where the term "authorization" is used. In many contexts, this 
term is a synonym for access control. However, in this context it seems 
to be used almost interchangeably with "authentication" in most places. 
I suspect the terminology choice arises for historical reasons, but it 
might be helpful to explicitly note this, where applicable.

The introduction says that it includes "the relevant parts of RFC 2616 
with only minor changes ([RFC2616]), plus the general framework for HTTP 
authentication, as previously defined in "HTTP Authentication: Basic and 
Digest Access Authentication" ([RFC2617])." The document updates RFC 
2617, and obsoletes RFC 2616. It includes an appendix that describes the 
differences between this document and (the relevant portions) of 2616 
and 2617.

I'm not sure whether the use of lowercase "ought" in four places in 
Section 2.3.1 is intended to express a new level of IETF standards 
compliance, perhaps filling the gap between MAY and SHOULD ;-) .

I like the fact that the Security Considerations section addresses 
implementation issues, since the document, overall, addresses security. 
Only two topics are discussed here, but both seem relevant. I am 
surprised that there is no mention of using HTTPS, to protect the most 
commonly used credentials, i.e., passwords.