Per-Entity Metadata Working Group

[Steve Thorpe <>]

At MCNC we derive the NCTrust federation metadata by extracting out the 
InCommon entities we care about from the InCommon metadata then 
republishing those as NCTrust-metadata.xml, and this process is invoked 
manually by a human 2x/week.

We really like that the InCommon metadata's validity interval is 14 days 
rather than a shorter time. If memory serves our NCTrust publishing days 
are generally Tuesdays and Fridays, which means the NCTrust's metadata 
is generally valid for anywhere between 10-14 days (depending on when 
somebody downloads it).

If InCommon's validity interval is reduced to a shorter number (say 7 
days) then the NCTrust metadata validity would generally be somewhere 
between 3-7 days depending on when anybody downloaded it. There are a 
nagios monitors out there checking the NCTrust metadata, and those 
monitors start jumping up and down when the NCTrust metadata validity 
drops below only a few days (I can't remember how many but I think it 
might be 5 days).

Anyways that was a long story to get to the main point, which is I 
personally prefer the 14 day validity window of the InCommon metadata 
rather than a shorter one.

Thanks,

Steve



On 9/8/16 3:57 PM, Paul Caskey wrote:
> 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

--
Steve Thorpe
Sr. Advanced Services System Analyst
Email: 

Office: 919-248-1161
Mobile: 919-724-9654

Connecting North Carolina's Future Today