Subject: [Netconf] netconf server cert/psk mapping

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jul 2014 12:07:40 +0200

Hi,

these mappings have been turned into augmentations of the system data
model. I am not yet 100% convinced this is the way to go, at least it
looks strange to have the mapping in the SNMP specific part for SNMP
and kind of globally defined for NETCONF. I do not know how RESTCONF
is going to address this issue. Is there a requirement that the name
falling out of the mapping (e.g. extracted from the cert itself) must
match a valid /system/authentication/user/name or does this create a
completely orthogonal way of authenticating users to the system (note
that this is system scope, not service scope). I am not sure system
scope is the right thing here.

Nits:

 - ietf-x509-cert-to-name is defined in I-D.ietf-netconf-snmp-cfg and
   not in I-D.ietf-netconf-rfc5539bis.

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

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Jul 2014 02:11:08 +0000

Hi Juergen,

I think you're referring to
http://tools.ietf.org/html/draft-ietf-netconf-server-model-01#section-5

Defining it globally came about because of Radek's comments here:
http://www.ietf.org/mail-archive/web/netconf/current/msg08836.html

And the choice to use an augmentation made here:
http://www.ietf.org/mail-archive/web/netmod/current/msg09828.html

Does it still not seem right?

Thanks,
Kent

On 7/9/14, 6:07 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jul 2014 14:36:25 +0200

> http://tools.ietf.org/html/draft-ietf-netconf-server-model-01#section-5

Yes.
 
> http://www.ietf.org/mail-archive/web/netconf/current/msg08836.html

Yes, I have seen that exchange.

> Does it still not seem right?

Yes, I likely have issues with this. My understanding of the
/system/authentication/user list is that it essentially tells me
something about user accounts on a system and how to manage the
associated passwords and SSH keys with the goal to make typical SSH
access work. And typical SSH access maps the incoming connection into
a context of a local system user account. This makes sense since
access to remote system accounts was the prime reason for creating SSH
in the first place.

When we talk about other services, then the notion of a service
account is often detached from the notion of system accounts. Lets
take SNMP as an example: The SNMP users usually only exist within the
SNMP agent, they typically do not map to a local system user account.
The same is true for many HTTP based services. To configure say a
webdav share, you typically create a user with a password that purely
exists in the webdav implementation and does typically not map to a
local system user account.

The difference between these approaches is not only significant from
the implementation background but also from the point of the name
spaces. In typical implementations, my SNMP user name space is
distinct from my webdav user name space, which is again distinct from
my local system user account name space.

I guess one of the not clearly answered open questions is which model
NC over TLS (and RESTCONF over TLS) should follow - the 'user name
space is scoped to a service' model or the 'user name maps to a local
system user account' model.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Jul 2014 23:10:28 +0000

The augmentation is made to /system/authentication (not
/system/authentication/user).  The maps are currently to username strings,
with no assertion of them being related to the /system/authentication/user
accounts.  So this is a "service" account, as you put it, which seems
right to me.  Agreed?

That said, if they are service account mappings, specifically for the
NETCONF service, then we probably want it configured in
ietf-netconf-server, not ietf-system as it is now.  Agreed?

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jul 2014 11:44:03 +0200

> accounts.  So this is a "service" account, as you put it, which seems

no
 
> ietf-netconf-server, not ietf-system as it is now.  Agreed?

yes

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 17 Jul 2014 16:08:11 +0000

On 7/17/14, 5:44 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>No

No what?  - you don't think they are service accounts?  - please explain.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Jul 2014 20:53:47 +0200

> No what?  - you don't think they are service accounts?  - please explain.

No to 'service accounts are under /syste/authentication with no other
qualifier.

/js