Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
|
Roger Brown <RBrown@...>
Hello,
Please let me introduce myself. I am Roger Brown and I manage the Coordinated Vulnerability Disclosure programme within the GSMA. The programme offers an avenue for researchers to disclose Telco industry vulnerabilities. We then work with the industry to develop fixes and mitigations to protect the industry and its customers. We have recently received an OAuth2.0 vulnerability and we hoped someone at OpenApi might be able to assist with a couple of questions regarding your specifications:
The openAPI specification contains the following statements: 1) "To make security optional, an empty security requirement ({}) can be included in the array.", and 2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."
We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.
So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?
Many thanks for any assistance you can offer. If this has been sent to the wrong email account, please could you advise who would be best to contact.
Kind Regards, Roger Brown
Roger Brown Security Services Manager +447740433437
gsma.com
. |
||||||
|
|
||||||
|
Hi Roger, Sorry for the delay in response. The best place to go for answers is probably the #spec channel on Slack. To join Slack please use: If you run into any issues, please let me know, ncaidin@... . We also have a Discord space for discussions: Best regards, Neal Neal Caidin Program Manager, Program Management & Operations The Linux Foundation +1 (919) 238-9104 (w/h) +1 (919) 949-1861 (m) On Wed, Sep 28, 2022 at 7:56 AM Roger Brown <RBrown@...> wrote:
|
||||||
|
|
||||||
|
Zugenmaier, Alf <alf.zugenmaier@...>
Hi Darrel and Mark,
also from my side many thanks for the explanations.
This link will take you to a set of specifications produced by 3GPP: In the 29 series, there are a number of specifications that include API specifications: https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False A good one to start looking at is the specification for the AMF: 29.518 https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339 Looking at the latest version: https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip In that zip file, there is a yaml file and a textual description. That specification doesn't stand alone though, it builds on an architecture set out in 3GPP TS23.501 and TS23.502, as well as more protocol related, but still general TS29.500 and TS29.501.
Cheers,
Alf
Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:
|
||||||
|
|
||||||
|
Roger Brown <RBrown@...>
Hi Darrel, Mark,
Many thanks for the very useful call just now. Please see below the questions we discussed. For context here is some detail on the GSMA’s Coordinated Vulnerability Disclosure programme. @alf.zugenmaier@... if you could kindly add the links to the 3GPP Specs.
The openAPI specification contains the following statements: 1) "To make security optional, an empty security requirement ({}) can be included in the array.", and 2) "When a list of Security Requirement Objects is defined on the OpenAPI Object or Operation Object, only one of the Security Requirement Objects in the list needs to be satisfied to authorize the request."
We have a question about the meaning of the word optional here: In the language defining an API in a 3GPP specification, "optional use of OAuth" means that use of OAuth shall be controlled by a policy at deployment time; but if the policy at deployment time says it shall be used, then it becomes mandatory for all calls to the API.
So the question is how the corresponding .yaml file for the API specification within the standard would express this kind of optionality. Would it be correct to add the empty security requirement to the API specification ({}), as one could interpret from the quote 1)? Or would the presence of ({}) mean, that during runtime even requests without any token would be authorized as quote 2) from above would seem to imply?
Kind Regards, Roger Brown
Roger Brown Security Services Manager +447740433437
gsma.com
. |
||||||
|
|
||||||
|
Hi Alf,
As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call. I have also included Marsh and Ron from the TSC to give
them the opportunity share their perspective on this topic also.
As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture. While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may
choose different configuration options that might enable or disable certain features.
The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.
An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities. It is expected that when a client attempts to use those described
capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.
In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability. For example,
{
"security": [
{
x-runtime-configurable: true
},
{
"oAuth2ClientCredentials" : [],
x-runtime-configurable: true
}
]
}
It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this. The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.
The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times. It is a viable use case, just not one we see often. We welcome additional
input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios.
Please let me know if you have other questions,
Regards,
Darrel Miller
From: Zugenmaier, Alf <alf.zugenmaier@...>
Sent: Thursday, November 3, 2022 5:15 PM To: Darrel Miller <Darrel.Miller@...>; RBrown@... <RBrown@...>; Mark Weitzel <markweitzel@...> Cc: tsc@openapi.groups.io <tsc@openapi.groups.io> Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
Hi Darrel and Mark,
also from my side many thanks for the explanations.
This link will take you to a set of specifications produced by 3GPP: In the 29 series, there are a number of specifications that include API specifications:
https://portal.3gpp.org/Specifications.aspx?q=1&series=23&releases=all&draft=False&underCC=False&withACC=False&withBCC=False&numberNYA=False A good one to start looking at is the specification for the AMF: 29.518 https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3339 Looking at the latest version: https://www.3gpp.org/ftp/Specs/archive/29_series/29.518/29518-h70.zip In that zip file, there is a yaml file and a textual description. That specification doesn't stand alone though, it builds on an architecture set out in 3GPP TS23.501 and TS23.502, as well as more protocol related, but still general TS29.500 and TS29.501.
Cheers,
Alf
Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:
|
||||||
|
|
||||||
|
Roger Brown <RBrown@...>
Hi Darrel,
Many thanks for this, it’s a very good description of the concern and suggested mitigation. Off the back of this we plan to create an LS to 3GPP using your assessment below as the basis and plan to attribute the OpenAPI Initiative TSC.
Can you confirm you are happy for us to go ahead with this plan? We’d be happy to share the LS with you before it is sent.
Kind Regards, Roger Brown
Roger Brown Security Services Manager +447740433437
gsma.com
From: Darrel Miller <Darrel.Miller@...>
Sent: 05 November 2022 18:03 To: alf.zugenmaier@...; Roger Brown <RBrown@...>; Mark Weitzel <markweitzel@...>; marshg@...; webron@...; Neal Caidin <ncaidin@...> Cc: tsc@openapi.groups.io Subject: Re: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”
Hi Alf,
As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call. I have also included Marsh and Ron from the TSC to give them the opportunity share their perspective on this topic also.
As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture. While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may choose different configuration options that might enable or disable certain features.
The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.
An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities. It is expected that when a client attempts to use those described capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.
In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability. For example,
{ "security": [ { x-runtime-configurable: true }, { "oAuth2ClientCredentials" : [], x-runtime-configurable: true } ] }
It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this. The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.
The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times. It is a viable use case, just not one we see often. We welcome additional input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios.
Please let me know if you have other questions,
Regards,
Darrel Miller
From: Zugenmaier, Alf <alf.zugenmaier@...>
Hi Darrel and Mark,
also from my side many thanks for the explanations.
In the 29 series, there are a number of specifications that include API specifications: protocol related, but still general TS29.500 and TS29.501.
Cheers, Alf
Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:
. |
||||||
|
|
||||||
|
Hi Roger,
Sounds good to me.
Darrel
From: Roger Brown <RBrown@...>
Sent: Thursday, November 10, 2022 11:03 AM To: Darrel Miller <Darrel.Miller@...>; alf.zugenmaier@... <alf.zugenmaier@...>; Mark Weitzel <markweitzel@...>; marshg@... <marshg@...>; webron@... <webron@...>; Neal Caidin <ncaidin@...> Cc: tsc@openapi.groups.io <tsc@openapi.groups.io> Subject: RE: Question from GSMA Coordinated Vulnerability Disclosure Programme - OAuth2.0 and use of brackets in specifications
Hi Darrel,
Many thanks for this, it’s a very good description of the concern and suggested mitigation. Off the back of this we plan to create an LS to 3GPP using your assessment below as the basis and plan to attribute the OpenAPI Initiative TSC.
Can you confirm you are happy for us to go ahead with this plan? We’d be happy to share the LS with you before it is sent.
Kind Regards, Roger Brown
Roger Brown Security Services Manager +447740433437
gsma.com
From: Darrel Miller <Darrel.Miller@...>
“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”
Hi Alf,
As one of the members of the OpenAPI Initiative Technical Steering committee, I want to provide you with a written version of the answer I provided to your question raised in this weeks community call. I have also included Marsh and Ron from the TSC to give them the opportunity share their perspective on this topic also.
As I understand it, the 3GPP group use OpenAPI descriptions for the formal definition of APIs in their service based architecture. While your OpenAPI descriptions describe the set of possible features and capabilities of an API, a specific API deployment may choose different configuration options that might enable or disable certain features.
The particular area of concern is with the description of security requirement objects and the relationship between what is described in the OpenAPI definition and what is possible in a specific deployment of an API that implements the OpenAPI definition.
An API that implements an OpenAPI definition should provide the capabilities described, however, nothing prevents someone who deploys that API from disabling some of the described capabilities. It is expected that when a client attempts to use those described capabilities that the HTTP API respond with an appropriate HTTP status code and a error payload explaining why those capabilities do not behave as expected.
In order to help client developers be aware that certain capabilities may not be accessible at runtime, the OpenAPI definition could include a custom extension to signal this variability. For example,
{ "security": [ { x-runtime-configurable: true }, { "oAuth2ClientCredentials" : [], x-runtime-configurable: true } ] }
It is necessary to use an "x-" extension to describe this variability as there is currently no native way to describe this. The x-runtime-configurable name is simply a suggestion, you may find another name that is more descriptive.
The majority of usage of OpenAPI is to describe a particular instance of an API, not to describe a standard API shape that could be implemented by multiple providers and deployed many times. It is a viable use case, just not one we see often. We welcome additional input from your organization to identify ways in which OpenAPI could be improved in order to address your scenarios.
Please let me know if you have other questions,
Regards,
Darrel Miller
From: Zugenmaier, Alf <alf.zugenmaier@...>
Hi Darrel and Mark,
also from my side many thanks for the explanations.
In the 29 series, there are a number of specifications that include API specifications: protocol related, but still general TS29.500 and TS29.501.
Cheers, Alf
Am Donnerstag, dem 03.11.2022 um 17:08 +0000 schrieb Roger Brown:
. |
||||||
|
|
