Subject: [Netconf] FW: DISCUSS: netconf charter

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Aug 2010 09:59:20 +0200

Please address the issue raised by Russ in his DISCUSS. 

My take is that authenticating users with an identity based ACM is not
precluded by the charter, and it is the subset of NETCONF operations and
content which is to be pre-configured by the operator. The wording
however may not be clear if Russ got confused by the text.

Please answer timely, as the IESG telechat is scheduled for tomorrow at
11:30AM ET, and the WG chairs (who are on vacation now) wanted to have
the charter approved in the meeting. 

Thanks and Regards,

Dan

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 1:21 AM
To: Romascanu, Dan (Dan)
Cc: IESG
Subject: DISCUSS: netconf charter

Item 3 in the charter talks about access control based on the identity
of particular users that are pre-configured by the opertor.  Some form
of authenitcation is needed to work ahnd-in-hand with an identity-based
access control mechanism.  Please add aunthenication to the discussion.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Aug 2010 11:26:22 +0200

> the charter approved in the meeting. 

s/particular/authenticated/

/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: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 25 Aug 2010 17:32:29 +0200

Hi All,

nice to hear that the group is working even when the chairs 
are on vacation ;)

I would like to propose to change the first paragraph in point 3
(or any modified version which Russ is willing to accept)
Netconf Access Control Model (NACM) Requirements and Solution.

OLD:
      There is a need for standard mechanisms to restrict
      NETCONF protocol access for particular users to a pre-
      configured (by operator) subset of all available NETCONF
      operations and content.

NEW:
      There is a need for standard mechanisms to restrict
      NETCONF protocol access for authenticated users to a pre-
      configured (by operator) subset of all available NETCONF
      operations and content. For this purpose authentication 
      methods for use with the NETCONF protocol will be specified 
      to work hand-in-hand with the identity-based access control 
      mechanism.

Cheers,
Mehmet

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Juergen Schoenwaelder
> Sent: Wednesday, August 25, 2010 11:26 AM
> To: Romascanu, Dan (Dan)
> Cc: netconf
> Subject: Re: [Netconf] FW: DISCUSS: netconf charter
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Aug 2010 18:02:05 +0200

>       to work hand-in-hand with the identity-based access control 

So what is this "identity-based" access control thing then? And
as far as I understand, we are rechartering to do access control
work, not authentication work. I guess I do not understand why
the second sentence is useful.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Aug 2010 18:14:15 +0200

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, August 25, 2010 7:02 PM
> To: Ersue, Mehmet (NSN - DE/Munich)
> Cc: Romascanu, Dan (Dan); netconf; ext Bert Wijnen (IETF)
> > nice to hear that the group is working even when the chairs are on 
> > vacation ;)
> > 
> > I would like to propose to change the first paragraph in 
> point 3 (or 
> > any modified version which Russ is willing to accept) 
> Netconf Access 
> > Control Model (NACM) Requirements and Solution.
> > 
> > OLD:
> So what is this "identity-based" access control thing then? 
> And as far as I understand, we are rechartering to do access 
> control work, not authentication work. I guess I do not 
> understand why the second sentence is useful.
> 
> /js
> 

My understanding is that if the network has a mechanism to authenticate
users access, the access mechanisms protocols to be defined here will
need to work 'hand-in-hand' with it. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Aug 2010 23:52:13 +0200

> need to work 'hand-in-hand' with it. 

I still do not see why the new sentence is needed nor do I have a clue
what work 'hand-in-hand' means. Those who argue for the addition of
this sentence should explain it better. I maintain the position that
we are not rechartering to do authentication work. But this is what
the new sentence says.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 25 Aug 2010 15:59:27 -0700

>>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> I still do not see why the new sentence is needed nor do I have a clue
JS> what work 'hand-in-hand' means. Those who argue for the addition of
JS> this sentence should explain it better. I maintain the position that
JS> we are not rechartering to do authentication work. But this is what
JS> the new sentence says.

Authentication and authorization must play well together.  Hand-in-hand
to me does make sense because at some point you have to deal with
user-naming and privileges based on delivery methods, which hasn't been
done yet within netconf.  IE, you may want to treat "juergen"
differently over telnet than "juergen" over ssh.  Possibly because of
the security differences or possibly because they're actually
authenticating via two different databases.

