Hi George I guess it is more a question of definition of the scope of the authorization and authentication than of the actual mechanisms. I would invite you to read the RADIUS RFCs since your conclusions sound a little bit hasty. In RADIUS and in freeradius in particular the authentication is part of the authorization. This might sound somewhat strange, but is actually a sound and more general alternative from the AAA perspective, i.e. from an authenitcation service point of view. It goes like that: identification vector -> authorization -> authentication -> everything else. You could reflect upon it in terms of phases, although strictly speaking the whole treatment is applied on a per packet basis. It is of course true that one can do a lot of things with RADIUS (and especially with freeradius), that might not directly correspond to the initial goals, but I do believe that logically and generally one could speak about these phases. Thus, a user (or machine, or address or user logging in from certain mac address or whatever else is used as identity) can be allowed or not to use certain authentication schemes. Once a method is chosen, the claimed identity (or another one, unfortunately) can be verified during the authentication. If this verification of the identity (=authentication) is successful, certain parameters are transmitted to the NAS in the Access-Accept packet. These are to be applied to the service to be delivered. It could be duration, QoS parameters, service types, etc. - that is utterly dependent on the service and on the NAS and often employs a bunch of VSAs. So for me most definitely things such as Session-Timeout, the Tunnel attributes, and the most VSAs are authorizations, because these are properties to be applied to the already accepted service delivery for an authenticated identity. Now, there are other attributes (almost all of them, to cite Alan) that are actually authorizations. E.g. the same verified identity can be granted service access in certain conditions and not in the others. These conditions can be time, location, accounting (e.g. previous resource usage), roaming etc. related. E.g. you could allow only any member of a group A access to certain WiFi Access Points during certain time periods if and only if this particular member did not use up its resource limit. At the same time a group B could access all the other Access Points, etc. If that is not authorization for you, please explain your definition, since it would interest me personally. I do confess however that this particular scenario mixes up RADIUS and freeradius capabilities, but that seems normal since IETF protocols rarely specify behaviour. That leads to your question on policies. Policies also need a definition: what is a policy for you? In the broad common sense of the word, policies are not part of the RADIUS protocol. However you can quite easily implement policies in freeradius e.g. by grouping and actual resource usage (see example above - "during the course hours students are not allowed to login WiFi from the cafeteria", is that not a policy for you?). Depending on NAS capabilities and service to be provided, you can do more complex things... Is that helpful? artur On 2 Sep 2007, at 17:52, George Beitis wrote:
Hey Alan, thank you for your reply. I am writing up a part of my dissertation and I 'm referring to freeradius and the RADIUS protocol trying to explain how it works. From my research most people who use RADIUS for authentication purposes. Noone gives a clear image of whether or not they use it for authorization once they established authentication, so in other words authentication and authorization become one the same. Do you know of any products that can be used with freeradius to provide such authorization facilities? Using perhaps policies?
regards George
Alan DeKok wrote:
George Beitis wrote:
I have a general question regarding Authorization in the RADIUS protocol and how it is implemented in freeradius. What does the RADIUS protocol refer to when it talks about Authorization, does it actually refer to users being probably authorized after being authenticated, using the protocol?
I guess. It's not really clear. i.e. No one knows...
Are there RADIUS specific attributes that are for authorization? (not authentication).
Most of them? The authentication attributes are User-Password, CHAP-Password, EAP-Message... and not much else. Most everything else are authorization related.
There are ways of implementing authorization into freeradius, but do those simply overwrite the authentication decision?
I have no idea what you mean by that.
DIAMETER provides such authorization messeges from my understanding but the RADIUS protocol does not talk about any, is this correct?
Diameter is useless. It's a wonderful theoretical design that no one has deployed in a real network.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html