HTTPS integration is unusual about kbs HOT 32 CLOSED

It seems that we have reached an agreement. It is time to update the document to follow up our discussion results in this issue.

@sameo I see you mentioned in #3 that you will update the KBS protocol document, how is it going?

@jialez0 I'm working on it.

from kbs.

I am very new to KBS and so this might be completely off :-) However, if the goal is to authorise access to web resources using attestation as a "better" form of authentication, then maybe another way to achieve the objective is to extend existing protocols -- e.g., OAuth 2.0 (for the Web) and ACE (for the constrained space) -- to introduce attestation evidence as another type of identity credential.

from kbs.

I am very new to KBS and so this might be completely off :-) However, if the goal is to authorise access to web resources using attestation as a "better" form of authentication, then maybe another way to achieve the objective is to extend existing protocols -- e.g., OAuth 2.0 (for the Web) and ACE (for the constrained space) -- to introduce attestation evidence as another type of identity credential.

In a general context I would agree, but I'd say in this particular context the most likely scenario is that clients will only be using this schema for boot-time (or pre-boot time, in the case of SEV and SEV-ES) attestation, accessing a single type of object (a key for opening the encrypted payload). After it has booted, the TEE will likely switch to a different attestation mechanism, such as one based on a vTPM. In this case, I think trying to extend an existing protocol would probably be too expensive.

Another question is what happens when we'll want to provide a signed attestation quote to consumers of a service (Intel has proposed an HTTP variant for this, called HTTPA) or to sign artefacts, but that's a completely different story.

from kbs.

If this is the only expected interaction, I agree with your minimalist approach.

Thanks for the explanation @slp.

from kbs.

@hdxia @jiazhang0 @jialez0 have you guys seen some of the recent feedback about the KBS? What is the development status? I think we should probably try to integrate some of these suggestions.

In a general context I would agree, but I'd say in this particular context the most likely scenario is that clients will only be using this schema for boot-time (or pre-boot time, in the case of SEV and SEV-ES) attestation, accessing a single type of object (a key for opening the encrypted payload). After it has booted, the TEE will likely switch to a different attestation mechanism, such as one based on a vTPM. In this case, I think trying to extend an existing protocol would probably be too expensive.

For Confidential Containers, at least, I think we are planning to use the KBS at runtime as well. We will still have just one attestation at boot, but that session will then be used to request many different confidential resources as containers are verified, decrypted, and run. Generally I'm not thinking that we'll have a vTPM in this context, but if we do, one way to consume its measurement could be to send a quote to the KBS as evidence. We would also need to provision the vTPM somehow so we'll need to think more about this, but point is I think the scope might be a little bit broader.

Another question is what happens when we'll want to provide a signed attestation quote to consumers of a service

One thing that has been proposed is allowing the Attestation Agent in the guest to provide the hw evidence directly to the workload. A workload could then present this to some other party such as an end user. Guest owners could then also implement their own attestation processes in a container.

In certain circumstances it might be nice to have the KBS in the loop. xIn simple-kbs we have an experimental feature where the KBC can request a signed attestation report from the KBS. simple-kbs is only for SEV(-ES) where the launch measurement is not durable, so this report feature is kind of handy. It would probably be good if we could make these ideas a little more generic and standardized.

from kbs.

@hdxia @jiazhang0 @jialez0 have you guys seen some of the recent feedback about the KBS? What is the development status? I think we should probably try to integrate some of these suggestions.

In a general context I would agree, but I'd say in this particular context the most likely scenario is that clients will only be using this schema for boot-time (or pre-boot time, in the case of SEV and SEV-ES) attestation, accessing a single type of object (a key for opening the encrypted payload). After it has booted, the TEE will likely switch to a different attestation mechanism, such as one based on a vTPM. In this case, I think trying to extend an existing protocol would probably be too expensive.

For Confidential Containers, at least, I think we are planning to use the KBS at runtime as well. We will still have just one attestation at boot, but that session will then be used to request many different confidential resources as containers are verified, decrypted, and run. Generally I'm not thinking that we'll have a vTPM in this context, but if we do, one way to consume its measurement could be to send a quote to the KBS as evidence. We would also need to provision the vTPM somehow so we'll need to think more about this, but point is I think the scope might be a little bit broader.

Those confidential resources are also serviced by KBS or by other components?

In case they are serviced by other components, I can understand the need for a signed token that can be federated. But, even in this case, I think it'd be simpler and more effective to use a session cookie for the interactions with KBS, and then have it emit a signed token when the attestation is successful including it as part of the Response payload.

