Re: [Id-event] SAML subject identifier type

"Richard Backman, Annabelle" <richanna@amazon.com> Tue, 14 July 2020 23:54 UTC

Return-Path: <prvs=4570b4e1b=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 98E773A08AF for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 16:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.59
X-Spam-Level:
X-Spam-Status: No, score=-9.59 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, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 68JDKSqO3yv5 for <id-event@ietfa.amsl.com>; Tue, 14 Jul 2020 16:54:06 -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 449523A08A7 for <id-event@ietf.org>; Tue, 14 Jul 2020 16:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1594770847; x=1626306847; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=AhgyT2j9XaDUOJJn2KqKQQq6TdW645LXgLGa4wwSRsM=; b=cLQodQg46Chbx5UeSzwbHS09QYNSIC4yiTVLl2aygJSSfzY9awh+SVVg 0H3AlgZraKlfAE4V1m7O9VYpgZ+EfnThG1OwHWj5nBmQ6ToSRTMVBlics CzSbrhIP2bONfalCIEs9utNNjNh2US6m43Xf8FScsP0kvBaIkZws+unqH 4=;
IronPort-SDR: B69MacAv1l/9Nvm8W32KtKfG5i6I6sS9E0Epq4zYXMbh6yV6qwZIhbRX9+T3csUb4R7AMPc2jZ Kzb5+eqvQcHg==
X-IronPort-AV: E=Sophos; i="5.75,353,1589241600"; d="scan'208,217"; a="59875670"
Thread-Topic: [Id-event] SAML subject identifier type
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-81e76b79.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 14 Jul 2020 23:53:54 +0000
Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-81e76b79.us-west-2.amazon.com (Postfix) with ESMTPS id 4702CA1C0A; Tue, 14 Jul 2020 23:53:53 +0000 (UTC)
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 23:53:52 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 23:53:52 +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; Tue, 14 Jul 2020 23:53:52 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>, Brian Campbell <bcampbell@pingidentity.com>
CC: Yaron Sheffer <yaronf.ietf@gmail.com>, Chris Phillips <Chris.Phillips@canarie.ca>, "id-event@ietf.org" <id-event@ietf.org>
Thread-Index: AQHWWTErqa1UOmYxD0aXofDEeWMAPqkFxAuAgAAwHICAAA4GAIABdk8AgAAPNoCAABqVgIAAGVRf//+QtoA=
Date: Tue, 14 Jul 2020 23:53:52 +0000
Message-ID: <C62035F9-E7D8-4CA4-89A3-2BE6DE941CE3@amazon.com>
References: <CAMCkG5thP1JnyBn5qAK0TLqBoa-y53Qnoq=mf-NPLfzSF2U7VQ@mail.gmail.com> <5B3455F1-9F82-40C5-BE22-2E3B715A0CF1@canarie.ca> <CAMCkG5uSQzTGCmFn6DLeXVbA0B0wrcPou8CEjtCQ5BCp3M+eOw@mail.gmail.com> <CAMCkG5uff+WwMRLDr+Lph-TagtwL5jWORg5ruvWLOxkNBM2s0A@mail.gmail.com> <E7D14134-0210-4515-ACA3-2AB5CDDCBF34@gmail.com> <CAMCkG5t+7z7OOLdsD77zj_eM7eYf2wOTGTV9tg5S01FXgcHC0w@mail.gmail.com> <8B77A27C-D5B3-477A-BD0D-8B3D3B818BB0@gmail.com> <CA+k3eCQ+f78Ct59D45SyQ8MnCLbpf6665h48MKpyvBaAA-ezZg@mail.gmail.com> <CAMCkG5ssFt2Dy-pbuuEch7KkBu+goNhSbfepx6dVxrUKChBRBw@mail.gmail.com>
In-Reply-To: <CAMCkG5ssFt2Dy-pbuuEch7KkBu+goNhSbfepx6dVxrUKChBRBw@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.26]
Content-Type: multipart/alternative; boundary="_000_C62035F9E7D84CA489A32BE6DE941CE3amazoncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/id-event/WgJnGs1nWOR1DvK17-1tEJ9OYww>
Subject: Re: [Id-event] SAML subject identifier type
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: Tue, 14 Jul 2020 23:54:09 -0000

