Re: [Rats] [External Sender] Discussion paper regarding RATS & OpenID-Connect -- RE: Adhoc meeting at IETF 117 for anyone interested in attested Open-ID/Connect and Oauth2

["Smith, Ned" <[e-mail]>]

--snip--
>>> For me a couple of interesting questions come to mind.
>>> 1. Does the RP need to directly integrate with the Verifier in some way 
>>> to get the attestation result or could it trust an attestation result provided by the OP?
>This is a great question. The way it is shown in Figure-2, the RP0 and the Verifier are distinct, but they could presumably be 
> placed together.
> With regards "trust" there is an assumption (though not explicit in in RFC9334) that the Verifier itself is "safe" and "trusted to > appease the evidence" (i.e. the Verifier has not been compromised and not manipulating the appraisal Results).
>
The RP and Verifier do need to agree on a format and representation for Attestation Results (AR). RFC9334 documents the AR flow from Verifier to RP, but doesn't describe how RP tells the Verifier what AR format to use and what Attester attributes are meaningful to the RP for making a decision.

All of the RATS roles can be combined / separated to achieve a particular deployment goal. If separated, the method by which they authenticate / trust each other is left out of scope for RFC9334. It could be based on provisioning (say of trust anchors), or it could depend on recursive application of attestation, or something else.

The AR_Token is intended to be a representation of Attestation Results that the OP, AS, or other relying party accepts as having the right set of Attester attributes necessary to decide whether to proceed or not. 

> Also, Fig-2 assumes that the OP is "safe and trusted".
>>> 2. I expect the OP will also want to validate the device evidence so do most 
>>> flows need to have the evidence evaluated twice? or is once sufficient?
> So, I think this is one of the design questions. Functionally, the Verifier should be compartmentalized away from the OP 
> function. In this case the OP is reliant on the Verifier for a locally-issued appraisal Result. 
> (Although out of scope, the OP machine could be an Attester in its own right).
>
The AR_Token, most likely, will have an expiration date. As long as the token hasn't expired, it could be reused.
However, there is the possibility that the Attester state is dynamic, e.g., a sw update was pushed, the update might trigger 
re-issuance of the AR_Token, even though the previous token didn't expire. That presents an interesting consistency
question. But likely not a security concern if the "RP" decision makers update their policies in a timely way. If the stale AR_Token
is used, access is denied until the re-issued token propogates.

