Metadata "trust"
Tom Poage
signed by a well-known CA as SP encryption/signing key is to satisfy
some clients requiring identity verification by a third-party CA (cf.
high-assurance, EV, ... certs).
The same also tells me to to use their
https://.../Shibboleth.sso/Metadata URL with a
FileBackedHTTPMetadataProvider in our IdP to accommodate key/certificate
rollover when this encryption/signing certificate expires in three years.
I haven't convinced myself to buy into this quite yet, except ...
Section 4.3.3 (third bullet) of the saml-metadata-2.0 doc suggests (to
me) fetching metadata over an SSL/TLS connection is sufficient as long
as I trust the server. OK, so XML digital signature is perhaps not
absolutely required to "trust" the metadata.
Down side, the SP /Metadata URL does not provide a validUntil nor a
digital signature, and I don't know if /Metadata end point knows how to
respond to HTTP If-Modified-Since (doesn't appear to), so it looks like
I'd need to poll every so many hours/days (maxRefreshDelay).
As long as the vendor adheres to good key rollover practice, cf.
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials,
then this might be workable.
I'm wondering if the vendor is perhaps confused over differing roles of
the web server certificate vs. the SP encryption/signing cert.
Comments/suggestions/guidance?
Thanks.
Tom.
--
To unsubscribe from this list send an email to users-un...@shibboleth.net
Chad La Joie
I think most rational and informed people, by now, harbor concerns
about the entire public CA infrastructure and what, exactly, it's
providing them. That doesn't mean it's wrong but people certainly
need to take claims about CAs infallibility with a grain (or 5 pound
block) of salt. If you know their processes, and you're good with
them, then go for it.
Added to the general issues of public CAs, trusting metadata because
it's delivered over a trust SSL/TLS connection means that you are
willing to trust any information anyone with access to that server
publishes. If you know their processes, and you're good with them,
then go for it.
In both cases there are dozens of switches and knobs that can be
adjusted. In most cases you probably can get to a point where you're
comfortable. How much work that will be will depend on where you set
the bar.
I think most technical people who have to deploy this stuff at scale
unanimously agree that PKI is very brittle and a source of a great
deal of pain and that blindly trusting everything published to a
server isn't good. So we recommend self-signed certs and signed
metadata, ideally signed with an offline of HSM-protected key.
Specifically related to the metadata endpoints for the IdP and SP.
Scott and I have said repeatedly, those endpoints provide deployers a
starting point they can use to prepare their real metadata. *Staring
point*, not ending state.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Cantor, Scott
>I have a vendor telling me their decision to use an X.509 certificate
>signed by a well-known CA as SP encryption/signing key is to satisfy
>some clients requiring identity verification by a third-party CA (cf.
>high-assurance, EV, ... certs).
That doesn't mean they have to use it in dealing with you, I would note.
Nor does it mean anything if you have metadata explicitly containing it,
since it won't matter what's in the certificate.
>The same also tells me to to use their
>https://.../Shibboleth.sso/Metadata URL with a
>FileBackedHTTPMetadataProvider in our IdP to accommodate key/certificate
>rollover when this encryption/signing certificate expires in three years.
That is, well, completely wrong. It *precludes* key rollover, because the
keys in the metadata are completely driven by what's configured in the SP.
That's exactly what you can't do if you want rollover to work, because you
have to separate the metadata from the keys actually used by the SP, in
order to control when the keys get published vs. configured.
That's one of the reasons why using the metadata handler directly is a bad
idea.
>Section 4.3.3 (third bullet) of the saml-metadata-2.0 doc suggests (to
>me) fetching metadata over an SSL/TLS connection is sufficient as long
>as I trust the server. OK, so XML digital signature is perhaps not
>absolutely required to "trust" the metadata.
You should probably ignore anything that document says about trust or
metadata exchange. It was written with a total absence of understanding of
how metadata would actually work in practice. The spec covers the metadata
syntax and content, and a little bit about caching (which has been
corrected recently in errata) but the rest is essentially useless.
I tried to do a better job of explaining these issues in our wiki in the
Metadata and Trust Management topics.
That said, sure, if you trust the SSL/TLS connection, then you're
essentially getting the metadata direct from the source, and as long as
you're willing to trust the peer to tell you anything you want to know
about the peer, that's fine.
However, note that while the IdP might actually allow this safely, the SP
doesn't. If you were the SP, pulling metadata using the XML metadata
provider in the SP from an IdP does NOT validate the transport layer, ever.
>Down side, the SP /Metadata URL does not provide a validUntil nor a
>digital signature, and I don't know if /Metadata end point knows how to
>respond to HTTP If-Modified-Since (doesn't appear to), so it looks like
>I'd need to poll every so many hours/days (maxRefreshDelay).
It doesn't cache. It can supply a validUntil or cacheDuration. It can also
sign. But that makes no sense in this context, if they're going to keep
changing the key.
>As long as the vendor adheres to good key rollover practice, cf.
>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCrede
>ntials,
>then this might be workable.
It's not, see above. You CANNOT use that process if you're going to point
people directly at the metadata handler. It simply won't work.
>I'm wondering if the vendor is perhaps confused over differing roles of
>the web server certificate vs. the SP encryption/signing cert.
There is virtually no doubt of that at all.
>Comments/suggestions/guidance?
Take anything that isn't managed by a federation you trust with an extreme
amount of salt. You are essentially owning the trust relationship and
there is a very high degree of chance that unless you're really breathing
this stuff daily, it won't be right.
Honestly, the safest choice outside of TTP federation is for you to
exchange metadata with those partners out of band, and never rely on
anything involving PKIX, CAs, or remote metadata. When changes have to get
made, you schedule it with each other. It sucks, but that's why we do TTP
federation.
-- Scott
Paul Hethmon
information on this topic, but also felt the need to throw in my opinion.
The problem you are trying to solve here is one of trust, not security. In
the wild Internet, certs signed by a well-known CA are a useful means to
establish trust so you know you are really talking to "Joe's Widgets"
instead of some site scamming to get your credit card number.
In the SAML SSO world, the trust is established by configuration. If I
tell my IdP or SP to load metadata with a public certificate in it, I've
told it to trust it. End of story. What I need to do as an administrator
is determine how I trust that metadata. Do I download it from a publicly
accessible site, perhaps protected by SSL (and again that signed
certificate), do I get the metadata out of band via personal contact with
the partner? Regardless of how I establish trust, once I have that cert
(metadata), it doesn't really matter, I have made a decision to trust it.
Once I trust it, then security will flow from that trust. The SAML
messages will use that certificate to show that I'm talking to the party I
trust.
Paul
On 3/14/12 7:37 PM, "Tom Poage" <tfp...@ucdavis.edu> wrote:
Cantor, Scott
> information on this topic, but also felt the need to throw in my opinion.
Thanks...
> In the SAML SSO world, the trust is established by configuration. If I
> tell my IdP or SP to load metadata with a public certificate in it, I've
> told it to trust it. End of story. What I need to do as an administrator
> is determine how I trust that metadata. Do I download it from a publicly
> accessible site, perhaps protected by SSL (and again that signed
> certificate), do I get the metadata out of band via personal contact with
> the partner? Regardless of how I establish trust, once I have that cert
> (metadata), it doesn't really matter, I have made a decision to trust it.
I certainly agree with all that, but the point I would add is that making that decision isn't a permanent one. Or at least it doesn't have to be, and whether it is or not, and how often the decision is "renewed" *is* a security function, namely how to handle revocation and exposure to compromised keys.
-- Scott
Tom Poage
(re)anchor my thoughts on the issue, and underscored that any decision
made today doesn't have to be permanent.
I'll make it a point to reference the Metadata and Trust Management wiki
pages on the subject.
Tom.
Christopher Bongaarts
> That said, sure, if you trust the SSL/TLS connection, then you're
> essentially getting the metadata direct from the source, and as long as
> you're willing to trust the peer to tell you anything you want to know
> about the peer, that's fine.
Not to mention that there's nothing precluding the metadata at, say,
www.providerA.com from "accidentally" including bogus data for an
entityID for competitorB.com (this is one of the reasons why
automatically loading metadata, even signed metadata, is risky).
--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
Cantor, Scott
> www.providerA.com from "accidentally" including bogus data for an
> entityID for competitorB.com (this is one of the reasons why
> automatically loading metadata, even signed metadata, is risky).
That's true, but you can just apply a whitelist filter to limit that. There's also (in the SP) the Dynamic plugin that will just go after a single entity's metadata on the fly.
-- Scott
Leif Johansson
Hash: SHA1
On 03/19/2012 04:39 PM, Christopher Bongaarts wrote:
> On 3/14/2012 8:40 PM, Cantor, Scott wrote:
>
>> That said, sure, if you trust the SSL/TLS connection, then
>> you're essentially getting the metadata direct from the source,
>> and as long as you're willing to trust the peer to tell you
>> anything you want to know about the peer, that's fine.
>
> Not to mention that there's nothing precluding the metadata at,
> say, www.providerA.com from "accidentally" including bogus data for
> an entityID for competitorB.com (this is one of the reasons why
> automatically loading metadata, even signed metadata, is risky).
>
But that would break the signature, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9nVBYACgkQ8Jx8FtbMZnc0HQCfah3UWWO10ERR6vVY0GViUyWS
XqEAoI/r+5kXQHo1aeyXfzblZJc7IEgI
=LAGj
-----END PGP SIGNATURE-----
Cantor, Scott
> > say, www.providerA.com from "accidentally" including bogus data for
> > an entityID for competitorB.com (this is one of the reasons why
> > automatically loading metadata, even signed metadata, is risky).
>
> But that would break the signature, right?
The genesis of this was if you didn't sign it at all and just blindly trust SSL connections. If the threat is somebody else slipping something into the file, and it was signed, then yes, it would break. If the threat is just a legitimate signer speaking about somebody else's metadata, then it wouldn't. That's why I built the Dynamic plugin, I don't think it's the right thing to use the third party plugin to fetch metadata directly from a peer.
-- Scott
RL 'Bob' Morgan
On Mon, 19 Mar 2012, Christopher Bongaarts wrote:
> Not to mention that there's nothing precluding the metadata at, say,
> www.providerA.com from "accidentally" including bogus data for an
> entityID for competitorB.com (this is one of the reasons why
> automatically loading metadata, even signed metadata, is risky).
Right, this is entirely analogous to the main problem of the public CA
infrastructure, that in general any CA can issue a cert for any name and
relying parties will accept it because there is no basis for filtering.
The problem of "who can can be trusted to say what" is the most profound
in security (in life, perhaps).
- RL "Bob" (just sayin')
Leif Johansson
Hash: SHA1
On 03/19/2012 04:47 PM, Cantor, Scott wrote:
>>> Not to mention that there's nothing precluding the metadata
>>> at, say, www.providerA.com from "accidentally" including bogus
>>> data for an entityID for competitorB.com (this is one of the
>>> reasons why automatically loading metadata, even signed
>>> metadata, is risky).
>>
>> But that would break the signature, right?
>
> The genesis of this was if you didn't sign it at all and just
> blindly trust SSL connections. If the threat is somebody else
> slipping something into the file, and it was signed, then yes, it
> would break. If the threat is just a legitimate signer speaking
> about somebody else's metadata, then it wouldn't. That's why I
> built the Dynamic plugin, I don't think it's the right thing to use
> the third party plugin to fetch metadata directly from a peer.
gotcha and agreed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9naFwACgkQ8Jx8FtbMZnc7owCgk7WEM3jxruMwW7PoBnZSCNcp
HgcAn0KUoctEhFdJbachsqbEpJuznrjp
=EX3T
-----END PGP SIGNATURE-----