REPOST: Authentication, Authorization TO Firewall

Hi, Thanks for the reply. I would like to put the query in a better form.

Do firewalls provide dynamically defined access control i.e., can they act as access controllers. e.g., it should be able to do the following, a user tries to access a resource, the packets would come to the firewall, if they are HTTP packets and the user is new (from IP address not being in the authenticated list), the packets would be redirected to a webproxy, the webproxy tries to get the user authenticated by a AAA server (say RADIUS), the firewall would get an authorization message from the AAA server (or webproxy), saying the time the user must be allowed access, the resources he can access etc. The firewall would provide that access.

Can this be done by the firewalls in the market such as Checkpoint firewall-1

greenhorn.

P.S. Walter, thanks for all your replies.

authentication/authorization boundary checkers are frequently being referred to as portals (when used as boundary interface to the internet). the application firewalls and packet-filter routers have frequently just been somewhat transparent boxes that filter out identifiable bad stuff.

boxes that clients interact with for authentication/authorization function are frequently referred to as portals.

authorization policy filtering based on origin ip-address possibly by time-of-day ... could be an administrative function that updated/changed packet filerting router rules at different times of the day. This frequently would be a push operation from the policy and administrative infrastructure ... rather than a pull function from the individual boxes.

authenticaton tends to be asserting some characteristic (like an account number or userid) and then providing some information supporting that assertion ... from 3-factor authentcation paradigm

• something you have

• something you know

• something you are

using ip-address origin is more akin to identification w/o necessarily requiring any proof (or additional interaction demanding proof).

authorization frequently tends to be taking some characteristic (either from simple identification or from an authorization process) and looking up the related permissions defined for that characteristic (like which systems can an authenticated userid access).

RADIUS was originally developed by livingston for their modem concentrator boxes (i.e. provided authentication boundary for userid/login authentication for dail-up modem pools). It has since grown into a generalized IETF standard for AAA

In the original livingston case ... the modem concentrator provided both the RADIUS boundary authentication/authorization as well as the traffic routing function in the same box. This continues as dominate technology used world-wide by ISPs to authenticate their dial-in customers.

the boxes that are routing traffic between intranet and internet are frequently not exposted to clients as separate functional boxes ... as is the case of the modem-pool routers that managed the boundary between the ISP intranet and their dial-in customers.

there is a related but different kind of administrative boundary situation for DSL/cable customers. They typically have a unquely identifiable box or (non-ip) address. DHCP requests come in from these boxes ... if the boxes are associated with a registered, up-to-date account .. and administrative policy will return DHCP responses that enable access to generally available ISP services. However, if the box is not associated with a registered, up-to-date account ... the DHCP response can configure them so that all their DNS requests and the resulting ip-address responses go to an in-house sign-up (regardless of the domain name supplied by your browser ... it would always get back the same ip-address directing it to a webservice associated with administrative signup). You tend to find similar setup/configuration for hotel high-speed internet service and many of the wireless ISP service providers.

in this scenario ... the dynamic administrative policy isn't based on ip-address (as an identification) but some other lower level hardware box address (enet mac address, cable box mac address, etc).

In article , Greenhorn wrote: : I am new to firewalls. Are firewalls usually compliant with AAA :servers (say RADIUS),

Depends on what you mean by 'usually' and 'firewall'. There are a lot of "firewalls" marketted by Linksys and kin that do not know how to talk to RADIUS.

:if not, is there other way for the firewalls to :get authorization information regarding letting an user traffic out/in :(e.g., how much time, etc).

TACACS+ or other proprietary protocols.

Firewalls don't necessarily know about time constraints.

:I am curious on how the web-based login system in hotspots works. The :user logs in to the web proxy. If the user is authentic, the firewall :should open up for this user (IP address). Is the web proxy part of the :firewall itself here,

Depends on the device.

:if so, can someone tell me a few such product :names. If the web proxy is a different element, the firewall should :recieve some authorization information on how much time the user :traffic (from that IP address or virtual port) should be allowed, wat :is the standard protocol used for this.

No standard protocol.

One hotspot with time control is ZyXel's ZyAir series.

long ago and far away ... for the original e-commerce payment gateway

we started out with administrative pushing permitted/allowed ip-addresses (webservers that had valid contracts to use the payment gateway) into routers.

this was also in the early days of haystack labs, wheel group, and some others.

In article , Greenhorn wrote: :I would like to put the query in a better form.

:Do firewalls provide dynamically defined access :control i.e., can they act as access controllers.

Some can. "firewalls" is a very broad term.

:e.g., it should be able to do the following, a user :tries to access a resource, the packets would come to :the firewall, if they are HTTP packets and the user is :new (from IP address not being in the authenticated :list), the packets would be redirected to a webproxy, :the webproxy tries to get the user authenticated by a :AAA server (say RADIUS), the firewall would get an :authorization message from the AAA server (or :webproxy), saying the time the user must be allowed :access, the resources he can access etc. :The firewall would provide that access.

The Cisco PIX doesn't "redirect" to a web proxy, it effectively is the proxy itself. It provides the authentication you are looking for, but there is no mechanism on the PIX for per-user adjustments of the timeout (such as might be desired for a hot-spot.) The PIX does have an adjustable authentication timeout, but it is the same relative timeout for all users -- and the next time the user went to authenticate, the RADIUS server would be free to examine accounting records to determine whether the user was still authorized. How exactly the RADIUS server would do that is dependant on the RADIUS server.

:Can this be done by the firewalls in the market such :as Checkpoint firewall-1

Sorry, I don't know much about Checkpoint-1.

If you are looking for hotspot-like behaviour, then have a look at the facilities provided by ZyXel's ZyAir series. That's mostly for wireless, but they may have other relevant models or it may give you further ideas.

In article , Anne & Lynn Wheeler wrote: :authorization policy filtering based on origin ip-address possibly by :time-of-day ... could be an administrative function that :updated/changed packet filerting router rules at different times of :the day. This frequently would be a push operation from the policy and :administrative infrastructure ... rather than a pull function from the :individual boxes.

I had interpreted the OP's questions about time to be matters of how long the user would be permitted, such as in a pay service. But time-of-day functionality is interesting too.

If the OP does turn out to be looking for time-of-day functionality, then the Cisco PIX 515/515E, 525, or 535, running PIX 7.0(1), support time-of-day based access lists.

All models of the PIX support (from PIX 5.1 onward) RADIUS downloadable access-lists . This suggests an alternative approach to the pay-for-use question: if one were using 515/515E, 525, or 535 with the 7.0 software, then the downloadable access list could be time-based. When the time ran out, then it could be arranged so that the user fell into a deny-everything situation.

The user interface would be a bit different, though: instead of the user getting challenged for a username/password and told that it is no longer valid, the user simply would suddenly not be able to get to anywhere. Same effect, but perhaps more confusing for the user.