COA | Change Of Authorization

COA | Change of authorization
RFC 3576
UDP port 3766 | IEEE

>Change of authorization is used to ask NETWORK SWITCH/ROUTER/WIFI-CONTROLLER to disconnect-user, session timeout, bounce port of the existing user session on network.
>Mostly AAA server is user to record the user accounting information and based on the user activity or time the user is then disconnected from the network or session timed out.
>The Network device will send the accounting information to a AAA server.
>The AAA server keeps track of user information like Device MAC-ADDRESS, User SESSION-ID, USERNAME, FRAMED-IP-ADDRESS and more based on what it gets from accounting request.
>The radius accounting request traffic will be send only after a successful authentication.
>You could configure to send interim accounting update about the user to accounting server.This interim update can help in scenarios where you want to disconnect the user after usage of certain amount of bandwidth in network. Default time:300 Sec

#Things to remember while working on a COA setup:
>Make sure the network device is configured to except the COA request from COA server on respected port.
>NAS devices wants to see particular attriutes in COA request to identify the user session and perform COA, So sending the right attributes on COA request is important and it depends on the NAS device vendor.
>The expected COA user identification attribute might be different for a Captive portal authenticated user and Dot1.x user.
>Some vendor ignote the unsupported or unknown attributes in COA request and still ACK your COA request. However some vendor devices dont like you sending a unsupported COA attributes, so they respond with disconnect-NAK
#Here in case of Fortigate Firewall you might need to send the right COA supported attribute to identify the user session.

*supported attributes: WPA-Enterprise&UserGroup and Captive Portal supports:
USER_NAME,
FRAMED_IP_ADDRESS,
EVENT_TIMESTAMP,
MESSAGE_AUTHENTICATOR,

*User-name” and “Frame-ip” were supported in DM request and both MUST be involved, other attributes like “Calling-Station-Id”, “Called-Station-Id” could not be supported and would cause 503 error message.
*The attributes “EVENT_TIMESTAMP” and “MESSAGE_AUTHENTICATOR” are options.
*Note: Supported attributes as on the latest firmware v5.4

#In case of ARUBA MOBILIY CONTROLLER:

The mobility controller supports the following attributes for identifying the users who authenticate with an RFC 3576 server:

* user-name: Name of the user to be authenticated.
* framed-ip-address: User’s IP address.
* calling-station-id: Phone number of a station that originated a call.
* accounting-session-id: Unique accounting ID for the user session

–> Other attribute might cause 503 error.

#Other ports to Remember:
*Radus Accounting request and Response is on UDP1813
*Radius Authentication is on UDP1812

#Some snapshots attached here to see what’s there inside Disconnect-request,Disconnect-,ACK,Disconnect-NAK.

Accounting Request:

radius-acc

Disconnect Request:

Disconnect-request

Disconnect-ACK:

Disconnect_Ack

Disconnect-NAK:

Disconnect_NAK

If would like to look at the entire pcap, let me know I can share with your guys.

 

BYOD fails because of those CNA agents on IOS and Android

I had this chance to work with an Australian Account for BYOD solution issue.

Deployment: Fortinet Infrastructure wifi solution with Forticonnect a Byod solution.

Issue: Windows devices are able to get on-boarded successfully but the Macintosh and android having issues.

Once i jumped onto troubleshoot this issue found the configuration seems to be totally fine. So is it a software bug?
What i get to find again is this tiny browser (CNA agent) on wifi clients which doesn’t have the full browser capacity is the cause of the issue.

Firstly , how a traditional BYOD solution works is users initially connect to a OPEN ssid and then they download a DOT1.X PROFILE and later using the profile user are on-boarded securely on the network.This can also be done using a single SSID also, It depends on how much your BYOD solution can assist you on this.

Coming back to my issue here, I say the user connected on the guest network and did authenticate to the CAPTIVE PORTAL/ BYOD. However this authentication success message was never passed back to the WLAN controller, So that WLC can initiate the RADIUS REQUEST to RADIUS SERVER.

>This is how a station log for problematic wifi client looks like.

2017-Jan- 9 13:14:27.306847 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:14:27.352095 | 44:2a:60:fc:39:d4 | Band Steering | <AID=0>[abgn](v0) Steering to 5Ghz under policy=A Blocking 2.4Ghz, present staType=ABGN ESSID=e-smart-access B-BSSID=00:0c:e6:0a:cb:1f Ch=11
station-log>
2017-Jan- 9 13:14:27.554238 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.554248 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555616 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555625 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555993 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=3>[abgn](v0) Steered to 5Ghz under policy=A staType=ABGN[15] ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0.203891 seconds
station-log>
2017-Jan- 9 13:14:27.563019 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:14:27.572135 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:14:28.573801 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135

While if you want to compare how a successful CP authentication looks like on contrast:

2017-Jan- 9 13:50:53.401458 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=RSSI changed
station-log>
2017-Jan- 9 13:50:55.921525 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) removed from <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Inactivity timer expired
station-log>
2017-Jan- 9 13:52:33.440124 | 44:2a:60:fc:39:d4 | Station Assign | <AID=2>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:52:33.440941 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.440950 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441122 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441131 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441549 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441558 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.442632 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=2>[abgn](v0) Self-steered to 5Ghz under policy = A staType = ABGN ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0
station-log>
2017-Jan- 9 13:52:33.448274 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:52:33.454929 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:52:34.507002 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135>
station-log>
station-log>
station-log>
station-log>
2017-Jan- 9 13:53:54.616485 | 44:2a:60:fc:39:d4 | CP User Authentication | <Captive Portal Profile= captive-portal> <User : chewc@xxxx.edu.au> <ipaddr=10.12.1.135> Sending User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616487 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Guest User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616626 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Radius Authentication Request.
station-log>
2017-Jan- 9 13:53:54.678054 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Radius User Authenticated Successfully <session_time=0 secs> <filter_id=> <idle_time=0 secs>
station-log>
>You would see on the above successful station log that the client has forwarded the WiFi Auth credentials back to the WLAN controller (4th line from the last) and so Radius Auth session can now be initiated to RADIUS Server(last 3 lines)
Note:This is very important for the controller to know that the users is authenticated and so later when ANDROID user going to google play store or when an IOS user going to Apple store the controller lets the traffic go out. Since captive portal SSID always allows only ARP, DNS, DHCP traffic of client before authentication success. And in few other vendors you still need to allow the client subnet to access google play store and apple store.

>Else you would run into issues such that the wifi clients are not able to download the application(smart connect) from APP STORE that assists the device to download dot1.x profile from BYOD server.

Solution: After we just disabling the CNA agent(tiny browser) the wifi clients have no problem in onbording to a dot1.x network. We forced the client not to use the CNA AGENT by using the feature in WiFi controller.

>There are some parameter (SSID+CLIENT_MACADDRESS+SWITCHIP:PORT+BROWSERINFO+some other)on the fly(During onboard) the browser  remember till it POST the credential back to controller for radius authentication.

>Since those tiny browsers are  not capable to do this, Some times you have hard time to Successfully design BYOD Onboard.