C_12547 - KIM 1.5.5 - Adressierung Design-Schwächen (CCC) & Weitere

Inhaltsverzeichnis

1 Änderungsbeschreibung

Mit dem KIM 1.5.5 Spezifikations-Release sollen folgende Punkte adressiert werden:

• durch CCC gemeldete sicherheitsrelevante Schwachstellen und Designschwächen bzgl. der Nachrichten-Integrität bezüglich Signatur
• Adaption der Änderungen aus dem zugehörigen KIM Security Hotfix 1.5.2-10 
• Problemszenarien im Umgang mit Fehlernachrichten und daraus unter anderem resultierenden Lastszenarien
• Behebung verschiedener technisch-fachlicher Konsistenz- und Textfehler, usw.

Basis dieser Änderungen ist der Release-Stand KIM 1.5.4

2 Adaption der Änderungen aus KIM Security Hotfix 1.5.2-10 - Schwachstellen

Die Änderungen mit dem KIM Security Hotfix 1.5.2-10 erfolgten auf dem Release-Stand KIM 1.5.2-9 und müssen äquivalent, aufbauend auf den aktuellen Release-Stand KIM 1.5.4 aufgenommen werden.

2.1 Änderungen bzgl. Prüfung von TLS-Zertifikaten

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario
Ein "reguläres" KIM Clientmodul kommuniziert mit einem "bösartigen" KIM Fachdienst, der missbräuchlich, als Serverzertifikat ein valides KIM Clientmodul Client-Server-Zertifikat verwendet (men in the middle). Voraussetzung ist Zugang zur TI und KIM.
Die Analyse der bestehenden Spezifikationslage zeigte, dass TLS-Zertifikate in KIM nicht ausreichend, gemäß der Möglichkeiten, geprüft werden und sowohl für das KIM Clientmodul als auch den KIM Fachdienst Optimierungen notwendig sind.
Die nachfolgenden Änderungen sollen eine entsprechende, mehrstufige Prüfung von TLS-Zertifikaten abbilden, welche Sicherheitsaspekte wie men in the middle, dns spoofing/cache poisoning ebenfalls adressieren.

2.1.1 Änderung in gemSpec_CM_KOMLE

geändert:

Entfällt:

A_17503-01 - Prüfung von TLS-Server-Zertifikaten in der gemSpec_BasisKTR_Consumer, da redundant

geändert:

Tabelle 1: Tab_Konf_Param Standardkonfiguration allgemeine Parameter

Parameter	Beschreibung des Parameters	Defaultwert
TLS_AUTH_KONNEKTOR	Authentifizierung des Clientmoduls gegenüber dem Konnektor bei aktivierter TLS-Verbindung (zertifikatsbasiert, Basic-Authentifizierung, ohne)	zertifikats-basiert
KONNEKTOR_TIMEOUT	Timeout für Aufrufe von  Schnittstellen des Konnektors	1 Minute
SMTP_TIMEOUT_SERVER	Timeout für Antworten vom SMTP-Server auf SMTP-Kommandos	5 Minuten
SMTP_TIMEOUT_CLIENT	Timeout für das Warten auf neue SMTP-Kommandos vom Clientsystem	5 Minuten
POP3_TIMEOUT_SERVER	Timeout für Antworten vom POP3-Server auf POP3-Kommandos	5 Minuten
POP3_TIMEOUT_CLIENT	Timeout für das Warten auf neue POP3-Kommandos vom Clientsystem	5 Minuten
TTL_VZD_DATA	Time to Live für gecachte Daten vom VZD wie Verschlüsselungs-zertifikate und Prüfergebnisse und KOM-LE-Versionen (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden)	12 Stunden
TTL_AM_DATA	Time to Live für gecachte Nutzer-Konfigurationsdaten (Operation getLimits) vom Account-Manager (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden)	12 Stunden
TTL_EMAIL_ICCSN	Time to Live für gecachte Zuordnungen von E-Mail-Adressen der Sender bzw. Empfänger zu ICCSNs von deren HBAs/SM-Bs (minimaler Wert 10 Tage; maximaler Wert 30 Tage)	30 Tage
TTL_FD_CERT	Time to Live für gecachte TLS-Server-Zertifikate, nach erfolgreicher OCSP Zertifikats-Prüfung	24 Stunden
TTL_FD_CERT_ERR	Time to Live für gecachte TLS-Server-Zertifikate, nach negativer Zertifikats-Prüfung (minimaler Wert 1 Minute; maximaler Wert 60 Minuten)	5 Minuten
TTL_PROTS	Time to Live für Protokolldateien.	30 Tage
PROT_PERF	Protokolldatei für Performance	JA
KONNEKTOR_URI	URI des DVD des Konnektors	-
CM_KAS_TIMEOUT	Timeout bei Inaktivität der Kommunikation zwischen Clientmodul und KAS	30 Sekunden
TTL_ERR_MSG	Time to Live für gecachte Informationen bzgl. bereits versendeter, gleicher KIM-Fehlerbenachrichtigungen (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden)	12 Stunden
TTL_MSG_AUTH	Zeitliche Gültigkeit des Tokens aus X-KIM-AUTH [A_28582-*] (minimaler Wert 15 Minuten; maximaler Wert 120 Minuten)	60 Minuten

2.1.2 Änderung in gemSpec_FD_KOMLE

geändert (KOM-LE-A_2144-01):

Entfällt:

KOM-LE-A_2228-01 - Ausschließliche Akzeptanz von TLS-Client-Zertifikaten von KOM-LE Clientmodulen

2.2 Änderungen bzgl. KAS-Freigabelink

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario

Im Anwendungsfall KAS – Versand KIM-Nachrichten > 15 MiB, werden E-Mail-Daten durch einen "Freigabelink" referenziert und dieser Link innerhalb einer KIM-Nachricht (KAS-Nachricht) übermittelt. Anhand des Links werden auf der Empfänger-Seite die Daten abgerufen. Eine solche KAS-Nachricht kann "missbräuchlich" gefälscht erstellt und mit einem beliebigen "Freigabelink" übermittelt werden. In der KIM-Nachrichtenverarbeitung wird dieser Link adressiert und kann so genutzt werden, um bspw. externe, öffentliche IP-Adressen von KIM-Teilnehmern zu ermitteln oder „bösartige“ Daten/Inhalte bereitzustellen. Voraussetzung ist Zugang zur TI und KIM.
Die nachfolgenden Änderungen stellen sicher, dass die wesentlichen KAS-Endpunkt-Informationen stets ermittelt werden müssen und der empfangene KAS-Link nicht unbehandelt verwendet wird.

2.2.1 Änderung in gemSpec_CM_KOMLE

geändert:

KAS-LINK Beispiele anpassen, siehe über Abschnitt https://gemspec.gematik.de/docs/gemSpec/gemSpec_CM_KOMLE/latest/#A_19360-02 

[RFC3986] in 5.5.2 Weitere Dokumente aufnehmen

Änderungen bzgl. des Fehlerfalls, der Fehlernachricht werden hier im Abschnitt "Änderungen bestehender Anforderungen der E-Mail-Fehlernachrichten" beschrieben.

2.2.2 Änderung in gemSpec_FD_KOMLE

geändert:

Hinweis:

Bildung Freigabelink KAS, inkl. Festlegungen aus [AttachmentService.yaml]:
https://{KAS-FQDN}/attachments/{version}/attachment/{id}

Beispiel Freigabelink KAS: 
https://kas.fqdn/attachments/v2.3/attachment/469bf002-701f-4362-a9bc-6585c1871250 

Entfällt:
A_19381 - KAS – Freigabelink Transportsicherheit

[RFC3986] in 6.5.2 Weitere Dokumente aufnehmen

2.3 Änderungen bzgl. Behandlung von Nachrichten die am Mail-Server des Fachdienstes eingeliefert werden

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario

Gemäß aktueller Spezifikation werden KIM-Fehlernachricht, in Annahme der Generierung durch zugelassene, technische Komponenten, weder signiert noch verschlüsselt übertragen. Eine solche Fehlernachricht kann, "missbräuchlich" erstellt, als reguläre KIM-Nachricht "getarnt" direkt übermittelt werden. Diese Nachrichten müssen sowohl der KIM Fachdienst als auch das empfangende KIM Clientmodul unbehandelt weiterleiten/zustellen. Folglich können "bösartige" (phishing, falsche Daten, ...) Nachrichten, als scheinbar reguläre KIM-Nachrichten ungeprüft, ohne Signatur und Verschlüsselung übermittelt werden. Voraussetzung ist Zugang zur TI und KIM.
Die nachfolgenden Änderungen stellen sicher, dass an zentraler Stelle, durch den KIM Fachdienst jede KIM-Fehlernachricht entsprechend behandelt wird.

2.3.1 Änderung in gemSpec_FD_KOMLE

geändert:

Entfällt:

A_20651-02 - Empfang von Fehlernachrichten des Clientmodules, muss entfallen
KOM-LE-A_2146-03 - Verarbeitung von Nachrichten entsprechend S/MIME-Profil, kann entfallen da redundant

3 Änderungen bzgl. Transportsignatur und Integritätsprüfung von KIM-Nachrichten - Design-Schwächen

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Aus CVDP-Meldung, folgendes Szenario

In KIM werden reguläre Nachrichten signiert und verschlüsselt übertragen. Dabei wird technisch nicht sichergestellt oder geprüft, ob die KIM-Absenderadresse zur Signatur bzw. technischen Identität gehört, welche die KIM-Nachricht signiert hat (vgl. S/MIME). Der Versand bietet keinen Nachweis zum Besitz des privaten Schlüsselmaterials → Kein Nachweis, dass Absender (in proximity) der berechtigten LEI angehört. Mit Kenntnis eines KIM-Accounts kann eine beliebige Umgebung mit KIM-Zugang "genutzt" werden, um KIM-Nachrichten zu versenden.
 

Ursachen

• In KIM wird lediglich mit einer "nutzbaren" SMC-B signiert, auch in Szenarien in denen mehrere SMC-B vorhanden sind
• Integritäts- und Signaturprüfung, nach Abruf einer Nachricht gibt lediglich Aussage über Validität der Signatur
• Es gilt/galt die Annahme "Versand erfolgte aus berechtigter LEI"
• Konfigurationen in Infrastruktur der LEI sowie des TI-Konnektors führen dazu, dass dieser Umstand ausgenutzt und eine nicht der Absender-Adresse zugeordnete SMC-B für die Signatur von KIM-Nachrichten genutzt werden kann

Ziele der Änderung

• Sicherstellung, dass eine KIM-Nachricht im Kontext der Identität = Telematik-ID (TID) signiert und versendet wird zu der die KIM-Absender-Adresse zugeordnet ist
• Abwärtskompatibilität
• Schnelle Umsetzbarkeit

Einordnung

• Mit Blick in die mögliche Zukunft TI & KIM 2.0 ff. wird diese Design-Schwäche generell als sicherheitsrelevant betrachtet und kann technisch bereits adressiert werden
• Eine eindeutige 1:1 Beziehung von KIM-Adresse zu Signaturzertifikat existiert aktuell nicht und würde grundlegende Änderungen oder S/MIME-Zertifikate notwendig machen
• Mit der Annahme, dass eine Identität (TID) mehrere E-Mail-Adressen und mehrere Zertifikate besitzen kann, so wie in praktischer Anwendung eine Person mehrere E-Mail-Adressen & ... besitzen kann, ist die Zuordnung der KIM-Absender-Adresse und des Signaturzertifikat zu einer TID über den VZD möglich und geeignet!
• Primäre Schwierigkeit ist die notwendige Nutzung des HBA zur Signatur beim Versand von KIM-Nachrichten, sofern die KIM-Absender-Adresse einem HBA zugeordnet ist. Bisher wurde in diesem Fall der HBA inkonsistent, lediglich zum Abruf von KIM-Nachrichten benötigt.
• Verbreitung der HBA-Nutzung in KIM hängt von Zuordnung der KIM-Adresse zu einer HBA-Identität im VZD ab
• Stand 29.10.2025 befinden sich in der PU 854 KIM-Adressen, die einem HBA zugeordnet sind. Demgegenüber stehen >200000 KIM-Adressen die einer SMC-B zugeordnet sind. Die gematik darf keine Kenntnis über die tatsächliche Nutzung dieser Adressen haben.
• Nachfolgende Maßnahmen ähnlich DomainKeys Identified Mail (DKIM)

3.1 Änderung in gemSpec_CM_KOMLE

3.1.1 Nutzung HBA im KIM-Versand

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Bisher wird der HBA, sofern diesem eine KIM-Adresse zugeordnet ist, lediglich beim Abruf von KIM-Nachrichten, für die Entschlüsselung der Daten benötigt.

Damit ein HBA für entsprechende Operationen des TI-Konnektors genutzt werden kann, wird eine "UserId" als Bestandteil des Aufrufkontextes des TI-Konnektors benötigt.

Folglich muss die "UserId" im SMTP-Benutzernamen, analog dem POP3-Benutzernamen, als optionale Komponente aufgenommen werden. SMTP- und POP3-Benutzername müssen in KIM, aufgrund struktureller Abwärtskompatibilität, weiterhin getrennt betrachtet werden.

geändert:

3.3.2.2 Verbindungsaufbau mit MTA

[...]

Um mit SM-B/HBA über den Konnektor kommunizieren zu können, werden dem KOM-LE-Clientmodul ebenfalls als Teil des SMTP-Benutzernamens, die Parameter

• MandantId
• ClientSystemId
• WorkplaceId
• KonnektorId (optional)
• UserId (optional – ist für einen Zugriff auf HBA erforderlich)

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId, WorkplaceId und UserId). Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt. Der optionale Parameter KonnektorId, als Bestandteil des Aufrufkontext für SM-B, ermöglicht die Unterstützung von Multikonnektor-Umgebungen. Er kann entfallen, wenn das Clientmodul nicht mit mehreren Konnektoren kommunizieren muss. Der optionale Parameter UserId wird nur für den Zugriff auf einen HBA benötigt und kann entfallen, wenn kein HBA erforderlich ist.

Der Aufbau des SMTP-Benutzernamens entspricht dem folgenden Muster. Die Reihenfolge entspricht der den Parametern vorangestellten Nummer.

[0] Benutzername
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— <optional> —
[1] <Domain Adresse des SMTP-Servers>:<Port>
[5] KonnektorId
[6] UserId
[...]

Abbildung 1: Abb_MTA_Nutzer_Name Format des SMTP-Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „erik.mustermann@hrst_domain.kim.telematik“,
• Domain Adresse des MTAs = „hrst_domain.kim.telematik“ und Portnummer = 465,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7
• KonnektorId = Konn_1
• UserId = 13

