Subject: [netconf] Identity of an OAM user behind ONAP or NMS

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 May 2020 09:41:18 +0000

Hello,

We have systems where the Netconf client is actually a bigger management
system like ONAP or a Network Management system (NMS). These systems have
their own user management and access control with potentially many dozens of
OAM users that can handle thousands of nodes. We do not want create and
maintain these dozens of users in thousands of nodes. The idea is to have a
single NMS user that has superuser rights and leave the access control to
the NMS.

However, this presents a problem: The Netconf server does not have the
effective user identity who ordered the action in NMS. Still it would be
good to include this effective userId in the audit trail logs on the Netconf
server.

IS there some standard way to send such a second effective-user-id to the
Netconf server? Would there be interest for defining such a mechanism?

Regards Balazs

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

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

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 6 May 2020 12:12:15 +0200

Balász,

> Hello,
> We have systems where the Netconf client is actually a bigger management system like ONAP or a Network Management system (NMS). These systems have their own user management and access control with potentially many dozens of OAM users that can handle thousands of nodes. We do not want create and maintain these dozens of users in thousands of nodes. The idea is to have a single NMS user that has superuser rights and leave the access control to the NMS.
> However, this presents a problem: The Netconf server does not have the effective user identity who ordered the action in NMS. Still it would be good to include this effective userId in the audit trail logs on the Netconf server.
>  
> IS there some standard way to send such a second effective-user-id to the Netconf server? Would there be interest for defining such a mechanism?

This is one of the areas where operators' choices vary greatly, in my experience. The most common basic approach, as far as I have seen, is to actually use the real user id towards devices. If nothing else, so for auditing purposes. In order not to have to store user credentials on thousands of nodes, which as you say would be a problem, remote authentication protocols like Radius, LDAP or TACACS+ are configured on the nodes.

Best Regards,
/jan

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 May 2020 15:38:26 +0000

Hi Balazs,

> We have systems where the Netconf client is actually a bigger management system like ONAP or a Network Management system (NMS). These systems have their own user management and access control with…

This is what I’ve seen mostly: assuming NMS is the master, all AAA happens there.

> However, this presents a problem: The Netconf server does not have the effective user identity who ordered the action in NMS.

At first I thought you were going to say this is an issue because the server can’t implement access control, but it seems it’s more to do with attributing the userid in the audit trail logs...

> Still it would be good to include this effective userId in the audit trail logs on the Netconf server.

Assuming the only goal is to correlate the server-generated audit logs, techniques I’ve seen used include:

1) temporal correlation:  i.e., assume the audit logs generated by a server in some window of time immediately after a configuration update are related to that update event, and hence attributed to the NMS user.  PROs: no device modification required.  CONs: assumes non-overlapping and somewhat infrequent updates.

2) opaque correlation: if the device supports either a) accepting an opaque value in the request or b) generating an UID that it  returns in the RPC-reply that, in other case, it outputs in downstream audit logs.  This value can be used by the NMS to correlate audit-logs to the NMS-update, from which the NMS-user can be determined.  PROs: deterministic.  CONs: requires device support.

3) use remote-auth protocols, mentioned by Jan Lindblad.   PROs: also supports out-of-band updates.  CONs: requires greater network infrastructure access from all the servers.

> IS there some standard way to send such a second effective-user-id to the Netconf server? Would there be interest for defining such a mechanism?

If solely interested in audit-logs generated when <intended> is updated, then it is effectively always a synchronous update. But from the opstate-reqs days, it would be good to know when an update is *applied* (see requirement 2B in draft-ietf-netmod-opstate-reqs-04 <https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04>).  Of course, this consideration is additionally complex in cases, e.g., when a line-card is plugged in.

Nonetheless, for cases where the device knows that the RPC will be processed asynchronously, it might be good to return in the RPC-reply a handle (UID) that can be used in subsequent requests and/or returned in audit-logs for offline correlation.  An I-D along these lines might be generally useful.

Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 May 2020 08:58:17 -0700

On Wed, May 6, 2020 at 8:38 AM Kent Watsen <[email-masked]> wrote:

> their own user management and access control with potentially many dozens
> of OAM users that can handle thousands of nodes. We do not want create and
> effective user identity who ordered the action in NMS.
>
>
> At first I thought you were going to say this is an issue because the
> server can’t implement access control, but it seems it’s more to do with
> attributing the userid in the audit trail logs...
>
>
> 1) temporal correlation:  i.e., assume the audit logs generated by a
> server in some window of time immediately after a configuration update are
> related to that update event, and hence attributed to the NMS user.  PROs:
> no device modification required.  CONs: assumes non-overlapping and
> somewhat infrequent updates.
>
> 2) opaque correlation: if the device supports either a) accepting an
> opaque value in the request or b) generating an UID that it  returns in the
> RPC-reply that, in other case, it outputs in downstream audit logs.  This
> value can be used by the NMS to correlate audit-logs to the NMS-update,
> from which the NMS-user can be determined.  PROs: deterministic.  CONs:
> requires device support.
>
> 3) use remote-auth protocols, mentioned by Jan Lindblad.   PROs: also
> supports out-of-band updates.  CONs: requires greater network
> infrastructure access from all the servers.
>
>
> If solely interested in audit-logs generated when <intended> is updated,
> then it is effectively always a synchronous update. But from the
> opstate-reqs days, it would be good to know when an update is *applied*
> (see requirement 2B in draft-ietf-netmod-opstate-reqs-04
> <https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04>).  Of
> course, this consideration is additionally complex in cases, e.g., when a
> line-card is plugged in.
>
> Nonetheless, for cases where the device knows that the RPC will be
> processed asynchronously, it might be good to return in the RPC-reply a
> handle (UID) that can be used in subsequent requests and/or returned in
> audit-logs for offline correlation.  An I-D along these lines might be
> generally useful.
>
>
There is another (low-tech) solution possible -- add a "comment" leaf to
the commit and edit-config operations
and add the comment to the audit-log entry for the datastore update.

> Kent // contributor

Andy

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>