Re: [Isms] review of draft-ietf-isms-radius-usage

[Wes Hardaker <wjhns1 at hardakers.net>]

>>>>> On Sat, 12 Apr 2008 10:33:06 -0400, "David B. Nelson" <d.b.nelson at comcast.net> said:

David,

Sorry for the delay in a response...

[Re: section 2, paragraph 5 about in absence of radius distributed
authorization network management access is granted]

>> This is not correct at all (and would be really bad from a security
>> perspective if it was true).

DBN> I hope you are right.  However, I've seen some implementations of SSH and
DBN> RADIUS integrations where the SSH server ignores any authorization
DBN> attributes that come from the RADIUS Access-Accept message.  For example,
DBN> there is no standardized way of getting this information via the PAM
DBN> interface, although there are ways that can be made to work.

It's true, of course, that there are non-compliant implementations of
just about every protocol.   We can't force compliance.  We can only
state what it means to be compliant.  If the SSH/Radius standard says
that you can't ignore the distributed authorization information and an
implementation does so anyway, then it's not compliant.

That being said, we have to write standards based on what the real world
is expected to implement.  If the current largest body of usable
authentication plugins (PAM) means it's almost impossible to implement
authorization in that manner then either PAM needs to be rewritten (UGH)
or maybe the standard shouldn't have been defined that way.

But this is slightly off the topic that I was trying to get at.  Lets
say that the SNMP/SSH/Radius combination specified that the
authorization information can't be ignored in a radius packet.  If an
implementation choose to ignore it anyway because of implementation
complexities (PAM or otherwise) they *still* wouldn't be granted access
to the network management infrastructure because the SNMP/VACM
combination wouldn't let them in anyway.  That's not at all what the
paragraph implies, which was my compliant.

I believe this is going to be changed in the next rev so really I'm just
adding yet more explanation in case there is still any doubt of the
content from my original message.

>> If RADIUS didn't provision service authorization then network management
>> access would not be granted at all if there was no other provisioning 
>> (like in place priory configuration).

DBN> Yes, *assuming* that the service granting entity in the NAS actually looks
DBN> for the service provisioning information and acts upon it.  As I say, I've
DBN> seem implementations where it does not (poor implementations,
DBN> IMHO).

No, the SNMP stack would have to look at the VACM configuration
regardless.  If it wasn't there, it would be miscompliant with the SNMP
protocol entirely (forget Radius here).  Radius may provide a way to
distribute that VACM config so it's not missing (future work) or could
augment the VACM by stating that the only accessible path is over a
transport with certain properties (and that may be ignored, you're right).

>> That last sentence implies that without RADIUS access would magically be
>> granted to users or that if RADIUS provided authentication but did not
>> provide authorization then access would magically get granted to users,
>> which isn't true.

DBN> One would *hope* it isn't true.

I know of no SNMPv3 compliant stack that doesn't check VACM
authorization.

When SNMP/SSH/Radius comes out in a stack I could see the resulting
implementation ignoring the Radius set provisioning, but if it did so
and it didn't have any VACM configuration already in place the packet
would get no where (unless in the process of implementing the Radius
part they actually removed the VACM support, which I don't see as likely).

>> No where in this section does it discuss the ramifications of relying on
>> a centralized network based authentication system.

DBN> I think I recall a discussion of this issue on the list or in a
DBN> meeting early on.  I think the analogy I used is how Unix
DBN> workstation login often works in large organizations.  Workstations
DBN> often rely upon NIS (LDAP or similar) for centralized login
DBN> administration but almost always have a local password file for a
DBN> local root account.  If the network is down, or the NIS server has
DBN> moved, the administrator can use the local root password to gain
DBN> access to the workstation.

A perfect analogy.  But the current draft doesn't discuss such a
situation nor does it recommend that to avoid it a secondary path to the
SNMP infrastructure (like SNMPv3/USM without Radius) should be configured.

DBN> The same advice applies here.  Configure your NAS with a local
DBN> account (e.g.  username and password) that bypasses the need for
DBN> RADIUS authentication.  Do we need to add that implementation
DBN> reminder in this draft?

IMHO, Yes.

DBN> OK, good point.  We can add some text to that effect.  I am generally a bit
DBN> concerned that the implications of extending the ISMS work, originally
DBN> focused on v3, to v1 and v2c have not been completely though out.

For reference, I too think it's a bit odd and am not sure why it's so
important to support.  From a pure theory point of view, I can
understand it.  From a "is it really useful to waste that much time on"
I'm less convinced that it's worth the time because it's not that needed
in practice.

>> This whole section discusses two different cases:
>> RADIUS:Integrity-Confidentiality-Protection and mapping to SNMP:authPriv
>> and RADIUS:No-Protection and its mapping to SNMP:noAuthNoPriv.
...

DBN> In terms of the "auth" part of SNMP "authPriv", I always thought it stood
DBN> for "authentication".  When using RADIUS, which is all about authentication
DBN> and authorization, the user is *always* authenticated, so the use of RADIUS
DBN> with SNMP always implies "auth".  The "noAuth" case just doesn't map.

Ah...  I'd spell that out a bit more clearly.  I missed that somehow.

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms