Subject: RE: [Isms] Network management authorization

From: "Nelson, David" <[email-masked]>
Date: Wed, 12 Jan 2005 15:02:01 -0500

Wes Hardaker writes...

> David> Failure to strictly tie these together is a security problem.
> 
> I don't disagree with that.  I disagree with the mandatory tying.  You
> MUST have authorization to do something.  That authorization MUST be
> tied to an identity which has been authenticated.

Cool.

> You don't necessarily need to, however, tie it via AAA.

I disagree. (But see my previous reply.  I notice that replies sent only
to the mail reflector are slower...)

> VACM already has a tie, albeit limited in functionality.

VACM can bind a username string "dave" to a view.  The problem is that
we need to be sure that the user "dave" who was authenticated is the
same instance of "dave" that is used in the VACM binding.  In simple,
local database implementations of SNMP authentication and authorization,
this might be easy to guarantee.  In the cases of remote AAA, there is
no strong binding of the local "dave" instance bound to the VACM and the
"dave" instance whose credentials were validated by the remote AAA.  You
can issue an organizational fiat that all usernames will be unique in a
single flat name space, but that is hard to guarantee, and, I postulate,
impossible to guarantee to a level of certainty required for good
security.  Some form of cryptographic binding is generally required.

> It's the forced binding of two
> technologies that I object to.  I'd imagine local policy directives
> that would tie authentication systems to a authorization system. 

I'm not suggesting that remote AAA be required.  I'm suggesting that
authentication be strictly tied to authorization, and that *when* remote
AAA is used the authorization MUST be explicitly provided by the AAA
service and not "guessed" by some local policy configuration.  

> "If coming in over SNMPv3/XXXX then look up grouping or other 
> information in authorization system YYYY".  

I respectfully disagree and think that solution would have very poor
security properties.

-- Dave

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 12 Jan 2005 12:32:23 -0800

>>>>> On Wed, 12 Jan 2005 15:02:01 -0500, "Nelson, David" <[email-masked]> said:

>> VACM already has a tie, albeit limited in functionality.

David> VACM can bind a username string "dave" to a view.  The problem
David> is that we need to be sure that the user "dave" who was
David> authenticated is the same instance of "dave" that is used in
David> the VACM binding.  In simple, local database implementations of
David> SNMP authentication and authorization, this might be easy to
David> guarantee.  In the cases of remote AAA, there is no strong
David> binding of the local "dave" instance bound to the VACM and the
David> "dave" instance whose credentials were validated by the remote
David> AAA.  You can issue an organizational fiat that all usernames
David> will be unique in a single flat name space, but that is hard to
David> guarantee, and, I postulate, impossible to guarantee to a level
David> of certainty required for good security.  Some form of
David> cryptographic binding is generally required.

I agree completely.  Almost.  Your one failed statement is that the
user "dave" must be unique by itself.  That's not true at all.  It
must be unique in combination with the security model (see the indexes
to the vacmSecurityToGroupTable).  Thus, dave only needs to be unique
for a given security model.  SBSM takes this into account in its
document and specifies that each authentication mechanism will be
considered a different security model with respect to how the VACM
should perform a look up.  (and it's entirely possible, as I pointed
out previously, that the contents of that lookup could very easily be
propagated from a remote AAA server's exchange (trying to use the
right terminology here new).  But not required.  It could have been
locally pre-determined assigned as well.)

David> I'm not suggesting that remote AAA be required.

I'm finally seeing that in writing.  I hadn't inferred that from the
previous statements.  And since that's the case, then I agree.

David> I'm suggesting that authentication be strictly tied to
David> authorization, and that *when* remote AAA is used the
David> authorization MUST be explicitly provided by the AAA service
David> and not "guessed" by some local policy configuration.

That, however, I disagree with.  I see no problems with accepting the
authentication provided by a remote entity and certifying that a
request is authentic to the person "david" using radius, but I may
have a local notion of what I want the person I now know
authoritatively as "david" to be able to do.  There is still a binding
here, but it is locally bound in the policy configured into the
device.  Or, I may want what you're describing which is to have the
remote AAA server also hand who their authorization rights.

Neither usage is insecure (although we haven't talked about how an
agent can trust a remote AAA server for either of these decisions).

Let me give an example from my past.  I worked at a university with a
centralized authentication system.  This centralized system was
capable of certifying (via kerberos or kerberos via radius or ...) who
a user was.  Each sub-department had its own services though.  What it
needed to know, in many cases, was could the user authenticate himself
against his central account.  If so and an identity was handed to the
server requesting the authentication (its another story about how this
is done), *then* the local policy would check to see if the person was
in deed a member of the department and could view the information in
question.  The centralized service did not have the membership
information, nor does it even today 5 years+ later.  It's not its
responsibility and if it was forced to do so, it would probably be
unwilling to.  Just because something else is doing the authentication
doesn't mean that it's the only place you can securely retrieve
authorization information from.  Now, the one caveat is that you have
to trust the larger authentication system to actually give you a user
identity which you can verify is in a subset of interest only to you.
It does get more complex if you want to deal with multiple remote AAA
servers acting in different "domains".

-- 
Wes Hardaker
Sparta