Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Dec 2019 17:37:25 -0500

Smith, Ned <[email-masked]> wrote:
    > The step-0 protocol may have payload size or timing limitations that
    > prevents fully attesting. This is the case for 802.1X ethernet ports.

EAP-TLS would carry the certificate, and it has a way to segment the
payloads, I think.  If not, DTLS does.

The attestation would go into the TLS as data, inside the voucher-request, so
I don't imagine that there would be further size limitations.

    > On 11/22/19, 10:33 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    >> discoverable by the Verifier.   That step could have included the EAT
    >> or the TPM data

    > I have a todo item to write up:
    > 1) a use case for Attestation at BSKI onboarding time.
    > (really this is a RIV sub-case, I think)

    > 2) a document explaining how to carry EAT in BRSKI voucher-requests and
    > RFC8366 vouchers.

    > _______________________________________________
    > RATS mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/rats

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Dec 2019 17:41:04 -0500

Guy Fedorkow <[email-masked]> wrote:
    > The Step Zero I've been keeping at the back of my mind is RFC 8572,
    > which already has a number of complicated mechanisms to reach out and
    > obtain configuration information.  I think a RIV-style attestation
    > exchange could be added to the steps without deleterious interactions.

Yes, in particular this is a use case where the YANG TPM module would be
rather useful.

    > That's not to say that RFC 8572 is the only applicable environment,
    > it's just one that seems like a good match.

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

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 5 Dec 2019 00:01:55 +0000

On 12/4/19, 2:37 PM, "Michael Richardson" <[email-masked]> wrote:

    

That is one approach, other approaches include Evidence in certificates. Sometimes protocols have upper bound on the size of the certificate path payload. Doing attestation as part of a session establishment (e.g. TLS handshake) is the trust semantics of attestation apply to the session keys. If attestation is part of a data block, then it is possible for the trust semantics of attestation to be separated from the session endpoints.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Dec 2019 09:26:16 -0500

> That is one approach, other approaches include Evidence in
    > certificates. Sometimes protocols have upper bound on the size of the
    > certificate path payload. Doing attestation as part of a session
    > establishment (e.g. TLS handshake) is the trust semantics of
    > attestation apply to the session keys. If attestation is part of a data
    > block, then it is possible for the trust semantics of attestation to be
    > separated from the session endpoints.

BRSKI connects the inside to the outside via RFC8366 vouchers, so the end
points are really quite well pinned down :-)