RADIUS question?

I was looking at this question today: https://www.skillset.com/questions/remote-authentication-dial-in-user-service-radius-separates-the-aaa-functionalities-true-or-false-4304

Does RADIUS really separate AAA functionalities? I get conflicting info from wikipedia and Cisco sites.

Find more posts tagged with

Comments

TheFORCE

RADIUS does not separate the AAA services.

Spin Lock

I think the question is trying to get you to confuse RADIUS features with TACACS+. RADIUS doesn't allow you to separate authentication, authorization and accounting, but TACACS+ does.

Eric_gg

Spin Lock wrote: »

I think the question is trying to get you to confuse RADIUS features with TACACS+. RADIUS doesn't allow you to separate authentication, authorization and accounting, but TACACS+ does.

Thanks, yeah that makes sense. After leveling up to intermediate skill level on access control, I got another one RADIUS/TACAS question: https://www.skillset.com/questions/which-system-is-more-secure-radius-or-tacacs-plus-6333

Would it also be considered less secure because you cannot separate AAA components? Even though the answer explanation doesnt say that?

newjack

Radius does Authentication/Authorization on port 1812 and Accounting on 1813. Can someone explain to me how this is not considered separate?

Unless it's completely separate of each other?

5502george

Here ya go, should clear up questions you have on Access Control.

5502george wrote: »

Here ya go, should clear up questions you have on Access Control.

Thanks! Where did you get this info from? easy read and awesome diagrams,

Spin Lock

newjack wrote: »

Radius does Authentication/Authorization on port 1812 and Accounting on 1813. Can someone explain to me how this is not considered separate?

First, let me say that I’m not an access control expert by any stretch of the imagination. What I know about RADIUS and TACACS I learned from AIO, Conrad and my other CISSP study guides. So when the original question came up of “Can you separate the AAA services in RADIUS?” I simply regurgitated what I read in those books – no, you can’t separate AAA services. The CISSP Study guides all seem to agree on this point, as does the the graphic that 5502george posted above (cissp-3.jpg). If you look at the chart in that image, you’ll see that it says AAA is consolidated under RADIUS.

But after you pointed out that under RADIUS, the Accounting service is running on a different port from Authentication, that made me scratch my head. If RADIUS truly has consolidated AAA, why is Accounting using a different port?

So I went back and reviewed the IETF RFC for RADIUS and also did a little online research, and I think I have a better understanding now of what’s going on. But let me preface my comments by stating once again, *I DON’T KNOW JACK ABOUT RADIUS*. In my book, unless you’ve got hands-on experiece sertting up a RADIUS server to communicate with a network access server (or other RADIUS client) as well as an LDAP/SQL database, you’re not an expert.

So here’s what my limited research into the issue of AAA services running on RADIUS revealed:

Question: “Does the RADIUS protocol support AAA services being run seperately?”

Answer: Not really, but it’s complicated.

Part of the confusion in answering this question is semantics. As you point out, Accounting is running on a separate port from Authentication. That sure looks like it’s running seperately to me.

But if you boil the question down and simplify it to mean this “We know RADIUS will support all 3 A’s running at the same time, but can you configure RADIUS to only run one of the A’s or some combination of 2 A’s? For example, can I only run Authorization? Or how about Accounting and Authentication but not Authorization?

The answer to those questions, from what I can tell, is the following:

1.You can disable Accounting, which still running Authentication and Authorization.

If you look at the RFC 2865, you will see that RADIUS protocol supports the following commands:

Access-Request
Access-Reject
Access-Accept
Account-Request
Accounting-Response

This is not an exhaustive list. See the RFC for that. But what this group of commands shows is, if a RADIUS client wants accounting services to be started, it will issue an “Accounting-Request” command to the RADIUS Server. This instructs the RADIUS server to start counting data usage for the user. There are many other accounting commands that allow the client to report usage data back to the RADIUS server where it gets logged (see RFC 2866)

