[scim] SCIM Events Pull Request #20 - Unsecured Tokens

[Phillip Hunt <[e-mail]>]

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) 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
[e-mail]

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.