Section 7 - Security considerations - bearer tokens - WG-UMA - mailman.kantarainitiative.org

newer
Reminder for those convening UMA...

Section 7 - Security considerations - bearer tokens

older
Notes from UMA telecon 2016-10-21

Cigdem Sengul

18 Oct 2016 18 Oct '16

4:20 a.m.

Hello, Eve suggested that I start the discussion about this in the list. Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens. In addition, RFC 6750 recommendations may also be referred to in the draft. Thanks, --Cigdem

Attachments:

attachment.html (text/html — 2.8 KB)

Reply

Sign in to reply online Use email software

Show replies by date

Eve Maler

18 Oct 18 Oct

7:14 a.m.

Thank you, Cigdem! This ties into additional topics in the main body of the spec as well, since we're now up to the point of figuring out things like: - Can we now remove the MTI (mandatory-to-implement) requirement to introspect tokens, and just let RPTs be whatever kind of OAuth access tokens? -If so, if introspected, does the result still have to be profiled due to the resource set superstructure vs just scopes? - What does this mean for the UMA Bearer token profile? Should it go away, morph, stay the same? - What to say explicitly about refresh tokens, if anything? - What to say explicitly about PoP tokens, if anything? Note that we had discussed some of these potential "added options" under the #IoT roadmap item, e.g., being able to do local token validation at the RS instead of introspection at the AS. Oh, and we do have a tiny oblique mention of PoP in the following section ("holder-of-key-type approach")... We might want to update this now that time has marched on, especially once we've figured out our main-spec approach. https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#redirect-thre... Eve Maler (sent from my iPad) | cell +1 425 345 6756

On Oct 18, 2016, at 9:20 AM, Cigdem Sengul wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks, --Cigdem _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

James Phillpotts

8:32 a.m.

Hi Cigdem, Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket. Cheers, James On 18 October 2016 at 09:20, Cigdem Sengul wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks,

--Cigdem

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Cigdem Sengul

9:01 a.m.

Hello James, I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket. For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course. I understand that the choice is left to the implementation which type of tokens to use etc. --Cigdem From: James Phillpotts Date: Tuesday, 18 October 2016 at 13:32 To: Cigdem Sengul Cc: "wg-uma@kantarainitiative.org WG" Subject: Re: [WG-UMA] Section 7 - Security considerations - bearer tokens Hi Cigdem, Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket. Cheers, James On 18 October 2016 at 09:20, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote: Hello, Eve suggested that I start the discussion about this in the list. Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens. In addition, RFC 6750 recommendations may also be referred to in the draft. Thanks, --Cigdem _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Eve Maler

20 Oct 20 Oct

6:56 a.m.

The RPT hasn't been entirely a "plain" OAuth access token in UMA1, which is why I raised all the questions I did regarding UMA2. At least, I think that's true, to the extent that introspecting it would give a very customized answer. Would you agree that's true? My questions in this thread were based on trying to figure out what in our spec should/must/shouldn't change, based on aligning more closely with OAuth current practice, and guessing that whole bunches of stuff could be taken out. Basically, in the case of bearer tokens, could we get rid of the whole notion of an MTI UMA Bearer token profile, and possibly reference 6750, but would we still have to say something about the format of an introspected object (or locally validated token format) that contains explicit resource sets with scopes, vs. just scope strings? And to Cigdem's point, is it worth mentioning PoP tokens and therefore "porting" all of this to a PoP world? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul wrote:

Hello James,

I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket.

For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course.

I understand that the choice is left to the implementation which type of tokens to use etc.

--Cigdem

*From: *James Phillpotts *Date: *Tuesday, 18 October 2016 at 13:32 *To: *Cigdem Sengul *Cc: *"wg-uma@kantarainitiative.org WG" *Subject: *Re: [WG-UMA] Section 7 - Security considerations - bearer tokens

Hi Cigdem,

Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket.

Cheers, James

On 18 October 2016 at 09:20, Cigdem Sengul wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks,

--Cigdem

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Justin Richer

21 Oct 21 Oct

3:31 p.m.

