Subject: [netconf] UserId for authentication in https-notif

From: Balázs Lengyel <[email-masked]>
Date: Fri, 11 Oct 2019 09:43:38 +0000

Hello,

What userId will be used to perform access control on outgoing notifications
transferred via https?

regards Balazs

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909              email: [email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 11 Oct 2019 12:15:01 -0700

Hi Balasz,

> On Oct 11, 2019, at 2:43 AM, Balázs Lengyel <balazs.lengyel=[email-masked]> wrote:
> 
> Hello,
> What userId will be used to perform access control on outgoing notifications transferred via https?

This was also discussed in an earlier thread, when Martin brought up the broader question of whether we are planning on using PUT or POST, to which URI, and authorization. 

Kent suggested that user-id will be part of http-params supported by the http client/server draft, and will be the user-id used by NACM. The example in the draft will be augmented thus:

<receivers
     xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">
     <receiver>
       <name>foo</name>
       <tcp-params>
         <remote-address>my-receiver.my-domain.com <http://my-receiver.my-domain.com/></remote-address>
         <remote-port>443</remote-port>
       </tcp-params>
       <tls-params>
         <server-authentication>
           <ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
           <server-certs>explicitly-trusted-server-certs</server-certs>
         </server-authentication>
       </tls-params>
       <http-params>
         <client-identity>
           <basic>
             <user-id>my-name</user-id>
             <password>my-passsord</password>
           </basic>
        </client-identity>
        <path>/some/path</path>
       <http-params>
     </receiver>
 </receivers>

Cheers.

>  
> regards Balazs
>  
> -- 
> Balazs Lengyel                    Senior Specialist                       Ericsson Hungary Ltd. 
> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]>
>  
> _______________________________________________
> netconf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[email-masked]

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 11 Oct 2019 19:42:15 +0000

>              <password>my-passsord</password>

Are you saying that the idea is to configure a user id on the local RC
server pushing notifications to a remote receiver, i.e., the user id
is by config related to the certs used to protect the communication
channel?

Note that RFC 7589 (NC over TLS) suggests an algorithm mapping
certificates to user names. RFC 8040 (RC) also refers to this
algorithm for obtaining the client identity. [Is this algorithm
actually taken care of in the configuration IDs?]

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 11 Oct 2019 22:14:28 +0000

What does Syslog configuration and processing like?  - it seems that this effort could (should?) mimic Syslog...

Note: the client-credentials (client-cert or basic auth) used to log into the remote system (i.e., the receiver) reflect a user that exists on that remote system and hence cannot be used as a local user id.

FWIW, this is new protocol (i.e., not NETCONF or RESTCONF) such that the concept of NACM may not necessarily apply.

Kent // contributor

> On Oct 11, 2019, at 5:43 AM, Balázs Lengyel <balazs.lengyel=[email-masked]> wrote:
> 
> Hello,

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Fri, 11 Oct 2019 23:00:32 +0000

> FWIW, this is new protocol (i.e., not NETCONF or RESTCONF) such that the concept of NACM may not necessarily apply.

For deployments using RC/NC implementations that support NACM, a
backdoor protocol side-stepping NACM may not be a desirable feature.

/js