Subject: Re: [Isms] Network management authorization

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Jan 2005 14:57:25 -0800

>>>>> On Tue, 11 Jan 2005 17:42:20 -0500, "David B Harrington" <[email-masked]> said:

David> The other proposals could use use RADIUS and a
David> management-policy-id attribute as well, but neither discusses
David> doing so. SBSM says working with RADIUS is a goal, but also
David> seems to conclude that working with RADIUS simply won't work -
David> "Several approahces were considered, but none were determined
David> workable."

Ok, I've been too busy to respond to the rest of the comments today.
But this one just irked me since you tied two totally different
sections together by pulling a sentence from a later unrelated section
and some how applied it to the authentication section.  Specifically,
you're pulling text from the history section, in particular from
David's recanting of his past history about thinking about the
problem.  In particular, in that section he was describing how he
thought about tying something directly to Radius but in the end didn't
think it would be usable.

In short, SBSM as is (without modification) can be tied to radius now.
The authentication systems in the back aren't complete for various
reasons, as the draft states and as I stated previously this week, but
the local authentication mechanism that is defined there today passes
the information needed to the agent for the agent to do a radius
exchange.  This exchange could, but doesn't have to, lead to
bootstrapping of the VACM via similar mechanisms as the other drafts
discuss.  It's not mentioned within the SBSM document directly because
it's out of scope of the working group, but maybe I should have put a
note in saying that it in no way impedes progress in any VACM
centralization scheme.

-- 
Wes Hardaker
Sparta

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

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Jan 2005 18:55:28 -0500

Hi Wes,

Sorry to irk you.

I was responding largely to david's misquotes of what I had said, and
to his claim that "On the other hand, SBSM could use the 
...radius-management-authorization... proposal pretty easily."

I searched the SBSM proposal to see how it supported RADIUS and could
utilize the RADIUS-specific management-policy-id attribute, but didn't
see how it would do so pretty easily. I see now that I misread the
Goals and Objectives section - I missed the "... met by this protocol
include" sentence, much as you missed Eric's "ascending importance"
sentence, so it wasn't clear that a workable solution for RADIUS had
been found. The SBSM proposal does not describe how it can support
RADIUS at this point, so I had difficulty understanding how it would
use the RADIUS management-policy-ID proposal pretty easily. 

I apologize for my confusion.

dbh
 
> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Tuesday, January 11, 2005 5:57 PM
> To: [email-masked]
> Cc: 'David T. Perkins'; 'Martin Soukup'; [email-masked]
> Subject: Re: [Isms] Network management authorization
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 Jan 2005 17:46:25 -0800

Hi -

> From: "Wes Hardaker" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, January 11, 2005 2:57 PM
...
> In short, SBSM as is (without modification) can be tied to radius now.

This wasn't clear to me from the i-d.  Thanks for spelling it out.

> note in saying that it in no way impedes progress in any VACM
...

I don't think it's necessary to go so far as a "VACM centralization scheme."
This bit that *is* important to address in integrating with external
authentication systems is the mapping of users to groups.  Although
that is modeled in VACM, it can also be considered part of user management.
Failing to address it would be a grave mistake for the WG, IMO.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Jan 2005 08:24:56 -0800

>>>>> On Tue, 11 Jan 2005 17:46:25 -0800, "Randy Presuhn" <[email-masked]> said:

>> In short, SBSM as is (without modification) can be tied to radius now.

Randy> This wasn't clear to me from the i-d.  Thanks for spelling it
Randy> out.

Well, I said "can" but it is not the most ideal way to do it IMHO.  I
was hoping to do a better radius supported authentication system in
the future as well that wouldn't require the transfer of passwords to
the agent.  Granted, boxes that support remote terminal logins already
require users to type in passwords which are then used to authenticate
radius, I'd ideally like to see an SNMP system not require such as a
scheme if a better system was available (cram-md5, the newer one I
forget the name of suddenly (ug!), ...)

Randy> I don't think it's necessary to go so far as a "VACM
Randy> centralization scheme."  This bit that *is* important to
Randy> address in integrating with external authentication systems is
Randy> the mapping of users to groups.

Agreed...  The depth of which information needs to flow within the
VACM is likely to be closer to exactly what is described above (and in
the EUSM draft).

Randy> Although that is modeled in VACM, it can also be considered
Randy> part of user management.  Failing to address it would be a
Randy> grave mistake for the WG, IMO.

I think it should be a goal too.  But, I don't think it should be tied
to the authentication system since that would then require that the
authentication system be tied to radius, which I don't think would
make every operator out there happy.  Not everyone uses radius (and in
fact my survey showed this clearly).  If we only supported a radius
based extension we would not even be supporting a majority of the
market, which seems very counter to exactly what we're trying to do.

-- 
Wes Hardaker
Sparta