Re: xNF Security Requirements for HTTPS
Pawel Baniewski (Nokia)
During the last call (16th of July) there was a misunderstanding how server challenges client in client certificate authentication flow. It was told that when server challenges client to present client’s certificate it can’t fall back to Basic Auth and that is why every listening component needs to open TWO ports. But in fact all modern web-servers support usually two options:
· Require Client Cert – yes/no
· Fail if client doesn’t present own certificate – yes/no
In NGINX e.g. these two options are bundled and configured by one property - http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_verify_client
In Apache httpd the same story - https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html#intranet && https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslverifyclient
In such case, VES can open one port and require client cert = yes + don’t fail if client cert not present to fall back to Basic Authentication.
In other words, we can remove from auth.method two options: basicAuth and certOnly and change VES listener to behave as certBasicAuth by default. And in code check that when client presents cert, but also presents user/pass – do whatever we want – fail or choose cert. For development purpose, we can switch auth.method to noAuth.
This will simplify requirements, implementation and the most important – clients (xNF’s) won’t have to know how server (VES) is configured.
Nokia Mobile Networks BTSOAM Serviceability ARCH Tribe Architect
mobile: +48 728 361 386
From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: Monday, July 29, 2019 11:12 AM
To: Horn, Linda (Nokia - US/Murray Hill) <linda.horn@...>; ZWARICO, AMY <az9121@...>; onap-seccom@...; PAWLAK Pawel O-PL <pawel.pawlak3@...>; 'Krzysztof Opasiak' <k.opasiak@...>; CLOSE, PIERRE <pierre.close@...>; THORPE, HENRY E <ht1659@...>; 'Michela Bevilacqua' <michela.bevilacqua@...>; 'Zygmunt Lozinski' <zygmunt_lozinski@...>; HANSEN, TONY L <tony@...>; GATHMAN, JONATHAN C <jonathan.gathman@...>; 'Harald.Fuchs@...' <Harald.Fuchs@...>; 'meng.zhaoxing1@...' <meng.zhaoxing1@...>; Hillis, Marge (Nokia - US) <marge.hillis@...>; Kukulski, Marek (Nokia - PL/Wroclaw) <marek.kukulski@...>; Murgoski, Zlatko (Nokia - PL/Wroclaw) <zlatko.murgoski@...>
Subject: Re: [Onap-seccom] xNF Security Requirements for HTTPS
Many thnaks for this new version of the document.
Here are a few remarks :
o 1. For a client with a valid certificate, DCAE VES Event Listener MUST pass the client authentication and MUST use the Subject Name in the certificate as the client identity for authorization according to RFC 5280.
2. For a client with no or an invalid certificate and with correct basic authentication credentials, DCAE VES Event Listener MUST pass the client authentication and MUST use the username in the Authorization header as the client identity for authorization.
3. For a client with no or an invalid certificate and with no or incorrect basic authentication credentials, DCAE VES Event Listener MUST fail the client authentication.
==> indeed the N-3 forbids the basic authentication in case the client certificate is invalid whereas the 0-4 enables the fallback to basic authentication in case the certificate is invalid.
De : Horn, Linda (Nokia - US/Murray Hill) [linda.horn@...]
Updated version of the security requirements for HTTPS authentication enhancements are on the wiki here.
They are at the bottom of the page and dated July 23 2019.
These will be reviewed at the meeting on Tue July 30 at 8 am ET. WebEx info is below.
To be discussed whether we can remove the noAuth option for HTTPS authentication.
Cloud RAN Solution Definition and Architecture
Mobile Networks, Nokia
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.