Re: [dix] thoughts on "identity" and IETF

Jeffrey Altman <jaltman@secure-endpoints.com> Sat, 12 November 2005 21:05 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb2ZQ-0001O8-F7; Sat, 12 Nov 2005 16:05:56 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb2ZN-0001Mx-VS for dix@megatron.ietf.org; Sat, 12 Nov 2005 16:05:55 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23992 for <dix@ietf.org>; Sat, 12 Nov 2005 16:05:22 -0500 (EST)
Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb2q2-0005VK-W5 for dix@ietf.org; Sat, 12 Nov 2005 16:23:07 -0500
Received: from [18.100.0.94] (VPN-NINETY-FOUR.MIT.EDU [18.100.0.94]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jACL5aND029147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 12 Nov 2005 16:05:43 -0500 (EST)
Message-ID: <437659AB.80109@secure-endpoints.com>
Date: Sat, 12 Nov 2005 13:07:55 -0800
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Organization: Secure Endpoints Inc.
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: RL 'Bob' Morgan <rlmorgan@washington.edu>
Subject: Re: [dix] thoughts on "identity" and IETF
References: <Pine.LNX.4.63.0511091415480.16872@perf.cac.washington.edu>
In-Reply-To: <Pine.LNX.4.63.0511091415480.16872@perf.cac.washington.edu>
X-Enigmail-Version: 0.93.0.0
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5
Cc: IETF DIX list <dix@ietf.org>
X-BeenThere: dix@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Digital Identity Exchange <dix.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dix>
List-Post: <mailto:dix@ietf.org>
List-Help: <mailto:dix-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dix>, <mailto:dix-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0778781381=="
Sender: dix-bounces@ietf.org
Errors-To: dix-bounces@ietf.org

RL 'Bob' Morgan wrote:
>
> So is there something missing in the above stuff, some new
> requirements requiring new stuff, ie "Identity 2.0"?  I think the
> people who say there is are motivated by the huge number of new things
> that have happened on the web in the last few years.  The center of
> this is the blogging phenomenon.  Maybe 20 million people are now
> blogging.  They're doing other things like putting lots of photos
> online at Flickr, keeping their bookmarks on del.icio.us, tracking
> tags on technorati, and zillions of other examples.  They are
> composing these services in myriad ways to create new services.  In
> sociological terms they are creating online identities for themselves
> that they feel much more attachment to than their organizational
> account, even their "my.foo.com" page at one of the traditional portal
> sites.  In Identity 1.0 terms they are all becoming, or have an
> interest in becoming, both service providers and identity providers,
> that is, they have an interest in protecting their resources (in the
> canonical case of reducing blog spam), and in leveraging their
> personal info to their millions of peers.
>
> So now in addition to the tens or hundreds of thousands of
> institutions with identity interest, there are tens of millions of
> individuals.  Many people are trying to figure out what they need and
> respond to it.  The SXIP technology is one among those, others are
> OpenID, LID, Passel, and no doubt many others.  For the most part
> these approaches reject traditional identity management protocols and
> systems; whether they should or should not is one of the big
> questions.  A key point is that the individual interest in identity is
> much more about expression, ie ease of sharing and discovery, than it
> is in control (ie, fancy security).  Another key point is individual
> control, the same sort of control people feel over their personal
> domain name and its site, or their blog.  Even people who aren't
> radically anti-corporate like to feel in charge of their own stuff.
>
>
Kerberos is best known as an authentication system used by large
organizations.  It is thought that setting up and managing a Kerberos
realm requires too much infrastructure and in particular too much
administration for use by the masses.   However, this is not necessarily
the case.   There is another model that has been discussed within the
Kerberos development community but has not received much attention
elsewhere.   Instead of maintaining a very small number of highly
trusted realms with thousands to hundreds of thousands of principals,
what if it were possible for every computer that maintains its own set
of local user accounts to be a realm?  In this world service providers
of e-mail, blogs, photo albums, etc. would all establish Kerberos
realms, not to issue client principals but only to issue service
principals for the service instances running on their clusters of
computers.   The client principals would be managed by the users in
their own realms.

The magic that enables the client principal jaltman@MY.PC to be accepted
by blog/some.machine@BLOG.PROVIDER is Kerberos cross-realm
authentication.  The client application connecting to the blog service
on some.machine would query the MY.PC KDC for a cross-realm ticket for
BLOG.PROVIDER.  After receiving such a ticket the client application
would contact a BLOG.PROVIDER KDC to obtain the
blog/some.machine@BLOG.PROVIDER service ticket that would in turn be
used to authenticate jaltman@MY.PC to the blog service.

If you have been paying close attention you will be asking yourself,
"how can the MY.PC KDC issue a cross-realm ticket granting ticket for
the BLOG.PROVIDER realm?   The MY.PC realm administrator did not
exchange a key with the BLOG.PROVIDER realm administrator."  The answer
to this problem is a proposal put for almost a decade ago entitled
"Public Key Cryptography for Cross-Realm Authentication in Kerberos".  A
copy of the expired draft can be found in the Dec 1998 IETF
proceedings. 
http://www3.ietf.org/proceedings/98dec/I-D/draft-ietf-cat-kerberos-pk-cross-05.txt
By using public key cryptography (with or without a PKI) to perform the
key exchange, it is possible to remove the need for the manual exchange
of keys by the administrator.   Instead, "leap of faith" methods can be
used to allow an individual to register their principal name with a
service and validate the authenticating realm in much the same way that
receipt of an e-mail and subsequent access to a URL is used.  

One of the nice benefits of using Kerberos is that it is a proven
technology that has pre-existing wide spread deployment.   Every major
OS has Kerberos support already available for it.   The Kerberos ticket
format can also be used to exchange additional identity or authorization
data.  This data can be inserted by the realm issuing the ticket
granting ticket or the realm issuing the service ticket.   I grant that
not all of the required functionality is available in the Kerberos
support shipped in today's systems.  However, adding the support as an
incremental change to Kerberos would be no harder than adding support
for an entirely new infrastructure that does not exist in any form.

I look forward to answering any questions you might have.

Jeffrey Altman



_______________________________________________
dix mailing list
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix