Skip to content

Commit

Permalink
Rewrite overview, reword allowed #34
Browse files Browse the repository at this point in the history
  • Loading branch information
@nicorusti
nicorusti committed Jul 3, 2024
2 parents 1e9e13e + 4cd0b33 commit 3d19aa9
Showing 1 changed file with 64 additions and 71 deletions.
135 changes: 64 additions & 71 deletions draft-dekater-scion-pki.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -38,8 +38,45 @@ normative:
RFC5480:
RFC5652:
RFC5758:
RFC9217:
I-D.scion-cp:
title: SCION Control Plane
date: 2023
target: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/
author:
-
ins: C. de Kater
name: Corine de Kater
org: SCION Association
-
ins: N. Rustignoli
name: Nicola Rustignoli
org: SCION Association
-
ins: S. Hitz
name: Samuel Hitz
org: Anapaya Systems
I-D.scion-dataplane:
title: SCION Data Plane
date: 2023
target: https://datatracker.ietf.org/doc/draft-dekater-scion-dataplane/
author:
-
ins: C. de Kater
name: Corine de Kater
org: SCION Association
-
ins: N. Rustignoli
name: Nicola Rustignoli
org: SCION Association
-
ins: S. Hitz
name: Samuel Hitz
org: Anapaya Systems

informative:
RFC5398:
RFC6996:
BARRERA17: DOI.10.1145/3085591
CHUAT22:
title: "The Complete Guide to SCION"
Expand Down Expand Up @@ -76,57 +113,6 @@ informative:
ins: A. Perrig
name: Adrian Perrig
org: ETH Zuerich
I-D.scion-overview:
title: SCION Overview
date: 2022
target: https://datatracker.ietf.org/doc/draft-dekater-panrg-scion-overview/
author:
-
ins: C. de Kater
name: Corine de Kater
org: ETH Zuerich
-
ins: N. Rustignoli
name: Nicola Rustignoli
org: ETH Zuerich
-
ins: A. Perrig
name: Adrian Perrig
org: ETH Zuerich
I-D.scion-components:
title: SCION Components Analysis
date: 2022
target: https://datatracker.ietf.org/doc/draft-rustignoli-panrg-scion-components/
author:
-
ins: N. Rustignoli
name: Nicola Rustignoli
org: ETH Zuerich
-
ins: C. de Kater
name: Corine de Kater
org: ETH Zuerich
I-D.scion-cp:
title: SCION Control Plane
date: 2023
target: https://datatracker.ietf.org/doc/draft-dekater-scion-controlplane/
author:
-
ins: C. de Kater
name: Corine de Kater
org: SCION Association
-
ins: N. Rustignoli
name: Nicola Rustignoli
org: SCION Association
-
ins: S. Hitz
name: Samuel Hitz
org: Anapaya System
RFC5398:
RFC6996:



--- abstract

Expand All @@ -139,18 +125,33 @@ This document first introduces the trust model behind the SCION's control-plane

# Introduction

The control-plane PKI (CP-PKI) lays the foundation for the authentication procedures in SCION. It handles all cryptographic material used in the public key infrastructure of SCION's control plane. This section first introduces the key concepts of the SCION CP-PKI, including the trust model, its core elements (certificates, keys, and roles), and their relationships. The sections after the Introduction provide detailed specifications of the building blocks of the CP-PKI.
SCION is a path-aware internetworking routing architecture as described in {{RFC9217}}. It allows endpoints and applications to select paths across the network to use for traffic, based on trustworthy path properties. SCION is an inter-domain network architecture and is therefore not concerned with intra-domain forwarding.

**Note:** For extended information on the SCION next-generation inter-domain architecture, see {{CHUAT22}}, especially Chapter 2, as well as the IETF Internet Drafts {{I-D.scion-overview}} and {{I-D.scion-components}}.
SCION has been developed with the following goals:

*Availability* - to provide highly available communication that can send traffic over paths with optimal or required characteristics, quickly handle inter-domain link or router failures (both on the last hop or anywhere along the path) and provide continuity in the presence of adversaries.

*Security* - to provide higher levels of trust in routing information in order to prevent IP prefix hijacking/leaks, denial-of-service and other attacks. Endpoints can decide the trust roots they wish to rely on, routing information can be unambiguously attributed to an AS, and packets are only forwarded along authorized path segments. A particular use case is to enable geofencing.

*Scalability* - to improve the scalability of the inter-domain control plane and data plane, avoiding existing limitations related to convergence and forwarding table size. The advertising of path segments is separated into a beaconing process within each Isolation Domain (ISD) and between ISDs which incurs minimal overhead and resource requirements on routers.

SCION relies on three main components:

