Re: [Rats] More use cases for draft-richardson-rats-usecases-00

[Anders Rundgren <[e-mail]>]

Hi Ned et al,
I have briefly looked into the referenced documents and my conclusion is that "session-based attestation" probably lacks a clear definition.

What I meant with session-based attestation was that an attestation challenge-response sequence would in addition to exchange of trust information also create a session (in both ends) and associated session-key (typically using a DH scheme) which is subsequently used for executing MAC-protected API calls and finishing with a "commit" call.

For smart card provisioning a device-unique "masterkey" is sometimes used to achieve similar functionality but the trust establishment is implicit [1].

I'm currently not aware of any other system than SKS/KeyGen2 [2] supporting (this definition of) session-based attestation.  The protected API concept was loosely derived from TPM's authorization scheme.

Anders

1] https://naeemgik.blogspot.com/2017/12/globalplatform-secure-channel-protocol.html
2] https://github.com/ietf-teep/architecture/issues/52

On 2019-04-02 19:27, Smith, Ned wrote:
> Anders refers to session-based attestation in the TEEP archive which points to several sources including a TCG source. This may be referring to a public specification known as DICE - Device Identifier Composition Engine.  https://trustedcomputinggroup.org/wp-content/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf
> 
> TCG terminology for TEEP's "Static" attestation is "Explicit Attestation" and TEEP's term "Session Based" attestation is "Implicit Attestation" by TCG.
> 
> I.e.
> (i) TCG.Implicit-Attestation ~= IETF.TEEP.Session-Based-Attestation
> (ii) TCG.Explicit-Attestation ~= IETF.TEEP.Static-Attestation
> 
> The EAT draft defines an attestation approach that seems close to (i) if you ignore the nonce that is returned as a static claim / assertion and if you rule out of scope the definition of how the signing key is created / persisted.
> 
> The tokbind draft seems closely resemble (ii).
> The TUDA draft seems to resemble (i). (Henk can correct me).
> The yang draft seems to resemble (ii). (Henk can correct me).
> 
> -Ned
> 
> On 3/31/19, 12:01 AM, "RATS on behalf of Anders Rundgren" <[e-mail] on behalf of [e-mail]> wrote:
> 
>      On 2019-03-30 17:03, Carl Wallace wrote:
>      > Makes sense to me to capture current artifacts. Maybe in an appendix to
>      > the use cases draft.
>      
>      For completeness you should consider mentioning that there are two quite different platform attestation concepts:
>      - Static: FIDO, Android, and current TEEP architecture
>      - Session based: Used by some smart card schemes and SKS/KeyGen2 (https://github.com/ietf-teep/architecture/issues/52)
>      
>      >
>      > On 3/30/19, 7:04 AM, "Michael Richardson" <[e-mail]> wrote:
>      >
>      >>
>      >> Carl Wallace <[e-mail]> wrote:
>      >>     > Example attestations from Android devices, Yubikey devices and
>      >> Surface
>      >>     > Pro virtual smart cards can be found here:
>      >>     > https://github.com/Purebred/SampleAttestations. These are
>      >> accompanied
>      >>     > by SCEP requests that include the attestations and the resulting
>      >>     > certificates. The attestations were generated and used as part of
>      >>     > issuing device and end user certificates where the public key was
>      >> the
>      >>     > focus of the attestation. The Android and Yubikey attestations take
>      >> the
>      >>     > form of X.509 certificates (packaged as certs-only SignedData). The
>      >>     > Surface Pro attestations take the form of CMC requests.
>      >>
>      >> I think that seeing the examples is very useful to extract common pieces.
>      >> Do you think it's useful to include some in the use case document?
>      >>
>      >> --
>      >> Michael Richardson <[e-mail]>, Sandelman Software Works
>      >> -= IPv6 IoT consulting =-
>      >>
>      >>
>      >>
>      >
>      >
>      > _______________________________________________
>      > RATS mailing list
>      > [e-mail]
>      > https://www.ietf.org/mailman/listinfo/rats
>      >
>      
>      _______________________________________________
>      RATS mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/rats
>      
>