I have implemented an EAP-SIM enabled AP using Mikrotik ROS 4.x. I have noticed a few points i’d like to share with you and ask for comment from MT staff.
test system : RB493AH running ROS 4.16
1 : It just works, almost out of the box
The main configuration is in the radius server, the MK AP is just relaying the EAP messages to the radius server. Really easy to set up 
2 : The MK radius client, some headaches
It appears that when you use /radius for a service=wireless the options and customisations are pretty poor.
This causes problem mainly for Accountig setup. We have noticed that most of the accounting fields are empty and are impossible to customize. The standard /ip hotspot allows a lot more customisation here.
Here’s what we get in the radacct table from the MK AP
radacctid: 27054188
acctsessionid: 82b00248
acctuniqueid: 8b5f181e304b0a70
username:
groupname:
realm:
nasipaddress: 192.168.1.253
nasportid:
nasporttype:
acctstarttime: 2011-02-04 19:31:58
acctstoptime: 2011-02-04 19:33:50
acctsessiontime: 112
acctauthentic: RADIUS
connectinfo_start:
connectinfo_stop:
acctinputoctets: 7258
acctoutputoctets: 213
calledstationid:
callingstationid:
acctterminatecause: Lost-Service
servicetype: Framed-User
framedprotocol:
framedipaddress:
acctstartdelay: 0
acctstopdelay: 0
xascendsessionsvrkey:
NasIdentifier: sw-devcon-02
WISPrLocationID:
WISPrLocationName:
AcctOutputPackets: 6
AcctInputPackets: 42
We would like to be able to send to the accounting server at least the following fields, with customisation suitable for our server setup :
User-Name
Realm
Nas-Port-Type
Called-Station-Id
Calling-Station-Id
Framed-Protocol
Framed-Ip-Address (which have to be recuperated after authentication as far as the client doesn’t have an IP address before sucessfull authentication)
WISPrLocationId
WISPrLocationName
The idea here is to be able, as for /ppp or /ip hotspot, to do more fine tuning in radius fields behaviour in an EAP / 802.1x context.
3: Support additional recommendations from RFC 2865 - Radius
After the authentication dialog we send back the User-Name to the client in an Access-Accept radius packet. RouterOS doesn’t use the User-Name returned by the radius server.
The Radius RFC mentions :
RFC 2865 - RADIUS, 5.1 User-Name :
«It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session.»
Even if the current implementation respects the RFC (MAY/SHOULD) it brings some issues in our 802.1x/EAP-SIM implemetation context.
The user uses a TIMSI for authentication most of the time. To sum up it is a token which is renewed on every successfull authentication. The TIMSI is used as radius User-Name in the following form : TIMSI@3GPP_realm.
In the Access-Accept we send the permanent User-Name back to the client in order to set up the accounting correctly.
This doesn’t work on RouterOS as far as the User-Name returned by the radius in the Access-Accept is not taken into count.
This is a real issue for our setup.
4: Support for RFC 3580 IEEE 802.1x tunneling
(may be implemented in ROS, haven’t find how to setup this)
As described in RFC 3580, paragraph 3.31 - Tunnel attributes, it would be great to be able to affect a user to a vlan depending on authentication result.
This would allow us to handle per vlan differenciated service levels, configuration, etc.
5: conclusion and questions
The wpa-entreprise/802.1x/EAP setup is really easy to setup on MK but it’s hard to consider it entreprise grade on a large scale as far as it mainly lacks the possibility to fine tune the radius attributes.
Do you plan to implement some of the points exposed above in a future ROS releases ?
Have a great day