WIMSE D. Liu, Ed. Internet-Draft X. Wang Intended status: Informational L. Yi Expires: 18 October 2024 Alibaba Cloud 16 April 2024 Securing service-to-service traffic by WIMSE Token draft-liu-wimse-secure-service-to-service-traffic-00 Abstract This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens. 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 October 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Liu, et al. Expires 18 October 2024 [Page 1] Internet-Draft Abbreviated Title April 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Use Cases and Scenario . . . . . . . . . . . . . . . . . . . 2 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. WIMSE Token Format . . . . . . . . . . . . . . . . . . . . . 4 4.1. Token Format . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Token Content . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Support for Cross-Trust Domains . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This document specifies the architecture, token format and related mechanism that uses wimse token for securing service-to-service traffic. 1.1. Requirements Language 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. 2. Use Cases and Scenario In cloud computing, there exists a type of scenario where one workload invokes another workload, forming a chain of invocation for the workload. In such a scenario, for the next workload, it is necessary to authenticate the identity of the previous invoker workload and the associated software and hardware runtime environment. A specific example is when an AI-enhanced application invokes a Large Language Model instance deployed on a public cloud, it needs to verify the software and hardware runtime environment of the Large Language Model instance. At the same time, this Large Language Model instance needs to further call and use the industry-specific data Liu, et al. Expires 18 October 2024 [Page 2] Internet-Draft Abbreviated Title April 2024 running on another workload. It then needs to authenticate the invoked Large Language Model instance and the workload of the AI- enhanced application. This forms an authentication chain with the workload invocation chain. This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens. 3. Overview As shown in Figure 1, the overall architecture is depicted. There are several roles in this scenario. * Cloud Service Provider The cloud service provider that provides cloud computing services to users, for example, public cloud service provider * Workload A running instance of software executing for a specific purpose. [reference: draft-salowey-wimse-arch-01] * Workload caller The entity that invokes a workload, could be another workload. * Attestation Service provider A provider that provide remote attestation services by executing remote attestation protocols, providing evidence of the hardware and software environment on which the cloud service provider runs workloads. * WIMSE Token Token that used for the authentication and securing service-to- service traffic in this workload chain invoking scenario. Liu, et al. Expires 18 October 2024 [Page 3] Internet-Draft Abbreviated Title April 2024 ┌────────────────────────────────────────────────────┐ │ │ │ │ │ │ ───┐ │ ┌────────┐ ┌────────┐ ┌──────┼────► │ │ Token│ │ Token │ │ Token │ │ │ │ ┌─────┴────┐ │ ┌────┴─────┐ │ ┌──────┴───┐ │ └─┼──► Workload │ └──► Workload │ └───► Workload │ │ ┌────────────────────────────┐ │ └─────┬────┘ └─────┬────┘ └─────┬────┘ │ │ Remote Attestation Service │ │ │ │ │ │ │ Provider │ └────────┼─────────────────┼─────────────────┼───────┘ └──────────────▲─────────────┘ │ │ │ │ ┌────────┼─────────────────┼─────────────────┼───────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─────────────────▼─────────────────▼───────┼──────────────────────┘ │ │ │* Platform:Host Operating System/Hardware Software | │(The service-account bound to the Pod, the version/ | | source of the container image used by the Pod) | └────────────────────────────────────────────────────┘ Figure 1: Overview architecture 4. WIMSE Token Format 4.1. Token Format The WIMSE token has the following format: It includes several nested JWT structures. As defined by [RFC7519], the (Content Type) Header Parameter of a nested JWT should be set to "JWT". In a chained workload invocation scenario, the method for generating the JWT Token of the workload being called is: sign and encrypt the JWT Token of the calling workload and use it as the payload for the JWT Token of the workload that is being called. 4.2. Token Content The token includes the following claims: * iss (Issuer Claim): The identity of the issuer. * sub (Subject Claim): The subject of the token. Liu, et al. Expires 18 October 2024 [Page 4] Internet-Draft Abbreviated Title April 2024 * aud (Audience Claim): The intended recipients of the token, which can be the identifier of the workload. * exp (Expiration Time Claim): The expiration time, defining the validity period of the token. * nbf (Not Before Claim): The time before which the token is not valid. * iat (Issued At Claim): The time at which the token was issued. * jti (JWT ID Claim): The unique identifier of the JWT. * transaction_id: The transaction identifier, used to bind the token to a specific transaction. * context: Context information, which can include user identity, platform attestation information etc. The context field can contain various types of information, such as: * User Identity: Information about the user performing the current operation, which can be a user ID, username, or other unique identifiers. * Platform Attestation: Attestation information of the platform or system, such as runtime integrity check results. This may include the information of the Operating System/Hardware Software and also may include the service-account bound to the Pod, the version/ source information of the container image used by the Pod. To achieve interoperability across trust domains, it may be necessary to standardize the context field in different systems so that different service providers and consumers can understand and process this information. Liu, et al. Expires 18 October 2024 [Page 5] Internet-Draft Abbreviated Title April 2024 { "alg": "RSA1_5", "enc": "A128CBC-HS256", "cty": "JWT" "payload": { "iss": "https://issuer.example.com", "sub": "caller-identity", "aud": "https://service.example.com", "exp": 1601519424, "nbf": 1601519424, "iat": 1601519424, "jti": "abc123", "transaction_id": "tx123", "context": { "user_identity": "user-id", "platform_attestation": "attestation-data", }, "payload":"caller-JWT-Token", }, "signature": "TBE5Y3J0VGVzZHBGVbGxpbmc=" } Figure 2: Example of wimse token 4.3. Support for Cross-Trust Domains Federation: If working across multiple trust domains is required, SPIFFE federation or similar mechanisms can be implemented to securely share and verify tokens across domains. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Security Considerations TBD 8. References 8.1. Normative References Liu, et al. Expires 18 October 2024 [Page 6] Internet-Draft Abbreviated Title April 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . 8.2. Informative References Acknowledgements TBD Contributors TBD Authors' Addresses Dapeng Liu (editor) Alibaba Cloud Building 9, Block 4, Wangjing East Park Beijing Bejing, 100102 China Email: max.ldp@alibaba-inc.com Xining Wang Alibaba Cloud Building 9, Block 4, Wangjing East Park Beijing Bejing, 100102 China Email: xining.wxn@alibaba-inc.com Liu, et al. Expires 18 October 2024 [Page 7] Internet-Draft Abbreviated Title April 2024 Li Yi Alibaba Cloud Building 9, Block 4, Wangjing East Park Beijing Bejing, 100102 China Email: weiyuan.yl@alibaba-inc.com Liu, et al. Expires 18 October 2024 [Page 8]