Skip to Content.
Sympa Menu

per-entity - RE: [Per-Entity] deploying TLS on the MDQ server

Subject: Per-Entity Metadata Working Group

List archive

RE: [Per-Entity] deploying TLS on the MDQ server


Chronological Thread 
  • From: Paul Caskey <>
  • To: Thomas Scavo <>, David Walker <>
  • Cc: Per-Entity Metadata Working Group <>
  • Subject: RE: [Per-Entity] deploying TLS on the MDQ server
  • Date: Thu, 8 Sep 2016 19:57:37 +0000
  • Accept-language: en-US
  • Authentication-results: spf=none (sender IP is ) ;
  • Ironport-phdr: 9a23:sP38gxEJVf/bEo0A2E2HKp1GYnF86YWxBRYc798ds5kLTJ75pMSwAkXT6L1XgUPTWs2DsrQf1LqQ7vurADFIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnY6Uy/yPgttJ+nzBpWaz4Huj7jzqNXvZFB0hD24aKg6Fx6/swKZ4tUMmoBrNKEZyx3Vr2FOdvgMg25kOATX1zr1+Ma8tKFq9yddobp1+9FJVab3ZYw5S6BVFjIrLzpz6cH240rtVwyKs0MVT2FeuRNTAAXUpEXiVZ7qsSbrnut7xCSAO8DqF/Y5VSn0vPQjcwPhlCpSb21xy2rQkMElyfsD+B8=
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

I already wrestled with the question when building the UT System federation.
Ours was set at a 7-day validity.

