Minutes IETF106: rats
minutes-106-rats-00

Meeting Minutes Remote ATtestation ProcedureS (rats) WG
Title Minutes IETF106: rats
State Active
Other versions plain text
Last updated 2019-12-03

Meeting Minutes
minutes-106-rats

   Remote Attestation Procedures (RATS)
IETF 106 - Singapore (2 sessions)
Chairs: Nancy Cam-Windget, Kathleen Moriarty and Ned Smith
Note: Kathleen and Ned will be remote, so please ensure they receive slides to
upload and other administrative tasks that can be easily accomplished from
afar. FRIDAY NOTES BELOW.

Chair: Nancy Cam-winget

Note Takers: Peter Yee, Michael Richardson, Liang Xia, Wei Pan
Jabber Scribe: Jaime

15:20-16:50        Tuesday Afternoon session II (90 minutes)
Room: VIP A

EAT Claims Discussion, Laurence Lundblade (30 minutes)
 o Software Inventory claims
 o Measurement and integrity claims
 o Public key claims

15:23 Laurence presenting.

Support for CoSWID was expressed at the MIC.
Henk: some questions and then a hum.
Hannes: public key claim.  I believe that this already exists.  Was specified
in CWT and JWT. LL: proof of possession is not there and the Android claims are
not there (yet).

Henk: there is a format for RPK for DTLS
(https://tools.ietf.org/html/rfc7250#section-3) this is a MUST for the RPK
format.

Q: Does the group believe we should work to define Claims for Attestation
Results. Yes Hum: some people. No Hum: complete silence.

Q: Should we work on public key claim like proof of possession (PoP) and
GIRI: FIDO has a concept of Credential ID.
LL: we should refine this proposal and work on it another time.
Hannes: ACE has some PoP work.

Q: Does the group want to work on claims about software inventory
Yes Hum: moderate + some in jabber.
No Hum: nobody
Don't care: a few

Q: Does the group want to work on measurement/integrity claims
Yes Hum: silence, but 4 in jabber   [not sure the minutes need to identify the
people, as we don't identify hummers] No Hum: silence Don't care: some people

EAT Open Issues for discussion, Laurence Lundblade (50 minutes)
 o Detailed overview and discussion on submods and nesting.
 o OEMID Clarifications
 o UEID size
 o cti, jti and nonce
 o Claim optionality
 o Claim characteristics PR. Relates too above.
 o Boot state / debug as levels, not Booleans

Chair: Is there an issue on Github related to the OEMID PR?
LL: May not. Text before was incomplete, so I create a PR.
Henk: Question about encoding. Using CBOR for compactnees is fine. Dashes and
HEX values in Jason with base64 or base64 URL isn't fine. LL: It's common to
express MAC addresses in this form. We can discuss more on the mailing list.

Henk: The debug states isn't independent, it's platform specific. There should
be an indication about what platform this is for. LL: Try to make it general
and not platform specific. Henk: What does 'debug' mean? LL: It means whether
some debug facilities are truned on or not. Henk: So 'some' has to be defined
as platform specific. This is still platform-specific. LL: Read the context in
the draft. Ned: 1) Is the secure-boot moved out of the draft? 2) It deponds on
the uses cases as how useful the debug status are. LL: Vendors can always have
prefered proprietary claims. DaveThaler: Change 'boot' to 'start', then it'wll
be applicable to more scenarios, such as SGX Enclaves Giri: the states need to
be split across Chip OEM (e.g. Qualcomm) vs Device OEM (e.g. Phone). Can add a
lable into the claim to indicate which OEM owns these debug status? LL: OK.
Chris (not sure): It's better to add an 'unknown' state. Stephen: Agree with
Chris. LL: Will discuss more on the mailing list.

Dave: The submodules match my needs. Can all the 3 submodules be claims?
LL: The submods contain the claims. The name of the submod isn't a claim.
Henk: They may be covered by the attestation provenance concept in the
architecture. Signed submods are more complicated. Ned: It's unclear to me that
what is the attesting environment and what is the attested environment. Chair:
Do you mean to augment to diagram about who's doing the attesting? Ned: The
attesting environment has some special ability to observer the attested
environment, so it can make these claims legitimate. I don't get the use case
for the linkage for things that sign other things. Dave: This picture didn't
show the attesting vs. the attested environment. I agree with Henk that this
should be discussed in the architecture document.

# Security Considerations
Henk: It's an assumption that the attester knows which parties are there will
be able to appraise the evidence and it isn't always true. Giri: I think it's
reasonable, but the nonce needs to have some providence. Henk: This can be
remediated by the attester giving a hint, and the verifier will assess the
hint. Ned: Is it a case that the Verifier of submod A would provide its nonce
to the top-level Verifier who would forward it to the attester. Giri: Not
necessarily. Dave: The bottom case is complex. It may be suitable for the use
case draft to consider. Frank Xia: Agree with Dave. It's an use case. Giri:
There's transport security issues to be considered. Frank Xia: It's not a
typical remote attestation security consideration. Dave: For the simple case
that has EAT and EAT, are you assuming that nonce on the left is the same as
the nonce on the right? Giri: The nonces can be different. Dave: Then the
attester only talks to the top-level Verifier because that's the only nonce
that it needs to include. Henk: There could be multiple remote attestation
servers, and the attester needs to know this, then the nonce create is viable.
Otherwise there has to be a distribution system.

New Drafts:
Explanation to contrast this proposal with EAT, Giri Mandyam (5 minutes)
    https://tools.ietf.org/id/draft-mandyam-rats-qwestoken-00.txt

Henk: For the PKHash, I assume the evidence comes with the hash of the public
key, and then you need to go back to the Asserter to resolve the hash and
validate the religion provenance of the evidence. Right? Giri: Yes. If the
private keys of a device got lost, I need to provision a new public key to this
device, then I can query the PKHash to know which device is using the old
public key. Henk: Why isn't the hash also been destroyed? Giri: If the device
updateds its public key store. Henk: The Asserter retains a secret key
derivation function to reconstruct everything, and then this would be possible.
Giri: It's usually a standard hash, like SHA-256. Henk: For every device, hash
index is maintained by the asserter. LL: This public key has nothing to do with
verifying attestations, this key is only used to verify the software that
you're going to run. The software producer has the private key and the device
running this software has the public key, so the device can verify the
software. Henk: It's implicit attestation by origination. LL: It's not even
attestation. Sometimes it's a stand-in for an OEM ID because the OEM has to
have the private key otherwise they can't sign the software.

Chair: Is your intent to bring your draft as a potential profile?
Giri: Yes. I want to resolve these questions whether some of these claims
belong to EAT draft or profile draft. Chair: Make this clarification when you
pose it. Giri: File an issue or put it on the mailing list? Chair: Issus is
more formal.

Henk: About the 'Context', might that be related to the audience tag and CWT?
Giri: It could be related to the audience tech. The entity usage of the token
would be implict in the audience tag. Chair: Discuss more on the mailing list.

==========

10:00-12:00        Friday Morning session I (120 minutes)
Room: Orchard

Friday Nov 22, 2019
Chairs: Nancy Cam-Winget
Kathleen Moriarty (Remote)
Ned Smith (Remote)

Note Takers: Liang Xia, Peter Yee (offline), Wei Pan

#Security Considerations for RIV draft, Guy/Jess (20 minutes - remote)
2 minutes comments and then discussing the intention of the draft for RATS
Michael: IDevID and LDevID issues, maybe need a specific terminology for RATS
instead of just using IDevID and LDevID. Certificate chain relation needs more
clarifications. Guy: explain the process of manufacturing routers with TPM of
Juniper. Laurence: all is talking about integrity check of the booting stage,
not running time, and other evidence that can be attested? Guy: yes, this
document is not intended for those parts, which is a gray area.

Chairs: Ask the authors about the intention of this draft? adopted as a WG item?
Guy: Can be an informational draft to describe the process of RA for routers.
Chairs: your draft may be the use cases or part of the architecture.
Considering to merge into use cases or architecture draft? AD: clarify the role
of use cases draft.

