Re: [Atoca] What information is used for authorization?

"Richard L. Barnes" <rbarnes@bbn.com> Mon, 17 January 2011 14:57 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BB728C0FE for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 06:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level:
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, 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 T-40IvOdJUNs for <earlywarning@core3.amsl.com>; Mon, 17 Jan 2011 06:57:08 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 671F628C0DF for <earlywarning@ietf.org>; Mon, 17 Jan 2011 06:57:08 -0800 (PST)
Received: from [128.89.253.241] (port=65237 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PeqYX-000EJc-RW; Mon, 17 Jan 2011 09:59:42 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net>
Date: Mon, 17 Jan 2011 09:59:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BE459C1-D2CC-4656-AD90-BE32529225CA@bbn.com>
References: <9C2879D3-CDE1-48A6-B4F0-DC98B6EF1E0C@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1082)
Cc: Igor Faynberg <igor.faynberg@alcatel-lucent.com>, earlywarning@ietf.org
Subject: Re: [Atoca] What information is used for authorization?
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2011 14:57:09 -0000

At a high level, the question of what *information* is used for authorization is not one for this group to consider.  That's a policy question, not an engineering question.  Our focus should be specifying *containers* for such information; at most, we specify what *can* be used for authorization, not what *will* be.

At a technological level, I would suggest that we take this in steps.  

Identity-based access control is clearly low-hanging fruit: There are long-standing mechanisms in several protocols (HTTP, SIP, XMPP, etc.) for authenticating users either with shared secrets or with PKIX certificates.  

PKIX-based authentication in particular can also support some forms of attribute-based authorization, e.g., based on CA identity, CP OID, or extensions like the Clearance attribute [1].  This approach has the benefit that several organizations already have the necessary authentication/authorization infrastructure -- there's not necessarily a need for any new credentials or processes.

Once we have something basic in place based on these technologies, then we can certainly look at ways of adding additional attributes, say using SAML or attribute certificates.

--Richard

[1] <http://tools.ietf.org/html/rfc5913>



On Jan 15, 2011, at 2:31 PM, Hannes Tschofenig wrote:

> Hi all, 
> 
> it was Igor again who raised a question regarding authorization at the IETF#79 ATOCA meeting. He was wondering whether we would only consider the identity of the originator for authorization or some other information as well.
> 
> Are we considering trait-based authorization, see http://www.rfc-editor.org/rfc/rfc4484.txt,  to be utilized in this context? 
> 
> So, what model do we envision? 
> What other information is useful in the context of an authorization decision? 
> 
> Ciao
> Hannes
> 
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning