RATS at IETF 116
27 March 9:30
Note Takers: Pieter Kasselman, Rich Salz
Attendees: 52 (online count)
(5 min) WG Chairs - Nancy Cam-Winget, Kathleen Moriarty, Ned Smith
David Thaler: If grouping technology, putting CoRIM vs EAT should be
near Concise RIM, but if group WG docs first, this is fine. Some
discussion, left as-is.
(10 min) Thomas Fossati
Defines media-types for different EAT token encodings
Two open issues
(15 min) Thomas Fossati
01 version added (1) tags (reserved a space of tags as "earmarked",
which is a compromise) and (2) conditional endorsements
Two PRs in flight
(10 min) Henk Birkholz
DAA a 15 year old solution, adds privacy features/anonmous operation
Long discussion on previous blocking issue: how to put DAA protocols
into RATS architecture; insight (from Thomas) was that this is a
protocol that lets "things" take on some of the RATS entities.
Next Steps - Asking WGLC. Nancy will issue last-call
(10 min) Thomas Fossati
Encapsulation format for RATS conceptual messages. Use-cases include TLS
auth credentials, include evidence about certs/crl's, etc (DICE),
archiving attestation results as files, transport in APIs.
Allows multiple protocols to tunnel attestation data and pass it around
without unwrap/process/rewrap steps.
May add secion for registration
Since London editorial fixes/updates and using latest cbor/cddl
features.
Cross- working group and SDDO discussions
Want call for adoption. Expect to be done by July, but depends on TCG
timelines.
Russ: Schedule not reasonable, LAMPS having a big discussion on it.
Currently last agenda item so might not happen at this IETF.
Nancy: RATS is referencing LAMPS draft
Both were confused by last bullet on page 9 of the slide set.
Thomas: It is the other way round (LAMPS references RATS inderictly via
TCG)
Nancy: Will request clarification during adoption call to make sure all
agree about the dependency chain within the docs.
(15 min) Dave Thaler
Original charter did not allow for endorsements, recharter now allows it
Draft outlines what endorsements are; "current state" is not the same as
"desired/required/needed-for-verification" state.
Endorsements are "current state" (e.g. state of hardware at time of
manufacture)
Appraisal policy defines comparison rules between reference and current
state
What endorsements formats (plenty in industry already)?
Coparison rules are the simplest if all "current state" use same format,
same for "reference state". Less risk of things going wrong (security
concerns with increased complexity, such as using different formats).
Security: Use CoRIM or EAT, but be consistent for "current state" and
"reference state". Question for Working Group, which one to recommend?
Footprint: e.g. what if you want to use it on a Cortex M? How many
parser do you need in a constrained node?
Is there a defintiion of internal verifuer? Dave - yes
Thomas: we did discuss this in CoRIM. Note-taker: not sure of what
issues/conclusions, if any, they had reached
Henk: CoRIM goal is to reduce complexity for big verifiers, for small
verifiers agrre with Dave (should be consistent and avoid multiple
formats for verifiers)
Andrew Draper: Already have multi-format evidence protocols, verifiers
already have to deal with this, so should make it easy to have safe
transformations.
Dave to make an update, and then will ask for WG adoption.
(10 min) Giri Mandyam
Attested geo-location provides "evidence" of security state
See FIRA consortium for some background on location. It is productized,
conveyed via geodetic coordinates (WGS-84).
Secure ranging detects relative location of device (car keys,
point-of-sale under development)
Proximate location is different from geolocation attestation
Projected location
planar projection may be sufficient (small distance between device)
Secure ranging reader determines target device location and makes
projection
* needs to identify the device (out-of band protocol like Bluetooth)
What is the trust relationship betwwen decice and reader. Answer - a
shared key derived from trusted element
Henk: Need is for a new claim? What is the problem with the
architecture? There is no concept of distance between attesting
device and attested device. Conversation to continue offline and
maybe during open mic time.
(20 min) Henk Birkholz
EpochIDs a mechanism to determine freshness of messages (like nonce, but
used by multiple parties - terminolofy work-in-progress)
Conveyance of Epoch Bells is what is being introduced.
Draft includes seven types o Epoch Markers, Bell veracity proofs
Next Steps: Working Group Call for Adoption?
Ned: If we define role for bell ringer and we use a nonce, do we still
need this new role?
Dave: Support going to WG Adoption, with terminology changes (Nonce is
confusing)
Nancy: Can go to adoption call, with changes
(10 min) Thomas Fossati
Prototypes two use cases:
(15 min)
Laurence: Question about endorsements - doesn't an endorsement have a
public key to verify the signature on the claims?
Dave: Happy to add that. Same as for evidence. All should be signed by a
key. Endorser has key and signs claims
Michael Richardson: Want to have conversation at the COSE working group
about mediatype registration (+cwt compared to +cbor+cose)
Thomas: Can have conversation on COSE mailing list. Haven't heard from
them.
Thomas: Suggest differnece between endorsed identities vs status
Henk: Public key in an endorsement is an identity document. There is
more to endorsement than that.
Laurence: Endorsements is more than a key securing a message. Should
carry implications or informationabout level of trust from the evidence.
Lot's of implications from an endorsement, More than range values to
check against.
Andrew Draper: May need different levels of information/endorsement
Dave: Can build out the concept of endorsement, happy to discuss and
explore further
Andrew: Endorsements are conditional on device properties, would be
interested in discussing with Dave.
Ned: Question for Dave - is there a repo for discussion? Yes. Will post
link, but once adopted will move to WG repo.
Giri: Is TCG looking at EAT?
Ned: Short answer is yes; if there's a need to put an unsigned eat token
in a cert, there would be a way to do that using a CMW cert extension.
Dave: added github repository to datatracker document page. Editorial
note: do this for all drafts :)
Thomas: Question for chairs on progress of EAT - timeline wise, what are
the next steps
Roman: AD review completed, wrking group to review and resolve
Giri: Was expecting IANA review, and havent seen further reviews. is AD
review gating it.
Roman: After AD review, goes for IETF last call. Director reviews (by
statute - GenArt etc). IANA takes a look as well at thispoint. IESG
review after that
Laurence: Thanks for thorough review. Next draft is a few weeks out.
Roman: If there are specific concenrs with IANA, we can discuss.
Session closed