RE: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-10

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

> 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."

Also probably a bit strong, but remember that you can also read SHOULD as
"unless you have a good reason not to and have thought about the question".

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

Yes, it was definitely a MAY in that profile.

> 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).

Right.

> 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?

That's really up to the IdP, that's the problem. There's nothing you can
write that gets around the fact that trust is out of scope, and ACS checking
is all about trust because what you're doing is authenticating the
destination.

You can do that using metadata (whether the request is signed or not), or
you can rely on self-assertion by a trusted SP by authenticating the
signature in some non-metadata-based way.

Or arguably you can satisfy the intent by saying "I trust anybody",
presumably by also including a user consent piece that makes it the user's
choice.

> An IdP is not required to use metadata.

Yes, but a formal metadata schema isn't the only way to verify ACS
information. (In the old days it was hand-entered.) Reading strictly, the
profile says you have to do it and doesn't say how. Reading loosely, "doing
it" could even mean making it the user's problem, but there is no consensus
on that.

> 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.

There's definitely nothing in core that would preclude that.

> The profiles seem to be putting forth a different point of view, however.

I don't think they do at the end of the day, but I concede you have to read
it somewhat loosely and it's not going to be clear what this is all about
unless you have experience implementing and deploying.

> 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.

Core certainly doesn't assume anything about a PKI. It doesn't preclude it
of course. But the thing in the original profile that leads away from signed
requests is the idea that verifying the ACS might require more than just
trusting the SP to self-assert that the location belongs to it.
 
> Right, in your world, SAML metadata plays a crucial role, so signed
> AuthnRequests are almost redundant.

It has more to do with where you bake in an assumption about who is trusted
to provide the things that happen to be in metadata. I would argue that
basing the design on metadata (with a small m) is vastly more flexible
because it still permits self-assertion of that information, whereas not
having it limits you to self-assertion.

> 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?

You don't care, and the profile doesn't require you to.

> 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.

If there are two, it's entirely undefined which one you use, but that's very
easy to implement. You may find it ambiguous, but that's not the same
argument. I'm only saying it's easy to implement.

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

Pick one. I can only say that's how I did it, and I believe that's supported
by the text.

-- Scott