All transactions that have monetary value or pass authentication credentials MUST run over encrypted (e.g. TLSv1, SSL or VPN) or physically secure network connections. Alternately the payload itself may be encrypted to similar strength, e.g. using [XMLENC].
For a network to be considered secure, it must achieve a security level equivalent to using any of the following cipher suites (assuming safe and sound key management practises):
DSA1024-SHA1-AES128-CBC
TLS_RSA_WITH_AES_128_CBC_SHA
This compliance requirement satisfies Reqs. D1.2-2.21-DataProtLaw and D1.2-6.11-Confid.
All digital signatures MUST achieve at least the security level equivalent to using any of the following cipher suites (assuming safe and sound key management practises):
RSA1024-SHA1
DSA1024-SHA1
See threat T141-AltSig.
When data is signed, the intended recipient (see Audience) MUST verify the signature and MUST reject the operation if the verification fails. Verification of the signature MUST include in addition to the actual crypto operations, establishing that the signature was generated by the claimed trusted source.
For each verification, whether failed or successful, audit trail items MUST be generated, documenting at least
Signed data or its message digest (e.g. SHA1)
Who signed and how his trustworthiness was established
Date of signature and vertification and the credibility of both
Outcome of the verification
In case of verification failure due to failed message digest, the input to the message digest function
In case of verification failure due to failed public key crypto operation, the input to the operation (e.g. the message digest of the signed data).
See threat T141-AltSig.
Whenever long lived or revocable credentials are used (e.g. public key in signature verification), a revocation list or online status service (e.g. OCSP) SHOULD be consulted. If credential is SAML assertion, then long lived means more than 60 seconds. The revocation check SHOULD be done using Assertion Query Profile described in [SAML2prof].
The result MAY be cached for efficiency for duration indicated in relevant protocol and architecture specifications, but lacking clear indication, it should not be cached for longer than risk assessment dictates (if you are confused, do not cache for more than 10 seconds).
All signature and crypto operations MUST use a secure source of cryptographically strong random numbers. Acceptable sources include
Hardware approaches based on electic noise
/dev/random
/dev/urandom on busy machines and when seeded from strong source
Pseaudo random number generator with at least 128bit cycle, when seeded from a strong source (such as user input as in PGP).
Unacceptable sources include
Any predictable source
Only seeding with current time and/or process identifier
Less than 128bit cycle or search space
The random number pool should be consulted whenever new randomness is needed, but at the same time care should be taken to make sure that the pool is not unduely depleted of entropy. This is especially a risk whe using /dev/urandom.
Care should be taken to not to leak the random numbers except as strictly mandated by the protocols.
Whenever unique identifiers are called for, uniqueness must either be absolute (within specified namespace) or statistical with at least 128bits of search space.
See threat T61-Replay.
Audit trail, including logs, MUST be digitally signed or otherwise tamper proof. Tamperproofness MUST achieve at least the security level equivalent to using any of the following cipher suites (assuming safe and sound key management practises):
RSA1024-SHA1
DSA1024-SHA1
Depending on circumstances, such as hosting of services in a untrusted data center, the logs SHOULD also be encrypted to achieve a security level equivalent to using any of the following cipher suites (assuming safe and sound key management practises):
RSA1024-SHA1-AES128-CBC
DSA1024-SHA1-AES128-CBC
See threat T142-Tamper.
This compliance requirement addresses Reqs. D1.2-2.17-AuditUntamp, D1.2-2.15-Resp, D1.2-6.10-Redress, D1.2-6.17-TechBind, D1.2-4.4-CourtProof.
All backups or batch data transfers MUST be in encrypted form ensuring security level equivalent to using any of the following cipher suites (assuming safe and sound key management practises):
RSA1024-AES128-CBC
DSA1024-AES128-CBC
See threat T101-LeakBackup and Req. D1.2-2.21-DataProtLaw.
If SAML assertions are involved the software implementation MUST have passed the relevant SAML certification administered by the Liberty Alliance certification program.
If Liberty ID-WSF is involved the software implementation MUST have passed the relevant certification administered by the Liberty Alliance certification program.
When Systems Entities are required to authenticate each other or assymmetrically one party, HTTPS MUST be supported and other X509v3 certificate based methods (PKI) MAY be supported. HTTP Authentication header based methods MAY be supported.
Authentication requirement CAN be satisfied at VPN, SSL, or application layer (e.g. application layer credentials or trusted digital signature over data). In any case, the authentication MUST be part of the audit trail in a cryptographically strong way and SHOULD be referenced by the summary audit events.
This satisfies Req. D1.2-7.3-An.
Certificates used for entity authentication and digital signatures MUST be obtained from a trustworthy authority. Designation of acceptable authorities MUST be made in the Governance Agreement of the Trust Network.
Private Keys MUST be adequately protected. In the minimum this should mean procedural protections against exposure during generation, certification, install, and backup, as well as operational protection using file system permissions. Disclosure of private keys MUST be on strictly need to know basis.