erwartet das Clientmodul, dass das Clientsystem ihm folgenden SMTP-Benutzernamen als String überträgt:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7#Konn_1#13

Das Beispiel ohne den übergebenen Parameter "Domain Adresse des MTAs" sieht wie folgt aus:

  erik.mustermann@hrst_domain.kim.telematik#*#1#KOM_LE#7#Konn_1#13

Das KOM-LE-Clientmodul bricht die Kommunikation mit dem entsprechende SMTP-Antwortcode ab (siehe Tabelle Tab_SMTP_Verbindung), wenn der erhaltene SMTP-Benutzername nicht alle erforderlichen Parameter enthält. Beinhaltet der SMTP-Benutzername zusätzliche optionale durch ‚#’ abgegrenzte Parameter (z. B. #KonnektorId), dann müssen diese Parameter vom Clientmodul ausgewertet werden und der Sendevorgang wird fortgesetzt.

[...]

----------------------------------------------------------

geändert:

Hinweis: Das Attribut kimData ist in [gemSpec_VZD] definiert. Für die Aktualisierung der KOM-LE-Version im Verzeichnisdienst ruft das Clientmodul die Operation SetAccount an der Schnittstelle I_AccountManager_Service am Fachdienst des Absenders auf.

Beispiel: empfaenger@hrst_domain.kim.telematik,1.5

Hinweis: Wenn die Mail-Adresse zu einem HBA-Account gehört, dann kann die Aktualisierung der KOM-LE-Version im Verzeichnisdienst erst erfolgen, nachdem ein POP3 Nachrichtenabruf erfolgt ist, da für die Aktualisierung im Verzeichnisdienst die UserID benötigt wird (für den Konnektor-Aufrufkontext zur Erzeugung des jwt).

3.1.2 Authentizität von KIM-Nachrichten

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Bisher erfolgt in KIM die Transportsignatur ausschließlich als CMS-Signatur mit einer nutzbaren SM-B-Identität (SMC-B). Dies erfolgt unabhängig davon, ob dieser Identität auch die KIM-Adresse des Absender zugeordnet ist.

Die Sicherstellung, dass eine KIM-Nachricht im Kontext einer Identität (SM-B oder HBA) versendet wird, zu der auch die KIM-Absender-Adresse zugeordnet ist, wird nachfolgend beschrieben.

Die Signatur in KIM basiert bisher ausschließlich auf einer nonQES CMS-Signatur mittels SM-B. Eine CMS-Signatur mit HBA wäre nur als QES möglich. Dieser Umstand impliziert verschiedene Probleme und ist in realer Anwendung nicht praktikabel:

• Bei jedem Versand. im Kontext HBA, ist stets PIN-Eingabe oder Komfort-Signatur-Kontext notwendig
• Das zusätzlich zur ggf. vorangegangen PIN-Eingabe zur regulären QES von u.a. eAU, eArztbrief, ...
• Komfortsignatur (nur 1-stufig für Primärsysteme gedacht) - Kontext müsste systemübergreifend verwaltet, synchronisiert werden

QES ist nicht für automatisiert, dunkel-verarbeitende (headless) Prozesse konzipiert, was in KIM häufig der Fall ist.

neu:

Schema der Angabe als Header der Mail:

X-KIM-Auth: Bearer <JWT>

Hinweise:

Die Notwendigkeit einer Identifikation eines AUT-Zertifikats zur Token-Signatur, welches der KIM-Adresse/dem KIM-Account zugeordnet ist, besteht bereits äquivalent im Kontext der Nutzung von Operationen des Interface I_AccountManager_Service [A_21387-*, A_21381-*] beim Versand oder Abruf von KIM-Nachrichten.

Die Ermittlung der TID kann anhand der beim Versand zu nutzenden VZD-Daten erfolgen. Darüber hinaus, kann anhand der Daten aus dem VZD ebenfalls eingeschränkt werden, ob eine SMC-B oder ein HBA genutzt werden muss.

Daten aus der dazu notwendigen Ermittlung lokaler Zertifikatsinformationen können synergetisch im Kontext anderer Anforderungen [KOM-LE-A_2061-*] genutzt werden.

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Zwischen KOM-LE-A_2028 und KOM-LE-A_2193 einfügen?

Information zu A_28582 - Authentisierung einer KIM-Nachricht

Eine äquivalente Änderung bzgl. der bestehenden Anforderungslage zur CMS-Signatur mit SM-B (u.a. KOM-LE-A_2052 - Quellen zur Ermittlung der SM-B des Senders beim Signieren) ist nicht zielführend, da diese den HBA-Fall nicht berücksichtigen kann. Ohnehin würden diesbezügliche  Änderungen in "alten" Clientmodulen nicht, jedoch in zukünftigen Versionen der Clientmodule, noch vor der CMS-Signatur, für sowohl SM-B als auch HBA wirken. Folglich wird eine allgemeine Lösung für sowohl SM-B als auch die HBA-Variante favorisiert, welche in der realen Nutzung eine geringe Auswirkung hat und abwärtskompatibel ist. Die Signatur mittels AUT-Zertifikat ist sowohl mit HBA als auch mit SM-B nonQES möglich und verhält sich somit analog zu der bisherigen, bekannten KIM-Nutzung.

Mit dieser Lösung wird eine mehrschichtige Authentifizierung abgebildet, da das zusätzliche Token als Authentisierungsinformation innerhalb der CMS-Signatur und E2E-Verschlüsselung übertragen wird. Somit ist erreicht, dass:

• Abwärtskompatibilität gewährleistet ist, da zusätzliche Information gegeben und die bisherigen Festlegungen nicht verändert wurden
• Ein technisch einheitlicher Nachweis besteht, dass eine KIM-Nachricht im Kontext der Identität = telematik-id (TID) signiert und versendet wird, der die KIM-Absenderadresse zugeordnet ist
• Eine schnelle Umsetzbarkeit für Industrie im Marktmodell möglich ist, da bekannte Anforderungen & Feature nachgenutzt werden können

Für die Übermittlung des Tokens wurde ein KIM-spezifischer Header "X-KIM-Auth" definiert, da das sonst übliche Header-Element Authorization (RFC 7235) für HTTP-Requests gilt und semantische Inkonsistenz sowie potenzielle Wechselwirkungen mit bspw. Security-, Mail-Gateways vermieden werden soll.

Nachfolgend wird der "aud" claim ebenfalls für die bestehende Anforderung zur Erzeugung eines JWT aufgenommen.

geändert:

3.1.3 Erweiterung Integritätsprüfung von KIM-Nachrichten

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Die Integritätsprüfung von KIM-Nachrichten im KIM Clientmodul gibt bisher lediglich die Aussage, ob eine KIM-Nachricht nicht verändert und ob diese aus einer berechtigten Leistungserbringer-Institution (LEI) versendet wurde. Dies lässt bisher keine Aussage zu, ob der Absender der KIM-Nachricht der LEI angehört bzw. die Transportsignatur dem Absender zugeordnet ist.

geändert:

Hinweis:

• Für den Prüfschritt VerifyCertificate besteht ein jeweils temporärer Edge-Case, da aufgrund der Lebensdauer von KIM-Nachrichten (dataTimeToLive in I_AccountLimit_Service) ein zu prüfendes Zertifikat zum Prüfzeitpunkt als "ungültig" gelten kann. Dieser Fall tritt bspw. dann ein, wenn SMC-B- oder HBA-Zertifikate offiziell ablaufen, die damit signierten Nachrichten beim Empfänger noch nicht abgerufen wurden. In Annahme, wird dies nur vereinzelte Nachrichten betreffen, die über langen Zeitraum nicht abgerufen oder kurz vor Ablauf des jeweiligen Zertifikats versendet wurden. Diese Szenario wird entsprechend [A_23165-*] behandelt, sodass kein Payload verloren geht.
• Die Auswertung von "nbf" bzgl. TTL_MSG_AUTH wird dezentral nicht vorgesehen, da die variable Lebensdauer von KIM-Nachrichten zentral, anhand einer Löschfrist abgebildet und im Kontext [A_23422-*] ausgewertet wird. Nachrichten, welche die Löschfrist/Lebensdauer überschreiten sind folglich nicht abrufbar und damit die Prüfung innerhalb dieser Anforderung nicht relevant.

Zur Prüfung korrespondierender Eintrag in "Tabelle 9: Tab_Verm_Sig_Prüf Vermerke mit Ergebnissen der Signaturprüfung" erfolgt in einem nachfolgenden Abschnitt.

3.2 Änderung in gemSpec_FD_KOMLE

3.2.1 Erweiterung der Prüfung der Absender-Integrität am KIM Fachdienst

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Aufgrund der Anforderung "KOM-LE-A_2098-* - Header der äußeren Nachricht" (gemSMIME_KOMLE) wird das Header-Element "X-KIM-Auth" in die äußere Nachricht übernommen, welche zum Mailserver des KIM-Fachdienst übertragen wird. Folglich ist diese Information für u.a. die nachfolgende Zwecke zentral, am KIM Fachdienst auswertbar:

• Motivation zum Update von KIM-Clientmodulen
• Generelle Erweiterung der Absenderintegrität (erst sinnvoll wenn hinreichend große Verbreitung von "X-KIM-Auth")
• Anomalie-Erkennung
• ...

geändert:

Hinweise:

• Item (3) entspricht dem Anwendungsfall Versand/Weiterleitung „an sich selbst“.
• Die oben formulierten Prüfregeln gelten nur für SMTP vom Clientmodul kommend.
• Prüfungen im Kontext des Item (2), dürfen zur Einführung des „X-KIM-Auth“-Headers für eine Übergangszeit, gemäß (4) die Prüfergebnisse nur protokollieren, ins Monitoring überführen.
• Prüfung des Zertifikats aus Token claim "x5c" gegen OCSP oder weiterführend gemäß [GS-A_4652-*] wird aus dem Grund der Erzeugung von Last an den OCSP-Endpunkten und dem Mail-Server des KOM-LE Fachdienstes sowie der folgend notwendigen Prüfung beim Empfänger nicht gefordert [KOM-LE-A_2048-*].
• Eine Prüfung der Zuordnung Telematik-ID zu Absenderadresse ist i.d.R. technisch nicht ohne direkte Aufrufe an VZD oder KIM Account Manager abbildbar. Eine entsprechende Prüfung an dieser zentralen Stelle erzeugt Abhängigkeit, Last und Fehlerpotenzial. Diese Prüfung ist bereits auf Seite des Empfängers gefordert [KOM-LE-A_2048-*].
• Die Auswertung des Token claim "nbf" legt ebenfalls die zeitliche Gültigkeit des Tokens fest, was u.a. die Wiederverwendung des Tokens einschränken kann. Der Zeitwert der Gültigkeitsdauer basiert auf der Annahme, dass die Gesamt-Verarbeitungszeit beim Versand einer KIM-Nachricht (wesentlich sind Signatur, Verschlüsselung, ggf. KAS-Upload, SMTP DATA) diesen Zeitwert nicht überschreitet.

Nachfolgend wird die Auswertung des "aud" claims bzgl. [A_19457-*] auch in bestehender Anforderung, abwärtskompatibel aufgenommen.

geändert:

3.3 Auswirkungen der Änderungen Transportsignatur und Integritätsprüfung von KIM-Nachrichten - Design-Schwächen

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

1. Harmonisierung der HBA-Nutzung in KIM
1. Analog dem Abruf von KIM-Nachrichten, benötigen HBA-assoziierte KIM-Accounts nun auch beim KIM-Versand die Angabe der "UserID" im Benutzernamen, sowie einen gesteckten HBA.
2. Es resultiert vertretbarer, analog bekannter Aufwand in Konfiguration und Nutzung
3. (Einzelfallbetrachtung) Sofern diese Änderung im Kontext der Nutzung von HBA-assoziierten KIM-Accounts nicht tragbar ist, kann über das technische Feature "Wechsel der Telematik-ID" die KIM-Adresse auch einer SMC-B zugeordnet und entsprechend genutzt werden.
2. Edge-Case: KIM-Adresse wechselt die Telematik-ID
1. Wird die KIM-Adresse des Absenders vor dem Abruf einer KIM-Nachricht beim Empfänger einer anderen Telematik-ID zugewiesen, resultiert es in einem Fehler in der Integritätsprüfung.
2. Dieser Fehlerzustand ist bei der Integritätsprüfung erkennbar und wird in einer Fehlernachricht dem Empfänger angezeigt. Der originale Payload wird bei solchen Fehlerfällen aus der Integritätsprüfung trotzdem dem Empfänger bereitgestellt [A_23165-*].
3. Beim Versand von KIM-Nachrichten werden zusätzliche, verarbeitungstechnisch aufwandsarme, performante Aufrufe von Operationen des TI-Konnektors benötigt (ReadCardCertificate, ExternalAuthenticate)
1. Dieses Vorgehen ist jedoch bereits seit KIM 1.5, im Kontext der Anforderung [A_21387-*], gefordert und wird nachgenutzt.
4. Beim Abruf von KIM-Nachrichten wird im Fall der Integritätsprüfung bzgl. Token aus "X-KIM-Auth"-Header [KOM-LE-A_2048-02], welches im Kontext eines HBA erzeugt wurde, ein zusätzlicher Aufruf der Konnektor-Operation "VerifyCertificate" notwendig.
1. Vertretbar, da in diesem Fall die Prüfung der Authentizität einer KIM-Nachricht überhaupt möglich wird.
5. Die Prüfungen auf Basis des Tokens aus dem Header-Element "X-KIM-Auth", werden entsprechende Fehlerfälle verursachen, die auf Missbrauch oder unsachgemäße Konfigurationen des TI-Konnektors rückschließen lassen.
6. Diese Lösung ist Abwärtskompatibel und sollte bei regelgerechter, sachgemäßer Nutzung sowie Konfiguration der beteiligten Komponenten keine nachteiligen Auswirkungen bieten.
7. Insgesamt wird die Authentizität in der KIM-Kommunikation gestärkt.
8. Diese technische Lösung kann in der zukünftigen Fortentwicklung nachgenutzt werden.

3.4 Betrachtung Missbrauch des Token aus "X-KIM-Auth"

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Aufgrund der Konstellation, dass mit Einführung des Header-Elements "X-KIM-Auth" auch weiterhin KIM-Systemkomponenten im Feld sind, welche diese Information noch nicht kennen sowie im Sicherheitskontext "never trust the client" bzw. dem Sicherheitsparadigma "ZeroTrust", gilt nachfolgende Betrachtung:

• Header-Element "X-KIM-Auth" wird für Primärsysteme sichtbar und könnte ("missbräuchlich") weitergenutzt werden
• Die Wiederverwendung des Tokens kann stets gemäß [A_23422-01] behandelt werden.
• Mit Blick in Zukunft, könnte Header-Element "X-KIM-Auth" durch Primärsysteme analog ausgewertet werden.
• Wird eine originale Nachricht bereits mit dem Header-Element "X-KIM-Auth" über KIM versendet, werden folgende Szenarien betrachtet (Primärsystem/Angreifer (PS); KIM Clientmodul (CM), KIM Fachdienst (FD)):
1. Sender PS -> Sender CM (alt) -> FD (alt, neu) -> Empfänger CM (alt) -> Empfänger PS
• Sender CM (alt) leitet Header-Element "X-KIM-Auth" weiter
• FD handelt gemäß [A_23422-01]
• Empfänger CM (alt) wertet Information nicht aus, wie bisher = keine Auswirkung
2. Sender PS -> Sender CM (neu) -> FD -> Empfänger CM (alt) -> Empfänger PS
• Sender CM (neu) überschreibt Header-Element "X-KIM-Auth", oder Abbruch gemäß [A_28582-*]
• FD handelt gemäß [A_23422-01]
• Empfänger CM (alt) wertet Information nicht aus, wie bisher = keine Auswirkung
3. Sender PS -> Sender CM (alt) -> FD -> Empfänger CM (neu) -> Empfänger PS
• Sender CM (alt) leitet Header-Element "X-KIM-Auth" weiter
• FD handelt gemäß [A_23422-01]
• Empfänger CM (neu) für Integritätsprüfung gemäß [KOM-LE-A_2048-02] durch
4. Sender PS -> Sender CM (neu) -> FD -> Empfänger CM (neu) -> Empfänger PS
• Sender CM (neu) überschreibt Header-Element "X-KIM-Auth", oder Abbruch gemäß [A_28582-*]
• FD handelt gemäß [A_23422-01]
• Empfänger CM (neu) für Integritätsprüfung gemäß [KOM-LE-A_2048-02] durch
5. Szenario (2) & (3) sind für den Fall, dass ein PS direkt an FD sendet analog zu betrachten.
• Verwendung des Token aus "X-KIM-Auth" an I_AccountManager_Service
  
• Token könnte für Authentisierung am KIM Account Manager genutzt werden
• Verhinderung durch abwärtskompatible Einführung und Prüfung des Token claims "aud" gemäß [KOM-LE-A_2187-07]. Angabe des Token claim "aud" wird mit [A_28582]; [A_19457-05] und durch [KOM-LE-A_2187-07];[A_23422-01]; [KOM-LE-A_2048-02] prüft
• Token claim "nbf", als Angabe zum Gültigkeitsbeginn, wird im Kontext [KOM-LE-A_2187-07] & [A_23422-01] ausgewertet, um die Wiederverwendung von Token in KIM zentral einzuschränken.

Für KIM FD wurde angenommen, dass dieser die Feature bereits zentral bereitgestellt hat.

In Folge der Betrachtung, der sicherheitstechnischen Bewertung des Kontext JWT - "replay attack", ist die Wiederverwendung eines Token aus dem Header-Element "X-KIM-Auth" als unproblematisch anzusehen, da:

• das Token in Konstellationen "alter" KIM-Komponenten nicht ausgewertet wird,
• das Token keinen Zugriff o.ä. legitimiert, sondern Aussage über die Authentizität des Absenders beim Empfänger bietet,
• die Prüfung der Authentizität im Kontext der Integritätsprüfung gegeben ist, auf Empfängerseite stattfindet,
• das Token sogar durch Primärsysteme analog ausgewertet werden könnte,
• die Wiederverwendung durch [A_23422-01] am FD erkannt werden kann,
• die Kombination der zentralen Sicherstellung der Absender-Integrität [A_23422-01] und Integritätsprüfung auf Empfänger-Seite [KOM-LE-A_2048-02] auch bei Wiederverwendung eines solchen Tokens sicherstellt, dass die Nachricht vom zugehörigen Absender stammen muss.

4 Änderungen bzgl. Ergebnis der Integritätsprüfung von KIM-Nachrichten - Design-Schwächen

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Im Kontext des Abrufs von KIM-Nachrichten erfolgt nach der Entschlüsselung eine Integritätsprüfung. Die aktuelle Umsetzung der Integritätsprüfung lässt es zu, dass im Fall technisch transienter Fehlerbilder KIM-Nachrichten nicht oder immer unbehandelt an den Empfänger ausgegeben werden. Folglich resultieren auch missbräuchlich induzierte, technisch transiente oder gänzlich persistente Fehlerbilder in einem positiven Ergebnis der Integritätsprüfung. Teil der Integritätsprüfung ist u.a. die Signaturprüfung, welche wiederum von einer Vielzahl technischer Komponenten (Konnektor, OCSP, ...) abhängig ist.

Aus Sicht der Sicherheit muss standardmäßig gelten, dass bei einem negativen Ergebnis der Integritätsprüfung, den empfangenen Daten nicht vertraut werden darf. Jedoch müssen auch in diesem Fall stets entsprechende Fehler-Informationen an den Empfänger ausgegeben werden, damit der Fehlerzustand erkannt und behandelt werden kann.

KIM wird zu einem Großteil als Transportschicht von Fachverfahren genutzt, bspw. eAU. Diese Verfahren sehen i.d.R. eine zusätzliche Authentizität des payloads vor, bspw. QES signierter eAU payload. Ein transientes Problem in der Integritätsprüfung, durch bspw. temporäre Störung OCSP, kann folglich zu massenhaften Fehlerfällen in der Verarbeitung der Fachverfahren des Empfangssystems führen. Folglich muss die Ausgabe des entschlüsselten payloads auch bei Fehlern in der Integritätsprüfung, als Teil der Fehlernachricht, konfigurativ möglich sein. Die Authentizität des payloads kann durch das Empfangssystem (nach-)geprüft werden.

Abgeleitet gilt, dass eine KIM-Nachricht nur bei positiven Ergebnis der Integritätsprüfung, ohne nachfolgend beschriebene Fehlernachricht, an den Empfänger ausgegeben werden darf (Positiv-Fall). Die nachfolgenden Änderungen adressieren ebenfalls den Bedarf nach eindeutig identifizierbaren Fehler-Informationen, welche zusätzlich maschinell auswertbar sein sollen. In früheren Iterationen von KIM konnten Informationen zu Fehlern aus der Integrationsprüfung (Signaturprüfungsbericht, Vermerke) nicht eindeutig zugeordnet werden und waren fälschbar, ausblendbar.

Die nachfolgenden Änderungen zur Fehlernachricht aus der Integrationsprüfung sind als abwärtskompatibel anzusehen. Geeignete, maschinenauswertbare Informationen außerhalb des Fließtext werden weitergenutzt und Informationen ergänzt. Es resultieren wiederum mehr Möglichkeiten & Freiheitsgrade der maschinellen Auswertung durch Primärsysteme. Bestehende Sicherheitsmechanismen in Empfänger-Umgebungen werden durch diese Änderung nicht obsolet.

4.1 Änderung in gemSpec_CM_KOMLE

geändert:

Hinweis:
• Es muss sichergestellt werden, dass eine entschlüsselte KIM-Nachricht und damit nutzbarer Payload an den Empfänger ausgegeben wird. U.a. dürfen technisch transiente Ursachen nicht dazu führen, dass ggf. zeitkritischer Payload den Empfänger nicht erreicht. Es gilt in diesen Fällen die Sorgfalt und security policies der Empfängerumgebung einzubeziehen.

