[OAUTH-WG] Comments on draft-richer-oauth-introspection-04

Thomas Broyer <t.broyer@gmail.com> Tue, 22 October 2013 14:50 UTC

Return-Path: <t.broyer@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 EEDA611E83D7 for <oauth@ietfa.amsl.com>; Tue, 22 Oct 2013 07:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlpvncIlwdet for <oauth@ietfa.amsl.com>; Tue, 22 Oct 2013 07:50:45 -0700 (PDT)
Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C553411E81B6 for <oauth@ietf.org>; Tue, 22 Oct 2013 07:50:41 -0700 (PDT)
Received: by mail-ve0-f169.google.com with SMTP id oy12so5525192veb.28 for <oauth@ietf.org>; Tue, 22 Oct 2013 07:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=UorzQFrGQYHMpu6Gv41GwWntr90qwmnq5Kxgrg3gEIs=; b=SW4hCMQLfPOQznwzhntKmcvEqn9CiR2APlithFNDzmW228oOFG8MgeJvyuKiy0dpsc 9zETIGNFjDrDhjK1PajU5BbCePRhmIBKYMs9ThJMzozxLqo76/KKajQvvbbYIqWRX3ej 6ixkhN1jg1v8xJIgxsdtJllj5VR/vDmMGY1hJOO8LdTtLKTWj12UhVF8ieFm9ehz/RvY HQwxZ7WsVCRe60pL3eyICQNstpPud24Bg0qHOBOP+uKbKzWymC6vmqFa8AnEa1xZ0E1g vM/ZFlyXStHnqJsMWsx9sF1HbQP8+PxILq6aTXo0eJhrP5Wrcxh6QLhqxX9ZhhiuRfZx gTdw==
X-Received: by 10.52.164.102 with SMTP id yp6mr13300231vdb.14.1382453441207; Tue, 22 Oct 2013 07:50:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.219.132 with HTTP; Tue, 22 Oct 2013 07:50:21 -0700 (PDT)
From: Thomas Broyer <t.broyer@gmail.com>
Date: Tue, 22 Oct 2013 16:50:21 +0200
Message-ID: <CAEayHENijdeTVu9-OxsnrJEh0JQBrvQo0eKWSjFvXSLqwzVRWg@mail.gmail.com>
To: oauth@ietf.org, jricher@mitre.org
Content-Type: multipart/alternative; boundary=001a11c2c1ea48652304e95586b8
Subject: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 22 Oct 2013 14:52:35 -0000

Hi all,

In a platform we're building, we have AS, clients and PRs all as distinct
parties managed/provided by distinct companies. There's a single AS though,
doing SSO through OpenID Connect (i.e. the AS in an OP).

I thus need a way for a PR to ask the AS whether the token presented by the
client is valid and grants access to the PR. I've thus briefly
evaluated draft-richer-oauth-introspection-04 which seemed to fulfill my
needs. Here are my comments:

First, I'm a bit disturbed about privacy and potential security issues
about the way this is done (disclaimer: I'm in no way a security expert).
This draft is really about "introspection", and not "validation" of a
token, and that might be the problem: it returns the information about a
token to whoever asks for it (provided it authenticates, and possibly only
if the token grants it access, but that would mean there's an association
in the AS between scopes and registered PRs, themselves identified by a
client_id); this is IMO disclosing too much information.
In case the PR is compromised, this information could be used to then reuse
the token with other PRs inferred by the token's granted scopes and gain
access to private information in a way that the End User didn't explicitly
approved (he authorized the Client to access several PRs, he didn't
authorize exchanges between PRs directly). This could be mitigated by *not*
using Bearer tokens (using some sort of 'proof token' instead, e.g. either
MAC or JWT), but there's no reason we couldn't have such a feature/endpoint
that could work securely with Bearer tokens (I don't want to put too much
burden on client and PR implementers).
Before I saw this draft, my idea was to have an endpoint at the AS where
the PR would send the token received by the Client *and* the scopes
corresponding to the request being done (and the "sub" of the End-User if
it was part of the request; in our case, we use it as a global identifier
shared by all parties involved; we might change to per-party IDs and then
use that endpoint to "translate" the ID as known by the Client to the ID as
known by the PR, but this is another story), and the AS would answer with
just a "yes" (HTTP/1.1 204 No Content) or "no" (400 Bad Request with a JSON
payload similar to the Error Response from Section 5.2 or RFC 6749, with
the same error codes as defined by RFC 6750; that way the PR can just
"translate" the error response to a WWW-Authenticate: Bearer response
header). That way, the PR does not know where else the token is "valid",
i.e. what it could do with it.

Second thing, the draft talks about a "resource_id" but doesn't say how it
could be used, and whether it'll be used at all by the server, what impact
it could have on the response, etc. Could that resource_id replace the
"list of scopes" from my implementation idea? The PR would need to know the
list of scopes to return the correct WWW-Authenticate header anyway
(assuming a Bearer token is used here), so I'm not sure it's really better.
And the resource_id is optional, so what would happen if it's not provided?
you'd have *more* information returned? I understand that this is just a
framework and each server would have its own rules, but you're then either
saying too much or too few.

Thanks in advance for any guidance about how to achieve my goal. Should I
go with introspection? (maybe I misunderstood something, or saw a threats
where there isn't) or should I use something else? Does my initial idea
make sense? Should I go with it?

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>