Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
"Black, David" <david.black@emc.com> Mon, 15 December 2014 23:25 UTC
Return-Path: <david.black@emc.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790571A88C6; Mon, 15 Dec 2014 15:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level:
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5fKewM0csS49; Mon, 15 Dec 2014 15:25:48 -0800 (PST)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC981A8AFC; Mon, 15 Dec 2014 15:25:46 -0800 (PST)
Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNPXmq022819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 18:25:34 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBFNPXmq022819
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1418685936; bh=pSUKlt9Rp0eAuOB7Nm14ZNfxExk=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IWdD9ekU1PZAcMyez2yH3uT+uUjKttjJ84s3MX3DduIyCfM1tes7n4gT8jQ2RmD3u n6V2OYTkb8JVZOIiG8YKxQJfj9cfD7QlNdRnWLA4dI7BaAJ6ToSgJzT9HZ7SoazvNn 6OfNz8yubx7+/Tb128kQ8HOPb60NPCa+OT2mLR6g=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com sBFNPXmq022819
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 15 Dec 2014 18:25:11 -0500
Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.222.70.134]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBFNPG4W013039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Dec 2014 18:25:17 -0500
Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub22.corp.emc.com (128.222.70.134) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 15 Dec 2014 18:25:16 -0500
Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 18:25:16 -0500
From: "Black, David" <david.black@emc.com>
To: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "paul.hoffman@vpnc.org" <paul.hoffman@vpnc.org>, "mike@phresheez.com" <mike@phresheez.com>, "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07
Thread-Index: AdAYvlv0aser5OsbSxuh2NmwD9vCCw==
Date: Mon, 15 Dec 2014 23:25:14 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362C160A@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.122]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: DLM_1, public
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/-HY6-Ot8DujNBmYPiZH2wDErnUo
Cc: "Black, David" <david.black@emc.com>, "http-auth@ietf.org" <http-auth@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 23:25:51 -0000
This is a combined Gen-ART and OPS-Dir review. Boilerplate for both follows ... I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at: <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-httpauth-hoba-07 Reviewer: David Black Review Date: Dec XX, 2014 IETF LC End Date: Dec 24, 2014 Summary: This draft is on the right track, but has open issues described in the review. This draft specifies a signature-based authentication mechanism for HTTP that is based on asymmetric (public-private) key pairs without using certificates. A different key pair is used by each user for each for each host ("web-origin", see [RFC6454]), and each signature is based on a server-generated challenge. The draft is generally well-written and clear on the authentication mechanics, but has weaknesses in specifying the environment that surrounds use of this mechanism. Some of these issues are basic things that anyone working on web technology or applied crypto "just knows", but even the obvious needs to be stated when it's integral to security. -- Major issues: -- [1] Challenge size and predictability In the ABNF: challenge = 1*base64urlchars I did not see any other discussion of minimum length of challenge or amount of entropy in the challenge. For the latter, do the challenges need to be unpredictable? I would think so. I think a requirement on minimum challenge size and a recommendation on minimum amount of entropy would be good ideas. [2] Challenge verification and reuse This sentence on p.6 strikes me as subtly dangerous: The challenge however is sent over the network so as to make it simpler for a server to be stateless. (One form of stateless challenge might be a ciphertext that the server decrypts and checks, but that is an implementation detail.) The draft elsewhere asserts or assumes that challenge reuse can be prevented by the server or be time-bounded by max-age, and relies on those reuse limits for security properties, e.g., as in this sentence near the end of Section 6.1: Note that replay of registration (and other HOBA) messages is quite possible. That however can be counteracted if challenge freshness is ensured. The sentence quoted from p.6 appears to allow (or even encourage) stateless servers to implement rather weak checks on not only challenge reuse, but also challenge validity (e.g., what if the challenge validity test were "challenge mod 1024 == 7" ?). Allowing such weak checks could enable an attacker to choose or influence the choice of challenge values, which could be useful (e.g., for differential cryptanalysis attack on the hash function), as the attacker (client) already controls the nonce. As part of this, the server needs to check whether a challenge presented on one connection or session has been reused on another. I think the following sentence in section 3 is intended to prevent this, but it's weakened by the "stateless" language above: The challenge MUST be unique for every HTTP 401 response in order to prevent replay attacks from passive observers. Explicit server checks for challenge reuse ought to be REQUIRED, and the above use of "stateless" needs to be qualified. [3] Web origin checks I did not see text mandating that TLS (server certificate), HTTP (accessed URL) and HOBA (signature input) use the same web origin, and stating that the server has to check/enforce this. Did I miss something? I realize that this is an obvious requirement, but it does need to be stated. [4] TLS requirement level TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement - first paragraph in Section 8.1 (Privacy Considerations). If TLS is not a "MUST" requirement, at least a discussion of man-in-the- middle (MITM) attacks seems to be in order. There's no need for an extensive discussion of all of the security properties of TLS, but MITM attacks are definitely worth a mention, and that could be complemented by a pointer to suitable HTTP/TLS security considerations text elsewhere. [5] Section 5.3 - unrecognized key Paragraphs 4 and 5 in this section don't seem to belong here, and appear to be written in a somewhat loose fashion, particularly around user verification. A server that does what is suggested here could have significant security weaknesses. I strongly recommend replacing those two paragraphs with a short sentence that says: - if a kid is unrecognized or the server otherwise determines that the CPK is not to be used for this HTTP authentication, - then the Registration (see 6.1) and/or Associating Additional Keys to an Exiting Account (see 6.2) processes MAY be used instead of treating this situation as an authentication failure. and moving all discussion of user verification into Sections 6.1 and 6.2. -- Minor issues: -- [A] ABNF encoding of alg In section 2, I see: alg = 1*2DIGIT o alg: specifies the signature algorithm being used encoded as an ASCII character as defined in Section 9.3. Section 9.3 specifies a single digit. How does that become 1*2DIGIT ? I suggest: "as an ASCII character" -> "as one or two ASCII digits based on the IANA registry established by Section 9.3" This may seem like a nit, but any imprecision in signature algorithm input can lead to interoperability problems. [B] Section 5.3 - CPK vs. kid In the authentication phase, the server extracts the CPK from the signing phase and decides if it recognizes the CPK. If the server recognizes the CPK, the server may finish the client authentication process. That seems wrong. IIUC, the HOBA client sends: HOBA-RES = kid "." challenge "." nonce "." sig If so, I don't understand how the server extracts a CPK from that. I suspect that what was intended is that the server extracts a key identifier (kid) and then determines a) whether it knows a CPK for that kid and b) whether it allows use of that kid/CPK for this authentication. At least a) seems to be indicated by this text in Section 3: The server MUST check the cryptographic correctness of the signature based on a public key it knows for the kid in the signatures, [C] RSA signature algorithm Section 7 says: RSA is defined in Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS]. Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5. At a minimum, that algorithm name should be stated here (which is a nit). The minor issue is whether that is the signature algorithm that's wanted, on which I'll defer to the crypto experts on that (e.g., I seem to recall a negative saag comment on PKCS 1.5 mechanisms in the past couple of months). [D] Javascript local storage. The first paragraph of Section 8.2 on this topic concludes with: It's not clear that we introduce unique threats from which clear text passwords don't already suffer. That's at odds with the use of "all" in this sentence in the abstract: HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. One of those two paragraphs needs some editing. -- Nits/editorial comments: -- This is buried near the end of section 6.1 Note that replay of registration (and other HOBA) messages is quite possible. That however can be counteracted if challenge freshness is ensured. That's not a good place for these two sentences. HOBA registration messages don't contain a challenge, and the general discussion of replay attacks belongs under Security Considerations, not Registration. In Section 9.4 and 9.5, I see the following proposed as part of IANA registry contents: an unformatted string, at the user's/UA's whim I get the point, but it's still not appropriate for an IANA registry - remove ", at the user's/UA's whim". Appendix A appears to assume that human-memorable passwords are stored in the clear in server databases. It should also briefly discuss the use of one-way functions, especially computationally intensive ones, to generate stored password verifiers. HOBA is still superior by comparison, as the one-way functions only increase the difficulty of dictionary attack, whereas dictionary attack on HOBA keys is pointless when sufficiently large keys are used. idnits 2.13.01 found the references to W3C's web site (www.w3.org) in Section 4, e.g., 389 One element is required for HOBA-js: localStorage (see http:// 390 www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key 391 storage. I think idnits can be ignored, even though the "right way" to fix this is to move each URL to a reference and cite the reference in Section 4. OTOH, idnits did not complain about the normative reference to RFC 20 ;-). --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- Most of these questions are n/a because this draft describes an extension to HTTP authentication, and RFC 5706's concerns would apply primarily to HTTP and HTTP authentication. A.1.1 Has deployment been discussed? Yes, section 6 discusses how a user would deploy this for her access to web servers. A.1.4. Have the Requirements on other protocols and functional components been discussed? Yes, the discussion of how this functions within HTTP is sufficient. Major issues [3] and [4] fall into this category, but in both cases, I think they're probably text oversights that are easy to fix. A.2.7 Is security management discussed? Not really, but this is an Experimental RFC. I would expect that the experimental use of HOBA will yield insight into server key database structure/management, key lifecycle management (e.g., revocation), account management techniques/processes, etc. A.3. Documentation I do not expect significant operational impact. Section 10 notes the existence of two implementations of HOBA-JS and one implementation of HOBA-http. That's a good start for an experiment. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------
- RE: Gen-ART and OPS-Dir review of draft-ietf-http… Black, David
- Gen-ART and OPS-Dir review of draft-ietf-httpauth… Black, David
- Re: Gen-ART and OPS-Dir review of draft-ietf-http… Stephen Farrell
- RE: Gen-ART and OPS-Dir review of draft-ietf-http… Black, David
- Re: Gen-ART and OPS-Dir review of draft-ietf-http… Stephen Farrell
- RE: Gen-ART and OPS-Dir review of draft-ietf-http… Black, David
- Re: Gen-ART and OPS-Dir review of draft-ietf-http… Stephen Farrell