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

Abstract

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.

Status of this Memo

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 Notice

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.


Table of Contents

1. Definitions

1.1. Requirements Language

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]

1.2. Defined Terms

The following terms are used in this document:

Certificate
An X.509 Certificate, as specified in RFC 5280 [RFC5280].
Certification Policy (CP)
Specifies the criteria that a Certification Authority undertakes to meet in its issue of certificates.
Certification Practices Statement (CPS)
Specifies the means by which the criteria of the Certification Policy are met. In most cases this will be the document against which the operations of the Certification Authority are audited.
Certification Authority (CA)
An entity that issues Certificates in accordance with a specified Certification Policy.
Domain
The set of resources associated with a DNS Domain Name.
Domain Name
A DNS Domain name as specified in RFC 1035 [RFC1035] and revisions.
Domain Name System (DNS)
The Internet naming system specified in RFC 1035 [RFC1035] and revisions.
DNS Security (DNSSEC)
Extensions to the DNS that provide authentication services as specified in RFC 4033 [RFC4033] and revisions.
Public Key Infrastructure X.509 (PKIX)
Standards and specifications issued by the IETF that apply the X.509 [X.509] certificate standards specified by the ITU to Internet applications as specified in RFC 5280 [RFC5280] and related documents.
Resource Record (RR)
A set of attributes bound to a Domain Name.
Relying Party
A party that makes use of an application whose operation depends on use of a Certificate for making a security decision.
Relying Application
An application whose operation depends on use of a Certificate for making a security decision.

2. Introduction

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.

2.1. Requirements

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.

2.1.1. Risks

2.1.1.1. Protocol Downgrade Attack

In a protocol downgrade attack the attacker causes client software to communicate en-clair when TLS or some other security enhancement is offered.

2.1.1.2. CA Downgrade Attack

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.

2.1.1.3. Use of Revoked Certificate

Although PKIX specifies two mechanisms for certificate status checking, many clients will accept certificates when access to the certificate status checking infrastructure fails.

2.1.1.3.1. Use of Expired Certificate

Although use of expired certificates is discouraged, the frequency with which use of expired certificates occurs from administrative oversight prevents strict enforcement.

2.1.2. Security Policy Origination

Security policy statements may be obtained from explicit statements by domain name holders or obtained heuristically from observation of the network.

2.1.2.1. Explicit

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.

2.1.2.2. Heuristic

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.

2.1.3. Distribution

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:

Embedded in application code
Many clients have security policy statements embedded into the application code. For example code to look for specific certificates that are known to be invalid. While this is a highly effective means of enforcement it requires users to upgrade their client software in response to every compromise.
Local Configuration Files
Some client applications support local security policy configuration but the configuration options are limited and there is no standard format for distributing the configuration. A standard for specifying Security Policy potentially allows every client application to enforce the same security policy whether it be a Web browser, mail client or Web Services application.
Data driven updates
Data driven update of security policy overcomes the principal limitation of security policy distribution through embedded code and local configuration files. Security Policy can be updated in response to threats and reliably enforced without the need to perform online queries for each network operation. The principal disadvantage being that it is only possible to push out security policy statements for selected of domains.
Protocol Headers
Distribution of security policy in protocol headers overcomes the scaling limitation of data driven updates but only provides security after first contact. If the attacker can compromise the first contact they can compromise all subsequent contacts.
DNS Records
DNS provides a scalable means for distribution of security policy statements through realtime query and response. If the relying party can ensure a connection to a trustworthy DNS service, they can protect their security but an attacker that can block access to a trustworthy DNS service can force the relying party to choose between security and availability.
Irregular
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.

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.

2.2. Security Policy Statements

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.

2.2.1. Controlling Protocol Downgrade Attack

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
            

2.2.2. Mitigating CA Substitution Attack

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 
            

2.2.3. Emergency Certificate Revocation

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
            

2.3. Syntax

