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

["David B. Nelson" <d.b.nelson at comcast.net>]

Wes Hardaker writes...

> I've read the -02 version of the radius usage draft and think it's a
> well written, nicely terse and very understandable document.

Thanks.

 > Hopefully the "issues" are understandable.

I'll offer my comments, in-line, below.  Kaushik has already addressed most
or all of these, but I'll add my two-cents.

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

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

> 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).

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

In any event, it is important to have RADIUS service provisioning attributes
that are specific to NAS management, and in the specific instance of ISMS
work, for access to the SNMP engine of the NAS.  It's equally important that
the NAS looks for and enforces these attributes as a condition of access.
This all seems pretty obvious, of course.

> 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.

One would *hope* it isn't true.

> Even if a non-SNMP user was properly authenticated to
> a device over an SNMP transport authenticating through RADIUS, the user
> still wouldn't be able to actually do anything without proper VACM
> configuration in place to allow it to happen.

If proper VACM configuration had been configured, yes.

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

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

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

> The problem is if we start attaching RADIUS authorization fields to the
> Access-Accept message then we need to ensure that the authorization is
> only granted to the securityName the RADIUS protocol expects it to be
> granted to.

Right.

> EG, if RADIUS decides that user Wes should be allowed to access the 
> SNMP service using authPriv over his SSH session but should be 
> restricted to read-only access (which I realize this draft doesn't
> discuss and is a topic of future research), then if Wes specifies a
> community name that is allowed write access via the existing
> VACM/COMMUNITY config then Wes is being granted access beyond what was
> negotiated.

Yeah, I see how that could happen.
 
> The real problem, and this is what I think should be documented as the
> above only really applies to future work, is that if RADIUS and a secure
> transport (eg SSH) was used to authenticate and protect a message and if
> the v1/v2c community security model was selected then configuration
> would have to exist that allowed those community names to come in over
> unsecured transport.  Restated: the community name would need to be
> given rights in the VACM and COMMUNITY MIBs that would allow it to be
> used regardless of whether it came in over the secure transport or not
> (since the MIBs don't have a flag for 'only if over SSH, DTLS or
> similar').
> 
> Thus I'd add something like: It is NOT RECOMMENDED that a combination of
> a secure transport, RADIUS authentication and the SNMPv1 and/or SNMPv2c
> community models be used since it necessitates the opening of an
> insecure access pass within the ACS.

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

>    Secure transport protocols do not, however, specify how the transport
>    interfaces to authentication clients, leaving such as implementation
>    specific.  For e.g., the "password" method of SSH authentication
>    ...
> 
> This section implies that it is impossible to use RADIUS for just
> authorization distribution?

Well, there has been an expensive discussion of that issue.  The short
answer is that you can use RADIUS to re-authorize, including providing a
completely different authorization, based on a "binding" to a previous
RADIUS authentication.  This is "binding" is accomplished via the RADIUS
State attribute (a cookie issued by the RADIUS server to the RADIUS client).

This draft does not discuss RADIUS re-authorization, and how it might apply
to the ISMS work is another topic for future research.

> IE, you can't use SSH public/private key pairs to do the authentication
> and merely use RADIUS to pull other provisioning information? 

That's correct.  The initial authentication must have been via RADIUS, and
probably via the same RADIUS server.

> 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.  But it
> never mentions whether RADIUS:Integrity-Protection exists (I'm guessing
> at a name here; I'm not a RADIUS expert) and whether it can map to
> SNMP:authNoPriv.  Is it possible to do an authNoPriv equivalent?  Either
> way, it should be discussed.

The RADIUS Management-Transport-Protection attribute describes the minimum
required level of protection of the *transport*.  Basically you can call for
integrity protection (a cryptographic checksum) or integrity and
confidentially protection (encrypted payload and cryptographic checksum) or
no protection (unsigned clear text).

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

You could do an "authNoPriv" equivalent with the tools that RADIUS provides.
Is that useful?


_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms