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
[Ace] FW: draft-ietf-oauth-pop-key-distribution-04
I submitted an update of the PoP key distribution document to get it in sync with what is happening with the ACE OAuth framework. Ciao Hannes From: Hannes Tschofenig Sent: Tuesday, October 23, 2018 2:19 PM To: oauth Subject: draft-ietf-oauth-pop-key-distribution-04 Hi all, I refreshed the PoP key distribution document today, see https://tools.ietf..org/html/draft-ietf-oauth-pop-key-distribution-04, in an attempt to get the document inline with the agreements we made at the Montreal IETF meeting, the Resource Indicators draft, and the work happening in ACE. Thanks to Mike for going through the draft with me and for spotting several copy-and-paste mistakes. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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 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
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-oauth-params
On 22/10/2018 21:09, Jim Schaad wrote: Here are my WGLC comments: * I am not sure that I understand what the protocol flow is when JAR is being used. Is there a potential case where a JWT would be used as the structure of an OAuth response? If so then is there a problem with defining cnf in section 4.1? I wouldn't think so, all the other possible parameters in the introspection response are defined to be the claims of the token in RFC 7662, cnf is a claim of the token, so I don't see why it shouldn't go unchanged into the introspection response. * We need to have a OAuth CBOR integer mapping registry - the items in section 6 need to be registered into that registry. That was an oversight. Issue created. * Review - is the 'cnf' parameter in section 3.2 ok with the OAuth group or does it need to be renamed as well? I don't see how this could collide with another meaning. The AS is responding with the token and additional information about the token here. This parameter was called 'key' in draft-ietf-oauth-pop-key-distribution, which felt more phrone to misunderstandings to me ("what key?"). * Check that cnf in 4.1 is going to be ok with draft-ietf-oauth-jwt-introspection-response If I understood it correctly draft only proposes to replace the whole introspection response with a JWT. I don't see why this shouldn't work with a CWT as well. No additional data but the JWT/CWT would be sent in the introspection response, so there should not be any issue with the cnf claim here. -- 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