Re: [scim] SCIM Events
Phillip Hunt <phil.hunt@independentid.com> Sun, 14 January 2024 20:13 UTC
Return-Path: <phil.hunt@independentid.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 BF6B3C14F605 for <scim@ietfa.amsl.com>; Sun, 14 Jan 2024 12:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level:
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20230601.gappssmtp.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 i_tdTywDjid3 for <scim@ietfa.amsl.com>; Sun, 14 Jan 2024 12:13:01 -0800 (PST)
Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) (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 E01FAC14F5F2 for <scim@ietf.org>; Sun, 14 Jan 2024 12:13:01 -0800 (PST)
Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-2045bedb806so7383435fac.3 for <scim@ietf.org>; Sun, 14 Jan 2024 12:13:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20230601.gappssmtp.com; s=20230601; t=1705263180; x=1705867980; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=VS5RFjXD5vAN1r11xOb5OLq1YmIYjXbKNN8D7zmy9xo=; b=LoNYEz5J1JUo/yWZXEkqdIHQRnoZ4xG1t223MBbO7e/1l+6silOhnorWf5Lla0LvWB i+MNoHnGLy1N8pdBMWQny/tvKbF4XUiQwqm+aKjo8Too4Zypaxcn2m2XOiLmj21+4JSI XFM4xxABUGhbQGzQ4CxpRE5tVfKFm24dtr73W8D3trxJB0GlSS3y902nr92xpC+lL5N6 jHok8k+OBKrU6dWbF1zaPXN/V1NN1QIe48h3hHjLWUMhxrZUwZ9yMQaGhvwbfx//eELx VN3Z3NYzwxeNRp3FzQwicQJAf13hFgAp+/TGYeeKjoFrubRsfkN13dLXan/sI5JI3y3+ 1/dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705263180; x=1705867980; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VS5RFjXD5vAN1r11xOb5OLq1YmIYjXbKNN8D7zmy9xo=; b=jdNUkXymNW3XqRTPvvQEtBj0yy8brkhFmujxNiDVtiNyAoXuZFQOf4URMWvrbMtLpF SuArDwFMjcMQkyxiuX8I8RcKyHNZS15ttZaupUkuwqwCCLs1lw4V88R9cU5OH8h3HpZg Urku0A7y5po2sDE4gWCBuwf044WGXEdQDd00jTPTwXkyqpUds1cb9OQGmcwGH0r3HrOx x/lb60UiH3/U1Uby7oRFEf1TUMWfiS5QqWeIPCu6DymoweF6UPrVyPu380H2MCjPgu+3 xySvdqAMn8xOC+104hnkJesfeuF8v1K0BaS1uKJ5aVw7RTg1d01Hhmd3+DHPUq2/Mqr0 LBjQ==
X-Gm-Message-State: AOJu0YwfYAIq7PKIq0WIm4mMCLDAsJFc/ZxueKkf4BHKc5zPYwrI9gnl rg/RKCuaw4sBMqOrkd9ZQVdyC/zwT33mxI71ryvsw4hzMDA=
X-Google-Smtp-Source: AGHT+IHtyNghq1sDmOwEhWi92i3ywSn+w8JWLihlPcD+vSQtRzM5K5fpsnkXvzG4OEX/zaITHhrCNg==
X-Received: by 2002:a05:6871:5b0f:b0:204:3b53:ddcb with SMTP id op15-20020a0568715b0f00b002043b53ddcbmr8277395oac.107.1705263180380; Sun, 14 Jan 2024 12:13:00 -0800 (PST)
Received: from smtpclient.apple ([2001:569:7a96:c000:29e8:796b:59a:31f]) by smtp.gmail.com with ESMTPSA id c32-20020a631c20000000b005c67a388836sm6743754pgc.62.2024.01.14.12.12.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jan 2024 12:12:59 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-9E7484DC-CA03-44DF-8445-8C1065B87BC0"
Content-Transfer-Encoding: 7bit
From: Phillip Hunt <phil.hunt@independentid.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 14 Jan 2024 12:12:48 -0800
Message-Id: <CAA00130-8525-4281-9EA0-197FA4B1C37E@independentid.com>
References: <MW3PR11MB47307B2C013E3538D4A1A772CD6D2@MW3PR11MB4730.namprd11.prod.outlook.com>
Cc: SCIM WG <scim@ietf.org>
In-Reply-To: <MW3PR11MB47307B2C013E3538D4A1A772CD6D2@MW3PR11MB4730.namprd11.prod.outlook.com>
To: "Paulo Jorge N. Correia (paucorre)" <paucorre=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (21B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/fZBauyNCoCs216apTKx6bk9KCuU>
Subject: Re: [scim] SCIM Events
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: Sun, 14 Jan 2024 20:13:05 -0000
On Jan 14, 2024, at 11:42 AM, Paulo Jorge N. Correia (paucorre) <paucorre=40cisco.com@dmarc.ietf.org> wrote:
_______________________________________________Hi Phil,
As promised in the last IETF meeting I’m reading the last version of the SCIM event.
I’m struggling with 2.4.1 where the Event Provision (EP) or Event Router (ER) is going to create an SCIM event feed for provision, and I’m assuming that the Event Subscriber (ES) doesn’t has that user yet, how would this work if we don’t mandate the userName attribute in the data event payload attribute, in fact I would argue that similar to RFC 7863 this needs to be require for all the operations.
Or at this point it is irrelevant and there should be a statement saying that the data event payload should use the rules defined the schema defined in the schemas attribute in the data section, this will cover [RFC7633] but will cover others schemas like the work that Elliot is doing with devices.
Am I missing something ?
Thank you,
Paulo
From: scim <scim-bounces@ietf.org> On Behalf Of Saxe, Dean
Sent: Monday, December 11, 2023 11:40 PM
To: Phillip Hunt <phil.hunt@independentid.com>; SCIM WG <scim@ietf.org>
Subject: Re: [scim] SCIM Events Pull Request #20 - Unsecured Tokens
Thanks for raising this, Phil.
Intercepting proxies are in wide use, as is TLS termination that occurs in front of the targeted destination. In both of these scenarios, unencrypted SETs may be observed by the TLS terminator, the data may be logged, and thus available to unauthorized parties.
I see two specific issues here. First, disclosure of information is a risk with any sort of intercepting proxy or TLS termination if the SET is unencrypted. If the content of the SET is not sufficiently sensitive as to be a risk if disclosed, this is not a problem. However, for some data such as PII this is a challenge that needs to be solved. Second, modification of the SET in flight is a risk that is sufficiently solved by signing.
Perhaps the focus should be on the security considerations section and the handling of unencrypted SETs when terminating TLS proxies may be in use. The risk can be called out, a solution of using JWE proposed, and the attendant risks with JWEs as you outline below described. Implementers must then make a decision about the handling of PII in SETs.
I’m going to reach out to some folks deep in the SSF world to get their feedback, as well. I’ll post any relevant responses to the list.
Thanks,
-dhs
--
Dean H. Saxe, https://idpro.org/cidpro/" title="https://idpro.org/cidpro/" rel="nofollow">CIDPRO (he/him)
Senior Security Engineer, AWS Identity Security Team | Amazon Web Services (AWS)
E: deansaxe@amazon.com | M: 206-659-7293
From: scim <scim-bounces@ietf.org> on behalf of Phillip Hunt <phil.hunt@independentid.com>
Date: Sunday, December 10, 2023 at 11:13 AM
To: SCIM WG <scim@ietf.org>
Subject: [EXTERNAL] [scim] SCIM Events Pull Request #20 - Unsecured Tokens
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
I am just bringing to the group an issue that Dean raised in PR #20 (https://github.com/ietf-scim-wg/draft-ietf-scim-events/pull/20" rel="nofollow">https://github.com/ietf-scim-wg/draft-ietf-scim-events/pull/20) on the SCIM Events Github site.
This change occures in Section 3.1 which provides advice on use of encryption and signing (original below). Any new proposals from the group that address both Dean and my concerns would be greatly appreciated. Please reply to this email thread so we can record the decision.
Dean’s request is to change the paragraph under “Unsecured" to:
Unsecured tokens SHALL NOT be used.
The justification in the PR was:
Updated language to prevent the use of unencrypted, unsigned tokens in this profile. The concept of "inside" and "outside" networks is no longer sufficient to consider whether transmitting over a TLS-only protocol is sufficient for securing such information.
Supporting such tokens is likely to lead to implementations that leak sensitive information and / or man in the middle interception/modification of SETs.
Based on this assumption (that TLS is unsuffient) we would have to also disallow the use of “signed” tokens as JWS does not provide confidentiality. Note that in many cases because SETs may be processed through gateways (e.g. aggregating events from a cluster), using JWE may become challenging as the iss and aud values would not be accessible. Using JWE effectively forces point-to-point use only which again may cause the receiver to have to forward the unencrypted token on to its own internal endpoints.
It’s my belief that TLS is sufficient in most cases. MITM is not a threat except if administrative systems are compromised or faulty. To the contrary, RFC8935/8936 talks about exchanging events through fixed endpoints. I believe editorially it would be out of scope for this spec to imagine the number of subsequent poorly security or designed systems that might lead to a mis-configuration.
AFAIK, most OpenID Security Signals Framework implementations currently do not support signed or encrypted SETs (though i2gosignals does). These unencrypted systems are running in production now.
While I do generally agree using unencrypted tokens is a bad practice, saying SHALL NOT will likely be ignored. Editorially my goal is to give guidance that in the absence of SET signatures, what the alternative requirements should be.
I am proposing the following revised text for the “Unsecured Token” section:
Per Section 6 <xref target="RFC7519"/>, tokens MAY be generated with <tt>{"alg":"none"}</tt>.This mode potentially speeds up processing by avoiding what would be redundant cryptographic
processing. An example would be replication scenarios within a cluster (e.g. Kubernetes).
Unencrypted tokens MUST be transferred over mutually-authenticated TLS layer encryption and
SHOULD only be used in restricted network environments.
Cheers,
Phil
Original text:
3.1. Security Event Token Signing and Encryption
This specification uses Security Event Tokens as the message format
for SCIM Events. As SETs are based on JWT tokens [RFC7519], they can
be transmitted insecurely, signed, or encrypted. For more
information see the JWT Cookbook specification [RFC7520] for
examples. The decision on whether to use JWS and JWE depends on
operational considerations. For each SCIM Feed relationship, it is
up to deployers to decide on signing, encryption and algorithm
requirements. Deployers SHOULD be aware that too much emphasis on
turning on every possible encryption feature may cause operational
performance to suffer. Deployers MUST weigh the security trade-offs
of up-to-date SCIM services, vs. the potential information loss of an
event.
Unsecured
Per Section 6 [RFC7519], tokens MAY be generated with
{"alg":"none"}. This mode speeds up processing and is best used
in DBR scenarios. Unencrypted tokens MUST be transferred over
authenticated TLS layer encryption and SHOULD only be used in a
restricted network environment.
Signed
JWS ([RFC7515]) signed SETs are useful when it is important to be
able to verify the issuer of a SET as valid. In addition, some
Hunt, et al. Expires 24 May 2024 [Page 27]
?
Internet-Draft draft-ietf-scim-events November 2023
systems MAY wish to validate the authenticity of the event in a
review process which may occur at a later date. While the content
can be validated as originating from the correct issuer and is
unmodified, the message contents remain unsecure. Signed SETs
MUST be transferred over encrypted transport.
Encrypted
JWE ([RFC7516]) are encrypted SETs and are useful when the
transport mechanism is not fully secured (e.g. messages carried by
a third party). The use of JWEs ensures only the designated
receiver can read the event and provides mutual authentication
within the SET message itself.
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
- [scim] SCIM Events Pull Request #20 - Unsecured T… Phillip Hunt
- Re: [scim] SCIM Events Pull Request #20 - Unsecur… Saxe, Dean
- [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt
- Re: [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt
- Re: [scim] SCIM Events Paulo Jorge N. Correia (paucorre)
- Re: [scim] SCIM Events Phillip Hunt