Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FE13A67D3 for ; Tue, 13 Jul 2010 08:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXDZhNyvVr+j for ; Tue, 13 Jul 2010 08:55:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 814CA3A6848 for ; Tue, 13 Jul 2010 08:55:52 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id o6DFu0WQ031062 for ; Tue, 13 Jul 2010 08:56:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1279036560; bh=ovjRXD+0OzpatBrbMEG8fJj8AqI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u327ct7geQf6pyusVk9YPYsn/96/Hi400bhdtDOeXgt1QsHwe4ieGuv081/D5LsFX ePSOSx6h/QOTdP6mIgPkg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=yV5nvejWMMhJnZTw/H+pkifx9Yze9CGCu7fcD4BOOScZyJpHckD4pse3CBrFlRYtw ByHphg1Dfn1MUppx7Lqug== Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by hpaq11.eem.corp.google.com with ESMTP id o6DFtxJl020218 for ; Tue, 13 Jul 2010 08:55:59 -0700 Received: by iwn39 with SMTP id 39so5860351iwn.10 for ; Tue, 13 Jul 2010 08:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.13.199 with SMTP id d7mr16463461iba.167.1279036557288; Tue, 13 Jul 2010 08:55:57 -0700 (PDT) Received: by 10.231.130.9 with HTTP; Tue, 13 Jul 2010 08:55:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Jul 2010 08:55:57 -0700 Message-ID: From: Dirk Balfanz To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=00235452eebca73b82048b46e755 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] "shared symmetric secret" X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 15:55:54 -0000 --00235452eebca73b82048b46e755 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote: > From the client's perspective, they are 'shared symmetric secrets' because > the client has to store them as-is and present them as-is. The act exactly > like passwords. I added that text to make that stand out. > > When using passwords, the server doesn't need to store them in plain-text > either (e.g. uses a way one hash). > That's why we don't call passwords "shared symmetric secrets", either. The verifier of a passwords can verify it without knowing the secret. In that sense, it's not "shared" with the verifier. I would like the specification to make it clear that bearer tokens are only > secure while they remain *secret* and that *anyone* holding them can gain > full access to what their protect. > I think the word "capability" expresses that better than the word "shared secret". Dirk. > > EHL > > On 7/12/10 10:39 PM, "Brian Eaton" wrote: > > > Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 > > > > Calling access tokens "shared symmetric secrets" is misleading, > > because if they are implemented well the authorization server and > > protected resource do not store a copy of the secret. > > > > Instead they store a one-way hash of the token. Or they verify the > > token cryptographically. Under no circumstances do they need to store > > a copy. > > > > I'd suggest the following language: > > > > "Access tokens are bearer authentication tokens or capabilities." > > > > Cheers, > > Brian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00235452eebca73b82048b46e755 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 13, 2010 at 7:18 AM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
>From the client's perspective, they are 'shared symmetric secrets&#= 39; because
the client has to store them as-is and present them as-is. The act exactly<= br> like passwords. I added that text to make that stand out.

When using passwords, the server doesn't need to store them in plain-te= xt
either (e.g. uses a way one hash).

That= 's why we don't call passwords "shared symmetric secrets"= , either. The verifier of a passwords can verify it without knowing the sec= ret.=A0In that sense, it's not "shared" with the verifier.=A0=

I would like the specificati= on to make it clear that bearer tokens are only
secure while they remain *secret* and that *anyone* holding them can gain full access to what their protect.

I th= ink the word "capability" expresses that better than the word &qu= ot;shared secret".=A0

Dirk.
=A0

EHL

On 7/12/10 10:39 PM, "Brian Eaton" <beaton@google.com> wrote:

> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-= v2-10#section-5
>
> Calling access tokens "shared symmetric secrets" is misleadi= ng,
> because if they are implemented well the authorization server and
> protected resource do not store a copy of the secret.
>
> Instead they store a one-way hash of the token. =A0Or they verify the<= br> > token cryptographically. =A0Under no circumstances do they need to sto= re
> a copy.
>
> I'd suggest the following language:
>
> "Access tokens are bearer authentication tokens or capabilities.&= quot;
>
> Cheers,
> Brian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--00235452eebca73b82048b46e755--