RE: Comments on "SAML Core Assertions, 0.2"

[Philip Hallam-Baker <pbaker@verisign.com>]

>  My comments reference document:
> 
> draft-sstc-core-vmodel-examples-01.pdf
> 
> (1) Ticket Example (1.1.2)
> 
> Defining a fixed size "small" ticket aka "assertion
> reference".
> 
> (a) Assertion_ID: This appears to be a combination of a
> ticket issuer id and an assertion number.
> 
> I do not see how 7 bytes are enough to represent 
> BOTH the ticket issuer and the assertion number. While an IP
> quartet may be enough to identify the ticket issuer (BTW, 
> I would avoid identifying this with the actual address
> of the AP server), it seems to me 8 bytes (64-bit number) would
> be minimally required to represent assertion numbers. There is no
> need to call out a specific format for the assertion number BUT we
> do need enough space so that APs can create a unique
> assertions over large time periods.

Meta-comment, no fixed length fields!

3 bytes for an assertion identifier seems reasonable to me as a 
typical length. Certainly it is ridiculous for a maximum length.



> (b) Account: This one really caused me some real difficulty. Is
> this a resolved "name" of the subject? At its simplest I would imagine
> this as a pair of strings ("alice" X "finance"). In many common cases,
> it could take the form of a X.509DN (cn=alice,ou=finance,co=...)
> or some kind of one time string token (surely at least 8-10 bytes?).
> IMHO, Most "reasonable" schemes will require a fairly large
> size representation.

I suspect that if the account ID gets much larger than 8 octets then
either:

1) We don't care about the effect on ticket size, or
2) The full account Id would not appear in the ticket.


> The question arises why such a "name" is required in addition
> to an assertion_ID? Is the main issue to ensure that the ticket 
> itself be a complete assertion about a subject(mid-page,p.7)?
> 
> (c) Authentication: I would question the need for a mandatory 
> signature
> here. The assertion itself is provided separately
> over some mutually authenticated channel between the AP and 
> RP. Why is there
> a need for a signed ticket as well? What is the threat model here?

If presentation of the ticket is being used for authentication of
the subject the ticket must be authenticated. In SSL it is typically
only the server that is authenticated.

> 2. Assertion (1.1.5)
> 
> My main comment here is that it is extremely unlikely that BizEx Hub
> will maintain AuthZ information about SPECIFIC resources at Carol's
> store (e.g., http://store.carol.test/finance) unless both
> entities belong to the same security domain. This comment
> is also relevant to the example on the bottom of p.7. Basically,
> the issue here is that Carol manages her AuthZ INDEPENDENT of
> specific AuthZ APs (sites providing authenticated users).

I would agree in that instance. However in the case of
communication between a PDP and a PEP I would not agree.

One case in which there would be cross domain communication
relating to a specific resource is the case in which the resource
is hosted on an outsourced server (e.g. Exodous, Akamai) and
the PDP is maintained locally within the enterprise to say 
things like 'yes Alice can edit the finance pages'.

> In the use-case where BizEx and Carol belong to distinct
> security domains, the BizEx hub will authenticate Alice and 
> issue some type of AuthZ information defined by the business
> relationship between Carol and BizEx. I guess the URN rights
> identifier would cover this case; alternatively (and more
> likely) Carol and BizEx will agree upon some specific 
> AuthZ XML schema to represent these rights.

Yes, I would see the URN rights id as being the way to go.

Although many if not most XML schemas use a URL in a place where 
a URN would logically be used, so end systems may well be
configured using URLs for that purpose.

> Following, thru this analysis I have one final issue: the AuthZ
> decision at Carols site is based on the assertion issued at the
> BizEx site. Let us assume that Carol utilizes a PEP ---> PDP
> type of AuthZ decision engine. In such a case, the PEP --> PDP
> protocol may need to include assertions originating from various
> different sources (BizEx exchange, SomeOther exchange, ...) 
> in determining whether a subject is permitted access to a resource. 
> This is one of the core pieces of the S2ML Authorization service
> protocol and some equivalent would be required within this
> design as well. 

I am not sure I follow, surely the complex decision making gets done
at the PDP by definition?

The question of aggregating authorization data from many sources is
a policy issue. Clearly the PDP can do this using the protocol 
proposed - I introduced the policy language/ACL example specifically
to try to elucidate this.

The PEP is going to ask questions about a particular resource and
at most cache a response from a previous question relating to
the same resource tree.


		Phill

Phillip Hallam-Baker (E-mail).vcf