RFC 4809
Requirements for an IPsec Certificate Management Profile
Requirements for an IPsec Certificate Management Profile 🎀
Okay bestie, the header tea first 💅
- Stream: Network Working Group
- RFC number: 4809
- Authors (all listed as Editors, "Ed."): C. Bonatti, S. Turner, and G. Lebovitz
- Affiliations shown: IECA and Juniper
- Category: Informational
- Date: February 2007
- Obsoletes / Updates: none listed in the header block 🫶
Part 1 of 9! More parts are coming, so stay tuned bestie 💜
Status of This Memo ✨
okay so this memo is giving "FYI" energy 💖 It's here to provide information for the Internet community. It does not specify an Internet standard of any kind, so no pressure to implement anything 🌸 Distribution of this memo is unlimited, so share it with everyone you know 🦋
Copyright Notice 🌈
Copyright (C) The IETF Trust (2007). Legal stuff, but it's giving protected 💅
Abstract 🧚
ngl this is the main-character summary of the whole doc 👑 It describes and identifies the requirements for transactions that handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) Virtual Private Network (VPN) Systems using Internet Key Exchange (IKE) (versions 1 and 2) and Public Key Infrastructure (PKI) Systems. These requirements are designed for enterprise-scale IPsec VPN deployments, which is seriously ambitious 😭 It's also intended that a standards track profile of a management protocol will be created to address many of these requirements, so there's a sequel coming 🔥
Table of Contents 📋
1. Introduction ....................................................4
1.1. Scope ......................................................5
1.2. Non-Goals ..................................................6
1.3. Definitions ................................................6
1.4. Requirements Terminology ...................................8
2. Architecture ....................................................9
2.1. VPN System .................................................9
2.1.1. IPsec Peer(s) .......................................9
2.1.2. VPN Administration Function (Admin) .................9
2.2. PKI System ................................................10
2.3. VPN-PKI Interaction .......................................11
3. Requirements ...................................................13
3.1. General Requirements ......................................13
3.1.1. One Protocol .......................................13
3.1.2. Secure Transactions ................................13
3.1.3. Admin Availability .................................13
3.1.4. PKI Availability ...................................14
3.1.5. End-User Transparency ..............................14
3.1.6. PKC Profile for PKI Interaction ....................14
3.1.6.1. Identity ..................................15
3.1.6.2. Key Usage .................................15
3.1.6.3. Extended Key Usage ........................15
3.1.6.4. Revocation Information Location ...........15
3.1.7. Error Handling .....................................15
3.2. Authorization .............................................15
3.2.1. One Protocol .......................................15
3.2.2. Bulk Authorization .................................16
3.2.3. Authorization Scenario .............................16
3.2.4. Authorization Request ..............................17
3.2.4.1. Specifying Fields within the PKC ..........17
3.2.4.2. Authorizations for Rekey, Renewal,
and Update ................................18
3.2.4.3. Other Authorization Elements ..............18
3.2.4.4. Cancel Capability .........................19
3.2.5. Authorization Response .............................19
3.2.5.1. Error Handling for Authorization ..........20
3.3. Generation ................................................20
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......21
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair,
Admin Constructs PKS Request, Admin Signs PKC
Request ............................................22
3.3.3. Generation Method 3: Admin Generates Key Pair,
Constructs PKC Request, and Signs PKC Request ......23
3.3.4. Method 4: PKI Generates Key Pair ...................24
3.3.5. Error Handling for Generation ......................25
3.4. Enrollment ................................................25
3.4.1. One Protocol .......................................25
3.4.2. On-line Protocol ...................................25
3.4.3. Single Connection with Immediate Response ..........25
3.4.4. Manual Approval Option .............................25
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly ..26
3.4.6. Enrollment Method 2a: Peer Enrolls through Admin ...27
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin ...28
3.4.8. Enrollment Method 3a: Admin Authorizes and
Enrolls Directly to PKI ............................30
3.4.9. Enrollment Method 3b: Admin Requests and PKI
Generates and Sends PKC ............................31
3.4.10. Confirmation Handshake ............................32
3.4.11. Error Handling for Enrollment .....................33
3.5. Lifecycle .................................................34
3.5.1. One Protocol .......................................34
3.5.2. PKC Rekeys, Renewals, and Updates ..................35
3.5.2.1. Rekey Request .............................36
3.5.2.2. Renew Request .............................36
3.5.2.3. Update Request ............................37
3.5.2.4. Error Handling for Rekey, Renewal,
and Update ................................38
3.5.2.5. Confirmation Handshakes ...................38
3.5.3. Revocation .........................................38
3.6. Repositories ..............................................39
3.6.1. Lookups ............................................39
3.6.2. Error Handling for Repository Lookups ..............40
3.7. Trust .....................................................40
3.7.1. Trust Anchor PKC Acquisition .......................40
3.7.2. Certification Path Validation ......................41
3.7.3. Revocation Checking and Status Information .........41
3.7.4. Error Handling in Revocation Checking and
Certificate Path Validation ........................42
4. Security Considerations ........................................42
5. References .....................................................43
5.1. Normative References ......................................43
5.2. Informative References ....................................43
6. Acknowledgements ...............................................431. Introduction ✨
okay so this section sets the vibe: it describes and identifies the requirements for transactions that handle PKC lifecycle transactions between [IPsec] VPN Systems using IKE ([IKEv1] and [IKEv2]) and PKI Systems 💜 It's a requirements list for a transaction-based approach. Other models are conceivable, like a directory-centric approach, but those requirements are beyond the scope of this document 🙈
This doc lists the requirements for PKC lifecycle transactions between different VPN System and PKI System products 🦋 The goal is to better enable large-scale, PKI-enabled IPsec deployments with a shared set of transactions. Requirements for both the IPsec and PKI products are discussed. They're carefully designed to get security without wrecking ease of management and deployment, even when the deployment has tens of thousands of IPsec users and devices 😭🔥
The requirements cover the entire PKC lifecycle for a PKI-enabled VPN System: authorization (of PKC issuance), generation (public-private key pair and PKC request), enrollment (PKC request, PKC response, and confirmation), maintenance (rekey, renew, update, revoke, and confirm), and repository lookups 💅 These transactions let a VPN Operator:
- Use a VPN Administration function (Admin), which is introduced in this document, to manage PKC authorization and possibly act as the sole interface for the VPN System and the PKI System. 🎀
- Authorize individual or batches of PKC issuances based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). These authorizations can occur either prior to the enrollment or in the same transaction as the enrollment. 🌸
- Provision PKI-based user or machine identity to IPsec Peers, on a large scale. 🧚
- Set the corresponding gateway or client authorization policy for remote access and site-to-site connections. 🦋
- Establish policies for automatic PKC rekeys, renewals, and updates. ⭐
- Ensure timely revocation information is available for PKCs used in IKE exchanges. 💖
These requirements are meant to profile a certificate management protocol that the VPN System will use to talk to the PKI System. Note that this profile will be in another document 📄 The certificate management profile will also clarify and constrain existing PKIX (PKI for X.509 Certificates) and IPsec standards to limit deployment complexity. Some requirements may need either a new protocol, or changes or extensions to an existing protocol 🤓
The dream outcome of the requirements and profile documents is that both IPsec and PKI vendors make interoperable products to enable large-scale IPsec System deployments, and do it as quickly as possible 🚀 For example, a VPN Operator should be able to use any conforming IPsec implementation (VPN Administration or IPsec Peer) of the certificate management profile with any conforming PKI vendor's implementation to do the VPN rollout and management. Iconic, right? 👑
1.1. Scope 🌈
This section is where the doc decides what it's actually about 💅 It addresses requirements on transactions between the VPN Systems and the PKI Systems, and between the VPN Administration and IPsec Peers. The requirements aim to meet eighty percent of the market needs for large-scale deployments (i.e., VPNs including hundreds or thousands of managed VPN gateways or VPN remote access clients) 😭 Environments will understandably exist where large-scale deployment tools are wanted, but local security policy stringency won't allow those commercial tools. The solution will possibly miss the needs of the highest ten percent of stringency and the lowest ten percent of convenience requirements. Use cases will be considered or rejected based on this eighty percent rule 🫶 The needs of small deployments are a stated non-goal; however, service providers using the scoped solution and applying it to many smaller deployments in aggregate may address them 🍓
Gateway-to-gateway access and end-user remote access (to a gateway) are both covered ✨ End-to-end communications are not necessarily excluded, but they're intentionally not the focus 🙈
Only VPN-PKI transactions that ease and enable scalable PKI-enabled IPsec deployments are addressed 💜
1.2. Non-Goals 🙅♀️
okay bestie, let's talk about what this doc is not covering 💅
the scenario for PKC cross-certification? not addressed here 🙈
the protocol spec for the VPN-PKI interactions? also not addressed 🥱
the protocol spec for VPN Administrator to Peer transactions? not addressed either. these are considered vendor proprietary 🔒 they might get standardized later so VPN Administration function stations and IPsec Peers from different vendors can interoperate, but that's way beyond this current effort, so this doc will describe them as opaque transactions 🫥
and the protocol spec for Registration Authority - Certificate Authority (RA-CA), CA-Repository, and RA-Repository interactions? not addressed 🚫
1.3. Definitions 📚
okay the glossary era is here, let's gooo 🌸
VPN System 💜 the VPN System is made up of the VPN Administration function (more on that below), the IPsec Peers, and the communication mechanism between the VPN Administration and the IPsec Peers. it gets a deeper dive in Section 2.1.
PKI System 🔐 the PKI System, or just PKI, is the set of functions needed to authorize, issue, and manage PKCs. it gets a deeper dive in Section 2.2.
(VPN) Operator 👑 the Operator is the person or group of people who define security policy and configure the VPN System to enforce that policy, using the VPN Administration function.
IPsec Peer (Gateway or Client) 🦋 for this doc, an IPsec Peer (or just "Peer") is any VPN System component that talks IKE and IPsec to another Peer so they can create an IPsec Security Association for communications. it can be a traditional security gateway (two network interfaces, one for the protected network and one for the unprotected network) or an IPsec client (a single network interface). either way, the Peer can pass traffic with no IPsec protection, and can add IPsec protection to chosen traffic streams. see Section 2.1.1 for more deets ✨
(VPN) Admin 🎀 the Admin is the VPN System function that interacts with the PKI System to set up PKC provisioning for the VPN connections. see Section 2.1.2 for more ✨
End Entity 🧚 an end entity is the entity or subject identified in a PKC. it's the one entity that will actually use a private key tied to a PKC to digitally sign data. in this doc an IPsec Peer is definitely an end entity, but the VPN Admin can also be one. also, end entities can have different PKCs for different purposes (e.g., signature vs. key exchange, Admin-functions vs. Peer-functions) 🍓
PKC Rekey 🔄 the routine procedure of replacing a PKC with a new one that has a new public key for the same subject name. a rekey process can rely on the existing key pair to bootstrap authentication for the new enrollment.
PKC Renewal 🌈 getting a new PKC with the same public key because the existing one is expiring. renewal happens before the existing PKC expires so there are no connection outages 🙌 a renewal process can rely on the existing key pair to bootstrap authentication for the new enrollment.
PKC Update ✏️ a special renewal-like situation where a PKC needs to change before it expires because something in its subject's info changed. examples might be a change of address, telephone number, or name (like a name change due to marriage of the end entity). an update process can rely on the existing key pair to bootstrap authentication for the new enrollment.
Registration Authority (RA) 📝 an optional entity in a PKI System that handles some of the admin tasks needed to register end entities, like confirming the subject's identity and checking that the subject actually has the private key for the public key requested for a PKC.
Certificate Authority (CA) 🏛️ an authority in a PKI System that one or more users trust to create and sign PKCs. super important: the CA is responsible for PKCs during their whole lifetime, not just for issuing them 💀
Repository 🗄️ an Internet-accessible server in a PKI System that stores PKCs and Certificate Revocation Lists (CRLs) and makes them available for retrieval.
Root CA/Trust Anchor ⚓ a CA that an end entity directly trusts. that means securely getting the value of a Root CA public key takes some out-of-band step(s). this term doesn't mean a Root CA is necessarily at the top of any hierarchy, just that the CA in question is trusted directly 🫶
Certificate Revocation List (CRL) 🚫 a CRL is a CA-signed, timestamped list that identifies revoked PKCs and is made freely available in a repository. Peers retrieve the CRL to check that a PKC being presented to them as the identity in an IKE transaction hasn't been revoked.
CRL Distribution Point (CDP) 📍 the CDP is a PKC extension that identifies the location end entities should retrieve CRLs from to check status information.
Authority Info Access (AIA) 🔍 the AIA is a PKC extension that shows how to access CA information and services for the issuer of the PKC where the extension appears. that info and services may include on-line validation services and Certificate Policy (CP) data.
1.4. Requirements Terminology 🫧
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [MUSTSHOULD]. this is the official rulebook for the capital-letter words, so read carefully 📖✨
2. Architecture 🏗️
this section is the big picture of how a PKI-supported IPsec VPN deployment is built 🌟 first we meet the VPN System, then we get the key facts about the PKI System, and last we see how the VPN and PKI fit together.
2.1. VPN System 🛡️
the VPN System is made of the IPsec Peers and the VPN Administration function, as shown in Figure 1 💖
+---------------------------------------------------+
| |
| +----------+ |
| | VPN | |
| +---------->| Admin |<-------+ |
| | | Function | | |
| | +----------+ | |
| v v |
| +---------+ +---------+ |
| | IPsec | | IPsec | |
| | Peer 1 |<=======================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+---------------------------------------------------+
Figure 1: VPN System2.1.1. IPsec Peer(s) 🦋
the Peers are the two entities that need to establish an IPsec Security Association between them. Figure 1 shows two Peers, but implementations can support an actual number in the hundreds or thousands 🤯 the Peers can be gateway-to-gateway, remote-access-host-to-gateway, or a mix of both. the Peers authenticate themselves in the IKE negotiation using digital signatures made with PKCs from a PKI System 🔏
2.1.2. VPN Administration Function (Admin) 👑
this doc defines the VPN Administration function (from here on called Admin) and gives the Admin great responsibility inside the VPN System 😤 the Admin is a centralized function the Operator uses to interact with the PKI System to set PKI policy (e.g., algorithms, key lengths, lifecycle options, and PKC fields) for groups of IPsec Peers. the Admin also authorizes PKC issuance and can act as the Peer's PKI System interface, which lets it do lots of RA-like functions 💅
it's important to note that, in this doc, the Admin is neither a device nor a person. it's a function 🫢 every large-scale VPN deployment will have the Admin function. it can run on a stand-alone workstation, on a gateway, or on an administration software component. the Admin function can also be the same as the gateway, client device, or software. the diagram shows them as different functions, but they don't need to be different physical entities. so the Admin's architecture and how it talks to the participating IPsec Peers can vary wildly from implementation to implementation. still, some basic functions of the Admin are assumed:
- it, and not the PKI, will define the Certificate Policy (CP) [FRAME] for use in a VPN System. the PKC's characteristics and contents depend on the CP. in VPN Systems, the Operator chooses to strengthen the VPN by using PKI; PKI is a bolt-on to the VPN System. the Operator will configure local security policy partly through the Admin and its authorized PKI-enabled Peers.
- it will interact directly with the PKI System to start authorization for end entity PKCs by sending the parameters and contents for individual PKCs or batches of PKCs based on a pre-agreed template (i.e., both types of authorization requests refer to the pre-agreed template). templates will be agreed out-of-band by the VPN Operator and the PKI Operator. it will get back from the PKI a unique tuple of authorization identifiers and one-time authorization tokens that will authorize Peers to request a PKC 🎟️
- it will deliver instructions to the IPsec Peers, and the Peers will carry them out (e.g., Admin passes Peer information needed to generate keys and the PKC request) 📬
2.2. PKI System 🔐
the PKI System, shown in Figure 2, can be set up and run by the Operator (in-house), be provided by third-party PKI providers that have connectivity available at provisioning time (managed PKI service), or be integrated with the VPN product 🧩
+---------------------------------------------+
| +-------------------------+ |
| v | |
| +--------------+ v |
| | Repository | +----+ +----+ |
| | Certs & CRLs |<-> | CA |<->| RA | |
| +--------------+ +----+ +----+ |
| |
+---------------------------------------------+
Figure 2: PKI Systemthis framework assumes that all VPN components get their PKCs from a single PKI community 💜 an IPsec Peer can accept a PKC from a Peer whose CA is outside the PKI community, but the auto provisioning and life cycle management for that PKC or its trust anchor PKC are out of scope 🙅♀️
the PKI System has a mechanism for handling Admin's authorization requests and PKC enrollments. this mechanism is called the Registration Authority (RA) 📝 it also has a Repository where Peers can retrieve each other's PKCs and revocation info 🗄️ and last, it has the core function of a CA, which uses a public and private key pair and signs PKCs 🏛️ ✨
2.3. VPN-PKI Interaction ✨
Okay bestie, this is the part everybody's really here for 💅 The VPN System and the PKI System talking to each other is the whole point of this requirements doc 🔥 So it makes sense to walk through what it takes to set up, use, and manage PKCs for one Peer so it can build an association with another Peer 🦋
+-----------------------------------------------+
| PKI System |
| |
| +--------------+ |
| | Repository | +----+ +----+ |
| | Certs & CRLs | | CA | | RA | |
| +--------------+ +----+ +----+ |
| |
+-----------------------------------------------+
^ ^ ^
|[G] |[A] |[G]
|[E] |[G] |[E]
|[L] |[E] |[L]
|[R] |[R] |[R]
| |[L] |
+-----+------------------+-------------------+-------+
| | v | |
| | +----------+ | |
| | [G][E][L][R]| VPN |[G][E][L][R] | |
| | +---------->| Admin |<----------+ | |
| | | | Function | | | |
| | | +----------+ | | |
| v v v v |
| +---------+ +---------+ |
| | IPsec | [I] | IPsec | |
| | Peer 1 |<========================>| Peer 2 | |
| +---------+ +---------+ |
| |
| VPN System |
+----------------------------------------------------+
[A] = Authorization: PKC issuance
[G] = Generation: Public key, private key, and PKC request
[E] = Enrollment: Sending PKC request, verifying PKC response, and
confirming PKC response
[I] = IKE and IPsec communication
[L] = Lifecycle: Rekey, renewal, update, revocation, and confirmation
[R] = Repository: Posting and lookupsFigure 3. Architectural Framework for VPN-PKI Interaction
Okay so the [A], [G], [E], [L], and [R] interactions? Those get their requirements in Sections 3.2 through 3.6 🎀 BUT the certificate management profile only covers [A], [E], [L], and [R] 💀 The [I] stuff (IKE and IPsec traffic) is out of scope for this doc, and the actual certification step (binding the public key to the name) happens at the CA and isn't drawn in the figure, so no peeking 🙈
3. Requirements 🌸
3.1. General Requirements 🧚
3.1.1. One Protocol
The target profile, which is based on this requirements doc, MUST call for ONE PROTOCOL or ONE USE PROFILE for each main element of the [A], [E], [L], and [R] interactions. To keep things simple and interoperable 🫶 having a bunch of competing protocols or profiles solving the same problem is best avoided whenever possible.
Meeting some of these requirements might mean making a brand new protocol or a new extension for an existing one. Honestly though, the extension route is much preferred 💜
3.1.2. Secure Transactions
The target certificate management profile MUST specify the [A], [E], [L], and [R] transactions between VPN and PKI Systems. To make those work, the Admin and PKI MUST exchange policy details, identities, and keys. So the way [A], [E], and [L] transactions talk MUST be secured so it gives privacy, authentication, and message data integrity 🔒 The communication method MUST require that mutual trust gets established between the PKI and the Admin (see Section 3.7.1). [R] transactions don't need authentication or message data integrity, because the responses (PKCs and CRLs) are already digitally signed ✨ Whether [R] transactions need privacy depends on the local security policy.
The target certificate management profile will not specify [G] transactions. BUT these transactions MUST be secured for privacy, authentication, and message data integrity, because they're the foundation for all the other transactions 🍓
3.1.3. Admin Availability
The Admin MUST be reachable by the Peers. Most implementations hit this by making sure Peers can connect to the Admin from anywhere on the network or the Internet 🌈 However, Admin-to-Peer communication can be "off-line". In some environments it can be "moving media" (aka the configuration or data gets loaded onto a floppy disk or other media and physically carried over to the IPsec Peers) 💀 It can also be typed straight into the IPsec Peer through a User Interface (UI). In that case the Admin function lives right on the Peer device itself. Most requirements and scenarios in this doc assume the Admin is available online for the whole life of the VPN System.
3.1.4. PKI Availability
Availability is REQUIRED initially for authorization transactions between the PKI and Admin 🔥 After that, more availability is required in most cases, but how much is a decision point for the Operator. Most requirements and scenarios here assume the PKI is online for the whole life of the VPN System.
Off-line interaction between the VPN and PKI Systems (where physical media is the transport) is beyond the scope of this doc 🙅♀️
3.1.5. End-User Transparency
PKI interactions are meant to be invisible to the user ✨ Users SHOULD NOT even be aware that PKI is in use. First-time connections SHOULD consist of no more than a prompt asking for some identification and a pass phrase, plus a status bar letting the user know setup is in progress 🦋
3.1.6. PKC Profile for PKI Interaction
A PKC used for identity in VPN-PKI transactions MUST include all the [CERTPROFILE] mandatory fields. It MUST also contain whatever is needed to support path validation and certificate status checking 👑
It's preferable that the PKC profiles for IPsec transactions [IKECERTPROFILE] and for VPN-PKI transactions (in the certificate management profile) are the same, so one PKC could be used for both sets of transactions 💖 If the profiles don't match, you might end up needing different PKCs (and maybe different processing requirements). Still, the authors urge that progress keeps going on the other parts of this standardization effort no matter where the PKC profile consensus stands 🎀
3.1.6.1. Identity
PKCs MUST support identifying (i.e., naming) Peers and Admins. The following name forms MUST be supported:
- Fully-Qualified Domain Name (FQDN)
- RFC 822 (also called USER FQDN)
- IPv4 Address
- IPv6 Address
3.1.6.2. Key Usage
PKCs MUST support indicating the purposes the key (i.e., digital signature) can be used for. Further, PKCs MUST always indicate that relying parties (i.e., Peers) need to understand the indication 🧠
3.1.6.3. Extended Key Usage
Extended Key Usage (EKU) indications are not required. The presence or absence of an EKU MUST NOT cause an implementation to fail an IKE connection 💅
3.1.6.4. Revocation Information Location
PKCs MUST indicate the location of the CRL so any Peer holding the PKC locally knows exactly where to go and how to request the CRL 🗺️
3.1.7. Error Handling
The protocol for VPN-PKI transactions MUST specify error handling for each transaction. Thorough error condition descriptions and handling instructions will really help interoperability between PKI and VPN System products 🌟
3.2. Authorization 🦋
This section covers the [A] elements labeled in Figure 3.
3.2.1. One Protocol
One protocol MUST be specified for the Admin to PKI (RA/CA) interactions. This protocol MUST support privacy, authorization, authentication, and integrity 🔐 PKCs for authorizing the Admin can be initialized through an out-of-band mechanism.
The transport that carries the authorization SHOULD be reliable (TCP) ✨
The protocol SHOULD be as lightweight as possible 🪶
3.2.2. Bulk Authorization
Bulk authorization MUST be supported by the certificate management profile 📦 Bulk authorization happens when the Admin asks the PKI to set up authorization for several different subjects with almost identical contents. At least one value (more is also fine) has to differ per subject. Since authorizations might happen before any keys exist, the only way to make sure unique authorization identifiers get issued is for at least one value to differ per subject 🧩
Authorization can happen before a PKC enrollment request, or the authorization and the PKC enrollment request can be sent to the PKI at the same time. Both of these authorization scenarios MUST be supported 🙌
A bulk authorization SHOULD happen in one single connection to the PKI (RA/CA), with the number of subjects being one or greater. Implementations SHOULD be able to handle one thousand subjects in a batch authorization 🔥
3.2.3. Authorization Scenario
The authorization scenario for VPN-PKI transactions is a two-step process: an authorization request and an authorization response. Figure 4 shows the key interactions for authorization transactions 🎀
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
| 1
2 |
v
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+Figure 4. Authorization Transactions
- Authorization Request [A]. The Admin sends a list of identities and PKC contents for the PKI System to authorize for enrollment. See Section 3.2.4.
- Authorization Response [A]. The PKI returns a list of unique authorization identifiers and one-time authorization tokens to be used for the enrollment of each PKC (1). The response may indicate success, failure, or errors for any particular authorization. See Section 3.2.5. 💖
3.2.4. Authorization Request 💌
3.2.4.1. Specifying Fields within the PKC
Okay so the Admin authorizes individual PKCs or whole batches of PKC issuances based on a pre-agreed template 📝✨. The VPN Operator and PKI Operator agree on this template, and every authorization request refers back to it 🎀. That's the trick: the requests can stay super lean and still include everything a VPN System needs 💅.
The Admin can send the PKI System the set of PKC contents it wants issued to a group of IPsec Peers 🧚. Basically it's giving, "bestie, if you see a PKC request that looks like THIS, from THIS person, just process it and issue the PKC" 💖.
Requirements for PKC fields used in IPsec transactions are specified in [IKECERTPROFILE] 🔐. Requirements for PKC fields used in VPN-PKI transactions are specified in Section 3.1.6 🦋.
3.2.4.2. Authorizations for Rekey, Renewal, and Update
When the VPN Operator and PKI Operator pre-agree on a template, they MUST also agree on the local policy for PKC renewal and PKC update 📜. Here's what that covers:
- The Admin MUST specify if automatic renewals are allowed. In other words, the Admin authorizes the PKI to process a future renewal for the specified Peer PKC 🔄.
- The Admin MUST specify if PKC update is allowed. That means the Admin authorizes the PKI to accept a future request for a new PKC with changes to non-key-related fields ✏️.
If a PKC renewal is authorized, the Admin MUST further specify:
- Who can renew. Can only the Admin send a renewal request, can the Peer send a request directly to the PKI, or can either?
- How long before the PKC expiration date the PKI will accept and process a renewal. This can be N% of validity period, or the UTC time after which renewal is permitted ⏰.
If a PKC update is authorized, the Admin MUST further specify:
- The aspects of non-key-related fields that are changeable 🎨.
- The entity that can send the PKC Update request. That's only the Admin, only the Peer, or either 👯.
- How long before the PKC expiration date the PKI will accept and process an update. This can be N% of validity period, or the UTC time after which update is permitted 🕰️.
A new authorization by the Admin is REQUIRED for PKC rekey 🔑. No parameters of prior authorizations need to be considered, so start fresh, no baggage 💅.
3.2.4.3. Other Authorization Elements
The Admin MUST have the ability to specify the format for the authorization ID and one-time authorization token 🪪. The one-time authorization token SHOULD be unique per authorization ID 🔐. The more randomness you can get in the relationship between an authorization ID and its one-time authorization token, the better 🎲✨.
The one-time authorization token MUST be in UTF-8 format to avoid incompatibilities that may happen with international characters 🌏. It MUST support normalization as in [CERTPROFILE] 🧼. The Admin MUST have the ability to constrain the UTF-8 character set 🔤.
There MUST be an option to specify a validation period for the authorization ID and its one-time authorization token ⏳. If that validation period is set, any PKC requests using the authorization ID and one-time authorization token that arrive at the PKI outside of the validation period MUST be dropped, and the event logged 🚫📝.
The Protocol SHOULD consider what happens when Admin-requested information conflicts with PKI settings, so the Admin request can't be issued as requested 🙈. For example, the Admin requests a validation period of 3 weeks, but the CA is configured to only allow validation periods of 1 week. Proper conflict handling MUST be specified 🛠️.
3.2.4.4. Cancel Capability
Either the Admin or the Peer can send a cancel authorization message to the PKI 🙅♀️. The canceling entity MUST provide the authorization ID and one-time authorization token in order to cancel the authorization. Once that happens, the authorization is erased from the PKI, and a log entry of the event is written 🧾.
After the cancellation has been verified, the PKI will accept a new authorization request with the exact same contents as the canceled one, except that the identifier MUST be new 🆕. A Cancel, Cancel ACK, ACK type of process is REQUIRED to cover a lost connections scenario 🤝. The PKI MUST NOT process duplicate authorization requests 🚷.
Note that if the PKI has already issued a PKC associated with an authorization, then cancellation of the authorization is not possible. In that case the authorization request SHOULD be refused by the PKI 🛑. Once a PKC has been issued, it MUST be revoked in accordance with Section 3.6 💀.
3.2.5. Authorization Response
If the authorization request is acceptable, the PKI will respond to the Admin with a unique authorization identifier per subject authorization requested, and a one-time authorization token per authorization ID 🎟️. See Section 3.2.4.3 for additional authorization ID and one-time authorization token requirements 📖.
The PKI can alter parameters of the authorization request submitted by the Admin 👀. When that happens, the PKI MUST return all the contents of the authorization request (as modified) to the Admin with the confirmation of authorization success. This lets the Admin do an "operational test" to verify that the issued PKCs will meet its requirements 🧪. If the Admin decides the modified parameters are unacceptable, the authorization should be cancelled in accordance with Section 3.2.4.4 🙅♀️.
After receiving a bulk authorization request from the Admin, the PKI MUST be able to reply YES to those individual PKC authorizations it has satisfied, and NO or FAILED to those requests that can't be satisfied, along with sufficient reason or error codes 📋✨.
A method is REQUIRED to identify whether there is a change in PKI settings between the time the authorization is granted and the time the PKC request occurs, plus what to do about the discrepancy 🕵️♀️.
3.2.5.1. Error Handling for Authorization
Thorough error condition descriptions and handling instructions MUST be provided to the Admin for each transaction in the authorization process 🚨. Providing such error codes will greatly aid interoperability efforts between PKI and IPsec products 🤝💜.
3.3. Generation
This section refers to the [G] elements labeled in Figure 3 🏷️.
Once the PKI System has responded with authorization identifiers and authorization tokens (see Section 3.2), and this information is received at the Admin, the next step is to generate public and private key pairs and construct PKC requests using those key pairs 🔑✨. Key generation can happen in one of three places, depending on local requirements: at the IPsec Peer, at the Admin, or at the PKI. The PKC request can come from the IPsec Peer, from a combination of the Peer and the Admin, or not at all 🌸.
3.3.1. Generation Method 1: IPsec Peer Generates Key Pair, Constructs PKC Request, and Signs PKC Request
This option will be used most often in the field 🙌. It's the most secure method for keying, because the keys are generated on the end entity and the private key never leaves the end entity 🔒💖. The catch is that it's the most computationally intensive for the Peer, since it must be "ASN.1 aware" to support generating and digitally signing the PKC request 🤓.
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
+------>| Admin |
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 5. Generation Interactions:
IPsec Peer Generates Key Pair and Constructs PKC Request- Opaque transaction [G]. Admin sends authorization identifier, one-time authorization token, and any other parameters needed by the Peer to generate the PKC request, including key type and size 📨.
- Generation [G]. Peer receives authorization identifier, one-time authorization token, and any parameters. Peer generates key pair and constructs PKC request 🛠️.
Steps prior to these can be found in Section 3.2 👈. The next step, enrollment, can occur either directly between the Peer and PKI (see Section 3.4.5) or through the Admin (see Section 3.4.6) 🚀.
3.3.2. Generation Method 2: IPsec Peer Generates Key Pair, Admin Constructs PKC Request, Admin Signs PKC Request
This option also supports IPsec Peer generation of a key pair, and it removes the requirement for the Peer to be ASN.1 aware, because the Peer doesn't have to construct or digitally sign the PKC request 🧠. The drawback is that the key pair does need to be provided to the Admin 😬. In the most probable cases, where the Admin function is remotely located from the Peer, this means the private key will leave the cryptographic boundary of the Peer. That's a significant security trade-off to think about 🚨. Whenever possible, it is always better to have private keys generated and never leave the cryptographic boundary of the generating system 🔐💅.
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
3 +-------+
+------>| Admin | 4
| +-------+
|
| 1
V
+--------------------+ +--------+
2 | IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 6. Generation Interactions:
IPsec Peer Generates Key Pair, Admin Constructs PKC Request- Opaque transaction [G]. Admin sends command to Peer to generate key pair, based on parameters provided in the command 📣.
- Generation [G]. Peer generates key pair 🔑.
- Opaque transaction [G]. Peer returns key pair to Admin 📬.
- Generation [G]. Admin constructs and digitally signs PKC request ✍️.
Steps prior to these can be found in Section 3.2 👈. The next step, enrollment, occurs through the Admin (see Section 3.4.7) 💫.
3.3.3. Generation Method 3: Admin Generates Key Pair, Constructs PKC Request, and Signs PKC Request ✨
okay so this option is for when peers literally can't make their own keys 🥺 think PDAs and handsets, where generating an RSA key would be operationally impossible because the processing and battery just can't handle it 🔋💀. There's also the key recovery situation, where the same PKCs get used for other stuff besides IPsec (like local data encryption) and recovery is required, so key escrow is needed from the Peer 🔐. If key escrow happens, the exact requirements and procedures for it are beyond the scope of this document, so we're not going there 🙅♀️
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
+-------+
| Admin | 1
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 7. Generation Interactions:
Admin Generates Key Pair and Constructs PKC Request- Generation [G]. The Admin generates the key pair, constructs the PKC request, and digitally signs the PKC request 💅
Steps prior to these can be found in Section 3.2. The next step, enrollment, happens through the Admin (see Section 3.4.8) 🧚
Separate authorization steps are still worth it even though the Admin is also doing the key generation 🌸 The PKC template, Subject fields, SubjectAltName fields, and more are part of the request, and they have to get from the Admin to the PKI somehow. Instead of inventing a new mechanism, we just reuse the authorization schema 🔁 This also unlocks role-based administration, where Operator 1 is the only one allowed to have the Admin function pre-authorize PKCs, but Operator 2 is the one doing the batch enrollments and VPN device configurations 👑
3.3.4. Method 4: PKI Generates Key Pair 🌈
okay this one is for deployments where end entities can't generate their own keys AND the Admin function is a minimal implementation 🫶 The PKI and Admin pre-agree that the PKI will generate the key pairs and PKCs. This is, in all likelihood, the easiest way to deploy PKCs 😭 but it sacrifices some security, since both the CA and the Admin have access to the private key 💀 Still, in cases where key escrow is required, this may be acceptable 🔑 The Admin basically acts as a proxy for the Peer in the PKC enrollment process 🎀
+--------------+ +-----------------------+
| Repository | | CA/RA | 1
+--------------+ +-----------------------+
+-------+
| Admin |
+-------+
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 8. Generation Interactions:
IPsec Peer Generates Key Pair, Admin Constructs PKC Request- Generation [G]. The PKI generates the key pair.
Steps prior to these can be found in Section 3.2. The next step, enrollment, happens through the Admin (see Section 3.4.9) 🧚
3.3.5. Error Handling for Generation 🚨
Thorough error condition descriptions and handling instructions MUST be provided for each transaction in the key generation and PKC request construction process 📝 Providing those error codes will seriously help interoperability between the PKI and IPsec products 🤝
Error conditions MUST be communicated to the Admin no matter who generated the key or PKC request 📣
3.4. Enrollment 📬
This section refers to the [E] elements labeled in Figure 3 🏷️
No matter where the keys were generated and the PKC request was constructed, an enrollment process needs to happen to request that the PKI issue a PKC, and then the matching PKC gets sent back 💌
The protocol MUST be exactly the same whether the enrollment goes from the Peer to the PKI or from the Admin to the PKI 🫶
3.4.1. One Protocol 🎯
One protocol MUST be specified for enrollment requests, responses, and confirmations 💖
3.4.2. On-line Protocol 🌐
The protocol MUST support enrollment that happens over the Internet, without needing manual intervention 🙌
3.4.3. Single Connection with Immediate Response ⚡
Enrollment requests and responses MUST be able to happen in one on-line connection between the Admin (on behalf of the Peer) or the Peer itself, and the PKI (RA/CA) 🔌
3.4.4. Manual Approval Option 🙅♀️
Manual approval of PKC enrollments takes way too long for large scale implementations, so it is not required 🥱
3.4.5. Enrollment Method 1: Peer Enrolls to PKI Directly 🦋
In this case, the IPsec Peer only talks to the PKI after the Admin tells it to 🫡 This enrollment mode is shown in Figure 9, and the letters in the steps below refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.1) steps are not shown 👀
Most IPsec Systems have plenty of CPU power to generate a public and private key pair strong enough for secure IPsec 💪 So the end entity needs to prove to the PKI that it has such a key pair. This usually goes like this: the PKI sends the end entity a nonce, the end entity signs it, and then sends it back to the Admin along with its public key 🔏
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^
1,3 |
|
|
| +-------+
| | Admin |
| +-------+
|
2,4 |
v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 9. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys and PKC Request,
Enrolls Directly with PKI- Enrollment Request [E]. The IPsec Peer sends PKC requests to the PKI, along with the generated public key 📤
- Enrollment Response [E]. The PKI responds to the enrollment request with either the new PKC it generated or a suitable error indication 📥
- Enrollment Confirmation [E]. The Peer positively acknowledges receipt of the new PKC back to the Admin 🙏
- Enrollment Confirmation Receipt [E]. The PKI sends the enrollment confirmation receipt back to the Peer 🧾✨
3.4.6 Enrollment Method 2a: Peer Enrolls through Admin 🕵️♀️
In this case, the IPsec Peer has generated the key pair and the PKC request, but it doesn't enroll directly with the PKI System 🙅♀️ Instead, it automatically sends its request to the Admin, and the Admin redirects the enrollment to the PKI System 🔀 The PKI System doesn't care where the enrollment comes from, as long as it's a valid enrollment 🫶 Once the Admin gets the PKC response, it automatically forwards it to the IPsec Peer 💌
Most IPsec Systems have plenty of CPU power to generate a public and private key pair strong enough for secure IPsec 💪 So in this case, the end entity needs to prove to the Admin that it has such a key pair. This usually goes like this: the Admin sends the end entity a nonce, the end entity signs it, and then sends it back to the Admin along with its public key 🔏
This enrollment mode is shown in Figure 10, and the letters in the steps below refer to Figure 3. Prior authorization (Section 3.2) and generation (Section 3.3.1) steps are not shown 👀
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 2,6
|
|
v 3,7
1,5 +-------+
+> | Admin |
| +-------+
|
|
4,8 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 10. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys and PKC Request,
Enrolls Through Admin- Opaque Transaction [E]. The IPsec Peer requests a PKC from the Admin, along with the generated public key 🫠
- Enrollment Request [E]. The Admin forwards the enrollment request to the PKI 📨
- Enrollment Response [E]. The PKI responds to the enrollment request with either the new PKC it generated or a suitable error indication 📬
- Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer 🏃♀️
- Opaque Transaction [E]. The Peer positively acknowledges receipt of the new PKC back to the Admin 🙌
- Enrollment Confirmation [E]. The Admin forwards the enrollment confirmation back to the PKI 💅
- Enrollment Confirmation Receipt [E]. The PKI sends the enrollment confirmation receipt back to the Admin 🧾
- Opaque Transaction [E]. The Admin forwards the PKI's enrollment confirmation receipt back to the Peer 🎉
3.4.7. Enrollment Method 2b: Peer Enrolls through Admin 🎀
okay so in this one, the IPsec Peer makes the key pair itself, but the PKC request gets built and signed by the Admin 🧚 the PKI System doesn't care who sent the enrollment as long as it's a valid one 💅 once the Admin grabs the PKC, it automatically forwards it to the IPsec Peer along with the key pair 🫶
some IPsec Systems don't have enough CPU power to generate a public and private key pair that's strong enough for secure IPsec 😭 so the Admin has to prove to the PKI that it actually has such a key pair 🔐 this is usually done by the PKI sending the Admin a nonce, which the Admin signs and sends back to the PKI along with the end entity's public key ✨ the downside is that the private key will eventually get sent over the wire (hopefully securely!!) from Admin to the IPsec Peer 🙈 whenever possible, it's preferred to keep a key inside its cryptographic boundary of origin 💜 if you don't, the system is open to the private keys getting sniffed and figured out 💀
this enrollment mode is shown in Figure 11, and the letters in the steps below refer to Figure 3 🦋 the prior authorization (Section 3.2) and generation (Section 3.3.2) steps aren't shown
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 11. VPN-PKI Interaction Steps:
IPsec Peer Generates Keys, Admin Constructs and
Signs PKC Request, Enrolls through Admin- Enrollment Request [E]. The Admin requests a PKC from the PKI, providing the generated public key. ✨
- Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication. 📬
- Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer. 🌸
- Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin. 💖
- Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI. 🍓
- Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin. 🧚
- Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer. 👑
3.4.8. Enrollment Method 3a: Admin Authorizes and Enrolls Directly to PKI 💅
in this case, the Admin makes the key pair, the PKC request, and digitally signs the PKC request 🔥 again the PKI System doesn't care where the enrollment came from, as long as it's valid 🎀 once the Admin retrieves the PKC, it automatically forwards it to the IPsec Peer along with the key pair ✨
same vibe as before: some IPsec Systems don't have enough CPU power to make a key pair strong enough for secure IPsec 😭 so the Admin has to prove to the PKI that it has such a key pair 🔐 this is normally done by the PKI sending the Admin a nonce, which the Admin signs and returns to the PKI along with the end entity's public key 🦋 the drawback is that the private key will eventually be sent over the wire (hopefully securely!) from Admin to the IPsec Peer 🙈 whenever possible, it's preferred to keep a key within its cryptographic boundary of origin 💜 failing to do so opens the system up to the private keys being sniffed and discerned 💀
this enrollment mode is shown in Figure 12, and the letters in the steps below refer to Figure 3 🌈 the prior authorization (Section 3.2) and generation (Section 3.3.3) steps aren't shown
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 1,5
|
|
v 2,6
4 +-------+
+->| Admin |
| +-------+
|
|
3,7 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 12. VPN-PKI Interaction Steps:
Admin Generates Keys and PKC Request, and Enrolls Directly
with PKI- Enrollment Request [E]. The Admin requests a PKC from the PKI, providing the generated public key. ✨
- Enrollment Response [E]. The PKI responds to the enrollment request, providing either the new PKC that was generated or a suitable error indication. 📬
- Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer, along with the keys. 🌸
- Opaque Transaction [E]. Peer positively acknowledges receipt of new PKC back to the Admin. 💖
- Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI. 🍓
- Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin. 🧚
- Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer. 👑
3.4.9. Enrollment Method 3b: Admin Requests and PKI Generates and Sends PKC 🦢
so in this instance, the PKI and Admin have agreed beforehand that the PKI will generate keys and certificates whenever it gets an authorization request 🧁 the PKI sends the final product, a key pair and PKC, back to the IPsec Peer through the Admin 🎀 again, the mechanism for Peer to Admin communication is opaque 🫧
the drawback here is that the private key will eventually get sent over the wire (hopefully securely!) from Admin to the IPsec Peer 🙈 whenever possible, it's preferred to keep a key within its cryptographic boundary of origin 💜 failing to do so opens the system to the private keys being sniffed and discerned 💀
this enrollment mode is shown in Figure 13, and the letters in the steps below refer to Figure 3 🦋 the prior authorization (Section 3.2) and generation (Section 3.3.4) steps aren't shown
+--------------+ +-----------------------+
| Repository | | CA/RA |
+--------------+ +-----------------------+
^ 4
|
|
v 1,5
3 +-------+
+->| Admin |
| +-------+
|
|
2,6 v
+--------------------+ +--------+
| IPsec | | IPsec |
| Peer 1 | | Peer 2 |
+--------------------+ +--------+
Figure 13. VPN-PKI Interaction Steps:
PKI Generates Keys, PKC Request, and Enrolls
Directly with PKI- Enrollment Response [E]. The PKI responds to the authorization request sent, providing either the new PKC and public-private key pair that were generated or a suitable error indication. 📬
- Opaque Transaction [E]. The Admin forwards the enrollment response back to the IPsec Peer, along with the keys. 🌸
- Opaque Transaction [E]. Peer positively acknowledge receipt of new PKC back to the Admin. 💖
- Enrollment Confirmation [E]. Admin forwards enrollment confirmation back to the PKI. 🍓
- Enrollment Confirmation Receipt [E]. PKI sends enrollment confirmation receipt back to the Admin. 🧚
- Opaque Transaction [E]. Admin forwards PKI's enrollment confirmation receipt back to the Peer. 👑
3.4.10. Confirmation Handshake 🤝
any time the PKI issues a new PKC, a confirmation of PKC receipt MUST be sent back to the PKI by the Peer or the Admin (forwarding the Peer's confirmation) 🫶
operationally, the Peer MUST send a confirmation to the PKI verifying that it received the PKC, loaded it, and can use it effectively in an IKE exchange 🔥 this requirement is there so that:
- the PKI doesn't publish the new PKC in the repository for others until the Peer can actually use it effectively 📚, and
- a revocation may be invoked if the PKC isn't received and operational within an allowable window of time ⏰
to prove that, the Peer MUST sign a portion of data with the new key 🔏 the result MUST be sent to the PKI 📤 the entity that actually sends the result to the PKI MAY be either the Peer (sending it directly to the PKI) or the Admin (the Peer sends it to the Admin, and the Admin can, in turn, send it to the PKI) 🦋
the Admin MUST acknowledge successful receipt of the confirmation, which signals to the Peer that it may proceed using this PKC in IKE connections ✅ the PKI MUST complete all the processing needed to enable the Peer's operational use of the new PKC (for example, writing the PKC to the repository) before sending the confirmation acknowledgement 🌷 the Peer MUST NOT begin using the PKC until the PKI's confirmation acknowledgement has been received 🚫 bestie, this is the whole handshake, and it's so careful it's kind of iconic 👑
3.4.11. Error Handling for Enrollment ✨
okay so error handling is SO important bestie 😭 Every single transaction in enrollment REQUIRED to have detailed error condition descriptions and handling instructions. Like, no skipping 💅 Good error codes are what keep the PKI and IPsec products playing nicely together, and that's the whole goal 🫶
The profile has to spell out what happens when the request and retrieval fail for some reason. These cases MUST be covered 🔥:
- Admin or Peer cannot send the request.
- Admin or Peer sent the request, but the PKI did not receive the request.
- PKI received the request, but could not read it effectively.
- PKI received and read the request, but some contents of the request violated the PKI's configured policy such that the PKI was unable to generate the PKC.
- The PKI System generated the PKC, but could not send it.
- The PKI sent the PKC, but the requestor (Admin or Peer) did not receive it.
- The Requestor (Admin or Peer) received the PKC, but could not process it due to incorrect contents, or other PKC-construction-related problem.
- The Requestor failed trying to generate the confirmation.
- The Requestor failed trying to send the confirmation.
- The Requestor sent the confirmation, but the PKI did not receive it.
- The PKI received the confirmation but could not process it.
For every one of those cases, these four questions MUST be answered 🧚:
- What does Peer do?
- What does Admin do?
- What does PKI do?
- Is Authorization used?
If something goes wrong after the PKI sends the PKC but before the Peer gets it, the Peer MUST re-request with the same authorization ID and one-time authorization token. The PKI sees that authorization ID and token and MUST send the PKC again. Main character recovery arc 🦋
Also, enrollment errors MUST be sent to the Admin no matter which entity generated the enrollment request. Admin is always in the loop 👑
3.5. Lifecycle
This section is all about the [L] elements labeled in Figure 3 🌸
Once the PKI has issued a PKC for the end entity Peer, the Peer MUST be able to reach the PKI either directly or through the Admin for any later rekeys, renewals, updates, or revocations. The PKI MUST support both options for renewals, updates, and revocations ✨ Rekeys are Admin initiated, so any Peer initiated rekeys MUST be transferred via the Admin. Admin really runs the show 💅
3.5.1. One Protocol
One protocol MUST be specified for rekey, renew, and update requests, responses, and confirmations. It MUST be the same protocol as the one specified in Section 3.4. Consistency is everything 💖
Revocation requests MAY use the same protocol as rekey, renew, and update operations. They MAY also happen over email, telephone, Instant Messaging, etc. 🌈 Very flexible, very iconic.
3.5.2. PKC Rekeys, Renewals, and Updates
Okay so rekeys, renewals, and updates are all basically variants of the PKC enrollment request scenario, just with their own operational and management needs 🎀
- A PKC rekey swaps an end entity's PKC for a new one with a new public key, keeping the same SubjectName and SubjectAltName contents, and this happens before the currently held PKC expires.
- A PKC renewal swaps an end entity's PKC for one with the same public key and the same SubjectName and SubjectAlternativeName contents as an existing PKC, again before that PKC expires.
- A PKC update is a new PKC issuance with the same public key but an altered SubjectName or SubjectAlternativeName, before the end entity's current PKC expires.
When you send a rekey, renew, or update request, you have to send the entire contents of the PKC request to the PKI, not just the parts that changed 📦
The rekey, renew, and update requests MUST be signed by the private key of the old PKC. This lets the PKI verify who the requestor really is, and makes sure an attacker can't submit a request and walk away with a PKC carrying another end entity's identity. Not on my watch 😤🔥
Whether a new key gets used for the new PKC in a renew or update scenario is up to local security policy, and it MUST be specified by the Admin to the PKI in the original authorization request. Reusing the same key is permitted, but not encouraged 🙈 If a new key is used, the update or renew request must be signed by both the old key (to prove the right to make the request) and the new key (the one going into the new PKC). Double signature energy 🖊️🖊️
The new PKC from a rekey, renew, or update is retrieved in-band, using the same mechanism as a brand new PKC request 🦋
After a rekey, renewal, or update has been processed, and until the PKI gets confirmation that the Peer actually received the new PKC, both the old and the new PKCs for the end entity are valid. This means the Peer can keep its IKE connections running on the previous PKC while the whole process is happening. Zero downtime, no cap ✨
Once the dust settles, the PKI has to decide what to do with the old PKC. If it's supposed to become unusable, the PKI needs to add it to the revocation list and remove it from the repository. BUT this should only happen once all the connections that used the old PKC have expired 💀 Whether the old PKC becomes unusable is decided by local policy. Either the PKI or the Admin MUST specify this parameter during the authorization phase. In that case, the PKI or the Admin MUST also specify how long it takes, counting from when the PKI receives the end entity Peer's confirmation of receiving the PKC, until the old PKC is made unusable ⏳
For renew or update requests where new keys were generated, and for rekey requests, once the Peer gets the confirmation acknowledgement from the PKI, it's good practice to destroy the old key pair as soon as possible 🧹 Deleting it can happen once all connections that used the old PKC have expired.
If a PKC has been revoked, it MUST NOT be allowed a rekey, renewal, or update. No comeback for revoked PKCs 🚫
If the PKC expires without a rekey, renewal, or update, an entirely new request MUST be made. Fresh start, new era 🌸
3.5.2.1. Rekey Request
Admins manage rekeys so Peers can keep using the VPN without interruption while they switch to new keys 🫶 Rekeys can happen automatically if the Admin is set up to kick off a new authorization for the rekey.
The scenarios for rekey are left out, since they're the same ones used in the original PKC enrollment from Sections 3.2, 3.3, and 3.4. Why repeat yourself, periodt 💅
3.5.2.2. Renew Request
Admins also manage renewals so Peers keep uninterrupted VPN access, this time with the same key pair 🍓
When the renewal is authorized, the Admin passes certain details about renewal acceptance to the PKI, as described in Section 3.2.4.2. The renewal request MUST match the conditions that were set in the original authorization for:
- Keys: New, existing, or either.
- Requestor: End entity Peer, Admin, or either.
- Period: How soon before PKC expiry.
- Time: Length of time before making the old PKC unusable.
If any of these conditions aren't met, the PKI must reject the renewal and log the event 📝
The scenarios for renewal are left out too, since they're the same ones from Sections 3.2, 3.3, and 3.4 🦋
3.5.2.3. Update Request
An update to a PKC's contents is needed when the details about an end entity Peer's identity change, but the Operator doesn't want to make a whole new PKC and go through a full new authorization 🔄 For example, a gateway device might move from one site to another. Its IPv4 Address in the SubjectAltName extension changes, but everything else can stay the same. Another example is an end user who gets married and changes their last name, or moves from one department to another. Either way, only one field needs to change: the Surname or the Organizational Unit (OU) in the DN 💍
An update is different from a rekey or a renewal in a few ways:
- A new key is not necessary.
- The timing of the update event is not predictable, unlike a scheduled rekey or renewal.
- The update request may occur at any time during a PKC's period of validity.
- Once the update is completed and the new PKC is confirmed, the old PKC should cease to be usable, since its contents no longer accurately describe the subject.
When the update is authorized, the Admin can pass certain details about update acceptance to the PKI, as described in Section 3.2.4.2. The update request MUST match the conditions that were set in the original authorization for:
- Keys: new, existing, or either.
- Requestor: End entity Peer, Admin, or either.
- The fields in the Subject and SubjectAltName that are changeable.
- Time: Length of time before making the old PKC unusable.
If any of these conditions aren't met, the PKI MUST reject the update and log the event 🚨
If no update authorization was made at the time of the original authorization, one can still be made from the Admin to the PKI at any time during the PKC's valid life. When an update is wanted, the Admin must notify the PKI System that an update is authorized for the end entity, and must specify the new contents. Then the Admin starts the update request with those contents, using whichever mechanism the VPN System uses (directly from the end entity to the PKI, from the end entity through the Admin, or directly from the Admin) 🧚
The scenarios for update are left out as well, since they use the same scenarios from the original PKC enrollment in Sections 3.2, 3.3, and 3.4 ✨
3.5.2.4. Error Handling for Rekey, Renewal, and Update
Thorough error condition descriptions and handling instructions are required for each transaction in the rekey, renewal, or update process. Good error codes will really help the PKI and IPsec products interoperate 🤝
3.5.2.5. Confirmation Handshakes
The confirmation handshake requirements are the same as in Sections 3.2, 3.3, and 3.4, with one twist: depending on the Administrative policy, the PKI MUST also issue a revocation on the original PKC before it sends the confirmation response 🌈 Plot twist, but make it make sense 💜
3.5.3. Revocation 🦋
Okay bestie, revocation is how a cert gets cancelled before its time is up 💀 The Peer MUST be able to start a revocation for its own PKC. When it does, the revocation request MUST be signed with the Peer's current key pair for the PKC it wants to revoke. Whether that request goes straight to the PKI or gets sent to Admin first (Admin then proxies or forwards it to the PKI) is up to the implementation 🌸
Admin MUST be able to start a revocation for any PKC issued under a template it controls ✨ Admin identifies itself to the PKI using its own PKC, and it MUST sign any revocation request to the PKI with the private key from its own PKC. The PKI MUST be able to set up Admin(s) with revocation authority, identified by their PKC. Any PKC authorizations must say whether that PKC may be revoked by the Admin (check Section 3.2.3.2 for the details) 👑
The profile MUST name the one protocol, or the one transaction within a protocol, used for both Peer-initiated and Admin-initiated revocations 🎀 The profile MUST also state the size of CRL the client will be ready to support 🍓
Here are the guidelines for revocation in specific transactions 💅
- AFTER RENEW, BEFORE EXPIRATION: The PKI MUST be responsible for revoking the PKC during a renew transaction. The PKI MUST revoke the PKC after it gets the confirm notification from the Peer, and before it sends the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case 😭
- AFTER UPDATE, BEFORE EXPIRATION: The PKI MUST be responsible for revoking the PKC during an update transaction. The PKI MUST revoke the PKC after it gets the confirm notification from the Peer, and before it sends the confirm-ack to the Peer. The Peer MUST NOT revoke its own PKC in this case 🙈
3.6. Repositories 🧚
This section refers to the [R] elements labeled in Figure 3 🌈
3.6.1. Lookups 🔍
The PKI System SHOULD be built so that lookups resolve directly and completely at the URL listed in a CDP or AIA. The PKI SHOULD also be built so that URL contents don't contain referrals to other hosts or URLs 🙅♀️ Referral lookups slow down how long the IKE negotiation takes to finish, and they can make implementations time out, which is not the vibe 😩
CDP MUST be flagged as required in the authorization request. The method MUST also be specified: the HTTP method MUST be method, and the Lightweight Directory Access Protocol (LDAP) method MAY be supported 💖
The whole hierarchical PKC chain (except the trust anchor) MUST be able to be searched in its respective repositories. The info needed for those searches MUST be communicated well enough in the PKCs sent during the IKE transaction 🔥
All PKCs must be retrievable through a single protocol. The final specification will name one protocol as a "MUST", and others MAY be listed as "OPTIONAL" ✨
The general requirements for the retrieval protocol are 🫶
- The protocol can be easily firewalled (including Network Address Translation (NAT) or Port Address Translation (PAT)).
- The protocol can easily run a query against a remote repository on a specific ID element that was given to it in a standard PKC field.
Other things to think about are 🌸
- Relative speed
- Relative ease of administration
- Scalability
Intermediate PKCs will be needed when the CA gets re-keyed, or when a PKI System has multiple CAs 🦋
PKCs MAY have extendedKeyusage to help identify the right PKC for IPsec, though the default behavior is to not use them (see 3.1.5.3) 💜
IPsec Peers MUST be able to resolve Internet domain names and support the mandatory repository access protocol when they start up, so they can do the PKC lookups 🚀
IPsec Peers should cache PKCs to cut down latency when setting up Phase 1. Note that this is an operational issue, not an interoperability issue 🍓
Using lookups when PKCs aren't sent in IKE is a stated non-goal of the profile for now 🙈
3.6.2. Error Handling for Repository Lookups 🚨
Detailed error condition descriptions and handling instructions are required for each transaction in the repository lookup process. Providing these error codes will really help interoperability between PKI and IPsec products 🤝
3.7. Trust 👑
3.7.1. Trust Anchor PKC Acquisition 🗝️
The root PKC MUST reach the Peer through one of two methods 💅
(a) The Peer can get the root PKC through its secure communication with Admin. This means the Peer doesn't need to know as much about how to interact with the PKI 🌷
(b) Admin can command the Peer to retrieve the root cert directly from the PKI. How that retrieval happens is beyond the scope of this document, but it is assumed to happen over an unauthenticated but confidential enrollment protocol 🫧
3.7.2. Certification Path Validation 🛤️
The IPsec Peer MUST perform identity verification based on the fields of the PKC and the parameters that apply to the VPN Security Association 💖 The fields of the PKC used for verification MAY include either the X.500 Distinguished Name (DN) within the Subject Name, or a specific field within the Extension SubjectAltName (per [DOI] 4.6.2.1 Identification Type Values). Usage descriptions for each come next 🦋
The Peers or a Simple Certificate Validation Protocol (SCVP) server MUST validate the certification path, as per RFC 3280. The contents the PKC needs in order to allow this will be listed in the profile document 🔍
The Peer MAY be able to build the certification path itself. However, Admin MUST be able to supply Peers with the trust anchor and any chaining PKCs needed. Admin MAY make sure the template uses the AIA extension in PKCs to help with path validation 🌈
DNS MUST be supported by the Peers so they can resolve the URLs present in CDPs and AIA extensions 🌐
3.7.3. Revocation Checking and Status Information 🕵️♀️
The PKI System MUST provide a mechanism so Peers can check the revocation status of PKCs presented to them for IKE identity. The mechanism should allow access to extremely fresh revocation information ⏰ CRLs were picked as the mechanism for sharing this info. Operators are RECOMMENDED to refresh CRLs as often as logistically possible 💜
A single mandatory protocol mechanism for performing CRL lookups MUST be specified by the final specification 📜
All PKCs used in IKE MUST have cRLDistributionPoint and authorityInfoAccess fields populated with valid URLs. This lets every recipient of the PKC know right away how revocation is to be done, and where to find the revocation info 🗺️ The AIA is needed where multiple layers of CAs exist, and for the case of a CA key roll-over 🎀
IPsec Systems have an OPTION to turn off revocation checking. That might be wanted when the two Peers are talking over a network without access to the CRL service, like at a trade show, in a lab, or in a demo environment 🎪 If revocation checking is OFF, the implementation MUST proceed to use the PKC as a valid identity in the exchange, and it need not perform any check 🙌
If revocation of a PKC is the only way access authorization for the Peer (or user) gets deactivated, then deactivation will be only as fast as the refresh rate of the CRL issued and published by the PKI 🐢 If you need access deactivated more immediately than CRL refreshing can provide, then another authorization mechanism that deactivates access more immediately should be layered into the VPN deployment. That second mechanism is out of the scope of this profile. (Examples are Xauth, L2TP's authentication, etc.) 🛡️
3.7.4. Error Handling in Revocation Checking and Certificate Path Validation 🧯
Detailed error condition descriptions and handling instructions are required for each transaction in the revocation checking and path validation process. Providing these error codes will greatly aid interoperability between PKI and IPsec products 🫶
4. Security Considerations 🔐
This requirements document does not specify a concrete solution, so it has no system-related security considerations per se 🙃 However, the PKI4IPSEC WG intended to profile and use concrete protocols for certificate management (e.g., Cryptographic Message Syntax (CMS), Certificate Management over CMS (CMC), Certificate Request Message Format (CRMF)). The individual security considerations of these protocols should be carefully considered in the profiling effort 😤
Also, this document allows a lot of flexibility in how functions are split between the roles of Peer and Admin. That split is crucial both for successful deployment and for keeping the integrity of the PKI enrollment and management processes. But much of the responsibility for this split necessarily falls to product implementers and system operators, through choosing the right use cases and building security policy constraints. These factors must be carefully considered to keep PKI4IPSEC certificate management secure 🚨💀
5. References 📚
5.1. Normative References
- [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
- [CERTPROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [DOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
- [FRAME] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
- [IKECERTPROFILE] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", Work in Progress, February 2007.
- [IKEv1] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
6. Acknowledgements 🙏
This RFC is substantially based on a prior document developed by Project Dploy. The principle editor of that document was Gregory M. Lebovitz (NetScreen/Juniper). Contributing authors included Lebovitz, Paul Hoffman (VPN Consortium), Hank Mauldin (Cisco Systems), and Jussi Kukkonen (SSH Communications Security). Substantial editorial contributions were made by Leo Pluswick (ICSA), Tim Polk (NIST), Chris Wells (SafeNet), Thomas Hardjono (VeriSign), Carlisle Adams (Entrust), and Michael Shieh (NetScreen/Juniper) 💜
Once brought to the IETF's PKI4IPSEC WG, the following people made substantial contributions: Jim Schaad and Stefan Santesson 🌟
Editors' Addresses 📮
Chris Bonatti, IECA, Inc., EMail: Bonattic@ieca.com
Sean Turner, IECA, Inc., EMail: Turners@ieca.com
Gregory M. Lebovitz, Juniper, EMail: gregory.ietf@gmail.com
Full Copyright Statement 🎀
Okay so, the legal bit, but make it cute 💅 This is Copyright (C) The IETF Trust (2007) 💖
This document is subject to the rights, licenses and restrictions in BCP 78. Except for what BCP 78 sets out, the authors keep all of their rights 🫶
This document and the info in it are provided "AS IS" 😭 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🙈
Intellectual Property 🦋
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed to cover the implementation or use of the technology in this document are valid or in scope. It also doesn't say whether any license under those rights might be available. And it hasn't made any independent effort to find those rights either 🌸 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 ✨
Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any assurances of licenses to be made available. You can also find the results of an attempt to get a general license or permission for implementers or users to use proprietary rights in this spec. All of that lives in the IETF on-line IPR repository at http://www.ietf.org/ipr 💜
The IETF invites any interested party to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🧚
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🌈👑
📦 where this page comes from
- ietf: rfc4809 2007-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms