Re: [Id-event] Review of Subject Identifiers for Security Event Tokens

"Richard Backman, Annabelle" <richanna@amazon.com> Mon, 20 July 2020 22:50 UTC

Return-Path: <prvs=463daaac5=richanna@amazon.com>
X-Original-To: id-event@ietfa.amsl.com
Delivered-To: id-event@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1A3A106C for <id-event@ietfa.amsl.com>; Mon, 20 Jul 2020 15:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LPITfNacSrn for <id-event@ietfa.amsl.com>; Mon, 20 Jul 2020 15:50:26 -0700 (PDT)
Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1573A106F for <id-event@ietf.org>; Mon, 20 Jul 2020 15:50:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1595285427; x=1626821427; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=/Rm5e1tp4FHxbF/S/iQAyfu3espZ0jDMQTnZX55/7WY=; b=MulwZxYRfZddrJHXysfunxNvyMbCcodhesXjfS4+1T73DL9Ql9ifFURB iSKF654sWiZ4lMjAajwVuz/6F5rkm4zCYhkOzYE42izmNhfcx9mUvn1f9 sOKu5uC1NXlE2I6yXqv8tEUpCQb0TEz9WGuQ/YNkHdGaevueEfWYK+4Ib s=;
IronPort-SDR: xMkdHQilXG4VxPxrGJcvx/sUQQrldJwRcyAOaw1TWnk1aIL4fFmsUD+zjn1pm8/RFfhwMl5qxH Rxee84sSl1YQ==
X-IronPort-AV: E=Sophos; i="5.75,375,1589241600"; d="scan'208,217"; a="61307086"
Thread-Topic: [Id-event] Review of Subject Identifiers for Security Event Tokens
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-4e24fd92.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 20 Jul 2020 22:50:24 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-4e24fd92.us-west-2.amazon.com (Postfix) with ESMTPS id B8D98A1FE2; Mon, 20 Jul 2020 22:50:23 +0000 (UTC)
Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 20 Jul 2020 22:50:23 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 20 Jul 2020 22:50:22 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1497.006; Mon, 20 Jul 2020 22:50:22 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: William Denniss <wdenniss=40google.com@dmarc.ietf.org>, ID Events Mailing List <id-event@ietf.org>
Thread-Index: AQHWXuCpR57/OAA87kmVNa/pRTO+fakQnTIA
Date: Mon, 20 Jul 2020 22:50:22 +0000
Message-ID: <3F52CB79-3003-4862-B1C8-95DAE38FC9B4@amazon.com>
References: <CAAP42hA=5xPOOA4JNij5pdjhTD3L__yGETXFK-DNriMxWFpXww@mail.gmail.com>
In-Reply-To: <CAAP42hA=5xPOOA4JNij5pdjhTD3L__yGETXFK-DNriMxWFpXww@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.65]
Content-Type: multipart/alternative; boundary="_000_3F52CB7930034862B1C895DAE38FC9B4amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/x67slC0qg8xVnXc5ixIDMEJSuKM>
Subject: Re: [Id-event] Review of Subject Identifiers for Security Event Tokens
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." <id-event.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/id-event>, <mailto:id-event-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/id-event/>
List-Post: <mailto:id-event@ietf.org>
List-Help: <mailto:id-event-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/id-event>, <mailto:id-event-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2020 22:50:29 -0000

Thank you for the review, William. No inline comments or questions from me, as I agree with all of your feedback. :)

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/


From: Id-event <id-event-bounces@ietf.org> on behalf of William Denniss <wdenniss=40google.com@dmarc.ietf.org>
Date: Monday, July 20, 2020 at 2:56 PM
To: ID Events Mailing List <id-event@ietf.org>
Subject: [EXTERNAL] [Id-event] Review of Subject Identifiers for Security Event 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 reviewed Subject Identifiers for Security Event Tokens v05 (https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05<https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#ref-JWT>).

Summary & Benefits:

The draft standardizes a way to represent the subjects when they may be of different types (e.g. some with email, some with ID). It does this in a way that allows the type and the value to be encoded together. JWT by itself doesn't define the type of subjects (it's defined as a case-sensitive string containing a StringOrURI value), leaving this to implementers which works in many situations, but can cause problems for the application of JWTs as security events. Also included is a way to present multiple identifiers for the same subject. Standidizing this is relevant in Security Event Token environments like RISC involving multiple parties where some mapping of identifiers between the systems is needed. For example, when two email systems share SETs to mitigate email recovery related risks, one party might identify users by ID, whereas the other by email address. The one-size-fits-all typeless "sub" can fall short in this situation.

Traditional use of JWT is unidirectional, with one issuer and multiple consumers whereby the subject itself can be more or less an opaque index. The SET application of JWT sees multiple issuers who consume each other's tokens and need to identify subjects across identity provider boundaries. Being able to communicate the subject type, as well as potentially multiple subject identifiers for the same subject is useful in this type of environment. Using JWT claims without the subject identifier approach defined in this draft, the issuer may put an opaque value in "sub", and an email address in "email", but without a way to indicate what the type of the sub is, or if it's reasonable to use "email" as the subject rather than just an attribute of the user. This draft allows for multiple subject identifiers to be communicated as such and removes the guesswork by consumers as to what should be considered a subject identifier and what should not.

Feedback:

Abstract:

Nit: I normally see RFC's referred to by number, so rather than "within a [JSON] object", I would  expect to see "within a JSON [RFC 7159] object". Same for JWT and SET. I think this style reads better, as it separates the name of the draft from the reference.

§ 3:

One thing that I feel is missing is an example of a full SET or JWT with the subject identifier. I'm a big believer in examples, as it gives the reader an easy way to picture the final application of what is being specified. Like what we did in RFC 8417, Section 2.1.4: https://tools.ietf.org/html/rfc8417#section-2.1.4.  There are some non-normative examples in this draft later for non-SET JWTs, which is great, so I think it would be useful to have ones for SET as well.

§ 3:

"   A Subject Identifier is a [JSON] object containing a "subject_type"
   claim"

Nit: I'm troubled slightly by the phrase "JSON object containing a claim" here. In JSON terms, these are key/value pairs not "claims" which is a JWT term. I think it's fine for the doc to mostly use "claims", since the context is JWT, but since we're designing a new type here, I'd suggest at first use to say something like "JSON object with multiple key/value pairs representing the subject's claims", after which you can just use "claim".

§ 4.1:

Document defines a "sub_id" JWT claim, but it doesn't really explain why or when to use it.

I think the doc would benefit from an introduction in this section that talks about why this is a useful construct, and where we expect it to be used. My understanding is that we expect subject identifiers to be used in SETs  (e.g. in RISC) and in non-SET JWTs.  It makes sense to me to have a "pure JWT" option here, and I'm sure it was added for good reason (including perhaps some that I enumerated in my benefits summary above), I think it would help to have those reasons listed.

§ 6:

I feel like there are always security considerations :-)

Maybe this could document some of the security considerations of sending subject as JWT claims without using this spec (e.g. that maybe someone could rely on a claim more strongly to identify a subject than was intended).

§ 7:

Just a comment: I agree with the choice of "Expert Review" for IANA. "Specification Required" would be too heavyweight here.


Best,
William