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

[Wes Hardaker <wjhns1 at hardakers.net>]

I've read the -02 version of the radius usage draft and think it's a
well written, nicely terse and very understandable document.  I have a
few nits and a few issues with it but other than that think it should go
forward.

Even though this is a bit late, Jurgen assured me the write up would
still be appreciated.  Hopefully the "issues" are understandable.  Let
me know if they're not and I'll elaborate with greater details or examples.

======================================== Issues:

2.0 paragraph 5 (mostly the last sentence):

   One reason that RADIUS-provisioned service authorization is important
   is that in many deployments the RADIUS server's back-end
   authentication database contains credentials for many classes of
   users, only a small portion of which may be authorized to access the
   management interfaces of managed entities (NASes) via SNMP.  In the
   absence of RADIUS-provisioned service authorization, network
   management access may be granted to unauthorized, but properly
   authenticated, users.

This is not correct at all (and would be really bad from a security
perspective if it was true).  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).

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

(Traps and informs are a more interesting case, but the IETF has yet to
standardize trap and inform acceptance and action authorization.)

----------------------------------------

Section 5: Security Considerations:

No where in this section does it discuss the ramifications of relying on
a centralized network based authentication system.  Looking very quickly
(but not in detail so I may have missed it) at the other documents that
this section references, it doesn't look like they do either.  SNMP has
traditionally designed to be used in a way that makes it always
available if you can get to the device in question.  The use of RADIUS
changes this and adds additional dependencies on network availability.
It will now possible to perform new denial of service attacks by
attacking the infrastructure between the SNMP server using RADIUS for
authentication and the RADIUS server providing that authentication
back-end.  The use is certainly well justified as RADIUS will provide
many positive benefits that may be worth the cost, but the downsides
should still be documented.

--------------------

Section 5 paragraphs 3:

   Note that if the SNMP Message Processing Module selects the SNMPv1 or
   SNMPv2c Security Model as the security model to use (because the
   message is SNMPv1 or SNMPv2), then securityName comes from the
   community name, as per RFC3584.  This may not be what is expected
   when using an SNMP secure Transport Model.

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

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.

IE, people may think they've secured their v1/v2c deployment or
implementation by using SSH but in fact it may open an additional access
hole regardless of whether they use that access method themselves.

--------------------

Section 6 paragraph 4:

Similar problem with USM as well...  noAuthNoPriv user names within a
USM based message will result in the VACM being configured to allow
access from a noAuthNoPriv user which would then be accessible outside
the secure transport that was used.

At least with authNoPriv the USM user has been authenticated using a
secure authentication system (HMAC MD5 or SHA1) along with the RADIUS
authentication but the message would still be protected with less
encryption than was expected by the secure transport/RADIUS negotiated
half of the system.

======================================== Nits/Edits:

1.1, paragraph 2:

OLD:
   protocols, since the other network management interfaces such as
   NETCONF are capable of authentication with the same RADIUS server.

NEW: (delete the)
   protocols, since     other network management interfaces such as
   NETCONF may be capable of authentication with the same RADIUS server.


--------------------
1.1, paragraph 3:
                                     While it is customary in SNMP
   documents to indicate which subsystem performs specific processing
   tasks, in this document we leave such decisions to the implementer,
   as is customary for RADIUS documents, and simply specify NAS
   behavior.

COMMENT: I'd suggest making this two sentences for better readability


--------------------
1.2, paragraph 3:

This is just avoid generalizing as to popularity of deployment types:

OLD:
   Access-Accept messages are typically populated with one or more

NEW:
   Access-Accept messages are           populated with zero or more

--------------------
1.3, paragraphs 3 and 4:

   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?  IE, you can't use SSH public/private key
pairs to do the authentication and merely use RADIUS to pull
other provisioning information?  (this doesn't shock me, I'm just
curious).

--------------------
1.3 paragraph 3:

                     SSH server implementations often use the Pluggable
   Authentication Modules (PAM) interface provided by operating systems
                               ^
                               ^

It'd be good to stick an informative reference there.

--------------------

2.0 paragraph 3:

Removing "in-between" text.  It's either important or not so if you
think it is, I'd say that:

OLD:
   based Security Model (USM), this distinction is not significant.  For
   the SNMP Transport Models and the SNMP Transport Security Model
   (TSM), this distinction is relevant, and perhaps important.

NEW:
   based Security Model (USM), this distinction is not significant.  For
   the SNMP Transport Models and the SNMP Transport Security Model
   (TSM), this distinction is relevant  and         important.


--------------------

2.0 paragraph 6:

OLD:
                    A detailed description of how an Access Control
   Model (ACM) might utilize the services of a RADIUS client to obtain
   access control policy information is ***the*** topic of current research,
   and beyond the scope of this document.

NEW:
                    A detailed description of how an Access Control
   Model (ACM) might utilize the services of a RADIUS client to obtain
   access control policy information is ***a*** topic of current research,
   and beyond the scope of this document.


--------------------

2.1 paragraph 1:

OLD:
   This document will rely ***of*** implementation specific integration of the
   transport protocols with RADIUS clients for user authentication.

NEW:
   This document will rely ***on*** implementation specific integration of the
   transport protocols with RADIUS clients for user authentication.

--------------------

2.3:

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.

--------------------
2.4:

OLD:
   (VACM) [RFC3415], might utilize RADIUS authorization are ***the*** topic of
   current research, and beyond the scope of this document.

NEW:
   (VACM) [RFC3415], might utilize RADIUS authorization are ***a*** topic of
   current research, and beyond the scope of this document.



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