Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 14 Apr 2005 20:22:24 -0400

>> RADIUS server or whatever is authorizing the user, must provide
(besides
>> the keying, of course) the mapping to SNMP VACM, so that the actual
>> access control can be performed.
>> 
>> We must solve the first problem first - getting users
RADIUS-authorized
>> (for example). But we must also realize that it is only a half of the
>> issue. 
>
>If user mapping to VACM can be in a centralized database accessible to 
>the RADIUS server, perhaps we solve half of the other half of the
issue!

No reason why it cannot be there. It's just another set of data, related
to users and their access rights.

So in case of RADIUS, the "access granted" should be accompanied by:

 - generated fresh keying for this session (including its life-time);
 - identity to use for this connection (as probably nobody wants to
configure user database on the SNMP agent :-);
 - mapping of that identity onto an existing VACM group.

Not that hard really...  But somebody has to add that info to the
existing server database. So this solution will utilize the existing
infrastructure - but it can never be "zero touch". Something extra will
have to be done. 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 14 Apr 2005 17:36:36 -0700

Hi -

> From: "Blumenthal, Uri" <[email-masked]>
> To: "Thierry Moreau" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, April 14, 2005 5:22 PM
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
...
>  - mapping of that identity onto an existing VACM group.
...

Sounds a lot like EUSM.  (not that that'd be a bad thing)

Randy

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 14 Apr 2005 21:09:10 -0400

> configure user database on the SNMP agent :-);

See my previous post on "A session-less fix to SNMP security issues?", 
section 3.4.3.

> infrastructure - but it can never be "zero touch". Something extra will

Indeed.

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 15 Apr 2005 09:35:50 -0700 (PDT)

HI Randy,

> Sounds a lot like EUSM.  (not that that'd be a bad thing)

Would you explain your statement "Sounds a lot like EUSM" because
EUSM didn't invent this, nor is it exclusive to EUSM, nor is
it key unique characteristic to EUSM that differentiates
it from other approaches. 

Thanks,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Apr 2005 12:46:57 -0700

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, April 15, 2005 9:35 AM
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
...
...

The EUSM proposal was the only one that *clearly* identified a mechanism
for handling dynamic VACM user->group mappings.  If it was spelled out
in any of the other proposals we looked at, I missed it.

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 15 Apr 2005 13:48:37 -0700 (PDT)

HI,

OK, you are falling into the trap of associating a characteristic
to the first place that you have seen it used.

Well it turns out that the problem of adding a user to the
"to group table" was clearly identified in the BOFs that
predated the EUSM submission. It was not "spelled out"
in the SBSM (and maybe other submissions) because it
was CLEARLY OUTSIDE THE SCOPE of the WG charter.

Let me ask the multipart question again...

What aspect of getting the mapping of identity to group from
a Radius sever:
1) is specific to EUSM
2) works better in EUSM than other approaches
3) a required for EUSM to work (that is, it is a fundamental
   and characteristic part of EUSM)

> in any of the other proposals we looked at, I missed it.

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 15 Apr 2005 14:19:50 -0700

Hi -

> Sent: Friday, April 15, 2005 1:48 PM

> was CLEARLY OUTSIDE THE SCOPE of the WG charter.

Dave, there's no need to get all bent out of shape.  All I said
was "Sounds a lot like EUSM".  If you felt that this was somehow
disparaging of other proposals, you're reading far too much into
the comment, and wasting energy that would be better spent
on technical discussion.

> What aspect of getting the mapping of identity to group from

I've made no such claim, although it was the only proposal
that spelled it out.  As we wrote in the evaluation, we *liked*
this aspect, because even though it goes farther than the
letter of the charter, it is clearly needed for a solution that
minimizes the need to touch managed devices every time
a new user is added.

> 2) works better in EUSM than other approaches

I've made no such claim, and I don't see why there's any
value to arguing this point one way or the other.

>    and characteristic part of EUSM)

Without it, an important benefit of EUSM would go away:
the ability to support the addition of users to the user/identity
management system without needing to touch managed devices.

But the real issue, from my perspective, is that *whatever* approach
this WG goes with needs to address the VACM user->group
mapping.  Failure to do so will, in my opinion, produce a solution
that is administratively no more appealing than what we have today,
since it would *still* require the administrator to go out and touch
every managed device that a user might access.

Randy