• Das Dateiformat ".eml", in dem die entschlüsselte, originale Mail der Fehlernachricht angehängt wird, kann geeignet nachverarbeitet, so auch in marktüblicher E-Mail-Client-Software geöffnet/importiert werden.

• Sollten mehrere negative Ergebnisse aus der Integritätsprüfung hervorgehen KANN das Mail-Header-Attribut X-KIM-IntegrityCheckResult mehrmals verwendet werden.

Beispiel:
X-KIM-IntegrityCheckResult: 08
X-KIM-IntegrityCheckResult: X99

Anpassung Auflistung zu Fehlerfällen der Integritätsprüfung

Aufgrund der Erweiterung der Integrationsprüfung [A_23422-01] sowie Anpassung im Umgang mit Fehlern aus der Integrationsprüfung [A_23165-01], wird nachfolgend die Auflistung entsprechender Zustände angepasst.

geändert:

Tabelle 3: Tab_Verm_Sig_Prüf Vermerke mit Ergebnissen der Signaturprüfung

ID*	Fehlercode	Ergebnis
01	-	Die Signatur der Nachricht wurde erfolgreich geprüft.
02	4115	Die Integrität der Nachricht wurde verletzt.
03	4253	Die digitale Signatur ist nicht vorhanden.
04	4112	Die digitale Signatur konnte aufgrund des falschen Formats nicht geprüft werden.
05	4206	Der Zertifizierungspfad des Signaturzertifikats kann nicht validiert werden.
06	[Fehlercode]	Die digitale Signatur konnte aufgrund eines nicht zuordenbaren Fehlercodes des Konnektors nicht geprüft werden.
07	4264-	Die digitale Signatur ist mathematisch korrekt, der Zertifikatsstatus des Signaturzertifikats konnte aber nicht geprüft werden.
08	-	Die digitale Signatur ist mathematisch korrekt und der Zertifikatsstatus des Signaturzertifikats konnte erfolgreich geprüft werden, aber beim Vergleich der Header-Elemente from, sender, reply-to, to und cc der äußeren Nachricht mit denen der inneren Nachricht wurden Abweichungen festgestellt.
09	-	Die digitale Signatur ist mathematisch korrekt und der Zertifikatsstatus des Signaturzertifikats konnte erfolgreich geprüft werden, aber das recipient-emails-Attribut aus signerInfos enthält nicht die gleichen Werte wie das recipient-emails-Attribut aus dem enveloped-data CMS-Objekt.
10	-	Prüfung der Authentisierung der KIM-Nachricht (X-KIM-Auth) schlug fehl. Hinweis: Fehlertext soll <ergänzende Information zum den Fehler auslösenden Prüfschritt> angeben.

5 Veränderung bzgl. E-Mail-Fehlernachrichten des KIM Clientmoduls - Design-Schwächen

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Das KIM-Clientmodul (CM) erzeugt im Verlauf technischer Funktionen zwei differenzierbare Typen von E-Mail-Fehlernachrichten:

1. E-Mail-Fehlernachricht, die als DSN - Delivery Status Notification gemäß [RFC3461-3464] an den KIM-FD versendet wird. Empfänger ist der Absender der ursprünglichen Nachricht, in deren Kontext der Fehlerfall aufgetreten ist.
2. E-Mail-Fehlernachricht, die beim Nachrichten-Abruf generiert und direkt, an Stelle der entschlüsselten, originalen E-Mail an den abrufenden Client ausgegeben werden.

Problem-Aspekte bzgl. E-Mail-Fehlernachrichten

• Eine als DSN generierte Fehlernachricht kann schützenswerte Daten der originalen Nachricht enthalten (Header-Element oder ganze Nachricht) und wird weder signiert noch verschlüsselt übertragen.
• Es existieren keine Festlegungen zum Umgang des RET-Parameters (Werte: HDRS = nur Header, FULL = ganze Nachricht) gemäß RFC 3464.
• Ist der RET-Parameter nicht in SMTP MAIL FROM angegeben, kann das System selbst entscheiden, welche Daten zusätzlich in der DSN angegeben werden.
• Festlegungen aus KIM Hotfix 1.5.2-10 zur Anforderung A_20771-02 behandeln bereits jede definierte E-Mail-Fehlernachricht zentral als DSN.
• Gemäß RFC 3464 sollen DSN durch das tatsächlich zustellende System (MTA) generiert werden. Das KIM CM ist lediglich Proxy, sodass eine DSN-Erzeugung in CM architektonisch unsauber ist.
• Festlegungen der A_20771-02 reduzieren das Datenschutzrisiko bereits, da nur ein Text-Teil der von CM eingelieferten DSN übernommen wird.
• Folglich entstehen unnötige Komplexität und Fehlerquellen im KIM CM bzgl. der Generierung von zu versendenden E-Mail-Fehlernachrichten als DSN.
• Redundante Festlegungen an verschiedenen Stellen der Spezifikation bzgl. o.g. Fehlernachrichten, begünstigen Komplexität und Risiko heterogener, fehlerhafter Umsetzungen.

Problem-Aspekt häufig wiederholter, redundanter E-Mail-Fehlerbenachrichtigung

• Primärsysteme rufen E-Mail- Fehlerbenachrichtigungen meist nicht ab oder werten diese nicht aus.
• Automatisiert arbeitende Primärsysteme verursachen wiederholt und in großer Menge gleiche Fehlerfälle, die wiederum zu massenhaft redundanten E-Mail-Fehlerbenachrichtigung führen, die das Gesamt-System KIM und die TI belasten.
• Beispiel: Ein dunkel-verarbeitendes Labor-Primärsystem sendet pro Tag tausendfach automatisiert KIM-Nachrichten mit einem Empfänger aus KIM-fremder E-Mail-Domain (@xyz.de). Daraus resultieren in mindestens gleicher Menge E-Mail-Fehlernachrichten, u.a. gemäß KOM-LE-A_2024-*, die den gleichen Inhalt haben
• Entsprechende Problem-Fälle sind auch an anderen Stellen der Spezifikation möglich, bekannt oder vorhanden.
• Redundante Festlegungen an verschiedenen Stellen der Spezifikation bzgl. o.g. Fehlernachrichten, somit Komplexität und Risiko heterogener, fehlerhafter Umsetzungen.
  

Diese Problem-Aspekte sollen durch die nachfolgenden neuen Anforderungen adressiert werden. Diese Anforderungen erzeugen eine notwendige Abstraktion und führen zu entsprechenden Änderungen, Vereinfachung sowie Reduktion der Komplexität in bestehenden Anforderungen, ohne jedoch diesbezügliche Bestandsfunktionalität wesentlich zu verändern. Die Menge der veränderten Anforderungen, welche in ihren Teilen die Generierung von E-Mail-Fehlernachrichten behandeln, ist damit begründet, dass redundante Festlegungen in diesen Anforderungen bestehen, welche in die nachfolgenden neuen Anforderungen herausgelöst, abstrahiert werden sollen.

5.1 Änderung in gemSpec_CM_KOMLE

neu:

neu:

Hinweis:

Entsprechend spezifischere Festlegungen existieren bspw. im Kontext von [A_23165-*]

neu:

