Per-Entity Metadata Working Group

[Tom Scavo <>]

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