Subject: Re: [Rats] RATS rechartering poll

From: Thomas Fossati <[email-masked]>
Date: Tue, 1 Mar 2022 12:41:14 +0000

Hi Laurence,

On Sun, Feb 27, 2022 at 11:21 PM Laurence Lundblade
<[email-masked]> wrote:
> I think providing authenticated integrity-protected device identity (make, model, serial number) all the way to the RP is part of RATS and the RATS standards should cover it in full standardized detail. (This is akin to providing a user name in authentication protocols and the server identifier in TLS).

I agree with you that identity is fundamental in trust establishment.
At the end of the day an evidence claim is a sentence of the form:
"attester says blah" and the precondition for evaluating the
trustworthiness of any such claim is to first determine the identity
of the claimant.

Also, I agree that in many cases the identity of the attester can
percolate through the attestation results to the RP where it will be
used either as an input to the local appraisal policy or passed to a
higher layer protocol.

However, the quantum of attester identity that reaches the RP depends
on the functional split between Verifier and RP.  One can envisage
situations where that quantum amounts to a simple attestation results'
claim from the Verifier that just says "attester recognised and good!"
-- maybe because of the overall privacy policy, or because the RP is
an extremely basic one, or because the RP doesn't care about the
identity details.

So, I am not sure I agree with the "[...]  all the way to the RP" part
of your sentence.  Instead, an identity that the RP needs to consider
*in all cases* is the identity of the Verifier.

It's maybe worth looking at Section 2.2 of AR4SI where all of this is
discussed in depth.

> [...]
> I think this goes far enough beyond attester’s trustworthiness to warrant the additional text about authenticated claims.

ISTM that we could achieve what you are asking (and more) by allowing
evidence to be encapsulated into (or otherwise bound to) the
authenticated attestation results, so that even in passport mode it'd
be fully visible to the RP?

> The separation is critical in the logical architecture, but in practice many implementations won’t follow it. We need to be really clear about that.

We can say what the principles are, but we can't control what
implementations do.

cheers, thanks
-- 
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2022 09:20:11 -0500

> an extremely basic one, or because the RP doesn't care about the

very well said.
I'd like RP/Verifier protocols to start with: "attester recognised and good!"
and then grow from there if justified.

Of course, the RP needs a way to corrolate the thing requesting
access/services with the Attestation Results.
For background check model, this is easy.
For passport model, it might be that the WG should specify something more
concrete and privacy preserving.
(The debates about privacy vs vaccine *passports* have hinged on exactly this
point)

    > It's maybe worth looking at Section 2.2 of AR4SI where all of this is

I'm not sure everyone knows how to expand AR4SI.
I'll do that for the list:
  draft-ietf-rats-ar4si-01
  Attestation Results for Secure Interactions

I guess I should read it.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 2 Mar 2022 18:07:52 +0000

Yes to (1) and (2) from my side as well.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]<mailto:[email-masked]>
Mobile:  +34 682 051 091
----------------------------------

On 24/02/2022, 11:37, "RATS on behalf of Jeremy O'Donoghue" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Ned.

1.       Yes

2.       2. Yes

Best regards
Jeremy

On 23/02/2022, 19:53, "RATS" <[email-masked]> wrote:

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi,

