Subject: [Rats] Organizing IETF attestation work

From: Laurence Lundblade <[email-masked]>
Date: Sun, 2 Sep 2018 12:02:10 -0700

Hi folks, here is a straw man proposal for organizing the IETF attestation work.

I proposed we combine eat and rats and call this the Remote Attestation or RA working group. 

Example in-scope use cases include:
TPM/TCG based attestations that are sent to remote entities, relying parties and such (non-local attestations)
Attestations used by protocols like FIDO that provide secured claims about a particular subsystem on a device to relying parties
Platform/system attestation schemes like Android O attestation
Reporting of device/system security characteristics by subsystems like TEEs and secure elements
Securing of risk signals (e.g., SW version, geographic location, device types) sent to relying parties
For IoT device on-boarding, proof of device provenance
The documents produced would probably be:
An overall model and terminology document (we have a start with the RATS <https://tools.ietf.org/html/draft-birkholz-attestation-terminology-02> document)
A claims definition document (we have a start with the EAT <https://tools.ietf.org/html/draft-mandyam-eat-00> document)
A protocol definition for transmitting attestations when they are not being carried in other protocols as extensions or such (not started)
Possibly the token binding attestation work (Giri has completed a lot of work on this <https://tools.ietf.org/html/draft-mandyam-tokbind-attest-04>)

We get to reference Ra, the Egyptian sun god and use hieroglyphics.

LL

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Sep 2018 16:06:08 -0400

> I proposed we combine eat and rats and call this the Remote Attestation

I dunno, cats eat rats, (don't they?) so surely it should be called:
  cats = Coordinated AttesTation and Statements

or maybe we can work out "feline"?  [And surely the purpose of remote
attestation is so that suppliers of (cat) videos will be confident that
it's really humans that are watching them]

    > * An overall model and terminology document (we have a start with the
    > RATS document)
    > * A claims definition document (we have a start with the
    > EAT document)
    > * A protocol definition for transmitting attestations
    > when they are not being carried in other protocols as extensions or
    > such (not started)
    > * Possibly the token binding attestation work (Giri
    > has completed a lot of work on this)

Have we had a BOF yet?

    > We get to reference Ra, the Egyptian sun god and use hieroglyphics.

Egyptians worshipped cats, didn't they?

... in seriousness, I'm not yet convinced that there is *IETF* work here to
do, for the simple reason that I'm not convinced that these specifications
will truly be open(stand.org) in a useful way.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carl Wallace <[email-masked]>
Date: Tue, 04 Sep 2018 06:43:46 -0400

I'd explicitly call out key attestation in the in-scope list. It's implied
by the references to TCG and the Attested TLS Token Binding but seems
important enough to call out:
-Key attestation schemes like Android P attestation, Yubikey attestation,
TPM/TCG key attestations.

The deliverables list would likely benefit from a document that describes
attestation verification in detail, including establishment of trust,
revocation of trust, etc.

From:  EAT <[email-masked]> on behalf of Laurence Lundblade
<[email-masked]>
Date:  Sunday, September 2, 2018 at 3:02 PM
To:  <[email-masked]>, <[email-masked]>
Subject:  [EAT] Organizing IETF attestation work

> * TPM/TCG based attestations that are sent to remote entities, relying parties
> and such (non-local attestations)
> * Attestations used by protocols like FIDO that provide secured claims about a
> particular subsystem on a device to relying parties
> * Platform/system attestation schemes like Android O attestation
> * Reporting of device/system security characteristics by subsystems like TEEs
> and secure elements
> * Securing of risk signals (e.g., SW version, geographic location, device
> types) sent to relying parties
> * For IoT device on-boarding, proof of device provenance
> * An overall model and terminology document (we have a start with the RATS
> <https://tools.ietf.org/html/draft-birkholz-attestation-terminology-02>
> document)
> * A claims definition document (we have a start with the EAT
> <https://tools.ietf.org/html/draft-mandyam-eat-00>  document)
> * A protocol definition for transmitting attestations when they are not being
> carried in other protocols as extensions or such (not started)
> * Possibly the token binding attestation work (Giri has completed a lot of
> work on this <https://tools.ietf.org/html/draft-mandyam-tokbind-attest-04> )
> 
> <snip>
> _______________________________________________ EAT mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/eat