>>> I'm wondering if it's possible to define a scope 'rats_results' that would be understood by the OP 
>>> and the attestation results could be returned in the id_token. 
>
> Would this be a mismatch of functions? id_tokens are for humans.
> Alternatively, could the id_token has a new flag that says this "human needs device verification to be performed".
>
W3C verifiable credentials has the notion of a presentation layer. This could be for humans or machines. 
Possibly, it makes sense for the AR_Token to have a presentation layer that is appropriate for both humans and machines?
That way, if in OIDC / OAuth flows that involve humans, there would be an attestation results expression that is meaningful
to humans. Likewise, for machine-machine flows, the AR-Token might contain something like AR4SI (https://datatracker.ietf.org/doc/draft-ietf-rats-ar4si/) or EAR (https://datatracker.ietf.org/doc/draft-fv-rats-ear/).
It might be better to think of Attestation Results as a distinct token, rather than a subset of an ID_Token or an Access_Token
since each token type has a different objective. Given an endpoint (relying party) has multiple objectives, receiving multiple tokens may make sense. Binding the various tokens becomes a relevant security consideration at that point.
--snip--

________________________________________
From: George Fletcher [[e-mail] <mailto:[e-mail]>]
Sent: Tuesday, August 22, 2023 7:37 AM
To: Thomas Hardjono
Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>stries; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Justin Richer; [e-mail] <mailto:[e-mail]>; Ned Smith ([e-mail] <mailto:[e-mail]>); [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
Subject: Re: [External Sender] Discussion paper regarding RATS & OpenID-Connect -- RE: Adhoc meeting at IETF 117 for anyone interested in attested Open-ID/Connect and Oauth2


Thanks for the discussion paper. I do think this is interesting work. In the past I've defined a private extension of OpenID Connect that was for "authenticating" devices rather than people so I agree that there is a need for this general functionality.


A couple of points on the OpenID Connect flow. The flow described is more akin to the "implicit flow" which is basically deprecated except for a few special use cases. In general, what the RP gets back from the OP after redirecting the user to the OP to authenticate is an 'authorization_code'. This code is then exchanged via a direct connection between the RP and the OP to obtain the id_token and access_token. Also, while in some deployments the token introspection endpoint will return user data, the more correct endpoint is the /userinfo endpoint defined by OpenID Connect.


For me a couple of interesting questions come to mind.
1. Does the RP need to directly integrate with the Verifier in some way to get the attestation result or could it trust an attestation result provided by the OP?
2. I expect the OP will also want to validate the device evidence so do most flows need to have the evidence evaluated twice? or is once sufficient?


I'm wondering if it's possible to define a scope 'rats_results' that would be understood by the OP and the attestation results could be returned in the id_token. This would just be a profile of OpenID Connect defining the new scope. Since the OP knows the RP making the request, it could ensure the Verifier applies the correct policy when evaluating the evidence. I realize this might not cover all use cases.


Thanks,
George


On Mon, Aug 21, 2023 at 7:39 PM Thomas Hardjono <[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>> wrote:


Folks,


Following from the sidebar meeting at IETF117, we have written a short discussion paper (PDF attached).


(The discussion paper is also available here: https://urldefense.com/v3/__https://shorturl.at/mnO37__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSb2bWmOXQ$ <https://urldefense.com/v3/__https://shorturl.at/mnO37__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSb2bWmOXQ$> )


The aim of the short paper is to explain better the motivations and use-cases for exploring OIDC as a mechanism to deliver RATS-based device-attestations.


We would appreciate comments & suggestions for going forward.




Best


Thomas & Ned








________________________________________
From: scim [[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>] on behalf of Smith, Ned [[e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>]
Sent: Wednesday, August 9, 2023 5:23 PM
To: [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>
Subject: Re: [scim] Adhoc meeting at IETF 117 for anyone interested in attested Open-ID/Connect and Oauth2


Folks,
We had a side-bar meeting at the IETF117 last week in San Francisco, regarding the possible use of OpenID-Connect/OAuth2.0 as a mechanism to deliver RATS-based device-attestation.


The meeting was attended by about 15 people, mostly from the Identity community (folks who regularly attend OAuth2.0, OIF and IWW).


From the start of the discussion, it was clear that there was some terminology mismatch between the various folks & communities.


For example, in the OAuth2.0 language the word "Client" is typically used to mean the service which is being driven by the user (e.g., to authorize access to a Resource Server (RS), which is typically also a RESTful web-based service).


However, in RATS and TCG language, the "Client" often means the hardware device (in the possession of a user) which will generate evidence regarding the composition (hardware, firmware, software) of the device.


Some folks also mentioned interesting use-cases that the RATS community perhaps have not previously considered. For example, prior to connecting to the RS it is possible that the OAuth2.0 Client (e.g., hosted by a provider) may seek device-attestations from RS machine itself (and vice versa).


All in all, we believe that a productive next step would be a discussion on the RATS mail-list regarding common Terminology, something that is meaningful to the RATS community as well as the broader IETF community.


There are 3 I-Ds that are in early stages that seem to be describing aspects of a comprehensive approach to attestation for identity infrastructures:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSbcXGWAaw$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSbcXGWAaw$> ,
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSZroxM0bQ$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tschofenig-oauth-attested-dclient-reg/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSZroxM0bQ$> ,
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sh-rats-oidcatt/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSZOfS7UfQ$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-sh-rats-oidcatt/__;!!FrPt2g6CO4Wadw!NnwooY8NaoY0bnR0dJsNZS1hv_XY7Ye5vraIb7WP-UvCNcshWwEpBTfhpBOiZAR8ZY0PcIQYSG0BUc5KLSZOfS7UfQ$>
Referring to these drafts for context (and possible disagreement) may help with the conversation.


I’m cross posting to several working groups, but the discussion thread will be exclusive to the RATS WG ([e-mail] <mailto:[e-mail]><mailto:[e-mail] <mailto:[e-mail]>>).


Best
Ned & Thomas


________________________________




The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.