| Internet Engineering Task Force | P. M. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Standards Track | R. N. Stradling |
| Expires: May 01, 2012 | Comodo CA Ltd. |
| October 29, 2011 |
Security Policy Distribution Format (SPDF)
draft-hallambaker-securitypolicy-01
This document describes a format for distributing collections of security policy statments as static documents.
Individual security policy statements are expressed in a HTTP compatible header syntax. Lists of security policy statements are signed for exchange. Strong references to static data objects are formed using Named Information (ni) URI specifiers.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 01, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]
The following terms are used in this document:
Recent compromises of critical infrastructure have highlighted the weaknesses that result from the fact that on the Internet, security is an option, not the default.
Security Policy provides a mechanism for advising parties of the minimum degree of security that they should accept for a communication and thus preventing downgrade attacks.
Security Policy statements provide a mechanism for advising parties of the risk of a downgrade attack and the enforcement actions that are appropriate based on the quality of the security policy information available.
While the natural inclination of security specialists is to advise that a security policy violation always result in a hard failure with the corresponding transaction being aborted, this approach imposes a high cost for false positives. Previous attempts to employ security policy data (e.g. in DKIM) have faced objections from those fearing that the false positive rate will be unacceptably high.
Recent events have demonstrated that the value of reporting a security policy violation is considerably higher than than security policy enforcement on a limited scale. While security policy enforcement has the potential to protect the individual Internet user, reporting a violation to the appropriate parties has the potential to protect the entire community of Internet users.
In a protocol downgrade attack the attacker causes client software to communicate en-clair when TLS or some other security enhancement is offered.
In a CA downgrade attack the attacker applies for a certificate from a different issuer to that authorized by the Domain name holder or for a category of certificate with lest strict validation requirements.
Although PKIX specifies two mechanisms for certificate status checking, many clients will accept certificates when access to the certificate status checking infrastructure fails.
Although use of expired certificates is discouraged, the frequency with which use of expired certificates occurs from administrative oversight prevents strict enforcement.
Security policy statements may be obtained from explicit statements by domain name holders or obtained heuristically from observation of the network.
A domain name holder MAY specify security policy explicitly through publication mechanisms that include:
Even though a statement is explicit, an enforcement point may only learn of its existence through heuristic means. For example observing DNS traffic, use of Web crawlers and HTTPS inspection.
Publication of an explicit Security policy Statement requires a considerable commitment of time and effort for a large site.
Security policy data MAY also be determined heuristically by observation of network traffic. If a site has been using a particular CA for many years and a certificate is suddenly detected from an obscure issuer, questions may be asked.
While the quality of heuristic data may fall short of that required to abort transactions by itself, it can still provide a useful basis for reporting potential violations and for enforcement when combined with data from other sources.
Security Policy Statements set expectations for security, thus overriding the Internet default security expectation of 'none'.
Security Policy Statements may be used to protect individual Internet users through client enforcement and communities of users through reporting.
A Security Policy Statments are designed to permit distribution through a variety of means including:
Each distribution mechanism provides a tradeoff between scope, effectiveness and resilience.
The formats described in this document is targetted at distribution of Local Security Policy and as data driven updates. With appropriate format the same semantics could be carried in alternative distribution media such as protocol headers and DNS records.
Security Policy Statements are used to inform relying parties that host(s) support a particular level of security, thus permitting relying parties to avoid downgrade attacks.
Security Policy Statement lists are formatted as a sequence of HTTP format headers. Each header contains a single statement policy statement.
The TLS statement provides a control against protocol downgrade attacks. The following statement specifies that every Web server in the domain example.com offers the use of TLS security enhancement.
TLS: optional;Domain=*.example.com;Protocol=_http._tcp;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
A security policy statement that advises relying parties that security is always offers permits a 'promiscuous security approach' to be adopted in which clients are advised that the default mode of connection SHOULD be with TLS security enhancements.
When a domain is in the scope of multiple statements the principle of closest match is applied. The following TLS statements specify exceptions to the previous statement.
The following policy statement declares that use of TLS is REQUIRED for the authentication server login.example.com, that clients MUST perform strict HTTPS processing rules and that a minimum TLS version of 3.1 MUST be used.
TLS: strict;Domain=login.example.com;Protocol=_http._tcp;
UTC=2011-10-25:17:23;Expire=2011-10-28T00:00;min=3.1
Action: Block ;Domain=payments.example.com;
UTC=2011-10-25:17:23;Expire=2011-10-28T00:00
Exceptions MAY also be used to specify a lower level of security. This is useful when a broad security policy is being deployed in stages and some hosts do not yet comply with the requirements.
The following statement specifies that the host test.example.com does not have a defined security policy.
TLS: unknown;Domain=test.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
A security policy statement MAY specify a user interface action that relying parties are advised to take when a security policy violation is detected. This may range from advising the relying party that they MUST ignore the violation to advising them that they SHOULD block all communication.
A security policy statement MAY provide a means of reporting security policy violations. While client enforcement of security policy can protect one user, reporting of a violation has the potential to help protect the whole community. Such reporting is orthogonal to the relying party action.
The following statement specifies that relying parties MUST ignore security policy violations for all hosts in *.example.com except to report them in machine readable format to the specified reporting address. An action statement of this form would typically be used during beta testing of a security policy deployment.
Action: Ignore ;Domain=*.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
Report: security@example.com; format=iodef;Domain=*.example.com;
UTC=2011-10-25T17:23;Expire=2011-10-28T00:00
The CA-PIN and UNPIN statements provide a controll against a CA substitution attack.
The following statement specifies that the domain *.example.com is under control against server certificate substitution attacks and that X.509v3 certificates conformant with the specified criteria are valid for that domain. If a certificate is presented for a host in the domain that does not conform to the criteria specified in any security policy statement in the enclosing Security Policy Statement list it MUST be considered untrustworthy.
CA-PIN: ni:///sha-256;RpmvP1PSoV5788nW64mHZbkLinRVdZQi; match=path;
Domain=*.example.com; UTC=2011-10-25:17:23;Expire=2011-10-28T00:00
unpin=ni:///sha-256;2UADniDyBYLOISFHDCMdcbQpw3ctAI7o
The unpin parameter in the above statement contains the digest value of a piece of data to be released to revoke the corresponding CA-PIN statement.
The following UNPIN statement revokes the CA-PIN statement above by releasing the private data used to create the unpin digest.
UNPIN: data:base64;RpmvP1PSoV5788nW64mHZbkLinRVdZQi;
pin=ni:///sha-256;2UADniDyBYLOISFHDCMdcbQpw3ctAI7o
Although X.509v3 and PKIX specify mechanisms for advising relying parties of the status of certificates, these approaches must by necessity rely on access to the information sources used to distribute the status information (CRLs, OCSP tokens).
Emergency Certificate Revocation advises a relying party that a certificate has been found to be invalid and there is a very high risk that the certificate will be used for a malicious purpose.
The following Revoke statement revokes the CA certificate that will eventually be attached in an appendix.
Revoke: ni:///sha-256;6cNTPy-7cu9A0fnNuFSWaQXO9_Gmlf-T
Encoding is 7 bit ASCII as for headers.
All Security Policy Statements have a common syntax based on the syntax used in HTTP and SMTP message format.
Forgetting about the traditional white space and line wrapping considerations, the syntax has the format has the following common syntax:
statement = header-tag ":" values
header-tag = token
values = principal-value *("," principal-value)
*( ";" parameter )
principal-value = dns-name | uri | quoted-string
parameter = attribute | attribute "=" value
attribute = token
value = token | quoted-string
WS = " " | tab
Principal values and parameter values take one of the following types.
A DNS Domain name specifier. [cite]
A wildcard may be specified using the asterisk character '*'. Domain names MUST not occur amywhere other than as leftmost label in a domain name.
The form *.example.com is valid but sub.*.example.com, www*.example.com and *x.example.com are invalid.
A Date-Time value in XML time value format
Time values MUST be in UTC.
Specified an internet protocol by means of an SRV protocol prefix as specified in [RFC2782].
Specifies a reference to static data content by means of an ni scheme URI.
Support for the SHA-256 algorithm is REQUIRED.
A data URI formatted in accordance with [RFC2397].
The TLS version number specified as major '.' minor. Where the values of major and minor are as specified by the TLS specification [RFC4346].
TLS 1.1 has the version number 3.1
The following parameters MAY occur in any Security Policy Statement.
The domain(s) to which the security policy statement applies.
The wildcard character '*' MAY be used to indicate that the security policy statement also applies to subdomains within the specified domain.
To facilitate mapping of security policy originated in DNS records, the rules for use of wildcards are the same as those defined for DNSSEC. I.e. wildcards SHALL only occur as the first label in a DNS name, if a domain is in the scope of multiple security policy statements, the principle of closest match is applied.
A list of protocols to which the Security Policy applies. Protocols are identified by their SRV prefix labels.
The time at which the security policy statement was obtained. This MAY be earlier than the time at which the SPDF document is signed but SHOULD NOT be later.
The time at which the security policy statement expires. This MUST NOT be earlier than the time at which the SPDF document was signed.
The common parameter is used to provide a simple means of compression when specifying lists of Security Policy headers. If the Common header is specified, all unspecified common parameters take their value from the preceding header.
The CA-PIN statement is used to prevent a certificate issuer downgrade attack. A certificate SHALL be in violation of the specified security policy if the domain in question was within the scope of at least one CA-PIN statement at the time in question and the certificate does not comply with the requirements of any CA-PIN statements that were active at the time in question.
The principal parameter of a CA-PIN statement is an ni URI that specifies the criteria for the pinning.
Specifies whether the specified Named Information URI applies to an end entity subject key (key), a certificate signing subject key (csk), an end entity certificate (cert) or a certificate signing certificate (path). If no match is specified, the 'key' match is the default.
Is calculated over the subjectKeyInfo structure within the certificate.
The digest of a certificate is calculated over the binary certificate value.
The statement is only to be applied to certificates issued after the specified date and time.
The statement is only to be applied to certificates issued before the specified date and time.
A Named Information URI that specifies the digest of an unpinning value. Disclosure of the unpinning value has the effect of revoking the corresponding security policy statement to which it is attached.
The unpinning value SHOULD be a randomly chosen nonce with sufficient ergodicity to make determination by brute force attack infeasible.
An unpinning value for a previously distributed CA pinning statement encoded as Base64.
The Revoke statement is used to declare that a certificate is invalid.
While the functionality of the Revoke statement overlaps the capabilities and functionality of the existing PKIX revocation schemes (CRLs and OCSP), it is intended for a different field of use.
In particular the Revoke statement SHOULD NOT be employed except as a last resort mechanism for use in situations that are not adequately addressed by the existing certificate status infrastructure and the risk of relying on the revoked certificate is unacceptably high.
Specifies the action that SHOULD be performed in the case that a security policy violation is detected. Valid actions are 'Ignore', 'Advise', 'Fail' and 'Block':
Note that the specification of client actions is independent of reporting requests.
This part is to be aligned with whatever is agreed in PKIX for use in CAA.
Specifies the use of TLS:
Additional parameters MAY be specified to further control the mode of use of TLS. For example the minimum version of the protocol to be used. [[While this could be extended to include cipher suites it is believed that the existing protocol is sufficiently proofed against downgrade attack on cipher suites. If this should be found not to be the case it would likely drive an urgent update of the protocol version.]]
Specifies the minimum version of the TLS protocol to which the security policy applies (default is SSL 1.0).
Specifies the maximum version of the TLS protocol to which the security policy applies (default is no maximum version).
A SPDF document consists of a Cryptographic Message Syntax object [RFC5652] that contains a list of Security Policy statements. SPDF documents SHOULD be signed and MAY be encrypted.
[TBS details of CMS options that MUST be supported, crib this from SMIME]
[TBS optional, not sure if it is actually very usefull for this particular application but...]
TBS
TBS
Need to create a registry for the statements and parameters.