Per-Entity Metadata Working Group

[David Walker <>]

A couple of comments...

• 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'll also observe that we already have the same possibility with the aggregate files.
  
• 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?  If we do, perhaps it should be a topic for the people thinking about base practices for the federation, rather than us coming up with alternative mechanisms that can still be ignored. </rant>

David

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 
     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: [ [[5]] On Behalf Of
       Tom
       Scavo
       Sent: Thursday, September 08, 2016 7:47 AM
       To: Per-Entity Metadata Working Group 
       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. 
   4. 
   5. 
   6. 

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

Attachment: signature.asc
Description: OpenPGP digital signature