[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: New Issues, Authorities and Domains
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). > Attributes must be quailfied by a domain as well. are we imagining each individual attribute-and-value being attributed to a "domain" or whether an attribute assertion, which is ostensibly a bundle of attributes-and-values, is just itself attributed to a "domain", or both? > Nigels comments in the last concall suggest that resources also need to be > qualified by domain. > [...] > 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'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, including reasoning about use of assertions (aka attribute certs (ACs) in pkix-ac509prof-06) in context, and the decisions a relying party (aka AC verifiers) must make based upon the identifying information (e.g. holder identity, issuer identity, relation of said identities with forms of authentication and authentication identities, etc.) in the assertion (aka AC). Also, it is interesting & worthwhile to note that they've made the decision to map what we've called a "domain" above (and they call a "policyAuthority") to certain attributes defined in the context of that doc. It appears to me that there is much we can learn and/or borrow from pkix-ac509prof-06 and thus it'd behoove us to examine it carefully. I've listed below particular sections that I noticed in my reading. It'd REALLY help if Stephen Farrell could chime in from his perspective as a coauthor of pkix-ac509prof-06. I'd guess that he's in the best position amongst us'ns to proprose which specific techniques/features from it are appropriate for our consideration in the SAML spec. JeffH ----- Sections from.. http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt ..that're applicable in a SAML context: 1. Introduction . . . 1.2 Attribute Certificate Distribution ("push" vs. "pull") . . . +--------------+ | | Server Acquisition | AC issuer +----------------------------+ | | | +--+-----------+ | | | | Client | | Acquisition | | | +--+-----------+ +--+------------+ | | AC "push" | | | Client +-------------------------+ Server | | | (part of app. protocol) | | +--+-----------+ +--+------------+ | | | Client | Server | Lookup +--------------+ | Lookup | | | | +---------------+ Repository +---------+ | | +--------------+ Figure 1: AC Exchanges [hmm, substitute "assertion" for "AC" and this sure looks like diagrams that've been appearing in various SAML docs. ] . . . 3. Requirements [seems like "targeting" is pretty darn similar to the "audience" notion] . . . 4.2.2 Holder [aka "subject"? has specific techniques for relating the AC (aka assertion) to the holders PKcert if the underlying authn mech used by the holder was PK-based] . . . 4.2.3 Issuer . . . 4.2.5 Serial Number [it's worth noting that the combo of issuer/sesrialNumber is the AC approach to an assertionID. ] . . . 4.2.7 Attributes . . . 4.3.2 AC Targeting [aka "audiences"] . . . 4.4 Attribute Types Some of the attribute types defined below make use of the IetfAttrSyntax type, also defined below. The reasons for using this type are: 1. It allows a separation between the AC issuer and the attribute policy authority. . . . IetfAttrSyntax ::= SEQUENCE { "domain" ==> policyAuthority [0] GeneralNames OPTIONAL, values SEQUENCE OF CHOICE { octets OCTET STRING, oid OBJECT IDENTIFIER, string UTF8String } } . . . 4.4.2 Access Identity The accessIdentity attribute identifies the AC holder to the server/service. [...] This attribute is intended to be used to provide information about the AC holder, that can be used by the AC verifier (or a larger system of which the AC verifier is a component) to authorize the actions of the AC holder within the AC verifier's system. [this is what's referred to as an "authorization identity" in SASL and SASL-based protocols, e.g. LDAP (see RFC 2829/2830); it seems to me that we don't have an analagous, explicit feature in SAML. Is it something to think about?] . . . 5. Attribute Certificate Validation This section describes a basic set of rules that all valid ACs MUST satisfy. Some additional checks are also described which AC verifiers MAY choose to implement. [e.g. "attribute assertion validation"] . . . 7.1 Attribute Encryption [appropos to our (sub)topic of encrypting various sub-chunks of an assertion. note this only applies to attribute-values, not to the holder/issuer fields. actual analogous techniques in the SAML world would depend upon XMLdsig, of course.] . . . 7.2 Proxying [anything to think about here?] . . . 7.3 Use of ObjectDigestInfo [how to relate the assertion/AC to a public key rather than one of the more human-palatable identifiers (which're encapsulated in GeneralName). Anyting to learn/borrow here?] . . . 7.4 AA Controls During AC validation a relying party has to answer the question: is this AC issuer trusted to issue ACs containing this attribute? The AAControls PKC extension MAY be used to help answer the question. . . . 8. Security Considerations [a must-read, but nothing terribly new for those who're PKI-literate] . . . --- end
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC