| Internet Engineering Task Force | P. M. Hallam-Baker |
| Internet-Draft | Comodo Group Inc. |
| Intended status: Standards Track | R. N. Stradling |
| Expires: April 26, 2012 | Comodo CA Ltd. |
| October 24, 2011 |
Security Policy Distribution Format (SPDF)
draft-hallambaker-securitypolicy-00
This document describes a format for distributing security policy statments.
Individual security policy statements are expressed in a HTTP compatible header syntax. Lists of security policy statements are exchanged as signed CMS objects. 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 April 26, 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 can be distributed through multiple channels. The best choice of channel depends on the information in question and the application.
The Security Policy is embedded in client or operating system code. This approach has traditionally been limited to embedding revocation notices for certificates that have been known to be fraudulently issued.
The security policy data is carried in the protocol to which the policy applies. E.G HTTP headers for a HTTP transaction. One drawback to this approach is that it only provides 'secure after first contact'.
The DNS has been used to distribute Security Policy Statements. The principle drawback being that deployment of DNSSEC is immature and likely to be blocked in the regions where security policy is most needed.
The format described in this document is designed to support data driven update.
The main limitation to this approach is that it does not scale. Thus the use of the distribution format should be limited to distributing policy for the domains that carry the highest risk.
Security Policy distribution is hard because the adversaries encountered to date include nation state actors with complete control of the local network infrastructure. It is thus not possible to address every possible need in a standard based approach since the adversary can block deployment of the necessary standards.
It follows that standards based techniques SHOULD be supplemented by resort to irregular methods where necessary.
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 = token ":" values
values = principal-value *("," principal-value)
*( ";" parameter )
principal-value = dns-name | uri | quoted-string
parameter = attribute "=" value
attribute = token
value = token | quoted-string
WS = " " | tab
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 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.
TBS
TBS
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 TLS to be used in a format that I am sure someone will advise me on.
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5652] | Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. |
| [RFC4033] | Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [X.509] | International Telecommunication Union , "ITU-T Recommendation X.509 (11/2008): Information technology - Open systems interconnection - The Directory: Public-key and attribute certificate frameworks ", ITU-T Recommendation X.509, November 2008. |