Re: [kitten] PKCROSS and philosophical tangents...

Nico Williams <nico@cryptonector.com> Wed, 29 January 2014 23:56 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ADF1A03D6 for <kitten@ietfa.amsl.com>; Wed, 29 Jan 2014 15:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHYTQXPaR8WX for <kitten@ietfa.amsl.com>; Wed, 29 Jan 2014 15:56:42 -0800 (PST)
Received: from homiemail-a108.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5972B1A02F0 for <kitten@ietf.org>; Wed, 29 Jan 2014 15:56:42 -0800 (PST)
Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 4EA4C2007F118; Wed, 29 Jan 2014 15:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=z0/EMabpQTg97I AX0OI0GmyohqQ=; b=LQ7LZaLMjzVuTdIVUI+hRbXyBGRS+wvCu10220XOqa8fTc 1X8pawSEgQCov/6mVBoAXOFoPANCYfiaHWBwb6xUSI6WbprCnOSKcU8abz2aYnga 0WsycCBlZkXGHPb+Et7b+cRTxdiyibOkAoL5y0KUKLLceMDhwKc39fOfl1tOM=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 0AAA12007F106; Wed, 29 Jan 2014 15:56:38 -0800 (PST)
Date: Wed, 29 Jan 2014 17:56:38 -0600
From: Nico Williams <nico@cryptonector.com>
To: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>
Message-ID: <20140129235636.GB6916@localhost>
References: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E683B4E@001FSN2MPN1-046.001f.mgd2.msft.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] PKCROSS and philosophical tangents...
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 23:56:44 -0000

On Wed, Jan 29, 2014 at 07:01:31PM +0000, Nordgren, Bryce L -FS wrote:
> I hope this isn't out of line. I spend quite a lot of time thinking
> about this, as much of my job involves trying to collaborate with
> others.

It's not only not out of line, it's very welcomed.

> Tangent #1: What is "authentication"?

That's a long topic.  For the sake of brevity, and to answer your more
concrete questions/proposals, I'll not go down this tangent :)

> PKCROSS introduces a paradigm where entire foreign domains are
> authenticated by a certificate authority, to varying degrees of rigor.

A "varying degree of rigor" (I like the phrase) is exactly it.

It's already the case in pretty much all distributed authentication
systems, including Kerberos w/o PKCROSS, including PKIX, and so on.

Grow your world of actual and potential peers large enough and any
assumption that "can authenticate" == "someone I can trust" evaporates.

> [...]

> I would like to propose a third type of authentication: a "Sponsored
> external user". This paradigm assumes a home-user-driven need to
> [...]

This smells to me more like authorization than authentication, but it
can be seen either way, and it really depends on what operational
details you'd like to have involved.  If "sponsorship" means that the
sponsor has to provide a KDC-/CA-/IdP-like infrastructure for sponsees,
then it's really authentication, but also a pain.  If what you have in
mind is more like writing down somewhere that a sponsee [whose identity
must be possible to establish in roughly the same way every time,
perhaps every time after the first] can do this or that, then it's more
like authorization, and much easier to manage.

Treating this as authorization is much easier, but it does require that
you be able to demand repeatability from authentication of the sponsee.

You may not care who a peer's IdP/CA/KDC is, as long as it stays the
same and the trust path for authenticating the IdP/CA/KDC stays the
same.  If you can see to this then it's easier to view this as
authorization.

> 4] human trust anchor aggregation: if several sponsors affirm several
> identities from the same foreign realm, confidence in that realm's
> identity should be high;

You still get this if you treat this as delegated authorization, again,
provided that you have a way to authenticate the "several identities'"
[presumably] common credential issuer reliably.

Nico
--