The RISC Profile’s “ID Token Claims” type does not identify a subject that is an ID Token, it identifies a subject that was the subject of an ID Token. It was intended for cases where the OP sent multiple identifiers of different types in the ID Token (e.g., iss+sub and email), and does not know which of them the client will recognize (yes, the should use iss+sub; no, they doesn’t always do so). This type was replaced in draft-ietf-secevent-subject-identifiers-03 with the “aliases” type, which is a general solution to this problem that is not defined in terms of one particular use case (i.e., ID Tokens).

The OIDF SSE working group’s OAuth Event Types draft<https://openid.net/specs/oauth-event-types-1_0-ID1.html#rfc.section.2.1> defines a “oauth_token” type that identifies a subject that is an OAuth 2.0 token, and does so using either the full or partial plain text value of the token, or a hash of the token.

It is perfectly fine for a token to be the subject of a security event. 8417<https://www.rfc-editor.org/rfc/rfc8417.html#section-2.2> actually includes the following as an example of a possible value for the “sub” claim:
*  a token identifier (e.g. "jti") for a revoked token.

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


From: Id-event <id-event-bounces@ietf.org> on behalf of Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org>
Date: Tuesday, July 14, 2020 at 4:32 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, Chris Phillips <Chris.Phillips@canarie.ca>, "id-event@ietf.org" <id-event@ietf.org>
Subject: RE: [EXTERNAL] [Id-event] SAML subject identifier type


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.


IMO if we have a common enough use-case that requires a specific type to be defined, then we should define that type in the spec rather than rely on an interpretation of the "iss-sub" type, since that interpretation can cause incompatibilities.

In this specific case however I feel that the use cases outlined in my previous email can be achieved (with limitations) using the durable subject types such as email. I'd like the members of the SSE working group to chime in (since that is where this got added), or we can drop the SAML subject identifier type.

On Tue, Jul 14, 2020 at 4:09 PM Brian Campbell <bcampbell@pingidentity.com<mailto:bcampbell@pingidentity.com>> wrote:
+ 1 to what Yaron is saying here. I'd include also the "iss-sub" subject identifier type https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers-05#section-3.4 as already having semantics covering what's described in the ID Token Claims Subject Identifier Type in the RISC document referenced. And all those things represent a durable subject rather than a session, which strikes me as appropriate for a document that describes identifying subjects. A SAML assertion ID, however, which is an identifier of an XML document that is only indirectly related to a session by an association that likely isn't maintained, does not seem appropriate as a "subject identifier".

On Tue, Jul 14, 2020 at 4:01 PM Yaron Sheffer <yaronf.ietf@gmail.com<mailto:yaronf.ietf@gmail.com>> wrote:
Hi Atul,

The ID Token subject type, as described in the document you are referencing, does not add any semantics, compared to a “phone number” or “email” subject type. So I don’t see the value in adding it.

In addition, it does not, actually, describe an ID Token. In fact the text is very clear that it describes a “subject” (a durable entity) rather than a session, and does it by citing various claims included in the ID token. So as a subject identifier type, it is not at all equivalent to a SAML assertion.

As to the SAML Assertion subject type, I think these use cases could be addressed by adding information to the event.

Thanks,
                Yaron

From: Atul Tulshibagwale <atultulshi@google.com<mailto:atultulshi@google.com>>
Date: Tuesday, July 14, 2020 at 23:26
To: Yaron Sheffer <yaronf.ietf@gmail.com<mailto:yaronf.ietf@gmail.com>>
Cc: Chris Phillips <Chris.Phillips@canarie.ca<mailto:Chris.Phillips@canarie.ca>>, "id-event@ietf.org<mailto:id-event@ietf.org>" <id-event@ietf.org<mailto:id-event@ietf.org>>
Subject: Re: [Id-event] SAML subject identifier type

Hi Yaron,
There are a few SSE use cases where the events are about a specific single sign-on session. You're right that this should not be limited to SAML. The RISC profile of SETs (based on which we are doing the SSE work) had the ID Token subject identifier type, which for some reason is missing in this spec (I did not realize until now). The specific events that need to refer to sessions are:
·         Identity provider context change: The conditions under which a SAML assertion or OIDC token was generated are no longer valid. This can be due to various things, including a password change.
·         Session property change: A session has been determined to have been compromised
·         Revocation: The issuer of the single sign-on SAML assertion or ID Token needs to be revoke
I can also add the ID Token claim from the RISC profile<https://bitbucket.org/openid/risc/src/master/openid-risc-profile-1_0.txt#lines-250> to my pull request.

Thanks,
Atul


On Tue, Jul 14, 2020 at 12:32 PM Yaron Sheffer <yaronf.ietf@gmail.com<mailto:yaronf.ietf@gmail.com>> wrote:
I need a lot more context here. So far, subject IDs have denoted durable entities, such as email addresses, phone numbers, account. This is adding a subject ID that denotes an ephemeral entity, basically similar to a session ID. This looks weird from an architectural point of view, and also begs the question, why specifically SAML and not other session types.

Thanks,
                Yaron

From: Id-event <id-event-bounces@ietf.org<mailto:id-event-bounces@ietf.org>> on behalf of Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf..org>>
Date: Tuesday, July 14, 2020 at 00:14
To: Chris Phillips <Chris.Phillips@canarie.ca<mailto:Chris.Phillips@canarie.ca>>
Cc: "id-event@ietf.org<mailto:id-event@ietf.org>" <id-event@ietf.org<mailto:id-event@ietf.org>>
Subject: Re: [Id-event] SAML subject identifier type

Just clarifying the proposal as it stands today (before incorporating Chris's input):
The following section should be added in the "Subject Identifier Types" section:
4.9.  SAML Subject Identifier Type

   The SAML [SAML.REF] Subject Identifier Type describes a subject by
   the assertion identifier in the SAML assertion that was used to
   convey the subject's information to the Receiver.  Subject
   Identifiers of this type MUST contain an ` assertion_id"claim.  The
   value of this claim is a string that is equal to the Assertion
   Identifier in the SAML assertion.  The SAML Subject Identifier Type
   is identified by the name "saml`.

   Below is a non-normative example Subject Identifier for the SAML
   Subject Identifier Type:

   {
     "subject_type": "saml",
     "assertion_id": "_f551d88963ab4e3decb7cfe8f4dcc3f5",
   }

     Figure 8: Example: Subject Identifier for SAML Subject Identifier
                                   Type.


On Mon, Jul 13, 2020 at 1:22 PM Atul Tulshibagwale <atultulshi@google.com<mailto:atultulshi@google.com>> wrote:
Hi Chris,
I was proposing using the "assertion id" (SAML Core<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf> spec, line 553) in the proposal, not the "subject-id" as defined in SAML (spec section 3.3). The main reason was to be able to refer to a session that was established using a specific assertion. If it's useful, we could perhaps extend the SAML subject identifier type in this spec to include either the assertion_id or the subject_id claim.

Thanks,
Atul


On Mon, Jul 13, 2020 at 10:30 AM Chris Phillips <Chris.Phillips@canarie.ca<mailto:Chris.Phillips@canarie.ca>> wrote:
Hi.
Quiet lurker observing..
Thanks for consider the SAML elements..

Atul, are you referring to the actual session identifier that someone may have where the Subject-Id was exchanged OR the actual Subject-id itself in your reference in the proposal with the github link?

I’m trying to square what I see on the git delta on line 294-296 in https://github...com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994<https://github.com/richanna/secevent/pull/1/commits/b20b6692eb50628927476ca78f9be077ace88994>


And a Subject-id as shown in the example in 3.3.3 here: https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1.0-cs01.html#_Toc536097229<https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/cs01/saml-subject-id-attr-v1..0-cs01..html#_Toc536097229>

What you offered in the example is not a Subject-id  per the OASIS SAML spec as written in section 3.3.1

Am I mis-interpreting something?

C


From: Id-event <id-event-bounces@ietf.org<mailto:id-event-bounces@ietf.org>> on behalf of Atul Tulshibagwale <atultulshi=40google.com@dmarc.ietf.org<mailto:40google.com@dmarc.ietf.org>>
Date: Monday, July 13, 2020 at 12:17 PM
To: "id-event@ietf.org<mailto:id-event@ietf.org>" <id-event@ietf.org<mailto:id-event@ietf.org>>
Subject: [Id-event] SAML subject identifier type

Hi all,
Based on the discussions in the SSE working group within the OpenID Foundation, we would like to propose that the subject identifier specification include a SAML subject identifier type. This is so that sessions established across peers using SAML may be identified in events that include the subject identifier.

 A SAML subject identifier has only one claim within it, the assertion id of the SAML assertion used to establish the single sign-on session.

This change is also included in my proposal here<https://github.com/richanna/secevent/pull/1>.

Thanks,
Atul

_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________ Id-event mailing list Id-event@ietf.org<mailto:Id-event@ietf.org> https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Id-event mailing list
Id-event@ietf.org<mailto:Id-event@ietf.org>
https://www.ietf.org/mailman/listinfo/id-event

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.