...
For this to make sense, we would also need to see IdPs ship with the endpoint bypass logic enabled by default, which would not happen until 3.0 at the earliest. In practice, if an SP wanted to avoid registering enpodints in metadata, the cost of turning on a simple option is insignificant, and so the SP default here is fairly unimportant. It's also possible to trigger signing by the SP by means of the wantAuthnRequestsSigned flag in metadata.
Summing up:
Goal: Avoid endpoint registration.
Deployment Constraint: All IdPs have to support bypassing the endpoint check (and of course must support signed requests to begin with).
Likely Scenario: Useful only in scenarios where IdPs are known to support the feature, insignifiant cost to enable signing in the SP, some risk in changing the default, so unlikely to make sense.
Question: Should we implement any DoS mitigation in the SP?
Back-Channel
The SOAP-based profiles are where the bulk of the complexity lies. The frustrating conclusion is that there's essentially no functional advantage to avoiding mutual TLS on a dedicated port; it's by far the fastest, simplest to understand, easiest to implement, and most secure approach to the problem. So, not a huge surprise that we picked it.
What it does have, though, is some deployment costs:
Many deployers are clueless in basic web site administration or have problems supporting extra ports because of firewall issues.
Only a handful of deployers have any experience configuring TLS client authentication.
Using a single port and virtual host usually means configuring renegotiation-based TLS in a subdirectory, which has been a large source of web server bugs.
Relying on server authentication (and confidentiality) via a TLS certificate issued by a browser-friendly CA creates significant burdens for managing trust. SPs must have mechanisms for handling frequent certificate rollover by the IdP, and we all know that essentially everything but Shibboleth and simpleSAML.php don't.
Supporting TLS client authentication usually negates the off-loading of TLS to load balancers, and even then, there are substantial bugs and limitations involving certificate validity and chain size caused by bugs in Apache and some Java containers. Avoiding Apache here altogether tends to help.
The vast majority of commercial implementations fall down when it comes to doing non-traditional trust management of TLS connectivity, even if they support alternatives for message signing. Basically, they can't be bothered to do anything but call into the HTTP stack's TLS support and let it do whatever it wants to do.
Breaking Down the Model
To get into a discussion of what could be changed, we have to break down the pieces of the security problem that we're solving with mutual TLS, because we either have to reimplement each piece or agree that a loss of function is acceptable.
Request Authentication
Request Confidentiality Guarantee to Client
Server-Side Protection from MITM
Response Authentication
Response Confidentiality Guarantee to Server
Client-Side Protection from MITM
In this breakdown, I include message integrity guarantees as part of message authentication, because the technology for one generally supplies the other "for free". However, note that confidentiality protection is directional (the sender of a message needs a guarantee that its message can be confidential).
...
The only downside would be some overhead in unnecessary signing, but SOAP traffic is relatively rare and not triggered by unauthenticated activity. Mitigating this would require work on metadata extensions for attaching security policy to endpoints.
Summing up:
Goal: Allow for IdPs to ignore/disable client TLS.
Deployment Constraint: Legacy IdPs and probably other commercial variants won't support signatures, so client TLS would need to remain active.
Likely Scenario: Seems like enabling it by default could be risk-free, and exist alongside client TLS, but this would need to be tested.
Question: Should we shoot for changing this in V2.5, or wait for a 3.0? Should we develop metadata extensions to guard against interop issues?
Request Confidentiality Guarantee to Client
...
Basically, we have the client include the server's certificate (or its hash) in the signed request (assuming its verified with a TLS handshake), and the server verifies that its certificate or hash is in the request, verifying the channel. At that point, the other end of the TCP connection must have been connected to the server directly, or it wouldn't have seen that certificate at the other end of the TLS connection. Thus, the server knows that a correctly implemented client is in fact the sender of the message, and there is no MITM.
Summing up:
Goal: Protect from MITM attacks without client TLS.
Deployment Constraint: Replay/freshness checks should be in place, but channel binding would require new code (not to mention finishing that spec).
Likely Scenario: We live with things as is given the low risk, but add channel binding.
Response Authentication
As in the request case, it is possible to substitute digital signing of the response for server TLS. In this case, TLS may well be in place, but the certificate may not be trustworthy, and the signature can rely on a different key.
...
As a compatibility matter, one would assume that an unsupported signature will usually be ignored, but this would create a requirement to simultaneously allow for verification of either the signing key or the TLS certificate depending on what the client can handle.
Summing up:
Goal: Allow for IdPs to run on a single port.
Deployment Constraint: Legacy SPs and probably other commercial variants won't support signatures, so server TLS would need to remain active, and more importantly, trustable.
Likely Scenario: Seems like enabling it by default could be risk-free, and exist alongside server TLS, but this would need to be tested. In constrained scenarios, it may be possible to leave the TLS certificate out of the metadata, but not in general.
Question: Should we make single port deployment the primary 3.0 model?
Response Confidentiality Guarantee to Server
...
But in the meantime, we may have bugs/holes in the determination of whether to encrypt if we were to see IdPs deployed without client TLS enabled, which may mean waiting to recommend such an approach until they're fixed (probably until 3.0).
Summing up:
Goal: Guarantee confidentiality to client without client TLS.
Deployment Constraint: The IdP needs to know that confidentiality isn't available if client TLS isn't used.
Likely Scenario: We add channel binding and advise deployers wanting to support this in the meantime to force encryption.
Question: Does the IdP (like the SP) assume that the presence of TLS alone guarantees confidentiality?
Client-Side Protection from MITM
...
However, this doesn't work for confidentiality on the request, since the determination isn't made until we see the response. Fixing that would require an additional round trip and isn't compatible with implementations.
Summing up:
Goal: Protect from MITM attacks without server TLS.
Deployment Constraint: Replay/freshness checks should be in place, but channel binding would require new code (not to mention finishing that spec).
Likely Scenario: We live with things as is given the low risk, but add channel binding.