Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hello, I am also not aware of any IPR on our side, and I confirm I’m willing to co-author the document. Thanks, --- Sebastian Echeverria Tactical and AI-enabled Systems (TAS) Software Engineering Institute Carnegie Mellon University Sebastian Echeverria From: Ace on behalf of Marco Tiloca Date: Monday, March 13, 2023 at 3:11 PM To: Daniel Migault , Ace Wg Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt Hi Daniel and all, On 2023-03-13 18:36, Daniel Migault wrote: Hi everyone, This email starts a WGLC for draft-ietf-ace-revoked-token-notification which ends on March 27. Please provide your support and feed backs by that time. We will take advantage of the IETF116 session to solve any remaining discussions on that draft. I am also looking for someone interested in being the document shepherd: Please volunteer! To the co-authors I am looking at: - 1) a heads-up regarding the implementations. ==>MT An implementation from Marco Rasori is available at [1], as building on the implementation of the ACE framework at [2]. It is planned to make a pull request of [1] onto [2]. [1] https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/ [2] https://bitbucket.org/marco-tiloca-sics/ace-java <== - 2) a confirmation that they are or not aware of any IPR ==>MT I do not have and I am not aware of any IPR on this document. <== - 3) a confirmation that they are willing to co-author the document. ==>MT I am willing to be a co-author of this document. Best, /Marco <== Yours, Logan and Daniel On Mon, Mar 13, 2023 at 11:36 AM mailto:internet-dra...@ietf.org>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Authentication and Authorization for Constrained Environments (ACE) WG of the IETF. Title : Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework Authors : Marco Tiloca Ludwig Seitz Francesca Palombini Sebastian Echeverria Grace Lewis Filename: draft-ietf-ace-revoked-token-notification-04.txt Pages : 59 Date: 2023-03-13 Abstract: This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. The method allows Clients and Resource Servers to access a Token Revocation List on the Authorization Server, with the possible additional use of resource observation for the Constrained Application Protocol (CoAP). Resulting (unsolicited) notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gYpZlIuI%2BzStJC5ry%2FAgPKsG0dsCQFlP6YvWA61JJV4%3D=0> There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ace-revoked-token-notification-04.html<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-revoked-token-notification-04.html=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8A%2FhfRSRo848%2BPuH9tENHNbjyZ5tLM1rbdbt%2FOEaBY8%3D=0> A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-revoked-token-notification-04<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-ace-revoked-token-notification-04=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=p7r7kMc09mEkD3tHNYmvwMygX0OmjHU1MlaThzk%2F7sk%3D=0> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace<https:
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
[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] 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] ACE Implementation for Disadvantaged Environments
Hi Hannes, Regarding your questions: 1. “How easy do you think would it be to port the code to some other OS? (or in other words: how tightly have you coupled it to Contiki?)” - Most of the code is called by Contiki processes, so it is not that coupled, and the cn-cbor and TinyDTLS dependencies are independent from Contiki. The code depends on two main things from Contiki: the Erbium CoAP server, and the CFS file system. The coupling with Erbium is not that strong, but wherever the code is ported, it would need a CoAP/CoAPs server on that OS, or the actual porting of a subset of Erbium (which I guess is doable, but it may be substantial work). The dependency on the CFS file system is for storing keys and tokens, and that would need to be adapted to whatever another OS offers, though this dependency is fairly contained in one module, and changes should not be that hard. 2. “Is the COSE/CWT parsing library separable from the rest? “ - Yes, it is fairly separable from the rest, other than the fact that it uses cn-cbor for cbor parsing, and TinyDTLS for AES decryption. However, at the moment it is very limited in terms of COSE parsing, only supporting the COSE wrapper and cypher suites we are actually using/supporting in our implementation. 3. “For the 300 Kb flash: does this contain the firmware update mechanism?” - No, this does not include the firmware update mechanism. Any more questions, just let me know. Thanks, Sebastian From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com] Sent: Monday, January 28, 2019 10:19 AM To: Sebastian Echeverria Cc: Grace A Lewis ; ace@ietf.org; Dan Klinedinst Subject: RE: ACE Implementation for Disadvantaged Environments Hi Sebastian, Thanks for the details. How easy do you think would it be to port the code to some other OS? (or in other words: how tightly have you coupled it to Contiki?) Is the COSE/CWT parsing library separable from the rest? For the 300 Kb flash: does this contain the firmware update mechanism? Ciao Hannes From: Sebastian Echeverria mailto:sechever...@sei.cmu.edu>> Sent: Montag, 28. Januar 2019 16:06 To: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> Cc: Grace A Lewis mailto:gle...@sei.cmu.edu>>; ace@ietf.org<mailto:ace@ietf.org>; Dan Klinedinst mailto:djklinedi...@cert.org>> Subject: Re: ACE Implementation for Disadvantaged Environments Hello, Here is some more information about it: - We used Contiki as the base/OS for the code. More specifically, we forked 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. - The implementation handles CWT tokens. - We modified the Erbium CoAP server in 6lbr to be able to simultaneously listen for CoAP and CoAPs connections (using TinyDTLS underneath). - The implementation uses the cn-cbor library for decoding CBOR data. - The implementation supports receiving tokens at the authz-info endpoint, and then giving access to a couple of sample resources based on the claims from the received tokens. - 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. - 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. Best, --- Sebastian Echeverria Tactical Technologies Group (TTG) Software Engineering Institute Carnegie Mellon University From: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> Date: Monday, January 28, 2019 at 5:05 AM To: Grace Lewis mailto:gle...@sei.cmu.edu>>, "ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>> Subject: RE: ACE Implementation for Disadvantaged Environments Congrats to the work. Could you say a little bit the (constrained) resource server implementation? Ciao Hannes From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of Grace A Lewis Sent: Mittwoch, 23. Januar 2019 19:12 To: ace@ietf.org<mailto:ace@ietf.org> Subject: [Ace] ACE Implementation for Disadvantaged Environments Hello, I just wanted to make the group aware of our ACE implementation (SEI-ACE), which includes an implementation for a resource-constrained server. Details available in this news article: https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184 Article includes the link to our Git repo. Enjoy! - Grace Lewis __
Re: [Ace] ACE Implementation for Disadvantaged Environments
Hello, Here is some more information about it: * We used Contiki as the base/OS for the code. More specifically, we forked 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. * The implementation handles CWT tokens. * We modified the Erbium CoAP server in 6lbr to be able to simultaneously listen for CoAP and CoAPs connections (using TinyDTLS underneath). * The implementation uses the cn-cbor library for decoding CBOR data. * The implementation supports receiving tokens at the authz-info endpoint, and then giving access to a couple of sample resources based on the claims from the received tokens. * 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. * 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. Best, --- Sebastian Echeverria Tactical Technologies Group (TTG) Software Engineering Institute Carnegie Mellon University From: Hannes Tschofenig Date: Monday, January 28, 2019 at 5:05 AM To: Grace Lewis , "ace@ietf.org" Subject: RE: ACE Implementation for Disadvantaged Environments Congrats to the work. Could you say a little bit the (constrained) resource server implementation? Ciao Hannes From: Ace On Behalf Of Grace A Lewis Sent: Mittwoch, 23. Januar 2019 19:12 To: ace@ietf.org Subject: [Ace] ACE Implementation for Disadvantaged Environments Hello, I just wanted to make the group aware of our ACE implementation (SEI-ACE), which includes an implementation for a resource-constrained server. Details available in this news article: https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=539184 Article includes the link to our Git repo. Enjoy! - Grace Lewis __ Grace A. Lewis, Ph.D. Principal Researcher and TTG Initiative Lead Carnegie Mellon Software Engineering Institute Software Solutions Division (SSD) Tactical Technologies Group (TTG) 4500 Fifth Ave. #5412 Pittsburgh, PA 15213 Phone: (412) 268-5851 http://www.sei.cmu.edu/staff/glewis “A change in perspective is worth 80 IQ points” --- Alan Kay 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] Security of the Communication Between C and RS
Hello, >> If it is detected the AS would revoke the token. Then the client _could_ use >> client introspection to get that information. Note that this is what the CMU >> people are looking at. Yes, handling compromised RSs is in fact something that we have been looking into. Our main concern is that in our scenarios, the environment is expected to be very hostile and connection is limited and intermittent (disadvantaged or DIL networks). Since we wanted to add some support for revoking tokens, without having to modify the framework to handle token revocation explicitly, what we ended up doing was using client introspection, along with some caveats and some considerations, to be able to add this functionality, besides also having ways to handle expired tokens. The main advantage of this is, again, that we aren't really modifying or even extending the ACE framework, but just taking advantage of functionality that is already there to implement this functionality, which makes sense in our use case. In fact, we were looking into writing a BCP-like document suggesting ways to do this based on what we did. We were envisioning this as maybe the starting point of a document containing practices on how to better handle client communications with OAuth/ACE when we are dealing with disadvantaged networks and hostile environments. If there is interest in the group, we could share that document here, and maybe discuss what other practices could be added to it. Thanks, --- Sebastian Echeverria Tactical Technologies Group (TTG) Software Engineering Institute Carnegie Mellon University -Original Message- From: Ludwig Seitz [mailto:ludwig.se...@ri.se] Sent: Wednesday, December 19, 2018 8:24 AM To: Hannes Tschofenig ; Stefanie Gerdes ; Jim Schaad ; ace@ietf.org Subject: Re: [Ace] Security of the Communication Between C and RS On 19/12/2018 14:04, Hannes Tschofenig wrote: > Thanks, Ludwig. The list of steps below help me to understand the concern. > > > > > 1.) C obtains token and pop-key from AS > 2.) C transmits token to RS and sets up secure communication (e.g. > DTLS-PSK) using the pop-key > 3.) C sends secure requests to the RS > 4.) token expires, an attacker manages to get hold of the pop-key > 5.) C continues to send requests containing sensitive information to the RS , > attacker can now read the messages and spoof positive responses from the RS. > C never notices that the token is invalid and that it is actually talking to > the attacker. > > > > In step (4) you tie the expiry of the token to the attacker getting > hold of the key. What happens if the attacker gets hold of the pop key > before the token expires? If it is detected the AS would revoke the token. Then the client _could_ use client introspection to get that information. Note that this is what the CMU people are looking at. > Additionally, if you use DTLS/TLS just having the PoP key still > requires the attacker to run a new DTLS/TLS handshake with the RS. If the pop-key was used as a basis for doing a DTLS-PSK handshake, the attacker should be able to hijack the connection and impersonate either party. > It would also be useful to know where the attacker got the PoP key > from and how you can even detect the compromise. That is a different story entirely. You could imagine the case of an RS improperly deleting an expired token and the associated pop-key, and then being subject to a physical attack that recovers that information. > > Additionally, there is the question why the RS wouldn't stop > communicating if the token expired since it has that information. The RS would indeed stop, but since the token is opaque to the client, it has no way of knowing that the token has expired, and our clever attacker is using the pop-key to impersonate the RS and maintain the illusion that the connection is still alive an running. > Normally, the idea is that the RS has a protected resource and the > client wants to access it. That's why the RS is asking the client to > send a token that gives it access. > Yes but say e.g. that the RS is a message broker and the client is a publisher, writing sensitive data to the RS. I think Steffi's point definitely warrants text in the security considerations, outlining how a client could detect that a token has expired. /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