*PKI* - To achieve scalability and trust, SCION organizes existing ASes into logical groups of independent routing planes called *Isolation Domains (ISDs)*. All ASes in an ISD agree on a set of trust roots called the *Trust Root Configuration (TRC)* which is a collection of signed root certificates in X.509 v3 format {{RFC5280}}. The ISD is governed by a set of *core ASes* which typically manage the trust roots and provide connectivity to other ISDs. This is the basis of the public key infrastructure which the SCION control plane relies upon for the authentication of messages that is used for the SCION control plane.

*Control Plane* - performs inter-domain routing by discovering and securely disseminating path information between ASes. The core ASes use Path-segment Construction Beacons (PCBs) to explore intra-ISD paths, or to explore paths across different ISDs. See {{I-D.scion-cp}}

*Data Plane* - carries out secure packet forwarding between SCION-enabled ASes over paths selected by endpoints. A SCION border router reuses existing intra-domain infrastructure to communicate to other SCION routers or SCION endpoints within its AS. See {{I-D.scion-dataplane}}

This document describes the SCION PKI component used by the Control Plane.

## Terminology

**Control-Plane PKI (CP-PKI)**: The control-plane PKI is the public-key infrastructure upon which SCION's control plane relies for the authentication of messages. It is a set of policies, roles, and procedures that are used to manage trust root configurations (TRCs) and certificates.

**Autonomous System (AS)**: An autonomous system is a network under a common administrative control. For example, the network of an Internet service provider, company, or university can constitute an AS. If an organization operates multiple networks that are not directly connected together, then the different networks are considered different ASes.

**Isolation Domain (ISD)**: In SCION, autonomous systems (ASes) are organized into logical groups called isolation domains or ISDs. Each ISD consists of ASes that span an area with a uniform trust environment (i.e., a common jurisdiction). A possible model is for ISDs to be formed along national boundaries or federations of nations.
**Isolation Domain (ISD)**: In SCION, Autonomous Systems (ASes) are organized into logical groups called isolation domains or ISDs. Each ISD consists of ASes that span an area with a uniform trust environment (i.e., a common jurisdiction). A possible model is for ISDs to be formed along national boundaries or federations of nations.

**Core AS**: Each isolation domain (ISD) is administered by a set of distinguished autonomous systems (ASes) called core ASes, which are responsible for initiating the path-discovery and -construction process (in SCION called "beaconing").

Expand Down Expand Up @@ -206,7 +207,7 @@ As already mentioned previously, the control-plane PKI, SCION's concept of trust

### Updates and Trust Resets {#trust-reset}

There are two types of TRC updates: regular and sensitive. A **regular TRC update** is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged, whereas a **sensitive TRC update** is an update that modifies critical aspects of the TRC, such as the set of core ASes. In both cases, the base TRC remains unchanged. If the ISD's TRC has been compromised, it is necessary for an ISD to re-establish the trust root. This is possible with a process called **trust reset** (if allowed by the ISD's trust policy). In this case, a new base TRC is created.
There are two types of TRC updates: regular and sensitive. A **regular TRC update** is a periodic re-issuance of the TRC where the entities and policies listed in the TRC remain unchanged, whereas a **sensitive TRC update** is an update that modifies critical aspects of the TRC, such as the set of core ASes. In both cases, the base TRC remains unchanged. If the ISD's TRC has been compromised, it is necessary for an ISD to re-establish the trust root. This is possible with a process called **trust reset** (if permitted by the ISD's trust policy). In this case, a new base TRC is created.


### Substitutes to Certificate Revocation {#substitutes-to-revocation}
Expand Down Expand Up @@ -357,19 +358,19 @@ The recommended **maximum validity period** of a CP AS certificate is: 3 days.

### Voting Certificates {#cp-voting-cert}

There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that are allowed to cast votes in the TRC update process. Voting certificates are X.509-style certificates.
There are two types of voting certificates: the (1) regular voting certificates and the (2) sensitive voting certificates. They contain the public keys associated with the private keys that MAY cast votes in the TRC update process. Voting certificates are X.509-style certificates.

Regular and sensitive voting certificates are used to verify regular and sensitive TRC updates, respectively, and are embedded in the TRC.

#### Regular Voting Certificate

Regular voting certificates state which keys are allowed to cast votes in a regular update. In X.509 terms, regular voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a regular voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a regular voting certificate cannot be used to verify other certificates.
Regular voting certificates state which keys MAY cast votes in a regular update. In X.509 terms, regular voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a regular voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a regular voting certificate cannot be used to verify other certificates.

The recommended **maximum validity period** of a regular voting certificate is: 1 year.

#### Sensitive Voting Certificate

