Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

[Richard Barnes <[e-mail]>]

On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones <[e-mail]>
wrote:

> Thanks for your review, Richard.  I'm replying to your DISCUSS about the
> audience being required below...
>
>                                 -- Mike
>
> > -----Original Message-----
> > From: OAuth [mailto:[e-mail]] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 15, 2014 8:48 PM
> > To: The IESG
> > Cc: [e-mail];
> [e-mail];
> > [e-mail]
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> draft-ietf-oauth-assertions-17:
> > (with DISCUSS and COMMENT)
> >
> > Richard Barnes 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:
> > ----------------------------------------------------------------------
> >
> > "The assertion MUST contain an Audience that identifies the Authorization
> > Server as the intended audience.  Assertions that do not identify the
> > Authorization Server as an intended audience MUST be rejected."
> >
> > Could you please identify the threat model within which this "MUST" is
> required?
> > This requirement doesn't follow from any of the threats elaborated in
> Section 8.
>
> Sure, this is to prevent a legitimate assertion intended for one
> authorization server being captured by the attacker and sent to a different
> authorization server.  Unless there's an audience for the authorization
> server to check, there's no way for the authorization server to reject
> assertions intended to be used by a different server.  Using the audience
> is the normal way to prevent this attack.
>

That all assumes that the issuer of the assertion intends to limit it to a
specific authorization server.  That is not the case with many assertion
systems today, e.g., PKIX.



> > The Audience is only necessary if the Issuer wishes to constrain the set
> of
> > Authorization Servers with which an assertion may be used.  So ISTM that
> this
> > should be "MAY contain..."
>
> Constraining the set to the intended server is basic to the security
> guarantees.  If I can take a server intended for server1 and get server2 to
> accept it, all security bets are off.
>

That's dramatically overstating things.  The only security bet that is off
in that case is that the assertion is not limited to one authorization
server.  Which may or may not be the issuer's intent.

The only thing I could see justifying this requirement is something in the
overall OAuth architecture that requires authorizations to be scoped to a
specific authorization server.  If that exists, add a citation and I'll
clear.  Otherwise, this needs to be un-MUST-ed.

--Richard




>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > "keyed message digest" -> "Message Authentication Code"
> >
> > That's the proper terminology [RFC4949], especially since there are MACs
> that
> > are not based on digests.
> >
> > "This mechanism provides additional security properties." -- Please
> delete this or
> > elaborate on what security properties it provides.
> >
> > Section 8.2 should note that "Holder-of-Key Assertions" are also a
> mitigation for
> > this risk.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>