[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. Agreed. > 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? Tom
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]