Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

[Laurence Lundblade <[e-mail]>]

Hi Eric,

Really glad we’re having a discussion on attestation results now. Kind of a coincidence we both focused on it at 111.


> On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[e-mail]> wrote:
> 
> Hi Laurence,
>  
> During the RATS IETF 111 sessions, we both shared views of how to encode Attestation Results (AR).   From the perspective of draft-voit-rats-attestation-results, the AR in scope are Verifier generated claims* about trustworthiness of the Attester itself.   Some examples of such claims include:  
> the Verifier asserts that the Attester has only known good software loaded     
> the Verifier asserts Attester's configuration doesn't expose security holes
> We are now beginning to standardize these Verifier generated claims (and associated AR object definitions).   We need to do this with the stated objective of maximally simplifying the interworking of different types of Attesters, Verifiers, and Relying Parties.  That maximal simplification is essential as we diverse group of RATS roles and developers spanning different industries.  And to accomplish this, I suggest we adopt the following set of design principles: 
>  
> (1) We should only have a small number of Verifier trustworthiness claims standardized at this time.  Reason: a plethora of similar trustworthiness claims will result in divergent choices made between different Verifiers.  This would place a lot of complexity in the Relying Party as it would be up to the RP (and its policy language) to enable normalization across rich incompatible Verifier object definitions.
>  
> (2) Any objects from (1) which we do standardize should only include specific enumerated states that could viably result in a different action from the applied Policy for Attestation Results.   Reason: by explicitly disallowing the standardization of any enumerated states which cannot easily be connected to a use case, we avoid forcing implementers making incompatible guesses on what could happen.  This will eliminate many types of errors.
>  
> (3) Verifier and RP developers need explicit definitions of *each* state in order to accomplish the goals of (1) and (2).  Without such guidance, the Verifier will send plenty of raw info, as it relieves the Verifier of making the hard decisions.  Of course, this raw info will be mostly non-interpretable and therefore non-actionable by the RP.
>  
> (4) We do need extensibility for this type of Verifier generated claim.  But Verifier generated claims should be worked in the WG and managed via the RFC process, rather than being in a separately maintained Attester Claims list.  This will keep a tight lid on extensions which must be considered by the RP's policy language.

I assume these claims would be in the CWT and JWT registry like other claims and that they have no special status in those registries. We’re not creating a new registry for these, nor are we going to modify the CWT or JWT registries so they can have special status, right?

I also assume we should clarify that EAT profiles apply to attestation results and/or evidence and that is the mechanism used to keep a handle on the number of claims in attestation results.


I would like to add this important design principle:

(5) Cover the full range of use cases, device types and security levels. Use cases may include letting a device on the network, a financial transaction, a biometric authentication and more. Device types may include complex mobile phones, simple IoT sensors, laptops and network equipment. Security levels may range from EAL 5 certified secure element, to a TEE, to entirely simple minimal devices with no special security properties.


>  
> These design principles are important to keep the number of Verifier generated claims low, and to retain the complexity in the Verifier rather than the RP.   We followed these design principles in draft-voit-rats-attestation-results.   Consequently, the next version of draft-voit-rats-attestation-results will include a total of 9 Verifier generated Trustworthiness Claims supporting a total of 18 enumerated states.   18 enumerated states feels like an easily digestible number for the developers of RP policy language :-).  

I think there may be more than one model for constructing attestation results.  Your draft is one. Another might be based on machine learning, in which case the RP just wants every data item possible. I think a single  “trust me” boolean is OK for some use cases. Maybe the boolean is implied because attestation results were generated.

This also fans out by submodule for complex devices, even with draft-voit-rats-attestation-results (there is no inheritance with submodules).



> I am hoping we can connect this thinking to your swresult object from your IETF 111 slides.   Looking at your slide on the swresult claim, *each* software measurement could include a large array of results.  I believe this unbounds the complexity of the RP policy language.  Effectively, the Evidence to the Relying Party may often be richer than that originally sent by the Verifier.  In what scenarios do you see Relying Party applying such a rich language?   And at least from the perspective of deciding whether Attester itself is trustworthy, do you see ways for just a few Verifier generated claims to expose key trustworthiness attributes and states evaluated for the Attester?

Swresults was intended as a flexible way to report what ever SW measurement results need to be reported. It is intended to cover all possible cases. I would expect many use cases to use very little of it. Many, hopefully, most could be very simple using it.

Swresults also can be in attestation evidence when one subsystem like a TEE can measure and evaluate another subsystem.

I’m not sure the principles above should be applied to swresults as I think it is for a different model for reporting attestation results. Open to discussion on this.

Swresults is kind of a first proposal. Would appreciate lots of discussion around it. Seems to me that we’re just getting started on this topic.


>  
> I know this is a complex question which might only be worked in an upcoming interim. 

Probably more than just one interim :-)

LL




> But I figured I would start the dialog now.
>  
> Thanks,
> Eric
>  
> * Note from above: these Verifier generated claims are not the same thing as a Verifier ratifying specific claims generated within the Attester (such as UEID, location, software manifest, etc.)   Many of your AR definitions within the swresult appear aimed at this context.  So there might not be an explicit overlap between our drafts.  
>  
> Eric Voit 
> Principal Engineer
> .:|:.:|:. Cisco Systems, Inc.
>  
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>