I also think it'd be nice if the emission of this token is optional and must be explicitly requested by using a dedicated field in the Request payload, since it's likely some TEE use cases don't need it.

Another question is what happens when we'll want to provide a signed attestation quote to consumers of a service

One thing that has been proposed is allowing the Attestation Agent in the guest to provide the hw evidence directly to the workload. A workload could then present this to some other party such as an end user. Guest owners could then also implement their own attestation processes in a container.

In certain circumstances it might be nice to have the KBS in the loop. xIn simple-kbs we have an experimental feature where the KBC can request a signed attestation report from the KBS. simple-kbs is only for SEV(-ES) where the launch measurement is not durable, so this report feature is kind of handy. It would probably be good if we could make these ideas a little more generic and standardized.

The option of having a KBS-signed attestation sounds really interesting. Honestly, I haven't put much thought into this because that requires adaptations in userspace and we're barely getting the guest up and attested ;-)

from kbs.

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse it in order to skip the Attestation and Challenge steps to request more resources from the KBS.

I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

from kbs.

Those confidential resources are also serviced by KBS or by other components?

I think the KBS will fulfill future requests, although it might get some secrets from an external party. I think you're right that we don't need anything more than some kind of cookie.

from kbs.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

I'm glad to see these constructive suggestions for KBS protocol, which is very helpful for us to optimize the attestation system of confidential containers.

I don't know about the current implementation progress of KBS. @hdxia is doing the implementation work. Maybe he can give some updated information about the current implementation progress.

Using the same route /kbs/key/key_id for all payloads forces both the server and the client to first identify the nature of the payload, and then deserialize it. Most web frameworks are designed to support a single payload per route, otherwise requiring manual parsing of the body contents. This means more error-prone work on the shoulders of the devs implementing the protocol.

This is reasonable to me. Putting more information in the request into the route will indeed make the implementation simpler and easier to maintain. Thanks for this proposal.

from kbs.

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse it in order to skip the Attestation and Challenge steps to request more resources from the KBS.

I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

Current kbs protocol can also short circuit the Attestation and Challenge steps. So from this point, there are no differences between the existing design and new proposal.

We talk current token scheme is stateless. Essentially, the so-called "state" is the unsigned token. In session cookie scheme, it just holds the "state" in kbs side. In token scheme, we transfer the "state" with signature protection and expiration check in form of token. Right?

from kbs.

@slp I see the thing becomes complex rather than relaxed. More specifically, KBS becomes relaxed but KBC become complex because it is not stateless any more. KBC running inside a TEE should be more simpler.

In addition, the interaction overhead increases in slow path:

