Re: [scim] I-D Action: draft-ietf-scim-device-model-03.txt

[Monty Wiseman <[e-mail]>]

Eliot,

Great to hear we are in agreement. As I'm proposing a very similar 
architecture to what we just finished in the csr-attestation. This 
method was discussed in LAMPS just before this session so we know this 
is a reasonable approach. I'll be willing to help with this change to 
the draft and I'll add the TCG method as another example.

Monty Wiseman
Security Architect, Beyond Identity
www.beyondidentity.com

On 24/03/18 16:18, Eliot Lear wrote:
>
> Hi Monty,
>
> Actaully I agree with what you write.  As you'll hear today, this is 
> work to be done, but I don't think it's a lot of work. The only *real* 
> issue is whether versioning should be internalized to the module name 
> or separated.
>
> Eliot
>
> On 18.03.2024 02:59, Monty Wiseman wrote:
>> I can include an approach for using TCG-defined device identity (as 
>> provided in the links below) but I have a broader concern. This draft 
>> includes a specific set of device Extensions for specific 
>> implementations but doesn't appear to to be extensible. What if a new 
>> method comes along (or a modification of an existing one. I recommend 
>> we take the approach we just did for the csr-attestion in LAMPS where 
>> there is a need to provide attestations from many types of components 
>> (TPM being just one example). There is a place specified in the spec 
>> where an OID is provided to identify the type of 
>> attestation_statement is being provided and we (LAMPS) will be 
>> requesting an IANA registry for those. This way the RFC is 
>> extensible. See: 
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/
>>
>> Monty Wiseman
>> Security Architect, Beyond Identity
>> www.beyondidentity.com
>>
>> On 24/03/05 18:58, Eliot Lear wrote:
>>> Hi Monty
>>>
>>> To get things in, I think the general approach should to indicate, 
>>> at least briefly, what the semantics of the server would be.  So for 
>>> instance, for DPP the semantics involve getting the QR code 
>>> components to the DPP controller so that when a device "chirps", it 
>>> can perform the authentication exchange.
>>>
>>> What would those semantics be here?  Would it simply be to insert a 
>>> certificate root and, say, Subject bound by that root, into an 
>>> EAP-TLS/TEAP process?  At which point, the two SCIM data objects 
>>> would be something like a trust anchor (or a URL to it) and then a 
>>> Subject or SAN or some such.
>>>
>>> Eliot
>>>
>>> On 05.03.2024 00:33, Monty Wiseman wrote:
>>>> There should be a Device Extension for TCG-defined TPM-based 
>>>> devices. There is a "Platform Certificate" and "TPM2 Key for device 
>>>> Identity" (802.1ar keys in TPM) x.509-based certificate defined by 
>>>> Trusted Computing Group (TCG) that defines a particular device and 
>>>> includes supply chain assurance back to the manufacturer. I'd be 
>>>> willing to contribute.
>>>>
>>>> https://trustedcomputinggroup.org/wp-content/uploads/IWG_Platform_Certificate_Profile_v1p1_r19_pub_fixed.pdf 
>>>>
>>>>
>>>> https://trustedcomputinggroup.org/wp-content/uploads/TPM-2p0-Keys-for-Device-Identity-and-Attestation_v1_r12_pub10082021.pdf 
>>>>
>>>>
>>