[Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
Hello, I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply. Thanks, Sebastian Echeverria ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
> On Feb 18, 2019, at 15:59, Sebastian Echeverria > wrote: > > Hello, > > I have a short comment about error responses from an RS in > draft-ietf-ace-oauth-authz-21. More specifically, my question is about > section 5.8.2. In the second paragraph, it states “The response code MUST be > 4.01 (Unauthorized) in case the client has not performed the > proof-of-possession, or if RS has no valid access token for the client.” I am > assuming this means that if the client is trying to access a resource and > sending a pop key id that is not known by the RS, either because the RS has > never seen it or because it is associated to a token that has already been > removed from the RS, then this is how the RS should reply. > > If this is the case, I am a bit confused on how to implement this when using > the DTLS profile. When using this profile, a client will first try to > establish a DTLS session with the RS when accessing a resource. Once the > session is established, it will actually try to access the resource over that > DTLS connection. The pop key id to be used is sent when establishing the DTLS > connection in the DTLS handshake messages, but if the RS does not have a > key+token associated to that id for whatever reason, then it will cancel the > DTLS handshake. If the DTLS handshake is never completed, then the RS can’t > really send a reply at all, much less a 4.01 reply. Actually, if the DTLS handshake fails, the client can’t even send the request, so the MUST doesn’t apply. (That is probably worth another sentence.) (Another question of course is if the DTLS handshake failure is sufficiently speaking for this case.) Grüße, Carsten > > Thanks, > > Sebastian Echeverria > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
Sebastian, The 4.01 is not restricted to just the DTLS case. One could get this error from just trying to get the resource on the schema coap rather than coaps. However, this could occur even in the DTLS profile case. Consider the situation of the following: I have a token which allows me to do a get on a resource I setup the DTLS session with that token and preform the get I then attempt to do a PUT on that same resource. This would then return a 4.01 (Unauthorized) because I don’t have a valid access token for the purpose of doing the action. The same thing would be true if I attempted to do a GET on a different resource. Jim From: Ace On Behalf Of Sebastian Echeverria Sent: Monday, February 18, 2019 6:59 AM To: ace@ietf.org Subject: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21 Hello, I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply. Thanks, Sebastian Echeverria ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
Hello Jim, Thanks for your comments! I understand and I agree. In any case, my point wasn’t really that there was no situation in which a 4.01 reply would make sense. My point was that, in the way the draft is currently written, it asks a RS to return 4.01 in certain cases, and in at least some of those cases, the RS can’t really reply with a 4.01 (and as Carsten mentioned, the RS can’t even get the actual request). I am not sure what the best way to clarify that is, but when we were trying to implement that part of the draft, it was confusing because we couldn’t really comply with what is requested there, at least in the specific case I described. As a separate comment, I am not sure I understand the specific examples you mention. From the draft (same section 5.8.2), it looks as if, in the first case you are describing (different action on the same resource), 4.05 should be returned. And in your second example (same action on a different resource), it looks as if the RS should return 4.03. Is this correct? We are just trying to ensure we are implementing error handling properly here. This is only a comment on these specific examples; I am not saying there is no situation where 4.01 could be returned. Sebastian From: Jim Schaad Date: Tuesday, February 19, 2019 at 6:17 PM To: Sebastian Echeverria , "ace@ietf.org" Subject: RE: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21 Sebastian, The 4.01 is not restricted to just the DTLS case. One could get this error from just trying to get the resource on the schema coap rather than coaps. However, this could occur even in the DTLS profile case. Consider the situation of the following: I have a token which allows me to do a get on a resource I setup the DTLS session with that token and preform the get I then attempt to do a PUT on that same resource. This would then return a 4.01 (Unauthorized) because I don’t have a valid access token for the purpose of doing the action. The same thing would be true if I attempted to do a GET on a different resource. Jim From: Ace On Behalf Of Sebastian Echeverria Sent: Monday, February 18, 2019 6:59 AM To: ace@ietf.org Subject: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21 Hello, I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply. Thanks, Sebastian Echeverria ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
On 18/02/2019 15:59, Sebastian Echeverria wrote: Hello, I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply. Thanks, Sebastian Echeverria Sebastian is right. I will change the text in the framework to allow for cases where no answer at all can be provided. The intent was that these error messages should only be sent when the access token is POSTed to the authz-info endpoint. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 smime.p7s Description: S/MIME Cryptographic Signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