[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with KBS directly and attestation-service then communicate with KBS or simple-kbs and eventually return a token to KBS to access more external services (not all resources are hosted by KBS) authenticated by the issued token.

Also, we need to listen the opinions from KBS maintainer @hdxia , after all what I heard from @peterzcst is that the kbs will be submitted soon according to current KBS protocol. I don't oppose session cookie scheme, but we want to see more benefits from it. By the way, the suggestions about route path definitions look more graceful.

from kbs.

I think something like this would be a more conventional approach

That sounds reasonable to me. Besides the weird GET with a payload approach, I think simply using a cookie should be enough for the current KBS purpose. As long as the cookie is valid, a KBC should be able to reuse it in order to skip the Attestation and Challenge steps to request more resources from the KBS.
I'm planning to soon send an update of the KBS document, I'll try to integrate this proposal to it.

Is there already software implementing the current KBS attestation protocol or are we still in time to introduce some changes to it?

We have not seen anything yet. @jialez0 @hdxia may know more.

Current kbs protocol can also short circuit the Attestation and Challenge steps. So from this point, there are no differences between the existing design and new proposal.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload.
Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.

Are there any other reasons for using a full JWT token as part of the Request payload instead of a standard HTTP cookie?

We talk current token scheme is stateless. Essentially, the so-called "state" is the unsigned token. In session cookie scheme, it just holds the "state" in kbs side. In token scheme, we transfer the "state" with signature protection and expiration check in form of token. Right?

Correct. With the current design the KBS side is stateless but we need to carry the state with every Request message. It's basically an ad-hoc scheme for letting the KBS know how to wrap the symmetric key used in the Response. AFAICT we're always going to pass the same key, the TEE public one.
Do you see use cases where the KBC would want to request the KBS to use other keys? Wouldnt that be a security concern?

from kbs.

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with KBS directly and attestation-service then communicate with KBS or simple-kbs and eventually return a token to KBS to access more external services (not all resources are hosted by KBS) authenticated by the issued token.

As I wrote before, I think it's possible to combine both authentication models (cookie and signed token), obtaining the best of both models.

The Request payload could be extended to indicate that the requester (KBC), in addition to authenticating with the KBS, wants to obtain a signed token from the latter. This is to avoid the overhead of forcing the KBS to generate a signed token for the case where the client won't need it (combined TEE+vTPM models, such as Confidential VMs, or smaller footprint models, such as Confidential Workloads).

Then, a new payload could be introduced to be sent by the KBS in response to a successful attestation through POST /kbs/v0/key/<key_id>/attest with the Attestation payload that, in addition to the attestation result, returns a signed token, in case it was requested and the attestation was successful.

Finally, the KBS can define the same route /kbs/v0/<key_id> with both a GET and a POST method. This is valid and supported by every web framework, triggering different code paths. The GET method would rely on a existing cookie for authentication, while the POST method would expect to receive a payload that includes a signed token.

With this schema, a KBC wanting to rely only on signed tokens would be able to obtain the secret with this interaction:

• POST to /kbs/v0/key/<key_id>/session with Request
  • Receives Challenge as response
• POST to /kbs/v0/key/<key_id>/attest with Attestation
  • Receives a payload with the result of the attestation and a signed token
• POST to /kbs/v0/key/<key_id> with a payload including the signed token
  • Receives Response including the secret

...while providing a more natural HTTP workflow and simplifying the implementation of the server and the clients that only want to request a one-time attestation.

In addition, the interaction overhead increases in slow path:

[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

IMHO, mixing authentication and authorization in the schema is not a good idea, but if we really need to reduce the interaction to two HTTP operations, the Request payload could be extended to include a field to indicate that the client wants to receive the secret in the reply to the POST to /kbs/v0/key/<key_id>/attest.

But I really think this should be an optional feature of the protocol that some KBS implementations may decide not to adopt. Clients can easily support for models by looking for the field that should hold the secret and issuing a GET/POST to /kbs/v0/key/<key_id> if they find it empty.

from kbs.

One other advantage of the flow proposed by @slp with the KBC doing POST for the challenge consists that it could be easily extendable if the attestation is initiated by the KBS instead of the KBC.
In today's schema, the attestation is always initiated by the attestation agent because it needs to retrieve the secret in order to start the workload.
However, for other remote attestation projects (e.g keylime), the attestation flow is started by the server. For example, in order to health check the system. In this case, the KBS starts the attestation and could provide the id of the session. If we decide to introduce the POST for the challenge, then the rest of the attestation flow remains the same as the KBC can simply reply with the POST challenge and use the session id provided by the KBS

from kbs.

@slp I see the thing becomes complex rather than relaxed. More specifically, KBS becomes relaxed but KBC become complex because it is not stateless any more. KBC running inside a TEE should be more simpler.

In addition, the interaction overhead increases in slow path:

[GET] request vs [POST] request  // Yeah using GET method should be fixed
          Challenge response vs Challenge response
[GET] attest vs [POST] attest
          Response (with the encrypted resource) vs Response statue
[GET] none vs [GET] requested resource
           none vs Response (with the encrypted resource)

You're right, @slp proposal adds one more KBC message, to eventually get the resource.

Current design:

-> GET /kbs/key/key_id [Payload: Request]
<- Response [Payload: Challenge]
->  GET /kbs/key/key_id [Payload: Attestation]
<- Response [Payload: Response]

Proposal:

-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

The proposal is not that different from the current design, and is closer to an idiomatic HTTP flow imho.

KBS protocol using token scheme targets to support cc scenario with the considerations to support broader usage such as passport model of attestation defined by RATS arch. For example, maybe current attestation-service can communicate with KBS directly and attestation-service then communicate with KBS or simple-kbs and eventually return a token to KBS to access more external services (not all resources are hosted by KBS) authenticated by the issued token.

What would the token look like in those cases?

Also, we need to listen the opinions from KBS maintainer @hdxia , after all what I heard from @peterzcst is that the kbs will be submitted soon according to current KBS protocol.

Yes, definitely, their feedback is needed.

from kbs.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload.
Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.

Yes, both the current design and @slp proposal allow for skipping attestation and challenge steps. But in the current design we're using a full JWT token basically for carrying the TEE public key and have the KBS use that to encrypt the symetric key it uses for the Response. That public key is something the KBS already got from the Attestation payload. Keeping track of that (and any other KBC session related parameter) through a standard Cookie-based sessionid value seems simpler. The KBS only need to map a session id to a public key instead of deserializing a JWT to get the key.

Are there any other reasons for using a full JWT token as part of the Request payload instead of a standard HTTP cookie?

It is still the challenging point between stateful and stateless in web service design.

Authentication has been a stateful affair for a long time. All user details associated the session ids are stored in KBS side. Many components in TEE that requires some sort of info about the workload provider must communicate with KBS. Most of user data is centralized. In complex scenarios, it is a limit that getting data from the central KBS for operations can be troublesome. If authorization and authentication were stateless, each operation can carry all necessary data contained in them. With stateless token scheme, we can keep the opaque of token intact but meanwhile embed arbitrary data in it. That means that getting to that data in KBS side needs no additional communication between KBS and its backend data store: the KBS only needs to decrypt the data contained in that token.

Additionally, in so-called transport model of attestation, KBC would request attestation-service directly to get a signed token and then request various external services to access the data with that token as proof for authorization. This scenario is very possible because not all resources are centralized in KBS. This is somewhat a OAuth2 scenario mentioned by @thomas-fossati .

The last point of using token scheme is that the initial design doesn't assume the transport protocol must be HTTPS. The messages defined in KBS protocol can be self-protected even without the support from transport protocol.

from kbs.

IMHO, mixing authentication and authorization in the schema is not a good idea, but if we really need to reduce the interaction to two HTTP operations, the Request payload could be extended to include a field to indicate that the client wants to receive the secret in the reply to the POST to /kbs/v0/key/<key_id>/attest.

But I really think this should be an optional feature of the protocol that some KBS implementations may decide not to adopt. Clients can easily support for models by looking for the field that should hold the secret and issuing a GET/POST to /kbs/v0/key/<key_id> if they find it empty.

Let me quote Sameo's workflow chart:

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

So if splitting the flow into two phases, it looks more reasonable, right? In addition, is it necessary to request /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

Does it make sense to you?

from kbs.

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/key/<key_id>/session [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/key/<key_id>/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

So if splitting the flow into two phases, it looks more reasonable, right?

Looks good to me. We might also want to have a POST method for the resource (/kbs/v0/key/<key_id>) that receives a payload with a signed token (perhaps marking it as optional?), thus preserving the current ability to obtain and use a federated token as an opt-in feature:

> -> POST /kbs/v0/key/<key_id> [Payload: new payload including the signed token]
> <- Response [Set-Cookie: <session-id>] [Payload: Response]

In addition, is it necessary to request /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

Does it make sense to you?

Yes, as I wrote before, I wasn't sure if the authentication/authorization was restricted to the scope of the resource, or was global to the KBS (and, potentially, some other federated services). In the latter case, dropping the resource type and resource id from the route, as you suggest, is the way to go.

from kbs.

So if splitting the flow into two phases, it looks more reasonable, right? In addition, is it necessary to request /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

Looks good to me. We might also want to have a POST method for the resource (/kbs/v0/key/<key_id>) that receives a payload with a signed token (perhaps marking it as optional?), thus preserving the current ability to obtain and use a federated token as an opt-in feature

Agree, I think we need this optional function to be compatible with the signed token scheme.

from kbs.

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

That looks pretty good to me. Authentication is not bound to a specific resource.

from kbs.

So if splitting the flow into two phases, it looks more reasonable, right? In addition, is it necessary to request /kbs/key/<key_id>/session and /kbs/v0/key/<key_id>/attest with resource route path? Actually the authorization for resource access can occur in resource access phase. If so, the URI in authentication phase can be simplified to:

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>][Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

from kbs.

I think it is a more appropriate choice to take the authentication phase as the global route of KBS, which will make the implementation of the server more clear. In this implementation mode, in order to still ensure the distinguishability of authentication on the resource scope, we can extend the Request payload message and add a field to it to indicate to KBS which resource the KBC want to access, which allows KBS to make a decision on "whether a specific KBC can access a specific resource".

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

I agree. Fine grained authorization definitions can easily grow out of control. Sounds like one of those things that it's better to leave for a future version of the protocol. 😉

from kbs.

Or should we keep the authentication phase simple and let KBS decide which resource a KBC/Attestation evidence can access when trying to get that resource?

OK, it does look clearer. Although I'm not sure whether this will cause some problems in the implementation, at present, it may be a good idea.

So let me summarize the results of our current discussion. If KBC needs to request /kbs/v0/key/<key_id>, there are two flow as follows:

If KBC uses session scheme:

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?
And, @hdxia Does this make sense to you?

from kbs.

So let me summarize the results of our current discussion. If KBC needs to request /kbs/v0/key/<key_id>, there are two flow as follows:

If KBC uses session scheme:

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?

That seems correct, although if we make the Cookie non optional and the token optional, then we can really have a common flow for both paths.

from kbs.

If KBC uses session scheme:

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: No)]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/key/<key_id> [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

If KBC uses the signed token scheme:

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request (token: Yes)]
<- Response [Payload: Challenge]
-> POST  /kbs/v0/attest [Payload: Attestation]
<- Response  [Payload: Token]

// resource access phase
-> POST /kbs/v0/key/<key_id> [Payload: Token: <signed token>]
<- Response [Payload: Response]

@sameo @slp @fitzthum @thomas-fossati @jiazhang0 Right?

That seems correct, although if we make the Cookie non optional and the token optional, then we can really have a common flow for both paths.

I also think making the Cookie non-optional is a good idea. Supporting cookies for the client is virtually free with most HTTP client libraries and very easy to implement for the server too.

With that, both paths for the authentication phase would be the same, with the only difference that if the emission of a ticket is desired, in Request the emit_token field would be set to true (instead of false), and the token field in the payload that is received as a response to POST /kbs/v0/attest would carry the signed token (instead of being empty).

from kbs.

I've just started writing a crate (kbs-types) to implement the types defined by the KBS attestation protocol in a way that can be easily consumed by Rust-based servers and clients, and found a small inconvenience with the payload format.

Currently, payload formats are defined like this:

{
  "payload_name": {
    "version": "0.1.0",
    (...other payload fields...)
  }
}

This means that, while parsing this as a JSON, we get a root object that holds a single payload_name object, and then the payload fields (Root Object->payload_name->field).

Since there are no fields outside payload_name, and the type of the payload is already defined by the route that's being serviced/accessed, I think it'd be nicer to remove the second object and just put the fields in the root:

{
  "version": "0.1.0",
  (...other payload fields...)
}

Another minor issue I've found is that the use of hyphens instead of underscores (or CamelCase) in field names means that we need to annotate some fields with #[serde(rename = "name-with-hyphens")], but this is a Rust specific issue with an existing workaround.

from kbs.

Well, I agree that making session and cookies non-optional, this will make the authentication process more unified. However, if so, I don't think token needs to be an optional scheme anymore. KBS can open a resource route for token acquisition separately, that is, treat token as the resource itself and obtain it like this: GET /kbs/v0/token/. In this way, we don't need to add an instruction to enable token in the payload of POST /kbs/v0/auth.

The reason why we need a token scheme is to support some scenarios of distributed services. In this way, attester can obtain a token from KBS, and then hold this token to request resources from other servers. In the future, it can even communicate directly with Attestation-Service, obtain a token from Attestation-Service, and hold the token to request a decryption key from KBS. This is what we often call the "passport model", We hope that the protocol we are designing now can be compatible with this. As I said above, we can request tokens as resources, so that we can obtain tokens through the following process:

// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible.
@sameo @slp @jiazhang0

from kbs.

// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible. @sameo @slp @jiazhang0

I think it's more elegant than a dedicated payload field, I like it. I don't mind the extra GET call for getting the token, I think the protocol clarity we get from it is worth it.

from kbs.

// resource access phase
-> GET /kbs/v0/token [Cookie: N/A]
<- HTTP/401 Unauthorized

// authentication phase
-> POST /kbs/v0/auth [Payload: Request]
<- Response [Set-Cookie: <session-id>] [Payload: Challenge]
-> POST  /kbs/v0/attest [Cookie: <session-id>] [Payload: Attestation]
<- Response [Set-Cookie: <session-id>]

// resource access phase
-> GET /kbs/v0/token [Cookie: <session-id>]
<- Response [Set-Cookie: <session-id>] [Payload: Response]

This token acquisition method will be more natural and more compatible. @sameo @slp @jiazhang0

I think it's more elegant than a dedicated payload field, I like it. I don't mind the extra GET call for getting the token, I think the protocol clarity we get from it is worth it.

I like it too, thanks!

from kbs.

FYI, I've started writing a reference implementation of the tentative KBS attestation protocol, using the kbs-types crate, to have a better idea of how well it fits with the most common TEE attestation mechanisms: reference-kbs

from kbs.

FYI, I've started writing a reference implementation of the tentative KBS attestation protocol, using the kbs-types crate, to have a better idea of how well it fits with the most common TEE attestation mechanisms: reference-kbs

+1 Thanks @slp. @hdxia Could we sync with Sergio here to make sure we're not duplicating efforts?

from kbs.

It seems that we have reached an agreement. It is time to update the document to follow up our discussion results in this issue.

@sameo I see you mentioned in #3 that you will update the KBS protocol document, how is it going?

from kbs.