RE: [security-services] SubjectType and multiple NameIdentifier,SubjectC

On the focus subgroup concall of October 9th I was assigned an action item to "write up background semantics and background assumptions on relationships btwn NameIdentifier(s) and subjectConfirmation(s) within Subject elements".

Summary

Lines 364-371 of Core-19 provide the schema for the <Subject> element as follows:

</choice>

</complexType>

From this schema we can see that a single <Subject> may have an arbitrary number of <NameIdentifier>’s, <SubjectConfirmation>’s, and <AssertionSpecifier>’s. The question is; what does it mean when a <Subject> contains more than one of these sub-elements (i.e. (two <NameIdentifier>’s) or (one <NameIdentifier> and one <SubjectConfirmation>) etc.)? Lines 357-362 of Core-19 state that:

If a <Subject> element contains more than one subject specification the issuer is asserting that the statement is true for all of the subjects specified. For example if both a <NameIdentifier> and a <SubjectConfirmation> element are present the issuer is asserting that the statement is true of both parties.

The definition of a <Subject> element that intentionally identifies more than one principal is deprecated.

Although the “both parties” wording is a bit confusing (implying, as it does, that there are two parties), nevertheless it seems clear that what is meant is that all the “subject specifications” refer to a single global principal that is identified in a number of different ways.

Hypothetical Use Case

One use case that could motivate these semantics is single sign-on into a federated domain of legacy applications that identify principals in different ways. For example, say I have built a SAML authentication layer on top of two sets of applications, Set A and Set B. To the applications in “Set A” I am known as “/…/dev.e2open.cell/users/gpilz” and to “Set B” I am known as “C=US, ST=California, L=Belmont, O=E2open, OU=Dev, CN=gpilz@e2open.com”. Given that there is only one Authentication Authority for this federated domain the question is “Does the Authentication Authority generate two separate Authn Assertions, one for Set A and one for Set B, each of which contains a single subject specifier, or do I generate a single Authn Assertion that contains multiple specifiers that can be consumed by either Set A or Set B”? Core-19 allows for the later but does not preclude the former.

The main idea here is that PEPs and other relying parties would selectively ignore those subject specifiers that didn’t make sense to them.

Other References

The F2F#3 whiteboard design (http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-Notes-Hodges-WhiteboardTranscription.pdf) outlines the contents of a “Subject” in four different places. Although there is a slight variation in the contents in some of these outlines (“holder of key” and “assertion ID” are present in some versions and missing in others), every outline presents “Subject” as a union of either a “[security domain, name]”, “bearer”, “holder of key”, or “assertion ID”. Also notable is that there are no “*” or “+” adornments indicating that there can be more than one of any of these elements. Applied to Core-19 schema this would mean that a <Subject> could contain either a singe<NameIdentifier>, a single <SubjectConfirmation>, or a single <AssertionSpecifier>.

Critique

Although the hypothetical use case outlined above is certainly plausible, there are a number of problems with the current design. For instance, suppose a PEP in an application in Set A submits an <AuthorizationQuery> containing a multi-specified <Subject> against a global PDP and receives back a <Response> that contains a <Subject> with a single specifier that it doesn’t understand? The same question applies to <AttributeQuery>’s as well. In addition to this, what happens when a PDP receives an <AuthorizationQuery> containing a multi-specified <Subject> and its internal policy database contains conflicting policies for one or more of the specifiers?

The Core-19 design optimizes for the hypothetical use case at the expense of creating a bunch of very sticky problems. The hypothetical use case is completely supported by an Authentication Authority that creates multiple Authentication Assertions each of which contains a single <Subject> with a single specifier. PEP’s and other relying parties are free to ignore Authn Assertions containing <Subject>’s that they do not understand, but the possibility of posing potentially ambiguous queries (Did he mean “/…/dev.e2open.cell/users/gpilz” or “C=US, ST=California, L=Belmont, O=E2open, OU=Dev, CN=gpilz@e2open.com”?) is removed.

Proposal

I propose that lines 357 through 362 of Core-19 should be removed and the schema for <Subject> should be changed to read:

</choice>

</complexType>

Gilbert W. Pilz Jr.
Security Architect
DIR: 650.226.1765

CELL: 831.239.3736
gpilz@e2open.com

E2open
1075 Old County Road
Belmont, CA. 94002
www.e2open.com

TEL: 650.769.3700

FAX: 650.591.2501

security-services message