Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session

Brian Campbell <bcampbell@pingidentity.com> Fri, 01 May 2020 18:19 UTC

Return-Path: <bcampbell@pingidentity.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 AE8303A191D for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 11:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 AiEQpUqx2L0s for <oauth@ietfa.amsl.com>; Fri, 1 May 2020 11:18:58 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 7AE9E3A1916 for <oauth@ietf.org>; Fri, 1 May 2020 11:18:45 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id z22so4331478lfd.0 for <oauth@ietf.org>; Fri, 01 May 2020 11:18:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SqQkitlT7ocz+ox9lgijMDun0FFk2JS/sSEGT+Ekye0=; b=QerqkHxDgYGUMjX8RlGEdNpqM27kfnTFN9cVcmCP+XCg+c0dkh5G/6NnUhYNLzWRuw 6C6vBXKXeVpE9ooKppJ9aIDZ1FdO2E0G+wUvZQtjDcworrO1yC6IUY8L2E9osvvlqo3M vhJr6YuRRfJ2i4rcPD2WyCrwCMLYmSsI2XkDsSdPH5fuKt+Cr4F+8xuBeJVJbi8vFdms H2R6qCbqwVfeKLCgON4B1EcFMZaUjNXXSYWm0QhYhbjLFhnwyv6PkuBM7EK6125V1Tf5 166sVWvU+SXV+QCbrBCLobpw5vjc9H8Ccndn7Zq3wsUOAns47FXOIdzR2kacNN4Gyx5E Qr0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SqQkitlT7ocz+ox9lgijMDun0FFk2JS/sSEGT+Ekye0=; b=UkyY3XahYnZxRmGCHmMaNIBnA3+YFjnDlsz2UyQ9MTFLFjYLQkFfjaM0XuwVDO6fpd C1O4e0CvKJ8tX42XlxOTfE+vSfqrzDxaS+s2TjLR4buPPgxXvaDM67LKeJiURwNxt7Mp 72Xso13TvrF0ONif9RbaypjIMH4Hi3432SZ1t7jVdjm1k2Y0D3jH6sJvSVc9C44L6Ukn K3Yz7ZEG9YftEnSvFhNkoA/Sd2UHj42XzUI1627Yqoll68x7o50+zaT41xPO2ompK03L zo9m4Nj8jq8uxYGMO2AfR8FHkVGz2PynMn/qTjUOjUqjrHspegeIb5oE/W8cNGX1VDqg JULg==
X-Gm-Message-State: AGi0PuZdQNWUqyXYZcdVLUDFyUbJb/SQQATODYHTxUM8JnzD6xMCiUtY 0bbdMs4lfwsxM4LGoHTWkf460pSLuMOUJVp6CPhhIMRlBopaP7ZcKJ0MW4zjk2foLTyXieH9kwy cj61bep5/XmknmA==
X-Google-Smtp-Source: APiQypJvq4ZoLPcGEkxvSEn3sbqCJzQK8XFYYK5OhlE0E834ykH0WlXX4L+l74XxsisN8rjICVyydrHNrIB7X4nYMQc=
X-Received: by 2002:a05:6512:74:: with SMTP id i20mr3303646lfo.104.1588357123539; Fri, 01 May 2020 11:18:43 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0@MN2PR00MB0686.namprd00.prod.outlook.com>
In-Reply-To: <MN2PR00MB0686F8BDA731C6F478C35EFCF5AB0@MN2PR00MB0686.namprd00.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 1 May 2020 12:18:17 -0600
Message-ID: <CA+k3eCQgcmgP4kPMUjEsyiK7pHDKiYoFbAXE8U7RdgP3j7Bi6A@mail.gmail.com>
To: Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>, Dmitri Zagidulin <dzagidulin@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002022a705a49a367d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/hpfcCk9EHKkOmruBN5VZwoyW9WQ>
Subject: Re: [OAUTH-WG] Microsoft feedback on DPoP during April 2020 IIW session
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: Fri, 01 May 2020 18:19:01 -0000

Thanks Mike for sharing this summary of what sounds like it was a valuable
discussion. I'm sorry that I wasn't "at" IIW so wasn't able to participate
in the session.

I will endeavor to incorporate the open issues into the presentation on
DPoP for the virtual interim on Monday
https://datatracker.ietf.org/meeting/interim-2020-oauth-07/session/oauth to
hopefully facitate some futher disscion and progress.

