Minutes IETF108: rats: Wed 11:00
minutes-108-rats-202007291100-00

RATS agenda for Wednesday 29, 2020
-------------------------------------
Chairs: Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
Notetakers: Ned Smith, Eric Voit, Thomas Fossati
Jabber/Chat: Nancy Cam-Winget

* Agenda bash (5min)

No second HUM test.

* Architecture -  Henk Birkholz(15 minutes)
        https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

     There is a large list of contributors that attend architecture team
     meetings. The list of participants has been updated to include regular
     participants. There are about 14 outstanding issues, but the list is
     getting smaller. Only a few big items remainging. Most are smaller details
     related to wording and so forth. A new Trust Model section was developed
     that members of the group are encouraged to read and comment on. Two
     larger topics still remaining:
      (1) Endorsement and Endorser role definition still seems too abstract for
      many. There is also the possibility that a next phase of the RATS charter
      could include additional details related to Endorsers and Endorsements.
      (1b) Per Laurence, Key Provisioning is something which may need to be
      covered as an adjunct to Endorsement interactions (there might be a
      loophole in the charter that allows that).
Current topics also includes time-keeping based on nonces. Hannes asks the
question "what about collection?" There is a new pull request and lots of
comments.
      (2) The hardware capabilities limit what elements of time/freshness might
      be collected or be asserted, as well as the asserted levels of
      trustworthiness.  Therefore one solution for understanding the time of
      evidence generation is not viable.
    Looking forward to WGLC in the near future.
    Dave Thaler asked a question about how timestamps and nonces might interact.
    (Dave Thaler) There are constrained devices that don't use a RT clock and
    you can still be successfully implement protocols for time synchronization.
    There are multiple ways to accomplish freshness without the architecture
    dictating a particular approach. (Henk) The question remains, "are the
    examples sufficient or do we need more?" (Dave Thaler) There are 4 examples
    now that form a classic 2X2 matrix. This should be sufficient for
    demonstration purposes. We shouldn't try to enumerate all possible way.
    (Henk) We're closing this section on freshness soon, so please provide
    feedback if any remaining cooncerns exist. (Dave) TUDA isn't on the agenda
    for IETF 108, but there is a discussion related to timing in the TUDA
    document that is referenced from the interactions draft (yesterday's
    meeting). Dave believes it doesn't make sense for drafts to reference other
    documents that are not adopted drafts. (Nancy) There was an IPR issued
    against the architecture by Huawei. It isn't clear if the IPR relates to
    the entire draft or just a part of it. (Wei) The IPR is about the composite
    device section, rather than the document as a whole. (Nancy) Can you please
    work the issue so that is it clarified in the IPR record.

* EAT: Attestation Keys taxonomy - Laurence Lundblade (20min)
        https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
(Laurence Lundblade) Prested slides showing Primary Trust Flow. Diagrams shows
who trusts who, how and why. Solid arrows are a more direct trust. Dotted
arrows are indirect trust. Verifiers have to trust manufacturer(s) because that
is where they obtain Endorsements. Relying Party is "told" by the Verifier
whether or not they trust the manufacturers. This is a transitive trust
condition. There is a secondary trust flow that has more to do with privacy and
PII. If the trust flow doesn't work then attestation doesn't work. (Nancy) When
you say "manufacturer" it doesn't have to be only a manufacturer, right?
(Laurence) The architecture uses "Endorser" but Laurence feels this term is
unclear still. It isn't a term used in IoT community. (Rich Saltz) suggests the
term "provider" (Laurence) Shows a diagram illustrating Endorsement materials
such as known-good-values, signing keys and verification keys. Attester must
have a secret (key) or something that allows it to prove that it is who it says
it is (otherwise known as authentication). (Dave Thaler) Does "signing keys"
refers to private keys that are used to sign Evidence? If so, it may not always
be the case that a manufacturer provisions keys. Private keys may originate
within the Attester (Laurence agrees). (Laurence) The point of attestation is
there has to be keying material. Laurence shows a slide about a taxonomy of
Verifier and Manufactuerer (Endorser) use of keys. Low cost devices cannot
afford to maintain the asymmetric key material, which motivates the use of
symmetric keys. An axis of the taxonomy involves two aspects: (1) Infrequent
interactions (2) Per-verification (frequent interactions) Laurence displays a
2X3 matrix showing behavior specific to public keys, symmetric keys and
verification services. (Dave Thaler - from chat window) Attesters can be
layered or composite in which case there are multiple such entities in general
Note: the aforementioned clarification is top right of this slide04 Nothing in
this slide is really specific to RATS right? The same slide could be used for
any use of keys between two entities (given that "manufacturer" is already an
ambiguous term). (Laurence) The point of symmetric key attestation is cost.
Constrained devices use symmetric keys and therefore symmetric key
considerations should be part of RATS efforts. (Dave Thaler) Since
'manufacturer' could mean lots of things the slide doesn't have to be specific
to RATS. This could be part of a general security area document that can be
referenced by multiple working groups. (Russ Housley) If we were to build such
a document, there are security considerations that need to be addressed. The
taxonomy is great. (Nancy) These slides could be presented in other forums as
well. (Laurence) Presents one more slide in the interest of time that drills
down on verification key taxonomy. Laurence solicits input on this topic.
(Nancy) Suggests a side meeting might be appropriate for next steps.