The WG has yet to make the decision if something like the
vacmSecurityToGroupTable is needed for netconf, which does include at
least some information about the authentication method (in the SNMP case,
just the model, but it's not "zero" knowledge).

But, certainly one choice is to have "juergen" always be "juergen"
according to access control because we don't want to care about database
incompatibilities between two different distinct authentication
mechanisms.  That, to me, is sort of what the text hints at, though I
have no idea if the original author intended me to interpret it this way.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Aug 2010 09:31:34 +0200

> have no idea if the original author intended me to interpret it this way.

Assuming for a moment that this interpretation is what the orignal
author intended and that there is a specific reason to have this
specific requirement hard coded in the charter, then I would still
appreciate a more direct wording, e.g.:

  The access control mechanism must be able to distinguish users
  authenticated in different authentication realms.

I am just trying to make sure that the WG understands the charter text
so that we avoid any debates about what the charter means later on.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Aug 2010 11:33:29 +0200

Unfortunately, what I am getting from these discussions is that the WG
did not reach a consensus on these issues. Despite the original request
of the chairs (who are both on vacation) the charter cannot be approved
today. I will ask to be sent for external review, so that the WG can
debate and agree in the next two weeks on the exact scope and words in
the charter. 

Dan

> Sent: Thursday, August 26, 2010 10:32 AM
> To: Wes Hardaker
> Cc: Romascanu, Dan (Dan); netconf
> > >>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen 
> Schoenwaelder <[email-masked]> said:
> > 
> > JS> I still do not see why the new sentence is needed nor 
> do I have a 
> > JS> clue what work 'hand-in-hand' means. Those who argue for the 
> > JS> addition of this sentence should explain it better. I 
> maintain the 
> > JS> position that we are not rechartering to do 
> authentication work. 
> > JS> But this is what the new sentence says.
> > 
> > Authentication and authorization must play well together.  
> > Hand-in-hand to me does make sense because at some point 
> you have to 
> > deal with user-naming and privileges based on delivery 
> methods, which 
> > hasn't been done yet within netconf.  IE, you may want to 
> treat "juergen"
> > least some information about the authentication method (in the SNMP 
> > case, just the model, but it's not "zero" knowledge).
> > 
> > according to access control because we don't want to care about 
> > database incompatibilities between two different distinct 
> > authentication mechanisms.  That, to me, is sort of what the text 
> > hints at, though I have no idea if the original author 
> intended me to interpret it this way.
> 
> Assuming for a moment that this interpretation is what the 
> orignal author intended and that there is a specific reason 
> to have this specific requirement hard coded in the charter, 
> then I would still appreciate a more direct wording, e.g.:
> 
> I am just trying to make sure that the WG understands the 
> charter text so that we avoid any debates about what the 
> charter means later on.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Aug 2010 11:47:07 +0200

> debate and agree in the next two weeks on the exact scope and words in

It seems it is not clear what the issue is. Perhaps you can clarify
during the discussion today and ask Russ in particular whether

is already resolving his comment. Otherwise, the WG needs a clearer
description from the IESG or Russ what the issue is. Without that, the
WG will just not know how to resolve this comment because we do not
understand what it means.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Aug 2010 12:01:34 +0200

> Sent: Thursday, August 26, 2010 12:47 PM
> To: Romascanu, Dan (Dan)
> Cc: Wes Hardaker; netconf
> > did not reach a consensus on these issues. Despite the original 
> > request of the chairs (who are both on vacation) the 
> charter cannot be 
> > approved today. I will ask to be sent for external review, 
> so that the 
> > WG can debate and agree in the next two weeks on the exact 
> scope and 
> > words in the charter.
> 
> It seems it is not clear what the issue is. Perhaps you can 
> clarify during the discussion today and ask Russ in particular whether
> 
> is already resolving his comment. Otherwise, the WG needs a 
> clearer description from the IESG or Russ what the issue is. 
> Without that, the WG will just not know how to resolve this 
> comment because we do not understand what it means.
> 
> /js
> 

OK.

Dan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Aug 2010 04:46:42 -0700

> authenticating via two different databases.

The intent of the current charter text was that NETCONF NACM will
authorize access for subsets of the entire conceptual content-store,
for a user which has already been authenticated.

> just the model, but it's not "zero" knowledge).

We standardize what is common, and what has WG consensus.
The YANG augment-stmt is there for a reason.  Vendors can
always add additional functionality, which in turn,
can be standardized in the future.

> have no idea if the original author intended me to interpret it this way.

Or we can leave this as am implementation detail like we decided at the
last IETF.  Operators will configure their systems correctly, for their
particular environment.  There may not be a 1-name-fits-all solution,
so we should not gate success or failure on solving this non-NETCONF-specific
problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Aug 2010 15:00:16 +0200

On Thu, Aug 26, 2010 at 01:46:42PM +0200, Andy Bierman wrote:

[...]
 
> so we should not gate success or failure on solving this non-NETCONF-specific

Andy,

the ISMS WG has gone through all this and the result is that it is
configurable whether you want to distinguish ssh:foo from tls:foo or
not. So the decision rests with the operator.

I think it would be good to provide a similar configuration option in
NETCONF land and I would not mind if this would be spelled out as a
requirements that the WG is to document as part of the solution
document.

That said, only the IESG knows whether this is so important that it
needs to be required in the charter - and this is what this thread is
about. Perhaps they were even hinting at something totally different.
I hope we will know by the end of the day.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Aug 2010 15:02:36 +0200 (CEST)

> requirements that the WG is to document as part of the solution

+1

/martin

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Aug 2010 15:08:50 +0200

In the latest news - Russ found the one word change suggested by Juergen
as acceptable. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Thursday, August 26, 2010 4:00 PM
> To: Andy Bierman
> Cc: netconf
> > Or we can leave this as am implementation detail like we decided at 
> > the last IETF.  Operators will configure their systems 
> correctly, for 
> > their particular environment.  There may not be a 1-name-fits-all 
> > solution, so we should not gate success or failure on solving this 
> > non-NETCONF-specific problem.
> 
> Andy,
> 
> the ISMS WG has gone through all this and the result is that 
> it is configurable whether you want to distinguish ssh:foo 
> from tls:foo or not. So the decision rests with the operator.
> 
> I think it would be good to provide a similar configuration 
> option in NETCONF land and I would not mind if this would be 
> spelled out as a requirements that the WG is to document as 
> part of the solution document.
> 
> That said, only the IESG knows whether this is so important 
> that it needs to be required in the charter - and this is 
> what this thread is about. Perhaps they were even hinting at 
> something totally different.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 26 Aug 2010 06:40:41 -0700

>>>>> On Thu, 26 Aug 2010 04:46:42 -0700, Andy Bierman <[email-masked]> said:

AB> The intent of the current charter text was that NETCONF NACM will
AB> authorize access for subsets of the entire conceptual content-store,
AB> for a user which has already been authenticated.

Andy,

FYI I think we're in agreement.  The only question left is "are you
going to define what a user is?" since that hasn't been done yet (and
you'll be make decisions about it).  Not standardizing that and letting
it be implementation specific, as you said, is certainly an option.

---

From: Mark Scott <[email-masked]>
Date: Thu, 26 Aug 2010 12:29:37 -0400

Juergen,

+1 more for a configuration option in NETCONF.

On assumption we want to reuse ISMS approach can you direct me to those specific requirements?  (e.g. is this configurable per user/principal? per group? per transport? per server?)

I had a quick look through the USM and per-transport docs but couldn't locate the specifics.

thank you,
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: August-26-10 9:03 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] FW: DISCUSS: netconf charter

+1

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 26 Aug 2010 19:18:27 +0200

On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote:
 
> On assumption we want to reuse ISMS approach can you direct me to
> those specific requirements?  (e.g. is this configurable per
> user/principal? per group? per transport? per server?)
>

The VACM [RFC3415] maps a (securityModel, securityName) tuple it into
a group. This means for the security models USM, CSM, and TSM, the
tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different
groups (but they can also map to the same group of course).

For secure transports such as TLS or SSH, the Transport Security Model
(TSM) [RFC5591] provides a prefixing mechanism where security names of
a given secure transport may be prefixed by the TSM, that is VACM will
end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via
ssh or tls. This prefixing can be turned off so that that both tuples
become (tsm, joe), regardless which transport joe is using.

The configuration choice is rather coarse grained - you either get the
prefixes for all secure transports or none of them. Hence, if it is
necessary to distinguish joe coming in over different transports, you
have to enable the prefixing and that might lead to additional VACM
rules to achieve the proper mapping into VACM groups.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Aug 2010 22:44:54 -0700

> rules to achieve the proper mapping into VACM groups.

IMO, this is a slippery slope.  We are better off keeping
the access control model as simple as possible, not as configurable
and fancy as possible.  That's how VACM got out of control.
That's how lots of complicated SMIv2 MIB modules got out of control.

Is this sort of what you are talking about? -- in concrete YANG terms:

Add to nacm.yang somewhere:

  import ietf-netconf-monitoring { prefix nmon; }

  list transport-user-to-group {
     description
       "List of mapping entries.  Each entry conceptually assigns a particular
        NETCONF transport type and a user identity tuple to a NACM group.
        The server will process this list in order, until there are no
        more entries, or until a transport type and user identity match
        the current NETCONF request being processed by the server.";

     key "transport-ref user-identity";
     ordered-by user;

     leaf transport-ref {
        description
           "Identifies the NETCONF transport for this entry.
            The special string '*' indicates that this entry is associated
            with all supported NETCONF transport mappings.";
        type union {
          type string { pattern "\*"; }
          type identityref { base nmon:transport; }
        }
     }

     leaf user-identity {
        description
          "Identifies the user/principal associated with this entry.";
          type union {
             // TBD: need to define constrained list of user identity types
             // (strings w/ patterns?)
             type string { pattern "...."; }
             type string { pattern "...."; }
             type string { length "1..max"; }
          }
     }

     leaf group-name {
        description
          "The group assigned to this transport/user-identity mapping.";
        mandatory true;
        type leafref {
           path /nacm/groups/group/name;
           require-instance false;
        }
     }
  }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Aug 2010 08:56:45 +0200

>From those configs I have seen, I believe that the security name to
group name mapping is the most used part of VACM. People really get
scared when they look at view tree family masks.

- I believe we need a user name to group mapping to support a role based
  access control model.

- I believe such a user name to group mapping should support the
  RADIUS Management-Policy-Id attribute [RFC5607] so that the user
  name to group mapping can be maintained on a RADIUS server.

- If we seriously support different authentication realms, we might
  provide a mechanism to deal with user name conflicts; a suitable
  default makes this a no brainer for most people.

  However, given the discussion we had recently on the SSH transport,
  we might choose to simply mark this as implementation dependent
  since there is already an implementation dependent mapping from the
  SSH authenticated user name to the system's account name; so
  colliding user names in different authentication realms could
  potentially be resolved at this 'layer'.

Perhaps it is time to note down requirements.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Aug 2010 09:26:04 -0700

> Perhaps it is time to note down requirements.

Are you volunteering?
Sometimes in this WG (and others) it is very easy for people to
rattle of a bunch of nice-to-have requirements for a charter item,
and then disappear from the WG.

Multiple people have to do the work:
   - agree on the concepts
   - agree on the details
   - write the text
   - review the text
   - repeat over many revisions of the draft(s).

We spend an awful amount of time and energy hammering out nice-to-have,
optional-to-implement, bells and whistles.  IMO, we need to rapidly deploy
a must-have framework, and get domain-specific WGs (and vendors) to
fill it in with real config knobs.  NACM should not block other work,
such as interfaces and system modules either.

Since we can't make tough decisions, we throw every bell and every
hood ornament we can think of into every module.  This may be more
satisfying to the WG at the time, but I am not so sure it helps
deployment and interoperability to spend so much time on optional features.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 27 Aug 2010 20:15:43 +0200

> deployment and interoperability to spend so much time on optional features.

If your rant is targeting me (which I assume since I took part in the
drafting of the charter text), then let me tell you that I strongly
disagree with your statement.

That said, it would be nice to know what you think the "nice-to-have
requirements for a charter item" are. Actually, I do not understand
the your charter rant at all; the ACM stuff is pretty much the text
your had on your slide in Maastricht.

/js (whose motivation to help just dropped significantly)

---

From: Phil Shafer <[email-masked]>
Date: Fri, 27 Aug 2010 15:58:12 -0400

Andy Bierman writes:
>fill it in with real config knobs.

So we're after "quick and dirty"?  Or is "rapidly" supposed to be
read in the context of IETF timelines?

>NACM should not block other work,

NACM should be orthogonal to other work.

>deployment and interoperability to spend so much time on optional features.

I completely disagree.  YANG gives many tools to handle optional
parts (augment, features, etc), so it's easier to say "we want to
make this common in our model but not everyone needs to do it" or
"this part is left for future work".  But part of creating useful
models is understanding how and where folks will need to extend and
adapt it, so having this list of "hood ornaments" has a value to
the modeler.  If you want to support TACACS, RADIUS, and LDAP-based
authentication, you need to understand how these are used in the
real world.  Leaving it for the TACACS modeler to come in later and
retrofit their model into your framework can be disasterous.

In addition, we have found that many times what we think are
areas of proprietary behaviour are, in fact, rather common
among the various implementations, so developing the list of
"bells" may enhance the WG's understanding of what exactly
they are modeling.

Thanks,
 Phil (who is definitely not volunteering)

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Aug 2010 13:35:33 -0700

> your had on your slide in Maastricht.

The rant is not directed at you or your charter text.
Are you offering to write a draft or provide text for NACM?
Does the WG even agree to these new requirements?

NMS developers are still hesitant to use optional-to-implement server APIs,
just like in SNMP days.  Yet we are very quick to use lots of
optional-to-implement definitions in the YANG data models and protocols.

I think this level of effort should only be spent on mandatory-to-implement YANG content.
We would get something done a lot faster, and time is a factor we should not ignore.
IMO, all the extra time could be eliminated by using optional-to-implement as
a last resort, instead of the first choice.  We will agree on much less, and
the YANG modules will be smaller. The NMS developers will also be more likely to use the
finished product.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 28 Aug 2010 00:13:39 +0200

> Does the WG even agree to these new requirements?

I have been trying to be constructive but I obviously failed
badly. And in case you forgot, the chairs have the task to 
determine concensus in the IETF.

/js (who prefers to go to sleep instead of continuing this thread)