Michael: can be a specific RATS profile with some specific claims and
mechanisms. It depends on architecture progress. Dave: I don't have enough
information to choose from yet. If no normative things contained then it suits
for use cases draft. Architecture draft is generic and this is specific.
Kathleen: Double-check the statement of use cases draft role. We can consider
to incorporate this draft into the use cases draft, and adopt them in the
future. Agree with Dave that this isn't fit for the architecture draft. Henk:
Agree with Kathleen and Michael. This can be a profile of the architecture.
Chair: encourage to clarify the intent of this draft and have more discussion
with architecture Design Team, and make the decision later

#RATS Architecture (45 minutes) Discussion from the Editorial Team
Chair: explain the goal of the architecture design team, and members: Dave,
Henk, Michael, Ned

Eliot: ask the way to reach consensus in Github, some confusions for him
Dave: explain the text: chairs close Github issues
Michael: discuss at Github first, then bring the result to the mailing list
Dave and Chair: agree with Michael on this point
Laurence: ask about the pace of publishing drafts and what are the decision
points. Dave: no answer now.

Henk: talking about the terminology and use cases, we need it and have several
options to include in current drafts Dave: ok and welcome more discussion

Thomas from Jabber: agree with the current way of deal with trust establish
part in arch draft

Elliot: in-band interaction vs out-of-band interaction clarification question
Dave: current diagrams are out-of-band, in-band ways are already in
architecture draft (the passport mode and background check mode)

Thomas from Jabber: Can Attester don't sign evidence at local which is to be
pulled later by Verifier? Dave: Yes. Michael: we may need to consider
cooperative and uncooperative methods for arch design, for protecting privacy
and confidentiality. Dave: I don't know yet whether it belongs to the
architecture so far. Need more thinking about it.

Henk: jabber says we need recharter for phase 2
Laurence: how many details should be in the arch? for example, signing methods,
... Chair: we need to consider this point.

Thomas from Jabber: also need to allow Verifier to ask for only the substance
of the claims. Dave: will discuss this after this meeting.

Chair: ask the timeline of arch draft
Michael: we will have a new one in December

# YANG Module, Henk Birkholz (20 minutes)
Michael: Is there any relation between the EAT part yang model and the rest
yang model? Henk: Not yet. For now, the EAT part can only include what defined
in the EAT draft.

Laurence: ok with defining the EAT part yang model, one suggestion: input is
lack of the identity info to tell the device which EAT the verifier needs Henk:
You can file an issue about this.

Dave: How does the verifier know whether it should call the yang function or
eat function? How does the Verifier know the Attester is TPM-based or
EAT-based? Shwetha from Jabber: One way is to use other YANG models to figure
out whether the device supports TPM or EAT. The other way is to separate the
TPM-based attestation and the EAT-based attestation into two YANG models. Henk:
Can use the 'feature' function provided by YANG.

Dave: How to know the address of the device to query? This is related to the
whole workflow, maybe the RIV people should consider this.

Dave: what's your consideration to include other formats (e.g., eat) in your
current yang model? Henk: we think we can deal with it.

Chair: ask the WG hum for adopting this draft.
    Many hums both in the meeting room and Jabber
Chair: ask the WG hum for not adopting this draft.
    Silence
from WG: the WG agrees with adopting this draft based on hum.
Chair: will still bring it to the mailing list for the formal process

# New Drafts:
RATS pub/sub model, Liang Xia (10 minutes)
    https://tools.ietf.org/id/draft-xia-rats-pubsub-model-01.txt
Dave: don't understand the counter for freshness check, timestamp can work. Is
it possible to be part of the current yang model draft? Henk: you are right,
they are similar and have the same basis. Dave: Consider whether to pull this
into the yang model draft. The freshness issue should be considered by using
TUDA or timestamp or other RPCs. Henk: Creating a YANG model for TUDA is easy.
TUDA work can be started again.

Michael: We agree that we need to solve the nonce problem for RATS pub/sub
solution.

Chair: please provide your feedback about how to process this draft together
with the current yang model draft to the mailing list.

Milestones, Summary of Calls for Adoption (5 minutes)
  - YANG Module draft
  - RIV draft

Open Mic (10 minutes)

Two virtual interim: TEEP
TEEP was planning to have interim during the hackathon in Feb.

Jabber: xmpp:rats@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf106/rats
Etherpad: https://etherpad.ietf.org/p/notes-ietf-106-rats