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] comments re sstc-saml-holder-of-key-browser-sso-draft-10

Thanks for your comments, Scott.  They really help.  See below for
inline responses.

On Mon, Jan 5, 2009 at 10:53 AM, Scott Cantor <cantor.2@osu.edu> wrote:
>> First, the HoK Web Browser SSO Profile specifies (lines 384--385) that
>> the <samlp:AuthnRequest> element MAY be signed, yet Core specifies
>> (lines 2012--2013) that the <samlp:AuthnRequest> element SHOULD be
>> signed.
> I think core is seriously overstating the case. It's a binding-specific or
> even profile-specific question. I'd have to look, but it's probably text
> inherited from ID-FF.

In fact, in section 5 of Core, the following general requirement is given:

"A SAML protocol message arriving at a destination from an entity
other than the originating sender SHOULD be signed by the sender."

Btw, I should note that [SAML2Prof] is likewise more relaxed than
Core.  In [SAML2Prof], it says:

"The <AuthnRequest> message MAY be signed (as directed by the SAML
binding used)."

>> "If the <samlp:AuthnRequest> is not authenticated and integrity
>> protected, the information in it MUST NOT be trusted except as
>> advisory."
> That's the problem. An IdP rarely if ever "trusts" a request so it's kind of
> moot.
>> Sorry, I do not understand the above requirement.

Ah, after reading your comments, Scott, I think I understand the
origins of that statement (beyond the fact that it also appears in
[SAML2Prof]).  For example, both Web Browser SSO profiles state that
any AssertionConsumerServiceURL or AssertionConsumerServiceIndex
attributes called out in the <samlp:AuthnRequest> element have to be
"verified" by the IdP (typically by referring to metadata).  Let's
suppose, however, that the request is signed.  Does that abrogate the
IdP from its responsibility to verify the endpoint locations in
metadata?  In other words, is the IdP permitted to accept
authenticated requests from SPs that it otherwise knows nothing about?

An IdP is not required to use metadata.  Suppose an IdP decides to
accept all requests signed by a trusted private key.  Is there
anything preventing the IdP from doing so?  From a quick scan of
section 5 in Core, it appears the answer is no.  The profiles seem to
be putting forth a different point of view, however.

So it looks like we're straddling the fence between a SAML deployment
based on a traditional X.509-based PKI on the one hand (implicitly
assumed in Core) and a deployment based on SAML metadata (i.e., the
SAML V2.0 Metadata Interoperability Profile) on the other hand.  The
latter is not dependent on signed AuthnReqests.

> To make matters
>> worse, the HoK Web Browser SSO Profile specifically recommends against
>> signing in the section on Security and Privacy Considerations (lines
>> 522--523).  How do we reconcile this apparent discrepancy with regard
>> to request signing?  What are the proper requirements with respect to
>> signing the AuthnRequest?
> Well, I don't know if I'd go so far as to recommend against it, but I
> haven't ever seen a particularly compelling reason to do it either, at least
> not front-channel.

Right, in your world, SAML metadata plays a crucial role, so signed
AuthnRequests are almost redundant.

>> I know the language in the HoK Web Browser SSO Profile is
>> intentionally similar to that in the ordinary Web Browser SSO Profile,
>> but is there really a use case for multiple <saml:AuthnStatement>
>> elements?
> One issue is that you don't really gain much by limiting it.

Well, for one thing you gain simplicity of implementation at the SP.
Suppose multiple AuthnStatements were allowed.  Do they all have the
same AuthnInstant, and if not, how do you reconcile any differences?
Same question for SubjectLocality and AuthnContext.  At first glance,
one might think that multiple AuthnStatements might be a workaround
for the fact that one and only one AuthnContext is required per
AuthnStatement, but I shudder to think I might have to interpret two
such AuthnContexts in a single response.

> The challenge
> is dealing with the fact that you can get multiple assertions and multiple
> confirmation methods, and limiting the statements doesn't fix that.


> In retrospect, I think the changes involving the Statement/Subject
> relationship and the explicit requirement that every assertion refer to the
> same principal has mitigated some of the original motivation for being so
> loose about this in the text. It started more complex, got simplifiable, but
> then was never actually simplified. But I would stand by the point that it
> doesn't get much simpler anyway.

Can you briefly describe how a relying party parses the authentication
data from multiple AuthnStatements?


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