[secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
Donald Eastlake <d3e3e3@gmail.com> Sun, 28 December 2014 20:51 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348361A9139; Sun, 28 Dec 2014 12:51:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Y83jX3Ee8TdY; Sun, 28 Dec 2014 12:51:09 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8748D1A9134; Sun, 28 Dec 2014 12:51:09 -0800 (PST)
Received: by mail-oi0-f48.google.com with SMTP id u20so27121913oif.7; Sun, 28 Dec 2014 12:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=vxG2+O81fBneq+4e0uvdH8/Q/1Np9h47H1IulFTJaV4=; b=M5iDv9ZBmJ6mEM6jOG0Uz3EH2pVBr6c5mqkN7oRy/5OO53RzxR8Pynowyg96tB93ul E2O16Z9lhg5O7zyIf+Q0uXQKNBNp2I6eZxfyWNLqkSvh+6EcH5GSqKwQ4+Wuu/VW2I7z jz0bvaZ5QmfKoHanV70oKmyzE7ic/DVZNmP7WvowaO56ns/hYTHx5DpLMiR8S06YQq6f +eNPIFHFyL0RjQd8daoiWNAt8/5TGTz5fGYMnRrizeXfjMwZYxA4ETnruybMR08OZSQy 9kndHZETzfjY+y0NpTMc9xpFpi5zKXZ1+ej0Zc+JFi36q1ZUQOggVgqN/AezcTrvalXF 8dYg==
X-Received: by 10.202.170.74 with SMTP id t71mr28841632oie.73.1419799868774; Sun, 28 Dec 2014 12:51:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.104.104 with HTTP; Sun, 28 Dec 2014 12:50:48 -0800 (PST)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 28 Dec 2014 15:50:48 -0500
Message-ID: <CAF4+nEH3qmXQRg1B2F+uD4iwO8KQijzUTsJKb=u9TR5tEaAjSQ@mail.gmail.com>
To: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-httpauth-hoba.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/6q454ExkX0Pl6P9aw1YMENusuEg
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 28 Dec 2014 20:51:11 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies an Experimental protocol to use digital signatures in response to challenges for authentication to HTTP servers as a replacement for passwords. There are a lot more details than that and considerable effort has been put into making this fit into existing web authentication so as to be easily deployable. Overall, it looks like a good job. See comments below. As a heavily security oriented draft, I recommend it be looked at by the non-author Security AD :-) > Security Comments < --------------------- This draft is fairly clear about what happens when mandatory 2119 requirements are violated in strictly security contexts, such as a signature not validating. But is generally doesn't say much about what happens when mandatory formatting requirements are violated. I guess if things don't parse, then authentication will fail. But, for example, it says "The "realm" attribute MUST NOT appear more than once." Whenever I see something like that, I say to myself, OK, so what happens if the "MUST NOT" is violated? If the spec says nothing, then I would expect that with some implementations authentication would fail while others would use the first realm attribute and still others would use the last realm attribute. Could that be a problem? This draft uses "random" and "randomness" in various places without any reference/definition. Security Considerations: Perhaps there should be a reference in the Security Considerations section to Section 1.1. Can some level of confusion/denial be caused by setting max-age to a lower value than the server intended? Appendix B: It is good that an example is provided it seems like some things are missing. Shouldn't it specify the "alg" string and wouldn't it be useful if it gave the TBS blob explicitly? > Wording/Format Comments < --------------------------- Abstract: I always worry about words like "all" (or, being recursive to this sentence, "always" :-). I suggest deleting the one occurrence of "all" in the Abstract. Page 5, Section 1.2 OLD That will contain of at least one CPK and a web-origin; ^^ NEW That will contain at least one CPK and a web-origin; Page 6/7/13, Figure 1/2/3: I'm not sure that something that is entirely textural is best called a "Figure". But in any case, since the text is, or at least has, lines that are flush left, it looks like part of the preceding text and there isn't a clear demarcation of the start. I recommend that the body of the Figures be indented 3 or 4 spaces. Page 6, Section 2: - For "alg" inconsistently says it is "an ASCII character" and "ASCII numbers" where perhaps it should say "an ASCII encoded one or two digit non-negative integer" or something. - For "origin" perhaps the example should note that it would be prefixed by "28:" in the TBS blob. - Delete one of the two sequential occurrences of "reduce the amount of". Page 10, Section 5: I suggest rewording this sentence: OLD This section also covers the actions that give HOBA similar user features as today's passwords have. NEW This section also covers the actions that give HOBA user features similar to today's passwords. Page 16, Section 6.4: duplicated word "response". Page 18, Section 8.2: Is it a good idea to mention a particular on-line service name here? Page 19, IANA Considerations: It seems from draft-leiba-coton-iana-5226bis that IANA would prefer IANA Considerations to be written in the past tense as if the actions had already been accomplished, presumably to minimize IANA re-writing effort. Thus, I suggest that consideration be given to changing the initial part, between the Section 9 heading and the Section 9.1 heading, to the following and making similar changes in the remainder of the IANA Considerations Section: IANA has created the registries and made the registration specified below, placing the new registries in a new "HTTP Origin-Bound Authentication (HOBA) Parameters" category. Page 20, Section 9.3: A better way to note the restriction on potential values of Algorithm Name would be to add a third entry to the registry something like the following (there should also be a third Reference column): 2-99 Unassigned [this document] Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted UTF8 string". There should probably be a Reference column. "a small positive integer" is undefined. Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm not sure it needs "at the user's/UA's whim". There should also be a "[this document]" entry in a Reference column. Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid" and "did" are ordinary English words, suggest globally replacing them with "KID" and "DID" respectively. Page 24, Appendix A This is a nice appendix but there is no reference to it anywhere in the body of the draft. Suggest adding such a reference to the Introduction. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
- [secdir] SECDIR review of draft-ietf-httpauth-hob… Donald Eastlake
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Barry Leiba
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Stephen Farrell
- Re: [secdir] SECDIR review of draft-ietf-httpauth… Kathleen Moriarty