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

Monty Wiseman <monty.wiseman@beyondidentity.com> Mon, 18 March 2024 02:00 UTC

Return-Path: <monty.wiseman@beyondidentity.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27B6C14F5EF for <scim@ietfa.amsl.com>; Sun, 17 Mar 2024 19:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=beyondidentity.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6yDG0JxzTJn for <scim@ietfa.amsl.com>; Sun, 17 Mar 2024 18:59:58 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13CDC14F6AB for <scim@ietf.org>; Sun, 17 Mar 2024 18:59:57 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-5ce6b5e3c4eso2260290a12.2 for <scim@ietf.org>; Sun, 17 Mar 2024 18:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beyondidentity.com; s=google-bid; t=1710727197; x=1711331997; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=QSIb+XhMLP/jbJcrFat79W9dz8RUmJggSTj2/TXhPwg=; b=KhvoIBzanB06wRzWh9mVUwAkeOhIgbpDmDTQcMJdthhm+s9ZSTj7E9gF/d8nSMZ9oZ uACKjKI16s/NMfodFtYd5SsJ8uAzhvkcOA8HFjDAzJ+QgHbGxDrSA/K75dme19kuT357 IDCPO3n+vHsRve3cbaANfU/3Q6T3EpywU4rLeowBn0kAk9SuEdA6LqcCZmYiBiBuvDqu JlSk1Ov5LsKQcDlXY5RFNSRee7lNt5rDoYDJI4Z/GOhbHCH2AAxoEZLMHu09JmmDLkcp h42wCa0EejpDzD4GbO5HR+i2GcUx+jcEEc8ladLACkBph9tjemNw2yatDx7SRVd7QwkC 429A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710727197; x=1711331997; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QSIb+XhMLP/jbJcrFat79W9dz8RUmJggSTj2/TXhPwg=; b=us6wErw4jstZZr+LlPWchBMrSzGzEiVvzpdbLgt/b3IWvyXkQ30qU1592I0+Obnx7E pPt0yQZwWIHSCPogbqcbCm10TGoIrzYSPlxi76N18+QuOSRBH9S/tPhbjusKaEgBHdSa 6WejNZ1WcUS9zE+/4tcpyDLPRRVSrkr0cn0SFhCZARaYfPVyfKwJF9RAN5t+pPcw2GLZ X6r2I4fPUhisUeO31MQvhoG16pO7TdujpiPGQLh5o3qL+TlqCBQTe4lyBlxea5kPKZmu wJKOlVWjhE1tI/lMbfdGsv/4pGwsxMVPg+XrqDIRmksJMT2L0Q4APALHhwQB5g34jpPa YtUg==
X-Gm-Message-State: AOJu0YwLgsh5HXhZr74etRSlvMwZ6VV+lkTTWdzleVFEcUfMEU0VVO/i Dgy2DIfAMv9dKY01micWvmlJZrXORYOvsSDKw0AKhKvdnqwyr27nt7BLPj77SG28YZIuzk0/Gzl /BGc=
X-Google-Smtp-Source: AGHT+IFhCQzhrKq8ARJkZcJxvprVq07zZeAalBzKkl8ZqIMBUqc3TnjJazGGHBdcL0i/G5W4I3AXuA==
X-Received: by 2002:a17:902:cec6:b0:1e0:157a:8470 with SMTP id d6-20020a170902cec600b001e0157a8470mr3011110plg.12.1710727196593; Sun, 17 Mar 2024 18:59:56 -0700 (PDT)
Received: from [172.31.27.237] ([103.100.225.199]) by smtp.gmail.com with ESMTPSA id l18-20020a170903245200b001def758b7d0sm5052223pls.127.2024.03.17.18.59.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Mar 2024 18:59:56 -0700 (PDT)
Message-ID: <d57d463f-2103-49cb-b190-b8f79bdafbcb@beyondidentity.com>
Date: Mon, 18 Mar 2024 11:59:51 +1000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Eliot Lear <lear@lear.ch>
Cc: "scim@ietf.org" <scim@ietf.org>
References: <66298f3a-7d5d-4c1c-b09c-8a8aba49454b@beyondidentity.com> <a28e9b30-c94d-41f1-8222-4cca3828ba5d@lear.ch>
Content-Language: en-US
From: Monty Wiseman <monty.wiseman@beyondidentity.com>
In-Reply-To: <a28e9b30-c94d-41f1-8222-4cca3828ba5d@lear.ch>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/96dmSf7RMTadfhZiG_2HZD5IQnM>
Subject: Re: [scim] I-D Action: draft-ietf-scim-device-model-03.txt
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 02:00:02 -0000

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 
>>
>>