1. yes
2. yes

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]<mailto:[email-masked]>
(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434

On Wed, Feb 23, 2022 at 2:20 PM Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ned,

1. yes
2. yes

And a quick question: do the responses to Roman's statement [1]
(highlighting that some items in the related document section are "are
out of scope per the charter") that were indicating a desire for
rechartering count into the responses for Question 1.)?

Viele Grüße,

Henk

[1] https://mailarchive.ietf.org/arch/msg/rats/f7E-G5O_JuadzVVLjeGXqSBbpwo

On 23.02.22 20:10, Smith, Ned wrote:
>  1. Does the working group want to recharter now: yes / no
>
>  2. If you believe RATs should recharter, should the working group use
>     the proposed text
>     inhttps://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md<http://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md>
>     <https://github.com/ietf-rats/charter/blob/2nd-RC4/ietf-rats-charter.md>as
>     the new charter?
>
> Please respond to the above questions related to rechartering.
>
> Thanks,
>
> RATS Chairs
>
>
> _______________________________________________
> RATS mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats

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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 2 Mar 2022 23:26:28 -0800

I’d like to drive a big distinction between Verifier Identity and Attester/Device Identity. They are both critical, but very different.

Verifier Identity
This seems like common B2B TLS set up and security. IT people do this all the time.

In the protocol implementation, the Verifier Identifier is usually a DNS name. In the business arrangement between Verifier and RP there is probably a contract (which may be a click-through) that says what verification process the Verifier runs and describes what sort of security it implements and checks. This is super important, but the business agreement is out of scope for RATS.

Verifier Identity could also be implemented with JWT, CWT or EAT, in which case it might be a little different. Probably similar to how JWT’s are used for authentication.

Many of these B2B sets ups are high security. Think about the implementation of an online brokerage or bank. They are dealing with value and risk at least as attestation in many cases.

I don’t think there’s much work here for RATS to design or define here. We just need some security considerations.

Attester/Device Identity
Here we’ve got lots of work to do here (and we’ve done much of it)

This can be in several forms all of which may be in the Evidence at the same time
 - Identification by serial number (UEID/SUED in EAT)
 - Identification of OEM and model
 - Identification of the Attester (this is roughly equivalent to identification of the verification key)

There might be several Attester/Device Identities in composite devices.

Work here is getting people to understand what attestation is, how the keys work, defining formats and protocols for identity and so on. 

An RP of course must always care about Verifier Identity.

An RP may or may not care about Attester/Device Identity. It’s entirely reasonable for an RP to want only a yeah/nay for a device and it’s entirely reasonable to want all the Attester/Device Identity it can have or something in between.

The Attester/Device Identity might come from the actual attester/device in Evidence, but the Verifier might be the one to figure out it and provide it to the RP. For example, the Verifier might only receive the Attester identifier, a unique key ID, one for each device and from that figure out the serial number, OEM and model and send that on to the RP.

I’d like to see ar4si be sharp in this distinction, like separating the discussion of these two into separate sections in the document.

Comments below,

> On Mar 1, 2022, at 4:41 AM, Thomas Fossati <[email-masked]> wrote:
> 
> Hi Laurence,
> 

I looked at it and came up with the above comments.

I think we mostly agree. :-)

I certainly agree that the quantum of attester/device identity reaching the RP will vary and sometimes not go to the RP at all.

Then to clarify what I’m request — I requesting that *when attester/device identity goes to the RP* it is in a RATS standard format.

> be fully visible to the RP?

Seems like a pretty interesting idea! Will think about it!

I don’t think it covers the case where the Verifier figures out some of the device identity claims in results based on attester/device identity it got in evidence, but it still seems useful.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 3 Mar 2022 14:23:08 +0000

> From: Laurence Lundblade, March 3, 2022 2:26 AM

> The Attester/Device Identity might come from the actual attester/device in Evidence, 

> but the Verifier might be the one to figure out it and provide it to the RP. For example, 

> the Verifier might only receive the Attester identifier, a unique key ID, one for each 

> device and from that figure out the serial number, OEM and model and send that on to the RP.

> I’d like to see ar4si be sharp in this distinction, like separating the discussion of these two into separate sections in the document.

Ar4si - Table of Contents

     2.2.  Non-repudiable Identity . . . . . . . . . . . . . . . . .   6

       2.2.1.  Attester and Attesting Environment  . . . . . . . . .   7

       2.2.2.  Verifier  . . . . . . . . . . . . . . . . . . . . . .   9

       2.2.3.  Communicating Identity  . . . . . . . . . . . . . . .  10

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Mar 2022 11:39:46 -0800

> On Mar 3, 2022, at 6:23 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 

I can kind of see that distinction in what you have, but I think the text could be more clear and explicit about it.

Also, I think Communicating Identity is only about Verifier Identity so it should be merged into 2.2.3.

We probably shouldn’t be too prescriptive about how Verifier Identity is done. It could be with symmetric keys shared out of band. It could be that the Verifier and RP are so physically close and in a secured room that nothing is needed. It could be something else. And as I’ve said before, I think it is something the IT world knows how to do very well (maybe OWASP cover it?).

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 4 Mar 2022 10:46:02 -0800

There is a comment on the charter text buried in here. To re state it:

    Device/attester identity won’t always go to the RP,  but when it does, there should be a RATS standard for it.

I’m still requesting that the sending of device/attester identity and other claims to the RP be acknowledged in charter by adding “...provide authenticated claims about the peer…”

The EAT document adopted by this WG in 2019 explicitly said that all the claims went to the RP.

LL

> On Mar 2, 2022, at 11:26 PM, Laurence Lundblade <[email-masked]> wrote:
> 
>> On Mar 1, 2022, at 4:41 AM, Thomas Fossati <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Laurence,
>> 
>> <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>