Description of the specific requirements that a deployment must comply with when operating in TAS3 Trust Network. This is beyond and in addition to the architecture and protocol requirements, as well as governing agreement and trust operator policies described elsewhere.
Disclaimer: This document has not been reviewed or approved by European Comission.
This document describes the TAS3 Compliance Requirements for Deployments in a normative and prescriptive way. Any deployment claiming "TAS3" compliance MUST abide by this document as well as [TAS3ARCH], and [TAS3PROTO]. A deployment usually has to satisfy, as well, requirements of the Trust Guarantor's, see [TAS3GLOS], Governance Agreement and certification procedures, some of which concern the software implementation and others the organizational properties. Use of TAS3 Brand is governed by a separate TAS3 Brand Agreement.
This document uses the keywords (e.g. MUST, SHOULD) of [RFC2119]. All text is normative unless expressly identified as non-normative. Prose and specification has precedence over examples. In general the examples should not be assumed normative unless no normative specification for the subject matter is available.
This architecture, and related documents are copyrighted works of TAS3 Consortium, as dated. All Rights Reserved. This architecture, and related documents, are versioned and subject to change without notice. No warranty or guarantee is given. This architecture, and related specifications can be implemented on Royalty Free terms by anyone. However, no warranty regarding IPR infringement is given. For further details, please see [TAS3CONSOAGMT].
For a partner to operate in a TAS3 Trust Network, it must comply with certain software and protocol requirements described in [TAS3ARCH] and [TAS3PROTO]. However such software can often be configured in a variety of ways. This document incorporates by reference all the requirement described by the above documents, and then adds deployment and configuration specific requirements.
In addition to the present document, the Trust Guarantor of your Trust Network may have published additional policies and requirements. The Governing Agreement of the Trust Network can also specify more requirements.
Many compliance requirements that a Trust Guarantor will likely enforce to its Trust Network are described in the Identity Assurance Framework [IAF].
All legal requirements MUST be satisfied. Members MUST operate within the law.
All normative requirements of [TAS3PROTO] MUST be satisfied.
Each member MUST be registered on the file at the Trust Guarantor. The filing MUST include details appropriate for the jurisdiction to identify the entity to the extent needed to raise a law suit and/or coordinate investigation with the tax authorities. Typically this means at least
Entity name
Address
Company registration or VAT number
Version of Governance Agreement signed and date signed (Req. D1.2-6.13-Contract)
Whenever this information changes, the member MUST prompty inform the Trust Guarantor.
Each member MUST conspiciously publish a Privacy Policy and Terms of Use for their services on the internet. Member must make available a registry description and offer consultation, rectification, and/or removal of PII.
The Policy and the Terms MUST address at least
Entity name and contact for inquiries
Data retention policy
How is User identified (database keys, properties, such as pseudonymity, of identifier, etc.)
With whom data is exchanged and why
Whether the policy may change and how existing customers are handled upon the change.
A member MUST adhere to its own Policy and Terms.
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.
Governing Agreement should at least address
Governance structure, such as advisory and audit boards
Criteria to join and stay on the network, including certification and audits (Req. D1.2-6.14-Compat)
Process for removal from the network
Process for complaints, arbitration, and disciplinary action (Req. D1.2-6.9-Complaint)
Commercial liability and its fair appropriation
Liability due to negligence in criminal cases and its fair appropriation
Privacy protection
Redress for users that have suffered unwarranted disclosure (Req. D1.2-6.10-Redress)
Minimal mandatory security practises and policies (Reqs. D1.2-6.11-Confid and D1.2-6.15-MinPolicy)
Acceptable use for Service Providers
Acceptable use for Users
Requirement to be legally bound (Reqs. D1.2-6.16-Bound and D1.2-6.17-TechBind)
Any prospective Trust Network member should document the answer to the following questions:
Are you collecting or using PII as part of the service?
Do you have a Privacy Policy that you are bound to follow?
Do you use PII for any purpose other than providing the service?
Do you get User's consent or let him opt out before his information is used for other purposes than providing the specific service?
Do you share PII beyond your company or family of companies?
Do you get user's consent or let him opt out before your share his information with any other company not needed to provide the specific service?
Do you allow user to manage these preferences over time and change my options?
Trusted Guarantor MUST NOT have a conflict of interest with any of the parties that are designed to trust it.
Trust Guarantor MUST maintain credible business records, including:
Members of the Trust Network (see CR24-File).
Service Provider MUST use DNS to publish its network addresses in a symbolic form. This requirement facilitates reconfigurations of the network. It is a well accepted "best practise".
Service Provider's business processes MUST be modelled.
Service Requester SHOULD NOT log, even in encrypted form, the the tokens destined to the Service Responder or other parties if threat T107-LogTokLeak is a concern. If audit trail requires logging tokens, then the tokens must be blinded so that the correlatable part is not visible or the token MUST be encrypted such that legitimate viewers of audit trail can decrypt it, but SP itself can not.
Compliance with this requirement is established with audits.
Service Provider MUST have user's consent before leaking a correlation handle of any kind.
Service Provider MUST implement Well-Known Location (WKL) method of metadata export, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method.
Service Provider MUST implement Well-Known Location (WKL) method of metadata import, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method. The Import MUST NOT unintentionally lead to a trust relationship.
Service Provider MUST authenticate the Service Requester according to CR216-EntAn.
Service Provider MUST authenticate itself to the Service Requester according to CR216-EntAn.
Service Requester MUST use DNS to resolve names. This requirement facilitates configuration and provides a load balancing method (round robin DNS) for the SPs. DNS query results MUST NOT be cached beyond their TTL.
Service Requester MUST implement Well-Known Location (WKL) method of metadata export, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method.
Service Requester MUST implement Well-Known Location (WKL) method of metadata import, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method. The Import MUST NOT unintentionally lead to a trust relationship.
Service Requester MUST authenticate the Service Provider according to CR216-EntAn.
Service Requester MUST authenticate itself to the Service Provider according to CR216-EntAn.
Since Databases Storing Personally Identifiable Information (PII) usually are SPs, the requirements for SP also apply.
A future version of this document will specify in detail
Special encryption concerns
Special privacy protection
Record keeping and audit
Trusted Third Party MUST NOT have a conflict of interest with any of the parties that are designed to trust it.
Identity Provider MUST NOT have a conflict of interest with any of the Service Providers or Users. In general, IdP functions can not be performed by a SP.
Identity Provider MUST implement Well-Known Location (WKL) method of metadata export, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method.
Identity Provider MUST implement Well-Known Location (WKL) method of metadata import, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method. The Import MUST NOT unintentionally lead to a trust relationship.
Discovery Providers MUST NOT have a conflict of interest with any of the Service Providers or Users. In general, the discovery and token mapping functions can not be performed by a SP.
Discovery Service MUST implement Well-Known Location (WKL) method of metadata export, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method.
Discovery Service MUST implement Well-Known Location (WKL) method of metadata import, see [SAML2meta] section 4.1 "Publication and Resolution via Well-Known Location", p.29, for normative description of this method. The Import MUST NOT unintentionally lead to a trust relationship.
Trust and Reputation Provider MUST NOT have a conflict of interest with any of the Service Providers or Users to which it provides trust scorings.
Audit Provider, Audit Event Bus operator, or shared Event Bus Operator MUST NOT have a conflict of interest with any of the Service Providers or Users. In general, apart from SP internal audit, the audit functions can not be performed by a SP.
The compliance requirements have been drafted to ensure true security and accountability. However we recognize that some of the compliance requirements are quite onerous and could be a hindrance to TAS3 adoption in some low value situations. Therefore we define in this section a TAS3-Lite profile that can be used in low value situations as long as the risks are recongnized and the deployment is not misrepresented as fully TAS3 compliant. The TAS3-Lite relaxations are as follows:
CR24-File and CR25-Policy are dropped. Informal means should be used to achieve the same end result. Dropping these requirements seriously compromises the ability of the Trust Network and the Users to hold parties accountable.
CR214-CertSAML and CR215-CertIDWSF are dropped due to financial cost of the certification. Attending cheaper informal interop events is still highly recommended.
CR217-CertCert is dropped. Self-certification is allowed.
CR30-GA is dropped. Informal governance structure is allowed. The consequence of this is most likely that parties can not be held responsible in case of serious violations.
CR52-BPM is dropped. Informal modelling is still recommended.
Elaborate more compliance categories
draft-tas3-compliance-v05.pdf
repo.tas3.eu:/var/lib/tas3repo/arch/tas3-compliance.pd (1.20)
export CVSROOT=:ext:repo.tas3.eu:/var/lib/tas3repo
cvs co arch
cd arch
# modify tas3-*.pd
cvs ci -m 'What changed...'
~
Please comment on the TAS3WP02@LISTSERV.CC.KULEUVEN.AC.BE mailing list, or that failing, send your comments to the editor.
Any footnotes in this document will not appear in final version. They are editorial comments that may help reviewers to put material in context.