And we supported only TLS (so +1 to IJ's suggestion).

IMHO, we've got to stop trying to help the helpless - using TLS is just
better. There will always be those who do not validate signatures, I've seen
plenty of these deployments myself. Today, they are wide-open exposed with
zero protection (other than the fragile DNS system), so IMHO, TLS would only
help them. The rest are, IMHO, smart enough to understand the excellent doc
we'll writeup on the subject.






> -----Original Message-----
> From:
>
>
> [mailto:]
> On Behalf Of Tom
> Scavo
> Sent: Thursday, September 08, 2016 2:48 PM
> To: David Walker
> <>
> Cc: Per-Entity Metadata Working Group
> <>
> Subject: Re: [Per-Entity] deploying TLS on the MDQ server
>
> On Thu, Sep 8, 2016 at 3:23 PM, David Walker
> <>
> wrote:
> >
> > I agree with Tom about considering shortening the validity window as a
> > (probably stronger) alternative to TLS for mitigating the possibility
> > of receiving stale metadata.
>
> I don't think it's stronger...an attacker can mount a sustained DoS attack
> (by
> continually injecting stale metadata) without TLS.
>
> > I'll also observe that we already have the same possibility with the
> > aggregate files.
>
> Our aggregates have a two-week validity window. For comparison, eduGAIN
> metadata has a 4-day validity window (which is optimum IMO).
> Most federations mark their aggregates to expire in a week (but there is a
> lot
> of variation across federations).
>
> Tightening the validity window on InCommon metadata is an exercise in
> Disaster Recovery/Business Continuity. How long would it take us to rebuild
> our infrastructure from scratch? I don't know (I'll let Paul wrestle with
> that
> question :) but the validity window depends on it.
>
> > I continue to question what our obligation is to sites that do not use
> > the trust mechanisms (digital signatures for metadata, in this case)
> > we provide them. We certainly want to promulgate best practices, but
> > in the end, do we really care if a site wants to operate in a less secure
> manner?
>
> Absolutely. Take R&S SPs, for instance. An R&S SP is required to refresh and
> verify metadata automatically. The argument for supporting R&S would be
> suspect, otherwise.
>
> > If we do,
> > perhaps it should be a topic for the people thinking about base
> > practices for the federation
>
> I was thinking the very same thing.
>
> > rather than us coming up with alternative mechanisms that can still be
> > ignored. </rant>
>
> Ops can not ignore this issue. This issue has been square on our plate since
> the beginning. Why bother having strong on-boarding, credentialing,
> authentication, and authorization if in the end deployments don't verify the
> signature?
>
> Tom
>
> > On 09/08/2016 11:30 AM, Tom Scavo wrote:
> >
> > On Thu, Sep 8, 2016 at 1:51 PM, IJ Kim
> > <>
> > wrote:
> >
> > IMO, enabling TLS, specially when the word Trust is attached to it,
> > might mislead. The current mechanism for delivering metadata securely
> > is for Ops to sign it and the clients to verify its signature. It's
> > shared responsibility between Ops and the clients. I think all agrees
> > on enabling TLS is beneficial to complement the current mechanism for
> > something like mitigating stale metadata injection attacks. OTOH,
> > enabling TLS in order to provide *some* trust anchor for the clients
> > that are not verifying signature might involve more and I think that's
> > what we are debating about. Compromises on the metadata distribution
> > server implies compromises on the metadata for them and the security
> > of the server is the security of the metadata. The concerns with the
> > server security might include handling of unencrypted TLS private key
> > on the server, physical access to the server in a co-location,
> > difficulty of proving the integrity of the metadata on server at any
> > given moment, and occasional OpenSSL/TLS bugs like Heartbleed. So,
> > the concern is more people are skipping signature verification
> > believing TLS is good enough without realizing these weaknesses and
> > probably other dependencies like DNS or CAs.
> >
> > +1
> >
> > (IJ and I have always been on the same page with respect to this
> > issue)
> >
> > I think enabling TLS would be a good thing as long as it can be
> > communicated that it's not to provide a solution to the clients that
> > not verifying the signature but to complement the current mechanism.
> >
> > I don't think it's that simple. There are at least three distinct
> > groups of deployments to consider:
> >
> > 1) Deployments that refresh and verify metadata at least daily
> > 2) Deployments that do not refresh and verify metadata because their
> > SAML software is misconfigured (intentionally or otherwise)
> > 3) Deployments that do not refresh and verify metadata because their
> > SAML software doesn't support it
> >
> > The first group of deployments would (marginally) benefit from
> > commercial TLS that prevented man-in-the-middle attacks. Btw, a
> > similar benefit could be obtained by shortening the validity window on
> > metadata, so we need to include that open issue with this TLS issue.
> >
> > The third group of deployments include AD FS, Ping, and perhaps
> > others. There aren't very many of these in InCommon but we do want to
> > be inclusive. In any case, commercial TLS is not the answer for this
> > group of deployments. I believe something stronger is needed.
> >
> > The second group of deployments includes many of the deployments we
> > were discussing in the other thread. A significant proportion of site
> > administrators just don't get it, so they throw up their hands and do
> > nothing. It's probably too much to expect that a TLS option will
> > address this group as well, but that's the hope.
> >
> > We
> > might even consider starting with TLS only mdq server since the
> > benefit is clear and it might be simpler to communicate assuming the
> > overhead on response time is negligible. A side benefit might be that
> > it eliminates the possibility of using http without signature
> > verification.
> >
> > I won't rule out any option at this point but at first glance that
> > seems iffy to me.
> >
> > Tom
> >
> > On Thu, Sep 08, 2016 at 09:19:20AM -0400, Tom Mitchell wrote:
> >
> > I feel like I’m missing something in this TLS debate. Like why there’s
> > even a debate. Please illuminate me if that’s the case, and I apologize
> > in advance for being dense.
> > To me, TLS is standard stuff. I don’t think we’re talking about
> > anything more than a TLS certificate like that used
> > for [1]https://www.internet2.edu .
> > My answers to the relevant deployment questions below would be:
> > 1) Any CA in the generally trusted set, with “InCommon RSA Server CA”
> > being a likely candidate
> > 2) 3 years like the TLS certificate at [2]https://www.internet2.edu is
> > fine, whatever is normal for the chosen CA
> > 3) Revocation is handled by the CA just as it handles revocation of any
> > other TLS certificate
> >
> > On Sep 8, 2016, at 8:51 AM, Paul Caskey
> > <[3]>
> > wrote:
> > To me, it feels like you may be reading too much into the
> > requirements.
> >
> > Why not just use a regular InCommon server SSL cert like all the
> > other
> > websites?
> >
> > It mitigates certain attacks, which is what Scott (and others) was
> > talking about yesterday.
> >
> > -----Original Message-----
> > From:
> > [4]
> >
> > [[5]mailto:]
> > On Behalf
> Of
> > Tom
> > Scavo
> > Sent: Thursday, September 08, 2016 7:47 AM
> > To: Per-Entity Metadata Working Group <[6]per-
> >
> > Subject: [Per-Entity] deploying TLS on the MDQ server
> >
> > The key word on the subject line is "deploy." Personally, I'm not
> > convinced
> > that the benefits of TLS outweigh the costs (especially if we
> > tighten
> > validUntil) but in order to advance the discussion, let me ask the
> > relevant
> > deployment questions:
> >
> > 1) What CA signs the TLS server certificate?
> > 2) What is the expiration date on the TLS certificate?
> > 3) How do we handle revocation?
> >
> > I'll give one possible deployment scenario:
> >
> > 1) The metadata signing key also signs the TLS server certificate.
> > 2) TLS certificates are short-lived, on the order of days.
> > 3) Revocation is not necessary (since TLS certificates are
> > short-lived).
> >
> > The above deployment has teeth but I'm afraid it is nontrivial to
> > implement.
> > Are there other deployment scenarios that are easier to implement
> > yet
> > meet
> > our needs?
> >
> > Tom
> >
> > References
> >
> > Visible links
> > 1. https://www.internet2.edu/
> > 2. https://www.internet2.edu/
> > 3.
> > mailto:
> > 4.
> > mailto:
> > 5.
> > mailto:
> > 6.
> > mailto:
> >
> > --
> > IJ Kim, Technical Services Group
> > 100 Phoenix Drive, Suite 111
> > Ann Arbor, MI 48108
> >
> > Visit our website: www.internet2.edu
> > Follow us on Twitter: www.twitter.com/internet2 Become a Fan on
> > Facebook: www.internet2.edu/facebook
> >
> >



Archive powered by MHonArc 2.6.19.

Top of Page