Subject: [Rats] draft-richardson-rats-usecases-00 comments

From: Anthony Nadalin <[email-masked]>
Date: Tue, 12 Mar 2019 22:03:19 +0000

The section on FIDO usecase (5.3) is out of date, as in FIDO/W3C there are many attestation formats that are acceptable from devices, the major concern that we have is the privacy issues as most all the attestation formats lead to potential collusion in one form or the other. The JS API is now the W3C WebAuthentication API that is a recommendation now, this is no longer in FIDO. I would be happy to send edits to this section.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Mar 2019 23:27:41 -0400

Anthony Nadalin <tonynad=[email-masked]> wrote:
    > The section on FIDO usecase (5.3) is out of date, as in FIDO/W3C there are
    > many attestation formats that are acceptable from devices, the major concern
    > that we have is the privacy issues as most all the attestation formats lead
    > to potential collusion in one form or the other. The JS API is now the W3C
    > WebAuthentication API that is a recommendation now, this is no longer in
    > FIDO. I would be happy to send edits to this section.

That would be wonderful, THANK YOU!
It's a -00 afterall, and the goal is to tease out what might be
old/nonsensical/etc. so that we can get to the bottom of things :-)

(I thought I did say that it all became the WebAuthentication API...)

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

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 20 Mar 2019 12:00:38 -0700

The way I’d approach the FIDO use case is to say that the relying party wants to to have the HW/SW implementation that did the biometric check strongly identified (attested). This is to make sure that the end user is not using some short cut or hacked, or insecure implementation that is not checking the biometric properly. 

FIDO allows a bunch of attestation formats now because there is no broadly common attestation format, something I hope we will remedy. It will take some years of course…

I don’t know that it is necessary to dig into all the different formats that FIDO allows.

Agree with Tony that solving the privacy issue in a broad standard way will be really helpful for lots of use cases (also some use cases don’t have a privacy issue).

LL

> On Mar 12, 2019, at 8:27 PM, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 20 Mar 2019 12:05:34 -0700

Just briefly,

The TCG use case seems more like a description of technology than a use case. 

There is the Cisco / Network Function use case that is oriented around the list of SW components and measurement of them. Eric Voit is the man for that I think. Henk and a few others were also into it.

I also think there is at least one IoT use case. Maybe it is one with very many sub use cases. The main issue there is on boarding devices to an IoT management platform that have been drop-shipped or sent straight to the consumer or such.

LL

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 20 Mar 2019 19:19:43 +0000

And in the FIDO case we don't need a transport as it's carried in the W3C WebAuthn and FIDO CTAP protocols

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: Wednesday, March 20, 2019 8:00:38 PM
To: Michael Richardson
Cc: Anthony Nadalin; [email-masked]
Subject: Re: [Rats] draft-richardson-rats-usecases-00 comments

LL

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Ctonynad%40microsoft.com%7C036e72240d664c971e4508d6ad666949%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636887052703477437&amp;sdata=cJOWJx7QKyLqZOBxLQEWFj0SQX9eZ1AUUwdsEPxRtEY%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Mar 2019 21:58:21 -0400

> The TCG use case seems more like a description of technology than a use

yes, I was given a document in progress, and I felt it was very difficult
to determine what the use case was exactly.
I also felt it was  important to write something down to ferret out the target.

But, in particular what I saw was that it was more about attesting to
the integrity of physical systems in an enterprise rather than, for instance,
attesting to absense of holes for video to escape into.
I gather you did not get this from my text, so I will attempt to improve it.

    > There is the Cisco / Network Function use case that is oriented around
    > the list of SW components and measurement of them. Eric Voit is the man
    > for that I think. Henk and a few others were also into it.

    > I also think there is at least one IoT use case. Maybe it is one with
    > very many sub use cases. The main issue there is on boarding devices to
    > an IoT management platform that have been drop-shipped or sent straight
    > to the consumer or such.

Are there documents you can refer me to?

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 22 Mar 2019 21:01:53 +0000

I'm aware that the Open Connectivity Foundation (OCF) has implemented an IoT onboarding use case. Possibly it makes sense to reference one of their documents?
-Ned

On 3/22/19, 7:46 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Sat, 23 Mar 2019 08:55:43 +0000

