Subject: [Isms] comments on draft-nelson-isms-extended-vacm-00

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 09:24:52 +0200

Hi,

here are a few comments (posted as a technical contributor) on the
RADIUS / VACM document:

A: How specific should the document refer to the TSM? Should we try to
   phrase things such that things still work in case we replace TSM
   with something else?

B: I suggest that we do not overwrite existing table entries.

C: The aging I think needs more work so that we can handle situations
   where user joe logs into an agent at t1 and a second time at t2 and
   then the first session ends at t3. The second session should not
   loose the group name mapping entry in this case. So implementations
   somehow need to do some reference counting.

D: I am not sure why the USM discussion in the security considerations
   section is needed.

E: Is there a need for a MIB module exposing an augmentation of the
   VACM table with session/timeout information? Such a table would
   allow a management application that is aware of this extension to
   detect where some name to group mapping entries are originating
   from. But on the other hand, we do not generally indicate where
   some config snippet is originating from in SNMP land...

Though we will have time to discuss things later today in the WG
meeting, I brought this to the list since not all contributors and in
particular the document editors make it to Stockholm.

/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: "Dave Nelson" <[email-masked]>
Date: Mon, 27 Jul 2009 08:10:15 -0400

Juergen Schoenwaelder writes...

> here are a few comments (posted as a technical contributor) on the

I think you have nicely summarized the open technical issues in the -00
draft.

>    phrase things such that things still work in case we replace TSM

I think that might be nice to do.  My one concern is that the mechanism of
this document is dependent upon the tmStateReference.  While some
yet-to-be-written security model might also work with a secure transport
model, allowing the VACM extensions in this document to be used without a
RADIUS-aware transport model seems to open up a security issue, or at the
very least an undefined mode of operation. 
 
> B: I suggest that we do not overwrite existing table entries.

There seems to be some support for that in the list discussions to date.
What we haven't determined is how additional entries are to be structured
and what precedence they have with respect to the existing entries.  I think
some further discussion of this issue is needed.

>    somehow need to do some reference counting.

Yes.

> D: I am not sure why the USM discussion in the security considerations

Well, if VACM entries are configured so as to seriously restrict access, and
we are relying on dynamic VACM group bindings, what happens if the network
is down and we are using the USM "back door" credentials for access?  Don't
we need corresponding VACM configuration?  This more of an operational
consideration, than a security consideration, however.

>    some config snippet is originating from in SNMP land...

The authors expected that the draft would eventually need to specify a MIB
module for this and other items, based on the flow of list discussion to
date, but the ideas hadn't sufficiently gelled at the time -00 was written
to allow inclusion of that MIB module.

> particular the document editors make it to Stockholm.

Yes.  Continued discussion of these items on the list will help us prepare
the next draft revision.  Thanks!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 14:36:01 +0200

> very least an undefined mode of operation. 

But isn't the RADIUS aware transport doing the manipulation of the
VACM table? Perhaps this is one thing to clarify further - which
component is actually manipulating the VACM table.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 14:47:17 +0200

modularity - remember?

the access control model modifies the access control model MIB.
NEVER should a transport model modify an access control model MIB.

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Monday, July 27, 2009 2:36 PM
> To: Dave Nelson
> Cc: [email-masked]
> Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 14:52:05 +0200

> NEVER should a transport model modify an access control model MIB.

A manager modifies the access control MIB as well. :-)

But seriously, the whole idea relies on the RADIUS client embedded in
the SNMP implementation to somehow cause a change of the VACM table. I
am sure you will explain us later today how this is done in an
architectural pure way.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 27 Jul 2009 08:54:27 -0400

Juergen Schoenwaelder writes ... [
 
> VACM table?

Channeling Dave Harrington:  No, that would be a violation of RFC3411
modularity.  :-)

> Perhaps this is one thing to clarify further - which

The transport populates tmStateReference.  It's up to the extended VACM code
to do something with that information, i.e., populate MIB tables.

My concern is related to attempting to use extended VACM, and thus the
tmStateRefrence, in the absence of a RADIUS-aware secure transport.  The
only input to the VACM's ASI that would indicate whether there is or is not
a RADIUS-aware transport at work would be the Security Model selector.  Do
you see another way to accomplish this?

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 27 Jul 2009 08:55:39 -0400

> modularity - remember?

Ha!  You did beat me to it, after all.  (See my reply where I channel you.)
:-)

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 27 Jul 2009 08:59:30 -0400

Juergen writes...

> the SNMP implementation to somehow cause a change of the VACM table.

The details are in the "somehow cause".

I think the flow is something like:

RADIUS Client

PAM

SSH

SSHTM

tmStateReference

extended VACM

MIB table

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 15:31:00 +0200

> to do something with that information, i.e., populate MIB tables.

Except that the ASIs do not pass the tmStateReference to VACM.

/js

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 16:04:31 +0200

Hi,

This particular binding between the info delivered from RADIUS to VACM
uses the "other" path:
implementation-dependent magic happens! The RADIUS management
attributes are stored in an implementation-dependent manner.

