Subject: [Netconf] NACM draft

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Oct 2010 09:08:46 -0700

Hi,

There have not been any comments on this draft:
http://www.ietf.org/id/draft-ietf-netconf-access-control-00.txt

Juergen made a comment that the authentication objects should be removed.
Nobody else commented on that, and so they were not removed from -00.

There is no reason to publish a -01 draft since there has been no progress on this document in 4 months.

That means the draft is either ready for WGLC or the WG is ready to shut down, since 4741bis and 4742bis
are essentially done.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 25 Oct 2010 22:07:46 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Netconf" <[email-masked]>
> Sent: Wednesday, October 20, 2010 9:08 AM
> Subject: [Netconf] NACM draft
...
> Nobody else commented on that, and so they were not removed from -00.

FWIW, I agree with Juergen that the "authentication objects" should be removed.
In particular, if RADIUS is required to provide "group" mappings, then the
material on user/group mappings can be greatly simplified, as well as the
"superuser" stuff, which reduces to an all-powerful, potentially pre-installed
group, much like the appendix material in VACM).  It should also spell out
what happens when RADIUS fails to provide a group mapping, but has
authenticated the user.

I think any references to RADIUS should clearly identify the RADIUS attributes
involved.  If there is any possibility that this MAY be used with DIAMETER, that
should be spelled out, too.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Oct 2010 09:38:46 +0200 (CEST)

Hi,

> FWIW, I agree with Juergen that the "authentication objects" should be removed.

Do you think authentication should be split into a separate document,
or do you think that the solution should not cover authentication at
all?  Why?

It seems the term "access control" means different things to different
people.  Some people thinks it is just authorization, some think it is
authentication + authorization, and some even include audit
(e.g. http://en.wikipedia.org/wiki/Access_control#Computer_security)

Personally, I think we need both authentication and authorization.  If
it is done in one or two documents is not very important, although I
perfer one document at this stage.

> In particular, if RADIUS is required to provide "group" mappings

Currently RADIUS support is not required, and if RADIUS is supported,
it is not required to support the "group" mapping.

> , then the

Ok.  The idea is that group names are accumulative, i.e. the list of
local groups are added to the result from RADIUS.

> involved.

Don't you think that the currect draft does that?

> If there is any possibility that this MAY be used with DIAMETER,
> that

Ok.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Oct 2010 11:19:50 -0700

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, October 26, 2010 12:38 AM
> Subject: Re: [Netconf] NACM draft
...
> or do you think that the solution should not cover authentication at

It's not meaningful to talk about access control without reference to
the authentication of the entities.  (Not just the party being given access
permission, but also the authentication of the party providing the
information.)

In my opinion, if RADIUS support is to be optional, then authentication
details would belong in a (mercifully brief) separate document, in order
to maintain modularity.  (If modularity is a goal - I'm not convinced that
it really is a goal of netconf.)

Something should identify what the mandatory-to-implement authentication
mechanism is.  Access control without a mandatory-to-implement authentication
mechanism seems a cruel joke from an interoperability perspective.

> (e.g. http://en.wikipedia.org/wiki/Access_control#Computer_security)

Also, folks mean different things by "authorization".  Here, as in isms,
the policies for authorizing use of the communication channel are
separated from the policies for authorizing access to specific bits
of information.

If RADIUS handles the authentication and provides the group mapping,
the only reason the netconf machinery would need the user name would
be to support a (future, probably optional) audit funtion.

> perfer one document at this stage.

FWIW, I don't care a great deal about the question, though I think
two documents would give better future-proofing if mechanisms
other than RADIUS are to be supported in the future, or if the mandatory-to
implement mechanism takes more than a paragraph or two to specify.
On the other hand, if RADIUS support is mandatory-to-implement,
then it would be OK to do it in a single document.

> local groups are added to the result from RADIUS.

In that case, you'll need to work through how you want it to work when the
RADIUS-provided mapping is different from one in the configuration.  We
already went through that exercise in isms.

> Don't you think that the currect draft does that?

Not consistently.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Oct 2010 20:22:15 +0200

> it really is a goal of netconf.)

I believe in modularity. As fas as I understand the mandatory to
implement transport, authentication is handled by the SSH layer and
not by NETCONF directly. In other words, there should be a YANG module
to configure SSH and the problem is solved.

And for the other NETCONF transports, we should realize that their
ways of authenticating a principal is sometimes radically different
from SSH. If we want to give up modularity, the first step would be to
declare those transports Historic.

/js

-- 
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: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Oct 2010 22:16:44 +0200 (CEST)

Hi,

> it really is a goal of netconf.)

I do think modularity is a goal.  But it doesn't necessarily mean that
all different components must be defined in separate documents.

Are you saying that any mandatory authentication mechanism should be
defined in the NACM document?

> > Don't you think that the currect draft does that?

Can you be specific?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Oct 2010 22:25:13 +0200 (CEST)

