Re: [OAUTH-WG] draft-ietf-oauth-assertions-09

Brian Campbell <bcampbell@pingidentity.com> Fri, 11 January 2013 17:51 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29CA21F8994 for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 09:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.676
X-Spam-Level:
X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_EMAIL=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3VP3ULWSv2d for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 09:51:46 -0800 (PST)
Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3748521F894C for <oauth@ietf.org>; Fri, 11 Jan 2013 09:51:42 -0800 (PST)
Received: from mail-ob0-f198.google.com ([209.85.214.198]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKUPBRLEBp37Fe7E/sDZhFNPkO1PNGIVuN@postini.com; Fri, 11 Jan 2013 09:51:42 PST
Received: by mail-ob0-f198.google.com with SMTP id un3so9376301obb.1 for <oauth@ietf.org>; Fri, 11 Jan 2013 09:51:39 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=tcjr/tVpIH/9fc2AS5CgtTrFHibLEYffWdtZTTnWBfc=; b=nXjPEQRT3PAL+9+bb8m2/9oyTSUtIPNgL9Kr4Sx5wvUHJfrqEhOlnAmqR/Bw2dgzoU zvyzmTZKf8w42LtIrWegFl+ByEZTJ4vLBPFEmeioqSEj+FkkfqZ5PLBoJnPQQkJH2Tzh /Yx2nZG8zhtM9XvRhaVEX2wZvj/5Bl7vKNDvlb1utas7USij69mdv3yMP85u6ScvA5e3 jrBPxCtKjn4Vs0K38K4ZeW403tfe2P+xw06Vr+0wP8P432SwfLf7pb6tN4/si7Z2ogw0 aIQau7LIhx0zHGZZLxKZezZ9/NmNSXx2v17EKNRyxVLmU6iTawcL9TJ1sJjYFfOuF7tA 0gfg==
X-Received: by 10.50.214.39 with SMTP id nx7mr2494620igc.101.1357926699737; Fri, 11 Jan 2013 09:51:39 -0800 (PST)
X-Received: by 10.50.214.39 with SMTP id nx7mr2494614igc.101.1357926699581; Fri, 11 Jan 2013 09:51:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Fri, 11 Jan 2013 09:51:09 -0800 (PST)
In-Reply-To: <E8B38B05-4600-4EC8-8B76-C9010603E640@ve7jtb.com>
References: <A1DF5DE7-CC32-48CE-A33E-81BC2968DF14@gmx.net> <50EFF7F0.90300@cs.tcd.ie> <B33BFB58CCC8BE4998958016839DE27E0687634C@IMCMBX01.MITRE.ORG> <E8B38B05-4600-4EC8-8B76-C9010603E640@ve7jtb.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 11 Jan 2013 10:51:09 -0700
Message-ID: <CA+k3eCQeR1u=vNpjx4bct4TL5_a+fayj6tYYeZR7q5UxQu8e7g@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="14dae93406e38f42a304d306f21d"
X-Gm-Message-State: ALoCoQnBGod7CaFUt94GfIdPRPy1VpU8P8ZoeTahc+wQGCZPYgQxQk5p2aN8eTCLAG4ahW+a4htxKM38FA45ymiuDckUzUeZ+xmVWLp84JKSmhD/V/hDM9F+O8E4vEuW2ukhddOyPX2U
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-09
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jan 2013 17:51:55 -0000

That text around audience in the framework spec changed from a SHOULD to a
MAY in -09 so that it would be more consistent with the the SAML and JWT
versions, which were already using a MAY in that context.

Your concern is valid Hannes and your point is taken. But reality is rather
messy and I don't believe it can addressed as easily as you suggest.

In SAML, for example, an entity identifier is often used as a value for the
audience (per spec and in practice).  But an AS may not necessarily
identify itself with a full blown SAML entity, in which case the token
endpoint URI is more appropriate. The whole issue is also somewhat
complicated in SAML too by it having both audience and recipient that are
similar but not the same. I've tried to account for all of this in the SAML
doc but it's admittedly somewhat awkward and complex and not as simple as
saying the value has to be X and must be validated in exactly such a way.

JWT doesn't have the same history and baggage of SAML but is subject to
many of the same real world deployment variations.

I'm definitely open to improvements with respect to the handling of
audience values but I believe anything that is done needs to reflect the
realities of current implementations and deployments as well as related
specifications.,



On Fri, Jan 11, 2013 at 8:55 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Yes in assertions it needs to be general.  It is the JWT and SAML profiles
> that need to nail down what the format of the audience is.    They should
> probably both be the URI of the token endpoint.   In both SAML and JWT
> there can be multiple audiences for the token.
>
> John
> On 2013-01-11, at 11:37 AM, "Richer, Justin P." <jricher@mitre.org> wrote:
>
> > It's my understanding that the general assertions claim is more of a
> conceptual mapping than it is a concrete encoding, so anything more
> specific here would be out of place. I would like the authors to either
> confirm or correct my assumptions, though.
> >
> > -- Justin
> >
> >
> > On Jan 11, 2013, at 6:30 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> > wrote:
> >
> >>
> >> Hi,
> >>
> >> Since we thought we were done with it, I put this document
> >> on the IESG telechat agenda for Jan 24. Hannes' question
> >> however looks like its a real one that needs an answer.
> >>
> >> I'd appreciate it if the WG could figure out if there's any
> >> change needed and either make that change in the next week,
> >> or else tell me to take the draft off the telechat agenda
> >> for now.
> >>
> >> If discussion doesn't happen, or happens but doesn't reach
> >> a conclusion, then I'll take the draft off the agenda in a
> >> week's time and we can sort out if any changes are needed
> >> later.
> >>
> >> The reason why now+1-week matters, is that that's when
> >> IESG members tend to do their reviews and having 'em all
> >> review a moving target isn't a good plan.
> >>
> >> Thanks,
> >> S.
> >>
> >> On 01/11/2013 08:18 AM, Hannes Tschofenig wrote:
> >>> Hi guys,
> >>>
> >>> Thanks for updating the assertion document and for incorporating the
> comments received on the mailing list.
> >>>
> >>> There is only one issue that caught my attention. You changed the
> description of the audience element to the following text (in version -09
> of http://tools.ietf.org/html/draft-ietf-oauth-assertions-09):
> >>> "
> >>>  Audience  A value that identifies the parties intended to process the
> >>>     assertion.  An audience value MAY be the URL of the Token Endpoint
> >>>     as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> >>> "
> >>>
> >>> Since the value in the audience field is used to by the authorization
> server in a comparison operation (see Section 5.2) I believe the current
> text will lead to interoperability problems. Not only is the comparision
> operation unspecified but even the value that is contained in the field is
> left open. The RFC 2119 MAY does not really give a lot of hints of what
> should be put in there.
> >>>
> >>> Without having a clear description of what identifier is contained in
> this field and how the comparison works it is either possible that a
> legitimate client is rejected by the authorization server (which is
> annoying) or an assertion with an incorrect assertion is accepted (which is
> a security problem).
> >>>
> >>> Btw, the same issue can also be seen in
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04,
> http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15 and in a more
> generic form also in the JWT (Section 4.1.3 of
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06; "aud"
> claim). From the description in the JWT document I was not quite sure
> whether the ability to carry an array of case sensitive strings for that
> field is also allowed in any of the assertion documents.
> >>>
> >>> Note that there are two documents that provide input to this problem
> space, namely:
> >>> http://tools.ietf.org/html/rfc6125
> >>> http://tools.ietf.org/html/draft-iab-identifier-comparison-07
> >>>
> >>> So, I would suggest to decide what type of identifier goes into this
> field and then to point to a document that illustrates how the comparison
> operation would look like. Possible identifiers are domain names, IP
> addresses, URIs, etc. Just as an example from RFC 6125 would you allow a
> wildcard match (like "*.example.com") or only an equality match? Would "
> www.example.com" be the same as "example.com" if they resolve to the same
> IP address(es)?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>