Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)
Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 13 October 2019 16:50 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF912004A; Sun, 13 Oct 2019 09:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ooqY4jvJr-wq; Sun, 13 Oct 2019 09:50:55 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B166612000F; Sun, 13 Oct 2019 09:50:54 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id a6so14785771wma.5; Sun, 13 Oct 2019 09:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=zyjTqbDYJGc/F1yxVaT2OBn7PyXF9q1u6RihIktqgaQ=; b=MDNWnr9/rCuisJ66pKBAIQIctIozd7f8tEgnVthXAnxiVIndMxZXYpqzPl7GPYucVx ie14G/BshCKWueyxXz/JzEeOTaUX+OzlwPn+bFv3EuBIcyBM+fW/c7NgGzISkNrZfA5g c39LV+R6AretmEiwQyYyDTaRQuNJeCmYTeXR/qesMB5YRiM5AJVw/CTr8M/v9D6N1yuY WjAEnPZNH2RY+4GUvkHEyLsZcriLC28sL1pKgGHiH9gt+mQOEkx46HIgPq9csWHeuWjj nOTnU6A5M0o6zHD72obAyP8VMdcKTRlxx52HXtjWczd3mDrdgRTk1T2r1AGS7nDAdSfP 4lgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=zyjTqbDYJGc/F1yxVaT2OBn7PyXF9q1u6RihIktqgaQ=; b=j/lq/bVoQXReizF1yfM6UIQi4IzNgH1V85jPnIFN6+I/lSzYYX2I+bx1RGKAqIg6v/ ucOpyeLXJ08EzF/alpPwunsYA64L4FupBtOkAZEhq1N9ie++YnOo7CkSJ4XYP5tlLaaB 0MeQP8CDnWwH6+W/Z2a5+f+x7emRpMszSgEHmwU0nbtrCaxvam8qOBxlelwaaDtpfxZA N68IvqTzaKb7z+4aFeVUKWWEqxkSFWi0yjAt7eLFPUflXvh42ezNVE9KK2C03SYotDs9 TAm8f0SiHp2/AUMik+5Fl8lLoHfnRuXRJLEi/295y1/o3K5xu1oEXzP6Rcbg6DKSKG8a XUog==
X-Gm-Message-State: APjAAAXnmMPSlwR3E8BJS6GfeqIzQQpJEKiGLFoty5Gyl80fXderDbd+ h8JrQnvB+w3Anfwtzj7vwX0=
X-Google-Smtp-Source: APXvYqzaAe6kUYpjG6PgJNP0UAP8xiAtWC5Xli3R/8BoM7ZLLP038c3nzCgQ7dPkbKSsdmC6vFOh8w==
X-Received: by 2002:a05:600c:34b:: with SMTP id u11mr11960964wmd.176.1570985453029; Sun, 13 Oct 2019 09:50:53 -0700 (PDT)
Received: from [10.0.0.147] (bzq-79-182-74-87.red.bezeqint.net. [79.182.74.87]) by smtp.gmail.com with ESMTPSA id 79sm24909290wmb.7.2019.10.13.09.50.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Oct 2019 09:50:52 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.1d.0.190908
Date: Sun, 13 Oct 2019 19:50:50 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: draft-ietf-oauth-jwt-bcp@ietf.org, Hannes Tschofenig <hannes.tschofenig@arm.com>, oauth-chairs@ietf.org, oauth@ietf.org
Message-ID: <1E4BB923-8254-4DAB-ABF2-118946077304@gmail.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)
References: <156141841569.17730.5307482163620594441.idtracker@ietfa.amsl.com>
In-Reply-To: <156141841569.17730.5307482163620594441.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/GwfBLhG5l3FULbD89HLSNKdjGtM>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Oct 2019 16:50:58 -0000
Hi Ben, Sorry the responding to you retroactively (and with such delay). As you can imagine, most of the changes in the latest version are related to your review. See below for detailed comments. Thanks, Yaron On 25/06/2019, 2:20, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-oauth-jwt-bcp-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for assembling this document; it will be very valuable to the community. I intend to ballot Yes once the following items are resolved: Section 2.6 notes: Previous versions of the JSON format such as the obsoleted [RFC7159] allowed several different character encodings: UTF-8, UTF-16 and UTF- 32. This is not the case anymore, with the latest standard [RFC8259] only allowing UTF-8. [...] The actual situation is a bit more subtle than this text makes it seem; interoperable JSON can only use non-UTF-8 with explicit mutual prearrangement in a closed ecosystem. So, while this statement is true for Internet JWT usage, it may not be true for *all* JWT usage. (I do see that in Section 3.7 of this document we do mandate UTF-8 for JWT, which makes things unambiguous, even if this text here is not correct.) Fixed. Section 3.2 notes: JWT libraries SHOULD NOT generate JWTs using "none" unless explicitly requested to do by the caller. I couldn't find anywhere where we have matching guidance about "SHOULD NOT consume JWTs using 'none' unless explicitly requested"; this seems important enough to get called out explicitly. Fixed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have some non-Discuss-level substantive comments in the section-by-section notes, in addition to the usual editorial nits. Section 1 and/or encrypted. The JWT specification has seen rapid adoption because it encapsulates security-relevant information in one, easy to protect location, and because it is easy to implement using widely- nit: "one easy-to-protect location". OK Section 2.2 I'd consider rewording the text here to make it more poignant; perhaps: In addition, some applications use a keyed MAC algorithm such as "HS256" to sign tokens, but supply a weak symmetric key with insufficient entropy (such as a human memorable password). Such keys are vulnerable to offline brute-force or dictionary attacks once an attacker possesses such a token. OK Section 2.4 I'd suggest noting that the compression attacks are particularly powerful when there is attacker-controlled data in the same compression space as secret data. OK Section 3.2 Therefore, applications MUST only allow the use of cryptographically current algorithms that meet the security requirements of the application. This set will vary over time as new algorithms are introduced and existing algorithms are deprecated due to discovered cryptographic weaknesses. Applications MUST therefore be designed to enable cryptographic agility. This seems to have high overlap with BCP 201; a reference is probably in order. Since the JWT format itself enables crypto agility, we decided that a further reference to BCP 201 would not add clarity. Section 3.4 Some cryptographic operations, such as Elliptic Curve Diffie-Hellman key agreement ("ECDH-ES") take inputs that may contain invalid values, such as points not on the specified elliptic curve or other invalid points (see e.g. [Valenta], Sec. 7.1). Either the JWS/JWE library itself must validate these inputs before using them or it must use underlying cryptographic libraries that do so (or both!). side note: A phrasing like "JWS/JWE libraries MUST ensure that such input validation occurs" would leave the same wiggle room for the validation to occur at the underlying crypto layer, while leaving it crystal clear what entity is responsible for ensuring that the checks occur". But since I don't expect a change of this nature to actually cause different behavior by implementors, I'm not very tied to it. Left unchanged. Section 3.8 When we say "[o]ther applications may use different means of binding keys to issuers", is there any value in noting that certification by a trusted authority is a common way to perform this binding (in some contexts)? We couldn't find related use cases in the JWT space, left the text as-is. Section 3.9 If the same issuer can issue JWTs that are intended for use by more than one relying party or application, the JWT MUST contain an "aud" (audience) claim that can be used to determine whether the JWT is being used by an intended party or was substituted by an attacker at an unintended party. Furthermore, the relying party or application MUST validate the audience value and if the audience value is not present or not associated with the recipient, it MUST reject the JWT. (grammar nit?) Is the "Furthermore" sentence supposed to still be scoped to the case where the issuer can issue JWTs for more than one audience? If not, it seems like we're requiring the rejection of all "aud"-less JWTs but not requiring "aud" to be present when generating them. Clarified. Section 3.10 Applications should protect against such attacks, e.g., by matching the URL to a whitelist of allowed locations, and ensuring no cookies are sent in the GET request. This could probably be a SHOULD (or even a MUST?). Went for a SHOULD. Section 3.11 When applying explicit typing to a Nested JWT, the "typ" header parameter containing the explicit type value MUST be present in the inner JWT of the Nested JWT (the JWT whose payload is the JWT Claims Set). The same "typ" header parameter value MAY be present in the outer JWT as well, to explicitly type the entire Nested JWT. This is an interesting recommendation, as it is in some sense *introducing* type confusion by using the same type name for JWTs with different structures (the inner and outer JWTs)! My sense is that it is not practical to change current usage, though, so I think this should be treated as a side note and not an actionable recommendation. We discussed it, agree with your assessment and reworded a bit, indeed as a side-note. Section 3.12 - Use different keys for different kinds of JWTs. Then the keys used to validate one kind of JWT will fail to validate other kinds of JWTs. It might be worth calling back an analogy to RFC 8037's security considerations (where we advise to keep an association between key material and key algorithm), in effect extending the scope of "algorithm" to include application usage. We felt this would be more confusing than clarifying for our target audience. Given the broad diversity of JWT usage and applications, the best combination of types, required claims, values, header parameters, key usages, and issuers to differentiate among different kinds of JWTs will, in general, be application specific. For new JWT applications, the use of explicit typing is RECOMMENDED. This last recommendation seems to duplicate one from the end of Section 3.11. While it's important and worth reiterating, we do usually try to avoiding using normative RFC 2119 language when repeating ourselves, to make it very clear which requirement is the binding one. Added a reference to 3.11 to clarify.
- [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-… Yaron Sheffer