[Ace] Shepard comments on draft-ietf-ace-oscore-profile
1. Please update the text for MUST/SHOULD/MAY to include the language from RFC 8174. 2. Section 3.2.1 - What to do is clear if a field is not missing. What is the correct behavior if a field is present that the client and/or resource server does not recognize. Is this a fatal error or is it sufficient that they may not behave the same? Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] CWT equivalent of JWT.io
Does anyone know of an online tool that will decode CWTs like https://jwt.io/ does for JWTs? Thanks, -- Mike ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz
> -Original Message- > From: Ludwig Seitz > Sent: Wednesday, January 30, 2019 12:38 AM > To: Jim Schaad ; draft-ietf-ace-oauth- > au...@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard review for draft-ietf-ace-oauth-authz > > Thank you Jim, > > I'll upload a new version as soon as we have resolved my questions below. > > /Ludwig > > On 30/01/2019 07:01, Jim Schaad wrote: > > 1. Update the reference from RFC 5246 to RFC 8446 in all locations > > > > > > > > Items that don't appear to be resolved: > > > > * Section 3.1 - Refresh Token - I don't think that refresh tokens are > > going to be strings because binary is more efficient. > > Unless you are going to say that this is not OAuth 2.0, then a > > refresh token is still a text string. > > > > * I don't see any text that is addressing this. > > That text just describes how it is in OAuth 2.0 (where refresh tokens are > strings), since we didn't see the need to specify the use of refresh tokens in > ACE, we didn't mention them further. If we had we would certainly have > defined them to be binary. That would be fine, but you actually do define a CBOR mapping tag for refresh tokens in the body of the text and define it as binary. > > > > >> 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. > > > > * I don't see anything that I think addresses this issue. I would expect > > it to be a security consideration > > There is text in the draft according to the suggestion above in section > 5.8.1 "The Authorization Information Endpoint". Should that text be > moved to security considerations? No, I just missed the text. It just took me three times reading through to find 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. > > > > Right. I'll add some security considerations on that. > > > > ** IANA Section Issues > > > > 1. None of the new registries appear to have any guidance for the DEs to > > use when approving items. > > Is it acceptable to add a single guidance section for all of the new > registries, or does it need to be separate for each of them? As long as the guidance is comment this is fine. That is what I did for all of the COSE registries > > > > > 2. The title of the registry "ACE Authorization Server Information" is not > > really descriptive of what is in the registry. It makes sense in the text > > but not as a stand along title. Something along the lines of "ACE > > Authorization Server Request Creation Hints" seems to be closer to a solid > > identification. > > > Would "ACE Authorization Server Discovery Hints" be better? I thought about that, but it does not really cover the idea of having the nonce value there or the possibility of later adding things like - ok you should use this audience or this scope or some other similar thing. > > > 3. The mapping registries should use the OAuth registry name as a prefix. > > Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR > Mappings". > > > Done. Actually quite some changes were required to align all of the > mappings sections with the OAuth registry names. > > > 4. What is the initial registrations that need to occur for the "ACE > > Profile" registry. If there are none then this needs to be stated. > > > It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a > profile. However the DTLS and OSCORE profile will provide the two > initial entries. I added a sentence to that effect in the IANA section. Yea, I thought that was the case since the registrations are actually done in the profile documents. I just wanted to make sure that IANA realized that this was initially going to be an empty registry. Jim > > > 5. For the CBOR Web Token
Re: [Ace] ACE Implementation for Disadvantaged Environments
Hello Michael, Thanks! Answers to your questions here: - We used plain Contiki, since we forked from 6lbr, which itself forked from plain Contiki (we did this since 6lbr already had CoAPs functionality implemented). We have given thought to migrating to Contiki-ng, so that could happen at some point. - By disadvantaged networks we do mean something similar to constrained networks as defined in RFC 7228. In the past we've mostly focused on DIL (Disconnected, intermittent, and limited bandwidth) environments mostly due to the mobility of the devices involved and the environmental conditions of our use cases. But most of the constraints are similar. - We are striving to get it down to around 250 kb, but we haven't spent that much time yet trimming it down. With some work, we should probably be able to get there. Thanks for your comments! Sebastian On 1/28/19, 6:51 PM, "Michael Richardson" wrote: Thanks for the report! Sebastian Echeverria wrote: > * We used Contiki as the base/OS for the code. More specifically, we > forked Contiki, or contiki-ng? > from the 6lbr project (https://github.com/cetic/6lbr), as that version > already had some code for handling DTLS connections and AES encryption in > it. > * We are using the TI CC2538dk board as our constrained target platform. > * The implementation has support for the DTLS profile, using pre-shared keys, > as this was enough for our use case. Yes, but often not really enough for a deployment where we need certificates or raw public keys, and this may have significant affects on packet sizes :-( > * We modified the Erbium CoAP server in 6lbr to be able to simultaneously > listen for CoAP and CoAPs connections (using TinyDTLS underneath). That's an interesting and useful change. > * The implementation has some additional optional features related to our > disadvantaged network environments, such as bootstrapping of the PSK > credentials, and detecting revoked tokens through introspection. When you say "disadvantaged", I think that you mean "constrained", as per RFC7228? > * The current binary is around 300 kb, which is good enough for the 512 kb > flash on the TI boards, though it may be a bit too large for a class II > device. We can probably make it a bit smaller. In terms of RAM, it fits in > the 32 KB available on the TI boards. The key number is 256K, so that one can double buffer the firmware image. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz
On Wed, Jan 30, 2019 at 09:37:45AM +0100, Ludwig Seitz wrote: > > On 30/01/2019 07:01, Jim Schaad wrote: > > ** IANA Section Issues > > > > 1. None of the new registries appear to have any guidance for the DEs to > > use when approving items. > > Is it acceptable to add a single guidance section for all of the new > registries, or does it need to be separate for each of them? That's fine. -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz
Thank you Jim, I'll upload a new version as soon as we have resolved my questions below. /Ludwig On 30/01/2019 07:01, Jim Schaad wrote: 1. Update the reference from RFC 5246 to RFC 8446 in all locations Items that don't appear to be resolved: * Section 3.1 - Refresh Token - I don't think that refresh tokens are going to be strings because binary is more efficient. Unless you are going to say that this is not OAuth 2.0, then a refresh token is still a text string. * I don't see any text that is addressing this. That text just describes how it is in OAuth 2.0 (where refresh tokens are strings), since we didn't see the need to specify the use of refresh tokens in ACE, we didn't mention them further. If we had we would certainly have defined them to be binary. 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. * I don't see anything that I think addresses this issue. I would expect it to be a security consideration There is text in the draft according to the suggestion above in section 5.8.1 "The Authorization Information Endpoint". Should that text be moved to security considerations? 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. Right. I'll add some security considerations on that. ** IANA Section Issues 1. None of the new registries appear to have any guidance for the DEs to use when approving items. Is it acceptable to add a single guidance section for all of the new registries, or does it need to be separate for each of them? 2. The title of the registry "ACE Authorization Server Information" is not really descriptive of what is in the registry. It makes sense in the text but not as a stand along title. Something along the lines of "ACE Authorization Server Request Creation Hints" seems to be closer to a solid identification. Would "ACE Authorization Server Discovery Hints" be better? 3. The mapping registries should use the OAuth registry name as a prefix. Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings". Done. Actually quite some changes were required to align all of the mappings sections with the OAuth registry names. 4. What is the initial registrations that need to occur for the "ACE Profile" registry. If there are none then this needs to be stated. It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a profile. However the DTLS and OSCORE profile will provide the two initial entries. I added a sentence to that effect in the IANA section. 5. For the CBOR Web Token Claims - how many of these should have the JWT Claim name filled in? It would seem that all of them should. If not a comment about this is needed. Fixed. /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