Encoding is 7 bit ASCII as for headers.

2.3.1. Common Syntax

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
            

2.3.2. Data Types

Principal values and parameter values take one of the following types.

2.3.2.1. dns-name

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.

2.3.2.2. date-time

A Date-Time value in XML time value format

Time values MUST be in UTC.

2.3.2.3. protocol-id

Specified an internet protocol by means of an SRV protocol prefix as specified in [RFC2782].

2.3.2.4. ni-uri

Specifies a reference to static data content by means of an ni scheme URI.

Support for the SHA-256 algorithm is REQUIRED.

2.3.2.5. data-uri

A data URI formatted in accordance with [RFC2397].

2.3.2.6. tls-version

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

2.3.3. Common Parameters

The following parameters MAY occur in any Security Policy Statement.

2.3.3.1. Domain=<dns-name>

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.

2.3.3.2. Protocol=<protocol-id>*

A list of protocols to which the Security Policy applies. Protocols are identified by their SRV prefix labels.

2.3.3.3. UTC=<date-time>

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.

2.3.3.4. Expire=<date-time>

The time at which the security policy statement expires. This MUST NOT be earlier than the time at which the SPDF document was signed.

2.3.3.5. Common

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.

2.3.4. Statement: CA-PIN: <ni-uri>

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.

2.3.4.1. Match= 'key' | 'csk' | 'cert' | 'path'

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.

2.3.4.1.1. Calculating the digest of a Subject Key.

Is calculated over the subjectKeyInfo structure within the certificate.

2.3.4.1.2. Calculating the digest of a Certificate.

The digest of a certificate is calculated over the binary certificate value.

2.3.4.2. After=<date-time>

The statement is only to be applied to certificates issued after the specified date and time.

2.3.4.3. Before=<date-time>

The statement is only to be applied to certificates issued before the specified date and time.

2.3.4.4. Unpin=<ni-uri>

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.

2.3.5. Statement: Unpin: <data-uri>

An unpinning value for a previously distributed CA pinning statement encoded as Base64.

2.3.6. Statement: Revoke: <uri>

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.

2.3.7. Statement: Action: <action>

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':

Ignore
The client SHOULD ignore policy violations. This option is intended for use in testing Security Policy configuration prior to requesting enforcement.
Advise
The client SHOULD advise the user when policy violations occur but not impede access to the corresponding network resource.
Fail
The client SHOULD advise the user that a policy violation has occurred and discourage (but not prevent) access to the corresponding network resource.
Block
The client SHOULD advise the user that a policy violation has occurred and prevent access to the corresponding network resource.

Note that the specification of client actions is independent of reporting requests.

2.3.8. Statement: Report: <dns-name>

This part is to be aligned with whatever is agreed in PKIX for use in CAA.

2.3.9. Statement: TLS: <level>

Specifies the use of TLS:

refused
Use of TLS is not supported.
unknown
Use of TLS is unkown.
optional (default)
Use of TLS is optional.
required
Use of TLS is required.
strict
Use of TLS is required with Strict Transport Security.

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.]]

2.3.9.1. min=<tls-version>

Specifies the minimum version of the TLS protocol to which the security policy applies (default is SSL 1.0).

2.3.9.2. max=<tls-version>

Specifies the maximum version of the TLS protocol to which the security policy applies (default is no maximum version).

3. Distribution Format

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.

3.1. Cryptographic Message Syntax Properties

[TBS details of CMS options that MUST be supported, crib this from SMIME]

3.2. JSON Packaging

[TBS optional, not sure if it is actually very usefull for this particular application but...]

4. Security Considerations

TBS

5. IANA Considerations

TBS

Need to create a registry for the statements and parameters.

6. References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998.
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[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.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[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.

Authors' Addresses

Phillip Hallam-Baker Comodo Group Inc. EMail: philliph@comodo.com
Rob Stradling Comodo CA Ltd. EMail: rob.stradling@comodo.com