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
>