diff --git a/spec/draft-ietf-acme-dtnnodeid.xml b/spec/draft-ietf-acme-dtnnodeid.xml index ce7e314..e954cac 100644 --- a/spec/draft-ietf-acme-dtnnodeid.xml +++ b/spec/draft-ietf-acme-dtnnodeid.xml @@ -202,7 +202,7 @@ This specification is the first to make use of an Bundle Endpoint ID to identify In this document, the only purpose for which an Bundle Endpoint ID ACME identifier is validated is as a DTN Node ID (see ), but other specifications can define challenge types for other Endpoint ID uses. -Identifiers of type "bundleEID" in certificate requests MUST appear in an extensionRequest attribute containing a subjectAltName extension of type otherName with a name form of BundleEID, identified by id-on-bundleEID of , consistent with the requirements of . +Identifiers of type "bundleEID" in certificate requests SHALL appear in an extensionRequest attribute containing a subjectAltName extension of type otherName with a name form of BundleEID, identified by id-on-bundleEID of , consistent with the requirements of . Because the BundleEID is encoded as an IA5String it SHALL be treated as being in the percent-encoded form of . Any "bundleEID" identifier which fails to properly percent-decode SHALL be rejected with an ACME error type of "malformed". @@ -233,6 +233,9 @@ The ACME server validates control of the Node ID by verifying that received Resp Similar to the ACME use case for validating email address ownership , this challenge splits the token into several parts, each being transported by a different channel, and the Key Authorization result requires combining all parts of the token. +A separate challenge identifier is used as a filter by BP agents similarly to the challenge "from" email address of . + + The token parts are:
@@ -240,11 +243,11 @@ The token parts are: token-chal:
-This token is unique to, and identifies, each ACME authorization. -It is contained in the Challenge Object of as well as the Challenge Bundle of and Response Bundle of . +This token is unique to each ACME authorization. +It is contained in the Challenge Object of . Each authorization can consist of multiple Challenge Bundles (e.g. taking different routes), but they all share the same token-chal value. -This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization) and also allows the ACME client's BP agent to filter-in only valid Challenge Bundles. -This token is also accessible to DTN on-path eavesdroppers. +This ensures that the Key Authorization is bound to the specific ACME challenge (and parent ACME authorization). +This token does not appear on the BP channel so that any eavesdropper knowing the client's account key thumbprint (e.g. from some other validation method) is not able to impersonate the client.
token-bundle: @@ -257,11 +260,10 @@ This token is also accessible to DTN on-path eavesdroppers.
-For each ACME server, the pair of token-chal and token-bundle values is the unique correlator between Challenge and Response bundles. Because multiple Challenge Bundles can be sent to validate the same Node ID, the token-bundle in the response is needed to correlate with the expected Key Authorization digest. -The DTN Node ID Challenge SHALL only be allowed for an EID usable as a DTN Node ID, which . +The DTN Node ID Challenge SHALL only be allowed for an EID usable as a DTN Node ID, which is defined per-scheme in . When an ACME server supports Node ID validation, the ACME server SHALL define a challenge object in accordance with . Once this challenge object is defined, the ACME client may begin the validation. @@ -275,10 +277,10 @@ From either of these entry points an authorization for the "bundleEID" type is i See for more details.
  • -The ACME client obtains the challenge source Node ID and token-chal from the challenge object in accordance with . +The ACME client obtains the id-chal and token-chal from the challenge object in accordance with .
  • -The ACME client indicates to the administrative element of its BP agent the source Node ID and challenge token-chal which is authorized for use and the associated client account key thumbprint. +The ACME client indicates to the administrative element of its BP agent the id-chal which is authorized for use along with the associated token-chal and client account key thumbprint. The ACME client SHALL wait, if necessary, until the agent is configured before proceeding to the next step.
  • @@ -286,7 +288,7 @@ The ACME client POSTs a challenge response to the challenge URL on the ACME serv The payload object is constructed in accordance with .
  • -The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its token-bundle payload, in accordance with . +The administrative element waits for a Challenge Bundle to be received with the authorized ACME parameters, including its id-chal payload, in accordance with .
  • The administrative element concatenates token-bundle with token-chal (each as base64url-encoded text strings) and computes the Key Authorization in accordance with using the full token and client account key thumbprint. @@ -298,7 +300,7 @@ The administrative element computes the SHA-256 digest of the Key Authorization The ACME client waits for the authorization to be finalized on the ACME server in accordance with .
  • -Once the challenge is completed (successfully or not), the ACME client indicates to the BP agent that the validation source and token-chal is no longer usable. +Once the challenge is completed (successfully or not), the ACME client indicates to the BP agent that the id-chal is no longer usable. If the authorization fails, the ACME client MAY retry the challenge from Step .
    • @@ -333,7 +335,7 @@ If validation is not successful, a client may retry the challenge which starts i When responding to a Challenge Bundle, a BP agent SHALL send a single Response Bundle in accordance with . -A BP agent SHALL respond to ACME challenges only within the interval of time, only for the Node ID, and only for the token-chal indicated by the ACME client. +A BP agent SHALL respond to ACME challenges only within the interval of time and only for the id-chal indicated by the ACME client. A BP agent SHALL respond to multiple Challenge Bundles with the same ACME parameters but different bundle identities (source Node ID and timestamp); these correspond with the ACME server validating via multiple routing paths.
    @@ -349,19 +351,21 @@ The DTN Node ID Challenge request object has the following content:
    The string "dtn-nodeid-01".
    -
    source (required, array of string):
    +
    id-chal (required, string):
    -An unordered list of possible source Node ID of bundles originating at the BP agent(s) of the ACME server. -See for a discussion of multi-perspective validation using multiple sources. -The array SHALL be non-empty. -The array MAY contain Node IDs which are not actually used as a challenge bundle source. +This is a random value associated with a challenge which allows a client to filter valid Challenge Bundles. +The same value is used for all Challenge Bundles associated with an ACME challenge, including multi-perspective validation using multiple sources as described in . +This value SHALL have at least 128 bits of entropy. +It SHALL NOT contain any characters outside the base64url alphabet as described in . +Trailing '=' padding characters SHALL be stripped. +See for additional information on randomness requirements.
    token-chal (required, string):
    -A random value that uniquely identifies the challenge. -This value MUST have at least 128 bits of entropy. -It MUST NOT contain any characters outside the base64url alphabet as described in . -Trailing '=' padding characters MUST be stripped. +This is a random value, used as part of the Key Authorization algorithm, which is communicated to the ACME client only over the ACME channel. +This value SHALL have at least 128 bits of entropy. +It SHALL NOT contain any characters outside the base64url alphabet as described in . +Trailing '=' padding characters SHALL be stripped. See for additional information on randomness requirements.
    @@ -369,12 +373,12 @@ See for additional information on randomness requiremen { "type": "dtn-nodeid-01", "url": "https://example.com/acme/chall/prV_B7yEyA4", - "source": ["dtn://acme-server/"], + "id-chal": "dDtaviYTPUWFS3NK37YWfQ", "token-chal": "tPUZNY4ONIk6LxErRFEjVw" } -The token-chal value included in this object is fixed for the entire challenge, and may correspond with multiple separate token-bundle values when multiple Challenge Bundles are sent for a single validation. +The token-chal value included in this object applies to the entire challenge, and may correspond with multiple separate token-bundle values when multiple Challenge Bundles are sent for a single validation.
    @@ -432,8 +436,7 @@ The Destination EID SHALL be the ACME-server-normalized Node ID b
    Source Node ID:
    -The Source Node ID SHALL indicate the Node ID of the BP agent of the ACME server performing the challenge. -The challenge bundle source SHALL be present in the "source" array of the challenge object (see ) +The Source Node ID SHALL indicate the Node ID of a BP agent of the ACME server performing the challenge.
    Creation Timestamp and Lifetime:
    @@ -451,12 +454,12 @@ The Challenge Bundle administrative record content SHALL consist
    • -One pair SHALL consist of key 1 with value of ACME challenge token-chal, copied from the challenge object, represented as a CBOR byte string. +One pair SHALL consist of key 1 with value of ACME challenge id-chal, copied from the challenge object, represented as a CBOR byte string.
    • One pair SHALL consist of key 2 with value of ACME challenge token-bundle, represented as a CBOR byte string. The token-bundle is a random value that uniquely identifies the challenge bundle. -This value MUST have at least 128 bits of entropy. +This value SHALL have at least 128 bits of entropy. See for additional information on randomness requirements.
    @@ -484,15 +487,11 @@ The Challenge Bundle was received within the time interval allowed for the chall The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the Challenge Bundle.
  • -The Challenge Bundle Source Node ID is identical to the Node ID indicated in the ACME challenge object. -The comparison of Node IDs SHALL use the comparison logic of the NODE-ID from . -
    • -
  • The Challenge Bundle contains a BIB which covers at least the primary block and payload. That BIB has a security source which is trusted and passes security-context-specific validation (i.e. MAC or signature verification).
  • -The challenge payload contains the token-chal as indicated in the ACME challenge object. +The challenge payload contains the id-chal as indicated in the ACME challenge object. The challenge payload contains a token-bundle meeting the definition in .
    • @@ -541,7 +540,7 @@ The Response Bundle administrative record content SHALL consist o
    • -One pair SHALL consist of key 1 with value of ACME challenge token-chal, copied from the Request Bundle, represented as a CBOR byte string. +One pair SHALL consist of key 1 with value of ACME challenge id-chal, copied from the Request Bundle, represented as a CBOR byte string.
    • One pair SHALL consist of key 2 with value of ACME challenge token-bundle, copied from the Request Bundle, represented as a CBOR byte string. @@ -583,7 +582,7 @@ The Response Bundle contains a BIB which covers at least the primary block and p That BIB has a security source which is trusted and passes security-context-specific validation.
    • -The response payload contains the same token-chal and token-bundle as sent in the Challenge Bundle (this is also how the two bundles are correlated). +The response payload contains the same id-chal and token-bundle as sent in the Challenge Bundle (this is also how the two bundles are correlated). The response payload contains the expected Key Authorization digest computed by the ACME server.
    @@ -649,7 +648,7 @@ When a bundle security certificate is issued based on a validated Node ID SAN, t Multiple Identity Claims A single bundle security CSR MAY contain a mixed set of SAN claims, including combinations of "ip", "dns", and "bundleEID" claims. -There is no restriction on how a certificate combines these claims, but each claim MUST be validated by an ACME server to issue such a certificate as part of an associated ACME order. +There is no restriction on how a certificate combines these claims, but each claim SHALL be validated by an ACME server to issue such a certificate as part of an associated ACME order. This is no different than the existing behavior of but is mentioned here to make sure that CA policy handles such situations; especially related to validation failure of an identifier in the presence of multiple identifiers. The specific use case of allows, and for some network policies requires, that a certificate authenticate both the DNS name of an entity as well as the Node ID of the entity. @@ -660,10 +659,10 @@ The specific use case of allows, and for s ACME extensions specified in this document can be used to request encryption-only or signing-only bundle security certificates. -In order to request signing only bundle security certificate, the CSR MUST include the key usage extension with digitalSignature and/or nonRepudiation bits set and no other bits set. +In order to request signing only bundle security certificate, the CSR SHALL include the key usage extension with digitalSignature and/or nonRepudiation bits set and no other bits set. -In order to request encryption only bundle security certificate, the CSR MUST include the key usage extension with keyEncipherment or keyAgreement bits set and no other bits set. +In order to request encryption only bundle security certificate, the CSR SHALL include the key usage extension with keyEncipherment or keyAgreement bits set and no other bits set. Presence of both of the above sets of key usage bits in the CSR, as well as absence of key usage extension in the CSR, signals to ACME server to issue a bundle security certificate suitable for both signing and encryption. @@ -700,7 +699,7 @@ This section separates security considerations into threat categories based on g Because this challenge mechanism is used to bootstrap security between DTN Nodes, the challenge and its response are likely to be transferred in plaintext. The only ACME data present on-the-wire is a random token and a cryptographic digest, so there is no sensitive data to be leaked within the Node ID Validation bundle exchange. -Because each challenge uses a separate token, there is no value in an on-path attacker seeing the tokens from past challenges and/or responses. +Because each challenge uses a separate token pair, there is no value in an on-path attacker seeing the tokens from past challenges and/or responses. It is possible for intermediate BP nodes to encapsulate-and-encrypt Challenge and/or Response Bundles while they traverse untrusted networks, but that is a DTN configuration matter outside of the scope of this document. @@ -729,7 +728,7 @@ Even in a properly-configured DTN it is possible that intermediate bundle router Ultimately, the point of the ACME bundle exchange is to derive a Key Authorization and its cryptographic digest and communicate it back to the ACME server for validation, so the uniqueness of the Key Authorization directly determines the scope of replay validity. The uniqueness of each token-bundle to each challenge bundle ensures that the Key Authorization is unique to the challenge bundle. -The uniqueness of each token-chal to the ACME challenge ensures that the Key Authorization is unique to that ACME challenge. +The uniqueness of each token-chal to the ACME challenge ensures that the Key Authorization is unique to that ACME challenge and not based solely on values visible to on-path eavesdroppers. Having each bundle's primary block and payload block covered by a BIB from a trusted security source (see ) ensures that a replayed bundle cannot be altered in the blocks used by ACME. @@ -773,7 +772,7 @@ Either channel can potentially leak data or provide attack vectors if not proper These channels need to protect against spoofing of messaging in both directions to avoid interruption of normal validation sequencing and to prevent false validations from succeeding. -The ACME server and its BP agent exchange the outgoing token-chal, token-bundle, and Key Authorization digest but these values do not need to be confidential (they are also in plaintext over the BP channel). +The ACME server and its BP agent exchange the outgoing id-chal, token-bundle, and Key Authorization digest but these values do not need to be confidential (they are also in plaintext over the BP channel). Depending on implementation details, the ACME client might transmit the client account key thumbprint to its BP agent to allow computing the Key Authorization digest on the BP agent. @@ -977,11 +976,11 @@ The CDDL extension of BP for the ACME bundle ; All ACME records have the same structure $admin-record /= [0xFFFF, acme-record] acme-record = { - token-chal, + id-chal, token-bundle, ? key-auth-digest ; present for Response Bundles } -token-chal = (1 => bstr) +id-chal = (1 => bstr) token-bundle = (2 => bstr) key-auth-digest = (3 => bstr) @@ -1042,7 +1041,7 @@ This challenge requires that the ACME client respond within a 60 second time win <<[ / type-specific data / 0xFFFF, / record-type-code / { / record-content / - 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / + 1: b64'dDtaviYTPUWFS3NK37YWfQ' / id-chal / 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / } ]>> @@ -1086,7 +1085,7 @@ This response indicates that there is 30 seconds remaining in the response time <<[ / block-type-specific data / 0xFFFF, / record-type-code / { / record-content / - 1: b64'tPUZNY4ONIk6LxErRFEjVw' / token-chal / + 1: b64'dDtaviYTPUWFS3NK37YWfQ' / id-chal / 2: b64'p3yRYFU4KxwQaHQjJ2RdiQ' / token-bundle / 3: b64'mVIOJEQZie8XpYM6MMVSQUiNPH64URnhM9niJ5XHrew' / key auth. digest /