Subject: Re: [Rats] RATS rechartering poll - sidebar on charter wording related to identity

From: "Smith, Ned" <[email-masked]>
Date: Fri, 4 Mar 2022 22:41:52 +0000

There are only two occurrences of the word ‘identity’ in the proposed charter text. One citing FIDO the other copied here in [1]. This text differs from the text Laurence provided in [2]. [1] and [2] say different things. I don’t believe it is the intent of the charter that only RATS WG is allowed to define standards for how system component identity information can flow to the RP. I didn’t read that into the charter text.

Additionally, the text in [1] doesn’t imply conveyance of evidence would not be authenticated. The security objective is in the program of work item #5 and is clarified further in the architecture I-D. The use of “securely” in PoW#5 can be read from the perspective of both endpoints which would include privacy concerns either endpoint might have. I don’t think it was anybody’s intent that by not mentioning privacy, that addressing privacy would be out of scope for the WG.

I’m not sure I see where there is a gap in the charter text related to the change in scope. Unless that can be clearly pointed out, I don’t see the need to reset the timeline for rechartering.

The current plan is to close discussion on Wednesday (March 9th).

Thanks,
-Ned

[1] “To improve the confidence in a system component's trustworthiness, a relying party may require evidence about:
- system component identity,”
[2] “Device/attester identity won’t always go to the RP,  but when it does, there should be a RATS standard for it.”

From: Laurence Lundblade <[email-masked]>
Date: Friday, March 4, 2022 at 10:46 AM
To: Thomas Fossati <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>
Subject: Re: [Rats] RATS rechartering poll

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]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>> wrote:

Hi Laurence,

