+1
This is the standard mitigation for a known set of actual attacks. We
shouldn't even consider making it optional.
-- Mike
From: OAuth [mailto:[email protected]] On Behalf Of Phil Hunt
Sent: Friday, October 17, 2014 9:50 AM
To: John Bradley
Cc: [email protected]; Richard Barnes;
[email protected]; The IESG; oauth
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)
I believe that if you make "aud" optional, it only helps the simplistic
deployment scenarios where there is only one RS and one AS. The optionality
itself will cause more confusion. In the simplistic case, the AS and RS simply
have to agree on a URI.
In more sophisticated domains where there is more than one RS service, the
"aud" value is expected and is useful to determining who a token is intended
for.
Finally, there is the 3rd level case where the AS and the RS are in separate
domains (federated). In this case, we can expect inter-op to be required
between separate vendors as a majority of cases.
Making "aud" optional will greatly increase complexity in reality. Making it a
MUST only puts a trivial imposition on the trivial case (they have to provide a
made up URI).
We did not really discuss "aud" much on the list because it is well known
industry practice. I would not want to suggest re-writing something that works
well.
Phil
@independentid
www.independentid.com<http://www.independentid.com>
[email protected]<mailto:[email protected]>
On Oct 17, 2014, at 9:01 AM, John Bradley
<[email protected]<mailto:[email protected]>> wrote:
I am good with it as is. I think we have the flexibility to add HoK later.
I mostly wanted to point out that it is really only in that later HoK profile
where omitting audience is safe.
If I had the power to remove the DISCUS I would.
John B.
On Oct 17, 2014, at 12:56 PM, Brian Campbell
<[email protected]<mailto:[email protected]>> wrote:
These drafts define the use of bearer assertions. The only mention of HoK style
assertions is at the end of
https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which
notes that the "rules defined in this document are intended to support a client
presenting a bearer assertion to an authorization server. The use of
holder-of-key assertions are not precluded by this document, but additional
protocol details would need to be specified."
The requirement of having audience is for bearer assertions only (and we agree
need to be that way for bearer) and not intended to preclude anything for HoK
assertions.
Does that change your opinion? Is there something that could be added or
removed or clarified to allay concerns?
On Thu, Oct 16, 2014 at 6:54 PM, John Bradley
<[email protected]<mailto:[email protected]>> wrote:
Holder of key JWT is still in draft and we don't have a clear way to present
the proof to the token endpoint.
Brian and I started discussing that last week as I happen to have a use case
for a PoP JWT assertion flow in some other spec work.
I think that there is enough difference between bearer and PoP that doing a
follow on profile for SAML and JWT that can also cover the proof presentment
mechanisms makes the most sense.
I would go with restricting this to Bearer and MUST for audience, and removing
the audience requirement explicitly in the PoP profiles.
There are people who need the bearer version 6 months ago, I don't want to do
anything to hold it up based on future work.
I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML subject
confirmation stuff is relatively clear so it is mostly defining the presentment
mechanisms like mutual TLS and a self signed assertion. (we need to be careful
not to conflate client authentication and token proof, as they are different
and might both be used at the same time.
John B.
On Oct 16, 2014, at 7:20 PM, Richard Barnes <[email protected]<mailto:[email protected]>>
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.
--Richard
On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt
<[email protected]<mailto:[email protected]>> 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<http://www.independentid.com/>
[email protected]<mailto:[email protected]>
On Oct 16, 2014, at 8:43 AM, Brian Campbell
<[email protected]<mailto:[email protected]>> wrote:
Thanks for your review and feedback, Richard. Replies are inline below...
On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
