# TLS and Long-Term Authentication — Integration Notes

Dieses Dokument beschreibt empfohlene Schritte, Abhängigkeiten und eine kurze Roadmap zur Integration von TLS (turns) und RFC-konformer Long-Term Authentication für den `niom-turn` MVP.

Ziele
- TLS (turns) auf TCP/TLS Port 5349 (tokio-rustls / rustls)
- Long-Term Authentication (RFC 5389 / RFC 5766): Benutzerverwaltung + MESSAGE-INTEGRITY-Prüfung
- Sichere Speicherung von Credentials (keine Klartext-Passwörter in Produktion)

Empfohlene Bibliotheken
- rustls + tokio-rustls — TLS für Tokio-basierte Server
- rcgen — optional für lokale self-signed certs während Tests
- ring / argon2 / scrypt — für sichere Passwort-Hashing (statt MD5/A1 in Produktion)

Schritte (high-level)
1. TLS Listener
   - Ergänze einen TCP-Listener auf Port 5349.
   - Wrapping der TCP-Streams mit tokio-rustls using a configured ServerConfig (cert + private key).
   - Handhabe ALPN falls nötig (z. B. `webrtc` client expectations).

2. Socket Multiplexing und Protocols
   - Behalte den UDP-Listener auf 3478 für STUN/TURN (UDP). Für TLS/TCP setze eine separate Task auf.
   - Gemeinsame STUN/TURN-Nachrichtenverarbeitung (Parsing/Antworten) ist wiederverwendbar — benutze die Bibliotheks-Module (`stun.rs`, `alloc.rs`).

3. Long-Term Auth (Credentials)
   - Implementiere ein `PersistentCredentialStore`-Impl der `CredentialStore`-Trait, welches z. B. eine SQLite/Postgres-Tabelle oder Vault/Secrets-Backend nutzt.
   - Verifiziere MESSAGE-INTEGRITY gemäß RFC: Client sendet `USERNAME`, `REALM`, `NONCE` und `MESSAGE-INTEGRITY`. Der Server berechnet die HMAC-SHA1 über den Nachrichtenteil entsprechend RFC und vergleicht.
   - Verwende sichere Passwortspeicherung: speichere gehashte Passwörter (Argon2/Scrypt) und validiere beim Anmelden. Langfristige TURN-Konten sind oft server-seitig in Klartext/A1 gesetzt; für Produktion empfiehlt sich ein server-seitiges Secret, mit dem kurzfristige Credentials erzeugt werden (REST API zum Erstellen ephemerer Creds).

4. Nonce / Replay-Protektion
   - Implementiere Nonce-Generierung mit ausreichender Entropie und begrenzter Lebenszeit. Optional: zentrale Nonce-Store oder HMAC-gebundene Nonces.

5. Tests und Fallbacks
   - Automatisiere Tests: Unit-Tests für MESSAGE-INTEGRITY, Integrationstests mit `smoke_client` gegen UDP und TCP/TLS.
   - Fallback-Mode: if TLS configs not present, start UDP-only server but clearly log the insecure state.

Code-Snippets / Hinweise
- Beispiel (TLS-Server-Setup sketch):

```rust
// load cert/key
let certs = load_certs("/path/to/cert.pem")?;
let key = load_private_key("/path/to/key.pem")?;
let mut cfg = rustls::ServerConfig::builder()
    .with_safe_defaults()
    .with_no_client_auth()
    .with_single_cert(certs, key)?;
let tls_acceptor = tokio_rustls::TlsAcceptor::from(Arc::new(cfg));

let listener = TcpListener::bind("0.0.0.0:5349").await?;
loop {
    let (socket, peer) = listener.accept().await?;
    let acceptor = tls_acceptor.clone();
    tokio::spawn(async move {
        match acceptor.accept(socket).await {
            Ok(stream) => {
                // read STUN messages from the TLS stream, process same as UDP
            }
            Err(e) => tracing::error!("TLS accept failed: {:?}", e),
        }
    });
}
```

Prioritäten / Phasen
- Phase 1: Config-driven TLS listener + integration tests (low risk)
- Phase 2: Implement Persistent CredentialStore and nonce lifecycle
- Phase 3: Replace MD5/A1 usage with secure KDF-backed credential workflow (Argon2, PBKDF2)
- Phase 4: Hardening, monitoring, and deployment automation (cert renewal)

Weiteres
- Wenn du möchtest, kann ich die TLS listener-Integration direkt als PR implementieren (schrittweise: TLS listener -> tests -> credential-store wiring). Ich kann auch Beispiel-Implementierungen für `PersistentCredentialStore` mit SQLite/SQLx anbieten.