IETF Logo Mail Archive

Re: [OAUTH-WG] treatment of client_id for authentication and identification

"Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com> Thu, 18 August 2011 21:46 UTC

Return-Path: <huilan.lu@alcatel-lucent.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 4F91D21F8876 for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 14:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.253
X-Spam-Level:
X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 89HwuzsalYSB for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 14:46:18 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id CE5E021F884C for <oauth@ietf.org>; Thu, 18 Aug 2011 14:46:18 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p7ILlBKk015829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 16:47:12 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7ILlBwW028893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 16:47:11 -0500
Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 18 Aug 2011 16:47:11 -0500
From: "Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com>
To: 'Eran Hammer-Lahav' <eran@hueniverse.com>, Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 18 Aug 2011 16:47:10 -0500
Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification
Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmAAAWgcIAABDUFQ
Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244274@USNAVSXCHMBSB3.ndc.alcatel-lucent.com>
References: <4E317125.7080006@lodderstedt.net> <CA56CA21.1758B%eran@hueniverse.com> <CA+k3eCTguAGGC1xGuuA0Z2sRu7MNCdtsUnb-3V9vmz4CFwxBYw@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com> <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFAB5D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification
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: Thu, 18 Aug 2011 21:46:19 -0000

> > It is difficult to parse the last sentence of 3.2.1: "The security ramifications of
> > allowing unauthenticated access by public clients to the token endpoint
> > MUST be considered, as well as the issuance of refresh tokens to public
> > clients, their scope, and lifetime."
> >
> > I think it should be rewritten and reference relevant parts of security
> > considerations.
> 
> Text?
> 
> EHL

Here is my stab:
Allowing unauthenticated access by public clients has security ramifications. So does the issuance of refresh tokens to public clients. Such security ramifications MUST be considered. See section 10 for further details.

Huilan

v2.23.0 | Report a Bug | By Email