Hi Michael,
Maybe you can reference to this:
https://datatracker.ietf.org/meeting/103/materials/slides-103-rats-compromise-trustworthy-visibility-in-working-systems-00

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2019年3月22日 9:58
收件人: Laurence Lundblade <[email-masked]>
抄送: [email-masked]
主题: Re: [Rats] More use cases for draft-richardson-rats-usecases-00

    > The TCG use case seems more like a description of technology than a use

yes, I was given a document in progress, and I felt it was very difficult to determine what the use case was exactly.
I also felt it was  important to write something down to ferret out the target.

But, in particular what I saw was that it was more about attesting to the integrity of physical systems in an enterprise rather than, for instance, attesting to absense of holes for video to escape into.
I gather you did not get this from my text, so I will attempt to improve it.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Mar 2019 19:19:43 +0100

Laurence Lundblade <[email-masked]> wrote:
    > The way I’d approach the FIDO use case is to say that the relying party
    > wants to to have the HW/SW implementation that did the biometric check
    > strongly identified (attested). This is to make sure that the end user
    > is not using some short cut or hacked, or insecure implementation that
    > is not checking the biometric properly.

My changes based upon your comments:

 {{fidosignature}}, but these have been combined into the W3C document
 {{fido_w3c}} specification.

-This specification is very much focused on authenticating user from devices with
-humans attached to them.
+The FIDO use case involves a relying party that wants to have the HW/SW
+implementation does a biometric check on the human to be strongly attested.

(Still looking for some pointers to *attestion* parts of the Android KeyStore.)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Mar 2019 19:20:57 +0100

> W3C WebAuthn and FIDO CTAP protocols

Noted:

+FIDO does provides a transport in the form of the WebAuthn and FIDO CTAP protocols.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Mar 2019 23:23:06 +0100

Smith, Ned <[email-masked]> wrote:
    > I'm aware that the Open Connectivity Foundation (OCF) has implemented
    > an IoT onboarding use case. Possibly it makes sense to reference one of
    > their documents?  -Ned

https://openconnectivity.org/specs/OCF_Security_Specification_v1.0.0.pdf

Is this this document you are thinking of?

There is mention in a blog of a 2.0, but I haven't found it yet.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Mar 2019 23:33:16 +0100

"Xialiang (Frank, Network Standard & Patent Dept)" wrote:
    > Hi Michael, Maybe you can reference to this:

Okay, I think that this is the TCG use case, so I think the -01 will have it
covered.

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 28 Mar 2019 07:43:27 +0000

Yes, plus this https://openconnectivity.org/draftspecs/ocf2.0/CR_SecWG_B_1667_2331_SP_Common_Infra.pdf which describes profiles for different types of attestation checking that may include:
1) mfg installed attestation key / deviceID (x.509 cert based)
2) TCG platform certificate containing hardening / quality criteria supplied by 3rd party validation entities
3) Security and spec compliance status checking by OCF validation entity
4) Enrollment of a local deviceID credential for use post onboarding.
5) TLS / CoAPs as a conveyance protocol

On 3/27/19, 11:23 PM, "Michael Richardson" <[email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 28 Mar 2019 13:33:37 +0100

Here’s a starting point for Android Attestation https://developer.android.com/training/articles/security-key-attestation

Includes around 20 claims about a key pair and the device that stores it as X.509 v3 extensions.

LL

---

From: Carl Wallace <[email-masked]>
Date: Thu, 28 Mar 2019 08:41:33 -0400

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.

On 3/28/19, 8:33 AM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

>Here’s a starting point for Android Attestation
>https://developer.android.com/training/articles/security-key-attestation
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 12:03:35 +0100

> it as X.509 v3 extensions.

perfect, thank you.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 30 Mar 2019 12:04:50 +0100

Carl Wallace <[email-masked]> 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?

---

From: Carl Wallace <[email-masked]>
Date: Sat, 30 Mar 2019 12:03:13 -0400

Makes sense to me to capture current artifacts. Maybe in an appendix to
the use cases draft.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 31 Mar 2019 09:00:59 +0200

> Makes sense to me to capture current artifacts. Maybe in an appendix to

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)