OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Credential "Negotiation" Complexity


>> > 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

>> 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

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

================ 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

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

* 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
     - 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
          + 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

* 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
     - 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
     - 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
     - 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

>> 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
tokens of the form we exchange.  I assert that we should neither assume nor
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
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
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 Blakley
Chief Scientist, Security
Tivoli Systems, Inc.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC