Subject: [OAUTH-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS)

From: "Ted Lemon" <[email-masked]>
Date: Thu, 16 Oct 2014 06:07:58 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This has probably already been considered and addressed by the working
group, but coming into this as a neophyte it seems like a glaring
omission that the security considerations of bearer assertions are not
discussed here.   Isn't it the case that the use of bearer assertions
requires a trust relationship between the client and relying party such
that the client can be assured that the relying party will not misuse the
assertion to authenticate with some other entity?   I realize that this
sort of assertion will likely only be used in cases where the assertion
only works to authenticate to a specific relying party, but I think this
bears mentioning in the security considerations.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 08:59:59 -0600

I realized that I'd accidentally replied only to Ted in this thread (email
is hard!). So I wanted to send our discussion to the original cc list so
it'd be more on the record and also because I believe this discussion is
related to, and may help inform, some other comments that came in this
morning.

---------- Forwarded message ----------
From: Brian Campbell <[email-masked]>
Date: Thu, Oct 16, 2014 at 8:34 AM
Subject: Re: [OAUTH-WG] Ted Lemon's Discuss on
draft-ietf-oauth-assertions-17: (with DISCUSS)
To: Ted Lemon <[email-masked]>

On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon <[email-masked]> wrote:

> On Oct 16, 2014, at 8:37 AM, Brian Campbell <[email-masked]>
> wrote:
> > It's a good question Ted, thanks for your review. The concern is
> mitigated by the requirement in §5.2 (third bullet
> https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-5.2)
> which requires that these bearer assertions be audience restricted.
> Assertions with audience restrictions can only be used at the specific
> relying party(s) to whom they were addressed.
> >
> > So I think the concern is addressed in processing rules of the draft.
> But do you think it should also be mentioned in the security considerations?
>
> Hm, interesting.   I didn't connect that, because I assumed that while a
> bearer assertion could be issued for a particular relying party, other
> assertions might be issued for other relying parties using the same token.
>  This could be either because of some policy on the client, or because the
> end-user just types in the same token in several places, as is
> unfortunately common practice with user passwords.
>
> So I guess I think a bit more discussion is warranted, but it may be that
> my concern is based on a misunderstanding of how bearer assertions are
> generated, in which case the discussion may not be necessary.   So I guess
> the question is, am I misunderstanding something here that makes this
> concern not an issue?
>
>
Typically an assertion will be issued for use at a specific relying party
in a specific context (like one of these profiles or for web single
sign-on) . And it will be time limited to something on the order of minutes
or maybe hours but not longer. The assertion is the token. It carries
information about the user and how they authenticated (how is not dictated
here but the assertion can describe it to the relying party) with the
assertion issuer. But it's not something that the user would ever type in
or even see or be aware of in most cases. The audience restriction let's
the issuer say specifically what relying party is allowed to consume the
assertion, which ensures that the client can't use it somewhere that it
wasn't intended and that the relying party that receives the assertion
can't turn around and use it to access some other service.

Is this helping your understanding or just confusing matters?