[Ace] bringing draft-selander-ace-ake-authz to ACE?
I'm sorry that I missed today's meeting. I guess this wasn't on the agenda in the end? Göran Selander wrote: > But you are right that the draft is not just a new ACE profile. The > voucher concept fits into ANIMA, but is carried as an ACE access > token. It also makes use of the auxiliary data and other elements of > EDHOC. But neither ANIMA nor LAKE seems to be the right working > groups. ANIMA is not using the ACE framework, and LAKE is for the > nearest future only concerned with the basic AKE. ANIMA BRSKI is not using the ACE framework, but that's because I don't think it was clear when we started the work that vouchers were semantically similar to JWT/CWT. Well, I tried to move things that way, but it was just too soon. When we started, I thought that the thing that the AS (W) returns to V is an RFC8366 semantic voucher (encoded to CBOR a la draft-ietf-anima-constrained-voucher). However, in the document it has taken on it's own life. I think that we tried to make it close to an ACE token. This is where the connection comes in. Jim: jim> I have been sitting this to try and make a decision and figure out jim> what my feelings are with this draft. I did a fast read through the jim> document, too fast to actually understand what it is trying to do, and jim> I immediately ran into the question of why this document would be part jim> of ACE. It is using the concepts of a voucher, which is not currently jim> an ACE concept, as one of the fundamental concepts. That combined with jim> the use of an AKE makes me very wary of this document. (I have not jim> spent enough time embedded in the ECIES and HPKE world to understand jim> this well.) I think that the ECIES and HPKE part is not particularly significant. There are some links at: https://www.sandelman.ca/SSW/ietf/brski-links/ The link: Generic Animation of BRSKI - Bootstrapping Remote Secure Key Infrastructure (ODP) (screencast) (enterprise/IoT screencast) points to: https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5 minutes long. I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained enrollment. -- ] 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[ signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile
-Original Message- From: Ace On Behalf Of John Mattsson Sent: Saturday, September 5, 2020 5:51 AM To: ace@ietf.org Subject: [Ace] Review of draft-ietf-ace-oscore-profile Major comment --- - Asignment of OSCORE Sender and Recipient IDs I think the specified mechanism where the AS dictates the OSCORE connection parameters is unfortunate. It introduces several current and future limitations. The current assignment mechanisms only works without problems in close systems where the RS does not have any other non-AS OSCORE connections, where the CoAP client and CoAP server roles are fixed and cannot be switched, and where only draft-ietf-ace-oscore-profile is used. In systems where the OSCORE nodes can switch between CoAP client and CoAP server (a feature explicitly supported by OSCORE) the current mechanism is likely to lead to RecipientID collisions. Also in future systems where the AS also supports a more modern key management with PFS using e.g. a future draft-ace-edhoc-oscore-profile, the mechanism would not work together in an efficient way. My understanding is that the authors would like the solution to work with both role switching and EDHOC. How to negotiate these type of connection identifiers (in this case OSCORE Sender and Recipient IDs) have been studied and specified several times in e.g. draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where each party choses its OSCORE recipient ID for the connection always work without collisions. Such a negotiation could quite easily be added to the roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile to do such a change. This would also require a new identifier for the OSCORE_Security_Context Object, either a new objectID or a hash of the object could be used. I think this would be a good change as the current "hack" of using the ACE client sender Id and and ID context to identify the object might lead to other future limitations. The suggested changes would lead quite equal message sizes and storage requirements, they might even lead to some small improvements. [JLS] I'll start with what I said on the mailing list - this problem was discussed previously on the mailing list and in person and it was decided that it did not need to be fixed. 1) The use of the same token on multiple RS has security problems on its own that cannot be overlooked. It is possible that we need to say that this just should not be done. If you are using symmetric keys all around, then RS1 an impersonate C to RS2 because it has all of the necessary keying material to post the token and setup a security context. RS1 can go farther and potentially impersonate the AS to RS2 gaining additional privileges when it impersonates C if the AS is using symmetric keys to validate tokens to RS1 and RS2. This indicates that generally one does not want to use the same token with multiple devices. 2) I mentioned that one could use trial decryption to distinguish between multiple RS senders. This is normally only going to require one trial due to the fact that one can use the source IP address for sorting the different security contexts for trial. As long as you do not have address collisions or changing addresses this makes things much easier to distinguish them. 3) You seem to be ignoring the most practical solution to the problem, use the context identifier for name space separation. If you have five different ASs, then simply assign a one byte context to each of them and you now have no problems with name collisions unless somebody is going to be knowingly difficult. Similarly, you assign each of the group key managers a one byte value which is used as the prefix to the contexts assigned by that key manager for all of the groups it manages. I would have to look to see if one can specify a context for LAKE, but being able to do so would provide a separation for that space as well. 4) I am not clear why Francesca thinks that doing the bis would make this a difficult thing to add. You add two new items and then you get following cases: a) The client does not use the new item: The ids in the token are going to be used b) The client sends the item: The server errors back because it does not support it and is strict - client goes to a) The server does not return a new item because it does not support it and is lax, the ids in the token are going to be used The server does return it's new item, the ids in the messages are going to be used. 5) I don't understand the case you are trying to make about reversing roles. First see point 1 above as the RS is not going to know who it is talking to, it could be C or it could be RS2 acting as an on-path attacker. [/JLS] Cheers, John ___ Ace mailing list Ace@ietf.org
Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
Hi, Rereading Section 6.4 again I think the discussion on Denial-of-Service / amplification attacks in Section 6.4 clearly needs more work. - "However a compromised RS may use this to perform a denial of service against a specific AS" Any attacker (not just a compromised RS) on the path beween C and RS can easily trick C into contacting any node S (not just an ACE AS). Such a forged message would be a denial-of-service attack on both C and N, not only on N. - "It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers" The list would need to be allowlist to have any effect. My understanding is that C could contact an AS it does not trust. Having an allowlist in C does not help in general. Even if C have a list stating that AS1, AS2, and AS3 is allowed, an attacker can impersonate RS3 (belonging to AS3) and fool C to contact AS1 or AS2. The attacker may even be able to get C to alternate between contacting AS1 and AS2. Possible DDoS attacks in the IoT space is very serious. Recently, the lagest DDoS attacks have all been using IoT devices. New protocols should mitigate amlification and DDoS attacks. Cheers, John -Original Message- From: John Mattsson Date: Monday, 7 September 2020 at 12:45 To: Seitz Ludwig , "ace@ietf.org" Subject: Re: AS discovery in draft-ietf-ace-oauth-authz-35 Hi Ludwig, The problem I have is that the current mechanism is presented as a generic discovery mechanism and that none of the disadvantages are mentioned in section 5.1. "A generic procedure is described in Section 5.1" The mechanism is not presented as an error message when the client in good faith tries to access a resource. It is presented as something C do intentionally to dicsover the AS. In the description in the draft, C is clearly aware that the request is unauthorized. Section 6.4 describes the security properties quite well. But I cannot see any discusion about the inefficiency of doing discovery over the C-RS path, which in many cases is contrained. The current presentation is: 5.1 generic procedure to discover AS 6.4 BTW this mechanism has some security limitation My view would be that is should be more like: 5.1 Error message with AS address X.X BTW the error message could be used for AS discovery but has limited effeciency and security and is not recommended. Cheers, John -Original Message- From: Seitz Ludwig Date: Monday, 7 September 2020 at 08:28 To: John Mattsson , "ace@ietf.org" Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35 Hi John, Replies inline /Ludwig > -Original Message- > From: Ace On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1.It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2.The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
Hi John, On 09/07/2020 12:45 PM, John Mattsson wrote: > > The mechanism is not presented as an error message when the client in good > faith tries to access a resource. It is presented as something C do > intentionally to dicsover the AS. In the description in the draft, C is > clearly aware that the request is unauthorized. Yes, the request and response are unauthorized. The client must ascertain that the AS is authorized to provide access token and access information to the client. Accordingly, section 6.5 states that "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS." The information that is provided by RS helps C to find the respective AS. If an attacker changed that information, C would still not communicate with an unauthorized AS. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
Hi John, please see inline for remarks in addition to Ludwig's response. John Mattsson writes: > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder > about the AS discovery mechanism in the ACE framework. Why is this > particular discovery mechanism given so much attention? Of all > possible discovery mechanisms, this seems like one of the worst as: > > 1. It requires a round-trip over the C-RS path which is typically the > most constrained path in the architecture. > 2. The response would in many cases be unprotected, which means C does > not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could > be any type of look up service) would in many cases be much more > efficient and should be recommended. It is clear that the AS Creation Hints are just hints, and, as documented, this information needs to be treated with utmost care. But I do not see how we would justify to recommend a non-constrained path to take for a potentially constrained client. A good solution to this problem (DNS-SD being just one possibility, CoRE RD another) would be to delegate AS discovery to a not-so-constrained entity in the same security domain as the client. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
Hi Ludwig, The problem I have is that the current mechanism is presented as a generic discovery mechanism and that none of the disadvantages are mentioned in section 5.1. "A generic procedure is described in Section 5.1" The mechanism is not presented as an error message when the client in good faith tries to access a resource. It is presented as something C do intentionally to dicsover the AS. In the description in the draft, C is clearly aware that the request is unauthorized. Section 6.4 describes the security properties quite well. But I cannot see any discusion about the inefficiency of doing discovery over the C-RS path, which in many cases is contrained. The current presentation is: 5.1 generic procedure to discover AS 6.4 BTW this mechanism has some security limitation My view would be that is should be more like: 5.1 Error message with AS address X.X BTW the error message could be used for AS discovery but has limited effeciency and security and is not recommended. Cheers, John -Original Message- From: Seitz Ludwig Date: Monday, 7 September 2020 at 08:28 To: John Mattsson , "ace@ietf.org" Subject: RE: AS discovery in draft-ietf-ace-oauth-authz-35 Hi John, Replies inline /Ludwig > -Original Message- > From: Ace On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1.It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2.The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35
Hi John, Replies inline /Ludwig > -Original Message- > From: Ace On Behalf Of John Mattsson > Sent: den 5 september 2020 14:53 > To: ace@ietf.org > Subject: [Ace] AS discovery in draft-ietf-ace-oauth-authz-35 > > Hi, > > I just reviewed draft-ietf-ace-oscore-profile. This made me wonder about > the AS discovery mechanism in the ACE framework. Why is this particular > discovery mechanism given so much attention? Of all possible discovery > mechanisms, this seems like one of the worst as: > > 1.It requires a round-trip over the C-RS path which is typically the most > constrained path in the architecture. > 2.The response would in many cases be unprotected, which means C > does not know if the response comes from RS or an attacker. > > A discovery mechanism using a non-contrained path (e.g. DNS, but could be > any type of look up service) would in many cases be much more efficient and > should be recommended. Such a mechanism might also be protected in > more cases and therefore rule out the possibility that the response came > from an attacker. > > I understand that the ACE framework draft does not want to specify any > other AS discovery mechanism, but at a minimum the severe limitations of > the current mechanism should be detailed. The limitations of this mechanism are detailed in section 6.4, do you think that there is some consideration missing from that section? > I my view the current mechanism > should be not recommended and only used as an error message when the > client in good faith try to access a resource believing that it might have the > right to access it. > It is indeed intended as an error message when the client in good faith tries to access a resource believing it might have the right to access it. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