The RADIUS management attributes are principal-specific.
The principal-specific attributes can be found using
securitymodel/securityname/securitylevel.
isAccessAllowed already supports these fields.

dbh

> Sent: Monday, July 27, 2009 3:31 PM
> To: Dave Nelson
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 27 Jul 2009 14:23:28 +0000 (UTC)

> Except that the ASIs do not pass the tmStateReference 

No. tmStateReference is a "cache" that we invented to get around the issue of having to modify ASIs. :-)

---

From: [email-masked]
Date: Mon, 27 Jul 2009 14:30:28 +0000 (UTC)

David Harrington writes... 

Yes. 

I think another way to frame Juergen's original comment is why the (augmented) VACM tables should useTSM in the securityModel field. 

My answer was that it need not be restricted to TSM, but it would need to be restricted to some security model that was "dependent" on a RADIUS-aware transport model. Today, that means TSM.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 16:36:55 +0200

> the issue of having to modify ASIs.  :-)

Not really. See RFC 5590:

   [...] A
   tmStateReference is passed as an extra parameter in the ASIs between
   the Transport Subsystem and the Message Processing and Security
   Subsystems in order to identify the relevant cache. 

We pass the tmStateReference but no the detailed information the
tmStateReference points to. See also sections 6 of RFC 5590 for all
the details of the changes of the ASIs.

/js

---

From: [email-masked]
Date: Mon, 27 Jul 2009 14:47:32 +0000 (UTC)

> the details of the changes of the ASIs. 

Well, if we follow that precedent, and we want to avoid modifying the ASI of the access control model, we'll need to find another place to put the "magic". Since the tmStateReference pointer is only used in a "management" channel rather than a "message flow" channel, maybe it doesn't need to affect VACM's ASI, anyway. 

Any way you parse it, however, adding new functionality without modifying APIs (yes, I meant API, as in concrete implementation interface) is difficult.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 27 Jul 2009 17:10:20 +0200

Hi,
 
There would be no RADIUS attributes available if the transport model
doesn't support RADIUS.
Of course, that works on incoming traffic.
 
For notifications access control is done before authentication in
SNMP, so there would be no RADIUS attributes available (at least for
the first time).
I assume notifications might use pre-configured access controls.
 
dbh

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 27, 2009 4:30 PM
To: David Harrington
Cc: [email-masked]; Juergen Schoenwaelder
Subject: Re: [Isms] comments on draft-nelson-isms-extended-vacm-00

Yes.

I think another way to frame Juergen's original comment is why the
(augmented) VACM tables should useTSM in the securityModel field.

My answer was that it need not be restricted to TSM, but it would need
to be restricted to some security model that was "dependent" on a
RADIUS-aware transport model.  Today, that means TSM.

---

From: [email-masked]
Date: Mon, 27 Jul 2009 15:23:58 +0000 (UTC)

> There would be no RADIUS attributes available if the transport 
> model doesn't support RADIUS. 

Right.  It's an open question whether that always works as expected, but if the table entries make intelligent use of the securityModel field, this should be doable.

> Of course, that works on incoming traffic.

Right.

> For notifications access control is done before 
> authentication in SNMP...

Indulging in a "rat hole" side-discussion -- applying authorization before performing authentication seems fundamentally broken to me.  I know that we're not chartered to go down that "rat-hole", but I can't resist the observation in passing.

> ...so there would be no RADIUS attributes available
> (at least for the first time).

Right.

> I assume notifications might use pre-configured 

Yeah, I guess so.  Probably merits further thought.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Jul 2009 17:27:17 +0200

On Mon, Jul 27, 2009 at 04:47:32PM +0200, [email-masked] wrote:

> Well, if we follow that precedent, and we want to avoid modifying
> the ASI of the access control model, we'll need to find another
> place to put the "magic".  Since the tmStateReference pointer is
> only used in a "management" channel rather than a "message flow"
> channel, maybe it doesn't need to affect VACM's ASI, anyway.
> 
> Any way you parse it, however, adding new functionality without
> modifying APIs (yes, I meant API, as in concrete implementation
> interface) is difficult.

I think Randy Presuhn's model was that the RADIUS client acts pretty
much like an "embedded" SNMP manager doing a local set to modify the
VACM table. At least this one model to look at this. Another is the
black box magic (like someone /something modifying the SNMP agent's
configuration file is just magic). The WG needs to figure out to which
level of detail we want to / have to specify this.

/js

---

From: [email-masked]
Date: Mon, 27 Jul 2009 15:35:03 +0000 (UTC)

> I think Randy Presuhn's model was that the RADIUS
> client acts pretty much like an "embedded" SNMP
> manager doing a local set to modify the VACM table.

I think that's the right generic model, except that it isn't the RADIUS client that does this work.  (Another modularity discussion.)  The RADIUS client is typically isolated from the SNMP engine by PAM and the SSH server.  So, something external to the RADIUS client, that is triggered by the actions of the SSH server or the SSH Transport Model, will take the information from the tnStateReference and affect the VACM tables.