RE: [security-services] X509 Authn-based Attr Sharing Profile

["Scott Cantor" <cantor.2@osu.edu>]

Some additional comments, and comments on Thomas' comments...;-)

> Rick, here are some comments on the X509 profile. 
> 1.(section 1.4.1.1) It seems appropriate that the IDP should 
> decide what attributes are shareable and return them in a 
> attribute query response.. Asking for the specific set each 
> time is bound to impact performance and since we are 
> authenticating the sender, it should not pose a security 
> issue.

I don't see the performance impact. This is like saying SQL select
statements shouldn't indicate what columns to return. "select *" is always
slower.

Not to say I disagree that a wildcard query should be prohibited, it's
reasonable for the AA to configure what to release OOB. But it's always
better to just say what you want, IMHO. Why have a query syntax that can
carry attributes otherwise? The value filtering we added to 2.0 is
especially important here.

> The IDP should have a policy as to what is shareable 
> with any given SP and provide them accordingly. I would 
> propose to remove this section from the doc. Note if the 
> AttributeQuery has an option of AttributeConsumingIndex 
> similar to the AuthnRequest, that may have been used instead.

Queries don't need this, they can already be explicit. Why be implicit
instead? The only reason for the index was that a full query doesn't fit in
an AuthnRequest.
 
> 2. The document does not discuss whether Attributes should be 
> encrypted or not. Since the Assertion MUST be encrypted, 
> perhaps it should say that Attributes SHOULD NOT or MUST NOT 
> be encrypted.

I think I expressed this originally, but I'm still confused about why the
profile should mandate encryption. That just limits the usefulness, seems to
me. SAML conformance basically means that if you support attribute queries,
you MUST support encryption of the result (in varying ways). So any SAML
implementation that could handle this profile can be configured to do
encryption if the deployment requires it. Why should the profile duplicate
that requirement?

> 3. Regarding digital signatures (sections 1.3.1.3 and 
> 1.3.2.2). SAML in general usually allows for other ways to 
> authenticate, etc... msgs when using a back channel binding 
> (e.g., soap). Why can't this be used as well in this profile 
> vs. having to use dig signatures. I assume that signing just 
> the Assertion is not an alternative either?

+1, I didn't understand why both TLS and signing was required. Why not
simply defer to the SOAP binding, in a mutually authenticated fashion?

Unless the goal is auditability?

Other thoughts...

Why does the profile care whether the initial interaction is HTTP? Seems
like any use of TLS could be followed by this profile, which makes it more
general. Since that piece is out of scope of SAML (a non SAML authentication
interaction), why not leave it open? In that vein, I'd cast the roles as
attribute requester and attribute authority, rather than SP and IdP.

Also, if you want to handle both confirmation methods, you might want to
note that it's up to the requester to indicate what to use based on the
Subject in the AttributeQuery. The AA can't return holder-of-key if you ask
for bearer (see the subject matching rules in core).

On the subject of holder-of-key, is it appropriate to be so specific about
how to confirm that? This is kind of a general question, what does SAML
really require for holder-of-key? We're not very explicit about it, and
ds:KeyInfo can have anything in it. If you want real interoperability,
that's not enough. But I don't think this profile can fix that unless it
gets much more specific, and I'm not sure it should.

Lastly, section 1.4.1.2 seems to be implying that you want to use the
assertion lifetime to mean attribute lifetime. We talked at length last year
about the fact that that's not technically what it means. If you want it to
mean that for this profile, you should probably cover that in the discussion
earlier on what the assertion needs to look like.

Thx,
-- Scott