Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6012D539 for ; Fri, 24 Jun 2016 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-t1xY-TKtWo for ; Fri, 24 Jun 2016 12:05:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F0E12B008 for ; Fri, 24 Jun 2016 12:05:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48273 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bGWPV-000ATm-1u for sidr@ietf.org; Fri, 24 Jun 2016 15:05:01 -0400 From: Stephen Kent To: sidr Message-ID: Date: Fri, 24 Jun 2016 15:04:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------465133AF4A73FD631517E29E" Archived-At: Subject: [sidr] revising Section 7.2 of RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:05:05 -0000 This is a multi-part message in MIME format. --------------465133AF4A73FD631517E29E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I've been discussing details of text in the "validation revisited" I-D with Tim, now that he has become the primary editor. I believe a description of a new validation algorithm will be cleaner and easier to understand if we replace all of section 7.2 in 6487, rather than trying to change just step 6. Most of the text will remain the same, but I've tried to simplify the language where appropriate, to correct a technical error (in describing validity checking), and add text needed to describe the revised alg. I think it makes sense to fix the section while we're updating 6487. Here is my proposed re-write for this section. I've marked the changed text as *bold*, and included *red* comments to explain the rationale for the suggested changes. Steve ------ 7.2 Resource Certification Path Validation *The following algorithm is employed to validate CA and EE resources certificates. It is modeled on the path validation algorithm from [RFC5280], but modified to make use of the IP Address Delegation and AS **Identifier Delegation Extensions from [RFC3779]. (this is a shorter, simpler intro for the section)* *There are two inputs to the validation algorithm:* ** *1.**a trust anchor * ** *2.****a certificate to be validated* *(a description of inputs was present in 5280, in 6.1.1, but omitted in 6487)* *The algorithm is initialized with two new variables for use in the RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set-AS (VRS-AS). These sets are used to track the set of resources (IP address space and AS Numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and **AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.* *(this new text describes the sets needed to track what resources are present in all certs along a path. I suggest we use two sets, not one, because when we deal with ROAs and router certs they each have only only one of these 3779 extensions present.)* This path validation algorithm verifies, among other things, that aprospective certification path (a sequence of n certificates) satisfies the following conditions: A.for all 'x' in {1, ..., n-1}, the subject of certificate 'x' is the issuer of certificate ('x' + 1); B.certificate '1' is issued by a trust anchor; C.certificate 'n' is the certificate to be validated; and D.for all 'x' in {1, ..., n}, certificate 'x' is valid. *(I changed the enumeration for the bullets above to letters from numbers, because we use numbers to enumerate the steps below. 5280 also used letters vs. numbers when enumerating different aspects of path validation, in some parts of section 6, on which this is based.)* Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]. 1.***The signature of certificate x (x>1) is verified using the * ** *public key of the issuer’s certificate (x-1), using the * ** *signature algorithm specified for that public key (in * ** ***certificate x-1). **(this is a more precise specification of what * * it means to verify the sig of cert x in the path)* 2.*The current time lies within the interval defined by the * ** *NotBefore and NotAfter values in the Validity field of * ** *certificate x. **(this wording matches the names of the fields in a cert, whereas the 6487 text uses terms that do not match cert field names.)* 3.*The Version, Issuer, and Subject fields of certificate x * ** *satisfy the constraints established in Section 4.1-4.7 * ** *of this specification. ***(this text precisely defines constraints that apply to cert fields, vs. extensions. the 6487 text referred to fields in step 3, which does not encompass extensions!)** 4.*Certificate x contains all the extensions that MUST be * ** *present, as defined in Section 4.8 of this specification. * ** *The value(s) for each of these extensions MUST be satisfy* ** *the constraints established for each extension in the* ** *respective sections.**Any extension not identified in Section 4.8 MUST NOT****appear in certificate x. ***(this text describes the constraints imposed on extensions, vs. fields, paralleling #3 above) ** ****** 5.***Certificate x MUST NOT have been revoked, i.e., it * ** *MUST NOT appear on a CRL issued by the CA represented by certificate x-1 (this is a more concise wording of step 5 in 6487)* 6.*Compute the VRS-IP and VRS-AS set values as indicated below:* ** ** ** *If the IP Address Delegation extension is present * ** *in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-IP. * ** ** ** *If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL. * ** ** ** *If the AS Identifier Delegation extension is present * ** *in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-AS * ** ** ** *If the AS Identifier Delegation extension is absent * ** *in certificate x, set the VRS-AS to NULL.* ** ** ** *If x = n (i.e., this is the certificate being validated),* ** *then:* ** *1.**If IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP. * ** *2.**If an AS Identifier Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP. * ** *3.*** ** ** ** *If an RP is caching the results of validation, these values* ** *MAY be stored along with the certificate, to facilitate* ** *Incremental validation based on cached results.* ** ** ** *Otherwise, return to step 1 and continue path validation.* *(this is the description of the new rule for "relaxed" validation relative to 3779 extensions. it is more detailed than what Tim proposed, in part because I elected to treat IP address and ASNs as separate sets, consistent with the use of separate 3779 extensions. Tim has indicated that he would like to consider making this step apply only to CA certs, in hopes of not having to update the ROA RFC and the impending router cert RFC. This step can be modified to do that with a few tweaks.)* *These rules allow a CA certificate to contain resources * ** *that are not present in (all of) the certificates along * ** *the path from the trust anchor to the CA certificate. * ** *If none of the resources in the CA certificate are present * ** *in all certificates along the path, no subordinate * ** *certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition. * ** *Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the * ** *certificate in question.* ** ** ** *The IP address and/or AS number resources contained in an * ** *EE certificate being validated MUST always be **encompassed by all certificates along the path to the **trust anchor used to verify that certificate. The algorithm described above ensures this. * ** ** *(the last two paragraphs provide an explanation for the revised validation alg, and asserts a critical requirement for EE certs) * --------------465133AF4A73FD631517E29E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I've been discussing details of text in the "validation revisited" I-D with Tim, now that he has become the primary editor.  I believe a description of a new validation  algorithm will be cleaner and easier to understand if we replace all of section 7.2 in 6487, rather than trying to change just step 6. Most of the text will remain the same, but I've tried to simplify the language where appropriate, to correct a technical error (in describing validity checking), and add text needed to describe the revised alg. I think it makes sense to fix the section while we're updating 6487.  Here is my proposed re-write for this section. I've marked the changed text as bold, and included red comments to explain the rationale for the suggested changes.

Steve

------

7.2 Resource Certification Path Validation

The following algorithm is employed to validate CA and EE resources certificates. It is modeled on the path validation algorithm from [RFC5280], but modified to make use of the IP Address Delegation and AS Identifier Delegation Extensions from [RFC3779]. (this is a shorter, simpler intro for the section)

 

There are two inputs to the validation algorithm:

1.  a trust anchor

2.  a certificate to be validated

(a description of inputs was present in 5280, in 6.1.1, but omitted in 6487)



The algorithm is initialized with two new variables for use in the RPKI: Validated Resource Set-IP (VRS-IP) and Validated Resource Set-AS (VRS-AS). These sets are used to track the set of resources (IP address space and AS Numbers) that are considered valid for each CA certificate. The VRS-IP and VRS-AS sets are initially set to the IP Address Delegation and AS Identifier Delegation values, respectively, from the trust anchor used to perform validation.

(this new text describes the sets needed to track what resources are present in all certs along a path. I suggest we use two sets, not one, because when we deal with ROAs and router certs they each have only only one of these 3779 extensions present.)


This path validation algorithm verifies, among other things, that a prospective certification path (a sequence of n certificates)

satisfies the following conditions:

 

      A.  for all 'x' in {1, ..., n-1}, the subject of certificate 'x'

          is the issuer of certificate ('x' + 1);

 

      B.  certificate '1' is issued by a trust anchor;

 

      C.  certificate 'n' is the certificate to be validated; and

 

      D.  for all 'x' in {1, ..., n}, certificate 'x' is valid.


(I changed the enumeration for the bullets above to letters from numbers, because we use numbers to enumerate the steps below. 5280 also used letters vs. numbers when enumerating different aspects of path validation, in some parts of section 6, on which this is based.)

 

   Certificate validation requires verifying that all of the following

   conditions hold, in addition to the certification path validation

   criteria specified in Section 6 of [RFC5280].

 

 

1.   The signature of certificate x (x>1) is verified using the

    public key of the issuer’s certificate (x-1), using the

    signature algorithm specified for that public key (in

    certificate x-1). (this is a more precise specification of what

    it means to verify the sig of cert x in the path)

 

2.   The current time lies within the interval defined by the

NotBefore and NotAfter values in the Validity field of

certificate x. (this wording matches the names of the fields in a cert, whereas the 6487 text uses terms that do not match cert field names.)

 

3.   The Version, Issuer, and Subject fields of certificate x

satisfy the constraints established in Section 4.1-4.7

of this specification. (this text precisely defines constraints that apply to cert fields, vs. extensions. the 6487 text referred  to fields in step 3, which does not encompass extensions!)

 

4.   Certificate x contains all the extensions that MUST be

present, as defined in Section 4.8 of this specification.

The value(s) for each of these extensions MUST be satisfy

the constraints established for each extension in the

respective sections. Any extension not identified in Section 4.8 MUST NOT appear in certificate x. (this text describes the constraints imposed on extensions, vs. fields, paralleling #3 above)


 

5.   Certificate x MUST NOT have been revoked, i.e., it

MUST NOT appear on a CRL issued by the CA represented by certificate x-1 (this is a more concise wording of step 5 in 6487)

 

6.   Compute the VRS-IP and VRS-AS set values as indicated below:

 

If the IP Address Delegation extension is present

in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-IP.

 

If the IP Address Delegation extension is absent in certificate x, set the VRS-IP to NULL.

 

If the AS Identifier Delegation extension is present

in certificate x, compute the intersection of the resources between this extension and the current value of the VRS-AS

 

If the AS Identifier Delegation extension is absent

in certificate x, set the VRS-AS to NULL.

 

If x = n (i.e., this is the certificate being validated),

then:

1.  If  IP Address Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.

2.  If an AS Identifier Delegation extension is present, it is replaced with the intersection of the values from that extension and the current value of the VRS-IP.

3.   

 

If an RP is caching the results of validation, these values

MAY be stored along with the certificate, to facilitate

Incremental validation based on cached results.

 

Otherwise, return to step 1 and continue path validation.

(this is the description of the new rule for "relaxed" validation relative to 3779 extensions. it is more detailed than what Tim proposed, in part because I elected to treat IP address and ASNs as separate sets, consistent with the use of separate 3779 extensions. Tim has indicated that he would like to consider making this step apply only to CA certs, in hopes of not having to update the ROA RFC and the impending router cert RFC. This step can be modified to do that with a few tweaks.)

 

 

These rules allow a CA certificate to contain resources

that are not present in (all of) the certificates along

the path from the trust anchor to the CA certificate.

If none of the resources in the CA certificate are present

in all certificates along the path, no subordinate

certificates could be valid. However, the certificate is not immediately rejected as this may be a transient condition.

Not immediately rejecting the certificate does not result in a security problem because the associated VRS sets accurately reflect the resources validly associated with the

certificate in question.

 

The IP address  and/or AS number resources contained in an

EE certificate being validated MUST always be encompassed by all certificates along the path to the trust anchor used to verify that certificate. The algorithm described above ensures this.


(the last two paragraphs provide an explanation for the revised validation alg, and asserts a critical requirement for EE certs)

--------------465133AF4A73FD631517E29E--