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

[Kaushik Narayan <kaushik at cisco.com>]

Hi Wes,

Thanks for your comments. Please find my response inline.


On 4/9/08 2:50 PM, "Wes Hardaker" <wjhns1 at hardakers.net> wrote:

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


<Kaushik>

You are right. Service authorization is a coarse granular mechanism to limit
SNMP access only to operators/admins and deny access to a large population
of users that may be authenticated by the RADIUS server. As you point out,
lack of service authorization will require administrators to setup VACM and
it is not a security issue but it provides ease of management.

We will update the text in this section

</Kaushik> 


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


<Kaushik>

Section 4.1 of RFC3579 discusses the threat model for RADIUS. All those
threats apply to usage of RADIUS in ISMS.


</Kaushik>

 




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




<Kaushik>


That's a fair point. The text was meant to indicate that deployments cannot
expect inter-operability between community based authentication/USM
authentication with RADIUS authentication. It does not currently point out
the side effect of such behavior. It will be good to clarify.

We will add your suggested text to the draft.

</Kaushik> 


>


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

<Kaushik>

We will fix the nits.

Regards,
 kaushik

</Kaushik>



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

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