Dynamic Service Negotiation
draft-boucadair-connectivity-provisioning-protocol-19
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8921.
|
|
|---|---|---|---|
| Authors | Mohamed Boucadair , Christian Jacquenet , Dacheng Zhang , Panos Georgatsos | ||
| Last updated | 2020-03-06 | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| IETF conflict review | conflict-review-boucadair-connectivity-provisioning-protocol, conflict-review-boucadair-connectivity-provisioning-protocol, conflict-review-boucadair-connectivity-provisioning-protocol, conflict-review-boucadair-connectivity-provisioning-protocol, conflict-review-boucadair-connectivity-provisioning-protocol, conflict-review-boucadair-connectivity-provisioning-protocol | ||
| Additional resources | |||
| Stream | ISE state | Response to Review Needed | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Eliot Lear | ||
| IESG | IESG state | Became RFC 8921 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> |
draft-boucadair-connectivity-provisioning-protocol-19
RATS L. Lundblade
Internet-Draft Security Theory LLC
Intended status: Standards Track G. Mandyam
Expires: 18 July 2024
J. O'Donoghue
Qualcomm Technologies Inc.
C. Wallace
Red Hound Software, Inc.
15 January 2024
The Entity Attestation Token (EAT)
draft-ietf-rats-eat-25
Abstract
An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, a device like
a smartphone, IoT device, network equipment or such. This claims set
is used by a relying party, server or service to determine the type
and degree of trust placed in the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
attestation-oriented claims.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lundblade, et al. Expires 18 July 2024 [Page 1]
Internet-Draft EAT January 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Entity Overview . . . . . . . . . . . . . . . . . . . . . 7
1.2. EAT as a Framework . . . . . . . . . . . . . . . . . . . 8
1.3. Operating Model and RATS Architecture . . . . . . . . . . 9
1.3.1. Relationship between Evidence and Attestation
Results . . . . . . . . . . . . . . . . . . . . . . . 9
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Top-Level Token Definition . . . . . . . . . . . . . . . . . 12
4. The Claims . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. eat_nonce (EAT Nonce) Claim . . . . . . . . . . . . . . . 14
4.2. Claims Describing the Entity . . . . . . . . . . . . . . 14
4.2.1. ueid (Universal Entity ID) Claim . . . . . . . . . . 15
4.2.1.1. Rules for Creating UEIDs . . . . . . . . . . . . 15
4.2.1.2. Rules for Consuming UEIDs . . . . . . . . . . . . 18
4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs) . . . . 18
4.2.3. oemid (Hardware OEM Identification) Claim . . . . . . 19
4.2.3.1. Random Number Based OEM ID . . . . . . . . . . . 19
4.2.3.2. IEEE Based OEM ID . . . . . . . . . . . . . . . . 20
4.2.3.3. IANA Private Enterprise Number Based OEM ID . . . 20
4.2.4. hwmodel (Hardware Model) Claim . . . . . . . . . . . 21
4.2.5. hwversion (Hardware Version) Claim . . . . . . . . . 22
4.2.6. swname (Software Name) Claim . . . . . . . . . . . . 22
4.2.7. swversion (Software Version) Claim . . . . . . . . . 22
4.2.8. oemboot (OEM Authorized Boot) Claim . . . . . . . . . 23
4.2.9. dbgstat (Debug Status) Claim . . . . . . . . . . . . 23
4.2.9.1. Enabled . . . . . . . . . . . . . . . . . . . . . 24
4.2.9.2. Disabled . . . . . . . . . . . . . . . . . . . . 24
4.2.9.3. Disabled Since Boot . . . . . . . . . . . . . . . 24
4.2.9.4. Disabled Permanently . . . . . . . . . . . . . . 24
4.2.9.5. Disabled Fully and Permanently . . . . . . . . . 25
4.2.10. location (Location) Claim . . . . . . . . . . . . . . 25
4.2.11. uptime (Uptime) Claim . . . . . . . . . . . . . . . . 26
4.2.12. bootcount (Boot Count) Claim . . . . . . . . . . . . 26
4.2.13. bootseed (Boot Seed) Claim . . . . . . . . . . . . . 26
4.2.14. dloas (Digital Letters of Approval) Claim . . . . . . 27
4.2.15. manifests (Software Manifests) Claim . . . . . . . . 28
4.2.16. measurements (Measurements) Claim . . . . . . . . . . 29
Lundblade, et al. Expires 18 July 2024 [Page 2]
Internet-Draft EAT January 2024
4.2.17. measres (Software Measurement Results) Claim . . . . 30
4.2.18. submods (Submodules) . . . . . . . . . . . . . . . . 32
4.2.18.1. Submodule Claims-Set . . . . . . . . . . . . . . 35
4.2.18.2. Detached Submodule Digest . . . . . . . . . . . 36
4.2.18.3. Nested Tokens . . . . . . . . . . . . . . . . . 36
4.3. Claims Describing the Token . . . . . . . . . . . . . . . 36
4.3.1. iat (Timestamp) Claim . . . . . . . . . . . . . . . . 37
4.3.2. eat_profile (EAT Profile) Claim . . . . . . . . . . . 37
4.3.3. intuse (Intended Use) Claim . . . . . . . . . . . . . 38
5. Detached EAT Bundles . . . . . . . . . . . . . . . . . . . . 39
6. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Format of a Profile Document . . . . . . . . . . . . . . 41
6.2. Full and Partial Profiles . . . . . . . . . . . . . . . . 41
6.3. List of Profile Issues . . . . . . . . . . . . . . . . . 42
6.3.1. Use of JSON, CBOR or both . . . . . . . . . . . . . . 42
6.3.2. CBOR Map and Array Encoding . . . . . . . . . . . . . 42
6.3.3. CBOR String Encoding . . . . . . . . . . . . . . . . 43
6.3.4. CBOR Preferred Serialization . . . . . . . . . . . . 43
6.3.5. CBOR Tags . . . . . . . . . . . . . . . . . . . . . . 43
6.3.6. COSE/JOSE Protection . . . . . . . . . . . . . . . . 43
6.3.7. COSE/JOSE Algorithms . . . . . . . . . . . . . . . . 44
6.3.8. Detached EAT Bundle Support . . . . . . . . . . . . . 44
6.3.9. Key Identification . . . . . . . . . . . . . . . . . 44
6.3.10. Endorsement Identification . . . . . . . . . . . . . 45
6.3.11. Freshness . . . . . . . . . . . . . . . . . . . . . . 45
6.3.12. Claims Requirements . . . . . . . . . . . . . . . . . 45
6.4. The Constrained Device Standard Profile . . . . . . . . . 46
7. Encoding and Collected CDDL . . . . . . . . . . . . . . . . . 48
7.1. Claims-Set and CDDL for CWT and JWT . . . . . . . . . . . 48
7.2. Encoding Data Types . . . . . . . . . . . . . . . . . . . 48
7.2.1. Common Data Types . . . . . . . . . . . . . . . . . . 49
7.2.2. JSON Interoperability . . . . . . . . . . . . . . . . 49
7.2.3. Labels . . . . . . . . . . . . . . . . . . . . . . . 50
7.2.4. CBOR Interoperability . . . . . . . . . . . . . . . . 50
7.3. Collected CDDL . . . . . . . . . . . . . . . . . . . . . 50
7.3.1. Payload CDDL . . . . . . . . . . . . . . . . . . . . 50
7.3.2. CBOR-Specific CDDL . . . . . . . . . . . . . . . . . 55
7.3.3. JSON-Specific CDDL . . . . . . . . . . . . . . . . . 56
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 57
8.1. UEID and SUEID Privacy Considerations . . . . . . . . . . 57
8.2. Location Privacy Considerations . . . . . . . . . . . . . 58
8.3. Boot Seed Privacy Considerations . . . . . . . . . . . . 58
8.4. Replay Protection and Privacy . . . . . . . . . . . . . . 58
9. Security Considerations . . . . . . . . . . . . . . . . . . . 58
9.1. Claim Trustworthiness . . . . . . . . . . . . . . . . . . 58
9.2. Key Provisioning . . . . . . . . . . . . . . . . . . . . 59
9.2.1. Transmission of Key Material . . . . . . . . . . . . 59
9.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 60
Lundblade, et al. Expires 18 July 2024 [Page 3]
Internet-Draft EAT January 2024
amp; Charging |.
.+-----------+------------++-----------+---------------+.
. | | .
. +-------------------+ | .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
. . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
.Order Handling Management | | .
. +-------------------+ +-------+-----+--------------+ .
. |Network Topology DB+--+ CPNP Server | .
. +-------------------+ +-+---+---+---+---+-----+----+ .
. | | | | | | .
. +------------------------+-+ | | | | | .
. | Network Dimensioning | | | | | | .
. | & Planning | | | | | | .
. +--------------------------+ | | | | | .
. +----------------------------+-+ | | | +---+----+ .
. | | | | | | AAA | .
. | Network +------------+ | | | +--------+ .
. | Resource | +------------+-+ | +-+----------+ .
. | Management | | Customer | | | Orders | .
. | | | Profiles | | | Repository | .
. +-----------------+ +--------------+ | +------------+ .
. . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
+--------------------------------------+----------------+
| Network Provisioning Manager |
+-------------------------------------------------------+
Figure 5: Order Handling Management Functional Block (Focus on
Internal Interfaces)
The following order handling modes can also be configured on the
server:
Boucadair, et al. Expires September 7, 2020 [Page 16]
Internet-Draft CPNP March 2020
1. Fully automated mode: This mode does not require any action from
the administrator when receiving a request for a service. The
server can execute its decision-making process related to the
orders received and generate corresponding offers.
2. Administrative validation checking: Some or all of the server's
operations are subject to administrative validation procedures.
This mode requires an action from the administrator for every
request received. To that aim, the CPNP methods which can be
automatically handled by the server (or are subject to one or
several validation administrative checks) can be configured on
the server.
8.3. CPNP Session Entries
A CPNP session entry is denoted by a tuplet defined as follows:
o Transport session (typically, IP address of the CPNP client,
client's port number, IP address of the CPNP server, and CPNP
server's port number).
o Incremented Sequence Number (Section 11.3)
o Customer Agreement Identifier: This is a unique identifier
assigned to the order under negotiation by the CPNP client
(Section 9.1.1). This identifier is also used to identify the
agreement that will result from a successful negotiation.
o Provider Agreement Identifier: This is a unique identifier
assigned to the order under negotiation by the CPNP server
(Section 9.1.2). This identifier is also used to identify the
agreement that will result from a successful negotiation.
o Transaction-ID (Section 8.4).
8.4. CPNP Transaction
A CPNP transaction occurs between a client and a server for
completing, modifying, withdrawing a service agreement, and comprises
all CPNP messages exchanged between the client and the server, from
the first request sent by the client to the final response sent by
the server. A CPNP transaction is bound to a CPNP session
(Section 8.3).
Because multiple CPNP transactions can be maintained by the CPNP
client, the client must assign an identifier to uniquely identify a
given transaction. This identifier is denoted as Transaction-ID.
Boucadair, et al. Expires September 7, 2020 [Page 17]
Internet-Draft CPNP March 2020
The Transaction-ID must be randomly assigned by the CPNP client,
according to the best current practice for generating random numbers
[RFC4086] that cannot be guessed easily. Transaction-ID is used for
validating CPNP responses received by the client.
In the context of a transaction, the client needs to randomly select
a sequence number and assign it to the first CPNP message to send.
This number is then incremented for each request message that is
subsequently sent within the ongoing CPNP transaction (see
Section 11.3).
8.5. CPNP Timers
CPNP adopts a simple retransmission procedure which relies on a
retransmission timer denoted as RETRANS_TIMER and a maximum retry
threshold. The use of RETRANS_TIMER and a maximum retry threshold
are described in Section 11.
The response timer (EXPECTED_RESPONSE_TIME) is set by the client to
denote the time, in seconds, the client will wait for receiving a
response from the server to a provisioning quotation order request
(see Section 9.1.6). If the timer expires, the respective quotation
order is cancelled by the client and a CANCEL message is generated
accordingly.
The expected offer timer (EXPECTED_OFFER_TIME) is set by the server
to indicate the time by when the CPNP server is expecting to make an
offer to the CPNP client (see Section 9.1.7). If no offer is
received by then, the CPNP client will consider the order as
rejected.
An offer expiration timer (VALIDITY_OFFER_TIME) is set by the server
to represent the time, in minutes, after which an offer made by the
server becomes invalid (see Section 9.1.8).
8.6. CPNP Operations
CPNP operations are listed below. They may be augmented, depending
on the nature of some transactions or because of security
considerations that may necessitate a distinct CPNP client/server
authentication phase before negotiation begins.
o QUOTATION (Section 9.2.1):
This operation is used by the client to initiate a provisioning
quotation order. Upon receipt of a QUOTATION request, the server
may respond with a PROCESSING, OFFER or a FAIL message. A
Boucadair, et al. Expires September 7, 2020 [Page 18]
Internet-Draft CPNP March 2020
QUOTATION-initiated transaction can be terminated by a FAIL
message.
o PROCESSING (Section 9.2.2):
This operation is used to inform the remote party that the message
(the order quotation or the offer) sent was received and it is
processed. This message can also be issued by the server to
request more time, in which case the client may reply with an ACK
or FAIL message depending on whether extra time can or cannot be
granted.
o OFFER (Section 9.2.3):
This operation is used by the server to inform the client about an
offer that can best accommodate the requirements indicated in the
previously received QUOTATION message.
o ACCEPT (Section 9.2.4):
This operation is used by the client to confirm the acceptance of
an offer made by the server. This message implies a call for
agreement. An agreement is reached when an ACK is subsequently
received from the server, which is likely to happen if the message
is sent before the offer validity time expires; the server is
unlikely to reject an offer that it has already made.
o DECLINE (Section 9.2.5):
This operation is used by the client to reject an offer made by
the server. The ongoing transaction may not be terminated
immediately, e.g., the server/client may issue another offer/
order.
o ACK (Section 9.2.6):
This operation is used by the server to acknowledge the receipt of
an ACCEPT or WITHDRAW message, or by the client to confirm the
time extension requested (conveyed in a PROCESSING message) by the
server for processing the last received quotation order.
o CANCEL (Section 9.2.7):
This operation is used by the client to cancel (quit) the ongoing
transaction.
o WITHDRAW (Section 9.2.8):
Boucadair, et al. Expires September 7, 2020 [Page 19]
Internet-Draft CPNP March 2020
This operation is used by the client to withdraw an agreement.
o UPDATE (Section 9.2.9):
This operation is used by the client to update an existing
agreement. For example, this method can be invoked to add a new
VPN site. This method will trigger a new negotiation cycle.
o FAIL (Section 9.2.10):
This operation is used by the server to indicate that it cannot
accommodate the requirements documented in the PQO conveyed in the
QUOTATION message or to inform the client about an error
encountered when processing the received message. In either case,
the message implies that the server is unable to make offers and
as a consequence, it terminates the ongoing transaction.
This message is also used by the client to reject a time extension
request received from the server (in a PROCESSING message). The
message includes a status code for providing explanatory
information.
The above CPNP primitives are service-independent. CPNP messages may
transparently carry service-specific objects which are handled by the
negotiation logic at either side.
The document specifies the service objects that are required for
connectivity provisioning negotiation (see Section 8.7) purposes.
Additional service-specific objects to be carried in CPNP messages
can be defined in the future for accommodating alternative deployment
schemes or other service provisioning needs.
8.7. Connectivity Provisioning Documents
CPNP makes use of several flavors of Connectivity Provisioning
Documents (CPD). These documents follow the same CPP template
described in [RFC7297].
Requested Connectivity Provisioning Document (Requested CPD):
Refers to the CPD included by a CPNP client in a QUOTATION
request.
Offered Connectivity Provisioning Document (Offered CPD): This
document is included by a CPNP server in an OFFER message. Its
information reflects the proposal of the server to accommodate all
or a subset of the clauses depicted in a Requested CPD. A
validity time is associated with the offer made.
Boucadair, et al. Expires September 7, 2020 [Page 20]
Internet-Draft CPNP March 2020
Agreed Connectivity Provisioning Document (Agreed CPD): If the
client accepts an offer made by the server, the Offered CPD is
included in an ACCEPT message. This CPD is also included in an
ACK message. Thus, a 3-way handshake procedure is followed for
successfully completing the negotiation.
Figure 6 shows a typical CPNP negotiation cycle and the use of the
different types of Connectivity Provisioning Documents.
+------+ +------+
|Client| |Server|
+------+ +------+
|======QUOTATION (Requested CPD)=====>|
|<============PROCESSING==============|
|<========OFFER (Offered CPD)=========|
|=============PROCESSING=============>|
|=========ACCEPT (Agreed CPD)========>|
|<=========ACK (Agreed CPD)===========|
| |
Figure 6: Connectivity Provisioning Documents
A provisioning document can include parameters with fixed values,
loosely-defined values, or any combination thereof. A provisioning
document is said to be concrete if all clauses have fixed values.
A typical evolution of a negotiation cycle would start with a
quotation order with loosely-defined parameters, and then, as offers
are made, it would conclude with concrete provisioning document for
calling for the agreement.
8.8. Child Provisioning Quotation Orders
If the server detects that network resources from another Network
Provider need to be allocated in order to accommodate the
requirements described in a PQO (e.g., in the context of an inter-
domain VPN service, additional PE router resources need to be
allocated), the server may generate child PQOs to request the
appropriate network provisioning operations (see Figure 7). In such
situation, the server behaves also as a CPNP client. The server
associates the parent order with its child PQOs. How this is
achieved is implementation-specific (e.g., this can be typically
achieved by locally adding the reference of the child PQO to the
parent order).
Boucadair, et al. Expires September 7, 2020 [Page 21]
Internet-Draft CPNP March 2020
+------+ +--------+ +--------+
|Client| |Server A| |Server B|
+------+ +--------+ +--------+
| | |
|=====QUOTATION=====>| |
|<====PROCESSING=====| |
| |=====QUOTATION=====>|
| |<====PROCESSING=====|
| |<=======OFFER=======|
| |=====PROCESSING====>|
| |=======ACCEPT======>|
| |<=======ACK=========|
|<=======OFFER=======| |
|=====PROCESSING====>| |
|=======ACCEPT======>| |
|<=======ACK=========| |
| | |
Figure 7: Example of Child Orders
8.9. Multi-Segment Service
A composite service (e.g., connectivity) requested by a customer
could imply multi-segment services (e.g., multi-segment connectivity
spanning an end-to-end scope), in the sense that one single CPNP
request is decomposed into N connectivity requests at the provider's
side (thereby leading to child orders). The Provider is in charge of
handling the complexity of splitting the generic provisioning order
in a multi-segment context. Such complexity is local to the
Provider.
8.10. Negotiating with Multiple CPNP Servers
A CPNP client may undertake multiple negotiations in parallel with
several servers for various reasons, such as cost optimization and
fail-safety. These multiple negotiations may lead to one or many
agreements.
The salient point underlining the parallel negotiation scenarios is
that, although the negotiation protocol is strictly between two
parties, this may not be the case of the negotiation logic. The CPNP
client negotiation logic may need to collectively drive parallel
negotiations, as the negotiation with one server may affect the
negotiation with other servers; for example, it may need to use the
responses from all servers as an input for determining the messages
(and their content) to subsequently send within the course of each
individual negotiation. Timing is therefore an important aspect at
the client's side. The CPNP client needs to have the ability to
Boucadair, et al. Expires September 7, 2020 [Page 22]
Internet-Draft CPNP March 2020
synchronize the receipt of the responses from the servers. CPNP
takes into account this requirement by allowing clients to specify in
the QUOTATION message the time by which the server needs to respond
(see Section 9.1.6).
8.11. State Management
Both the client and the server maintain repositories to store ongoing
orders. How these repositories are maintained is deployment-
specific. It is out of scope of this document to elaborate on such
considerations. Timestamps are also logged to track state change.
Tracking may be needed for various reasons, including regulatory or
billing ones.
In order to accommodate failures that may lead to the reboot of the
client or the server, the use of permanent storage is recommended,
thereby facilitating state recovery.
8.11.1. On the Client Side
This is the list of the typical states that can be associated with a
given order on the client&9.4. Multiple EAT Consumers . . . . . . . . . . . . . . . . . 60
9.5. Detached EAT Bundle Digest Security Considerations . . . 60
9.6. Verification Keys . . . . . . . . . . . . . . . . . . . . 61
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
10.1. Reuse of CBOR and JSON Web Token (CWT and JWT) Claims
Registries . . . . . . . . . . . . . . . . . . . . . . . 61
10.2. CWT and JWT Claims Registered by This Document . . . . . 61
10.3. UEID URN Registered by this Document . . . . . . . . . . 68
10.4. CBOR Tag for Detached EAT Bundle Registered by this
Document . . . . . . . . . . . . . . . . . . . . . . . . 69
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.1. Normative References . . . . . . . . . . . . . . . . . . 69
11.2. Informative References . . . . . . . . . . . . . . . . . 72
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 74
A.1. Claims Set Examples . . . . . . . . . . . . . . . . . . . 74
A.1.1. Simple TEE Attestation . . . . . . . . . . . . . . . 74
A.1.2. Submodules for Board and Device . . . . . . . . . . . 76
A.1.3. EAT Produced by Attestation Hardware Block . . . . . 77
A.1.4. Key / Key Store Attestation . . . . . . . . . . . . . 78
A.1.5. Software Measurements of an IoT Device . . . . . . . 80
A.1.6. Attestation Results in JSON . . . . . . . . . . . . . 82
A.1.7. JSON-encoded Token with Submodules . . . . . . . . . 83
A.2. Signed Token Examples . . . . . . . . . . . . . . . . . . 84
A.2.1. Basic CWT Example . . . . . . . . . . . . . . . . . . 84
A.2.2. CBOR-encoded Detached EAT Bundle . . . . . . . . . . 85
A.2.3. JSON-encoded Detached EAT Bundle . . . . . . . . . . 87
Appendix B. UEID Design Rationale . . . . . . . . . . . . . . . 88
B.1. Collision Probability . . . . . . . . . . . . . . . . . . 88
B.2. No Use of UUID . . . . . . . . . . . . . . . . . . . . . 91
Appendix C. EAT Relation to IEEE.802.1AR Secure Device Identity
(DevID) . . . . . . . . . . . . . . . . . . . . . . . . . 91
C.1. DevID Used With EAT . . . . . . . . . . . . . . . . . . . 92
C.2. How EAT Provides an Equivalent Secure Device Identity . . 92
C.3. An X.509 Format EAT . . . . . . . . . . . . . . . . . . . 93
C.4. Device Identifier Permanence . . . . . . . . . . . . . . 93
Appendix D. CDDL for CWT and JWT . . . . . . . . . . . . . . . . 94
Appendix E. New Claim Design Considerations . . . . . . . . . . 96
E.1. Interoperability and Relying Party Orientation . . . . . 96
E.2. Operating System and Technology Neutral . . . . . . . . . 96
E.3. Security Level Neutral . . . . . . . . . . . . . . . . . 97
E.4. Reuse of Extant Data Formats . . . . . . . . . . . . . . 97
E.5. Proprietary Claims . . . . . . . . . . . . . . . . . . . 97
Appendix F. Endorsements and Verification Keys . . . . . . . . . 98
F.1. Identification Methods . . . . . . . . . . . . . . . . . 99
F.1.1. COSE/JWS Key ID . . . . . . . . . . . . . . . . . . . 99
F.1.2. JWS and COSE X.509 Header Parameters . . . . . . . . 99
F.1.3. CBOR Certificate COSE Header Parameters . . . . . . . 99
F.1.4. Claim-Based Key Identification . . . . . . . . . . . 100
Lundblade, et al. Expires 18 July 2024 [Page 4]
Internet-Draft EAT January 2024
Appendix G. Changes from Previous Drafts . . . . . . . . . . . . 100
G.1. From draft-ietf-rats-eat-24 . . . . . . . . . . . . . . . 100
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 101
1. Introduction
An Entity Attestation Token (EAT) is a message made up of claims
about an entity. An entity may be a device, some hardware or some
software. The claims are ultimately used by a relying party who
decides if and how it will interact with the entity. The relying
party may choose to trust, not trust or partially trust the entity.
For example, partial trust may be allowing a monetary transaction
only up to a limit.
The security model and goal for attestation are unique and are not
the same as for other security standards like those for server
authentication, user authentication and secured messaging. To give
an example of one aspect of the difference, consider the association
and life-cycle of key material. For authentication, keys are
associated with a user or service and set up by actions performed by
a user or an operator of a service. For attestation, the keys are
associated with specific devices and are configured by device
manufacturers. The reader is assumed to be familiar with the goals
and security model for attestation as described in RATS Architecture
[RFC9334] and are not repeated here.
This document defines some common claims that are potentially of
broad use. EAT additionally allows proprietary claims and for
further claims to be standardized. Here are some examples:
* Make and model of manufactured consumer device
* Make and model of a chip or processor, particularly for a
security-oriented chip
* Identification and measurement of the software running on a device
* Configuration and state of a device
* Environmental characteristics of a device like its Global
Positioning Sytem (GPS) location
* Formal certifications received
EAT is constructed to support a wide range of use cases.
Lundblade, et al. Expires 18 July 2024 [Page 5]
Internet-Draft EAT January 2024
No single set of claims can accommodate all use cases so EAT is
constructed as a framework for defining specific attestation tokens
for specific use cases. In particular, EAT provides a profile
mechanism to be able to clearly specify the claims needed, the
cryptographic algorithms that should be used, and other
characteristics for a particular token and use case. Section 6
describes profile contents and provides a profile that is suitable
for constrained device use cases.
The entity's EAT implementation generates the claims and typically
signs them with an attestation key. It is responsible for protecting
the attestation key. Some EAT implementations will use components
with very high resistance to attack like Trusted Platform Modules or
Secure Elements. Others may rely solely on simple software defenses.
Nesting of tokens and claims sets is accommodated for composite
devices that have multiple subsystems.
An EAT may be encoded in either JavaScript Object Notation (JSON)
[RFC8259] or Concise Binary Object Representation (CBOR) [RFC8949] as
needed for each use case. EAT is built on CBOR Web Token (CWT)
[RFC8392] and JSON Web Token (JWT) [RFC7519] and inherits all their
characteristics and their security mechanisms. Like CWT and JWT, EAT
does not imply any message flow.
Following is a very simple example. It is JSON format for easy
reading, but could also be CBOR. Only the Claims-Set, the payload
for the JWT, is shown.
{
"eat_nonce": "MIDBNH28iioisjPy",
"ueid": "AgAEizrK3Q",
"oemid": 76543,
"swname": "Acme IoT OS",
"swversion": "3.1.4"
}
This example has a nonce for freshness. This nonce is the base64url
encoding of a 12 byte random binary byte string. The ueid is
effectively a serial number uniquely identifying the device. This
ueid is the base64url encoding of a 48-bit MAC address preceded by
the type byte 0x02. The oemid identifies the manufacturer using a
Private Enterprise Number [PEN]. The software is identified by a
simple string name and version. It could be identified by a full
manifest, but this is a minimal example.
Lundblade, et al. Expires 18 July 2024 [Page 6]
Internet-Draft EAT January 2024
1.1. Entity Overview
This document uses the term "entity" to refer to the target of an
EAT. Most of the claims defined in this document are claims about an
entity. An entity is equivalent to a target environment in an
attester as defined in [RFC9334].
Layered attestation and composite devices, as described in [RFC9334],
are supported by a submodule mechanism (see Section 4.2.18).
Submodules allow nesting of EATs and of claims-sets so that such
hierarchies can be modeled.
An entity is the same as a "system component", as defined in the
Internet Security Glossary [RFC4949].
Note that [RFC4949] defines "entity" and "system entity" as synonyms,
and that they may be a person or organization in addition to being a
system component. In the EAT context, "entity" never refers to a
person or organization. The hardware and software that implement a
web site server or service may be an entity in the EAT sense, but the
organization that operates, maintains or hosts the web site is not an
entity.
Some examples of entities:
* A Secure Element
* A Trusted Execution Environment (TEE)
* A network card in a router
* A router, perhaps with each network card in the router a submodule
* An Internet of Things (IoT) device
* An individual process
* An app on a smartphone
* A smartphone with many submodules for its many subsystems
* A subsystem in a smartphone like the modem or the camera
An entity may have strong security defenses against hardware invasive
attacks. It may also have low security, having no special security
defenses. There is no minimum security requirement to be an entity.
Lundblade, et al. Expires 18 July 2024 [Page 7]
Internet-Draft EAT January 2024
1.2. EAT as a Framework
EAT is a framework for defining attestation tokens for specific use
cases, not a specific token definition. While EAT is based on and
compatible with CWT and JWT, it can also be described as:
* An identification and type system for claims in claims-sets
* Definitions of common attestation-oriented claims
* Claims defined in CDDL and serialized using CBOR or JSON
* Security envelopes based on CBOR Object Signing and Encryption
(COSE) and Javascript Object Signing and Encryption (JOSE)
* Nesting of claims sets and tokens to represent complex and
compound devices
* A profile mechanism for specifying and identifying specific tokens
for specific use cases
EAT uses the name/value pairs the same as CWT and JWT to identify
individual claims. Section 4 defines common attestation-oriented
claims that are added to the CWT and JWT IANA registries. As with
CWT and JWT, no claims are mandatory and claims not recognized should
be ignored.
Unlike, but compatible with CWT and JWT, EAT defines claims using
Concise Data Definition Language (CDDL) [RFC8610]. In most cases the
same CDDL definition is used for both the CBOR/CWT serialization and
the JSON/JWT serialization.
Like CWT and JWT, EAT uses COSE and JOSE to provide authenticity,
integrity and optionally confidentiality. EAT places no new
restrictions on cryptographic algorithms, retaining all the
cryptographic flexibility of CWT, COSE, JWT and JOSE.
EAT defines a means for nesting tokens and claims sets to accommodate
composite devices that have multiple subsystems and multiple
attesters. Tokens with security envelopes or bare claims sets may be
embedded in an enclosing token. The nested token and the enclosing
token do not have to use the same encoding (e.g., a CWT may be
enclosed in a JWT).
EAT adds the ability to detach claims sets and send them separately
from a security-enveloped EAT that contains a digest of the detached
claims set.
Lundblade, et al. Expires 18 July 2024 [Page 8]
Internet-Draft EAT January 2024
This document registers no media or content types for the
identification of the type of EAT, its serialization encoding or
security envelope. The definition and registration of EAT media
types is addressed in [EAT.media-types].
Finally, the notion of an EAT profile is introduced that facilitates
the creation of narrowed definitions of EATs for specific use cases
in follow-on documents. One basic profile for constrained devices is
normatively defined.
1.3. Operating Model and RATS Architecture
EAT follows the operational model described in Figure 1 in RATS
Architecture [RFC9334]. To summarize, an attester generates evidence
in the form of a claims set describing various characteristics of an
entity. Evidence is usually signed by a key that proves the attester
and the evidence it produces are authentic. The claims set includes
a nonce or some other means to assure freshness.
A verifier confirms an EAT is valid by verifying the signature and
may vet some claims using reference values. The verifier then
produces attestation results, which may also be represented as an
EAT. The attestation results are provided to the relying party,
which is the ultimate consumer of the Remote Attestation Procedure.
The relying party uses the attestation results as needed for its use
case, perhaps allowing an entity to access a network, allowing a
financial transaction or such. In some cases, the verifier and
relying party are not distinct entities.
1.3.1. Relationship between Evidence and Attestation Results
Any claim defined in this document or in the IANA CWT or JWT registry
may be used in evidence or attestation results. The relationship of
claims in attestation results to evidence is fundamentally governed
by the verifier and the verifier's policy.
A common use case is for the verifier and its policy to perform
checks, calculations and processing with evidence as the input to
produce a summary result in attestation results that indicates the
overall health and status of the entity. For example, measurements
in evidence may be compared to reference values the results of which
are represented as a simple pass/fail in attestation results.
It is also possible that some claims in the Evidence will be
forwarded unmodified to the relying party in attestation results.
This forwarding is subject to the verifier's implementation and
policy. The relying party should be aware of the verifier's policy
to know what checks it has performed on claims it forwards.
Lundblade, et al. Expires 18 July 2024 [Page 9]
Internet-Draft EAT January 2024
The verifier may modify claims it forwards, for example, to implement
a privacy preservation functionality. It is also possible the
verifier will put claims in the attestation results that give details
about the entity that it has computed or looked up in a database.
For example, the verifier may be able to put an "oemid" claim in the
attestation results by performing a look up based on a "ueid" claim
(e.g., serial number) it received in evidence.
This specification does not establish any normative rules for the
verifier to follow, as these are a matter of local policy. It is up
to each relying party to understand the processing rules of each
verifier to know how to interpret claims in attestation results.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
In this document, the structure of data is specified in CDDL
[RFC8610] [RFC9165].
The examples in Appendix A use CBOR diagnostic notation defined in
Section 8 of [RFC8949] and Appendix G of [RFC8610].
This document reuses terminology from JWT [RFC7519] and CWT
[RFC8392]:
base64url-encoded: base64url-encoded is as described in [RFC7515],
i.e., using URL- and filename-safe character set [RFC4648] with
all trailing '='s side:
o Created: when the order has been created. It is not handled by
the client until the administrator allows to process it.
o AwaitingProcessing: when the administrator approved the processing
of a created order and the order has not been handled yet.
o PQOSent: when the order has been sent to the server.
o ServerProcessing: when the server has confirmed the receipt of the
order.
o OfferReceived: when an offer has been received from the server.
o OfferProcessing: when a received offer is currently processed by
the client.
o AcceptSent: when the client confirmed the offer to the server.
o Completed: when the offer is acknowledged by the server.
o Cancelled: when the order has failed or cancelled.
Sub-states may be defined (e.g., to track failed vs. cancelled
orders) but those are not shown in Figure 8.
Boucadair, et al. Expires September 7, 2020 [Page 23]
Internet-Draft CPNP March 2020
+------------------+
| Created |-----------------+
+------------------+ |
| |
v |
+------------------+ |
|AwaitingProcessing|----------------+|
+------------------+ ||
| ||
QUOTATION/UPDATE ||
v ||
+------------------+ ||
| PQOSent |---CANCEL------+||
+------------------+ vvv
| +-----+
PROCESSING | |
v | |
+------------------+ CANCEL | C |
| ServerProcessing |------------>| A |
+------------------+ FAIL | N |
| | C |
| | E |
OFFER | L |
| | L |
v | E |
+------------------+ | D |
| OfferReceived |---CANCEL--->| |
+------------------+ | |
| PROCESSING +-----+
v ^^^
+------------------+ |||
| OfferProcessing |---DECLINE-----+||
+------------------+ ||
| ACCEPT ||
v ||
+------------------+ ||
| AcceptSent |---CANCEL-------+|
+------------------+ |
| ACK |
v |
+------------------+ |
| Completed |---WITHDRAW------+
+------------------+
Figure 8: Example of a CPNP Finite State Machine (Client Side)
Boucadair, et al. Expires September 7, 2020 [Page 24]
Internet-Draft CPNP March 2020
8.11.2. On the Server Side
The following lists the states which can be associated with a given
order and a corresponding offer on the server's side:
o PQOReceived: when the order has been received from the client.
o AwaitingProcessing: when the order is being processed by the
server. An action from the server administrator may be needed.
o OfferProposed: when the request has been successfully handled and
an offer has been sent to the client.
o ProcessingReceived: when the server received a PROCESSING for an
offer sent to the client.
o AcceptReceived: when the server received a confirmation for the
offer from the client.
o Completed: when the server acknowledged the offer (accepted by
client) to the client. Transitioning to this state assumes that
the ACK was received by the client (this can be detected by the
server if it receives retransmitted ACCEPT from the client).
o Cancelled: when the order cannot be accommodated or it has been
cancelled by the client. Associate resources must be released in
the latter case, if previously reserved.
o ChildCreated: when a child order has been created in cases where
resources from another Network Provider are needed.
o ChildPQOSent: when a child order has been sent to the remote
server.
o ChildServerProcessing: when a child order is currently processed
by the remote server.
o ChildOfferReceived: when an offer has been received to a child
order from the remote server.
o ChildOfferProcessing: when a received offer to a child order is
currently processed.
o ChildAcceptSent: when the child offer (offer received from the
remote server in response to a child order) is confirmed to the
remote server.
Boucadair, et al. Expires September 7, 2020 [Page 25]
Internet-Draft CPNP March 2020
o ChildCompleted: when an accepted child offer is acknowledged by
the remote server.
Boucadair, et al. Expires September 7, 2020 [Page 26]
Internet-Draft CPNP March 2020
+------------------+ +------------------+
|AwaitingProcessing|<----------| ChildCreated |
+------------------+ +------------------+
| | ^
v | |
+------------------+ | |
| ChildPQOSent |----------------+| Q
+------------------+ || U
| || O
QUOTATION/UPDATE || T
v || A +--------------------+
+---------------------+ CANCEL || T | PQOReceived |
|ChildServerProcessing|------------+|| I +--------------------+
+---------------------+ FAIL vvv O | |
| +-----+ N CANCEL |
PROCESSING | |<---|-------+ PROCESSING
v | | | v
+------------------+ | | +------------------------+
|ChildOfferReceived|----CANCEL---| C |<--| AwaitingProcessing |
+------------------+ | A | +------------------------+
| | N | ^ | OFFER
OFFER | C | | +------------------+
| | E |<DECLINE-| OfferProposed |
| | L | | +------------------+
v | L | | |
+------------------+ | E | | PROCESSING
|ChildOfferReceived|---CANCEL----| D | | v
+------------------+ | | | +------------------+
| | |<DECLINE-| Proc'ingReceived |
PROCESSING | | |+------------------+
| +-----+ | | ACCEPT
v ^^^^^ | v
+------------------+ ||||| | +------------------+
|ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-| AcceptReceived |
+------------------+ ||| | +------------------+
|ACCEPT ||| | |ACK
v ||| | v
+------------------+ ||| | +------------------+
| ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-| Completed |
+------------------+ | | +------------------+
| ACK | |
v | |
+------------------+ | |
| ChildCompleted |---WITHDRAW-----+ |
| +---------------------------+
+------------------+
Figure 9: CPNP Finite State Machine (Server Side)
Boucadair, et al. Expires September 7, 2020 [Page 27]
Internet-Draft CPNP March 2020
9. CPNP Objects
This section defines CPNP objects using the RBNF format defined at
[RFC5511].
Note 1: The formats of CPNP messages are provided using a generic
format. Implementors can adapt RBNF definitions to their
"favorite" message format. For example, JSON [RFC8259] or CBOR
[RFC7049] can be used.
Note 2: CPNP messages cannot be blindly mapped to RESTCONF
messages with the target service being modelled as configuration
data because such data is supposed to be manipulated by a RESTCONF
client only. In such model, the RESTCONF server cannot use a
value other than the one set by the client (e.g., Section 9.2.3)
or remove offers from its own initiative (e.g., Section 9.1.8).
An alternate approach might be to map CPNP operations into
RESTCONF actions (rpc). Assessing the feasibility of such
approach is out of scope.
9.1. Attributes
9.1.1. CUSTOMER_AGREEMENT_IDENTIFIER
CUSTOMER_AGREEMENT_IDENTIFIER is an identifier which is assigned by a
client to identify an agreement. This identifier must be unique to
the client.
Rules for assigning this identifier are specific to the client
(Customer). The value of CUSTOMER_AGREEMENT_IDENTIFIER is included
in all CPNP messages.
The client (Customer) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the client
side (Customer).
The server handles CUSTOMER_AGREEMENT_IDENTIFIER as an opaque value.
9.1.2. PROVIDER_AGREEMENT_IDENTIFIER
PROVIDER_AGREEMENT_IDENTIFIER is an identifier which is assigned by a
server to identify an order. This identifier must be unique to the
server.
Rules for assigning this identifier are specific to the server
(Provider). PROVIDER_AGREEMENT_IDENTIFIER is included in all CPNP
Boucadair, et al. Expires September 7, 2020 [Page 28]
Internet-Draft CPNP March 2020
messages, except QUOTATION messages (because the state is only
present at the client side).
The server (Provider) assigns an identifier to an order under
negotiation before an agreement is reached. This identifier will be
used to unambiguously identify the resulting agreement at the server
side (Provider).
The client handles PROVIDER_AGREEMENT_IDENTIFIER as an opaque value.
9.1.3. TRANSACTION_ID
This object conveys the Transaction-ID introduced in Section 8.4.
9.1.4. SEQUENCE_NUMBER
Sequence Number is a number that is monotonically incremented in
every new CPNP message pertaining to a given CPNP transaction. This
number is used to avoid reply attacks.
Refer to Section 11.3.
9.1.5. NONCE
NONCE is a random value assigned by the CPNP server. It is
RECOMMENDED to assign unique NONCE values for each order.
NONCE is then mandatory to be included in subsequent CPNP client
operations on the associated order (including the resulting
agreement) such as: withdraw the order or update the order.
If the NONCE validation checks fail, the server rejects the request
with a FAIL message including the appropriate failure reason code.
9.1.6. EXPECTED_RESPONSE_TIME
This attribute indicates the time by when the CPNP client is
expecting to receive a response from the CPNP server to a given PQO.
If no offer is received by then, the CPNP client will consider the
quotation order as rejected.
EXPECTED_RESPONSE_TIME follows the date format specified in
[RFC3339].
Boucadair, et al. Expires September 7, 2020 [Page 29]
Internet-Draft CPNP March 2020
9.1.7. EXPECTED_OFFER_TIME
This attribute indicates the time by when the CPNP server is
expecting to make an offer to the CPNP client. If no offer is
received by then, the CPNP client will consider the order as
rejected.
The CPNP server may propose an expected offer time that does not
match the expected response time indicated in the quotation order
message. The CPNP client can accept or reject the proposed expected
time by when the CPNP server will make an offer.
The CPNP server can always request extra time for its processing, but
this may be accepted or rejected by the CPNP client.
EXPECTED_OFFER_TIME follows the date format specified in [RFC3339].
9.1.8. VALIDITY_OFFER_TIME
This attribute indicates the time of validity of an offer made by the
CPNP server. If the offer is not accepted before this date expires,
the CPNP server will consider the CPNP client has rejected the offer;
the CPNP server will silently remove this order from its base.
VALIDITY_OFFER_TIME follows date format specified in [RFC3339].
9.1.9. SERVICE_DESCRIPTION
This document specifies a machinery to negotiate any aspect subject
to negotiation. Service clauses that are under negotiation are
conveyed using this attribute.
The structure of the connectivity provisioning clauses is provided in
the following sub-section.
9.1.9.1. CONNECTIVITY_PROVISIONING_DOCUMENT
The RBNF format of the Connectivity Provisioning Document (CPD) is
shown in Figure 10:
Boucadair, et al. Expires September 7, 2020 [Page 30]
Internet-Draft CPNP March 2020
<CONNECTIVITY_PROVISIONING_DOCUMENT> ::=
<Connectivity Provisioning Component> ...
<Connectivity Provisioning Component> ::=
<CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE> ::=
<Customer Nodes Map>
<SCOPE>
<QoS Guarantees>
<Availability>
<CAPACITY>
<Traffic Isolation>
<Conformance Traffic>
<Flow Identification>
<Overall Traffic Guarantees>
<Routing and Forwarding>
<Activation Means>
<Invocation Means>
<Notifications>
<Customer Nodes Map> ::= <Customer Node> ...
<Customer Node> ::= <IDENTIFIER>
<LINK_IDENTIFIER>
<LOCALISATION>
Figure 10: The RBNF format of the Connectivity Provisioning Document
(CPD)
9.1.10. CPNP Information Elements
An Information Element (IE) is an optional object which can be
included in a CPNP message.
9.1.10.1. Customer Description
The client may include administrative information such as:
o Name
o Contact Information
The format of this Information Element is as follows:
<Customer Description> ::= [<NAME>] [<Contact Information>]
<Contact Information> ::= [<EMAIL_ADDRESS>] [<POSTAL_ADDRESS>]
[<TELEPHONE_NUMBER> ...]
Boucadair, et al. Expires September 7, 2020 [Page 31]
Internet-Draft CPNP March 2020
9.1.10.2. Provider Description
The server may include administrative information in an offer such
as:
o Name
o AS Number ([RFC6793])
o Contact Information
The format of this Information Element is as follows:
<Provider Description> ::= [<NAME>][<Contact Information>][<AS_NUMBER>]
9.1.10.3. Negotiation Options
The client may include some negotiation options such as:
o Setup purpose: A client may request the setup of a service (e.g.,
connectivity) only for testing purposes during a limited period.
The order can be extended to become permanent if the client was
satisfied during the test period. This operation is achieved
using the UPDATE method.
o Activation type: A client may request a permanent or scheduled
activation type. If no activation type clause is included during
the negotiation, this means that the order will be immediately
activated right after the negotiation ends.
The format of this Information Element is as follows:
<Negotiation Options> ::= [<PURPOSE>]
9.2. Operation Messages
This section specifies the RBNF format of CPNP operation messages.
The following operation codes are used:
1: QUOTATION (Section 9.2.1)
2: PROCESSING (Section 9.2.2)
3: OFFER (Section 9.2.3)
4: ACCEPT (Section 9.2.4)
5: DECLINE (Section 9.2.5)
6: ACK (Section 9.2.6)
7: CANCEL (Section 9.2.7)
8: WITHDRAW (Section 9.2.8)
9: UPDATE (Section 9.2.9)
10: FAIL (Section 9.2.10)
11: ACTIVATE (Section 9.2.11)
Boucadair, et al. Expires September 7, 2020 [Page 32]
Internet-Draft CPNP March 2020
These codes are used to unambiguously identify a CPNP operation; the
operation code is conveyed in the "METHOD_CODE" attribute mentioned
in the following sub-sections.
In the following, "VERSION" refers to the CPNP version number. This
attribute MUST be set to 1.
9.2.1. QUOTATION
The format of the QUOTATION message is shown below:
<QUOTATION Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
A QUOTATION message MUST include an order identifier which is
generated by the client (CUSTOMER_AGREEMENT_IDENTIFIER). Because
several orders can be issued to several servers, the QUOTATION
message MUST also include a Transaction-ID.
The message MAY include an EXPECTED_RESPONSE_TIME which indicates by
when the client is expecting to receive an offer from the server.
QUOTATION message MUST also include a requested service description
(that is, requested connectivity provisioning document for
connectivity services).
The message MAY include ACTIVATION_TYPE to request a permanent or
scheduled activation type (e.g., using the ACTIVATE method defined in
Section 9.2.11). If no such clause is included, the default mode is
to assume that the order will be active once the agreed activation
means are successfully invoked (e.g., Section 3.11 of [RFC7297]).
When the client sends the QUOTATION message to the server, the state
of the order changes to "PQOSent" at the client side.
9.2.2. PROCESSING
The format of the PROCESSING message is shown below:
<PROCESSING Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
Boucadair, et al. Expires September 7, 2020 [Page 33]
Internet-Draft CPNP March 2020
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
[<EXPECTED_OFFER_TIME>]
Upon receipt of a QUOTATION message, the server proceeds with parsing
rules (see Section 10). If no error is encountered, the server
generates a PROCESSING response to the client to indicate the PQO has
been received and it is being processed. The server MUST generate an
order identifier which identifies the order in its local order
repository. The server MUST copy the content of
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID fields as conveyed
in the QUOTATION message. The server MAY include an
EXPECTED_OFFER_TIME by when it expects to make an offer to the
client.
Upon receipt of a PROCESSING message, the client verifies whether it
has issued a PQO to that server and which contains the
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID. If no such PQO is
found, the PROCESSING message MUST be silently ignored. If a PQO is
found, the client may check whether it accepts the
EXPECTED_OFFER_TIME and then, it changes to state of the order to
"ServerProcessing".
If more time is required by the server to process the quotation
order, it MAY send a PROCESSING message that includes a new
EXPECTED_OFFER_TIME. The client can answer with an ACK message if
more time is granted (Figure 11) or with a FAIL message if the time
extension request is rejected (Figure 12).
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|============ACK(TimeGranted)========>|
...
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|==========ACCEPT(Agreed CPD)========>|
|<==========ACK(Agreed CPD)===========|
| |
Figure 11: Request More Negotiation Time: Granted
Boucadair, et al. Expires September 7, 2020 [Page 34]
Internet-Draft CPNP March 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<========PROCESSING(time1)===========|
...
|<========PROCESSING(MoreTime)========|
|=====FAIL(More Time Rejected)=======>|
Figure 12: Request More Negotiation Time: Rejected
9.2.3. OFFER
The format of the OFFER message is shown below:
<OFFER Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<VALIDITY_OFFER_TIME>
<OFFERED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
The server answers with an OFFER message to a QUOTATION request
received from the client. The offer will be considered as rejected
by the client if no confirmation (ACCEPT message sent by the client)
is received by the server before the expiration of the validity time.
The server MAY include ACTIVATION_TYPE to indicate whether the offer
is about a permanent or scheduled activation type. The message MAY
include ACTIVATION_SCHEDULE to indicate when the order is to be
activated. If no such clause is included, the default mode is to
assume that the order will be active once the agreed activation means
are successfully invoked (e.g., Section 3.11 of [RFC7297] or
Section 9.2.11).
9.2.4. ACCEPT
The format of the ACCEPT message is shown below:
<ACCEPT Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
Boucadair, et al. Expires September 7, 2020 [Page 35]
Internet-Draft CPNP March 2020
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
This message is used by a client to confirm the acceptance of an
offer received from a server. The fields of this message MUST be
copied from the received OFFER message. This message SHOULD NOT be
sent after the validity time of the offer expires, as indicated by
the server (Section 9.2.3).
9.2.5. DECLINE
The format of the DECLINE message is shown below:
<DECLINE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
[<REASON>...]
The client may issue a DECLINE message to reject an offer.
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER,
TRANSACTION_ID, and NONCE are used by the server as keys to find the
corresponding order. If an order matches, the server changes the
state of this order to "Cancelled" and then returns an ACK with a
copy of the requested CPD to the requesting client.
A DECLINE message MAY include an information to indicate the reason
for declining an offer. The following codes are defined:
1 (Unacceptable gap between the request and the offer)
2 (Conflict with another offer from another server)
3 (Activation type mismatch)
If no order is found, the server returns a FAIL message to the
requesting client. In order to prevent DDoS (Distributed Denial of
Service) attacks, the server SHOULD restrict the number of FAIL
messages sent to a requesting client. It MAY also rate-limit FAIL
messages.
A flow example is shown in Figure 13.
Boucadair, et al. Expires September 7, 2020 [Page 36]
Internet-Draft CPNP March 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|=======QUOTATION(Requested CPD)=====>|
|<============PROCESSING==============|
|<=========OFFER(Offered CPD)=========|
|=============PROCESSING=============>|
|===============DECLINE==============>|
|<================ACK=================|
| |
Figure 13: DECLINE Flow Example
9.2.6. ACK
The format of the ACK message is shown below:
<ACK Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
[<EXPECTED_RESPONSE_TIME>]
[<CONNECTIVITY_PROVISIONING_DOCUMENT>]
[<INFORMATION_ELEMENT>...]
This message is issued by the server to close a CPNP transaction or
by a client to grant more negotiation time to the server.
This message is sent by the server as a response to an ACCEPT,
WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message
MUST include the copy of the service description document as stored
by the server. In particular, the following considerations are taken
into account for connectivity provisioning services:
o A copy of the requested/offered CPD is included by the server if
it successfully handled a CANCEL message.
o A copy of the updated CPD is included by the server if it
successfully handled an UPDATE message.
o A copy of the offered CPD is included by the server if it
successfully handled an ACCEPT message in the context of a
QUOTATION transaction (refer to "Agreed CPD" in Section 8.7).
o An empty CPD is included by the server if it successfully handled
a DECLINE or WITHDRAW message.
A client may issue an ACK message as a response to a time extension
request (conveyed in PROCESSING) received from the server. In such
Boucadair, et al. Expires September 7, 2020 [Page 37]
Internet-Draft CPNP March 2020
case, the ACK message MUST include an EXPECTED_RESPONSE_TIME that is
likely to be set to the time extension requested by the server.
9.2.7. CANCEL
The format of the CANCEL message is shown below:
<CANCEL Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
[<CONNECTIVITY_PROVISIONING_DOCUMENT>]
The client can issue a CANCEL message at any stage during the CPNP
negotiation process before an agreement is reached.
CUSTOMER_AGREEMENT_IDENTIFIER and TRANSACTION_ID are used by the
server as keys to find the corresponding order. If a quotation order
matches, the server changes the state of this quotation order to
"Cancelled" and then returns an ACK with a copy of the requested CPD
to the requesting client.
If no quotation order is found, the server returns a FAIL message to
the requesting client.
9.2.8. WITHDRAW
The format of the WITHDRAW message is shown below:
<WITHDRAW Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
[<AGREED_CONNECTIVITY_PROVISIONING_DOCUMENT>]
[<INFORMATION_ELEMENT>...]
This message is used to withdraw an offer already accepted by the
Customer. Figure 14 shows a typical usage of this message.
Boucadair, et al. Expires September 7, 2020 [Page 38]
Internet-Draft CPNP March 2020
+------+ +------+
|Client| |Server|
+------+ +------+
|============WITHDRAW(CPD)===========>|
|<============PROCESSING==============|
|<===========ACK(Empty CPD)===========|
| |
Figure 14: WITHDRAW Flow Example
The CPNP MUST include the same CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating
the order.
Upon receipt of a WITHDRAW message, the server checks whether an
order matching the request is found. If an order is found, the state
of the order is changed to "Cancelled" and an ACK message including
an Empty CPD is returned to the requesting client. If no order is
found, the server returns a FAIL message to the requesting client.
9.2.9. UPDATE
The format of the UPDATE message is shown below:
<UPDATE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER#x27; characters omitted and without the inclusion of
any line breaks, whitespace, or other additional characters.
Claim: A piece of information asserted about a subject. A claim is
represented as pair with a value and either a name or key to
identify it.
Claim Name: A unique text string that identifies the claim. It is
used as the claim name for JSON encoding.
Claim Key: The CBOR map key used to identify a claim. (The term
"Claim Key" comes from CWT. This document, like COSE, uses the
term "label" to refer to CBOR map keys to avoid confusion with
cryptographic keys.)
Claim Value: The value portion of the claim. A claim value can be
Lundblade, et al. Expires 18 July 2024 [Page 10]
Internet-Draft EAT January 2024
any CBOR data item or JSON value.
Claims Set: The CBOR map or JSON object that contains the claims
conveyed by the CWT or JWT.
This document reuses terminology from RATS Architecure [RFC9334]:
Attester: A role performed by an entity (typically a device) whose
evidence must be appraised in order to infer the extent to which
the attester is considered trustworthy, such as when deciding
whether it is authorized to perform some operation.
Verifier: A role that appraises the validity of evidence about an
attester and produces attestation results to be used by a relying
party.
Relying Party: A role that depends on the validity of information
about an attester, for purposes of reliably applying application
specific actions. Compare /relying party/ in [RFC4949].
Evidence: A set of claims generated by an attester to be appraised
by a verifier. Evidence may include configuration data,
measurements, telemetry, or inferences.
Attestation Results: The output generated by a verifier, typically
including information about an attester, where the verifier
vouches for the validity of the results
Reference Values: A set of values against which values of claims can
be compared as part of applying an appraisal policy for evidence.
Reference Values are sometimes referred to in other documents as
known-good values, golden measurements, or nominal values,
although those terms typically assume comparison for equality,
whereas here reference values might be more general and be used in
any sort of comparison.
Endorsement: A secure statement that an Endorser vouches for the
integrity of an attester's various capabilities such as claims
collection and evidence signing.
This document reuses terminology from CDDL [RFC8610]:
Group Socket: refers to the mechanism by which a CDDL definition is
extended, as described in [RFC8610] and [RFC9165]
Lundblade, et al. Expires 18 July 2024 [Page 11]
Internet-Draft EAT January 2024
3. Top-Level Token Definition
An "EAT" is an encoded (serialized) message the purpose of which is
to transfer a Claims-Set between two parties. An EAT MUST always
contain a Claims-Set. In this document an EAT is always a CWT or JWT.
An EAT MUST have authenticity and integrity protection. CWT and JWT
provide that in this document.
Further documents may define other encodings and security mechanims
for EAT.
The identification of a protocol element as an EAT follows the
general conventions used for CWTs and JWTs. Identification depends
on the protocol carrying the EAT. In some cases it may be by media
type (e.g., in a HTTP Content-Type field). In other cases it may be
through use of CBOR tags. There is no fixed mechanism across all use
cases.
This document also defines another message, the detached EAT bundle
(see Section 5), which holds a collection of detached claims sets and
an EAT that provides integrity and authenticity protection for them.
Detached EAT bundles can be either CBOR or JSON encoded.
The following CDDL defines the top-level $EAT-CBOR-Tagged-Token,
$EAT-CBOR-Untagged-Token and $EAT-JSON-Token-Formats sockets (see
Section 3.9 of [RFC8610]), enabling future token formats to be
defined. Any new format that plugs into one or more of these sockets
MUST be defined by an IETF standards action. Of particular use may
be a token type that provides no direct authenticity or integrity
protection for use with transports mechanisms that do provide the
necessary security services [UCCS].
Nesting of EATs is allowed and defined in Section 4.2.18.3. This
includes the nesting of an EAT that is a different format than the
enclosing EAT, i.e., the nested EAT may be encoded using CBOR and the
enclosing EAT encoded using JSON or vice versa. The definition of
Nested-Token references the CDDL defined in this section. When new
token formats are defined, the means for identification in a nested
token MUST also be defined.
The top-level CDDL type for CBOR-encoded EATs is EAT-CBOR-Token and
for JSON is EAT-JSON-Token (while CDDL and CDDL tools provide enough
support for shared definitions of most items in this document, they
don’t provide enough support for this sharing at the top level).
Lundblade, et al. Expires 18 July 2024 [Page 12]
Internet-Draft EAT January 2024
EAT-CBOR-Token = $EAT-CBOR-Tagged-Token / $EAT-CBOR-Untagged-Token
$EAT-CBOR-Tagged-Token /= CWT-Tagged-Message
$EAT-CBOR-Tagged-Token /= BUNDLE-Tagged-Message
$EAT-CBOR-Untagged-Token /= CWT-Untagged-Message
$EAT-CBOR-Untagged-Token /= BUNDLE-Untagged-Message
EAT-JSON-Token = $EAT-JSON-Token-Formats
$EAT-JSON-Token-Formats /= JWT-Message
$EAT-JSON-Token-Formats /= BUNDLE-Untagged-Message
4. The Claims
This section describes new claims defined for attestation that are to
be added to the CWT [IANA.CWT.Claims] and JWT [IANA.JWT.Claims] IANA
registries.
All definitions, requirements, creation and validation procedures,
security considerations, IANA registrations and so on from CWT and
JWT carry over to EAT.
This section also describes how several extant CWT and JWT claims
apply in EAT.
The set of claims that an EAT must contain to be considered valid is
context dependent and is outside the scope of this specification.
Specific applications of EATs will require implementations to
understand and process some claims in particular ways. However, in
the absence of such requirements, all claims that are not understood
by implementations MUST be ignored.
CDDL, along with a text description, is used to define each claim
independent of encoding. Each claim is defined as a CDDL group. In
Section 7 on encoding, the CDDL groups turn into CBOR map entries and
JSON name/value pairs.
Each claim defined in this document is added to the $$Claims-Set-
Claims group socket. Claims defined by other specifications MUST
also be added to the $$Claims-Set-Claims group socket.
All claims in an EAT MUST use the same encoding except where
otherwise explicitly stated (e.g., in a CBOR-encoded token, all
claims must be CBOR-encoded).
Lundblade, et al. Expires 18 July 2024 [Page 13]
Internet-Draft EAT January 2024
This specification includes a CDDL definition of most of what is
defined in [RFC8392]. Similarly, this specification includes CDDL
for most of what is defined in [RFC7519]. These definitions are in
Appendix D and are not normative.
Each claim described has a unique text string and integer that
identifies it. CBOR-encoded tokens MUST use only the integer for
claim keys. JSON-encoded tokens MUST use only the text string for
claim names.
4.1. eat_nonce (EAT Nonce) Claim
An EAT nonce is either a byte or text string or an array of byte or
text strings. The array option supports multistage EAT verification
and consumption.
A claim named "nonce" was defined and registered with IANA for JWT,
but MUST NOT be used because it does not support multiple nonces. No
previous "nonce" claim was defined for CWT. To distinguish from the
previously defined JWT "nonce" claim, this claim is named "eat_nonce"
in JSON-encoded EATs. The CWT nonce defined here is intended for
general purpose use and retains the "Nonce" claim name instead of an
EAT-specific name.
An EAT nonce MUST have at least 64 bits of entropy. A maximum EAT
nonce size is set to limit the memory required for an implementation.
All receivers MUST be able to accommodate the maximum size.
In CBOR, an EAT nonce is a byte string between 8 and 64 bytes in
length. In JSON, an EAT nonce is a text string between 8 and 88
bytes in length.
$$Claims-Set-Claims //=
(nonce-label => nonce-type / [ 2* nonce-type ])
nonce-type = JC< tstr .size (8..88), bstr .size (8..64)>
4.2. Claims Describing the Entity
The claims in this section describe the entity itself. They describe
the entity whether they occur in evidence or occur in attestation
results. See Section 1.3.1 for discussion on how attestation results
relate to evidence.
Lundblade, et al. Expires 18 July 2024 [Page 14]
Internet-Draft EAT January 2024
4.2.1. ueid (Universal Entity ID) Claim
The "ueid" claim conveys a UEID, which identifies an individual
manufactured entity like a mobile phone, a water meter, a Bluetooth
speaker or a networked security camera. It may identify the entire
entity or a submodule. It does not identify types, models or classes
of entities. It is akin to a serial number, though it does not have
to be sequential.
UEIDs MUST be universally and globally unique across manufacturers
and countries, as described in Section 4.2.1.1. UEIDs MUST also be
unique across protocols and systems, as tokens are intended to be
embedded in many different protocols and systems. No two products
anywhere, even in completely different industries made by two
different manufacturers in two different countries should have the
same UEID (if they are not global and universal in this way, then
relying parties receiving them will have to track other
characteristics of the entity to keep entities distinct between
manufacturers).
UEIDs are not designed for direct use by humans (e.g., printing on
the case of a device), so no such representation is defined.
There are privacy considerations for UEIDs. See Section 8.1.
A Device Identifier URN is registered for UEIDs. See Section 10.3.
$$Claims-Set-Claims //= (ueid-label => ueid-type)
ueid-type = JC<base64-url-text .size (10..44) , bstr .size (7..33)>
4.2.1.1. Rules for Creating UEIDs
These rules are solely for the creation of UEIDs. The EAT consumer
need not have any awareness of them.
A UEID is constructed of a single type byte followed by the unique
bytes for that type. The type byte assures global uniqueness of a
UEID even if the unique bytes for different types are accidentally
the same.
UEIDS are variable length to accommodate the types defined here and
future-defined types.
UEIDs SHOULD NOT be longer than 33 bytes. If they are longer, there
is no guarantee that a receiver will be able to accept them. See
Appendix B.
Lundblade, et al. Expires 18 July 2024 [Page 15]
Internet-Draft EAT January 2024
A UEID is permanent. It MUST never change for a given entity.
The different types of UEIDs 1) accommodate different manufacturing
processes, 2) accommodate small UEIDs, 3) provide an option that
doesn't require registration fees and central administration.
In the unlikely event that a new UEID type is needed, it MUST be
defined in a standards-track update to this document.
A manufacturer of entities MAY use different types for different
products. They MAY also change from one type to another for a given
product or use one type for some items of a given produce and another
type for other.
Lundblade, et al. Expires 18 July 2024 [Page 16]
Internet-Draft EAT January 2024
>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<EXPECTED_RESPONSE_TIME>
<REQUESTED_CONNECTIVITY_PROVISIONING_DOCUMENT>
[<INFORMATION_ELEMENT>...]
This message is sent by the CPNP client to update an existing service
agreement (e.g., connectivity provisioning agreement). The CPNP MUST
include the same CUSTOMER_AGREEMENT_IDENTIFIER,
PROVIDER_AGREEMENT_IDENTIFIER, and NONCE as those used when creating
the order. The CPNP client includes a new service description (e.g.,
updated CPD) which integrates the requested modifications. A new
Transaction_ID MUST be assigned by the client.
Upon receipt of an UPDATE message, the server checks whether an
order, having state "Completed", matches
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE.
Boucadair, et al. Expires September 7, 2020 [Page 39]
Internet-Draft CPNP March 2020
o If no order is found, the CPNP server generates a FAIL error with
the appropriate error code (Section 9.2.10).
o If an order is found, the server checks whether it can honor the
request:
* A FAIL message is sent to the client if the server cannot honor
the request. The client may initiate a new PQO negotiation
cycle (that is, a new UPDATE).
* An OFFER message including the updated clauses (e.g., updated
connectivity provisioning document) is sent to the client. For
example, the server maintains an order for provisioning a VPN
service that connects sites A, B, and C. If the client sends
an UPDATE message to remove site C, only sites A and B will be
included in the OFFER sent by the server to the requesting
client.
Note that the cycle that is triggered by an UPDATE message is
also considered as a negotiation cycle.
A flow chart that illustrates the use of UPDATE operation is shown in
Figure 15.
+------+ +------+
|Client| |Server|
+------+ +------+
|=========UPDATE(Requested CPD)======>|
|<============PROCESSING==============|
|<=========OFFER(Updated CPD)=========|
|=============PROCESSING=============>|
|==========ACCEPT(Updated CPD)=======>|
|<==========ACK(Updated CPD)==========|
| |
Figure 15: UPDATE Flow Example
9.2.10. FAIL
The format of the FAIL message is shown below:
<FAIL Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<STATUS_CODE>
This message is sent in the following cases:
Boucadair, et al. Expires September 7, 2020 [Page 40]
Internet-Draft CPNP March 2020
o The server cannot honor an order received from the client (i.e.,
received in a QUOTATION or UPDATE request).
o The server encounters an error when processing a CPNP request
received from the client.
o The client cannot grant more time to the server. This is a
response to a time extension request carried in a PROCESSING
message.
The status code indicates the error code. The following codes are
supported:
1 (Message Validation Error):
The message cannot be validated (see Section 10).
2 (Authentication Required):
The request cannot be handled because authentication is
required.
3 (Authorization Failed):
The request cannot be handled because authorization failed.
4 (Administratively prohibited):
The request cannot be handled because of administrative
policies.
5 (Out of Resources):
The request cannot be honored because resources (e.g., capacity)
are insufficient.
6 (Network Presence Error):
The request cannot be honored because there is no network
presence.
7 (More Time Rejected):
The request to extend the time for negotiation is rejected by
the client.
8 (Unsupported Activation Type):
The request cannot be handled because the requested activation
type is not supported.
9.2.11. ACTIVATE
The format of the ACTIVATE message is shown below:
<ACTIVATE Message> ::= <VERSION>
<METHOD_CODE>
<SEQUENCE_NUMBER>
<TRANSACTION_ID>
<CUSTOMER_AGREEMENT_IDENTIFIER>
<PROVIDER_AGREEMENT_IDENTIFIER>
<NONCE>
<ACTIVATION_SCHEDULE>
[<INFORMATION_ELEMENT>...]
Boucadair, et al. Expires September 7, 2020 [Page 41]
Internet-Draft CPNP March 2020
This message is sent by the CPNP client to request the activation of
an existing service agreement. The message MUST include the same
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE as those used when creating the order. The CPNP client may
includes a schedule target for activating this order. A new
Transaction_ID MUST be assigned by the client.
Upon receipt of an UPDATE message, the server checks whether an
order, having state "Completed", matches
CUSTOMER_AGREEMENT_IDENTIFIER, PROVIDER_AGREEMENT_IDENTIFIER, and
NONCE.
o If no completed order is found, the CPNP server generates a FAIL
error with the appropriate error code (Section 9.2.10).
o If an order is found, the server checks whether it can honor the
request:
* A FAIL message is sent to the client if the server cannot honor
the request (e.g., out of resources or explicit activation
wasn't negotiated with this client).
* An ACK is sent to the client to confirm that the immediate
activation (or de-activation) of the order or its successful
scheduling if a non-null ACTIVATION_SCHEDULE was included in
the request. Note that setting ACTIVATION_SCHEDULE to 0 in an
ACTIVATE request has a special meaning: it is used to request a
de-activation of an agreed order.
Figure 16 illustrates the use of ACTIVATE operation.
+------+ +------+
|Client| |Server|
+------+ +------+
|================ACTIVATE()==========>|
|<==============ACK()=================|
| |
Figure 16: ACTIVATE Flow Example
10. CPNP Message Validation
Both client and server proceed with CPNP message validation. The
following tables summarize the validation checks to be followed.
10.1. On the Client Side
Boucadair, et al. Expires September 7, 2020 [Page 42]
Internet-Draft CPNP March 2020
Operation Validation Checks
------------ --------------------------------------------------------
PROCESSING {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier} must match an
existing PQO with a state set to "PQOSent". The
sequence number carried in the packet must be larger
than the sequence number maintained by the
client.
OFFER {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier} must match an
existing order with state set to "PQOSent" or {Source
IP address, source port number, destination IP address,
destination port number, Transaction-ID,
Customer Order Identifier, Provider Order
Identifier} must match an existing order with a state
set to "ServerProcessing". The sequence number
carried in the packet must be larger than the
sequence number maintained by the client.
ACK {Source IP address, source port number, destination IP
(QUOTATION address, destination port number, Transaction-
Transaction) ID, Customer Order Identifier, Provider Order
Identifier, Offered Connectivity Provisioning Order}
must match an order with a state set to "AcceptSent".
The sequence number carried in the packet must
be larger than the sequence number maintained
by the client.
ACK (UPDATE {Source IP address, source port number, destination IP
Transaction) address, destination port number, Transaction-
ID, Customer Order Identifier, Provider Order
Identifier, Updated Connectivity Provisioning Order}
must match an order with a state set to "AcceptSent".
The sequence number carried in the packet must
be larger than the sequence number maintained
by the client.
ACK {Source IP address, source port number, destination IP
(WITHDRAW address, destination port number, Transaction-
Transaction) ID, Customer Order Identifier, Provider Order
Identifier, Empty Connectivity Provisioning Order}
must match an order with a state set to "Cancelled". The
sequence number carried in the packet must be
larger than the sequence number maintained by
the client.
Boucadair, et al. Expires September 7, 2020 [Page 43]
Internet-Draft CPNP March 2020
10.2. On the Server Side
Method Validation Checks
---------- ----------------------------------------------------------
QUOTATION The source IP address passes existing access filters (if
any). The sequence number carried in the packet
must not be lower than the sequence number
maintained by the server.
PROCESSING The sequence number carried in the packet must be greater
than the sequence number maintained by the
server.
CANCEL {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier} must match an
order with state set to "PQOReceived" or
"OfferProposed" or "ProcessingReceived" or "AcceptReceived
". The sequence number carried in the packet
must be greater than the sequence number
maintained by the server.
ACCEPT {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier, Provider Order
Identifier, Nonce, Offered Connectivity Provisioning
Order} must match an order with state set to
"OfferProposed" or "ProcessingReceived". The
sequence number carried in the packet must be
greater than the sequence number maintained by the server.
FAIL {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier, Provider Order
Identifier} must match an order with state set to
"AwaitingProcessing" and for which a request to grant more
time to process an offer was requested. The
sequence number carried in the packet must be
greater than the sequence number maintained by the
server.
DECLINE {Source IP address, source port number, destination IP
address, destination port number, Transaction-
ID, Customer Order Identifier, Provider Order
Identifier, Nonce} must match an order with state set
to "OfferProposed" or "ProcessingReceived". The sequence
number carried in the packet must be greater
than the sequence number maintained by the
server.
UPDATE The source IP address passes existing access filters (if
any) and {Customer Order Identifier, Provider
Order Identifier, Nonce} must match an existing
order with state "Completed".
Boucadair, et al. Expires September 7, 2020 [Page 44]
Internet-Draft CPNP March 2020
WITHDRAW The source IP address passes existing access filters (if
any) and {Customer Order Identifier, Provider
Order Identifier, Nonce} must match an existing
order with state "Completed".
ACTIVATE The source IP address passes existing access filters (if
any) and {Customer Order Identifier, Provider
Order Identifier, Nonce} must match an existing
order with state "Completed" for which the
activation procedure is tagged to be explicit.
11. Theory of Operation
Both CPNP client and server proceed with message validation checks as
specified in Section 10.
11.1. Client Behavior
11.1.1. Order Negotiation Cycle
To place a provisioning quotation order, the client first initiates a
local quotation order object identified by a unique identifier
assigned by the client (Client Order Identifier). The state of the
quotation order is set to "Created". The client then generates a
QUOTATION request which includes the assigned identifier, possibly an
expected response time, a Transaction-ID, and a Requested Service
(e.g., Requested Connectivity Provisioning Document). The client may
include additional Information Elements such as Negotiation Options
or Activation Type.
The client may be configured to not enforce negotiation checks on
EXPECTED_OFFER_TIME; if so, no EXPECTED_RESPONSE_TIME attribute (or
EXPECTED_RESPONSE_TIME set to infinite) should be included in the
quotation order.
Once the request is sent to the server, the state of the request is
set to "PQOSent" and a timer, if a response time is included in the
quotation order, is set to the expiration time as included in the
QUOTATION request. The client also maintains a copy of the CPNP
session entry details used to generate the QUOTATION request. The
CPNP client must listen on the same port number that it used to send
the QUOTATION request.
If no answer is received from the server before the retransmission
timer expires (i.e., RETRANS_TIMER, Section 8.5), the client
retransmits the message until maximum retry is reached (e.g., 3
times). The same sequence number is used for retransmitted packets.
Boucadair, et al. Expires September 7, 2020 [Page 45]
Internet-Draft CPNP March 2020
If a FAIL message is received, the client may decide to issue another
(corrected) request towards the same server, cancel the local order,
or contact another server. The behavior of the client depends on the
error code returned by the server in the FAIL message.
If a PROCESSING message matching the CPNP session entry (Section 8.3)
is received, the client updates the CPNP session entry with the
PROVIDER_AGREEMENT_IDENTIFIER information. If the client does not
accept the expected offer time that may have been indicated in the
PROCESSING message, the client may decide to cancel the quotation
order. If the client accepts the EXPECTED_OFFER_TIME, it changes the
state of the order to "ServerProcessing" and sets a timer to the
value of EXPECTED_OFFER_TIME. If no offer is made before the timer
expires, the client changes the state of the order to "Cancelled".
As a response to a time extension request (conveyed in a PROCESSING
message that included a new EXPECTED_OFFER_TIME), the client may
grant this extension by issuing an ACK message or reject the time
extension with a FAIL message having a status code set to "More Time
Rejected".
If an OFFER message matching the CPNP session entry is received, the
client checks if a PROCESSING message having the same
PROVIDER_AGREEMENT_IDENTIFIER has been received from the server. If
a PROCESSING message was already received for the same order but the
PROVIDER_AGREEMENT_IDENTIFIER does not match the identifier included
in the OFFER message, the client silently ignores the message. If a
PROCESSING message having the same PROVIDER_AGREEMENT_IDENTIFIER was
already received and matches the CPNP transaction identifier, the
client changes the state of the order to "OfferReceived" and sets a
timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER
message.
If an offer is received from the server (i.e., as documented in an
OFFER message), the client may accept or reject the offer. The
client accepts the offer by generating an ACCEPT message which
confirms that the client agrees to subscribe to the offer documented
in the OFFER message; the state of the order is passed to
"AcceptSent". The transaction is terminated if an ACK message is
received from the server. If no ACK is received from the server, the
client proceeds with the retransmission of the ACCEPT message until
the maximum retry is reached (Section 11.4).
The client may also decide to reject the offer by sending a DECLINE
message. The state of the order is set by the client to "Cancelled".
If an offer is not acceptable by the client, the client may decide to
contact a new server or submit another order to the same server.
Boucadair, et al. Expires September 7, 2020 [Page 46]
Internet-Draft CPNP March 2020
Guidelines to issue an updated order or terminate the negotiation are
specific to the client.
An order can be activated (or de-activated) using the ACTIVATE
message or other agreed activation means (Section 3.11 of [RFC7297]).
11.1.2. Order Withdrawal Cycle
A client may withdraw a completed order. This is achieved by issuing
a WITHDRAW message. This message MUST include Customer Order
Identifier, Provider Identifier, and Nonce returned during the order
negotiation cycle, as specified in Section 11.1.1.
If no ACK is received from the server, the client proceeds with the
retransmission of the message. If no ACK is received after the
maximum retry is exhausted, the client should log the information and
must send an alarm to the administrator. If there is no specific
instruction from the administrator, the client SHOULD schedule
another Withdrawal cycle. The client MUST NOT retry this Withdrawal
cycle more frequently than every 300 seconds and MUST NOT retry more
frequently than every 60 seconds.
11.1.3. Order Update Cycle
A client may update a completed order. This is achieved by issuing
an UPDATE message. This message MUST include Customer Order
Identifier, Provider Order Identifier and Nonce returned during the
order negotiation cycle specified in Section 11.1.1. The client MUST
include in the UPDATE message an updated CPD with the requested
changes.
Subsequent messages exchange is similar to what is documented in
Section 11.1.1.
11.2. Server Behavior
11.2.1. Order Processing
Upon receipt of a QUOTATION message from a client, the server sets a
CPNP session, stores Transaction-ID and generates a Provider Order
Identifier. Once preliminary validation checks are completed (
Section 10), the server may return a PROCESSING message to inform the
client that the quotation order is received and it is under
processing; the server may include an expected offer time to notify
the client by when an offer will be proposed. An order with state
"AwaitingProcessing" is created by the server. The server runs its
decision-making process to decide which offer it can make to honor
Boucadair, et al. Expires September 7, 2020 [Page 47]
Internet-Draft CPNP March 2020
the received order. The offer should be made before the expected
offer time expires.
If the server cannot make an offer, it sends backs a FAIL message
with the appropriate error code.
If the server requires more negotiation time, it must send a
PROCESSING message with a new EXPECTED_OFFER_TIME. The client may
grant this extension by issuing an ACK message or reject the time
extension with a FAIL message having a status code set to "More Time
Rejected". If the client doesn't grant more time, the server must
answer before the initial expected offer time; otherwise the client
will decline the quotation order.
If the server can honor the request or it can make an offer that
meets only some of the requirements, it creates an OFFER message.
The server must indicate the Transaction-ID, Customer Order
Identifier as indicated in the QUOTATION message, and the Provider
Order Identifier generated for this order. The server must also
include Nonce and the offered service document (e.g., offered
Connectivity Provisioning Document). The server includes an offer
validity time as well. Once sent to the client, the server changes
the state of the order to "OfferProposed" and a timer set to the
validity time is initiated.
If the server determines that additional network resources from
another network provider are needed to accommodate a quotation order,
it will create child PQO(s) and will behave as a CPNP client to
negotiate child PQO(s) with possible partnering providers (see
Figure 7).
If no PROCESSING, ACCEPT, or DECLINE message is received before the
expiry of the RETRANS_TIMER, the server re-sends the same offer to
the client. This procedure is repeated until maximum retry is
reached.
If an ACCEPT message is received before the offered validity time
expires, the server proceeds with validation checks as specified in
Section 10. The state of the corresponding order is passed to
"AcceptReceived". The server sends back an ACK message to terminate
the order processing cycle.
If a CANCEL/DECLINE message is received, the server proceeds with the
cancellation of the order. The state of the order is then passed to
"Cancelled".
Boucadair, et al. Expires September 7, 2020 [Page 48]
Internet-Draft CPNP March 2020
11.2.2. Order Withdrawal
A client may withdraw a completed order by issuing a WITHDRAW
message. Upon receipt of a WITHDRAW message, the server proceeds
with the validation checks, as specified in Section 10:
o If the checks fail, a FAIL message is sent back to the client with
the appropriate error code (e.g., 1 (Message Validation Error), 2
(Authentication Required), or 3 (Authorization Failed)).
o If the checks succeed, the server clears the clauses of the
Connectivity Provisioning Document, changes the state of the order
to "Cancelled", and sends back an ACK message with an Empty
Connectivity Provisioning Document.
11.2.3. Order Update
A client may update an order by issuing an UPDATE message. Upon
receipt of an UPDATE message, the server proceeds with the validation
checks as specified in Section 10:
o If the checks fail, a FAIL message is sent back to the client with
the appropriate error code (e.g., 1 (Message Validation Error), 2
(Authentication Required), 3 (Authorization Failed), or 6 (Network
Presence Error)).
o The exchange of subsequent messages is similar to what is
specified in Section 11.1.1. The server should generate a new
Nonce value to be included in the offer made to the client.
11.3. Sequence Numbers
In each transaction, sequence numbers are used to protect the
transaction against replay attacks. Each communicating partner of
the transaction maintains two sequence numbers, one for incoming
packets and one for outgoing packets. When a partner receives a
message, it will check whether the sequence number in the message is
larger than the incoming sequence number maintained locally. If not,
the message will be discarded. If the message is proved to be
legitimate, the value of the incoming sequence number maintained
locally will be replaced by the value of the sequence number in the
message. When a partner sends out a message, it will insert the
value of the outgoing sequence number into the message and increase
the outgoing sequence number maintained locally by 1.
Boucadair, et al. Expires September 7, 2020 [Page 49]
Internet-Draft CPNP March 2020
11.4. Message Re-Transmission
If a transaction partner sends out a message and does not receive any
expected reply before the retransmission timer expires (i.e.,
RETRANS_TIMER), a transaction partner will try to re-transmit the
message. The procedure is reiterated until a maximum retry is
reached (e.g., 3 times). An exception is the last message (e.g.,
ACK) sent from the server in a transaction. After sending this
message, the retransmission timer will be disabled since no
additional feedback is expected.
In addition, if the partner receives a retransmission of a last
incoming packet it handled, the partner can re-send the same answer
to the incoming packet with a limited frequency. If no answer was
generated at the moment, the partner needs to generate a PROCESSING
message as the answer.
To optimize message retransmission, a partner could also store the
last incoming packet and the associated answer. Note that the times
of retransmission could be decided by the local policy and
retransmission will not cause any change of sequence numbers.
12. Some Operational Guidelines
12.1. Logging on the CPNP Server
The CPNP server should be configurable to log various events and
associated information. Such information may include:
o Client's IP address
o Any event change (e.g., new quotation order, offer sent, order
confirm, order cancellation, order withdraw, etc.)
o Timestamp
12.2. Business Guidelines and Objectives
The CPNP server can operate in the following modes:
1. Fully automated mode:
The CPNP server is provisioned with a set of business guidelines
and objectives that will be used as an input to the decision-
making process. The CPNP server will service received orders
that fall into these business guidelines; otherwise, requests
will be escalated to an administrator that will formally
validate/invalidate an order request. The set of policies to be
configured to the CPNP server are specific to each administrative
entity managing a CPNP server.
Boucadair, et al. Expires September 7, 2020 [Page 50]
Internet-Draft CPNP March 2020
2. Administrative-based mode:
This mode assumes some or all CPNP server&+======+======+=====================================================+
| Type | Type | Specification |
| Byte | Name | |
+======+======+=====================================================+
| 0x01 | RAND | This is a 128, 192 or 256-bit random number |
| | | generated once and stored in the entity. This |
| | | may be constructed by concatenating enough |
| | | identifiers to make up an equivalent number of |
| | | random bits and then feeding the concatenation |
| | | through a cryptographic hash function. It may |
| | | also be a cryptographic quality random number |
| | | generated once at the beginning of the life of |
| | | the entity and stored. It MUST NOT be smaller |
| | | than 128 bits. See the length analysis in |
| | | Appendix B. |
+------+------+-----------------------------------------------------+
| 0x02 | IEEE | This makes use of the device identification |
| | EUI | scheme operated by the IEEE. An EUI is either |
| | | an EUI-48, EUI-60 or EUI-64 and made up of an |
| | | OUI, OUI-36 or a CID, different registered |
| | | company identifiers, and some unique per-entity |
| | | identifier. EUIs are often the same as or |
| | | similar to MAC addresses. This type includes |
| | | MAC-48, an obsolete name for EUI-48. (Note that |
| | | while entities with multiple network interfaces |
| | | may have multiple MAC addresses, there is only |
| | | one UEID for an entity; changeable MAC addresses |
| | | that don't meet the permanence requirements in |
| | | this document MUST NOT be used for the UEID or |
| | | SUEID) [IEEE.802-2001], [OUI.Guide]. |
+------+------+-----------------------------------------------------+
| 0x03 | IMEI | This makes use of the International Mobile |
| | | Equipment Identity (IMEI) scheme operated by the |
| | | GSMA. This is a 14-digit identifier consisting |
| | | of an 8-digit Type Allocation Code (TAC) and a |
| | | 6-digit serial number allocated by the |
| | | manufacturer, which SHALL be encoded as byte |
| | | string of length 14 with each byte as the |
| | | digit's value (not the ASCII encoding of the |
| | | digit; the digit 3 encodes as 0x03, not 0x33). |
| | | The IMEI value encoded SHALL NOT include Luhn |
| | | checksum or SVN information. See |
| | | [ThreeGPP.IMEI]. |
+------+------+-----------------------------------------------------+
Table 1: UEID Composition Types
Lundblade, et al. Expires 18 July 2024 [Page 17]
Internet-Draft EAT January 2024
4.2.1.2. Rules for Consuming UEIDs
For the consumer, a UEID is solely a globally unique opaque
identifier. The consumer does not and should not have any awareness
of the rules and structure used to achieve global uniqueness.
All implementations MUST be able to receive UEIDs up to 33 bytes
long. 33 bytes is the longest defined in this document and gives
necessary entropy for probabilistic uniqueness.
The consumer of a UEID MUST treat it as a completely opaque string of
bytes and MUST NOT make any use of its internal structure. The
reasons for this are:
* UEIDs types vary freely from one manufacturer to the next.
* New types of UEIDs may be defined.
* The manufacturer of an entity is allowed to change from one type
of UEID to another anytime they want.
For example, when the consumer receives a type 0x02 UEID, they should
not use the OUI part to identify the manufacturer of the device
because there is no guarantee all UEIDs will be type 0x02. Different
manufacturers may use different types. A manufacturer may make some
of their product with one type and others with a different type or
even change to a different type for newer versions of their product.
Instead, the consumer should use the "oemid" claim.
4.2.2. sueids (Semi-permanent UEIDs) Claim (SUEIDs)
The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs).
An SUEID has the same format, characteristics and requirements as a
UEID, but MAY change to a different value on entity life-cycle
events. An entity MAY have both a UEID and SUEIDs, neither, one or
the other.
Examples of life-cycle events are change of ownership, factory reset
and on-boarding into an IoT device management system. It is beyond
the scope of this document to specify particular types of SUEIDs and
the life-cycle events that trigger their change. An EAT profile MAY
provide this specification.
Lundblade, et al. Expires 18 July 2024 [Page 18]
Internet-Draft EAT January 2024
There MAY be multiple SUEIDs. Each has a text string label the
purpose of which is to distinguish it from others. The label MAY
name the purpose, application or type of the SUEID. For example, the
label for the SUEID used by XYZ Onboarding Protocol could thus be
"XYZ". It is beyond the scope of this document to specify any SUEID
labeling schemes. They are use case specific and MAY be specified in
an EAT profile.
If there is only one SUEID, the claim remains a map and there still
MUST be a label.
An SUEID provides functionality similar to an IEEE LDevID
[IEEE.802.1AR].
There are privacy considerations for SUEIDs. See Section 8.1.
A Device Identifier URN is registered for SUEIDs. See Section 10.3.
$$Claims-Set-Claims //= (sueids-label => sueids-type)
sueids-type = {
+ tstr => ueid-type
}
4.2.3. oemid (Hardware OEM Identification) Claim
The "oemid" claim identifies the Original Equipment Manufacturer
(OEM) of the hardware. Any of the three forms described below MAY be
used at the convenience of the claim sender. The receiver of this
claim MUST be able to handle all three forms.
Note that the "hwmodel" claim in Section 4.2.4, the "oemboot" claim
in Section 4.2.8 and "dbgstat" claim in Section 4.2.9 depend on this
claim.
Sometimes one manufacturer will acquire or merge with another.
Depending on the situation and use case newly manfactured devices may
continue to use the old OEM ID or switch to a new one. This is left
to the discretion of the manufacturers, but they should consider how
it affects the above-mentioned claims and the attestation eco-system
for their devices. The considerations are the same for all three
forms of this claim.
4.2.3.1. Random Number Based OEM ID
The random number based OEM ID MUST always be 16 bytes (128 bits)
long.
Lundblade, et al. Expires 18 July 2024 [Page 19]
Internet-Draft EAT January 2024
The OEM may create their own ID by using a cryptographic-quality
random number generator. They would perform this only once in the
life of the company to generate the single ID for said company. They
would use that same ID in every entity they make. This uniquely
identifies the OEM on a statistical basis and is large enough should
there be ten billion companies.
In JSON-encoded tokens this MUST be base64url-encoded.
4.2.3.2. IEEE Based OEM ID
The IEEE operates a global registry for MAC addresses and company
IDs. This claim uses that database to identify OEMs. The contents
of the claim may be either an IEEE MA-L, MA-M, MA-S or an IEEE CID
[IEEE-RA]. An MA-L, formerly known as an OUI, is a 24-bit value used
as the first half of a MAC address. MA-M similarly is a 28-bit value
uses as the first part of a MAC address, and MA-S, formerly known as
OUI-36, a 36-bit value. Many companies already have purchased one of
these. A CID is also a 24-bit value from the same space as an MA-L,
but not for use as a MAC address. IEEE has published Guidelines for
Use of EUI, OUI, and CID [OUI.Guide] and provides a lookup service
[OUI.Lookup].
Companies that have more than one of these IDs or MAC address blocks
SHOULD select one and prefer that for all their entities.
Commonly, these are expressed in Hexadecimal Representation as
described in [IEEE.802-2001]. It is also called the Canonical
format. When this claim is encoded the order of bytes in the bstr
are the same as the order in the Hexadecimal Representation. For
example, an MA-L like "AC-DE-48" would be encoded in 3 bytes with
values 0xAC, 0xDE, 0x48.
This format is always 3 bytes in size in CBOR.
In JSON-encoded tokens, this MUST be base64url-encoded and always 4
bytes.
4.2.3.3. IANA Private Enterprise Number Based OEM ID
IANA maintains a registry for Private Enterprise Numbers (PEN) [PEN].
A PEN is an integer that identifies an enterprise and may be used to
construct an object identifier (OID) relative to the following OID
arc that is managed by IANA: iso(1) identified-organization(3) dod(6)
internet(1) private(4) enterprise(1).
For EAT purposes, only the integer value assigned by IANA as the PEN
is relevant, not the full OID value.
Lundblade, et al. Expires 18 July 2024 [Page 20]
Internet-Draft EAT January 2024
In CBOR this value MUST be encoded as a major type 0 integer and is
typically 3 bytes. In JSON, this value MUST be encoded as a number.
$$Claims-Set-Claims //= (
oemid-label => oemid-pen / oemid-ieee / oemid-random
)
oemid-pen = int
oemid-ieee = JC<oemid-ieee-json, oemid-ieee-cbor>
oemid-ieee-cbor = bstr .size 3
oemid-ieee-json = base64-url-text .size 4
oemid-random = JC<oemid-random-json, oemid-random-cbor>
oemid-random-cbor = bstr .size 16
oemid-random-json = base64-url-text .size 24
4.2.4. hwmodel (Hardware Model) Claim
The "hwmodel" claim differentiates hardware models, products and
variants manufactured by a particular OEM, the one identified by OEM
ID in Section 4.2.3. It MUST be unique within a given OEM ID. The
concatenation of the OEM ID and "hwmodel" give a global identifier of
a particular product. The "hwmodel" claim MUST only be present if an
"oemid" claim described in Section 4.2.3 is present.
The granularity of the model identification is for each OEM to
decide. It may be very granular, perhaps including some version
information. It may be very general, perhaps only indicating top-
level products.
The "hwmodel" claim is for use in protocols and not for human
consumption. The format and encoding of this claim should not be
human-readable to discourage use other than in protocols. If this
claim is to be derived from an already-in-use human-readable
identifier, it can be run through a hash function.
There is no minimum length so that an OEM with a very small number of
models can use a one-byte encoding. The maximum length is 32 bytes.
All receivers of this claim MUST be able to receive this maximum
size.
The receiver of this claim MUST treat it as a completely opaque
string of bytes, even if there is some apparent naming or structure.
The OEM is free to alter the internal structure of these bytes as
long as the claim continues to uniquely identify its models.
Lundblade, et al. Expires 18 July 2024 [Page 21]
Internet-Draft EAT January 2024
$$Claims-Set-Claims //= (
hardware-model-label => hardware-model-type
)
hardware-model-type = JC<base64-url-text .size (4..44),
bytes .size (1..32)>
4.2.5. hwversion (Hardware Version) Claim
The "hwversion" claim is a text string the format of which is set by
each manufacturer. The structure and sorting order of this text
string can be specified using the version-scheme item from CoSWID
[RFC9393]. It is useful to know how to sort versions so the newer
can be distinguished from the older. A "hwversion" claim MUST only
be present if a "hwmodel" claim described in Section 4.2.4 is
present.
$$Claims-Set-Claims //= (
hardware-version-label => hardware-version-type
)
hardware-version-type = [
version: tstr,
? scheme: $version-scheme
]
4.2.6. swname (Software Name) Claim
The "swname" claim contains a very simple free-form text value for
naming the software used by the entity. Intentionally, no general
rules or structure are set. This will make it unsuitable for use
cases that wish precise naming.
If precise and rigourous naming of the software for the entity is
needed, the "manifests" claim described in Section 4.2.15 may be used
instead.
$$Claims-Set-Claims //= ( sw-name-label => tstr )
4.2.7. swversion (Software Version) Claim
The "swversion" claim makes use of the CoSWID version-scheme defined
in [RFC9393] to give a simple version for the software. A
"swversion" claim MUST only be present if a "swname" claim described
in Section 4.2.6 is present.
The "manifests" claim Section 4.2.15 may be instead if this is too
simple.
Lundblade, et al. Expires 18 July 2024 [Page 22]
Internet-Draft EAT January 2024
$$Claims-Set-Claims //= (sw-version-label => sw-version-type)
sw-version-type = [
version: tstr
? scheme: $version-scheme
]
4.2.8. oemboot (OEM Authorized Boot) Claim
An "oemboot" claim with value of true indicates the entity booted
with software authorized by the manufacturer of the entity as
indicated by the "oemid" claim described in Section 4.2.3. It
indicates the firmware and operating system are fully under control
of the OEM and may not be replaced by the end user or even the
enterprise that owns the device. The means of control may be by
cryptographic authentication of the software, by the software being
in Read-Only Memory (ROM), a combination of the two or other. If
this claim is present the "oemid" claim MUST be present.
$$Claims-Set-Claims //= (oem-boot-label => bool)
4.2.9. dbgstat (Debug Status) Claim
The "dbgstat" claim applies to entity-wide or submodule-wide debug
facilities of the entity like [JTAG] and diagnostic hardware built
into chips. It applies to any software debug facilities related to
privileged software that allows system-wide memory inspection,
tracing or modification of non-system software like user mode
applications.
This characterization assumes that debug facilities can be enabled
and disabled in a dynamic way or be disabled in some permanent way,
such that no enabling is possible. An example of dynamic enabling is
one where some authentication is required to enable debugging. An
example of permanent disabling is blowing a hardware fuse in a chip.
The specific type of the mechanism is not taken into account. For
example, it does not matter if authentication is by a global password
or by per-entity public keys.
As with all claims, the absence of the "dbgstat#x27; operations are subject
to a formal administrative validation. CPNP events will trigger
appropriate validation requests that will be forwarded to the
contact person(s) or department which is responsible for
validating the orders. Administrative validation messages are
relayed using another protocol (e.g., SMTP) or a dedicated tool.
Business guidelines are local to each administrative entity. How
validation requests are presented to an administrator are out of
scope of this document; each administrative entity may decide the
appropriate mechanism to enable for that purpose.
13. Security Considerations
Means to defend the server against denial-of-service attacks must be
enabled. For example, access control lists (ACLs) can be enforced on
the client, the server or the network in between, to allow a trusted
client to communicate with a trusted server.
The client and the server MUST be mutually authenticated.
Authenticated encryption MUST be used for data confidentiality and
message integrity.
The protocol does not provide security mechanisms to protect the
confidentiality and integrity of the packets transported between the
client and the server. An underlying security protocol such as
(e.g., Datagram Transport Layer Security (DTLS) [RFC6347], Transport
Layer Security (TLS) [RFC8446]) MUST be used to protect the integrity
and confidentiality of protocol messages. In this case, if it is
possible to provide an Automated Key Management (AKM) and associate
each transaction with a different key, inter-transaction replay
attacks can naturally be addressed. If the client and the server use
a single key, an additional mechanism should be provided to protect
inter-transaction replay attacks between them. Clients MUST
implement DTLS record replay detection (Section 3.3 of [RFC6347]) or
an equivalent mechanism to protect against replay attacks.
DTLS and TLS with a cipher suite offering confidentiality protection
and the guidance given in [RFC7525] MUST be followed to avoid attacks
on (D)TLS.
The client MUST silently discard CPNP responses received from unknown
CPNP servers. The use of a randomly generated Transaction-ID makes
it hard to forge a response from a server with a spoofed IP address
belonging to a legitimate CPNP server. Furthermore, CPNP demands
that messages from the server must include the correct identifiers of
Boucadair, et al. Expires September 7, 2020 [Page 51]
Internet-Draft CPNP March 2020
the orders. Two order identifiers are used: one generated by the
client and a second one generated by the server.
The Provider MUST enforce means to protect privacy-related
information included the documents (see Section 8.7) exchanged in
CPNP messages [RFC6462]. In particular, this information MUST NOT be
revealed to external parties without the consent of Customers.
Providers should enforce policies to make Customer fingerprinting
difficult to achieve. For more discussion about privacy, refer to
[RFC6462][RFC6973].
The Nonce and the Transaction ID attributes provide sufficient
randomness and can effectively tolerate attacks raised by off-line
adversaries, who do not have the capability of eavesdropping and
intercepting the packets transported between the client and the
server. Only authorized clients must be able to modify agreed CPNP
orders. The use of a randomly generated Nonce by the server makes it
hard to modify an agreement on behalf of a malicious third-party.
14. IANA Considerations
This document does not request any IANA action.
15. Acknowledgements
Thanks to Diego R. Lopez and Adrian Farrel for the comments.
Thanks to the ISE reviewers.
Special thanks to Luis Miguel Contreras Murillo for the detailed
review.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
Boucadair, et al. Expires September 7, 2020 [Page 52]
Internet-Draft CPNP March 2020
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP
Connectivity Provisioning Profile (CPP)", RFC 7297,
DOI 10.17487/RFC7297, July 2014,
<https://www.rfc-editor.org/info/rfc7297>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
16.2. Informative References
[AGAVE] Boucadair, M., Georgatsos, P., Wang, N., Griffin, D.,
Pavlou, G., Howarth, M., and A. Elizondo, "The AGAVE
Approach for Network Virtualization: Differentiated
Services Delivery", April 2009,
<https://rd.springer.com/article/10.1007/
s12243-009-0103-4>.
[ETICS] EU FP7 ETICS Project, "Economics and Technologies of
Inter-Carrier Services", January 2014, <https://www.ict-
etics.eu/fileadmin/documents/news/
ETICS_white_paper_final.pdf>.
Boucadair, et al. Expires September 7, 2020 [Page 53]
Internet-Draft CPNP March 2020
[I-D.boucadair-lisp-idr-ms-discovery]
Boucadair, M. and C. Jacquenet, "LISP Mapping Service
Discovery at Large", draft-boucadair-lisp-idr-ms-
discovery-01 (work in progress), March 2016.
[I-D.contreras-teas-slice-nbi]
Contreras, L., Homma, S., and J. Ordonez-Lucena,
"Considerations for defining a Transport Slice NBI",
draft-contreras-teas-slice-nbi-00 (work in progress),
November 2019.
[I-D.geng-netslices-architecture]
67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com,
k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing
Architecture", draft-geng-netslices-architecture-02 (work
in progress), July 2017.
[I-D.ietf-opsawg-l3sm-l3nm]
Aguado, A., Dios, O., Lopezalvarez, V., Voyer, D., and L.
Munoz, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-01 (work in progress), November 2019.
[I-D.itsumo-dsnp]
Chen, J., "Dynamic Service Negotiation Protocol (DSNP)",
draft-itsumo-dsnp-03 (work in progress), March 2006.
[I-D.nguyen-rap-cops-sls]
Nguyen, T., "COPS Usage for SLS negotiation (COPS-SLS)",
draft-nguyen-rap-cops-sls-03 (work in progress), July
2002.
[Karl] Czajkowski, K., Foster, I., Kesselman, C., Sander, V., and
S. Tuecke, "SNAP: A Protocol for Negotiating Service Level
Agreements and Coordinating Resource Management in
Distributed Systems",
<http://citeseerx.ist.psu.edu/viewdoc/
summary?doi=10.1.1.19.5907>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, DOI 10.17487/RFC3084, March 2001,
<https://www.rfc-editor.org/info/rfc3084>.
Boucadair, et al. Expires September 7, 2020 [Page 54]
Internet-Draft CPNP March 2020
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176,
DOI 10.17487/RFC4176, October 2005,
<https://www.rfc-editor.org/info/rfc4176>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop",
RFC 6462, DOI 10.17487/RFC6462, January 2012,
<https://www.rfc-editor.org/info/rfc6462>.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012,
<https://www.rfc-editor.org/info/rfc6574>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <https://www.rfc-editor.org/info/rfc6770>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012,
<https://www.rfc-editor.org/info/rfc6793>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
Boucadair, et al. Expires September 7, 2020 [Page 55]
Internet-Draft CPNP March 2020
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
Networking: A Perspective from within a Service Provider
Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
<https://www.rfc-editor.org/info/rfc7149>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309&" claim means it is
not reported.
This claim is not extensible so as to provide a common interoperable
description of debug status. If a particular implementation
considers this claim to be inadequate, it can define its own
proprietary claim. It may consider including both this claim as a
coarse indication of debug status and its own proprietary claim as a
refined indication.
Lundblade, et al. Expires 18 July 2024 [Page 23]
Internet-Draft EAT January 2024
The higher levels of debug disabling requires that all debug
disabling of the levels below it be in effect. Since the lowest
level requires that all of the target's debug be currently disabled,
all other levels require that too.
There is no inheritance of claims from a submodule to a superior
module or vice versa. There is no assumption, requirement or
guarantee that the target of a superior module encompasses the
targets of submodules. Thus, every submodule must explicitly
describe its own debug state. The receiver of an EAT MUST NOT assume
that debug is turned off in a submodule because there is a claim
indicating it is turned off in a superior module.
An entity may have multiple debug facilities. The use of plural in
the description of the states refers to that, not to any aggregation
or inheritance.
The architecture of some chips or devices may be such that a debug
facility operates for the whole chip or device. If the EAT for such
a chip includes submodules, then each submodule should independently
report the status of the whole-chip or whole-device debug facility.
This is the only way the receiver can know the debug status of the
submodules since there is no inheritance.
4.2.9.1. Enabled
If any debug facility, even manufacturer hardware diagnostics, is
currently enabled, then this level must be indicated.
4.2.9.2. Disabled
This level indicates all debug facilities are currently disabled. It
may be possible to enable them in the future. It may also be that
they were enabled in the past, but they are currently disabled.
4.2.9.3. Disabled Since Boot
This level indicates all debug facilities are currently disabled and
have been so since the entity booted/started.
4.2.9.4. Disabled Permanently
This level indicates all non-manufacturer facilities are permanently
disabled such that no end user or developer can enable them. Only
the manufacturer indicated in the "oemid" claim can enable them.
This also indicates that all debug facilities are currently disabled
and have been so since boot/start. If this debug state is reported,
the "oemid" claim MUST be present.
Lundblade, et al. Expires 18 July 2024 [Page 24]
Internet-Draft EAT January 2024
4.2.9.5. Disabled Fully and Permanently
This level indicates that all debug facilities for the entity are
permanently disabled.
$$Claims-Set-Claims //= ( debug-status-label => debug-status-type )
debug-status-type = ds-enabled /
disabled /
disabled-since-boot /
disabled-permanently /
disabled-fully-and-permanently
ds-enabled = JC< "enabled", 0 >
disabled = JC< "disabled", 1 >
disabled-since-boot = JC< "disabled-since-boot", 2 >
disabled-permanently = JC< "disabled-permanently", 3 >
disabled-fully-and-permanently =
JC< "disabled-fully-and-permanently", 4 >
4.2.10. location (Location) Claim
The "location" claim gives the geographic position of the entity from
which the attestation originates. Latitude, longitude, altitude,
accuracy, altitude-accuracy, heading and speed MUST be as defined in
the W3C Geolocation API [W3C.GeoLoc] (which, in turn, is based on
[WGS84]). If the entity is stationary, the heading is NaN (floating-
point not-a-number). Latitude and longitude MUST always be provided.
If any other of these values are unknown, they are omitted.
The location may have been cached for a period of time before token
creation. For example, it might have been minutes or hours or more
since the last contact with a GNSS satellite. Either the timestamp
or age data item can be used to quantify the cached period. The
timestamp data item is preferred as it a non-relative time. If the
entity has no clock or the clock is unset but has a means to measure
the time interval between the acquisition of the location and the
token creation the age may be reported instead. The age is in
seconds.
See location-related privacy considerations in Section 8.2.
Lundblade, et al. Expires 18 July 2024 [Page 25]
Internet-Draft EAT January 2024
$$Claims-Set-Claims //= (location-label => location-type)
location-type = {
latitude => number,
longitude => number,
? altitude => number,
? accuracy => number,
? altitude-accuracy => number,
? heading => number,
? speed => number,
? timestamp => ~time-int,
? age => uint
}
latitude = JC< "latitude", 1 >
longitude = JC< "longitude", 2 >
altitude = JC< "altitude", 3 >
accuracy = JC< "accuracy", 4 >
altitude-accuracy = JC< "altitude-accuracy", 5 >
heading = JC< "heading", 6 >
speed = JC< "speed", 7 >
timestamp = JC< "timestamp", 8 >
age = JC< "age", 9 >
4.2.11. uptime (Uptime) Claim
The "uptime" claim contains the number of seconds that have elapsed
since the entity or submodule was last booted.
$$Claims-Set-Claims //= (uptime-label => uint)
4.2.12. bootcount (Boot Count) Claim
The "bootcount" claim contains a count of the number times the entity
or submodule has been booted. Support for this claim requires a
persistent storage on the device.
$$Claims-Set-Claims //= (boot-count-label => uint)
4.2.13. bootseed (Boot Seed) Claim
The "bootseed" claim contains a value created at system boot time
that allows differentiation of attestation reports from different
boot sessions of a particular entity (e.g., a certain UEID).
This value is usually public. It is not a secret and MUST NOT be
used for any purpose that a secret seed is needed, such as seeding a
random number generator.
Lundblade, et al. Expires 18 July 2024 [Page 26]
Internet-Draft EAT January 2024
There are privacy considerations for this claim. See Section 8.3.
$$Claims-Set-Claims //= (boot-seed-label => binary-data)
4.2.14. dloas (Digital Letters of Approval) Claim
The "dloas" claim conveys one or more Digital Letters of Approval
(DLOAs). A DLOA [DLOA] is a document that describes a certification
that an entity has received. Examples of certifications represented
by a DLOA include those issued by Global Platform and those based on
Common Criteria. The DLOA is unspecific to any particular
certification type or those issued by any particular organization.
This claim is typically issued by a verifier, not an attester.
Verifiers MUST NOT issue this claim unless the entity has received
the certification indicated by the DLOA.
This claim MAY contain more than one DLOA. If multiple DLOAs are
present, verifiers MUST NOT issue this claim unless the entity has
received all of the certifications.
DLOA documents are always fetched from a registrar that stores them.
This claim contains several data items used to construct a Uniform
Resource Locator (URL) for fetching the DLOA from the particular
registrar.
This claim MUST be encoded as an array with either two or three
elements. The first element MUST be the URL for the registrar. The
second element MUST be a platform label indicating which platform was
certified. If the DLOA applies to an application, then the third
element is added which MUST be an application label. The method of
constructing the registrar URL, platform label and possibly
application label is specified in [DLOA].
The retriever of a DLOA MUST follow the recommendation in [DLOA] and
use TLS or some other means to be sure the DLOA registrar they are
accessing is authentic. The platform and application labels in the
claim indicate the correct DLOA for the entity.
$$Claims-Set-Claims //= (
dloas-label => [ + dloa-type ]
)
dloa-type = [
dloa_registrar: general-uri
dloa_platform_label: text
? dloa_application_label: text
]
Lundblade, et al. Expires 18 July 2024 [Page 27]
Internet-Draft EAT January 2024gt;.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
<https://www.rfc-editor.org/info/rfc8329>.
[RFC8597] Contreras, LM., Bernardos, CJ., Lopez, D., Boucadair, M.,
and P. Iovanna, "Cooperating Layered Architecture for
Software-Defined Networking (CLAS)", RFC 8597,
DOI 10.17487/RFC8597, May 2019,
<https://www.rfc-editor.org/info/rfc8597>.
[TEQUILA] Georgatsos, P. and G. Giannakopoulos, "Service Negotiation
Protocol (SrNP)", <https://www.ist-
tequila.org/presentations/srnp-pipcm.pdf>.
[Xin] Wang, X., "Resource Negotiation and Pricing Protocol
(RNAP)",
<http://www.cs.columbia.edu/~xinwang/public/projects/
protocol.html>.
Boucadair, et al. Expires September 7, 2020 [Page 56]
Internet-Draft CPNP March 2020
Authors' Addresses
Mohamed Boucadair (editor)
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Dacheng Zhang
Huawei Technologies
Email: dacheng.zhang@huawei.com
Panos Georgatsos
Centre for Research and Innovation
Hellas
78, Filikis Etairias str.
Volos, Hellas 38334
Greece
Phone: +302421306070
Email: pgeorgat@gmail.com
Boucadair, et al. Expires September 7, 2020 [Page 57]