In my view, the RPT has *always* been an access token, so I don’t agree with Eve’s stance below. The UMA2 work is aligning more explicitly with how I’d personally always looked at it. That said, I’ve also never been a fan of the token profiles and other extension-from-zero-examples aspects of UMA. It’s my personal preference to get rid of them until such time as they’re needed and there’s a demonstrable thing to extend it with in a meaningful way. The problem with having an extension point and only one thing defined in it is that it invites implementors to get lazy and assume that things will always be this way. I think we’ve already seen this with most OAuth clients and the “token_type” parameter for bearer tokens. Since bearer tokens are the only tokens that shipped in 2012 (the MAC token spec got dropped by the group at the time), most OAuth clients don’t even check the field when parsing the token response. I wouldn’t be surprised if the same kind of assumptions were true of UMA1 implementations (I’m pretty sure it’s true of ours, at least). So with that in mind, I don’t really think that we need the profile/extension points (and associated MTI) as they are written in to UMA1. — Justin

On Oct 20, 2016, at 3:56 AM, Eve Maler wrote:

The RPT hasn't been entirely a "plain" OAuth access token in UMA1, which is why I raised all the questions I did regarding UMA2. At least, I think that's true, to the extent that introspecting it would give a very customized answer.

Would you agree that's true? My questions in this thread were based on trying to figure out what in our spec should/must/shouldn't change, based on aligning more closely with OAuth current practice, and guessing that whole bunches of stuff could be taken out.

Basically, in the case of bearer tokens, could we get rid of the whole notion of an MTI UMA Bearer token profile, and possibly reference 6750, but would we still have to say something about the format of an introspected object (or locally validated token format) that contains explicit resource sets with scopes, vs. just scope strings? And to Cigdem's point, is it worth mentioning PoP tokens and therefore "porting" all of this to a PoP world?

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote: Hello James,

I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket.

For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course.

I understand that the choice is left to the implementation which type of tokens to use etc.

--Cigdem

From: James Phillpotts mailto:james.phillpotts@forgerock.com> Date: Tuesday, 18 October 2016 at 13:32 To: Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> Cc: "wg-uma@kantarainitiative.org mailto:wg-uma@kantarainitiative.org WG" mailto:wg-uma@kantarainitiative.org> Subject: Re: [WG-UMA] Section 7 - Security considerations - bearer tokens

Hi Cigdem,

Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket.

Cheers, James

On 18 October 2016 at 09:20, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks,

--Cigdem

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Eve Maler

5:37 p.m.

Okay. I certainly understand the direction and the desire. That said, in UMA1, how do you deal with the MTI token profile, if at all? Did you implement it but not use it with any clients? When it comes to the resource set ID layer of permissions, do you just hand over a pile of scopes to the RS that happen to be named in such a way that they don't overlap per resource set ID? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Oct 21, 2016 at 12:31 PM, Justin Richer wrote:

In my view, the RPT has *always* been an access token, so I don’t agree with Eve’s stance below. The UMA2 work is aligning more explicitly with how I’d personally always looked at it.

That said, I’ve also never been a fan of the token profiles and other extension-from-zero-examples aspects of UMA. It’s my personal preference to get rid of them until such time as they’re needed and there’s a demonstrable thing to extend it with in a meaningful way. The problem with having an extension point and only one thing defined in it is that it invites implementors to get lazy and assume that things will always be this way. I think we’ve already seen this with most OAuth clients and the “token_type” parameter for bearer tokens. Since bearer tokens are the only tokens that shipped in 2012 (the MAC token spec got dropped by the group at the time), most OAuth clients don’t even check the field when parsing the token response. I wouldn’t be surprised if the same kind of assumptions were true of UMA1 implementations (I’m pretty sure it’s true of ours, at least).

So with that in mind, I don’t really think that we need the profile/extension points (and associated MTI) as they are written in to UMA1.

— Justin

On Oct 20, 2016, at 3:56 AM, Eve Maler wrote:

The RPT hasn't been entirely a "plain" OAuth access token in UMA1, which is why I raised all the questions I did regarding UMA2. At least, I think that's true, to the extent that introspecting it would give a very customized answer.

Would you agree that's true? My questions in this thread were based on trying to figure out what in our spec should/must/shouldn't change, based on aligning more closely with OAuth current practice, and guessing that whole bunches of stuff could be taken out.

Basically, in the case of bearer tokens, could we get rid of the whole notion of an MTI UMA Bearer token profile, and possibly reference 6750, but would we still have to say something about the format of an introspected object (or locally validated token format) that contains explicit resource sets with scopes, vs. just scope strings? And to Cigdem's point, is it worth mentioning PoP tokens and therefore "porting" all of this to a PoP world?

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul wrote:

...
Hello James,

I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket.

For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course.

I understand that the choice is left to the implementation which type of tokens to use etc.

--Cigdem

*From: *James Phillpotts *Date: *Tuesday, 18 October 2016 at 13:32 *To: *Cigdem Sengul *Cc: *"wg-uma@kantarainitiative.org WG" *Subject: *Re: [WG-UMA] Section 7 - Security considerations - bearer tokens

Hi Cigdem,

Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket.

Cheers, James

On 18 October 2016 at 09:20, Cigdem Sengul wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks,

--Cigdem

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

Justin Richer

22 Oct 22 Oct

1:55 p.m.

We just implement the only option (which is MTI) and don’t check any of the “here’s what’s implemented” fields. This is what I mean by a lazy implementation of a single option in an extension point. There’s not really anything profiled here other than the introspection response. The RS’s use that to determine whether the call being made applies to them. There’s no real worry or danger of scope overlap with the way the data structures are set up: scopes are subservient to resource set identifiers. Since the resource set gets to define the scope (and really, its’ the API the resource set is providing that defines the scope), then there’s no chance of overlap because it’s all internal to the resource set. There is zero need for profiling to make that work. — Justin

On Oct 21, 2016, at 2:37 PM, Eve Maler wrote:

Okay. I certainly understand the direction and the desire. That said, in UMA1, how do you deal with the MTI token profile, if at all? Did you implement it but not use it with any clients? When it comes to the resource set ID layer of permissions, do you just hand over a pile of scopes to the RS that happen to be named in such a way that they don't overlap per resource set ID?

Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Fri, Oct 21, 2016 at 12:31 PM, Justin Richer mailto:jricher@mit.edu> wrote: In my view, the RPT has *always* been an access token, so I don’t agree with Eve’s stance below. The UMA2 work is aligning more explicitly with how I’d personally always looked at it.

That said, I’ve also never been a fan of the token profiles and other extension-from-zero-examples aspects of UMA. It’s my personal preference to get rid of them until such time as they’re needed and there’s a demonstrable thing to extend it with in a meaningful way. The problem with having an extension point and only one thing defined in it is that it invites implementors to get lazy and assume that things will always be this way. I think we’ve already seen this with most OAuth clients and the “token_type” parameter for bearer tokens. Since bearer tokens are the only tokens that shipped in 2012 (the MAC token spec got dropped by the group at the time), most OAuth clients don’t even check the field when parsing the token response. I wouldn’t be surprised if the same kind of assumptions were true of UMA1 implementations (I’m pretty sure it’s true of ours, at least).

So with that in mind, I don’t really think that we need the profile/extension points (and associated MTI) as they are written in to UMA1.

— Justin

...
On Oct 20, 2016, at 3:56 AM, Eve Maler mailto:eve@xmlgrrl.com> wrote:

The RPT hasn't been entirely a "plain" OAuth access token in UMA1, which is why I raised all the questions I did regarding UMA2. At least, I think that's true, to the extent that introspecting it would give a very customized answer.

Would you agree that's true? My questions in this thread were based on trying to figure out what in our spec should/must/shouldn't change, based on aligning more closely with OAuth current practice, and guessing that whole bunches of stuff could be taken out.

Basically, in the case of bearer tokens, could we get rid of the whole notion of an MTI UMA Bearer token profile, and possibly reference 6750, but would we still have to say something about the format of an introspected object (or locally validated token format) that contains explicit resource sets with scopes, vs. just scope strings? And to Cigdem's point, is it worth mentioning PoP tokens and therefore "porting" all of this to a PoP world?

Eve Maler Cell +1 425.345.6756 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote: Hello James,

I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket.

For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course.

I understand that the choice is left to the implementation which type of tokens to use etc.

--Cigdem

From: James Phillpotts mailto:james.phillpotts@forgerock.com> Date: Tuesday, 18 October 2016 at 13:32 To: Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> Cc: "wg-uma@kantarainitiative.org mailto:wg-uma@kantarainitiative.org WG" mailto:wg-uma@kantarainitiative.org> Subject: Re: [WG-UMA] Section 7 - Security considerations - bearer tokens

Hi Cigdem,

Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket.

Cheers, James

On 18 October 2016 at 09:20, Cigdem Sengul mailto:Cigdem.Sengul@nominet.uk> wrote:

Hello,

Eve suggested that I start the discussion about this in the list.

Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.

In addition, RFC 6750 recommendations may also be referred to in the draft.

Thanks,

--Cigdem

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Reply

Sign in to reply online Use email software

2890

Age (days ago)

2894

Last active (days ago)

Download

7 comments

4 participants

tags

participants (4)

Cigdem Sengul
Eve Maler
James Phillpotts
Justin Richer