]> Best Practices for Secure ICAP Deployment with Credential-Based TLS Prometheus Systems
rwd.cameron@prometheus-systems.co.za
ICAP TLS security authentication This document defines a Best Current Practice for deploying the Internet Content Adaptation Protocol (ICAP) in a secure manner. It introduces a mechanism for symmetric encryption using TLS, with client authentication based on user credentials. The aim is to provide confidentiality and integrity of ICAP traffic in modern zero-trust and content-sensitive environments.
Introduction ICAP provides offloading of content adaptation to dedicated servers but lacks native support for transport-layer security and authentication. This document offers operational guidance for deploying ICAP securely using TLS with short-lived credential-based sessions to enable multi-tenant ICAP services.
Scope This BCP is intended for ICAP implementers and administrators deploying ICAP within security-sensitive environments where plaintext transport and persistent sessions are undesirable. This is particularly applicable to public ICAP services serving multiple customers.
Authentication and Key Derivation Clients MUST authenticate using a username/password mechanism encoded via HTTP Basic Authorization header. This credential pair MUST be used to derive a 256-bit session key using PBKDF2 with SHA-256. The derived session key serves as an additional authentication layer beyond TLS transport security, enabling multi-tenant session isolation and per-customer access control within the ICAP service.
TLS Enforcement ICAP servers MUST accept connections only over TLS 1.2 or newer. The recommended port for secure ICAP ("ICAPS") is 11344. Non-encrypted connections SHOULD be rejected by default.
Session Expiry Session keys and associated TLS sessions MUST expire no later than one (1) hour after creation. Clients SHOULD re-authenticate upon session renewal.
ICAP Header Constraints Implementations MUST include the Authorization header during the initial handshake. TLS renegotiation SHOULD NOT be used. Session rekeying MUST be triggered by explicit re-authentication.
Operational Guidance
  • Session caching MUST be scoped per client based on the derived session key and authentication credentials.
  • Salt and iteration count for PBKDF2 SHOULD be dynamically generated by the server and delivered via TLS extension parameters.
  • Clients SHOULD validate server certificates using pinned keys or a trusted CA.
  • To prevent downgrade attacks, the Options response MAY advertise "Require-TLS: yes".
Security Considerations
  • Weak password policies MUST be avoided.
  • TLS session resumption SHOULD be disabled.
  • Authorization headers MUST NOT be logged or echoed in diagnostics.
IANA Considerations No new IANA actions are required by this document.
References Normative References Internet Content Adaptation Protocol (ICAP)
Appendix A. Example: ICAP over Secure TLS C: Authorization: Basic ... ]]>
Appendix B. Sample Implementation (Pseudo-code)
Client Implementation
Server Implementation