Re: Credential "Negotiation" Complexity

[George_Robert_Blakley_III@tivoli.com]

All,

>> > One major reason to the extended scheme I propose, is that  the
current [rigid] approach
>> > seems to leave credential incompatibility issues in the hand  of the
user instead of the AP.
>> > It *may* cost an extra "round", but it will put much less burdon on
helpdesks.

>> Here I respectfully disagree. Consider your example:
> [snip]

>I find this example strange.  If it is a "fact" that an Assistant
Professor of Computer Science
>implies a Phd in the same subject, why did not the AP provided the
credential asked for?
>
>Regardless of scheme used, all parties must agree on format and exact
semantics of
>credentials.

This is the critical point.  This is one of the things I addressed in
comments I made
at the DeAnza meeting in MA just before the formation of the TC, which
I've just realized I never circulated to any list.  So I'll put it in this
note.

================ begin Bob's sermon on scope of activity
===================

The environment in which <name of spec> will be useful is:

* many domains
* many technologies, including security technologies
* many policies, administered by many autonomous authorities
* many naming domains, with no guarantee of global uniqueness of names and
  no single naming convention

* requirement for autonomy of domains
* requirement for high performance

Among the things which <name of spec> will address are:

* interoperability of domains which share a security infrastructure but not
  administration of security attributes
* interoperability of domains which don't share the same security
infrastructure

In order to achieve these goals, the domains need to do a variety of
things:

* Agree on the interoperable vocabulary

     - this could include
          + subject names (nouns)
          + subject attributes (adjectives)
          + assertions about subject (indicative sentences: "Bob is an
Assistant Prof.")
     - rules governing subject actions (optative sentences "Bob should be
allowed to read files")

* Agree on a syntax for the interoperable vocabulary

     - this could be
          + a universal syntax (used by all domains)
          + a transfer syntax (understood by all domains)

* Define a mechanism for making assertions

     - this should not depend on a particular protocol
          + because a pair of domains may communicate over several
protocols
     - this should not presume or require a trust relationship
          + because we don't know what trust relationships domains will
want to use
     - this should not presume or require a particular secure exchange
mechanism
          + such as SSL or a signed token
          + because some domains may not support some mechanisms
          + and because some pairs of domains may already have
            secure exchange mechanisms they use, and adding another one
            will be superfluous from a security viewpoint and will
            impose both a performance overhead and a software content
            and configuration overhead (for the code which implements
            our mechanism)

There are a number of dangers which should be avoided in achieving these
goals

* We shouldn't require agreement on subject names across domains
     - because domains already have given their subjects names and don't
       want to change them
* We shouldn't require external visibility or comprehension of resource
names
     - because each domain may want complete control over its resources
       and may not be willing or able to publicize them to other domains
* We shouldn't require one domain to enforce a policy stated by another
domain
     - because autonomy of domains requires that each domain be able to
       make independent decisions about its own policies.

My personal belief is that we should design our mechanisms to support
maximum autonomy.
This means

* We should define a transfer syntax, but NOT a universal syntax
* We should define scoped names (scoped by domain, like RFC 822 does), but
NOT global names
* We should exchange names and attributes, but NOT policies or capabilities
* We should define a mechanism for expressing assertions, but NOT a means
  of establishing the recipient's trust in the assertor
* We should ASSUME that each domain which recieves an assertion will
  re-interpret its contents
     - for example, if a domain recieves an assertion of a subject's name,
       it will translate that name into a locally-understood form
     - for example, if a domain receives an assertion of a subject's name,
       it will form its own local view of the groups to which that subject
       belongs
     - for example, if a domain recieves an assertion of a subject's group
       memberships, it may discard some of the asserted groups (as being
       "not recognized", or because the assertor is not in its view
       trusted to assert membership in these groups), and it may translate
       some of the asserted groups into other, locally-recognized groups.
     - etc...

================= end Bob's sermon on scope of activity
====================

>Evan,
>
>> But I think Anders has gotten to the kernel of this issue. I think for
>> most of us with experience with AuthXML or S2ML, we've dealt from the
>> get-go with expecting peer security systems to have arranged their
>> partnership out-of-band. In other words, there are configuration
>> options on each piece of software that say what data is sent as
>> credentials, what profile information to share, what keys belong to
>> what security system, etc.
>>
>> We explicitly have this called out in the current doc, saying that
>> "trust negotiations must be made out-of-band." I agree with Anders
>> that there's a momentous opportunity in dropping this non-goal and
>> allowing the trust relationship to be negotiated IN-band ("Who are
>> you? Who says that's you? What do you want?").
>
>I do not propose that we should solve all this IN-band.  It is largely
impossible IMO.
>Trust between parties (APs and RPs) will continue to be more or less out
of band.

I ***STRONGLY*** agree with this.  I think trust is something which needs
to be
established BASED ON (1) a trust model, (2) an authentication protocol, and
(3)
tokens of the form we exchange.  I assert that we should neither assume nor
define
a particular trust model -- instead we should define tokens which can be
exchanged within
any trust model.

If we try to turn this effort into an authentication and trust
establishment protocol
definition effort, we will never finish, AND we will limit the usefulness
of our
effort to environments which don't already have their own trust model and
authentication protocols defined.

>Regarding credentials, the parties must as already stated indeed support
the same profiles.  This is
>however something that does not always have to be performed using
hardcoded, point-to-point,
>out-of-band setups for each resource, URL etc.   That does not scale at
all IMO!

In principle I don't see how changing a given negotiation protocol from
"out-of-band" to "in-band" (by including it in our spec) changes its scale
characteristics.
I think this is just an issue of scope, and not one of function.

>If parties are able to define credential definitions that they can share,
it should be about the same work
>to define the run-time specification for the very same credentials.  This
is essentially all I am asking for.

I think what's being said here is that we should define a
"credential syntax and semantics negotiation facility" but not define the
underlying syntaxes and semantics (semantices?).

I think that we *might* consider defining a negotiation facility
but we *need not* do so.  The negotiation facility could be defined at
a later date, or different ones could be used, without any damage to
underlying facilities which support exchange of assertions based on
the understanding that they're mutually understood by all parties to the
exchange.
In the interests of simplicity, therefore, I'd prefer NOT to define
negotiation facilities this time around, but leave it as a recognized
area for future extensions.

--bob

Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.