Re: [Rats] Hint for a Verifier ... was AW: I-D Action: draft-ietf-rats-msg-wrap-01.txt

["Tschofenig, Hannes" <[e-mail]>]

Hi Tom,

of course, the Relying Party has to trust the Verifier directly or indirectly. I am thinking about a model that is similar to what we have today with network access authentication.
When the supplication (device) sends the Network Access Identifier (NAI) it is, at this point, also “unprotected”. This initial message with the NAI is routed to the home AAA server and then the authentication procedure begins. In that model there is also a chain of trust between the NAS, the local AAA server and the home AAA server.

I guess this topic deserves a bit longer explanation.

Ciao
Hannes

Von: Tom Jones <[e-mail]>
Gesendet: Dienstag, 2. Januar 2024 18:45
An: Tschofenig, Hannes (T CST SEA-DE) <[e-mail]>
Cc: Thomas Fossati <[e-mail]>; [e-mail]
Betreff: Re: [Rats] Hint for a Verifier ... was AW: I-D Action: draft-ietf-rats-msg-wrap-01.txt

attacks against the system would then be trivial.
The attestor would insert itself (disguised of course) in as the verifier.
How would the RP know that the whole thing wasn't bogus from start to finish?
Be the change you want to see in the world ..tom


On Tue, Jan 2, 2024 at 7:40 AM Tschofenig, Hannes <hannes.tschofenig=[e-mail]<mailto:[e-mail]>> wrote:
Hi Thomas, Hi all,

I believe there is a need to add functionality for helping replying parties to locate Verifiers.
This is a topic that recently surfaced in the LAMPS Attestation Design Team and is documented here:
https://github.com/lamps-wg/csr-attestation/issues/70

The issue is the following: As a design principle, we want the relying party to be agnostic of the attestation technology (and the encoding of the Evidence format). Instead, the Verifier and the Attester have to understand the attestation technologies.

In simple deployments, a relying party just relays the Evidence to a Verifier. In more complex deployments, there are most likely multiple Verifiers and the relying party needs to decide where to send the Evidence.

As described in the above-referenced issue, the suggestion is to include additional information about what the attester believes the correct Verifier is. This is a hint to the relying party. This information would be included in the Evidence, at least if it is based on something like an EAT, but since the relying party is not expected to parse the Evidence, it would be replicated into a "wrapper" outside -- for example into the CMW.

I am wondering what others think.

Ciao
Hannes


-----Ursprüngliche Nachricht-----
Von: RATS <[e-mail]<mailto:[e-mail]>> Im Auftrag von Thomas Fossati
Gesendet: Donnerstag, 21. Dezember 2023 10:41
An: [e-mail]<mailto:[e-mail]>
Betreff: Re: [Rats] I-D Action: draft-ietf-rats-msg-wrap-01.txt

Hi,

In this freshly published -01, we added a "CMW collection" modelled on Simon's "EAT collections" [1].  The main driver for this is supporting composite/layered attesters.

The other added bit is the media types registration.

See the "diff" link below for the details.

cheers!

[1] https://datatracker.ietf.org/doc/draft-frost-rats-eat-collection/


On Thu, 21 Dec 2023 at 10:28, <[e-mail]<mailto:[e-mail]>> wrote:
>
> Internet-Draft draft-ietf-rats-msg-wrap-01.txt is now available. It is
> a work item of the Remote ATtestation ProcedureS (RATS) WG of the IETF.
>
>    Title:   RATS Conceptual Messages Wrapper
>    Authors: Henk Birkholz
>             Ned Smith
>             Thomas Fossati
>             Hannes Tschofenig
>    Name:    draft-ietf-rats-msg-wrap-01.txt
>    Pages:   20
>    Dates:   2023-12-21
>
> Abstract:
>
>    This document defines two encapsulation formats for RATS conceptual
>    messages (i.e., evidence, attestation results, endorsements and
>    reference values.)
>
>    The first format uses a CBOR or JSON array with two mandatory
>    members, one for the type, another for the value, and a third
>    optional member complementing the type field that says which kind of
>    conceptual message(s) are carried in the value.  The other format
>    wraps the value in a CBOR byte string and prepends a CBOR tag to
>    convey the type information.
>
>    This document also defines a corresponding CBOR tag, as well as JSON
>    Web Tokens (JWT) and CBOR Web Tokens (CWT) claims.  These allow
>    embedding the wrapped conceptual messages into CBOR-based protocols
>    and web APIs, respectively.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://data/
> tracker.ietf.org<http://tracker.ietf.org/>%2Fdoc%2Fdraft-ietf-rats-msg-wrap%2F&data=05%7C02%7Cha
> nnes.tschofenig%40siemens.com<http://40siemens.com/>%7C0bc7d290475f43a8184408dc02091811%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638387485278246935%7CUnknown%7
> CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000%7C%7C%7C&sdata=YbdIy5tz4qp1bAbJAJ6YHA7L75WU9m2us0t5u7
> lOTYY%3D&reserved=0
>
> There is also an HTML version available at:
> https://www/.
> ietf.org<http://ietf.org/>%2Farchive%2Fid%2Fdraft-ietf-rats-msg-wrap-01.html&data=05%7C0
> 2%7Channes.tschofenig%40siemens.com<http://40siemens.com/>%7C0bc7d290475f43a8184408dc02091811
> %7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638387485278246935%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw
> iLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bfQvm7mbwh6z%2FEpc77aotMhV73bZPV
> UUjIZ%2Ffzm6A5M%3D&reserved=0
>
> A diff from the previous version is available at:
> https://auth/
> or-tools.ietf.org<http://or-tools.ietf.org/>%2Fiddiff%3Furl2%3Ddraft-ietf-rats-msg-wrap-01&data=0
> 5%7C02%7Channes.tschofenig%40siemens.com<http://40siemens.com/>%7C0bc7d290475f43a8184408dc020
> 91811%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638387485278246935%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yRX8Lk2XLU4su3FmNClI16qTBwh
> sDt4qRV5xt54gf8E%3D&reserved=0
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]<mailto:[e-mail]>
> https://www/.
> ietf.org<http://ietf.org/>%2Fmailman%2Flistinfo%2Frats&data=05%7C02%7Channes.tschofenig%
> 40siemens.com<http://40siemens.com/>%7C0bc7d290475f43a8184408dc02091811%7C38ae3bcd95794fd4add
> ab42e1495d55a%7C1%7C0%7C638387485278403181%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> %7C%7C%7C&sdata=uiTcw1o8zlIvXplSg0GbuE5UwDE%2FwriHBEP9WpU%2BAo4%3D&res
> erved=0

_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats