Re: [Rats] Android comments on EAT draft

[Giridhar Mandyam <[e-mail]>]

> The idea is that a device might want to attest a key that would be used for other purposes than proof-of-possession (authentication).

EAT can be applied to use cases other than attestation of a key that is only used for PoP.

For instance, I had proposed a usage of EAT for the W3C’s Web Authentication API (Webauthn).  For Webauthn, the ideal attestation would be for the authenticator itself (e.g. biometric), which could also include the credential (keypair) along with matcher protection, anti-spoof implementation, etc.  In the Webauthn case, the keypair is used to sign assertions when a user verification having taken place (see https://w3c.github.io/webauthn/#sctn-op-get-assertion, the assertion represents more than just PoP of the private key).  The Webauthn attestation can be broader than just attesting the keypair – the authenticator implementation can be attested as well (which is not the same as the device itself).  In other words, the attestation is broader than for a key used only for proof-of-possession.

Following the model provided in Webauthn (https://w3c.github.io/webauthn/#sctn-attestation), I proposed https://pr-preview.s3.amazonaws.com/gmandyam/webauthn/pull/1121.html#fido-eat .  Granted – this is only an initial proposal and would need a another look.  But the existing claim set only had to be extended slightly in order to meet Webauthn requirements.  The claim set can be extended further given the use of the Webauthn keypair in the context of user verification.  For instance, in the SoC context, if the keypair is implemented in a root-of-trust but the biometric is implemented in user space (e.g. rich execution environment such as Android), then the EAT claims can be augmented to provide this information.

Note that for Webauthn, an IANA registry has been proposed that would allow for extension of the existing suite of attestation formats (https://tools.ietf.org/html/draft-hodges-webauthn-registries-02 ).  For any attestation formats this group considers, it could be a good exercise to see how the format could meet the Webauthn requirements if we want to verify that an attestation format is usable beyond keypairs used for PoP.

-Giri Mandyam

From: RATS <[e-mail]> On Behalf Of Mathias Brossard
Sent: Monday, May 20, 2019 2:04 PM
To: Laurence Lundblade <[e-mail]>
Cc: Shawn Willden <swillden=[e-mail]>; [e-mail]; Simon Frost <[e-mail]>
Subject: Re: [Rats] Android comments on EAT draft

.
Hi,

The idea is that a device might want to attest a key that would be used for other purposes than proof-of-possession (authentication). The attestation token would act as a form of certificate, essentially the link between a key to a device. We are thinking about integrity (signature) and encryption / key agreement. In many cases you could use TLS with PoP to provide the same kind of security properties. But in some cases there is no IP connectivity, the resources are too constrained or you want the security to be maintained end-to-end (rather than at the transport layer).

The protocol flow would not change for attestation.

Sincerely,
-- Mathias Brossard

From: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Date: Friday, May 17, 2019 at 6:57 PM
To: Mathias Brossard <[e-mail]<mailto:[e-mail]>>
Cc: Simon Frost <[e-mail]<mailto:[e-mail]>>, Shawn Willden <swillden=[e-mail]<mailto:swillden=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] Android comments on EAT draft


On May 16, 2019, at 9:31 AM, Mathias Brossard <[e-mail]<mailto:[e-mail]>> wrote:

But even for the relatively simple use-case of putting a public key in a token, which it technically supports, I am worried that the semantics might be too constraining. It focuses on proof-of-possession (PoP), where we are thinking about additional functions (signature, encryption, key agreement, etc.).

Mathias, can you say more about the additional functions you are thinking about?

Would they change the protocol flow in a big way? Mostly what we are thinking is that the RP sends a nonce to the device and the device returns a token.

LL


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.