[OAUTH-WG] RFC 8898 - UAC security threats

Timothée Jaussoin <edhelas@movim.eu> Tue, 15 October 2024 12:20 UTC

Return-Path: <edhelas@movim.eu>
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 5703DC151095 for <oauth@ietfa.amsl.com>; Tue, 15 Oct 2024 05:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=movim.eu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQlIIJ2VJq0u for <oauth@ietfa.amsl.com>; Tue, 15 Oct 2024 05:19:57 -0700 (PDT)
Received: from movim.eu (v2202101139504140605.quicksrv.de [94.16.111.188]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD22DC151549 for <oauth@ietf.org>; Tue, 15 Oct 2024 05:19:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=movim.eu; s=mail; t=1728994796; bh=GWGRXPCDKmRUeO9363sMrC7rO9aw+2gkQlfTuJyQgPs=; h=Date:To:From:Subject:From; b=du4uYoUBpQGo75+7jq/u/qHNHIumnQdEbcmgWm2nZOF/BkKkwu2ENe0iNLXaFsuce QrEpS8FOL5mxOIYErd8WxfRTrr16RT1Oz3UsFdOF8aB4ZAD/Sj0ZF3f/1vaReJMubm +vL9ZS/HotQ1uOeq05/o6rXhHt94jMtSoQNWUzI3UtJ5H3NjOcY7ZShCELH/vtTDDE bpxJXPF9ozQkCBOJmquilaFNfomTloknra/uHttTEkBJEqg3RTEFYQmG27caEV3W7d +TeD04EVM9zu4rS4b/GZLseFWqMMrbrXGktgQEJ3sqCL1eYRoewVfRfsC5yd78vk4w LBeZl7pF+Uj1A==
Received: from [IPV6:2a01:e0a:27e:8210:16b8:c9bb:b15a:45d4] (unknown [IPv6:2a01:e0a:27e:8210:16b8:c9bb:b15a:45d4]) (Authenticated sender: edhelas) by movim.eu (Postfix) with ESMTPSA id 17116E00B0 for <oauth@ietf.org>; Tue, 15 Oct 2024 14:19:56 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------YRANJ2sfFiuqrawyAe7QHVei"
Message-ID: <17a4c5cd-27d1-4115-8209-09e9113dad66@movim.eu>
Date: Tue, 15 Oct 2024 14:19:55 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: oauth@ietf.org
Content-Language: en-US
From: Timothée Jaussoin <edhelas@movim.eu>
Message-ID-Hash: HGKVSSRJ5JM5PTCS5EBOXHDXVVLWQI63
X-Message-ID-Hash: HGKVSSRJ5JM5PTCS5EBOXHDXVVLWQI63
X-MailFrom: edhelas@movim.eu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] RFC 8898 - UAC security threats
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/iEvIwFN6RNFJTgAzhlwmzTK4ugg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hi,

I'm currently implementing the RFC 8898 and I have a question regarding 
this specific paragraph (in 
https://www.rfc-editor.org/rfc/rfc8898#name-security-considerations)

    /The UAC MUST check the AS URL received in the 401/407 response
    against a list of trusted ASs configured on the UAC in order to
    prevent several classes of possible vulnerabilities when a client
    blindly attempts to use any provided AS./

Is it possible to have some precision on the kind of vulnerabilities 
that not checking the returned AS URL in the UAC could cause? This 
actually change the purpose of this RFC as it doesn't allow anymore to 
discover some new AS but more to guide the UAC to a specific AS based on 
its own list.

Regards,

Timothée Jaussoin/
/