If you want disable the Accounting server, you should probably be able to do that by simply ensuring the client never issues an “Account-Request” or any “Account-*” command to the RADIUS server in the first place.

2. You can’t run Authentication and Authorization seperately.

So disabling Accounting seems to be rather staight-forward. Can you disable Authentication or Authorization in the same manner? No. Notice that there is no “Authorization-Request” command in the RADIUS protocol. This is because RADIUS doesn’t allow you to separate Authorization and Authentication. Those two A’s go together hand-in-hand. This is how it works:

Suppose a RADIUS client wants to authenticate a user. The client will send a UDP packet to the RADIUS Server. The payload of that UDP packet will contain data formatted according to the RADIUS protocol. That protocol looks like this:

Byte 0: Code
Byte 1-2: Identifier
Byte 3: Length
Byte 4-7: Authenticator
Byte 8-?: List of Attributes

The “code” field is the Radius command. For user authentication, the command will be “Access-Request”. In the “List of Attributes” field, the Client will include the User’s name and password hash.

The RADIUS server will use this information to authenticate the user. It will then respond to the client with a UDP packet formatted according to the RADIUS protocol as well. This time though, the command will be “Access-Accept”. And in the Attribute field, it can specify services that the user is *authorized* to access. So the client has made an authentication request, and the server has responded with an authentication approval *AND* a list of attributes that grant the user services he is authorized to use.

What you can’t do is separate the authentication and authorization. In TACACS+ you have commands that allow the user to be authenticated and a separate set of commands that grant authorization. That’s not the case in RADIUS.

So to summarize, from what I can tell from reviewing the spec, it’s possible to disable Accounting and use RADIUS only for Authentication and Authorization, but that’s the only variation. You can’t separate Authentication and Authorization.

JDMurray

I think RADIUS does not allow different accounting systems to be used, but TACACS+ does. If this is so, one might say that that accounting in RADIUS is "tightly coupled" and accounting in TACACS+ is "loosely coupled."

docrice

I only skimmed this thread but I'll put my quick 2 cents in.

In RADIUS, in the authentication request/reply there are certain attributes available for conditional situations which allow for certain types of restrictions or assignments of address pools, etc. depending on what initial attributes sent in the request. However, the functionality isn't really deep in granular authorization. So verifying 1) who you are and 2) what you can do once your claimed identity is validated are essentially combined into the same workflow sequence. If you watch the wire via packet trace, RADIUS authentication is usually done over UDP 1812 (or 1645 in older implementations). It's a single Access-Request from the RADIUS client and a Access-Reply from the RADIUS server. Two packets and that's it. Everything (except the user's password) is cleartext. The RADIUS shared secret does not obfuscate any of the data, although it's partly used to mask the password. RADIUS accounting is done over UDP 1813 (or 1646 for older implementations).

In TACACS+ (typically used for network device management via Cisco ACS), authentication and authorization are separate actual events done over TCP 49. You can be allowed to SSH into a device via AAA authentication (TACACS+ in this example), but what you are authorized to do within the device is defined by an authorization policy tied to the user account. In Cisco ACS, you have the ability to define shell profiles for different user accounts. One shell profile could allow a certain group of users full administrative access to the device (that is, run virtually any command), while another shell profile could merely allow other users to run a few commands or a subset of a larger set of commands, which is typical if you have a set of junior admins which you don't want to grant complete device management ability.

With some vendor devices configured for TACACS+ authentication and authorization, simply running commands will initiate a separate TACACS+ authorization check for each command. In that case, until the AAA server responds with a "it's okay for this user to run that particular command" the device won't execute that command on behalf of the authenticated user. For example, a command like "show cpu" would be okay but "show firewall policy" would be denied.

Long story short, if you want real authorization capabilities, you go with TACACS+ instead of RADIUS.

5502george

newjack wrote: »

Thanks! Where did you get this info from? easy read and awesome diagrams,