On Sun, Feb 27, 2022 at 11:21 PM Laurence Lundblade
<[email-masked]<mailto:[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 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.

[...]
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?

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

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

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 5 Mar 2022 11:10:37 -0800

Hi Ned,

The changes I’ve proposed are in a PR <https://github.com/ietf-rats/charter/pull/13> here. 

I think the most important change is to drop the word “third” in the description of Verifier. This is important because that word strongly indicates the RP must be separate from the Verifier and that is highly incorrect. I believe Thomas agreed to this change. 

I have also asked for the addition of  "provide authenticated claims about the peer and”. That is to be clear that data other than base trustworthiness can go to the RP. I guess to some degree this is strong implied by the bulleted list later on, but it would also be nice to be explicit in the first paragraph. I think this is important to resolve now and in the charter because it seems to me there is opposition to this.

I also proposed some wording improvements.

I wasn’t actually proposing this text for the charter.

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

I also chose those words carefully so as to not assert exclusivity.  It says is that RATS should develop at least one standard for identity, but not to the exclusion of other formats or standards.

LL

> On Mar 4, 2022, at 2:41 PM, Smith, Ned <[email-masked]> wrote:
> 
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Thomas Fossati <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Smith, Ned" <[email-masked] <mailto:[email-masked]>>
>> On Mar 2, 2022, at 11:26 PM, Laurence Lundblade <[email-masked] <mailto:[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>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 7 Mar 2022 09:55:40 +0100

Hi Laurence & Ned,
greetings fellow rodent enthusiasts,

I'd like to highlight explicitly here that I agree with Thomas' replies:

> https://mailarchive.ietf.org/arch/msg/rats/ErjZPisukFnsZIfpgmPlpNQF1QY

and

> https://mailarchive.ietf.org/arch/msg/rats/9jgZsL5wAlUz-TnG5aoVCxU2qF4

Specifically I'd like to support:

* the notion that a Verifier is an mandatory intermediate role that most 
certainly can be collapsed into a single entity together with a Relying 
Party role. The current text in now way precludes that scenario and it 
is definitely not exclusive to FIDO as it is commonly used in TCG space 
for literally more than one decades and

* that I am also having a hard time to follow the "[...]  all the way to 
the RP" part, correspondingly.

In essence, I share Ned's point of view that the current charter 
proposal actually does not include gaps that would require a change 
w.r.t content or scope. Admittedly, I do not like the asymmetric 
phrasing for conveyance protocols, but I also don't think it is a 
blocker for any emerging or upcoming work (at this point in time, and 
there can always be another re-chartering).

Viele Grüße,

Henk

On 04.03.22 23:41, Smith, Ned wrote:
> There are only two occurrences of the word ‘identity’ in the proposed 
> charter text. One citing FIDO the other copied here in [1]. This text 
> differs from the text Laurence provided in [2]. [1] and [2] say 
> different things. I don’t believe it is the intent of the charter that 
> only RATS WG is allowed to define standards for how system component 
> identity information can flow to the RP. I didn’t read that into the 
> charter text.
> 
> Additionally, the text in [1] doesn’t imply conveyance of evidence would 
> not be authenticated. The security objective is in the program of work 
> item #5 and is clarified further in the architecture I-D. The use of 
> “securely” in PoW#5 can be read from the perspective of both endpoints 
> which would include privacy concerns either endpoint might have. I don’t 
> think it was anybody’s intent that by not mentioning privacy, that 
> addressing privacy would be out of scope for the WG.
> 
> I’m not sure I see where there is a gap in the charter text related to 
> the change in scope. Unless that can be clearly pointed out, I don’t see 
> the need to reset the timeline for rechartering.
> 
> The current plan is to close discussion on Wednesday (March 9^th ).
> 
> Thanks,
> 
> -Ned
> 
> [1] “To improve the confidence in a system component's trustworthiness, 
> a relying party may require evidence about:
> 
> [2] “Device/attester identity won’t always go to the RP,  but when it 
> does, there should be a RATS standard for it.”
> 
> *From: *Laurence Lundblade <[email-masked]>
> *Date: *Friday, March 4, 2022 at 10:46 AM
> *To: *Thomas Fossati <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Smith, Ned" <[email-masked]>
> *Subject: *Re: [Rats] RATS rechartering poll
> 
> 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…”
> 
>     On Mar 2, 2022, at 11:26 PM, Laurence Lundblade
>     I’d like to drive a big distinction between/Verifier
>     Identity/and///Attester/Device Identity/. They are both critical,
>     but very different.
> 
>         _Verifier Identity_
> 
>         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_
> 
>           - Identification of the Attester (this is roughly equivalent
>         to identification of the verification key)
> 
>         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 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,
> 
> 
> 
>             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 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.*
> 
> 
> 
> 
> 
>             [...]
>             I think this goes far enough beyond attester’s
>             trustworthiness to warrant the additional text about
>             authenticated claims.
> 
> 
>     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
> 
>     <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
> 
> 
> [email-masked]

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 7 Mar 2022 17:25:43 +0000

(not as chair)
The fact that the RATs Architecture draft didn't interpret the charter's use of "third party" to mean that a Verifier role could not be combined with a Relying Party role seems to suggest that the current charter wording isn't mandating that these roles MUST NOT be combined. 

So while in retrospect the wording may not be ideal, it doesn't seem to be causing an issue for the architecture or any of the drafts. 

Since it doesn't directly relate to the scope change request, I'm wondering if it should be a blocker for moving forward?

-Ned

On 3/7/22, 12:56 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Laurence & Ned,

    and

    Viele Grüße,

    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Mar 2022 08:55:28 -0800

OK. Now that there is clear confirmation on how to interpret “third” (mostly ignore it) in the public record from Ned, Henk and Thomas, I’m OK with leaving that word in.

On EAT claims going to the Relying Party in Attestation Results, comments were made particularly by Ned and Henk. I provided a thorough response and proposed a clarifying change <https://github.com/ietf-rats-wg/eat/pull/171> to EAT, but haven’t heard back.

LL

> On Mar 7, 2022, at 9:25 AM, Smith, Ned <[email-masked]> wrote:
> 
> (not as chair)

It was introduced as part of this scope change, which is why I commented on it.

LL