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 3:20 PM, Richard Barnes <[e-mail]> wrote:

> You guys are all arguing that having an Audience can be useful.  I don't
> disagree.  I disagree that it should be REQUIRED in all cases.
>
> The Google vulnerability that Brian raised was an interesting read, but as
> John points out, it only applies to Bearer Assertions.  There's no security
> requirement at all for holder-of-key assertions to have an audience, since
> they can't be replayed by someone who doesn't hold the key.
>
> I could agree that an audience should be REQUIRED for bearer assertions.
> Since they are vulnerable to replay, Audience protects against the
> Authorization Server re-using the token.  (It would be good to say this
> explicitly in the doc, actually.)  But for holder-of-key assertions, the
> Audience should be OPTIONAL.  Note that this requires that instance
> documents define the difference between bearer assertions and holder-of-key
> assertions, so that implementations can enforce these requirements.
>
> So it seems like there are two solutions here:
> 1. Scope the document to bearer assertions only, and keep the MUST
> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key
> assertions, and define the difference in the instance docs.
>

I'll also offer a third resolution:
3. Show me that the WG discussed this question and made the decision to
forbid holder-of-key assertions without an Audience parameter.

--Richard




> --Richard
>
>
>
>
>
>
> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <[e-mail]> wrote:
>
>> It is also important for a non-protocol purpose. Liability.
>>
>> If a 3rd party uses an assertion that was not intended for it, it cannot
>> obviously hold the asserting party responsible.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> [e-mail]
>>
>>
>>
>> On Oct 16, 2014, at 8:43 AM, Brian Campbell <[e-mail]>
>> wrote:
>>
>> Thanks for your review and feedback, Richard. Replies are inline below...
>>
>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <[e-mail]> wrote:
>>
>>> 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.
>>>
>>> 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..."
>>>
>>>
>>
>> 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 else 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.
>>
>> Strictly speaking, you are right that the audience is only necessary if
>> the Issuer wishes to constrain the set of Authorization Servers with which
>> an assertion may be used. But the Issuer really really really should make
>> that constraint and fully understanding the implications of not doing so is
>> difficult and unlikely.
>>
>> There was a vulnerability in Google apps SAML a few years back that
>> demonstrates how important audience restriction is and how it can be
>> difficult for even very sophisticated providers to get it all right. I
>> haven't had time to read it again to make sure but I think that this is the
>> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
>>
>> I don't see what value allowing audience to be omitted brings other than
>> that it is academically a possibility. But requiring it (hopefully, if the
>> requirement is followed) helps reduce the possibility of a whole bunch of
>> security problems that folks likely won't foresee.
>>
>>
>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> "keyed message digest" -> "Message Authentication Code"
>>>
>>> That's the proper terminology [RFC4949], especially since there are MACs
>>> that are not based on digests.
>>>
>>
>> OK
>>
>>
>>>
>>> "This mechanism provides additional security properties." -- Please
>>> delete this or elaborate on what security properties it provides.
>>>
>>
>> Will delete.
>>
>>
>>>
>>> Section 8.2 should note that "Holder-of-Key Assertions" are also a
>>> mitigation for this risk.
>>>
>>>
>> OK
>>
>>
>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>