* Trusted Path Routing – Eric Voit (10min)
        https://datatracker.ietf.org/doc/draft-voit-rats-trustworthy-path-routing/

(Eric Voit) Expands on the RATS interim presented topic on trusted path routing.
The objective of trusted path routing was presented. Followed by a document
roadmap relating several other drafts. This I-D includes trustworthiness
'levels' that defines a range of integrity levels having to do with hardware,
unique identity, boot integrity, filesystem integrity. Question to the group
"Do we want to work in definition of level in RATS?" (Kathleen) Definitions
could be done by another "entity" or group, similar to what is done with
policies in PKI. (Eric) There is a lot of potential for follow on work. (Eric)
An example related to boot integrity was presented. These results are given to
the router for inclusion in a routing fabric that implements attestation
protocol that is topology based. Next steps: (1) Does the WG want to
standardize attestation result formats? (2) Definition of EAP payload? (3) Is
there interest in adoption? Questions? (Russ) When you talk about routing
protocols, what is the potential support for routing protocols? (Eric) We can
support both IGP and BGP. (Dave Thaler) I don't know if I understand the
trustworthiness vectors, but in TPR then the granularity is in terms of the
'trust layers' that might make sense for TPR but outside of this context, it
might be difficult due to variability and heterogenaity concerns. (Eric) This
is a legitimate concern.   The specific claims at a high level might look the
same.  In specifics we don't know if they are generalizable.  (e.g., multiple
line cards.) (Nancy) You don't see this draft adopted in RATS? (Eric) It could
be adopted here if it makes sense, I don't know where else that here for
routers based on the dependent drafts (e.g., charra) (Dave) The TPR draft
belongs in RATS but doesn't feel strongly about it. (Nancy) We're 8 min over
time. Solicits feedback for interest for adoption.

* SUIT/TEEP Evidence and attestation claims – Henk Birkholz  (10min)
        https://datatracker.ietf.org/doc/draft-birkholz-rats-suit-claims/

(Henk) "Trustworthiness Vectors" term was taken from Eric's draft (Trustworthy
Path Routing) with the goal of applying it to TEEP interactions The
consideration that RATS Attester might process a SUIT manifest. SUIT manifests
can be used to process remediation procedures. Trustworthiness levels apply to
system properties claims. EAT claims are somewhat specializations or
generalizations of SUIT claims. Maybe there should be a mapping exercise
performed? "Trustworthiness Vectors" conceptually simplifies the set of
properties that are evaluated / appraised reducing the load on Verifiers.
(Laurence) The reason Verifiers and Relying Parties are distinct is because
they perform different roles. (Brendan Moran) Verifiers can't be fully
eliminated (RP can understand claims about system properties itself, but it'd
need a verifier to interpret more complex semantics - e.g., coming from SUIT
command evaluations) but there seems to be ways that SUIT can simplify things.
(Henk) There are other domains outside of routing that make sense for defining
'trust levels' (Dave Thaler) In the context of SUIT, "trust" may be the wrong
term. Some factors aren't specific to trustworthiness. (Henk) Only 10 min
remaining, but there are aspects that are related to trustworthiness state
transitions. Updates are a remediation procedure, but remediation relates to
trust. (Nancy) Called a close to this presentation.

* Unprotected CWT Claims  – Henk Birkholz (10min)
        https://datatracker.ietf.org/doc/draft-birkholz-rats-uccs/
