Re: [EAT] {RATS] Introduction

["Diego R. Lopez" <[e-mail]>]

Hi,

If I am correctly following your proposal, this is connected with the idea of a trusted channel we experimented with in the SECURED project, and described in draft-pastor-i2nsf-vnsf-attestation:

“A trusted channel is an enhanced version of the secured channel. It adds the requirement of integrity verification of the contacted endpoint by the other peer during the initial handshake to the functionality of the secured channel. However, simply transmitting the integrity measurements over the channel does not guarantee that the platform verified is the channel endpoint. The public key or the certificate for the secure communication MUST be included as part of the measurements presented by the contacted endpoint during the remote attestation. This way, a malicious platform cannot relay the attestation to another platform as its certificate will not be present in the measurements list of the genuine platform.”

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Tel:         [phone]
Mobile:  [phone]
----------------------------------

On 12/09/2018, 22:17, "EAT on behalf of Eric Voit (evoit)" <[e-mail]<mailto:[e-mail]> on behalf of evoit=[e-mail]<mailto:evoit=[e-mail]>> wrote:

I think saving both the attestation data and the attested evidence is useful.  One RATS use case I have been interested in relates to proxy verification.  For example, what if changes in attested PCRs from one router’s TPM are provided both to an SDN controller (as part of a YANG Notification) and to a peer router (perhaps as EAP credentials over 802.1x).

This would allow the controller to use the same information to determine if a controlled device is trustworthy, as well as act as a RADIUS Server for the peer router.

Eric

From: Carl Wallace, September 7, 2018 7:55 AM


This gets at one difference between current attestation formats. Some require the generator to save the attestation if needed later, others are on demand.

From: EAT <[e-mail]<mailto:eat-bounces@ietf..org>> on behalf of Shawn Willden <swillden=[e-mail]..org<mailto:swillden=[e-mail]>>
Date: Friday, September 7, 2018 at 7:45 AM
To: "Smith, Ned" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [EAT] Introduction

Proof of protection is a good description of what Keystore attestation aims to accomplish, and timeliness or "freshness" is important.  Keystore achieves the latter with a challenge value supplied by the verifier.

On Thu, Sep 6, 2018 at 6:21 PM Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:
|--- snip ---
|So Keystore provides a valuable tool to authors of apps that require strong
|security. For example, for a key used to authenticate an account holder to
|a banking system. But this tool is much less valuable if the bank's server
|can't verify that the secret is managed in a trusted environment. Hence,
|Keystore attestation, which allows the trusted environment to prove that it
|secures the key material, and specifies the authorizations that define how
|it may be used.
--- snip ---
Right, the main objective of attestation is to provide evidence to a verifier regarding the trustworthiness properties of the environment that protects keys and other important things. It goes beyond traditional proof-of-possession.. I think of it as proof-of-protection (PoPr) though that term isn’t widely used. Distinguishing between storage and use may be important since protection techniques differ for each. At the end-of-the-day, attestation expects there is a ‘verifier’ – some entity that wants to check attestation evidence – who engages with the ‘attester’ following some sort of protocol to pass attestation evidence. Timeliness of evidence exchange can be important since, often, environments that protect key storage and use will change during deployment (after initial manufacturing). Attestation protocol is needed to facilitate a timely exchange of attestation evidence. I think these aspects are a primary area where IETF could add value to attestation infrastructure.


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição