Re: [OAUTH-WG] Auth Server / Resource Server Coordination

Ofer Nave <odigity@gmail.com> Tue, 13 October 2015 13:43 UTC

Return-Path: <odigity@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38281B3DC5 for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 06:43:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 p1dSyPQ8v9S3 for <oauth@ietfa.amsl.com>; Tue, 13 Oct 2015 06:43:03 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (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 AC70D1B3DBF for <oauth@ietf.org>; Tue, 13 Oct 2015 06:43:02 -0700 (PDT)
Received: by wijq8 with SMTP id q8so33029619wij.0 for <oauth@ietf.org>; Tue, 13 Oct 2015 06:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WQV2lofQj20qqWRn2yM9lctMDArHNbwXMbe+GUuW8vE=; b=InstGTHexHcPlAueqJAktzvgbrSJqWY4j7DZ5o7tCLmhi/MVbcAUeFc/oH9sMX/9V7 FVhVEByzoVnwJblraOK7O7HxY67p4+/V03gQ7QXpY9Yp7Y3+ft6NmcBKbvRc3+OPdiKj sev7yOj44valYmSJPhVtPEIIlpb9ydJIdgPjUpfWUiO/HWr+kRQM0Bs162ig8YwMjrR0 Nb0Lwpx18gYMUXvgBky0A+F8O75szHY6zDi46jaRD3sYhxP29z5j7rg6tCPG5tIUUOH+ RlZpdKsgOLBIfvfQ/HykzXQc/4AGUzmmYhQG4P/BfB5a06A7VSKn45b2tyD8tTqjhIrh 61PA==
MIME-Version: 1.0
X-Received: by 10.180.93.168 with SMTP id cv8mr22248916wib.54.1444743750186; Tue, 13 Oct 2015 06:42:30 -0700 (PDT)
Received: by 10.27.125.70 with HTTP; Tue, 13 Oct 2015 06:42:30 -0700 (PDT)
In-Reply-To: <561CC364.1090206@connect2id.com>
References: <CABPN19_wYVEvqEU85FDZMYe6k8E8qkL0gGDvFeQMXaaQt+yAbQ@mail.gmail.com> <2064190583.2714607.1444710048221.JavaMail.yahoo@mail.yahoo.com> <CABPN19_VCKzuQCfFHV=C6LjHDVUghmMgkz9dW-3iH8fscBGD4Q@mail.gmail.com> <561CC364.1090206@connect2id.com>
Date: Tue, 13 Oct 2015 09:42:30 -0400
Message-ID: <CABPN199fA1M_P5KJ5gQJ+Ug9=m-k7BM3XHswp5TRoEKuWJTR6w@mail.gmail.com>
From: Ofer Nave <odigity@gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Content-Type: multipart/alternative; boundary="f46d043c7fba0596b70521fc9ecb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/YZ4VTWcH50E0mXPLR3OiLz7nyKM>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Server / Resource Server Coordination
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 13 Oct 2015 13:43:04 -0000

> With asymmetric keys you won't have these problems. The RS would only
need to have a copy of the public AS key to verify the tokens.

That's an excellent point I had considered.

-ofer

On Tue, Oct 13, 2015 at 4:40 AM, Vladimir Dzhuvinov <vladimir@connect2id.com
> wrote:

>
>
> On 13.10.2015 07:37, Ofer Nave wrote:
> >> You do have decisions to make on whether you use symmetric crypto or PK
> > there.
> >
> > That's another thing I was pondering -- simple shared secret, or require
> > generated a private/public key pair.
> >
> > The asymetric form is a little more complicated in terms of the user
> > experience.  Is there a practical reason to prefer it?
>
> If the AS and the Resource Servers (RS) share a secret, there is a risk
> of an RS impersonating authorised clients by creating valid tokens to
> access other RSs.
>
> You may prevent this by making sure every RS gets its own secret, but in
> that case you cannot issue tokens with multiple RS audiences.
>
> With asymmetric keys you won't have these problems. The RS would only
> need to have a copy of the public AS key to verify the tokens.
>
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>