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

From: "Stuart William Card" <[email-masked]>
Date: Mon, 7 Mar 2022 12:39:29 -0500

We make the following definitions in the DRIP architecture draft  at
https://datatracker.ietf.org/doc/draft-ietf-drip-arch/

   Claims:

      A claim in DRIP is a predicate (e.g., "X is Y", "X has property
      Y", and most importantly "X owns Y" or "X is owned by Y").

   Assertions:

      An assertion in DRIP is a set of claims.  This definition is
      borrowed from JWT [RFC7519] and CWT [RFC8392].

   Attestations:

      An attestation in DRIP is a signed assertion.  The signer may be
      the claimant or a related party with stake in the assertion(s).
      Under DRIP this is normally used when an entity asserts a
      relationship with another entity, along with other information,
      and the asserting entity signs the assertion, thereby making it an
      attestation.

   Certificates:

      A certificate in DRIP is an attestation, strictly over identity
      information, signed by a third party.  This third party should be
      one with no stake in the attestation(s) over which it is signing.

So we don't take a position on whether the signer must be a third party,
but we do distinguish the case where it is (certificate) from where it is
not (attestation). This might allow policy to come into play. I don't know
whether this is useful in the context of your current RATS discussion.

> (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,
>     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:
>     >
>     > - 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
>     >     <https://www.ietf.org/mailman/listinfo/rats>
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > RATS mailing list
>     > [email-masked]
>     > https://www.ietf.org/mailman/listinfo/rats
>
>     _______________________________________________
>     RATS mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/rats
>
>

-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<[email-masked]>