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

From: Wes Hardaker <[email-masked]>
Date: Wed, 09 Apr 2008 14:50:55 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Apr 2008 08:59:12 -0400

Wes,

Thank you very much for your review.  I really appreciate it.  I've been
ignoring it up to now, solely because I've had very little time for IETF
work this week.  I hope to circle back and address your comments sometime
next week.

Regards,

Dave

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 11 Apr 2008 08:50:28 -0700

Hi Wes,

Thanks for your comments. Please find my response inline.

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

<Kaushik>

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

</Kaushik>

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

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Apr 2008 09:21:11 -0700

Hi Kaushik,

Thanks for the responses!

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

KN> We will update the text in this section

Thanks.  Please make sure that it's clear that the important thing is
that RADIUS may propose additional restrictions, but just by using
RADIUS you still need VACM configuration in place until the "future
research" on distributing VACM content is completed.  RADIUS may result
in closing of the connection and no messages making it to the VACM
layer, but it doesn't remove the VACM layer either...

> should still be documented.

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

That section doesn't discuss my concerns above.

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 11 Apr 2008 15:21:43 -0700

Hi Wes,

Please find my response inline.

<snipped>
> layer, but it doesn't remove the VACM layer either...

<Kaushik> Sure. </Kaushik>

<Kaushik>

I guess you are referring specifically to security considerations of any
form of external authentication for SNMP usage above and beyond the security
issues of specific authentication protocol (RADIUS).

We will add text to highlight security considerations for SNMP messages
being authenticated over the network. Are there specific considerations you
believe are important to highlight above and beyond the ones you have
mentioned in this note

regards,
 kaushik

</Kaushik>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Apr 2008 17:32:52 -0700

>>>>> "KN" == Kaushik Narayan <[email-masked]> writes:

KN> We will add text to highlight security considerations for SNMP messages
KN> being authenticated over the network. Are there specific considerations you
KN> believe are important to highlight above and beyond the ones you have
KN> mentioned in this note

Thanks!  Nope, just the fact that centralized authentication has it's
own issues when the protocol was originally designed to be able to fix
problems when the rest of the network was inaccessible.  Using a
centralized server potentially adds an easy DoS attack on the entire
management infrastructure as a whole because one central server can be
targeted which will result in the inability to manage every device on a network.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "David B. Nelson" <[email-masked]>
Date: Sat, 12 Apr 2008 10:33:06 -0400

Wes Hardaker writes...

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

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

> which isn't true.

One would *hope* it isn't true.

> Even if a non-SNMP user was properly authenticated to

If proper VACM configuration had been configured, yes.

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

> 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

Yeah, I see how that could happen.
 
> 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.

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

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Apr 2008 14:17:43 -0700

>>>>> On Sat, 12 Apr 2008 10:33:06 -0400, "David B. Nelson" <[email-masked]> 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]

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

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

>> provide authorization then access would magically get granted to users,

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

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

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