Getting a grasp on Heartbleed and IDPs

[Cantor, Scott]

On 4/10/14, 9:15 PM, "Paul B. Henson" <henson at csupomona.edu> wrote:

>So, to identify the certificates/keypairs involved, if I understand
>correctly there are:
>
>A) the certificate/keypair used on port 443 of the idp for interaction
>with end-user browsers
>B) the certificate/keypair use on port 4443 of the idp for back channel
>interaction

B normally runs on 8443, but certainly isn't limited to that. You have to
apply generalities to your own deployment.

B is the authentication credential for transport authentication of SOAP.

>C) the certificate/keypair configured in relying-party.xml as the
>security:Credential

C is the message signing credential.

>D) the public key listed in the IDPSSODescriptor section of the metadata
>E) the public key listed in the AttributeAuthorityDescriptor section of
>the metadata

These aren't separate things, those are documenting the credentials used
in B and C for other people.

>We can disregard A, as that is just a normal commercial certificate
>solely used for interaction with end-users.

It's extremely critical in the case of authentication servers, though, and
it's very relevant to ECP if you use that. It isn't part of the SAML
exchange, no.

>Currently, in my configuration, B, C, D, and E all refer to the same
>certificate/keypair.

As in mine.

>If I'm understanding correctly, C is the XML signing key, and B is the
>TLS key. So the recommendation is to make B and C different, but both B
>and C need to be in the metadata. What is the correlation between B/D and
>D/E? Does the XML signing key correspond with the IDPSSODescriptor
>metadata or the AttributeAuthorityDescriptor metadata? And then the TLS
>key corresponds with whatever one the XML signing key does not?

The TLS key is generally in both roles because there are multiple profiles
that can use SOAP, and they span them. Queries use the AA descriptor,
artifact resolution uses the IDP role. What you need in the metadata
depends on what you deploy and support.

The signing key may also need to be in both roles, but that depends on
settings. Normally you don't sign the responses in SOAP results, in which
case the signing key might not apply to the AA role. In practice, you may
well just simplify and advertise it in both.

>Well, the vulnerability is in openssl, not specifically Apache, so if
>you're running tomcat with the tomcat-native apr ssl option, the
>vulnerability is in the java application, right next to the key. At least
>for us.

Yes, that's true. I think there's evidence at this point that the speed up
from the native code is not terribly substantial, definitely less than it
used to be. And OpenSSL being the cesspool it is, I'm not sure it's a
great trade-off at this point. Something to consider.

-- Scott