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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: New Issues, Authorities and Domains


Jeff Hodges wrote:

> A couple of questions and then a comment/rant.
> 
> Hal Lockhart wrote:
> > 
> > Here are a couple of issues we should think about.
> > 
> > An Assertion is issued by an authority.
> > 
> > Assertions may be signed.
> > 
> > The name of a subject must be qualified to some domain.
>                                                   ^^^^^^^
> Are we implicitly referring to a DNS domain name here? I 
> believe so, but we need
> to be explicit, because "domain" is such an 
> overloaded/overused/ambiguous word
> (when used without qualification). 

Sorry, lazy typist. What I meant was Security Domain. This might be
expressed as a DNS domain or in some other way.

> > 2. Should SAML take any position on the relationship between the 1)
> > Authority, 2) the entity that signed the assertion, and 3) 
> the various
> > domains scattered throughout the assertion? The contrary 
> view is that is a
> > matter for private arrangement among asserting and relying parties.
> 
> overall comment: 
> 
> I think the SAML specs will need to specify a combination of 
> both "views"
> expressed in "2." (above). The specs will have to outline what the
> relationships, and meanings thereof, are between all the 
> pieces of info in an
> assertion and the context within which the assertion is 
> wielded. The specs will
> also need to describe the opportunities, and lattitude 
> thereof, for tuning said
> stuff in particular deployment contexts. 

I don't think there is a middle ground on the mandatory aspects of SAML. We
either say you MUST do such and such or we simply discuss the implications
of various choices in the security considerations section. I take it from
your message that you favor the latter course of action.

Just to be clear, the kinds of questions I have in mind are:

Can one Authority make assertions about multiple domains?
If I trust an Authority, does that mean I trust their assertions on any
domain?
If not, does the fact I trust an Authority to make assertions about subjects
from a particular domain mean that I also trust it to make assertions about
resources from that domain, or are there two (N?) lists?
Is it sensible for an Authority to issue an assertion containing a subject
from one domain and a resource from another? 

I am not implying that there are any deep unfathomable mysteries here, just
that we need to specify something.

> I've spent some time today looking at..
> 
>  An Internet Attribute Certificate Profile for Authorization
>  http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt
> 
> ..and it seems to me that the authors & reviewers of that doc 
> have already
> considered many (if not all) of the same sorts of questions 
> we have above,

I happen to be extremely familiar with that document, as I am the Security
Architect for one of the few organizations in the world that has implemented
it in an applied environment (as distinguished from a software toolkit). I
agree that it is a very fruitful source of ideas on the subject and has
certainly conditioned my view of SAML, as well as, to my knowledge,
Stephen's and Carlisle's and perhaps other people's. (I believe in stealing
good ideas wherever I can find them.)

However, the PKIX spec merely provides a number of optional mechanisms (e.g.
policyAuthority, AAControls) and little guidance for their use. In general,
Distinguished Names, while certainly making it possible to construct names
which are globally unique, does make it explicit what is name and what is
domain. For example, in CN=Hal Lockhart, OU=ASG, O=Entegrity Solutions, Inc.
it is not clear whether the domain is the OU or the O. (This is not a
criticism, I know why it was left ambigious.) Contrast this to Kerberos e.g.
hal.lockhart@entegrity.com, where the domain (realm) is explicit.

I note in passing that in AssureAccess, we consider the same attribute from
a different domain (which we call Authorization Provider) to be a different
attribute. A policy that requires the user to be a supervisor according to
some LDAP directory will not be satisfied by supervisor according to an NT
domain. The Administrator must explicitly specify a wildcard if that is
desired.  

Another point is that X.509 and PKIX do not provide explicit for
Authorization Decision Assertion functionality. Yes, I realize you can put
anything you like in an octet string, but nothing in the document suggests
that this is recommended or possible. The word entitlement does not appear
in the document and the underlying model makes a clear distinction between
and Attribute Authority and a PDP.

Hal


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


Powered by eList eXpress LLC