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] | [List Home]


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

sstc-saml-x509-authn-attrib-profile-cd-04.odt

sstc-saml-x509-authn-attrib-profile-cd-04.pdf

sstc-saml-x509-authn-attrib-profile-cd-04-marked.pdf

sstc-saml-x509-authn-attrib-profile.xsd

sstc-saml-x509-authn-attrib-profile-usecase1.odg



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]