RE: [security-services] Attribute Sharing Profile

["Philpott, Robert" <rphilpott@rsasecurity.com>]

Hi Tom,

I meant to mention this when the CD-03 document was mailed around, but
it slipped my mind.

When making proposed edit to an existing document that has achieved CD
status, please do not use a file name with "CD" in it.  The document
must be renamed to "draft" since that is its official status.  In this
case, since the last "draft" version of this document prior to CD-02
approval was posted as "sstc-saml-x509-authn-attrib-profile-draft-08",
the previous one you submitted should be named
"sstc-saml-x509-authn-attrib-profile-draft-09" and the latest one
"sstc-saml-x509-authn-attrib-profile-draft-10".

If someone were to see this document in the repository, they may be
fooled into thinking it is an approved CD.

Also, all draft documents should be uploaded to the document repository
into the folder named "A.2: Post-V2.0 Working Documents" rather than
just being emailed to the entire list. 

Cheers,

Rob Philpott
Senior Consulting Engineer
RSA Security Inc.
Tel: 781-515-7115
Mobile: 617-510-0893
Fax: 781-515-7020
Email: rphilpott@rsasecurity.com
I-name:  =Rob.Philpott


> -----Original Message-----
> From: Tom Scavo [mailto:trscavo@gmail.com]
> Sent: Wednesday, July 05, 2006 11:44 PM
> To: OASIS SSTC
> Subject: Re: [security-services] Attribute Sharing Profile
> 
> Attached is a proposed cd-04 of the Attribute Sharing Profile.  Most
> of my previous comments regarding this document have been accumulated
> in this version.  Comments that have not been incorporated are listed
> below.
> 
> --------------------------------------------------------
> Document identifier: sstc-saml-x509-authn-attrib-profile-cd-02
> 
> Comments re version cd-02 of this document (for reference):
> http://lists.oasis-open.org/archives/security-services-
> comment/200606/msg00057.html
> http://lists.oasis-open.org/archives/security-services-
> comment/200606/msg00085.html
> 
> Comments/Suggestions:
> 
> [section 2.2] The use case in subsection 2.2 is applicable to basic
> mode, but it fails to motivate encrypted mode.  Why would you encrypt
> at the message level if there were only two endpoints taking part in
> the exchange?  Discuss a use case scenario that motivates encrypted
> mode.
> 
> [line 131] The phrase "after verifying that the service provider is a
> valid requester" is problematic since client authentication is not
> required, at least in basic mode, which is what this use case
> illustrates.
> 
> [line 174] Why MUST the response contain exactly one assertion?  This
> is overly restrictive.  Indeed, I have a use case that returns two
> attribute assertions to the SP, one an assertion of federated
> attributes and the other an assertion of VO attributes.
> Unfortunatetly, this profile precludes such a scenario.
> 
> [lines 176--177] Why MUST the assertion contain exactly one attribute
> statement?  This is overly restrictive.  I don't have a use case for
> more than one attribute statement, but unless there's good reason for
> this, I'd suggest deleting these lines.
> 
> [section 4] Evidently, both the <Response> and the <Assertion> MUST be
> signed (lines 194--195 and lines 250--251, resp.).  Is this really
> necessary?  I suggest the <Assertion> MAY be signed if the situation
> warrants.
> 
> [line 245] Why MUST the response contain exactly one encrypted
> assertion?  This is overly restrictive.  Indeed, I have a use case
> that returns two attribute assertions to the SP, one an assertion of
> federated attributes (which SHOULD be encrypted) and the other an
> assertion of VO attributes (which MAY be encrypted).  Unfortunately,
> this profile precludes such a scenario.
> 
> [lines 248--249] Why MUST the assertion contain exactly one attribute
> statement?  This is overly restrictive.
> 
> [sections 4.1.2 and 4.2.2] Since both modes may employ encryption,
> most of the content in these sections should be pulled out of section
> 4 and put in sections 3 or 5.  Any content specific to the mode (such
> as the FIPS requirement) should remain in section 4, of course.
> 
> [sections 4.1.3 and 4.2.3] Since both modes may employ digital
> signatures, most of the content in these sections should be pulled out
> of section 4 and put in sections 3 or 5.  Any content specific to the
> mode (such as the FIPS requirement) should remain in section 4, of
> course.
> 
> [section 4.2.1] Does the name identifier in the response need to be
> encrypted?  Since the assertion itself is encrypted, this doesn't seem
> to be necessary, but you need to be explicit about this since
> [SAMLCore] does not specify what is to be done in this case.
> 
> [section 4.2.2] The IdP is allowed to reuse a previously established
> symmetric key only if the SP did not include a symmetric key in the
> request. As far as I can tell, this restriction is unwarranted.  If
> there is no symmetric key in the response, the SP won't know if the
> IdP used the symmetric key in the request or some other previously
> established symmetric key, so there is no point restricting the IdP's
> use of encryption in this case.  From the perspective of this profile,
> the symmetric key in the request *is* a previously established
> symmetric key, and therefore the three encryption options for the IdP
> may be safely reduced to two.
> 
> [general] Security considerations are too tightly bound to the
> protocol bits.  The normative security language is either too lax
> (basic mode) or too strict (encrypted mode).  It would be better if
> much of the security language were relegated to section 5.
> 
> [general] Encrypted mode is not properly motivated.  The use case in
> section 2 applies to basic mode, not encrypted mode.  It seems
> encrypted mode is geared more towards multi-hop web service
> frameworks, so perhaps such an example could be given (or at least
> mentioned) in section 2.
> 
> Tom Scavo
> NCSA/University of Illinois