[Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08
"Black, David" <david.black@emc.com> Sat, 27 December 2014 03:16 UTC
Return-Path: <david.black@emc.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD781A1B43; Fri, 26 Dec 2014 19:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NuqB4lc0j1pq; Fri, 26 Dec 2014 19:16:10 -0800 (PST)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACF91A1B21; Fri, 26 Dec 2014 19:16:09 -0800 (PST)
Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR3G5KK009684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2014 22:16:05 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBR3G5KK009684
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1419650166; bh=8lKZs4pzLTAEBmH5vBVEgwsFQd0=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OlcpX7G6EkYh4HRUgOqfQ0Jc/X+xlnshothzGiW2GMjq3LByibE/IbH6o8ylNgtAH 4MeyKkM5XAhHbYeA6jSubVYbZJXAYgCDkLuh66KO0rZ41UEF6K63CLMaqWYRXjx4IX bgVpd8+MX/HTZVlTMnInmwPc2iJqWj8Z1sFvqyzw=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com sBR3G5KK009684
Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 26 Dec 2014 22:14:49 -0500
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id sBR3Fu7e012210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Dec 2014 22:15:56 -0500
Received: from MXHUB204.corp.emc.com (10.253.68.30) by mxhub24.corp.emc.com (128.222.70.136) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 26 Dec 2014 22:15:55 -0500
Received: from MX104CL02.corp.emc.com ([169.254.8.208]) by MXHUB204.corp.emc.com ([10.253.68.30]) with mapi id 14.03.0195.001; Fri, 26 Dec 2014 22:15:55 -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>
Thread-Topic: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08
Thread-Index: AdAhg2z9pL2pKktfRKq2qd7TNjhE1g==
Date: Sat, 27 Dec 2014 03:15:55 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362CDC75@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.251.42.79]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com
X-RSA-Classifications: DLM_1, public
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/aBU3dSIePEaHCPcD9QpPphWSRf4
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Dec 2014 03:16:14 -0000
The -08 draft addresses all of the important issues in the combined Gen-ART and OPS-Dir review of the -07 version, and is a definite improvement over its -07 version. Based on discussion of item [5], there are a couple of remaining editorial nits in Section 5.3: During the authentication phase, if the server cannot determine the correct CPK, it could use HTML and JavaScript to ask the user if they are really a new user or want to associate this new CPK with another CPK. The server can then use some out-of-band method (such as a "can" -> "should" confirmation email round trip, SMS, or an UA that is already enrolled) to verify that the "new" user is the same as the already- enrolled one. Thus, logging in on a new user agent is identical to logging in with an existing account. If the server does not recognize the CPK the server might send the client through a either a join or login-new-UA (see below) process. "might" -> "should" I agree w/the draft editor that these are matters of editorial taste. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, December 15, 2014 6:25 PM > To: stephen.farrell@cs.tcd.ie; paul.hoffman@vpnc.org; mike@phresheez.com; > General Area Review Team (gen-art@ietf.org); ops-dir@ietf.org > Cc: ietf@ietf.org; http-auth@ietf.org; Black, David > Subject: Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07 > > 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 15, 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 > ----------------------------------------------------
- [Gen-art] Gen-ART and OPS-Dir review of draft-iet… Black, David
- Re: [Gen-art] [http-auth] Gen-ART and OPS-Dir rev… Julian Reschke
- Re: [Gen-art] [http-auth] Gen-ART and OPS-Dir rev… Black, David
- Re: [Gen-art] Gen-ART and OPS-Dir review of draft… Jari Arkko