UCCS was recapped by Henk
If a signature over Claims is omitted there needs to be a way to protect the
Claims equivalently. In a RATS scope there needs to be a context for how UCCS
Claims are protected. This may involve defining the characteristics of the
Secure Channel (presumably this is the replacement for an ommitted signature).
There is ongoing discussion on UCCS - looking for input generally from the
working group. (Laurence) Security considerations for UCCS in the RATS context
should be included in the RATS security considerations. (Henk) we pulled the
security considerations in the UCCS draft as we want to have an understanding
of how to frame this work. (Laurence) UCCS is used in multiple other places,
each needs to have context sensitive security considerations. This can
snowball. (Henk) what would happen if we don't include that, that'd be a
disaster. (Kathleen) Who have read the draft? (5 people) (Kathleen) Others
willing to read the draft? (2 people: Russ, Jessica, Kathleen (but chairs don't
count)) (Kathleen) Are we ready for WG adoption? Comment in chat if you think
it's ready. (all yes) (Kathleen) Will take steps to recommend for adoption.

* RESTful attested Resources – Thomas Fossati (15min)
        https://datatracker.ietf.org/doc/draft-shaw-rats-rear/

(Thomas) Goal - Present the main ideas in I-D useful to those interested in
building a RATS toolbox. Use case: Dam - Water level sensor, Spillway sensor,
Spillway gate
    Verifier appraises attestation from the sensors.
Attested Resource - contains a resource representation, Evidence about the
hosting platform security state and Freshness indicator. Interaction Model - A
compund data format needed to pull together resource state, attestation data
and freshness RESTful Attested Resources - A 'basic' RESTful interface is used
to access attested resources. Uses CoAP and HTTP transports. Optional discovery
based on CoRD(?) Implementation Model - Diagram showing REST Clieent<-->REST
Front-end<-->TEE-back-end Mixing Function - Defines the fundamental security
guarantee. Prevents attackers from spicing malicious assertions. Mix(n, r, t) =
H($n || $r || $t) --> E.nonce (Dave Thaler) Why the nonce rather than a
separate claim? (Thomas) This needs more discussion. A separate claim might be
reasonable. (Nancy) Notes that a separate claim might be better. Attester
Interface - diagram showing a challenge - response protocol. Compositions
Examples - diagram showing the background-check model with nonce and using the
Mixing Function. An example of the REST messages was displayed. The passport
model with timestamp was discussed briefly and REST messages displayed.
Discovery example using REST messages was displayed. Questions: (1) Is there
interest in this? (2) Should we go forward? (Nancy) Please take to the mail list

* Milestones – Chairs (15min)

(Nancy) Milestones need to be updated.
Given there are more drafts lets first update the currently recognized drafts
then we can look at additional drafts Adopted Drafts: EAT, Arch, and Charra Are
we ready for WGLC next month for Charra? (Henk) Yes we can do that but will be
ambitious (Nancy) Will we be ready for publication in Dec? (Henk) Make it
september (for WGLC) (Nancy) Target March for publication then? (Yes)
Interaction Models - Call for adoption needed. Token Bind - to be removed. EAT
- WGLC is needed before it can be submitted for publication. (Nancy) Is it
ready? (for WGLC) (Laurence) It has a way to go still. (several topics
mentioned that needs work) (Nancy) We need to make progress. Should we target
WGLC in Dec? (Laurence) Seems reasonable. (Nancy) Targeting IESG submission in
6 months (Nancy) We haven't mentioned TUDA recently, what is the status? (Henk)
Interaction model should go first because other I-Ds depend on it. (Nancy)
Can't to a call for adoption since it hasn't been presented recently. (Dave)
One can argue that TUDA is a type of interaction model. Remove the TUDA draft
and adopt it as yet another interaction model. Proposing to merge into
interaction models. (Henk) That would be too disruptive at this point. (Nancy)
We need a WGLC for architecture draft. Are there remaining issues that prevents
WGLC? (Henk) End of Sep should be the new focus. (Nancy) We're not opposed to
doing multiple WGLC if that helps shake out the issues. (Nancy) Targeting March
for IESG submission. (Nancy) RIV I-D is already adopted. When will WGLC be
appropriate? (Guy) End of August. (Nancy) Haven't seen much by way of comments
on the list. (Kathleen) Time check (Guy) Assume 'yes' unless other issues exist
(Nancy) Post to mail list intent for adoption. (Nancy) We'd like to hold 2
interim meeting between now and sept. We'll use doodle poll to find a date.

Meeting closed at 12:52 UTC