Hinweis:
Da Fehlernachrichten veränderlichen Inhalt haben können, wird ein caching anhand der normalisierten Empfängeradresse, des Fehlercodes sowie einem eindeutigen hash des Textinhalts des text/plain MIME-Parts empfohlen. So kann erkannt werden, dass ein Fehlerfall wiederholt, mit gleichem Informationskontext aufgetreten ist und verhindert werden, dass E-Mail-Fehlernachrichten mit gleicher Aussage mehrfach, in kurzem Abstand versendet wird.

5.1.1 Änderungen bestehender Anforderungen der E-Mail-Fehlernachrichten

Weitere Änderungen von A_19370-08 - Download von E-Mail-Daten (in diesem Dokument in Abschnitt 2.1.2):

Die Unterscheidung zwischen persistentem und transientem Fehler wird entfernt, da:

• im Fall des persistenten Fehler die Abbildung als multipart/mixed MIME-Nachricht nicht korrekt war,
• erhalt von Freiheits-Graden im Fall eines persistenten Fehlers
• Persistenter Fehler an einem Interface kann nicht deterministisch aussagen, ob die Daten jemals, durch bspw. organisatorische Maßnahmen, Updates, Backups, doch wieder verfügbar, abrufbar, verarbeitbar werden,
• Harmonisierung & Komplexitätsreduktion der Fehlerbehandlung im Clientmodul,
• Erhalt von ggf. wichtigen Header-Information der abgerufenen KOM-LE-S/MIME-Nachricht, auch im Falle eines persistenten Fehlers,
• Die KOM-LE-S/MIME-Nachricht bedeutet an dieser Stelle nur eine geringe Datenmenge, da es sich um die verschlüsselte KAS-Nachricht handelt, so wie sie auch in allen verwandten, Fehlerfällen an dieser Stelle zurückgegeben wird.

Tabelle 4: Tab_Fehlertext_Download Fehlertext beim Download von E-Mail-Daten

Bedingung	Fehlertext
E-Mail-Daten konnten nicht heruntergeladen werden. (transienten Fehler)	Die E-Mail-Daten dieser Nachricht konnten nicht heruntergeladen werden. Bitte leiten Sie diese Nachricht nach einer angemessenen Zeit an Ihre eigene E-Mail-Adresse (<Email Adresse>) weiter. Beim nächsten Abholen wird der Download wiederholt. Bleibt der Fehler bestehen kontaktieren sie Ihren/Ihre Systembetreuer*in.
E-Mail-Daten konnten nicht entschlüsselt werden. (persistenter Fehler)	Die E-Mail-Daten dieser Nachricht konnten nicht entschlüsselt werden, bitte kontaktieren Sie den Absender der Nachricht.
E-Mail-Daten auf dem KAS passen nicht zu der, in der KIM-Attachment-Datenstruktur, angekündigten Größe.	Die E-Mail-Daten dieser Nachricht passen nicht zu der vom Sender angekündigten Größe. Eine erneute Abholung ist nicht sinnvoll.

Hinweis: Entgegen [RFC3464] muss bei der Übermittlung der Fehlernachricht im SMTP Kommando MAIL FROM die Absenderadresse angeben werden. Es geht um die Fehlernachricht-Inhalte. Der [RFC3464] gilt nicht normativ.

Weitere:

1. In Abschnitt "3.4.1 Übersicht":
• Wenn die Integritätsprüfung der entschlüsselten KOM-LE-Nachricht fehlschlägt ... "eine Fehlernachricht an den Empfänger der KOM-LE-Nachricht gesendet zurückgegeben"
2. In Abschnitt "3.4.4.2.1 Entschlüsselung":

Absatz zum Umgang mit Entschlüsselungsfehler ändert sich wie folgt:

Wenn die Entschlüsselung fehlschlägt, wird dem Clientsystem die verschlüsselte Nachricht im Anhang einer Fehlernachricht gemäß [A_28602-*] übermittelt. Hierzu wird die angekommene KOM-LE-S/MIME-Nachricht als eine message/rfc822 MIME-Einheit in eine multipart/mixed MIME-Nachricht verpackt, die zusätzlich eine text/plain MIME-Einheit mit der Fehlermeldung enthält. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen Nachricht werden aus der ursprünglichen Nachricht übernommen. Der Betreff der neuen Nachricht enthält die Zeichenkette „Die Nachricht konnte nicht entschluesselt werden“.

6 Weiteres

6.1 Inkonsistenzen ESMTP & POP3 Capabilities

6.1.1 Änderung in gemSpec_CM_KOMLE

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Durch KIM 1.5 wurde die Möglichkeit geschaffen E-Mail-Daten bis zu 500 MB zu übermitteln. Die Kommunikation zu diesem Feature bezieht sich auf die Nutzersicht, sodass heterogene Funktionsweisen von E-Mail-Clients einbezogen werden müssen, die in KIM genutzt werden. Da E-Mail-Clients die Daten vor dem Versand, oft für den Nutzer nicht sichtbar "anpassen", nimmt die Brutto-Datenmenge durch bspw. base64-Kodierung (500 MB -> ~700 MB) zu. Daraus würde das Problem-Szenario entstehen, in dem ein Nutzer eine E-Mail mit 500 MB Datei-Anhang erstellt, diese aber nicht versenden kann, da das KIM-Clientmodul nicht die entsprechend größere Datenmenge zulässt. In solchen Fällen wären generell, aus Nutzersicht "nur" ~357 MB, statt der zugesagten 500 MB möglich.

Diese Funktionsweise ist bereits seit KIM 1.5 gegeben. Die nachfolgende Änderung passt lediglich die falsche Angabe des "alten" Werts von 35 MiB auf 700 MiB an, was ebenfalls Konsistenz zur geltenden Spezifikation bzgl. "maxMailSize" in I_AccountLimit_Service schafft.

geändert:

im Kapitel 3.3.2.1 Initialisierung

[...]

Tabelle Tab_SMTP_Ant_Init beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 5: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand

SMTP-Kommando (Clientsystem -> Clientmodul)	SMTP-Antwortcode (Clientmodul -> Clientsystem)
HELO	“250 OK” Antwortcode
EHLO	“250 OK” Antwortcode mit folgenden EHLO Kennworten: SIZE <size> AUTH LOGIN PLAIN 8BITMIME ENHANCEDSTATUSCODES DSN und <size> gleich oder größer als 35882577734003200
AUTH	Anmeldungsdaten erhalten und Verbindungsaufbau mit dem MTA beginnen (siehe Kapitel 3.2.2.2)
RSET, NOOP	„250 OK“ Antwortcode
MAIL, RCPT, DATA	„530 5.7.0“ Antwortcode (Authentication required)
QUIT	„221 OK“ Antwortcode senden und die Verbindung mit dem Clientsystem schließen
Andere Meldungen	„502  5.5.1“ Antwortcode (Invalid command)

[...]

im Kapitel 3.4.2.2 Verbindungsaufbau mit dem POP3-Server

Unter die Anforderung "KOM-LE-A_2033-01 Verbindungsaufbau mit POP3-Server über Adresse und Portnummer" wird der folgende Hinweis ergänzt:

Hinweis: Sind die POP3-Adresse und die zugehörige Portnummer nicht Bestandteil des übergebenen POP3-Benutzernamens, dann ermittelt das Clientmodul diese fehlenden Parameter mit Hilfe des übergebenen Benutzernamens (Domainanteil) und damit ausgelöster DNS Service Discovery [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery].

[...]

im Kapitel 4.1.4 Transportsicherung zwischen Clientmodul und Fachdienst

