Draft of revision r8.3

[harrdou]

This is an update to CATS V2 to prepare for the transition to CATS v3.

https://github.com/canada-ca/CATS-STAE/blob/CATS2-updates/docs/archive/CATS_IAS_V2_0_Deployment_Profile_Draft_r8_3_en.pdf

Please review and provide feedback by adding comments to this pull request.

[lsleduc]

Hi Doug, the eGov 2.8.1.1 Binding and Security Requirements / Cyber-Auth Deployment states that SPs implementations that cannot support SOAP must still include a SingleLogoutService SOAP binding in their metadata but may contain a non functional endpoint such as an end point that refuses TCP connections . I Understand this being a work around to have the IDPs return a partial logout response to the RP that has initiated the logout. However, I think the Federation would need to validate the SingleLogoutService SOAP binding (URL) as there should be some security rules or restrictions on it. For instance, it would need to be a URL or an IP address hosted for or by the department program.... Second, how would the IDP or Credential Provider now determine between a true and a false SOAP end Point failure? Meaning, the SP's implementation does support SOAP and has a valid SingleLogoutService SOAP end point but is now failing for x reason... i think this will eventually kill the Global Logout as well as the administrative Logout scenarios as they would become unreliable.
Thanks

[harrdou]

I think you've raised 3 concerns here, so lets look at each:

Federation validation of the endpoint URL

Currently, the federation operator as well as all federation members are required to validate the URL of all service endpoints (SSO, SLO, ACS) by validating the digital signature on the peer's SAML metadata. Metadata signatures use an ICM certificate so in order to establish an illegitimate endpoint URL an attacker would need to either steal a federation member's private signing key, or else fraudulently obtain a replacement certificate from the ICM service.

Section 2.4.5.1 does require that all ICM certificates be maintained "in compliance with the Subscriber responsibilities". These used to be documented in a Certificate Policy that was published on the web, but for years all I've been able to find is broken links. If someone knows a URL where the ICM CP is published I can add a reference to it.

Validation of the endpoint IP address

This effectively requires validation of the all the DNS resource records needed to resolve the URL for each service endpoint in the metadata to an IP address. In an ideal world this validation would be done by each federation member using DNSSec. Unfortunately that is not possible today as SSC has not yet implemented DNSSec on either of the main GC parent domains (gc.ca and canada.ca). I know there are plans to do this in the future, but whether we bother making the change to CATS 2 or implement this for CATS 3 (or later) will depend on the timing. There is no point adding this to CATS v2 if it is no longer being used by the time the GC implements DNSSec.

There is also an extra safeguard in place that would confound an attacker's attempt to eavesdrop on logout requests via a DNS poisoning attack against one of the CSPs. CATS-compliant IDPs are required to perform TLS server authentication of all SP SOAP endpoints, so the attacker would also need to obtain a fraudulent but recognized TLS certificate bearing the domain name of the SOAP endpoint.

Operationally, it is a viable option to have the Federation Operator create, register and manage a single "dead" single logout service endpoint that multiple RPs could then reference. This would allow the Federation Operator to manage any "endpoint spoofing" risk on behalf of the entire federation. It would also save money by not having each affected RP doing this themselves, although the cost of implementing this is trivial: hosting this endpoint on Azure or AWS would be around $85/year.

Differentiating between different reasons for failure

What value do you see in differentiating whether propagation failed because the SP failed to process the logout request, vs failing because the RP department decided to not implement support for receiving logout requests? The desired behavior of the IDP is the same in both cases: We want to warn the user that they were not completely logged out of their session.

Ultimately, the purpose of this change is to provide a new, very low cost option to the very small number of relying parties who have decided, for over 7 years now, that they are willing to accept the additional privacy risk from not supporting single logout via a reliable communications channel. The overall motivation for this new requirement is to prevent these relying parties from creating additional privacy risks for other members of the federation in addition to themselves, as they do today.

[lsleduc]

Thanks for the clarification. To answer your question on the value added, the GCCF CSPs have implemented operational procedures to monitor the RPs application availability including the soap endpoint and report, via a Sev 3 TT, when failure occurs. Here, the CSPs would need to track a true vs false RP SOAP point failure.

[lsleduc]

Requirement eGov 2.8.2.1 Binding and Security Requirements / Cyber-Auth Deployment Details. "SP implementations MUST support SAML SOAP binding for issuance of samp2p:LogoutResponse messages" is in contradiction with the eGov 2.8.1.1 Binding and Security Requirements / Cyber-Auth Deployment solution proposal for SPs implementations that cannot support SOAP. That is to include a valid addressable but 'dead/non functional' SOAP endpoint binding that would return a TCP error or an http internal error.... and not a proper SAML SOAP response message .