Getting a grasp on Heartbleed and IDPs

[Cantor, Scott]

On 4/10/14, 4:12 PM, "Paul B. Henson" <henson at csupomona.edu> wrote:
>
>To clarify, it is a poor practice to use the idp keypair used in the
>metadata to also serve as the HTTPS certificate for the backchannel 8443
>connection?

No, it has to be in the metadata regardless. The key hygeine issue is
reusing the XML signing key for TLS instead of using separate keys. They
can't be distinguished in SAML, that's not the point. It's the impact of
pulling the compromised key from the metadata, and how many partner
systems are running Ping Federate when you do, and will just break.

Few commercial/broken products do much with the back channel unless you're
doing artifacts.

>Our deployment currently does that; I didn't initially set it up, but my
>(evidentally flawed) understanding was that you were supposed to use the
>idp cert for the backchannel connection so remote SP's could validate it
>based on the metadata.

You need a key that's in the metadata. Using the same key is done to avoid
giving people that are PKI-impaired the requirement to juggle two keys
instead of one. I'm not PKI-impaired, so it's time I stopped being lazy
and split the keys.

>Currently, the tomcat install guide at:
>
>https://wiki.shibboleth.net/confluence/display/SHIB2/IdPApacheTomcatPrepar
>e
>
>shows the example configuration for 8443 as including:
>
>           keystoreFile="IDP_HOME/credentials/idp.jks"

We could have generated two, and documented pointing the connector at the
second one, and then we'd have to get people to safely provide two
certificates in metadata instead of just one.

It's not a simple problem to produce a workable security model if the
starting point is that people are willing to email private keys around.
There are trade-offs in what you document.

>BTW, given the "If you're paranoid, assume anything in process memory
>space might have leaked" perspective, does it really matter if you
>weren't using the idp signing key as a TLS key, given it was presumably
>in memory and potentially leaked?

It's not in memory when the vulnerability is in Apache and the key is in a
Java application.

-- Scott