Re: [Ace] WGLC for draft-ietf-ace-authz
This sounds like a good solution, Ludwig. Thanks for the productive conversation. -- Mike -Original Message- From: Ludwig Seitz Sent: Wednesday, October 31, 2018 2:08 AM To: Mike Jones ; ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz On 30/10/2018 19:52, Mike Jones wrote: > Thanks for your responses, Ludwig. > > > I could live with "access_token" having a single-byte representation, > since as you point out, it is needed for every ACE OAuth interaction. > An "error" value is only needed when something goes wrong, so that > doesn't seem like a case that needs to be optimized for space. A > two-byte "error" representation will only be used when errors have > occurred, so shouldn't be a problem. > > -- Mike > > -Original Message- From: Ace On Behalf Thank you for the quick and comprehensive answer Mike! I conclude the following: We are in agreement about giving "profile", "error", "token_type" and "grant_type" two-byte abbreviations in CBOR. "scope" and "access_token" will get a one-byte abbreviation aligned with the unused numbers from CWT claims. At IETF 103 I will propose the solution of registering all parameter abbreviations in the CWT claim registry in order to align abbreviations and avoid duplicate assignments. If a signed request (and response) format is needed I am all for using CWT in the context of ACE access token requests, responses and introspection requests and responses. I will take up that discussion at IETF 103. I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from the OAuth 2.0 specs and defining the default token type to be "PoP" and the default grant_type to be "client_credentials". This will avoid having to send grant_type with every access token request and token_type with every successful access token response. Regards, Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
> -Original Message- > From: Ludwig Seitz > Sent: Tuesday, October 30, 2018 3:20 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > au...@ietf.org > Cc: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 22/10/2018 21:09, Jim Schaad wrote: > > > > > * Registries - I am wondering if we should think about re-writing a > > couple of the registries. As things stand it appears that the > > application/ace+cbor content type is being used in 5 or 6 places. It > > might make more sense to have a registry for all of the CBOR > > abbreviations that are being used in a single table and have multiple > > columns for each of the different places were the content format is > > being used. This would make it easier to keep everything constant and can > make re-use of integer values easier to see. > > > > Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is > clear that the whole registry process needs a second (third, n-th) go-over. > > I'd very much like to have all abbreviations in a single table, however some > of > them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where > to do the table, since I'd like to have the parameters from there in it. While it has some "goodness" to have all of the abbreviations in a single table, in the end that single table is going to be a registry that is maintained by IANA. This allows multiple documents to create the abbreviations and not have any overlap. I would just leave the items in oauth-params there and let them be registered on their own. Jim \> > > /Ludwig > > > -- > Ludwig Seitz, PhD > Security Lab, RISE > Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
> -Original Message-
> From: Ace On Behalf Of Ludwig Seitz
> Sent: Tuesday, October 30, 2018 5:13 AM
> To: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>
> On 25/10/2018 02:58, Mike Jones wrote:
> > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between
> > many of the CBOR numeric values used in this this specification and
> > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the
> > relationship is currently unspecified and the goals behind it are
> > undefined. The spec should be augmented to make the nature and goals
> > of this relationship explicit. I infer that there's such a
> > relationship because the Mapping Parameters to CBOR in Section 5.6.5
> > apparently carefully do not overlap with the values registered in the
> > IANA CWT Claims registry at
> > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection
> > mappings in Section 5.7.4 apparently carefully use the same values as
> > CWT for the same things, but then adds additional values. And some of
> > these values are the same as values proposed for the CWT Claims
> > registry in 8.13. This has to be more than a coincidence but the spec
> > doesn't currently say why.
>
> For example in "5.6.5 Mapping Parameters to CBOR" there is this:
>
> "Note that we have aligned these abbreviations with the claim
> abbreviations defined in [RFC8392]."
>
> I can add some text to explain that this makes it easier to manage the
> abbreviations in code (no need to handle complex namespace issues, when
> you just use one abbreviation space). Would that address the "to make the
> nature and goals of this relationship explicit." part of your comment?
I think that this should be lost as a requirement in the document. I don't
think it makes it any easier to deal with things by having the abbreviations
from two different things line up to be the same. They need to be dealt
with on their own in code anyway.
>
> >
> > Per my earlier reviews of the ace-authz spec, I believe that the ACE
> > OAuth parameters should all be registered in the CWT Claims registry
> > because of the possibility of them being used in signed requests in a
> > manner analogous to
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The
> > parameters need to be registered to avoid future claim number
> > conflicts. While conflicts have clearly been carefully avoided to
> > date, they will inevitably occur in the future unless the values are
> > actually registered. Please do so.
> >
>
> I have avoided doing this so far, since there was no precedent from
> OAuth on doing so (registering OAuth req/resp parameters as JWT claims)
> and I was trying to align with OAuth in that respect.
> For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of
> the classical OAuth req/resp parameters as JWT claims ("This
> specification requests no actions by IANA.")
>
> How is the position of the OAuth WG on this?
>
> > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all
> instances
> > of numbers to be assigned by designated experts in existing
> > registries from specific values to "TBD". For instance, all the
> > values for the CWT Claims Registry in Section 8.13 (currently 12, 16,
> > and 17) should be changed to TBD. Our chair, Jim Schaad has been a
> > vigorous advocate of not squatting in my past interactions with him
> > as a Designated Expert and I believe would support this request.
> > Likewise, the "19" in the CoAP Content-Format Registration in Section
> > 8.15 should become TBD.
> >
> I get your point.
>
> Any hints on how one usually do that while still providing provisory
> numbers for interop tests?
Generally this is done by assigning temp numbers from a private number space
that are then changed at the time of registration. Additionally one can ask
for early registrations to occur. This is done at the discretion of the
chairs.
>
> > req_aud: Several examples use the "req_aud" parameter without
> > defining it. Doesn't this duplicate the "resource" parameter defined
> > by
> > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?
> > If so, please delete this parameter and use "resource". If not, say
> > how it is different and why the differences are necessary.
> >
> > rs_cnf: There isn't a clear normative definition of this parameter.
> > It's mentioned obliquely but its purpose, syntax, and semantics
> > should be plainly stated (as with each other newly defined
> > parameter).
Re: [Ace] WGLC for draft-ietf-ace-authz
Mike, Writing a document to do this is easy. I am not clear that there is anybody that is going to implement this. Are industries such as banking going to abandon JWT for CWT? Jim > -Original Message- > From: Ace On Behalf Of Mike Jones > Sent: Tuesday, October 30, 2018 11:52 AM > To: Ludwig Seitz ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > Thanks for your responses, Ludwig. > > Responding to your point about "Note that we have aligned these > abbreviations with the claim abbreviations defined in [RFC8392]." The point > of the alignment was to enable signed requests to be expressed as CWTs - > just as OAuth signed requests are expressed as JWTs. But given the high > likelihood of numeric CWT claim collisions with unregistered OAuth request > number values assigned by the spec, this won't actually work in the long term > unless the request parameters are registered as CWT claims. Collision-free > alignment without IANA registration is a fleeting situation. Please make the > alignment permanent by registering the needed claims. > > I get Jim's point that there are other ways to do signed requests. If this > working group wants to define a different signed request syntax for ACE > OAuth requests than CWTs, that's fine, but if so, please do so before this > draft finishes. If a different signed request format is used, I'll note that > there's no need for claim alignment with CWT [RFC8392] - in which case the > draft should probably abandon it up front. I'll note that abandoning the > current alignment is more work and would be more confusing to > implementers than simply using CWTs but multiple choices are possible. The > most important thing is to pick one now. Industries such as banking are > REQUIRING signed requests. > > Since you asked about signed responses, those are also in the works for > OAuth, for the same reasons - including requirements from the banking > industry. See https://openid.net/specs/openid-financial-api-jarm.html. (Just > as the OpenID Foundation standardized signed requests in 2014 in > https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in > 2014 and then an IETF version was created, signed responses are currently > on a similar trajectory.) > > Per your question about values in IANA registries to be assigned by > designated experts being TBD, the normal way of providing short-term > values for interop purposes is to say "TBD (maybe ). For > instance, you'll see that usage at https://tools.ietf.org/html/draft-ietf-ace- > cwt-proof-of-possession-03#section-7.1.1. > > I could live with "access_token" having a single-byte representation, since as > you point out, it is needed for every ACE OAuth interaction. An "error" value > is only needed when something goes wrong, so that doesn't seem like a case > that needs to be optimized for space. A two-byte "error" representation will > only be used when errors have occurred, so shouldn't be a problem. > > -- Mike > > -Original Message- > From: Ace On Behalf Of Ludwig Seitz > Sent: Tuesday, October 30, 2018 5:13 AM > To: ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > On 25/10/2018 02:58, Mike Jones wrote: > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between > > many of the CBOR numeric values used in this this specification and > > corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the > > relationship is currently unspecified and the goals behind it are > > undefined. The spec should be augmented to make the nature and goals > > of this relationship explicit. I infer that there's such a > > relationship because the Mapping Parameters to CBOR in Section 5.6.5 > > apparently carefully do not overlap with the values registered in the > > IANA CWT Claims registry at > > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > > mappings in Section 5.7.4 apparently carefully use the same values as > > CWT for the same things, but then adds additional values. And some of > > these values are the same as values proposed for the CWT Claims > > registry in 8.13. This has to be more than a coincidence but the spec > > doesn't currently say why. > > For example in "5.6.5 Mapping Parameters to CBOR" there is this: > > "Note that we have aligned these abbreviations with the claim > abbreviations defined in [RFC8392]." > > I can add some text to explain that this makes it easier to manage the > abbreviations in code (no need to handle complex namespace issues, when > you just use one abbreviation space). Would that ad
Re: [Ace] WGLC for draft-ietf-ace-authz
On 23/10/2018 20:44, Jim Schaad wrote: -Original Message- From: Ludwig Seitz Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad ; draft-ietf-ace-oauth- au...@ietf.org Cc: ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz Hallo Jim, thank you for the review! Comments inline. /Ludwig On 22/10/2018 21:09, Jim Schaad wrote: * Section 5.8.1 - What is the purpose of creating an identifier for a token? Is this supposed to be used rather than the one from the AS for something like shared secret TLS? Note that this is an unprotected value. AFAIK cti is not a mandatory claim of an access token, thus a RS might want to create an identifier for tokens that do not have a cti. Ok - so the client has this cti - what could it use it for? You might want to treat the token as a RESTful resource under /authz-info that the client can GET or DELETE using the cti as part of the URI. I admit this is never explicitly stated and would need to be worked out quite a bit (as Steffi remarked, there would need to be access control on the tokens), so I wouldn't argue against removing the comment from the draft altogether. * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) to try introspection before returning a response if the RS does introspection? The text currently says MAY. If this is really MAY then the text should say that the token is always successfully accepted by the RS. I'm not sure I understand the issue. Introspection is optional in general, and may be required in specific use cases. If the RS determines that the token is not valid on its own, why would it want to do introspection on top of this? The RS has just received a token. The RS wants to validate said token. It can do it on its own or it can do it with introspection. If it is going to do it with introspection can it defer this validation until first use or does it need to do it immediately so it is not going to store an invalid token? It is possible that an RS is going to both support some tokens and require introspection on others. In that case it would decide the token was not valid, but would not necessarily know if it was a legal introspection token. I'm not convinced we need to REQUIRE a certain behavior here. I would however agree to put some text in the draft outlining these options and analyzing the resulting security implications. Would that address your comment sufficiently? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
On 22/10/2018 21:09, Jim Schaad wrote: * Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see. Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is clear that the whole registry process needs a second (third, n-th) go-over. I'd very much like to have all abbreviations in a single table, however some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where to do the table, since I'd like to have the parameters from there in it. * Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. In the light of your and Steffi's comments, this seems to merit a section in the security considerations. * I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved. I'd like to have the view of our OAuth experts here: How is OAuth typically used, when a client needs to get more permissions than initially granted? Is the old token invalidated and a new token issued, or is there something like "add-on" scopes in additional tokens? Given the amount of trouble the handling of multiple tokens for one client-RS pair can raise, I'm not disinclined to forbid them or at least recommend against their use. However with audiences possibly addressing overlapping sets of RSs this might be more difficult than it looks. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
> -Original Message- > From: Mike Jones > Sent: Wednesday, October 24, 2018 5:58 PM > To: Jim Schaad ; ace@ietf.org > Subject: RE: [Ace] WGLC for draft-ietf-ace-authz > > IT CAN'T BE A COINCIDENCE: There's clearly a relationship between many of > the CBOR numeric values used in this this specification and corresponding > CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is > currently unspecified and the goals behind it are undefined. The spec should > be augmented to make the nature and goals of this relationship explicit. I > infer that there's such a relationship because the Mapping Parameters to > CBOR in Section 5.6.5 apparently carefully do not overlap with the values > registered in the IANA CWT Claims registry at > https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection > mappings in Section 5.7.4 apparently carefully use the same values as CWT > for the same things, but then adds additional values. And some of these > values are the same as values proposed for the CWT Claims registry in 8.13. > This has to be more than a coincidence but the spec doesn't currently say > why. You are right it is not a coincidence. You have been asking that they match up for quite a while and at one time the authors tried to do this. This does not mean that it should be that way. > > Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth > parameters should all be registered in the CWT Claims registry because of > the possibility of them being used in signed requests in a manner analogous > to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters > need to be registered to avoid future claim number conflicts. While conflicts > have clearly been carefully avoided to date, they will inevitably occur in the > future unless the values are actually registered. Please do so. This is something that I think is incorrect - see my mail on 10/3. > > DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances > of numbers to be assigned by designated experts in existing registries from > specific values to "TBD". For instance, all the values for the CWT Claims > Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD. > Our chair, Jim Schaad has been a vigorous advocate of not squatting in my > past interactions with him as a Designated Expert and I believe would > support this request. Likewise, the "19" in the CoAP Content-Format > Registration in Section 8.15 should become TBD. If they are creating a new registry - which means not going in the CWT claim registry then it makes sense for them to assign numbers. I agree on the content format registration unless they have gotten an early registry done. > > req_aud: Several examples use the "req_aud" parameter without defining it. > Doesn't this duplicate the "resource" parameter defined by > https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If so, > please delete this parameter and use "resource". If not, say how it is > different and why the differences are necessary. > > rs_cnf: There isn't a clear normative definition of this parameter. It's > mentioned obliquely but its purpose, syntax, and semantics should be plainly > stated (as with each other newly defined parameter). > > The proposed numbers in Figures 12 and 16 contain mismatches. For > instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 > in Section 5.7.4. There's too much alignment for it to be a coincidence but if > you intend alignment, please say so explicitly and fix the alignment. The > proposed ongoing alignment should also be described in the registration > instructions for the Designated Experts. > > -- Mike > > P.S. Per my earlier reviews of this specification, in my view as a Designated > Expert for the CWT Claims registry, I believe that it's not appropriate to use > up rare single-byte identifiers for most of the OAuth parameter encodings > specified in 5.6.5. I could be persuaded that "scope" merits one of these rare > numbers, but "profile", "error", "grant_type", "access_token", and > "token_type" probably do not, as they are application-specific and not of > general applicability. I also believe that some of the other Designated > Experts for this registry agree with me. Yet another reason why we should not be combining these registries into a single one in my opinion. Jim > > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: Monday, October 8, 2018 2:35 PM > To: ace@ietf.org > Subject: [Ace] WGLC for draft-ietf-ace
Re: [Ace] WGLC for draft-ietf-ace-authz
Looking back to the message I sent on 10/3 I don't believe that the OAuth requests are the same thing as CWTs and I proposed a solution there about how to fix thing in the future so that they don't become them. > -Original Message- > From: Carsten Bormann > Sent: Wednesday, October 24, 2018 10:34 PM > To: Mike Jones > Cc: Jim Schaad ; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > +1 for making all the CWT-like structures into real CWTs. > > Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
On Oct 25, 2018, at 19:41, Michael Richardson wrote: > > OAuth claim statements too confusing Indeed, there is a problem there (as with many things inherited from OAuth). We might want to fix those issues for the purposes ACE, even if it wasn’t in the domain for the ANIMA work. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
Well, I was a bit terse, was I. I really meant to address the CWT-like structures, not everything that is ever encoded in CBOR. If it doesn’t feel like a claim set, then of course there is no point in mimicking CWT. Grüße, Carsten > On Oct 25, 2018, at 10:45, Olaf Bergmann wrote: > > Carsten Bormann writes: > >> +1 for making all the CWT-like structures into real CWTs. > > Not every key/value-pair encoded as CBOR is automatically a CWT. What > happens here is that we are trying to force every protocol element that > is required to solve an application-specific problem to fit into > existing registered OAuth elements. As already pointed out by Mike, this > does not work well because ACE is different from vanilla OAuth. > > The best solution I can imagine to conserve precious number space is to > use the media type (Content-Format in CoAP) as differientiator and use > CWT-numbers only for things that are CWTs > > Grüße > Olaf > > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
+1 for making all the CWT-like structures into real CWTs. Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
On 24/10/2018 03:44, Benjamin Kaduk wrote: Just one minor note -- this is a great discussion to see happening! On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote: On 22/10/2018 21:09, Jim Schaad wrote: * Section 5.8.2 - If the RS is going to do introspection, can it send some type of "Server Busy - try again in xxx" while it does the introspection rather than just doing an ack of the request and possibly waiting a long time? This is probably transport protocol specific, and we were asked not to link the framework to a specific protocol, thus I don't know if we can provide guidance here. I think it would be okay to say something like "some transport protocols may provide a way to indicate that the server is busy and the client should retry after an interval; this type of status update would be appropriate while the server is waiting for an introspection response". Which does provide guidance, but in a non-normative fashion that does not require or prohibit any given transport protocol. -Ben Thank you for the suggestion. I will integrate that text. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
On 23/10/2018 20:44, Jim Schaad wrote:
* Section 6 - I am not sure that I agree with the SHOULD NOT in
the last paragraph. Think multicast.
Any suggestions on how to mitigate the issue then? If I issue a
token bound to a symmetric key for audience {R1, R2, R3}, as soon
as R1 got this token it can impersonate the client and gain access
to R2 and R3.
I am not sure that I think this is an issue that needs to be
mitigated. It needs to be acknowledged, but the assumption would be
that if you have three resource servers that are hosting the same
audience they are going to be run by the same RO and already be
coupled. After all it should not matter which of them you do a GET
from, you should get the same answer. Similarly a PUT to one should
propagate to the others so that it is available to all clients.
Say the client is a cleaning service and the audience is the locks of
the different apartments it is allowed to open.
If the token uses symmetric keys, as soon as the cleaning service sends
the token to one apartment, this apartment can open the other
apartments. This is the situation I want to avoid.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
Just one minor note -- this is a great discussion to see happening! On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote: > > On 22/10/2018 21:09, Jim Schaad wrote: > > * Section 5.8.2 - If the RS is going to do introspection, can it send some > > type of "Server Busy - try again in xxx" while it does the introspection > > rather than just doing an ack of the request and possibly waiting a long > > time? > > This is probably transport protocol specific, and we were asked not to > link the framework to a specific protocol, thus I don't know if we can > provide guidance here. I think it would be okay to say something like "some transport protocols may provide a way to indicate that the server is busy and the client should retry after an interval; this type of status update would be appropriate while the server is waiting for an introspection response". Which does provide guidance, but in a non-normative fashion that does not require or prohibit any given transport protocol. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] WGLC for draft-ietf-ace-authz
> -Original Message-
> From: Ludwig Seitz
> Sent: Tuesday, October 23, 2018 7:43 AM
> To: Jim Schaad ; draft-ietf-ace-oauth-
> au...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>
> Hallo Jim,
>
> thank you for the review! Comments inline.
>
> /Ludwig
>
> On 22/10/2018 21:09, Jim Schaad wrote:
> > * Section 5.8.1 - What is the purpose of creating an identifier for a token?
> > Is this supposed to be used rather than the one from the AS for
> > something like shared secret TLS? Note that this is an unprotected value.
> >
> AFAIK cti is not a mandatory claim of an access token, thus a RS might want
> to create an identifier for tokens that do not have a cti.
Ok - so the client has this cti - what could it use it for?
> > * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
> > to try introspection before returning a response if the RS does
> > introspection? The text currently says MAY. If this is really MAY then the
> > text should say that the token is always successfully accepted by the RS.
> >
> I'm not sure I understand the issue. Introspection is optional in
> general, and may be required in specific use cases. If the RS determines
> that the token is not valid on its own, why would it want to do
> introspection on top of this?
The RS has just received a token. The RS wants to validate said token. It can
do it on its own or it can do it with introspection. If it is going to do it
with introspection can it defer this validation until first use or does it need
to do it immediately so it is not going to store an invalid token? It is
possible that an RS is going to both support some tokens and require
introspection on others. In that case it would decide the token was not valid,
but would not necessarily know if it was a legal introspection token.
>
>
> > * Section 5.8.2 - If the RS is going to do introspection, can it send some
> > type of "Server Busy - try again in xxx" while it does the introspection
> > rather than just doing an ack of the request and possibly waiting a long
> > time?
>
> This is probably transport protocol specific, and we were asked not to
> link the framework to a specific protocol, thus I don't know if we can
> provide guidance here.
> > * Section 6 - I am not sure that I agree with the SHOULD NOT in the last
> > paragraph. Think multicast.
> Any suggestions on how to mitigate the issue then? If I issue a token
> bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got
> this token it can impersonate the client and gain access to R2 and R3.
I am not sure that I think this is an issue that needs to be mitigated. It
needs to be acknowledged, but the assumption would be that if you have three
resource servers that are hosting the same audience they are going to be run by
the same RO and already be coupled. After all it should not matter which of
them you do a GET from, you should get the same answer. Similarly a PUT to one
should propagate to the others so that it is available to all clients.
>
> > * Section 8.6.1 - Is pop still this document or is it Mike's document?
>
> The token type pop is currently not part of
> draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting
> it there.
I would only because it would delay that document. I just could not remember
where if it was there and was too lazy to look.
>
> >
> > * Section 8.9 - The description of reference is wrong.
>
> Can you explain how? I'm not seeing the issue (assuming you mean the
> reference to RFC8126).
Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists.
This is not about grant types.
>
> >
> > * Section 8.12 - some of these should move to the OAuth parameters
> document?
> >
> These are new claims. We could move them to the params draft, which
> would then become the params and claims draft. I have not strong opinion
> either way.
I have no opinion either way - was just asking.
> > * Registries - I am wondering if we should think about re-writing a couple
> > of the registries. As things stand it appears that the application/ace+cbor
> > content type is being used in 5 or 6 places. It might make more sense to
> > have a registry for all of the CBOR abbreviations that are being used in a
> > single table and have multiple columns for each of the different places
> were
> > the content format is being used. This would make it easier to keep
> > everything constant and can make re-use of integer values easier to see.
> >
> > * Comments on protection of CWT/Token: I am
Re: [Ace] WGLC for draft-ietf-ace-authz
Hallo Jim,
thank you for the review! Comments inline.
/Ludwig
On 22/10/2018 21:09, Jim Schaad wrote:
* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.
This refers to the way it is defined in OAuth. I'll add a word to clarify.
* Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
available.
Agree.
* Description for Figure 6 - Should the example somehow indicate in the
message that it is going to be an application/ace+cbor content. Also, I
don't know that this is a good example in some ways because this is not a
currently documented profile anywhere.
True. I'll change this to OSCORE.
* Section 5.6.3 - Should the content type for an error response be
application/ace+cbor ?
That makes sense. I'll add a sentence to that effect.
* Section 5.7.1 - Is the content format for a request application/ace+cbor?
I assume it is but that is not documented in this section.I'll add that.
Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter
Right that slipped through. I'll replace it.
* Section 5.8.1 - What is the purpose of creating an identifier for a token?
Is this supposed to be used rather than the one from the AS for something
like shared secret TLS? Note that this is an unprotected value.
AFAIK cti is not a mandatory claim of an access token, thus a RS might
want to create an identifier for tokens that do not have a cti.
* Section 5.8.1 - Given the change in the OSCORE profile, you might want to
make this an application/ace+cbor structure as well.
Right
* Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
to try introspection before returning a response if the RS does
introspection? The text currently says MAY. If this is really MAY then the
text should say that the token is always successfully accepted by the RS.
I'm not sure I understand the issue. Introspection is optional in
general, and may be required in specific use cases. If the RS determines
that the token is not valid on its own, why would it want to do
introspection on top of this?
* Section 5.8.2 - If the RS is going to do introspection, can it send some
type of "Server Busy - try again in xxx" while it does the introspection
rather than just doing an ack of the request and possibly waiting a long
time?
This is probably transport protocol specific, and we were asked not to
link the framework to a specific protocol, thus I don't know if we can
provide guidance here.
* Section 5.8.3 - third point - I think that the correct text would be "The
method does not provide timely expiration, but it makes sure that older
tokens will cease to be valid after newer issued tokens are registered with
the RS." My problem is that just issuing tokens is not enough as they may
be going to a different RS for use. This may also need to have some type of
rate limit to issued tokens or making the sequence number be on an
RS/audience basis.
I think the sentence here: "The AS increments this number for each
access token it issues" needs to be ammended to "... for each access
token it issues for this RS".
* Section 6. - The recommendation not to use a shared secret for an audience
which is hosted by multiple servers is interesting. This does require that
a multiple recipient COSE structure be used and it may be worth calling that
out. Also the size of the CWT is going to grow for that. You are also now
losing the low-level authentication and thus a signature wrapping is now
also needed.
Right, I'll extend the paragraph to add this information.
* Section 6 - "Developers MUST" para - May want to add that this can also be
mitigated to some extent by making sure that keys roll over more frequently.
Ok
* Section 6 - I am not sure that I agree with the SHOULD NOT in the last
paragraph. Think multicast.
Any suggestions on how to mitigate the issue then? If I issue a token
bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got
this token it can impersonate the client and gain access to R2 and R3.
* Section 6.4 - This also applies to sending back some type of identifier
from the RS->C when a token is registered.
That is correct, however the token identifier should be just as opaque
to attackers as the token itself.
* Section 8.6.1 - Is pop still this document or is it Mike's document?
The token type pop is currently not part of
draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting
it there.
* Section 8.9 - The description of reference is wrong.
Can you explain how? I'm not seeing the issue (assuming you mean the
reference to RFC8126).
* Section 8.12 - some of these should move to the OAuth parameters document?
These are new claims. We could move them to the params draft, which
would then become the params and claims draft. I have not strong opinion
either way.
* Section 8.13 - ditto
* Appendix A - para
Re: [Ace] WGLC for draft-ietf-ace-authz
* Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet available. * Description for Figure 6 - Should the example somehow indicate in the message that it is going to be an application/ace+cbor content. Also, I don't know that this is a good example in some ways because this is not a currently documented profile anywhere. * Section 5.6.3 - Should the content type for an error response be application/ace+cbor ? * Section 5.7.1 - Is the content format for a request application/ace+cbor? I assume it is but that is not documented in this section. Section 5.8 - bytes arrays or byte strings? I think CBOR uses the latter * Section 5.8.1 - What is the purpose of creating an identifier for a token? Is this supposed to be used rather than the one from the AS for something like shared secret TLS? Note that this is an unprotected value. * Section 5.8.1 - Given the change in the OSCORE profile, you might want to make this an application/ace+cbor structure as well. * Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST) to try introspection before returning a response if the RS does introspection? The text currently says MAY. If this is really MAY then the text should say that the token is always successfully accepted by the RS. * Section 5.8.2 - If the RS is going to do introspection, can it send some type of "Server Busy - try again in xxx" while it does the introspection rather than just doing an ack of the request and possibly waiting a long time? * Section 5.8.3 - third point - I think that the correct text would be "The method does not provide timely expiration, but it makes sure that older tokens will cease to be valid after newer issued tokens are registered with the RS." My problem is that just issuing tokens is not enough as they may be going to a different RS for use. This may also need to have some type of rate limit to issued tokens or making the sequence number be on an RS/audience basis. * Section 6. - The recommendation not to use a shared secret for an audience which is hosted by multiple servers is interesting. This does require that a multiple recipient COSE structure be used and it may be worth calling that out. Also the size of the CWT is going to grow for that. You are also now losing the low-level authentication and thus a signature wrapping is now also needed. * Section 6 - "Developers MUST" para - May want to add that this can also be mitigated to some extent by making sure that keys roll over more frequently. * Section 6 - I am not sure that I agree with the SHOULD NOT in the last paragraph. Think multicast. * Section 6.4 - This also applies to sending back some type of identifier from the RS->C when a token is registered. * Section 8.6.1 - Is pop still this document or is it Mike's document? * Section 8.9 - The description of reference is wrong. * Section 8.12 - some of these should move to the OAuth parameters document? * Section 8.13 - ditto * Appendix A - para "CBOR, COSE, CWT" - Is it really a requirement to use CBOR or is that a recommended? I thought this was part of what Hannes was looking at. * Appendix A - para Client Credentials Grant s/can the/can then/ * Registries - I am wondering if we should think about re-writing a couple of the registries. As things stand it appears that the application/ace+cbor content type is being used in 5 or 6 places. It might make more sense to have a registry for all of the CBOR abbreviations that are being used in a single table and have multiple columns for each of the different places were the content format is being used. This would make it easier to keep everything constant and can make re-use of integer values easier to see. * Comments on protection of CWT/Token: I am wondering if there needs to be any comments on how a CWT is going to be protected. While it is ok to use either a symmetric key or a direct key agreement operation for a single recipient without forcing a signature operation to occur. If the token is going to be targeted a single audience hosted on multiple RSs then a signature operation would be required for the purposes of authentication. * I am not sure where this issue should be raised so I am putting it here. Both of the profiles have as their last security consideration a statement that the use of multiple access tokens is a bad idea. Both of them also devote a large section of text to how to deal with multiple access tokens as does this document. More methods of having multiple access tokens seem to be coming down the path from the OAuth group. This appears to be a distinct contradiction within the set of documents that should be resolved. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] WGLC for draft-ietf-ace-authz
The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-authz We know that the following issues are outstanding: draft-ietf-ace-authz * There are a couple of esoteric issues around listing AS servers associated with resources in a Resource Directory Jim & Roman ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
