Re: xNF Security Requirements for HTTPS


Pawel Baniewski (Nokia)
 

Hello,

  1. Certificate Validation is described in RFC 5280, chapter 6.
  2.  
    1. No need to add info about HTTPS tunnel as only HTTPS is planned to be supported
    2. xNF’s certificate is required only for mutual TLS (mTLS)
  3. No, because N-3 describes client side (xNF) logic, while O-4 describes server side processing

 

 

Additionally:

 

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

The same in Spring Boot - https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/web/server/Ssl.ClientAuth.html

The same in Tomcat - https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_SSLHostConfig

 

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.

 

 

Regards

 

Pawel Baniewski

____________________________________________

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@...>
Cc: onap-seccom@...
Subject: Re: [Onap-seccom] xNF Security Requirements for HTTPS

 

Hello,

 

Many thnaks for this new version of the document.

 

Here are a few remarks :

  • what are the criteria to determine whether a certificate is valid or not?
  • for the alternative O-3:
    • it should reminded that basic authentication credentials are sent within an HTTPS tunnel.
    • how is established this tunnel between xNF and DCAE if the xNF does not have a certificate?
  • isn't there a contradiction between N-3 and O-4:
    • N-3: If the xNF is using Certificate Authentication, then the xNF MUST NOT use Basic Authentication for authenticating HTTPS connections to the DCAE Event Listener.
      Note:  xNF fallback from certificate authentication to basic authentication is not allowed.
    • O-4: If auth.method = certBasicAuth, DCAE VES Event Listener MUST authenticate the HTTPS client as follows:

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.

 

Best regards

Natacha

 

==

 

 

 


De : Horn, Linda (Nokia - US/Murray Hill) [linda.horn@...]
Envoyé : mercredi 24 juillet 2019 14:06
À : ZWARICO, AMY;
onap-seccom@...; PAWLAK Pawel O-PL; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; MACH Natacha TGI/OLS; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'; Hillis, Marge (Nokia - US); Kukulski, Marek (Nokia - PL/Wroclaw); Murgoski, Zlatko (Nokia - PL/Wroclaw)
Objet : RE: xNF Security Requirements for HTTPS

All,

 

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.

 

Thank you!

 

Linda
-----------------------------------------------------------------------------------
Linda S. Horn, DMTS

Cloud RAN Solution Definition and Architecture

Mobile Networks, Nokia

Phone:  +1-908-679-6580

 

-----Original Appointment-----
From: ZWARICO, AMY <
az9121@...>
Sent: Tuesday, July 23, 2019 11:46 AM
To: ZWARICO, AMY;
onap-seccom@...; Horn, Linda (Nokia - US/Murray Hill); 'Pawlak Paweł 3 - Korpo'; 'Krzysztof Opasiak'; CLOSE, PIERRE; THORPE, HENRY E; 'Michela Bevilacqua'; 'Zygmunt Lozinski'; HANSEN, TONY L; GATHMAN, JONATHAN C; 'natacha.mach@...'; 'Harald.Fuchs@...'; 'meng.zhaoxing1@...'
Subject: xNF Security Requirements for HTTPS
When: Tuesday, July 30, 2019 7:00 AM-8:00 AM (UTC-06:00) Central Time (US & Canada).
Where: webex

 

 
-- Do not delete or change any of the following text. --  
 
 
Join Webex meeting  
Meeting number (access code): 732 539 754
Meeting password: tpdmsy4$ 
 

Join from a video system or application
Dial 732539754@... 
You can also dial 173.243.2.68 and enter your meeting number.  
 
Join by phone 
Tap to call in from a mobile device (attendees only) 
1-844-517-1415 United States Toll Free 
1-618-230-6039 United States Toll 
Global call-in numbers  |  Toll-free calling restrictions  
 
 
Accessibility and Assistive Technologies  
Select this job aid for tips and guides to make Webex Meetings accessible to persons with disabilities who may rely on assistive technologies.
 
 
Can't join the meeting?
 
If you are a host, go here to view host information.

IMPORTANT NOTICE: Please note that this Webex service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

 

 

_________________________________________________________________________________________________________________________
 
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.
Thank you.

Join onap-seccom@lists.onap.org to automatically receive all group messages.