Re: [abfab] Levels of Assurence

Sam Hartman <hartmans@painless-security.com> Fri, 09 December 2011 13:02 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: abfab@ietfa.amsl.com
Delivered-To: abfab@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CC21F8500 for <abfab@ietfa.amsl.com>; Fri, 9 Dec 2011 05:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 kWYNWfGLxfcF for <abfab@ietfa.amsl.com>; Fri, 9 Dec 2011 05:02:28 -0800 (PST)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 40C0C21F84FD for <abfab@ietf.org>; Fri, 9 Dec 2011 05:02:27 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 56A2B2016B; Fri, 9 Dec 2011 08:02:26 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B611D42E8; Fri, 9 Dec 2011 08:02:00 -0500 (EST)
From: Sam Hartman <hartmans@painless-security.com>
To: Josh Howlett <Josh.Howlett@ja.net>
References: <CB077920.3DF5D%josh.howlett@ja.net>
Date: Fri, 09 Dec 2011 08:02:00 -0500
In-Reply-To: <CB077920.3DF5D%josh.howlett@ja.net> (Josh Howlett's message of "Fri, 9 Dec 2011 08:44:44 +0000")
Message-ID: <tslpqfxaofr.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Jim Schaad <ietf@augustcellars.com>, "abfab@ietf.org" <abfab@ietf.org>
Subject: Re: [abfab] Levels of Assurence
X-BeenThere: abfab@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" <abfab.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abfab>, <mailto:abfab-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/abfab>
List-Post: <mailto:abfab@ietf.org>
List-Help: <mailto:abfab-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abfab>, <mailto:abfab-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 13:02:29 -0000

At least in the Moonshot implementation we plan on handling this through
the Communities of Interest concept in draft-mrw-abfab-trust-router.
As Hannes points out LOA really implies more of a system concept than
just how the user is authenticated.
So, some proxies may not be up to carrying particular LOA traffic.

So a particular request would enter the system in a community with a
particular LOA requirement.  That would influence which proxies were
considered appropriate and potentially keying between proxies.

In some cases there may be a RADIUS hop before trust router starts, or
RADIUS hops that carry multiple COIs, similar to how other labeled
traffic is handled.  We'd need some sort of RADIUS attribute for
distinguishing COI in this case.

Obviously, this is very specific to our implementation at the moment,
and we don't have code for this yet.  However it very much is a system
property and so aspects of this are easier to think of in a system
context like Moonshot than purely in a standardization context in order
to see how it all fits together.
Obviously it would be great to standardize as much of this as possible.