Re: [Rats] UEID where an instance is a group member

[Henk Birkholz <[e-mail]>]

Hi Laurence,

I am having a hard time to follow the discussion. What does "secured 
attestation" mean in this context, an EAT that is Evidence or something 
else? I am really not sure, because I cannot parse your first paragraph.

It could also be an Endorsement, such as a Metadata-Service Certificate?

Viele Grüße,

Henk

On 27.03.20 02:14, Laurence Lundblade wrote:
> I was trying to make the case that the bits in the secured attestation 
> that the verifier uses to verify the signature (key ID, X.509 cert 
> chain, ECDAA parameters and such) are not always the same as UEID, as a 
> device identifier. Seems like we agree on this, as you say a key ID 
> identifies a key and UEID identifies a device.
> 
> I’m quite sure that Simon’s proposal is to use GEID to identify keys. I 
> say it’s find to have such an identifier, but put it in the COSE headers 
> where key IDs should go and just use it as a key ID.
> 
> If we want some other thing that is a claim that is for groups of 
> devices, define that separately and say what the purpose and rules for 
> grouping are.
> 
> LL
> 
> 
> 
>> On Mar 26, 2020, at 2:58 PM, Smith, Ned <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Laurence,
>> The point I was making is that EUID and keyID are not always 
>> synonymous. In a case where a device only ever has one key, then maybe 
>> they are synonymous. Otherwise, they should be treated differently. My 
>> assumption is UEID identifies an entity (device) while keyID 
>> identifies a key.
>> A GEID has the same semantics in terms of being an entity identifier 
>> (vs. key identifier) only the GEID points to an entity that is 
>> pseudonymously named. I agree it might be a useful to write a draft 
>> that defines how attestation for privacy sensitivity should be 
>> accomplished.
>> The other observations seems accurate but I don’t see how they relate 
>> to the discussion about whether entity identifiers differ from key 
>> identifiers.
>> Thanks,
>> Ned
>> *From:*Laurence Lundblade <[e-mail] 
>> <mailto:[e-mail]>>
>> *Date:*Thursday, March 26, 2020 at 10:35 AM
>> *To:*"Smith, Ned" <[e-mail] <mailto:[e-mail]>>
>> *Cc:*Henk Berkholz <[e-mail] 
>> <mailto:[e-mail]>>, "[e-mail] 
>> <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>> *Subject:*Re: [Rats] UEID where an instance is a group member
>> The claims giving characteristics of the device should really just 
>> focus on the characteristics of the device, not the scheme for 
>> securing the evidence and results. Seems like overloading could result 
>> in trouble. For example, you need to change the grouping scheme 
>> because of some manufacturing problem, but you can’t because you are 
>> using it to represent some type or model info. Or maybe there’s a 
>> proxy necessary for securing attestation evidence. It would be best if 
>> it didn’t need to look into and/or modify the claims.
>> Here’s a few schemes I think are likely to get used to secure evidence 
>> and results:
>>
>>   * Basic flat per-device public key
>>   * Some X.509 hierarchy that may have X.509 certs carried in COSE headers
>>   * ECDAA and other variants of DAA that may have other things in COSE
>>     headers
>>   * Group keys like FIDO, Android and this proposal
>>   * Symmetric schemes, either per-device or group
>>   * TLS (particularly for attestation results)
>>   * Other new crypto protocol...
>>
>> COSE, JOSE, TLS, CMS and such all provide headers / parameters to 
>> carry things like key IDs to make all of these schemes work.
>> Using UEID for the key ID for per-device keys is probably mostly OK 
>> because it is exactly using the semantics of the UEID. There’s not 
>> really any overloading.
>> GEID used for a key ID and something else would be overloading. Better 
>> to clearly define separate claims for device types, models and such.
>> I’d suggest defining a group key ID header for COSE (and JOSE) and 
>> using that instead of inventing the GEID claim. It would be even 
>> cooler and more useful to write a draft and standardize 
>> privacy-preserving attestation signing for COSE. It would be really 
>> beneficial for lots of people doing attestation that need to solve the 
>> privacy problem. Maybe FIDO and Android would eventually adopt it someday.
>> If using the group key ID header, you’d leave out the UEID, so the 
>> number of bytes transmitted is the same (if you put the UEID in you’d 
>> break the privacy preservation).
>> Keeping claims separate from security header parameters also keeps the 
>> SW stack simpler and cleaner. To verify typical COSE:
>> - Parse the COSE headers to get the key ID and look up the key
>> - Verify the signature and get the payload
>> - Decode the sig-checked claims in the payload
>> If you depend on the claims to verify the signature:
>> - Decode the COSE structure to get the unverified payload
>> - Decode the unverified claims to get the key ID and look up the key
>> - Verify the signature and get the payload
>> - Decode the sig-checked claims in the payload again
>> LL
>>
>>
>>> On Mar 25, 2020, at 11:34 AM, Smith, Ned <[e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>> It seems the purpose for using group ID (GEID) instead of a device ID 
>>> (UEID) is for privacy reasons. UEIDs can be used to track device 
>>> instance. This violates the pseudonymity/unlinkability requirement 
>>> (https://tools.ietf.org/html/rfc6973#page-18). Therefore, if the 
>>> device is operating in a privacy protected mode it might opt to use a 
>>> GEID instead of a UEID as its identity claim/evidence.
>>>
>>> Keep in mind that keyID is also potentially privacy sensitive. 
>>> Therefore, the keyID in privacy sensitive mode should refer to a 
>>> privacy preserving / group key. For example, in FIDO there is support 
>>> for DAA keys (I think?).
>>>
>>> The use of identifier claims and key IDs should be consistent with 
>>> the privacy protection requirements. Either GEID is a privacy 
>>> preserving equivalent to UEID (and a group attestation key is used to 
>>> attest when in privacy protected modes). Or key IDs double as 
>>> identifiers which seems to suggest UEID and GEID are unnecessary.
>>>
>>> However, since a device may have multiple keys over its lifetime (and 
>>> therefore multiple key IDs) the value of identifiers (UEID / GEID) 
>>> being distinct from key IDs is that the device / group identity 
>>> persists even though keys are revoked/replaced/refreshed.
>>>
>>> -Ned
>>>
>>> On 3/25/20, 9:55 AM, "RATS on behalf of Henk Birkholz" 
>>> <[e-mail] <mailto:[e-mail]>on behalf 
>>> [e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>    Hi Laurence,
>>>
>>>    potentially, I just realized, it could serve the purpose of 
>>> matching the
>>>    Authenticator Moodel of a FIDO Authenticator and therefore might help
>>>    the peer that the Atttester is talking to understand the format it has
>>>    to expect being incoming based on the additional input of a FIDO
>>>    Metadata-Service (aka the Authentcator-Model that is called, 
>>> IIRC?). Any
>>>    structure of that kind would help a Verifier to better... "guess"
>>>    (well.. it probably is the output of some kind of negotiation), 
>>> whether
>>>    it is, e.g. FIDO or RIV?
>>>
>>>    Viele Grüße,
>>>
>>>    Henk
>>>
>>>    On 25.03.20 17:46, Laurence Lundblade wrote:
>>>
>>>> A GEID of similar structure to a UEID  seems like a possibility, but
>>>> what exactly is purpose of such a GEID? What does the RP do with it?
>>>> What does the verifier do with it?
>>>>
>>>> An RP will use the UEID to track the unique, specific device. That is
>>>> its clearly stated purpose.
>>>>
>>>> In some designs, a verifier may use the UEID to identify the
>>>> verification key, but that is not the UEID’s purpose. It a useful
>>>> side-effect.
>>>>
>>>> If the purpose of a GEID is solely for the verifier to identify the
>>>> verification key, then I don’t think it is should be a GEID. It should
>>>> be key id.
>>>>
>>>> So for me this kind of hinges on what a GEID will mean for the RP. What
>>>> are the groupings it gives and how are they meaningful to an RP?
>>>>
>>>> LL
>>>>
>>>>
>>>>
>>>>
>>>>> On Mar 25, 2020, at 9:29 AM, Smith, Ned <[e-mail] 
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> Is a GEID structurally different from a EUID? I think currently a EUID
>>>>> is either a 128-bit or 256-bit bstr. I assume the semantics of
>>>>> uniqueness differ.
>>>>> *From:*RATS <[e-mail] 
>>>>> <mailto:[e-mail]><mailto:[e-mail]>> on
>>>>> behalf of Simon Frost <[e-mail] 
>>>>> <mailto:[e-mail]><mailto:[e-mail]>>
>>>>> *Date:*Wednesday, March 25, 2020 at 8:47 AM
>>>>> *To:*Laurence Lundblade <[e-mail] 
>>>>> <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>
>>>>> <mailto:[e-mail]>" <[e-mail] 
>>>>> <mailto:[e-mail]><mailto:[e-mail]>>
>>>>> *Subject:*[Rats] UEID where an instance is a group member
>>>>> We had an internal discussion in response to some changes in PSA which
>>>>> have elaborated the definition of an Instance Attestation Key (IAK) so
>>>>> that it may either be “unique to each device or a collection of
>>>>> identical devices”. The definition of the Identity claim is now a
>>>>> value that identifies the IAK. This has been done to support entity
>>>>> grouping for (some) privacy scenarios.
>>>>> While we have an EAT Profile for PSA that uses a full set of custom
>>>>> claims, our intent has always been to be to migrate as many claims as
>>>>> possible to the standard once the RATS work is complete. Previously,
>>>>> there has been a direct analogy betweenarm_psa_UEIDand the standard
>>>>> UEID. With this change though, we would have to move away from this.
>>>>> The current description of UEID makes it clear that it must be device
>>>>> world unique. There is some discussion
>>>>> (https://ietf-rats-wg.github.io/eat/draft-ietf-rats-eat.html#name-ueid-privacy-considerations)
>>>>> of the group scenario, but the only statement about the claim
>>>>> situation is that “It will often be the case that tokens will not have
>>>>> a UEID for these reasons”.
>>>>> In the privacy scenario, it is still desirable to have an entity
>>>>> identity claim, for use by a verifier or for general usage. The
>>>>> options seem to be:
>>>>> a/ If the entity is unique, include an UEID claim, otherwise include a
>>>>> custom group claim. It seems a pity to encourage diversification
>>>>> between profiles.
>>>>> b/ If the entity is unique, include an UEID claim, otherwise use a new
>>>>> standard GEID claim
>>>>> c/ punt this problem out to the kid of the COSE wrapper. This would
>>>>> ignore any more general uses of group identities.
>>>>> Of these, b/ (introduce a new standard GEID claim) seems to make the
>>>>> most sense and is the option we would propose to the WG.
>>>>> Thoughts?
>>>>> Thanks
>>>>> Simon
>>>>> Simon Frost
>>>>> Senior Principal Systems Solution Architect, ATG, Arm
>>>>> Mob: [phone]
>>>>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> RATS mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/rats
>>>>
>>>
>>>    _______________________________________________
>>>    RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>>
>>>
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
>> _______________________________________________
>> RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
>