> to configure SSH and the problem is solved.

But configuration of an SSH server in general is a much bigger task
than configuration of SSH on a typical networking device that can be
configured with NETCONF.

> from SSH.

Absolutely.  The draft tries to take this into account.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Oct 2010 14:23:59 -0700

Hi -

> Sent: Tuesday, October 26, 2010 1:16 PM
...
> Can you be specific?

The new I-D (October 25) addresses the issue.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 00:59:44 +0200

> than configuration of SSH on a typical networking device that can be

But I do at the end configure sshd on NETCONF servers I happen to
have.  So why not try to have a minimal SSH configuration model that
can be extended with more features? Does it match reality to have some
SSH config in a NETCONF access control model, some in an SNMP
transport model, and the rest elsewhere? How is an implementation
expected to resolve conflicts?

I am also concerned about /nacm/authentication/user - I consider local
accounts a system property, not specifically a NETCONF property. Is
this /nacm/authentication/user covering all accounts on a system or
only a proper subset that is allowed to be used by NETCONF?

On my system, RADIUS is also not really a property of NETCONF; it is
PAM that takes care of how a password is validated and whether it is
sent to a RADIUS server. In other words, sshd calls PAM and the PAM
config tells whether RADIUS is involved and if so, the PAM RADIUS
config tells how to talk to the right RADIUS server. We can pretend
all this is not happening. But then, what do we do if someone has to
configure a different protocol that authenticates in a similar way via
RADIUS? Are we expecting them to use or augment
/nacm/authentication/user? Or do they do their own little thing,
leaving it to surprises if things collide and fail in non-obvious
ways?

My proposal back in Maastricht was to remove the authentication
material from NACM so that this module can focus on the access control
decision and the document can move on according to schedule. The
notion of system accounts (= local users) and account authentication
can be taken up as part of a core system model in NETMOD.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Oct 2010 16:22:06 -0700

Hi,

It seems clear that the new authentication objects are controversial.
I had some concerns that the scope would expand too much, and it looks
like that could happen.  I don't think we signed up for modeling sshd.conf.

I could also see how a user that wanted to configure CLI access using NETCONF
scripts might be confused if the user table was in the NACM module.

If the authentication objects were moved to a separate draft, then
some complex procedures that Martin updated need to be undone.
That means if authorization is added in the future, the NACM RFC might
need to be updated as well.

Getting bogged down on complex optional-to-implement data model objects
is not something I have a lot of time for.  ;-)

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, October 26, 2010 4:00 PM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] NACM draft

/js

-- 
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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 08:44:04 +0200

> need to be updated as well.

I can't follow. Can you be precise?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Oct 2010 09:44:37 +0200 (CEST)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> have.

This is one deployment scenario, but there are also systems that use
embedded ssh stacks integrated with the NETCONF server.  Both
scenarios should be supported.

> So why not try to have a minimal SSH configuration model that
> transport model, and the rest elsewhere?

No, I agree.

> only a proper subset that is allowed to be used by NETCONF?

I agree it make sense to move this to /system, for example.  But at
the same time, I don't think we should do a model for configuration of
any user account.  There are many parameters to configure, and they
depend on the OS and services available.

> leaving it to surprises if things collide and fail in non-obvious

On most embedded system, even if PAM is used behind the scenes, it is
not obvious that the operator directly configures PAM from the CLI or
over NETCONF.

Ok.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 09:49:36 +0200

> not obvious that the operator directly configures PAM from the CLI or

True. The challenge of writing configuration models is to make them
flexible enough so that different systems can be supported. Getting
this right is hard. But lets at least try.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Oct 2010 09:54:42 +0200 (CEST)

Hi,

> some complex procedures that Martin updated need to be undone.

Yes.  The current NACM spec gives access to a session from a set of
group names.  If we move authentication, will the NACM spec leave it
as an implementation-specific matter how users are mapped to groups?
Or will we have a NETCONF-specific mapping from user names to groups?
(and a SNMP-specific mapping, and CLI-specifc mapping, etc).  If we
have such protocol specific mappings, does that mean that RADIUS, or
other mechanisms, cannot be used to do the mapping?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 27 Oct 2010 02:15:03 -0700

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, October 27, 2010 12:54 AM
...
...

Ignoring session authorization for the moment,
I think there are three interesting cases to consider:

  (a) the authentication mechanism is able to determine the group
        mapping (RADIUS)

  (b) the user/group mapping for a particular authentication mechanism
        will be configurable via netconf, but is peculiar to that mechanism.

  (c) the authentication mechanism does not not provide a mapping, but
       does provide a user name.

(a) by itself is trivial.
(c) could be handled in two ways - by a (1) user/group mapping "table"
      associated with the mechanism, or a (2) mechanism/user/group
      mapping table associated with netconf.  (1) seems simpler until
      one starts thinking about managing access control for this access
      control policy information.   (2) has the advantage of allowing
      a consistent, integrated discussion of of how conflicts between (a)
      and the configuration are to be handled.
