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


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