Status of the SP's Metadata Generation Handler

[Peter Schober]

* Sander Maijers <s.n.maijers at gmail.com> [2015-10-21 18:08]:
> I asked as I'm wondering what Shibboleth developers think of the
> current status of the Metadata Generation Handler.

Had you stated that you're not interested in reasons given by
non-developers that would have saved me some time.

> On Wed, Oct 21, 2015 at 5:01 PM, Peter Schober <peter.schober at univie.ac.at>
> wrote:
> > First and formost, an unsigned SAML Metadata document is just a plain
> > text file. Noone should be bootstrapping trust in endpoints and
> > crypographic material (public keys) based on automatically downloading
> > (and regularly re-downloading) plain text files over the Internet.
> >
> 
> What do you mean with this comment? Whether XML data is signed or
> not has no influence on its syntax (XML vs. plain) or
> confidentiality (encrypted vs. plain).

Signing has nothing to do with confidentiality (encryption has), but
with integrity (has not been modified) and authenticity (comes from
the right source).
So obviously signing has /everything/ to do with whether a piece of
plain text (be it XML or SAML Metadata or not) can be trusted by an
automated process.

> I take it you refer to the authentication and message integrity of
> the communication channel when one uses the Metadata Generation
> Handler as primary source of SAML metadata about an SP.

No, I'm explicitly NOT referring to TLS, as TLS does not give you
authenticity and integrity of the document itself.

That is a very different topic (and I don't want to talk about it
much), let me just say that TLS failure modes (or "degradation") could
be sublime and/or hard to catch in /all/ cases (and you'd need to
handle them properly in /all/ cases). While your web browser might
have ways to interactively signal some kind of problem with a TLS
connection, a library somewhere in your metadata-refreshing stack will
not. If error handling is not perfect you could lose /all/ security
(integrity and authenticity) TLS provided for the connection, blindly
putting your trust in cryptographic material in plain text files
downloaded over the Internet (open to any variant of manipulation).

Of course signed SAML Metadata also protects you against attacks not
even happening at the transport layer, e.g. hacking the server that
services up files (or the source the web server gets the file from).
It also allows you to publish signed Metadata documents anywhere, as
the location or transport channel are irrelevant.

> First of all, out-of-band SAML metadata distribution is not by
> definition secure or more secure than this.  In fact, I've never
> seen anyone do something close to thorough out-of-band
> authentication of providers of SAML metadata batches. Out-of-band
> SAML message integrity checking using signed SAML metadata batches
> is the main alternative I suppose you're preferring.

Not sure I understand. The security of SAML protocol messages has
little to do with the signature on signed SAML Metadata (batches or
otherwise).  The latter (Signed Metadata, with a signature provided by
a trusted third party) is merely used to bootstrap technical trust
into the integrity and authenticity of key material embedded in each
entity's Metadata.  It is /those/ keys (authenticated by having been
included in a SAML Metadata document with a valid signature from a
trusted source) that are consequently used to sign and encrypt SAML
protocol messages, not the Metadata signing key(s).
Also end-to-end encryption of SAML protocol messages (plus signing) is
much more than "SAML message integrity checking", it provides
everything I explained above (signing) plus confidentiality
(encryption).

> It follows that using the Metadata Generation Handler does not of
> necessity lower authentication and/or message integrity security
> compared to the alternative.

I don't follow.  Even you open up your SP to a trivial DoS attack by
signing metadata automatically on the SP (and even then you have the
issue of establishing trust into the credential used to sign the
self-hosted metadata), or your self-hosted metadata there is unsigned
and therefore (by definition) not trustworthy.

> Moreover, there is no fundamental reason why the Metadata Generation
> Handler could not put out signed SAML metadata in a way that does
> not increase DoS risk, even if that would not be the case for
> Shibboleth SP at this time.

Trying to defend the current implementation (which strongly recommends
against using the handler for the many reasons one could get that
wrong) with fictitious changes to said implementation is certainly
original.

> In the meantime, there are of course many other security mechanisms
> available to deliver authentication and message integrity, insofar
> needed. E.g. TLS, DNSSEC and pinning.

I've commented on TLS above. The others are either unable to provide
trust in real large-scale SAML deployments (how would cert pinning
achieve that?), or are largely undeployed themselfs today (DNSSEC).

> > Finally, the provided Metadata will almost certainly be incomplete,
> > i.e., you will need to add more data to it before publishing.
> > Stuffing all of that into the SP software only that a built-in
> > web-server can push it our again does not make a lot of sense.
> 
> What would be missing if you use a complete template?

My point was that you wouldn't gain much by doing so (unless you used
signing in the handler), it'd be simpler and certainly more efficient
to serve up the Metadata from the web server.
Also there are cases where you may not be able to provide a complete
template, as some data structures (e.g. REFEDS R&S Entity Category
Entity Attributes) can only be provided by a trusted third party, and
cannot be self-asserted. But the incompleteness certainly is not the
main issue.
-peter