[...]

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Die Anforderung A_23225 - lokales Caching von Sperrinformationen und Toleranzzeiten (gemSpec_PKI) beschreibt Funktionalität, welche bereits Teil der zu nutzenden Operation "VerifyCertificate" ist. Folglich wäre dies redundant zu [A_22348-*], sowie nicht adäquat durch das KIM Clientmodul umsetzbar.

Die Zuordnung der Anforderung A_23225 zum KIM CM/iCM wird gelöscht.

Hinweis:

Für das lokale Caching von Sperrinformationen und für die Toleranzzeiten gilt A_23225 - lokales Caching von Sperrinformationen und Toleranzzeiten.

Die Anforderung ist wie folgt zu interpretieren:

• Als Sperrinformation gilt die Response des Konnektors zum Request VerifyCertificate.
• Die Zeit zu der die Sperrinformation erzeugt wurde ist der Zeitpunkt der Response des Konnektors.
• TUC_PKI_006 wird nicht verwendet, daher entfällt Punkt 4 der Anforderung.

6.1.2 Änderung in gemSpec_FD_KOMLE

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Für das KIM Clientmodul wird gemäß "A_23554 - Weiterleitung MAIL FROM - SIZE-Parameter" gefordert, dass der Parameter "SIZE" übermittelt werden soll. Die Unterstützung dieses Parameters muss entsprechend vom KIM Fachdienst als SMTP-Response auf SMTP EHLO angegeben werden.

Ähnliches gilt für POP3 UIDL, welches zwingend durch die Primärsysteme zu nutzen ist und durch die KIM Clientmodule weitergeleitet wird.

Folglich werden zur Konsistenzbildung entsprechende Anforderung für den KIM-Fachdienst aufgenommen, die jedoch notwendigerweise bereits technisch umgesetzt sein müssten.

neu:

in Kapitel 4.1.1 Operation send_Message

...

Beispiel Antwort SMTP-Begrüßung: 220 KOM-LE-Fachdienst ESMTP

Table # Tab_SMTP_Dialog_Fachdienst_KOM-LE

SMTP-Kommando (Clientmodul -> Fachdienst KOM-LE)	SMTP-Antwortcode (Fachdienst KOM-LE -> Clientmodul)
HELO	“250 OK” Antwortcode
EHLO	“250 OK” Antwortcode mit folgenden EHLO Kennworten: SIZE 22020096 AUTH LOGIN PLAIN 8BITMIME ENHANCEDSTATUSCODES DSN

neu:

in Kapitel Operation receive_Message

Table # Tab_POP3_Dialog_Fachdienst_KOM-LE

Clientmodul -> Fachdienst KOM-LE	Fachdienst KOM-LE -> Clientmodul
CAPA	“+OK” Antwortcode mit folgenden CAPA Kennworten: TOP USER SASL PLAIN UIDL

6.2 Änderung zur Absender-Integrität CM und Vermeidung von Folgefehler-Last

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Es traten/treten vermehrt Fehlerfälle auf, welche durch Fehladressierung an bspw. ("@xyz.de") E-Mail-Adressen begründet sind. Da eine Verarbeitung dieser Adressen gesichert Fehlerfälle sowie ggf. unnötige Abfragen an zentralen Diensten der TI (VZD) verursachen können, sollten diese Adressen direkt ignoriert und aus der Verarbeitung ausgeschlossen werden.

6.2.1 Änderung in gemSpec_CM_KOMLE

6.3 Angabe TI-User-Agent in HTTP-Requests

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Dienste und Anwendungen wie KIM (inhaltsagnostisches Transportmedium), werden zunehmend auch als Teil automatisierter Prozesse (Dunkelverarbeitung) genutzt. Dies kann zu einer unbekannten Zusatzlast, Fehlfunktionen und Stabilitätsrisiken der involvierten Systemkomponenten führen. Um zukünftig eine bessere Aussage zur Nutzung dieser Dienste und Anwendungen treffen zu können, sollen Produkttypen (in diesem Fall der KOM-LE Fachdienst & Clientmodul), bei der HTTP-Kommunikation ein zusätzliches Header-Feld namens "TI-User-Agent" mit-übermitteln. Für den KIM Fachdienst sind das u.a. die Kommunikationsbeziehungen zum VZD, BDE, TSL und für das KIM Clientmodul zu den KIM Fachdienstteilen Account Manager und KAS. Dieses Header-Feld ist auch in der bzw. für die Zukunft der TI und KIM relevant und notwendig. Folglich leitet sich identischer Nutzen auch für die KIM Fachdienstteile ab.

Generell soll zukünftig die gesamte Infrastruktur entsprechende Informationen liefern, um eine bessere Datengrundlage für Betrachtungen der Stabilität, Sicherheit und Skalierung abzubilden.

Für die Produkttypen

• Fachdienst KOM-LE
• KOM-LE-Clientmodul
• Integriertes Clientmodul KIM (KIM-iCM)
• Basis-Consumer

wird nachfolgende Anforderung aus gemSpec_Perf aufgenommen:

Die Client-ID wird über einen gemeinsamen, organisatorischen Prozess den KIM Providern bereitgestellt.

7 Änderungen gemSpec_ DS_Anbieter

Änderung der Zuordnung der Anforderung A_27098-01 - Verpflichtung zur Umsetzung des TI Security Standards zum KIM Fachdienst wurde korrigiert und ist nur noch dem Anbieter Fachdienste KOM-LE zugewiesen.

"Der Anbieter MUSS die im TI Security Standard (in seiner jeweils aktuell durch die gematik freigegebenen und veröffentlichten Fassung) festgelegten betrieblichen Pflichten in Abhängigkeit der ihm zugewiesenen Security Governance Stufe umsetzen."

8 Änderungen gemSpec_Perf

Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!

Die Performance-Anforderungen an KIM werden aktuell in zwei (A_26323, A_20129), teilweise redundanten, inkonsistenten Anforderungen abgebildet. Die marktanteiligen Spitzenlastvorgaben aus A_20129 können analog auf A_26323 angewendet werden, sodass A_20129 entfallen kann.

entfällt:

A_20129 – Performance – Fachdienst KIM – Spitzenlastvorgaben

Der Anbieter Fachdienst KIM MUSS das System so dimensionieren, dass für seine Nutzer der erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_Fachdienst_KIM: Lastvorgaben" erfüllt werden. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl aller KIM-Teilnehmer.    <=

 

Zur Erläuterung zu [A_20129]:

Der Anbieter muss die Anzahl seiner KIM-Teilnehmer kennen und sein System mindestens so dimensionieren, damit die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KIM-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).

Tabelle : Tab_gemSpec_Perf_Fachdienst_KIM: Lastvorgaben

Anwendungsfall	Datenmenge in KB	Lastanforderungen
		Anfragen [1/sec]
Nachricht über KIM-Clientmodul empfangen	100	302
	25.600	15
Nachricht über KIM-Clientmodul Download	100	302
	25.600	15
Nachricht an KIM-FD senden	100	160
	25.600	8
Nachricht von KIM-FD empfangen	100	160
	25.600	8
Aufbau TLS-Kanal zwischen KIM-Clientmodul und KIM-Fachdienst		820

[...]

Unterhalb der Anforderung A_26323-01 wird eine Erläuterung hinzugefügt.

Erläuterung zu [A_26323-*]:

Der Anbieter muss die Anzahl seiner KIM-Teilnehmer kennen und sein System mindestens so dimensionieren, damit die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KIM-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).

9 Änderungen in der gemSpec_Krypt

geändert: