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

[Jeffrey Altman <jaltman at secure-endpoints.com>]

Hallam-Baker, Phillip wrote:
> I agree people want flexibility, but this was the starting point for
> SAML, GSSAPI, SASL. It is time to say 'choose one negotiation
> infrastructure, the existence of 6 negotiation standards does not mean
> there is value to supporting more than one.
>
Speaking as Chair of the Kitten (GSSAPI Next Generation) working group,
what many of
us have been saying for a long time is that applications should when
possible develop to SASL
because it provides the ability to construct post authentication
security layers (data privacy and
integrity protection) and mechanism implementors should implement their
mechanisms within
the GSSAPI framework.  All GSS mechanisms can be used within SASL. 
There is a strong
desire to be able to specify a unified mechanism specification which
would allow mechanisms
consistent with such a specification to be utilized by EAP as well.

It is important to point out that this flexibility is necessary for
mechanism implementors.  
There is absolutely no reason why an application protocol should accept
more than one of
SASL, GSS, EAP, etc.  In fact, allowing for the use of multiple security
context negotiation
protocols within an application will almost always introduce downgrade
attacks.

There has been discussion of implementing a GSS mechanism for SAML. 
There is also
discussion within the Kerberos communicating of transporting SAML within
the authorization
data field of the Kerberos service tickets.   Kitten is looking at
extending GSS to support stackable
mechanisms so that a generic SAML mechanism could be piggybacked on top
of existing
authentication mechanisms.

One thing that concerns me about the terminology within this discussion
is that the concept of
"identity" being discussed is not one that is appropriate for use in
performing authentication
and the establishment of secure (private and integrity protected)
communication channels.  In
the early days of JXTA we discussed a great deal the concept of
peer-to-peer trust models.
Look for the early Poblano papers.   One of the things that we agreed
very early on is that
distributed trust is orthogonal to authentication.  

I also have a problem with the terminology being used.   Are we really
trying to say that
an entity has multiple "identities"?   As far as I know, I have only one
identity, "me".  What I do
have many of are forms of identification which include government issued
IDs (driver's license, passport,
birth certificate, gun permit, etc), university issued IDs, employer
issued IDs, e-mail addresses,
banking related IDs (credit and check cards), X.509 certificates,
Kerberos principals, etc.
I imagine a world in which, for example, every machine with local
accounts on it is its own Kerberos
realm that manages the client principals for the local accounts.  
Elsewhere in the world are service
providers that have their own realm that manages service principals for
each of their services (blogs,
photo libraries, etc.).   The client realm and the service realms are
able to authenticate to each other
via Kerberos cross-realm where key sharing is performed using public key
cryptography.   Similar
to the PGP model, the trust value of the cross-realm relationship is
configured by human beings.
A cross-realm relationship in which two administrators inspected each
other's environments and
manually setup keys could be given a high trust value; others which were
established after validating
X.509 certificates might be given a medium trust value, and others that
were established with
anonymous public key crypto would be given a very low level of initial
trust. 

A bank might establish the cross-realm relationship but not allow that
locally managed identification
to be used for anything significant without additional forms of
verification.  

One thing that is absolutely true is that we are never going to be in a
world in which an entity has only
a single form of identification.   I already manage dozens of Kerberos
principals and X.509 certificates
that are used for authenticating to services at various organizations.  
If it were the case that only one
form of identification could be used with any one service, then
implementing a search algorithm to choose
the appropriate form of identification for authenticating to that
service would be easy.    Where the
fun starts is when it is possible to use multiple forms of
identification with a specific service that 
associates each form of identification with a different role.  It then
becomes extremely difficult to develop
the necessary associations between identifications and services to
automate the process for the user
and make accurate choices based upon the user's needs at the given
moment.   On the other hand if
you try to involve the user in the decision making process for each
authentication, the user will find the
software unusable.

One real world example is the Andrew File System.  AFS uses Kerberos for
authentication and cross-
realm relationships are used to allow an ATHENA.MIT.EDU Kerberos client
principal to obtain a
Kerberos service ticket for afs/andrew.cmu.edu at ANDREW.CMU.EDU.   Now as
it turns out
due to the cross-realm relationships how should my local tools decide
which of my many Kerberos
principals that can obtain the necessary service ticket should be used
to do so?

    jaltman at ATHENA.MIT.EDU
    jaltman at RAEBURN.ORG
    jaltman at SECURE-ENDPOINTS.COM
    jaltman at WINDOWS.SECURE-ENDPOINTS.COM
    jaltman/admin at SECURE-ENDPOINTS.COM
    jaltman at DEMENTIA.ORG
    jaltman at ANDREW.CMU.EDU

They would all work and at the present time each one would result an
authentication as a separate AFS ID
where the AFS ID is the thing placed in an ACL.   One of the ways in
which we are going to address
this problem is by making the end user tools smart so they can be told,
unless told otherwise when accessing
the "andrew.cmu.edu" AFS cell, the jaltman at SECURE-ENDPOINTS.COM
principal name should be
used.  Secondly, we are adding functionality to the AFS Protection
Service that will allow multiple
identifications to be associated with a single AFS ID, where an
identification is defined as an authentication
type and name pair (such as Kerberos 5, jaltman at SECURE-ENDPOINTS.COM).

I believe that by approaching the problem from both sides in this manner
it will be possible for us to
construct an extremely user friendly environment that allows users to
access services at various times
and from various places with different sets of available forms of
identification.   Service providers will
determine for themselves which forms of identification are acceptable
for which tasks based upon their
own risk assessments.  I believe the most important thing to realize is
that solving the problem does not
require throwing out what we have already built.  The existing
authentication infrastructures can be
extended to meet the needs of the broader community.

Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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