Re: [Trust-router] Considering delaying BOF Request
David Chadwick <d.w.chadwick@kent.ac.uk> Wed, 15 May 2013 15:32 UTC
Return-Path: <d.w.chadwick@kent.ac.uk>
X-Original-To: trust-router@ietfa.amsl.com
Delivered-To: trust-router@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D694F21F9092 for <trust-router@ietfa.amsl.com>; Wed, 15 May 2013 08:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Etc47p21J28N for <trust-router@ietfa.amsl.com>; Wed, 15 May 2013 08:32:34 -0700 (PDT)
Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1D99821F908B for <trust-router@ietf.org>; Wed, 15 May 2013 08:32:33 -0700 (PDT)
Received: from 129.9.113.87.dyn.plus.net ([87.113.9.129] helo=[192.168.1.66]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from <d.w.chadwick@kent.ac.uk>) id 1Ucdgt-0005Je-Q4; Wed, 15 May 2013 16:32:31 +0100
Message-ID: <5193AA8E.2020109@kent.ac.uk>
Date: Wed, 15 May 2013 16:32:30 +0100
From: David Chadwick <d.w.chadwick@kent.ac.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Sam Hartman <hartmans@painless-security.com>
References: <tslwqr0gu1p.fsf@mit.edu>
In-Reply-To: <tslwqr0gu1p.fsf@mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: trust-router@ietf.org
Subject: Re: [Trust-router] Considering delaying BOF Request
X-BeenThere: trust-router@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "ABFAB Trust Router discussion list." <trust-router.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trust-router>, <mailto:trust-router-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trust-router>
List-Post: <mailto:trust-router@ietf.org>
List-Help: <mailto:trust-router-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trust-router>, <mailto:trust-router-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 15:32:39 -0000
This is a topic I am very much interested in, and I have a student project starting next month to integrate the whole ABFAB infrastructure into OpenStack. So I expect to contribute to this discussion from then onwards, once we start to get experience of using trust routers and understand its your model better. Currently we have built our own trust rules into OpenStack. Specifically we have trust policies for i) which IDPs are trusted to be used as identity providers (authn trust) ii) which identity attribute types each IDP is trusted to assert (identification trust) iii) which trusted identity attribute values can be mapped into which OpenStack authz attribute types and values (authz trust) Once we integrate Abfab then we will replace i) above with the name of a community of interest instead of the name of an IdP, so that OpenStack will trust a specific CoI instead of an IdP to authenticate its users. This means that OpenStack will be trusting the trust routers to operate correctly and not allow untrusted IdPs to join the CoI. I presume that there must be a CoI administrator somewhere who configures one or more trust routers to say which IdPs are in the trusted group (and all others are not). But I dont yet appreciate how this trust is distributed between all the IdPs, and what stops a fraudulent IdP from tricking its way in. (Is it like a CA hierarchy for example?) We can similarly change policy ii), so that the identity attributes returned from ABFAB are trusted to be issued by a CoI member instead of a named IdPs. So we will be depending heavily on the trust router infrastructure to be trustworthy regards David On 15/05/2013 16:08, Sam Hartman wrote: > > > folks. > There hasn't been a lot of discussion on the list so far. Some of that > has been caused by us. We've been busy trying to test some aspects of > our documents with early implementation rather than discussing the > protocol. > > So far it doesn't seem like there's been enough discussion or interest > to put together a BOF request for IETF 86. we're still moving forward > on trying to get implementation and deployment experience with the > technology. We're still interested in standardization including making > changes we'd need to make to comply with an eventual standard. > > We're interested in thoughts on delaying the BOF request? > Does that seem like a good idea? > > Regardless, we will continue to use this list for any discussion of the > protocol or general use cases and the moonshot-community list to discuss > our implementation. > > --Sam > _______________________________________________ > trust-router mailing list > trust-router@ietf.org > https://www.ietf.org/mailman/listinfo/trust-router >
- [Trust-router] Considering delaying BOF Request Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… Rafa Marin Lopez
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick
- Re: [Trust-router] Considering delaying BOF Reque… Josh Howlett
- Re: [Trust-router] Considering delaying BOF Reque… Sam Hartman
- Re: [Trust-router] Considering delaying BOF Reque… David Chadwick