(b) could get really ugly if the protocol used by the mechanism can also
      carry group mapping information, since the user/group conflict resolution policy
      would potentially be mechanism-specific.  Such flexibility would be
      a trap for the unwary, and would also require the most specification
      effort.

I think this could all be made to work with something like the following:
   - service interface to netconf provides mechanism identifer, authenticated
     user name, and optional group mapping provided by mechanism

   - netconf looks up (mechanism, user) tuple in its configured group mappings
      determines configured group, if any

   - if no group was provided by the service, and no group found in the mappings,
     then categorical DENY.

 - if group provided by service, and no group found in the mappings, use that group.

 - if group provided by mappings, and none provided by the service, use that group.

  - if group provided by service and group provided by mapping are the same,
    use that group, otherwise (if group provided by service and group provided by
    mapping are different) apply netconf's conflict resolution algorithm (whatever
    it might be)

But this is roughly how RADIUS/ VACM works.  However, I think the
conflict resolution part is potentially harder in netconf land, if we admit the
possibility that a conflict resolution process could potentially result in
operational state at odds with configuration data.  (In RADIUS/VACM,
configuration takes precedence over what the mechanism says, avoiding
the problem.)

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 11:14:31 +0200

On Wed, Oct 27, 2010 at 09:54:42AM +0200, Martin Bjorklund wrote:
 
> (and a SNMP-specific mapping, and CLI-specifc mapping, etc).

That is a good question to discuss. Perhaps the answer can be found by
looking what implementations commonly do.

> If we have such protocol specific mappings, does that mean that
> RADIUS, or other mechanisms, cannot be used to do the mapping?

For SNMP, there is an ID describing how RADIUS can influence the user
to group mapping. So I do not see why this "cannot" be done if there
are protocol specific user to group mappings.

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Oct 2010 08:15:44 -0400

Martin Bjorklund writes:
>I agree it make sense to move this to /system, for example.

FWIW: in JUNOS, we put local services under /system/services/
so netconf is under /system/services/netconf and ssh is under
/system/services/ssh.  These are protocols that are local to
the box, rather than part of the box's role in the network,
which are under /protocols/.

It would be _very_ nice if we had some sort of understanding (and
over-arching organization) for how we want ietf standards to mesh,
rather than just "wild west" style where everything ends up in the
root.

>But at

It seems you really need to decide if you are configuring NETCONF
users or users that might happen to use NETCONF.  My experience is
that most operators will want the latter.  IIRC one of the "wins"
for using ssh was reusing existing infrastructure (deployed ssh
keys) so this view of configuring NETCONF users would lose that.
Unless your model has a big boolean leaf that says "use-your-real-users".

>not obvious that the operator directly configures PAM from the CLI or

If the operator doesn't configure it, who does?  Or are you saying
this is sometimes hard coded and your model needs to reflect that
(via "feature")?

FWIW:  In JUNOS, this is done with the following config:

system {
    authentication-order [ radius password ];
    radius-server {
        10.1.2.3 secret "$9$SfPe87bs4Ui.X7s4"; ## SECRET-DATA
        10.1.3.2 secret "$9$GOimTn/t1EyfT/t"; ## SECRET-DATA
    }
}

Where "authentication-order" controls the order in which the
authentication methods are attempted (pam.conf) and the radius
servers are (in order) the servers used (radius.conf).

(In JUNOS we write this information to the standard UNIX files and
run the stock UNIX daemons and libraries) (which makes life so much
simpler).

s/radius/tacplus/ for TACACS+ support.

In a YANG-based model, this might look something like:

<system>
    <authentication-order>
        <radius/>
        <password/>
    </authentication-order>
    <radius-server>
        <name>10.1.2.3</name>
        <secret>$9$SfPe87bs4Ui.X7s4</secret?
    </radius-server>
    <radius-server>
        <name>10.1.3.2</name>
        <secret>$9$GOimTn/t1EyfT/t</secret>
    </radius-server>
</system>

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Oct 2010 15:25:12 +0200 (CEST)

> keys) so this view of configuring NETCONF users would lose that.

What is "this view"?  If we move the user authentication to /system,
we would configure users that might happen to use NETCONF.  So I think
we agree.

> If the operator doesn't configure it, who does?

There is one simple model which gets mapped by the implementation on
the device to PAM config files and whatnot.  This seems to be what you
are doing as well.  It is not possible to tune all PAM knobs in this
simple model.  In fact, the operator might not even know that PAM is
used in the implementation.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 27 Oct 2010 09:40:04 -0400

>we would configure users that might happen to use NETCONF.  So I think

Cool.

>used in the implementation.

Yup, since PAM is an internal-to-the-box software interface, the
user should remain blissfully ignorant of it.  But the model needs
to reflect the functionality that it offers, since this is driven
by operator needs.

Thanks,
 Phil