Re: [Rats] draft-chen-rats-tee-identification-01 and IDevID

[Meiling Chen <[e-mail]>]

Hi Laurence,
It was really under your comments we noticed the IDevID, your suggestion do help.
We are not sure if we can reuse the implementation of IDevID, since we have notice there are some gaps, such as the processing of encryption and the interface with server. we will discuss it in detail, if it can be reused, we are willing to introduce it as a part for implementation. 

Best Reguards,
Meiling
 
From: Laurence Lundblade
Date: 2021-08-04 03:25
To: yangpenglin
CC: rats; 粟栗; chenmeiling
Subject: Re: [Rats] draft-chen-rats-tee-identification-01 and IDevID
Hello,

My primary observation is that the goals of the two protocols are very similar. I didn’t know whether you had looked at IDevID or not.

Also, I think an implementation of IDevID could be put in a TEE. Then your security goals would be met, I think.

This is just to offer a few thoughts and ideas. :-)

LL




On Aug 2, 2021, at 7:51 PM, [e-mail] wrote:

Hello there，as one of the authors, thank you very much for your advice, and it helps a lot. I made a comparison below to make a clarification about the difference and the meaning of TEE identification.
Architecture of IDevID
<CatchA81D.jpg>


Architecture of TEE Identification
<Catch04E1.jpg>
    In figure 1，the identity of IDevID will be exposed during the interface which is shown in arrow. In another word, there is no trusted binding between the ID and EAP-TLS server. If the attestation device is compromised, the attackers could obtain the ID and use it in other authentication scenarios.
In figure 2, all the ID related data will be encrypted by EAP-TLS handshake keys. The Inner middle layer could only export the handshake secret key encrypted certificate after verifying the credentials of EAP-TLS server. Since the EAP-TLS server will generate a random during every connection, so this architecture could also prevent replay attack.
The above is the fundamental distinction of these two architectures. This TEE identification architecture also indicates that this draft mostly focuses on the Inner middle layer and external middle layer design to provide a mechanism that could build a trusted connection between TEE and EAP-TLS Server. 
In the webinar there is a question about which identity should be supported in the architecture. Because of time limitation we cannot communicate very well. I think that the draft doesn’t restrict the type of identities since it can use X509 or RPK to identify during the process of EAP-TLS establishment. Or other identities could be sent out as encrypted application layer data after the EAP-TLS establishment.
AS a summary, the meaning of this architecture is to build a trusted authentication procedure with EAP-TLS server when the TEE resource is restricted. (If the TEE resource is sufficient, the whole network stack and EAP-TLS client could be involved in TEE.) And based on the protection of TEE, the sensitive data like IDs, keys will never be exposed in REE as plaintext.   




BR 

Penglin Yang 
China Mobile

 
From: Laurence Lundblade
Date: 2021-07-31 06:33
To: rats
CC: chenmeiling; suli
Subject: [Rats] draft-chen-rats-tee-identification-01 and IDevID
This is just to note that draft-chen-rats-tee-identification-01 seems conceptually similar to IDevID which is described in 
IEEE Std 802.1ARTM-2018, the title of which is "Secure Device Identity”.
 
LL