Open eCard

As pointed out in the issue, the problem is in the TCTokenVerifier.assertSameChannel function. As the comment explains, the interpretation when the code was written assumed a strong coupling between the TCToken Address and the PAOS Server.
We will revise the relevant parts of the specification and decide whether this is an allowed behaviour or not.

    private void assertSameChannel(String name, String address) throws InvalidRedirectUrlException,
        InvalidTCTokenUrlException, SecurityViolationException {
    // check that everything can be handled over the same channel
    // TR-03124-1 does not mention that redirects on the TCToken address are possible and it also states that there
    // are only two channels. So I guess we should force this here as well.
    URL paosUrl = assertURL(name, address);
    List<Pair<URL, TlsServerCertificate>> urls = ctx.getCerts();
    for (Pair<URL, TlsServerCertificate> next : urls) {
        if (! TR03112Utils.checkSameOriginPolicy(paosUrl, next.p1)) {
        String minor = ResultMinor.COMMUNICATION_ERROR;
        String errorUrl = token.getComErrorAddressWithParams(minor);
        throw new SecurityViolationException(errorUrl, FAILED_SOP);
        }
    }
    }

TR-03124-1 (page 7, section 2.1, right above figure 2) states:
"In the special case of both channels TLS-1 and TLS-2 terminating at the same domain (“Attached eID-Server”), the intermediary channel TLS-1-2 is not necessary."

This is not the case in the present example, as TLS-1=elster-epa-test.elsteronline.de and TLS-2=deveid.elsteronline.de and
hence it seems to be fully in line with TR-03124 that the Open eCard App yields a corresponding error here.

If that works with other eID-Clients, this would indicate that there is a test case missing in TR-03124-2. ;-)

TR-03130-1 is pretty clear about the number of channels the eID Client may establish. If the TCToken URL used in the activation and the ServerAddress in the TCToken differ, then more than one channels are needed.

As the topic came up again new specifications are available I decided to take another look at what is within the bounds of the latest specifications (TR-03124-1 v1.3 and TR-03130-1 v2.1.2). Furthermore this should act as a foundation for a discussion with the BSI and Governikus.

Client Perspective¶

The first thing to look at is TR-03124-1 which is the specification containing everything to know when implementing an eID client. If one leaves out the eCard API, EAC and Crypto recommendations which are not of interest for the things were talking about here.

Sec. 2.1 Communication Model describes over which channels the eID Client, the eService and the eID Server communicate.

The following pictures show the two patterns that are possible and also defines that if eService and eID Server are used in the attached scenario, then the domains of both are the same.

In the special case of both channels TLS-1 and TLS-2 terminating at the same domain (“Attached eID-Server”), the intermediary channel TLS-1-2 is not necessary. Usage of the attached model is indicated by the eService via the absence of a pre-shared key in the TC Token (see sections 2.4 and 2.5.2).

I want to stretch the fact here that the eService (TLS-1) and the eID Server (TLS-2) are operated under the same domain. And at this point in the specification we are talking about a communication pattern which should apply to the SAML case as well. Furthermore as the eID-Client detects the attached case based on the missing PSK, the whole thing can not work anymore in case the domains of the eService and the domain of SAML-Processor/eID-Server are different.

And that is the actual problem here, there is no specified way to determine the case set up in the Elster environment. Disabling the check would be not compliant to the specification. One could try to detect if there was a SAML Request in the Request Response pair returning the TCToken. But that is nothing the specification demands as it already defines the attached case as stated above.

Continuing in Sec. 2.6 SAML, we find a description of a more fine grained communication pattern of the SAML pattern which attaches the SAML-Processor to the eID-Server.

This section does not mention a special case of an attached SAML server, so from the point of view of the client implementor, the relevant part is described in Sec. 2.1. It references TR-03130-1, so lets take a look there.

Server Perspective¶

In TR-03130-1 we find the first mention of the attached SAML-Processor in Sec. 4.2.2 Interaction.

I is only mentioned that SAML Processor and eID-Server may be operated in attached mode. I fails to mention, that eService and eID-Server must operate under the same domain if an attached model is used. Please note that TR-03124-1 did not require that the entity delivering the TCToken must be operated under the same domain, but rather the entity operating TLS-1 and TLS-2.

Conclusion¶

The specification is indeed hard to follow and there is quite some room for interpretation. However one thing is clear to me. I can not see how an attached deployment can be in accordance with the requirement that the TLS-1 and TLS-2 must be operated under the same domain in case the domains of TLS-1 and TLS-2 differ which is checked by the code referenced in this issue. And in case I misinterpret this requirement, then there is missing a way to detect that TLS-12b (channel to SAML-Processor) and TLS-2 must be used for the domain check.