Sensitive voting certificates specify which keys are allowed to cast votes in a sensitive update. In X.509 terms, sensitive voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a sensitive voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a sensitive voting certificate cannot be used to verify other certificates.
Sensitive voting certificates specify which keys MAY cast votes in a sensitive update. In X.509 terms, sensitive voting certificates are self-signed end-entity certificates. This means that the issuer and subject of a sensitive voting certificate are the same entity, and the public key within the certificate can be used to verify the certificate's signature. However, a sensitive voting certificate cannot be used to verify other certificates.

The recommended **maximum validity period** of a sensitive voting certificate is: 5 years.

Expand Down Expand Up @@ -482,18 +483,14 @@ The recommended **maximum validity period** of a sensitive voting certificate is

All certificates used in the SCION control-plane PKI are X.509 v3 certificates. However, the SCION specification is in some places more restrictive. This section defines these additional constraints and conditions compared to {{RFC5280}} for each type of SCION control-plane PKI certificate.

**Note**: The settings for the SCION-specific constraints and conditions are based on the SCION open-source implementation [scionproto](https://github.com/scionproto/scion/). Adjusting these settings to the requirements of a customer implementation may be possible and is allowed.

### Basic Fields: SCION-Specific Constraints and Conditions

This section briefly describes the fields of the SCION control-plane PKI certificates based on X.509. These fields are relevant for each SCION certificate used in the control plane, regardless of the certificate type. For detailed descriptions of the full generic format of X.509 v3 certificates, see {{RFC5280}} and [X509](https://handle.itu.int/11.1002/1000/13031), clause 7.2. Additionally, the section lists the SCION-specific constraints and conditions compared to {{RFC5280}}, per certificate field.

`TBSCertificate` sequence: Contains information associated with the subject of the certificate and the CA that issued it. It includes the following fields:

- `version` field: Describes the version of the encoded certificate.

- **SCION constraints**: "v1" and "v2" are not allowed.
- **Additional conditions and remarks**: MUST be set to "v3" (as extensions are used and mandatory in SCION).
- `version` field: Describes the version of the encoded certificate. It MUST be set to "v3" (as extensions are required in SCION).

- `serialNumber` field: A positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA.
- `signature` field: Contains the identifier for the algorithm used by the CA to sign the certificate.
Expand Down Expand Up @@ -528,13 +525,9 @@ This section briefly describes the fields of the SCION control-plane PKI certifi

- **SCION constraints**: For constraints regarding the algorithm, see the `signature` field.

- `issuerUniqueID` field: If set, it enables reusing the issuer name over time.

- **SCION constraints**: This field is disallowed in SCION and MUST NOT be used.

- `subjectUniqueID` field: If set, it enables reusing the subject name over time.
- `issuerUniqueID` field: it MUST NOT be used in SCION.

- **SCION constraints**: This field is disallowed in SCION and MUST NOT be used.
- `subjectUniqueID` field: it MUST NOT be used in SCION.

- `extensions` sequence: Defines the extensions of the certificate. For a description of all extensions used in SCION, see [](#exts).

Expand Down Expand Up @@ -712,7 +705,7 @@ The `basicConstraints` extension specifies whether the certificate subject may a
The `basicConstraints` extension includes the following attributes relevant for SCION:

- `cA` attribute: Specifies whether the certificate subject may act as a CA. If yes, this attribute MUST be set to TRUE.
- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the allowed length of the certification path.
- `pathLenConstraint` attribute: This attribute is only relevant if the `cA` attribute is set to TRUE. It specifies the maximum number of CA certificates that may follow this CA certificate in the certification chain. Value "0" means that this CA may only issue end-entity certificates, but no CA certificates. If the attribute is not set, there is no limit to the maximum length of the certification path.

The settings of the `basicConstraints` extension differ for each SCION control-plane PKI certificate type. The next table shows the specifications per certificate type.

Expand Down Expand Up @@ -935,7 +928,7 @@ The value of the `gracePeriod` field in a base TRC MUST be zero. The value of th

##### `noTrustReset` Boolean {#notrustreset}

The `noTrustReset` Boolean specifies whether a trust reset is forbidden by the ISD. Within a TRC update chain, this value CANNOT be changed by a regular or sensitive update. However, it is possible to change the `noTrustReset` value in the event of a trust reset, where a new base TRC is created.
The `noTrustReset` Boolean specifies whether a trust reset is forbidden by the ISD. Within a TRC update chain, this value MUST NOT be changed by a regular or sensitive update. However, it is possible to change the `noTrustReset` value in the event of a trust reset, where a new base TRC is created.

The `noTrustReset` field is optional and defaults to FALSE.

Expand Down

0 comments on commit 3d19aa9

Please sign in to comment.