On Thu, Apr 30, 2020 at 8:29 PM Mike Jones <Michael.Jones=
40microsoft.com@dmarc.ietf.org> wrote:

> Daniel Fett and David Waite (DW) hosted a great session on OAuth 2.0
> Demonstration of Proof-of-Possession at the Application Layer (DPoP)
> <https://tools.ietf.org/html/draft-ietf-oauth-dpop-00> at the virtualized
> IIW <https://internetidentityworkshop.com/> this week.  Attendees also
> included Vittorio Bertocci, Justin Richer, Dmitri Zagidulin, and Tim
> Cappalli.
>
>
>
> After Daniel and DW finished doing their overview of DPoP, I used some of
> the time to discuss feedback on DPoP from Microsoft Azure Active Directory
> (AAD) engineers.  We discussed:
>
>    - *How do we know if the resource server supports DPoP?*  One
>    suggestion was to use a 401 WWW-Authenticate response from the RS.  We
>    learned at IIW that some are already doing this.  People opposed trying to
>    do Resource Metadata for this purpose alone.  However, they were supportive
>    of defining AS Metadata to declare support for DPoP and Registration
>    Metadata to declare support for DPoP.  This might declare the supported
>    token_type values.
>    - *How do we know what DPoP signing algorithms are supported?*  This
>    could be done via AS Metadata and possibly Registration Metadata.  People
>    were also in favor of having a default algorithm – probably ES256.
>    Knowing this is important to preventing downgrade attacks.
>    - *Can we have server nonces? * A server nonce is a value provided by
>    the server (RS or AS) to be signed as part of the PoP proof.  People agreed
>    that having a server nonce would add additional security.  It turns out
>    that Dmitri is already doing this, providing the nonce as a
>    WWW-Authenticate challenge value.
>    - *Difficulties with **jti at scale.*  Trying to prevent replay with
>    jti is problematic for large-scale deployments.  Doing duplicate
>    detection across replicas requires ACID consistency, which is too expensive
>    to be cost-effective..  Instead, large-scale implementations often use
>    short timeouts to limit replay, rather performing reliable duplicate
>    detection.
>    - *Is the DPoP signature really needed when requesting a bound token?*
>    It seems like the worst that could happen would be to create a token bound
>    to a key you don’t control, which you couldn’t use.  Daniel expressed
>    concern about this enabling substitution attacks.
>    - *It seems like the spec requires the same **token_type for both
>    access tokens and refresh tokens.*  Whereas it would be useful to be
>    able to have DPoP refresh tokens and Bearer access tokens as a transition
>    step.  Justin pointed out that the OAuth 2 protocol only has one
>    token_type value – not separate ones for the refresh token and access
>    token.  People agreed that this deserves consideration.
>    - *Symmetric keys are significantly more efficient than asymmetric
>    keys.*  In discussions between John Bradley, Brian Campbell, and Mike
>    Jones at IETF 106, John worked out how to deliver the symmetric key to the
>    Token Endpoint without an extra round trip, however it would likely be more
>    complicated to deliver it to the resource without an extra round trip.  At
>    past IETFs, both Amazon and Okta have also advocated for symmetric key
>    support.
>    - *What are the problems resulting from PoP key reuse?*  The spec
>    assumes that a client will use the same PoP key for singing multiple token
>    requests, both for access token and refresh token requests.  Is this a
>    security issue?  Daniel responded that key reuse is typically only a
>    problem when the same key is used for different algorithms or in different
>    application contexts, when this reuse enables substitution attacks.  It’s
>    also the case that clients can choose to use different PoP keys whenever
>    they choose to.
>    - *Could access tokens be signed?*  Having the DPoP key hash in the
>    access token is equivalent if the access token is integrity protected.  But
>    people said that many deployments don’t use structured access tokens in
>    which the key hash can be included.  For instance, Ping Identity uses
>    access tokens that are just database indexes.  Would access token signing
>    be needed then?
>    - *Why aren’t query parameters signed?*  Daniel said that
>    canonicalization of query parameters that use different URL escape syntaxes
>    for representations of the same characters would likely result in interop
>    problems.  People said that while SOAP deployments might have many logical
>    endpoints differentiated only by query parameters, that’s no longer the
>    normal pattern for REST systems.
>
>
>
> Thanks for the great discussion!
>
>
>
>                                                        -- Mike
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._