Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
-Original Message- From: Ace On Behalf Of Michael Richardson Sent: Wednesday, September 9, 2020 8:32 AM To: ace@ietf.org Subject: Re: [Ace] bringing draft-selander-ace-ake-authz to ACE? Göran Selander wrote: > We have been working on lightweight procedures for an IoT device to > join a network. The join process may include a number of components > such as authentication, remote attestation, authorization, enrolment of > locally significant certificate, etc. Much of current standards are > based on doing things in sequence, one thing at a time. This may be a > good idea but it introduces some redundancies. One way to reduce > overhead is to reuse elements from the authentication protocol in the > authorization or certificate enrolment processes. So, instead of > passing public keys and signatures multiple times between the same > endpoints over constrained links during different phases of the joining > procedure, we try to make more use of the authentication protocol while > ensuring that the security properties are as expected. ... > 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. Thinking a day later, I think that presenting a well animated view of ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what fits into ACE and what does not, would help out small design team clarify/debug our message, should we go to secdispatch, or whatever. [Jim: does that answer your question better?] I mean, we could also just hold our own virtual meeting too :-) [JLS] Yes this does a much better job of telling me what you are trying accomplishment. Having an idea of what the document is trying to do and what the problem that you are trying to solve makes it easier to slot in time for this. I am more than willing to have ACE sponsor a different time slot if you want to have a known amount of time up front for the presentation. I am willing to schedule it into the next meeting. But you never know how much time is going to get consumed dealing with adopted documents. [JLS] I still need to do a deep read on this document. Jim I am personally more interested in writing code than wrangling documents from WG to WG in the next ~4 months. I think that some other things in the IETF will sort themselves out in that timeframe, and a path forward will become clear. In the meantime, explaining things to others helps me get it right. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
-Original Message- From: Ace On Behalf Of Stefanie Gerdes Sent: Wednesday, September 9, 2020 4:12 AM To: ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy Hi John, On 09/09/2020 11:36 AM, John Mattsson wrote: >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack >>> vector for DoS attacks as an attacker on the C-RS path can make C >>> contact a chosen node on the Internet. >> >> The important part here is the "If". A proper client MUST NOT act on >> unauthorized information at any time. The workaround is the list of >> known AS'es in the draft. (In the current architecture, a client >> would not and cannot communicate with an unknown AS anyway as it has >> no way to establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST NOT > act on unauthorized information at any time”. This also raises the question > why the unauthorized information is needed in the first place. Hm, section 6.5 already states "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS." We can add "The client must not interact with an AS if it cannot determine that AS has the authority for this RS." We also should change section 6.4 because the attack described there is not possible as C must not interact with an AS that is not authorized for this RS. I think that paragraph is a relic. How about: old: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers, possibly including information used to authenticate the AS, such as a public key or certificate fingerprint. AS Request Creation Hints referring to a URI not listed there would be ignored. A compromised RS may use the hints to trick a client into contacting an AS that is not supposed to be in charge of that RS. Since this AS must be in the hard-coded list of trusted AS no violation of privileges and or exposure of credentials should happen, since a trusted AS is expected to refuse requestes for which it is not applicable and render a corresponding error response. However a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. new: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. C therefore must be able to determine if an AS is authorized to provide access tokens for a certain RS. A compromised RS may use the hints for attempting to trick a client into contacting an AS that is not supposed to be in charge of that RS. Therefore, C must not communicate with an AS if it cannot determine that this AS has the authority to issue access tokens for this RS. Otherwise, a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. [JLS] I do not know how C is supposed to be able to determine if AS has the authority to issue access tokens for a specific RS. If it had the ability to do that then it can go directly to the AS in question without ever needing to use this mechanism. This mechanism is designed to be used for the case where C does not have a priori knowledge about which AS it will talk to get the token for RS. > >>> - That RS shares the AS address with anybody that asks can be a >>> severe privacy problem. If RS is a medical device, the AS address >>> can reveal sensitive information. If RS is a blood pressure sensor >>> it could e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” [JLS] My first hope is that this RS would never return an AS address to a client. Sending information which has secure privacy problems amounts to a case where the rule should be: If C does not know what AS to talk to, it has no business talking to me (RS). [JLS] This is the type of situation where that information itself is going to be information to which access is to be restricted and where you need to talk to an AS to get permissions to get that information. In this type of situation I would expect that the information would only be available either throw an already secure channel or from a DS with the, not yet defined, AS attributes. Jim >> >> This is a valid concern. However, I would argue
Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
Göran Selander wrote: > We have been working on lightweight procedures for an IoT device to > join a network. The join process may include a number of components > such as authentication, remote attestation, authorization, enrolment of > locally significant certificate, etc. Much of current standards are > based on doing things in sequence, one thing at a time. This may be a > good idea but it introduces some redundancies. One way to reduce > overhead is to reuse elements from the authentication protocol in the > authorization or certificate enrolment processes. So, instead of > passing public keys and signatures multiple times between the same > endpoints over constrained links during different phases of the joining > procedure, we try to make more use of the authentication protocol while > ensuring that the security properties are as expected. ... > 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. Thinking a day later, I think that presenting a well animated view of ACE-AKE-AUTHZ at an ACE virtual interim and listening to feedback about what fits into ACE and what does not, would help out small design team clarify/debug our message, should we go to secdispatch, or whatever. [Jim: does that answer your question better?] I mean, we could also just hold our own virtual meeting too :-) I am personally more interested in writing code than wrangling documents from WG to WG in the next ~4 months. I think that some other things in the IETF will sort themselves out in that timeframe, and a path forward will become clear. In the meantime, explaining things to others helps me get it right. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
John Mattsson writes: > Hi Olof, > > Your reasoning does seem to be anchored in the draft. See inline. > > The current state of the draft is not acceptable. I may agree with you in this point in so far as the sections 6.4 and 6.5 might contradict each other as Steffi has pointed out previously. And I agree with you also if the requirements on proper behavior I have stated are not clearly stated in the draft as you seem to believe. More inline. > > -Original Message- > From: Olaf Bergmann > Date: Wednesday, 9 September 2020 at 10:20 > To: John Mattsson > Cc: "ace@ietf.org" , > "draft-ietf-ace-oauth-authz@ietf.org" > > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS > address, DoS, and privacy > > Hello John, > > Thank you for condensing this discussion thread. See inline for my > reasoning why I think that this issue is less severe than one would > expect at first: > > John Mattsson writes: > >>> Summarizing my thoughts and opinion on this issue. Changing the title >>> to highlight the issues better. >>> >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack vector >>> for DoS attacks as an attacker on the C-RS path can make C contact a >>> chosen node on the Internet. >> >>The important part here is the "If". A proper client MUST NOT act on >>unauthorized information at any time. The workaround is the list of >>known AS'es in the draft. (In the current architecture, a client would >>not and cannot communicate with an unknown AS anyway as it has no way to >>establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST > NOT act on unauthorized information at any time”. In this case we may need to state that. I presume the authors have treated that as natural behavior of any networked station on the Internet. > This also raises the question why the unauthorized information is > needed in the first place. As explained at the end of my previous post it is needed if there is no other discovery mechanism and to prevent the need to do a wks lookup in case an unauthorized plain-text request failed with a 4.01. >>> - That RS shares the AS address with anybody that asks can be a severe >>> privacy problem. If RS is a medical device, the AS address can reveal >>> sensitive information. If RS is a blood pressure sensor it could >>> e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” >> >>This is a valid concern. However, I would argue that the Uri-Path in >>this URI should not be constructed to reveal this information in the >>first place. All discussions so far assumed that the authorization >>information endpoint on the AS would be named more descriptively as, >>e.g., /autz-info. This could at least mitigate the issue. > > I don’t find anything in the draft stating that “the Uri-Path in this > URI should not be constructed to reveal this information”, or how such > a construction would look like. This is not trivial. The construction would be easy: coaps://as.hopkinsmedicine.org/authz-info. Not trivial if you want to disguise the FQDN as well. There is a lot of work on how to achieve this. See, e.g., [1] for a brief discussion and a working solution [2]. I agree with you that this might be worth a paragraph in the Privacy Considerations section. [1] S. Stadler, S. Gerdes, O. Bergmann: Privacy-enhanced Authenticationfor the Internet of Things. In: Proceedings of the 18. GI/ITG KuVS FachGespräch SensorNetze, FGSN 2019, Magdeburg, Germany, p. 37—40. Available online http://dx.doi.org/10.25673/28428, last access 2020-09-09. [2] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf/-/tree/abc >>> The requirement "the client MUST be able to determine whether an AS >>> has the authority to issue access tokens for a certain RS. This can >>> for example be done through pre-configured lists, or through an online >>> lookup mechanism that in turn also must be secured." indicates that C >>> is required to have another mechanism to determine the AS for a >>> specific RS and that the unauthorized AS address is completely >>> redundant. >> >>No. This indicates that before contacting an AS (in order to retrieve an >>access token for its communication with RS), the client must be sure >>that it trusts the AS to provide this access token. This is something >>that the client always needs to do, independent of the discovery >>mechanism. > > I don’t find anything in the draft stating that “the client must be > sure that it trusts the AS”. Which would be ill-worded. "Trust" is a useless term unless it is specified to what extend someone relies on someone else to do something. In this context this "trust" needs to be specified as: "The client must be sure that the AS is authorized to issue access tokens for RS to the
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi John, On 09/09/2020 11:36 AM, John Mattsson wrote: >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack vector >>> for DoS attacks as an attacker on the C-RS path can make C contact a >>> chosen node on the Internet. >> >> The important part here is the "If". A proper client MUST NOT act on >> unauthorized information at any time. The workaround is the list of >> known AS'es in the draft. (In the current architecture, a client would >> not and cannot communicate with an unknown AS anyway as it has no way to >> establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST NOT > act on unauthorized information at any time”. This also raises the question > why the unauthorized information is needed in the first place. Hm, section 6.5 already states "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS." We can add "The client must not interact with an AS if it cannot determine that AS has the authority for this RS." We also should change section 6.4 because the attack described there is not possible as C must not interact with an AS that is not authorized for this RS. I think that paragraph is a relic. How about: old: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers, possibly including information used to authenticate the AS, such as a public key or certificate fingerprint. AS Request Creation Hints referring to a URI not listed there would be ignored. A compromised RS may use the hints to trick a client into contacting an AS that is not supposed to be in charge of that RS. Since this AS must be in the hard-coded list of trusted AS no violation of privileges and or exposure of credentials should happen, since a trusted AS is expected to refuse requestes for which it is not applicable and render a corresponding error response. However a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. new: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. C therefore must be able to determine if an AS is authorized to provide access tokens for a certain RS. A compromised RS may use the hints for attempting to trick a client into contacting an AS that is not supposed to be in charge of that RS. Therefore, C must not communicate with an AS if it cannot determine that this AS has the authority to issue access tokens for this RS. Otherwise, a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. > >>> - That RS shares the AS address with anybody that asks can be a severe >>> privacy problem. If RS is a medical device, the AS address can reveal >>> sensitive information. If RS is a blood pressure sensor it could >>> e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” >> >> This is a valid concern. However, I would argue that the Uri-Path in >> this URI should not be constructed to reveal this information in the >> first place. All discussions so far assumed that the authorization >> information endpoint on the AS would be named more descriptively as, >> e.g., /autz-info. This could at least mitigate the issue. > > I don’t find anything in the draft stating that “the Uri-Path in this URI > should not be constructed to reveal this information”, or how such a > construction would look like. This is not trivial. I guess that an authorization server with such a URI is a general problem since the client needs to communicate with it at some point. This problem therefore is not specific for the AS Request Creation Hints. Nevertheless, we should clarify the impact of the not carefully chosen hints on the privacy in the privacy considerations. There already is some text about the unauthorized request in the privacy considerations. How about: old: An unprotected response to an unauthorized request (see Section 5.1.2) may disclose information about RS and/or its existing relationship with C. It is advisable to include as little information as possible in an unencrypted response. new: An unprotected response to an unauthorized request (see Section 5.1.2) may disclose information about RS and/or its existing relationship with C. It
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi Olof, Your reasoning does seem to be anchored in the draft. See inline. The current state of the draft is not acceptable. Grüße, John Preuß Mattsson -Original Message- From: Olaf Bergmann Date: Wednesday, 9 September 2020 at 10:20 To: John Mattsson Cc: "ace@ietf.org" , "draft-ietf-ace-oauth-authz@ietf.org" Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy Hello John, Thank you for condensing this discussion thread. See inline for my reasoning why I think that this issue is less severe than one would expect at first: John Mattsson writes: >> Summarizing my thoughts and opinion on this issue. Changing the title >> to highlight the issues better. >> >> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >> happily send the AS address to any node that asks. This causes two >> problems. >> >> - If C acts on the unauthorized information, this is an attack vector >> for DoS attacks as an attacker on the C-RS path can make C contact a >> chosen node on the Internet. > >The important part here is the "If". A proper client MUST NOT act on >unauthorized information at any time. The workaround is the list of >known AS'es in the draft. (In the current architecture, a client would >not and cannot communicate with an unknown AS anyway as it has no way to >establish a secure communication.) I cannot find anything in the draft stating that “A proper client MUST NOT act on unauthorized information at any time”. This also raises the question why the unauthorized information is needed in the first place. >> - That RS shares the AS address with anybody that asks can be a severe >> privacy problem. If RS is a medical device, the AS address can reveal >> sensitive information. If RS is a blood pressure sensor it could >> e.g. be “AS address = >> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > >This is a valid concern. However, I would argue that the Uri-Path in >this URI should not be constructed to reveal this information in the >first place. All discussions so far assumed that the authorization >information endpoint on the AS would be named more descriptively as, >e.g., /autz-info. This could at least mitigate the issue. I don’t find anything in the draft stating that “the Uri-Path in this URI should not be constructed to reveal this information”, or how such a construction would look like. This is not trivial. >> The requirement "the client MUST be able to determine whether an AS >> has the authority to issue access tokens for a certain RS. This can >> for example be done through pre-configured lists, or through an online >> lookup mechanism that in turn also must be secured." indicates that C >> is required to have another mechanism to determine the AS for a >> specific RS and that the unauthorized AS address is completely >> redundant. > >No. This indicates that before contacting an AS (in order to retrieve an >access token for its communication with RS), the client must be sure >that it trusts the AS to provide this access token. This is something >that the client always needs to do, independent of the discovery >mechanism. I don’t find anything in the draft stating that “the client must be sure that it trusts the AS”. The draft states that “It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers”. “Advisable” is not the same as “must”, “trustworthy” is not the same as “trust, and “C trust in AS” is completely different than “whether an AS has the authority to issue access tokens for a certain RS” >> The draft does not discuss the privacy issues of unauthorized AS >> addresses at all and the draft is diminishing the DoS issues by only >> talking about compromised RS and attacking an AS. This indicates that >> none of these issues has been discussed enough. >> >> I currently have a strong opinion that Unauthorized AS address should >> be removed from the specification. > >I still think that due to the lack of a secure discovery mechanism for >authorized AS'es, this mechanism is the best we have. Otherwise, the >specification would leave the reader completely in the dark on how to >guess to which AS the RS has delegated its authorization tasks. (A >natural way would be to include it in /.well-known/core but I fail to >see a difference except for an additional roundtrip in case the client >is not aware a priori that the requested resource is protected.) Your reasoning seems to indicate that the mechanism "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS” is just an imaginary requirement, and not something you believe will be possible in practice. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Assignment of OSCORE Sender and Recipient IDS - was RE: Review of draft-ietf-ace-oscore-profile
I agree very much with you Jim regarding the use on symmetric keys, and I think this is something IETF needs to work with in the future. I think a lot of IETF groups and drafts are using way too much symmetric keys for authentication and key exchange. There seems to be a belief that symmetric keys are needed for constrained IoT, which is not the case. Asymmetric authentication and key exchange can be achieved in similar message sizes to PSK authentication. E.g. - method type 3 (static DH Key + static DH Key) in https://tools.ietf.org/html/draft-ietf-lake-edhoc-01 - static-static Diffie-Hellman shared secret in https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-09 There are also very efficient ECC implementations taking up just a few kB. Two-party authentication with symmetric keys comes with privacy problems, and symmetric groups keys does not provide authentication of the peer, just group membership. Symmetric key exchange does not provide PFS. Symmetric keys also comes with severe deployment problems. While there are cases where asymmetric cryptography requires too much storage, memory, message sizes, or processing (latency), these are exceptions and should not be the default. I see a limited need for symmetric authentication or key exchange in new systems, and I think the use should be clearly motivated. The main reason to use symmetric keys is in my view legacy interop. John -Original Message- From: Jim Schaad Date: Wednesday, 9 September 2020 at 00:48 To: John Mattsson , "ace@ietf.org" Subject: RE: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile Hey John, comments in line commented with JLS2 -Original Message- From: John Mattsson Sent: Tuesday, September 8, 2020 12:34 AM To: Jim Schaad ; ace@ietf.org Subject: Re: Assignment of OSCORE Sender and Recipient IDS - was RE: [Ace] Review of draft-ietf-ace-oscore-profile Hi Jim, I agree with most of what you say. Below are some additional comments on some of the bullets. [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. [JM] My understanding from Francesca and Göran is that neither migration path to e.g. EDHOC nor systems where the nodes change roles have been discussed before. Both have additional collision probems. How important the use cases are and how bad the collision problem would be can be discussed. [JLS2] This may be a case of people not hearing things that they don't think are of immediate importance. I spent a couple of years arguing about much of this. I did not deal with the reversing situation because I am not sure that this really makes a great deal of sense for ACE in general. The one exception would be things like revocation, but that is always going to be a single RS. [JLS] 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. [JM] Yes, that is definitely a solution, but I don't think it matters if you use ID context or longer Sender IDs, it's the sum of the lengths that matter for the collision probability. I agree that you can definitely solve the collision problem by randomly assigning longer ID Context + Sender ID, potentially combined with a mechanism (as you mentioned during the interim) where the client rejects tokens that lead to collisions. This solves collision problems on with the cost of additional roundtrips and/or larger OSCORE message sizes. Both could be acceptable, but unfortunate as collision free and optimal (in terms of message size) are well-known and there seems to be no benefits of the AS dictating Sender and Recipient IDs. Both RFC 7252 and RFC 8613 is very careful to not waste a single byte. [JLS2] Please re-read what I outlined. I was suggesting the use of very short ID contexts which are assigned in a non-random method. This means that the collision probability can be highly controlled and you are not using longer sender IDs that you would otherwise. [JLS2] One of the big advantages of the AS assigning client ids is that updated tokens will have the same client IDs so that you don't end up with having to change these because you do not recognize that it should be the same security conversation. There are also advantages because neither party needs to
Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?
Hi Michael, and all, No, this hasn't been discussed in ACE yet. But since you brought it to the list, we may restart the discussion here. We have been working on lightweight procedures for an IoT device to join a network. The join process may include a number of components such as authentication, remote attestation, authorization, enrolment of locally significant certificate, etc. Much of current standards are based on doing things in sequence, one thing at a time. This may be a good idea but it introduces some redundancies. One way to reduce overhead is to reuse elements from the authentication protocol in the authorization or certificate enrolment processes. So, instead of passing public keys and signatures multiple times between the same endpoints over constrained links during different phases of the joining procedure, we try to make more use of the authentication protocol while ensuring that the security properties are as expected. The draft in the subject is looking at third party authorization. It uses the "auxiliary data" extension point of EDHOC, and reuses the client ephemeral key/nonce with the authorization server. The actual authorization information is carried in a "voucher" using the ANIMA terminology, but is requested and retrieved as an 8 byte access token using a new ACE profile. This enables mutual authentication and authorization at completion of EDHOC, and with little additional overhead compared to EDHOC. A certificate enrolment request may in a similar way be included in message 3 (not covered in this draft) since authentication and authorization of responder takes place at reception of message 2. In order for sending back a certificate (or a reference to a certificate) to the initator, a fourth message needs to be added, but the overall join procedure could be completed in two round trips. The question is if ACE is the right place to discuss this topic. Göran On 2020-09-08, 03:04, "Michael Richardson" wrote: 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://protect2.fireeye.com/v1/url?k=245f61e6-7affa3a3-245f217d-8692dc8284cb-0438c9725de3a5ae=1=43232919-eac0-44fe-9b22-4dd1e1e25947=https%3A%2F%2Fwww.sandelman.ca%2FSSW%2Fietf%2Fbrski-links%2F 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 https://protect2.fireeye.com/v1/url?k=d54ae6c7-8bea2482-d54aa65c-8692dc8284cb-93b42ef9756fce01=1=43232919-eac0-44fe-9b22-4dd1e1e25947=http%3A%2F%2Fwww.sandelman.ca%2F | ruby on rails[ ___ Ace mailing list Ace@ietf.org
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hello John, Thank you for condensing this discussion thread. See inline for my reasoning why I think that this issue is less severe than one would expect at first: John Mattsson writes: > Summarizing my thoughts and opinion on this issue. Changing the title > to highlight the issues better. > > As currently specified in draft-ietf-ace-oauth-authz-35, the RS will > happily send the AS address to any node that asks. This causes two > problems. > > - If C acts on the unauthorized information, this is an attack vector > for DoS attacks as an attacker on the C-RS path can make C contact a > chosen node on the Internet. The important part here is the "If". A proper client MUST NOT act on unauthorized information at any time. The workaround is the list of known AS'es in the draft. (In the current architecture, a client would not and cannot communicate with an unknown AS anyway as it has no way to establish a secure communication.) > - That RS shares the AS address with anybody that asks can be a severe > privacy problem. If RS is a medical device, the AS address can reveal > sensitive information. If RS is a blood pressure sensor it could > e.g. be “AS address = > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” This is a valid concern. However, I would argue that the Uri-Path in this URI should not be constructed to reveal this information in the first place. All discussions so far assumed that the authorization information endpoint on the AS would be named more descriptively as, e.g., /autz-info. This could at least mitigate the issue. > The requirement "the client MUST be able to determine whether an AS > has the authority to issue access tokens for a certain RS. This can > for example be done through pre-configured lists, or through an online > lookup mechanism that in turn also must be secured." indicates that C > is required to have another mechanism to determine the AS for a > specific RS and that the unauthorized AS address is completely > redundant. No. This indicates that before contacting an AS (in order to retrieve an access token for its communication with RS), the client must be sure that it trusts the AS to provide this access token. This is something that the client always needs to do, independent of the discovery mechanism. > The draft does not discuss the privacy issues of unauthorized AS > addresses at all and the draft is diminishing the DoS issues by only > talking about compromised RS and attacking an AS. This indicates that > none of these issues has been discussed enough. > > I currently have a strong opinion that Unauthorized AS address should > be removed from the specification. I still think that due to the lack of a secure discovery mechanism for authorized AS'es, this mechanism is the best we have. Otherwise, the specification would leave the reader completely in the dark on how to guess to which AS the RS has delegated its authorization tasks. (A natural way would be to include it in /.well-known/core but I fail to see a difference except for an additional roundtrip in case the client is not aware a priori that the requested resource is protected.) Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi, Summarizing my thoughts and opinion on this issue. Changing the title to highlight the issues better. As currently specified in draft-ietf-ace-oauth-authz-35, the RS will happily send the AS address to any node that asks. This causes two problems. - If C acts on the unauthorized information, this is an attack vector for DoS attacks as an attacker on the C-RS path can make C contact a chosen node on the Internet. - That RS shares the AS address with anybody that asks can be a severe privacy problem. If RS is a medical device, the AS address can reveal sensitive information. If RS is a blood pressure sensor it could e.g. be “AS address = coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” The requirement "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS. This can for example be done through pre-configured lists, or through an online lookup mechanism that in turn also must be secured." indicates that C is required to have another mechanism to determine the AS for a specific RS and that the unauthorized AS address is completely redundant. The draft does not discuss the privacy issues of unauthorized AS addresses at all and the draft is diminishing the DoS issues by only talking about compromised RS and attacking an AS. This indicates that none of these issues has been discussed enough. I currently have a strong opinion that Unauthorized AS address should be removed from the specification. Cheers, John ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review of draft-ietf-ace-oscore-profile
I agree we need to distinguish between managed id-spaces, like groupcomm, and cases where we do not strictly need to manage the ids. Given the discussion we are having here, a recommendation for to add to RFC8613 would be "Each endpoint SHOULD assign its recipient identifiers." This is what EDHOC does and, with hindsight, this is what the ACE-OSCORE profile should have done. There is no security issue with the current draft, it is about simplifying the identification of security contexts in various situations by removing the need for special considerations due to identifiers allocated by different parties. I see no drawbacks in allowing the endpoints make the assignment (an OSCORE protected resource request must complete before parties are authenticated but this is also required in the current version, Sender/Recipient ID may be reused for updated access rights between the same endpoints, Client/Server ID terminology becomes redundant, ... ) except that we are very late in the process. And this is the authors' fault, Jim has been raising issues on this topic and we have not been responsive. Göran On 2020-09-09, 08:52, "John Mattsson" wrote: The question in my view is if this draft should create collisions. All other drafts assigning identities to RFC 8613 that have ever been discussed in the IETF takes efforts to not create any collisions in the first place https://tools.ietf.org/html/draft-selander-lake-edhoc-01 https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00 https://tools.ietf.org/html/draft-friel-tls-atls-04 All these assignment mechanism can be used together collision-free without ID Context and with minimal length Sender ID / Recipient ID. So I don’t think the statement that “Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established.” is correct. Group OSCORE is a different story, there the assignment mechanism have to handle collisions with ID Contexts (unless the deployment is strictly local, e.g. when used only over a local radio technology). One option is that this draft recommends the use of an ID context unless the draft is uses in a local closed system, and that a bis version of the draft makes the simple changes to not get collisions in the first place. It would as you say have been very good if RFC 8613 discussed how to negotiate Sender ID / Recipient ID. If there is ever a bis version, this should definitly be added. John -Original Message- From: Jim Schaad Date: Tuesday, 8 September 2020 at 21:14 To: John Mattsson , Göran Selander , "ace@ietf.org" Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile John, I am wondering if this is really the document that should be dealing with this collision problem. A number of the collisions that might occur are going to be out of the ACE scope and a more general discussion of the problem should probably occur in a BIS version of the CoRE OSCORE document itself. Memory says that the document does not claim to deal with how names are assigned to contexts, but I think that having a centralized location that LAKE, ACE (AS, Groupcomm and pub-sub) and perhaps other methods that we don’t currently have in our radar. Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established. Jim -Original Message- From: Ace On Behalf Of John Mattsson Sent: Tuesday, September 8, 2020 12:40 AM To: Göran Selander ; ace@ietf.org Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to say that I don't have any strong opinions on how to proceed. I just wanted to point out the collision problems with the draft are more severe that the group have discussed. Ignoring collisions seems like a mistake, and to my understanding there seems to be no benefits of the AS dictating Sender and Recipient IDs. I think Jim has a good point in that the solution with symmetric key authentication comes with a lot of limitations anyway. /John -Original Message- From: Göran Selander Date: Monday, 7 September 2020 at 17:05 To: John Mattsson , "ace@ietf.org" Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to acknowledge, as was discussed in the WG meeting today, that the major comment below is alternatively a possible -bis update. I think this is good functionality, and even though related problem statements have been discussed before, this solution has not. And although the change is small it comes at a late stage. But if it doesn't make it for this version then let's make it in an update soon. Göran On 2020-09-05, 14:51, "Ace on behalf of John Mattsson" wrote: Hi, I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
Re: [Ace] Review of draft-ietf-ace-oscore-profile
The question in my view is if this draft should create collisions. All other drafts assigning identities to RFC 8613 that have ever been discussed in the IETF takes efforts to not create any collisions in the first place https://tools.ietf.org/html/draft-selander-lake-edhoc-01 https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00 https://tools.ietf.org/html/draft-friel-tls-atls-04 All these assignment mechanism can be used together collision-free without ID Context and with minimal length Sender ID / Recipient ID. So I don’t think the statement that “Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established.” is correct. Group OSCORE is a different story, there the assignment mechanism have to handle collisions with ID Contexts (unless the deployment is strictly local, e.g. when used only over a local radio technology). One option is that this draft recommends the use of an ID context unless the draft is uses in a local closed system, and that a bis version of the draft makes the simple changes to not get collisions in the first place. It would as you say have been very good if RFC 8613 discussed how to negotiate Sender ID / Recipient ID. If there is ever a bis version, this should definitly be added. John -Original Message- From: Jim Schaad Date: Tuesday, 8 September 2020 at 21:14 To: John Mattsson , Göran Selander , "ace@ietf.org" Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile John, I am wondering if this is really the document that should be dealing with this collision problem. A number of the collisions that might occur are going to be out of the ACE scope and a more general discussion of the problem should probably occur in a BIS version of the CoRE OSCORE document itself. Memory says that the document does not claim to deal with how names are assigned to contexts, but I think that having a centralized location that LAKE, ACE (AS, Groupcomm and pub-sub) and perhaps other methods that we don’t currently have in our radar. Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established. Jim -Original Message- From: Ace On Behalf Of John Mattsson Sent: Tuesday, September 8, 2020 12:40 AM To: Göran Selander ; ace@ietf.org Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to say that I don't have any strong opinions on how to proceed. I just wanted to point out the collision problems with the draft are more severe that the group have discussed. Ignoring collisions seems like a mistake, and to my understanding there seems to be no benefits of the AS dictating Sender and Recipient IDs. I think Jim has a good point in that the solution with symmetric key authentication comes with a lot of limitations anyway. /John -Original Message- From: Göran Selander Date: Monday, 7 September 2020 at 17:05 To: John Mattsson , "ace@ietf.org" Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to acknowledge, as was discussed in the WG meeting today, that the major comment below is alternatively a possible -bis update. I think this is good functionality, and even though related problem statements have been discussed before, this solution has not. And although the change is small it comes at a late stage. But if it doesn't make it for this version then let's make it in an update soon. Göran On 2020-09-05, 14:51, "Ace on behalf of John Mattsson" wrote: Hi, I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f=1=5ecc1a37-faa1-4082-857b-150aa2dc3b9a=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html In general this draft looks very good. I have one major comments, and several more minor comments. 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
Re: [Ace] Review of draft-ietf-ace-oscore-profile
The question in my view is if this draft should create collisions. All other drafts that have ever been discussed in the IETF takes efforts to not create any collisions in the first place https://tools.ietf.org/html/draft-selander-lake-edhoc-01 https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00 https://tools.ietf.org/html/draft-friel-tls-atls-04 All these assignment mechanism can be used together collision-free without ID Context and with minimal length Sender ID / Recipient ID. So I don’t think the statement that “Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established.” is correct. Group OSCORE is a different story, there the assignment mechanism have to handle collisions with ID Contexts (unless the deployment is strictly local, e.g. when used only over a local radio technology). One option is that this draft recommends the use of an ID context and that a bis version of the draft makes the simple changes to not get collisions in the first place. It would as you say have been very good if RFC 8613 discussed how to negotiate Sender ID / Recipient ID. If there is ever a bis version, this should definitly be added. John -Original Message- From: Jim Schaad Date: Tuesday, 8 September 2020 at 21:14 To: John Mattsson , Göran Selander , "ace@ietf.org" Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile John, I am wondering if this is really the document that should be dealing with this collision problem. A number of the collisions that might occur are going to be out of the ACE scope and a more general discussion of the problem should probably occur in a BIS version of the CoRE OSCORE document itself. Memory says that the document does not claim to deal with how names are assigned to contexts, but I think that having a centralized location that LAKE, ACE (AS, Groupcomm and pub-sub) and perhaps other methods that we don’t currently have in our radar. Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established. Jim -Original Message- From: Ace On Behalf Of John Mattsson Sent: Tuesday, September 8, 2020 12:40 AM To: Göran Selander ; ace@ietf.org Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to say that I don't have any strong opinions on how to proceed. I just wanted to point out the collision problems with the draft are more severe that the group have discussed. Ignoring collisions seems like a mistake, and to my understanding there seems to be no benefits of the AS dictating Sender and Recipient IDs. I think Jim has a good point in that the solution with symmetric key authentication comes with a lot of limitations anyway. /John -Original Message- From: Göran Selander Date: Monday, 7 September 2020 at 17:05 To: John Mattsson , "ace@ietf.org" Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile Hi, Just want to acknowledge, as was discussed in the WG meeting today, that the major comment below is alternatively a possible -bis update. I think this is good functionality, and even though related problem statements have been discussed before, this solution has not. And although the change is small it comes at a late stage. But if it doesn't make it for this version then let's make it in an update soon. Göran On 2020-09-05, 14:51, "Ace on behalf of John Mattsson" wrote: Hi, I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f=1=5ecc1a37-faa1-4082-857b-150aa2dc3b9a=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html In general this draft looks very good. I have one major comments, and several more minor comments. 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
