From 644fac6f64ba98ef62a608e277475b5a9b740dc0 Mon Sep 17 00:00:00 2001 From: "Dapeng(Max) Liu" Date: Wed, 19 Jun 2024 22:09:31 +0800 Subject: [PATCH 1/3] Propose to add one use case of security context establishment and propagation Propose to add one use case of security context establishment and propagation --- draft-ietf-wimse-arch.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/draft-ietf-wimse-arch.md b/draft-ietf-wimse-arch.md index 75e1bc8..36905ce 100644 --- a/draft-ietf-wimse-arch.md +++ b/draft-ietf-wimse-arch.md @@ -200,6 +200,43 @@ take place across intermediate workloads (in an end-to-end style). In a typical system of workloads additional information is needed in order for the workload to perform its function. For example, it is common for a workload to require information about a user or other entity that originated the request. Other types of information may include information about the hardware or software that the workload is running or information about what processing and validation has already been done to the request. This type of information is part of the security context that the workload uses during authorization, accounting and auditing. This context is propagated and possibly augmented from workload to workload using tokens. Workload identity comes into play to ensure that the information in the context can only be used by an authorized workload and that the context information originated from an authorized workload. +One example of security context establishment and propagation is as follows: + +~~~aasvg +┌───────────────────────────────────────────────────────────┐ +│ │ +│ ┌───────────────────┐ ┌──────────────────┐ │ +│ │ -Identity 1 │ │ -Identity 1 + 2 │ │ +│ │ -Security Context│ │ -Security Context│ │ +│ └──────────┬────────┘ └────┬─────────────┘ │ +│ │ │ │ +│ ┌──────────┐ ▼ ┌──────────┐ ▼ ┌──────────┐ │ +│ │ Workload1├──────► Workload2├──────► Workload3│ │ +│ └─────▲────┘ └──────────┘ └──────────┘ │ +│ │ │ +│ │Attestation │ +│ │ │ +├──────────▼────────────────────────────────────────────────┤ +│ │ +│ Platform: Host Operating System/Hardware Software │ +└───────────────────────────────────────────────────────────┘ +~~~~ +{: #arch-chain title="Security context establishment and propagation"} + +1. Workload 1 requests to load the LLM(Large Language Model) within Workload 2; Workload 2 requires that Workload 1 has hardware-based security to prevent model leakage. The hardware-based security context information of Workload 1 can be obtained by running a remote attestation protocol. Workload 1 provides its Identity and the security context information to Workload 2 to apply for loading the LLM. + +2. Workload 2 verifies the Identity and corresponding security context information provided by Workload 1 to confirm whether the model can be provided to Workload 1. + +3. Workload 1 also requires the LLM on Workload 2 to use the vertical industry domain-specific data on Workload 3 for model fine-tuning training. + +4. Workload 2 provides its Identity, Workload 1’s Identity, and its hardware-based security context information to Workload 3. + +5. Workload 3 uses this information for authentication and, upon passing, provides the industry domain-specific data to Workload 2. + +6. After fine-tuning training with the industry domain-specific data provided by Workload 3, Workload 2 provides the Model to Workload 1. + + + ### Delegation and Impersonation TBD. From 733361f0f03617f37682c5a12b2ebd0cde6efc7d Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 8 Jul 2024 14:30:49 +0200 Subject: [PATCH 2/3] Update draft-ietf-wimse-arch.md --- draft-ietf-wimse-arch.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-wimse-arch.md b/draft-ietf-wimse-arch.md index 36905ce..459223a 100644 --- a/draft-ietf-wimse-arch.md +++ b/draft-ietf-wimse-arch.md @@ -221,7 +221,7 @@ One example of security context establishment and propagation is as follows: │ Platform: Host Operating System/Hardware Software │ └───────────────────────────────────────────────────────────┘ ~~~~ -{: #arch-chain title="Security context establishment and propagation"} +{: #arch-chain title="Security Context Establishment and Propagation"} 1. Workload 1 requests to load the LLM(Large Language Model) within Workload 2; Workload 2 requires that Workload 1 has hardware-based security to prevent model leakage. The hardware-based security context information of Workload 1 can be obtained by running a remote attestation protocol. Workload 1 provides its Identity and the security context information to Workload 2 to apply for loading the LLM. From 70ab669ec4a1c8a1ba66541337f67918354d4337 Mon Sep 17 00:00:00 2001 From: "Dapeng(Max) Liu" Date: Wed, 6 Nov 2024 11:37:06 +0800 Subject: [PATCH 3/3] Update draft-ietf-wimse-arch.md, generalized the use case for security context establishment and propagation --- draft-ietf-wimse-arch.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/draft-ietf-wimse-arch.md b/draft-ietf-wimse-arch.md index 459223a..16ef33c 100644 --- a/draft-ietf-wimse-arch.md +++ b/draft-ietf-wimse-arch.md @@ -223,17 +223,15 @@ One example of security context establishment and propagation is as follows: ~~~~ {: #arch-chain title="Security Context Establishment and Propagation"} -1. Workload 1 requests to load the LLM(Large Language Model) within Workload 2; Workload 2 requires that Workload 1 has hardware-based security to prevent model leakage. The hardware-based security context information of Workload 1 can be obtained by running a remote attestation protocol. Workload 1 provides its Identity and the security context information to Workload 2 to apply for loading the LLM. +1. Workload 1 requests to load a service function within Workload 2. For example, the service function may be a LLM(Large Language Model) or a function to process PII information; Workload 2 requires that Workload 1 has hardware-based security （confidential computing） to prevent model or PII information leakage. The hardware-based security context information of Workload 1 can be obtained by running a remote attestation protocol. Workload 1 provides its Identity and the security context information to Workload 2 to apply for loading the service function. -2. Workload 2 verifies the Identity and corresponding security context information provided by Workload 1 to confirm whether the model can be provided to Workload 1. +3. Workload 2 verifies the Identity and corresponding security context information provided by Workload 1 to confirm whether the service function can be provided to Workload 1. -3. Workload 1 also requires the LLM on Workload 2 to use the vertical industry domain-specific data on Workload 3 for model fine-tuning training. +4. Workload 1 also requires the service function on Workload 2 to use the service function or data on Workload 3. For example, in the case of LLM, Workload 2 may required to load the vertical industry domain-specific data on Workload 3 for model fine-tuning. + +6. Workload 2 provides its Identity, Workload 1’s Identity, and its hardware-based security context information to Workload 3. -4. Workload 2 provides its Identity, Workload 1’s Identity, and its hardware-based security context information to Workload 3. - -5. Workload 3 uses this information for authentication and, upon passing, provides the industry domain-specific data to Workload 2. - -6. After fine-tuning training with the industry domain-specific data provided by Workload 3, Workload 2 provides the Model to Workload 1. +7. Workload 3 uses this information for authentication and, upon passing, provides the required service function or data to Workload 2.