Update Needed
This page needs to be updated
The TOS changed recently, although SOWN is compliant to them, this document is slightly out of date
SOWN doesn't peer directly with the JRS NRPS, however as we offer eduroam authentication, we do endeavour to adhere to all its prerequisites. This is a case study regarding what services we provide and the considerations undertaken when peering with ECS Radius.
Contents |
3. Participants must designate a technical contact who can be contacted using
e-mail and telephone during normal business hours. The contact may be either
a named individual or an organisational unit. Arrangements must be made to
cover for absence owing to eventualities such as illness and holidays.
SOWN can be contacted directly by ECS and or via any of the committee lists. Details of who is available for direct support within SOWN can be provided on request.
4. Every log entry must state the date and time it was logged. 5. Logs must be kept for at least three months, and for no longer than six months.
SOWN keeps Packet logs for 93 days and database logs for 180 days Times+dates are included in this data.
6. Participants’ RADIUS (Remote Authentication Dial In Service) clients and servers
must comply with RFC 2865 and RFC 2866.
SOWN uses FreeRadius and/or Radiator as its RADIUS server. Nodes run Hostapd. All of these claim to be compliant with RFC 2866.
7. Participants’ RADIUS clients’ and servers’ clocks must be configured to
synchronise regularly with a reliable time source.
SOWN radius servers synchronize with ECS stratum 2 time servers which obtain their time from ECS gps time server and are peered with ISS stratum 2 servers which obtain their time from JANET stratum 1 time servers.
8. Participants must deploy at least one ORPS (organisational RADIUS proxy server).
SOWN Peers directly with ECS Radius servers as its uplink to the eduroam and JRS service. Southampton ISS servers provide ORPS servers for University of Southampton accounts. SOWN operates local ORPS for SOWN community accounts. This is not reciprocle as SOWN community accounts are non-academic in nature.
9. Participants’ ORPSs must be reachable from the JRS National RADIUS Proxy Servers
(NRPS) on either UDP/1812 and UDP/1813 (recommended), or UDP/1645 and UDP/1646
(if required by the participating Organisation).
SOWN Radius servers are all accessible on UDP 1812/1813
10. Participants’ ORPSs must respond to Internet Control Message Protocol (ICMP)
Echo Requests sent by the NRPS.
All SOWN servers are responsive internally, and externally, to ICMP. SOWN servers all respond to external and internal ICMP both from NRPS and Southampton ORPS.
11. Participants’ ORPSs must log all RADIUS authentication requests exchanged with
the NRPS; the following information must be recorded.
11.1. The value of the user name attribute in the request.
11.2. The value of the Calling-Station-Id attribute in the request.
As Part of ISS compliance with JRS, it will log the above for its uplink with NRPS. SOWN will log all requests which are forwarded to ECS Radius for the specified times.
12. Participants must log all RADIUS accounting requests exchanged with the NRPS;
the following information must be recorded.
12.1. The value of the user name attribute in the request.
12.2. The value of the accounting session identifier.
12.3. The value of the request’s accounting status type.
Similar to R11.
The larger portion of this section is not required of SOWN, as SOWN Radius servers are solely used for authenticating SOWN community accounts, which are non-academic in nature. The points have been considered and SOWN is compliant with all the requirements in case there is a change of policy, and/or if JRS ever decide to venture into provision of community accounts.
13. Home organisations’ JRS user names must conform to the Network Access
Identifier (NAI) specification (RFC 4282 [8]).
SOWN usernames take form [:alnum:]{3,8}@sown.org.uk which is compliant with RFC 4284
14. The realm component must conclude with participant’s realm name, which
must be a domain name in the global Domain Name System (DNS) that the
recipient organisation administers, either directly or by delegation.
SOWN controls sown.org.uk, and any pertinant ecs.soton.ac.uk hosts are delegated on request of ECS hostmaster.
15. Home organisations must log all authentication attempts; the following
information must be recorded.
15.1. The time that the authentication request was received.
15.2. The authentication result returned by the authentication database.
15.3. The reason given, if any, if the authentication was denied or failed.
SOWN logs all authentication traffic. See appendix for details.
4. Home organisations may configure their RADIUS server to authenticate
Password Authentication Protocol (PAP).
SOWN implements PAP authentication on its users' accounts.
16. Home organisations must configure their RADIUS server to authenticate one or
more Extensible Authentication Protocol (EAP) types.
16.1. Home organisations must select a type, or types, for which their
RADIUS server will generate symmetric keying material for encryption
ciphers and encapsulate the keys, following section 3.16 of RFC 3580,
within RADIUS Access-Accept packets.
SOWN authenticates EAP-TTLS with PAP and EAP-PEAP with GTC. Current investigations include the possibility of using further methods.
17. Home organisations must create an authenticatable test account.
17.1. The test account must be able to authenticate PAP and the EAP type(s)
selected by the participant.
17.2. JRS Support must always be informed immediately if the password for
this account is changed. However, if it is believed that the password
has been compromised then the password must be changed immediately
and JRS Support informed as soon as possible.
SOWN has a test account, details of which can be provided on request by any compitent and pertinent authority. Provisioning of security will be the responsibility of the technical contact. The test account will validate with all supported and required authentication methods.
18. Home organisations must educate their users to validate the certificate presented
by a WRD NAS.
SOWN accounts will never normally be validated against another JRS member's login system as they are non-academic. ECS and ISS are responsible for the administration of their peering arrangements, and would implement this requirement.
| Settings | IEEE properties | ||||||
|---|---|---|---|---|---|---|---|
| Tier | NAS | IPv6 | NAT | WEP | WPA | WPA2 | SSIDs |
| JRS1 | WRD | MAY | MAY | N/A | N/A | N/A | eduroam / eduroam-web |
| JRS2 | 802.1x | MAY | MAY | Must (one or both) | MAY | eduroam / optionally eduroam-wep | |
| JRS3 | 802.1x | MUST | MUST NOT | MUST NOT | MAY | MAY | eduroam |
19. Visited organisations must implement at least one of the JRS1,
JRS2 or JRS3 tiers.
SOWN will comply with most of JRS3 and all of JRS2 and JRS1 (we do not have globally routable address space for each node, subsequently it is dependant on NAT).
20. Visited organisations must ensure that a non-JRS service cannot be
mistaken by visitors for the participant’s JRS service.
21. The ‘eduroam’ prefix is reserved for SSIDs used with the JRS service tiers.
ISS and ECS have strict naming conventions for node naming. SOWN complies with these at all times. SOWN nodes are deployed far and wide, and due to that it is possible for members of the public to mis-name their nodes which is beyond the control of any establishment. Within campus, both ISS and ECS take immediate measures to hunt down and disable rogue nodes. SOWN undertakes to ensure that none of its documentation can mislead its eduroam users.
22. Visited organisations must implement a separate VLAN for each tier that they
choose to implement. A tier’s VLAN must not be shared with any other tier or network
service.
SOWN allocates seperate subnets for each tier of service it offers (in our implementation, Tier 1 is part of our centralised login, Tier 2 are on seperate virtual interfaces on our node each allocated to a seperate private ipv4/24 address block).
23. Visited organisations that provide access to a JRS tier for local users, or visitors
from organisations not participating in the JRS, must ensure that the user has read
and agreed to both the JRS Policy and the local AUP.
SOWN's AUP is conditional on accepting ECS, Soton ISS and Janet's roaming AUP. Links are provided to all three on our public website.
24. Visited organisations must not offer visitors any wireless media other than IEEE
802.11.
SOWN only offers 802.11 media, as do both ECS and ISS.
25. Visited organisations must forward RADIUS requests originating from JRS Network
Access Servers (NASs) and containing user names with unknown realms via an ORPS
to an NRPS.
25.1. RADIUS Access-Requests must be addressed to UDP/1812.
25.2. RADIUS Accounting-Requests must be addressed to UDP/1813.
SOWN directly peers with ECS Radius. See additional configuration for forwarding details. The SOWN ORPS communicates on UDP ports as specified.
26. Visited organisations may configure additional realms to forward requests to other
internal RADIUS servers, but these realms must not be derived from any domain in
the global DNS that the participant does not administer.
SOWN internal domains are only taken from space that it administers.
27. Visited organisations may configure additional realms to forward requests to external
RADIUS servers in other organisations, but these realms must be derived from domains
in the global DNS that the recipient organisation administers (either directly, or by
delegation).
SOWN's only point of peering is with the ECS Radius server.
28. Visited organisations must not otherwise forward requests to other JRS participants.
cf 27.
29. Visited organisations must deploy NASs that include the following RADIUS
attributes within Access-Request packets.
29.1. The supplicant’s MAC address within the Caller-Station-ID attribute.
29.2. The NAS’s IP address within the NAS-IP-Address attribute.
See specific configuration for details, However SOWN does pass this information.
30. Visited organisations may implement IPv4 and IPv6 filtering between the
visitor VLAN and other external networks, providing that this permits the
forwarding of the following protocols.
30.1. IPv6 Tunnel Broker NAT traversal: UDP/3653 and TCP/3653 egress
and established.
30.2. IPSec NAT traversal: UDP/4500 egress and established.
30.3. Cisco IPSec NAT traversal: TCP/10000 egress and established.
30.4. PPTP: IP protocol 47 (GRE) egress and established; TCP/1723
egress and established.
30.5. OpenVPN: TCP/5000 egress and established.
30.6. SSH: TCP/22 egress and established.
30.7. HTTP: TCP/80 egress and established.
30.8. HTTPS: TCP/443 egress and established.
30.9. LDAP: TCP/389 egress and established.
30.10. LDAPS: TCP/636 egress and established.
30.11. IMSP: TCP/406 egress and established.
30.12. IMAP4: TCP/143 egress and established.
30.13. IMAP3: TCP/220 egress and established.
30.14. IMAPS: TCP/993 egress and established.
30.15. POP: TCP/110 egress and established.
30.16. POP3S: TCP/995 egress and established.
30.17. Passive (S)FTP: TCP/21 egress and established.
30.18. SMTPS: TCP/465 egress and established.
30.19. Message submission: TCP/587 egress and established.
30.20. RDP: TCP/3389 egress and established.
30.21. VNC: TCP/5900 egress and established.
30.22. Citrix: TCP/1494 egress and established.
SOWN ipv6/ipv4 outbound traffic filter will not affect these ports beyond the requirement to establish QOS.
31. Visited organisations deploying application or ‘interception’ proxies
on the visitor LAN must publish this fact on their JRS website.
32. If an application proxy is not transparent, the Visited organisation
must also provide documentation on the configuration of applications
to use the proxy.
SOWN does not use any proxy devices. It is occassionally possible that some ISPs may do some form of transparent or opaque proxying that we have no knowledge or control of. Node deployment agreements prohibit intrusive proxies from intercepting application data on the part of the Node Host.
33. Visited organisations must publish a JRS website which must be generally accessible
from the Internet and within the organisation to allow visitors to access it easily.
The website must include the following information at a minimum.
33.1. The participant’s acceptable use policy (AUP).
33.2. Sufficient information to enable visitors to identify and access the service;
at a minimum this must include the locations covered, the JRS Tier(s),
and SSIDs.
33.3. Where applicable, the information specified in section 4.6
regarding application and interception proxies.
SOWN provides information on its public website, internal network about its AUP which is easilly accessible. The ISS AUP is published on the JRS site.
34. A broadcast SSID of ‘eduroam’ must always be used for JRS wireless services, except in
the following circumstances.
34.1. A broadcast SSID of ‘eduroam-wep’ may be used with WEP but only where
the ‘eduroam’ SSID is required by another JRS wireless service.
34.2. A broadcast SSID of ‘eduroam-web’ may be used with WRD but only where
the ‘eduroam’ SSID is required by another JRS wireless service.
SOWN will use upto all three SSIDs on any given node, depending on individual configuration.
35. The JRS1 tier must only implement WRD NASs.
36. WRD NASs must support RADIUS PAP authentication.
37. WRD NASs must support Secure Sockets Layer (SSL) or Transport Layer Security (TLS)
protection of the authentication transaction with the visitor’s client, and be
configured to present visitors with a server certificate from a well-known certificate
authority.
SOWN JRS1 tier NASs only implement WRD. These will be in the minority as 802.1x is implemented. Captive portal is secured by SSL. It is hosted on sown-auth.ecs.soton.ac.uk and certificated by the University of Southampton's well known certificate authority. It should be noted that All SOWN nodes provide [SOWN]-HOME ssid which is captive portal based. These are in addition to any eduroam SSIDs.
38. The JRS2 and JRS3 tiers must only implement IEEE 802.1X; no form of WRD is permitted.
39. IEEE 802.1X [23] NASs must support symmetric keying using keys provided by the Home
organisation within the RADIUS Access-Accept packet, in accordance with section 3.16
of RFC 3580.
40. Only a single user is permitted per NAS port.
cf Section 2.
41. The JRS3 tier does not allow the use of NAT. 42. The JRS3 tier must allow routing of IPv6 on the visitor VLAN.
SOWN does not provide JRS3.
43. Visited organisations must allocate IPv4 addresses to visitors using DHCP.
44. Visited organisations must log the IPv4 addresses allocated to visitors and the
corresponding MAC addresses.
45. Visited organisations must log NAT address mappings, if used.
SOWN uses dnsmasq to provide DHCP addresses An example dnsmasq script for a wireless node using 3 atheros interfaces (one ath0: SOWN ath1: eduroam-wep ath2 eduroam (wpa))
dhcp-script=/bin/dhcp-event dhcp-leasefile=/var/log/dnsmasq.leases dhcp-range=ath0,10.13.158.1,10.13.158.253,1h dhcp-range=ath1,10.13.165.1,10.13.165.253,1h dhcp-range=ath2,10.13.167.1,10.13.167.253,1h domain=sown.org.uk
All translations mappings are logged via dhcp-event script (a convenient side effect).
46. The JRS2 tier may implement WEP; if it does not, it must implement WPA.
SOWN may implement WEP on certain access points dependant on hardware. Otherwise WPA/WPA2 will be provided.
47. The JRS3 tiers must not implement WEP.
SOWN does not provide JRS3.
48. Visited organisations that choose to deploy WEP must configure their WAPs to require
the use of 128-bit keys, and to rotate these keys every five minutes.
SOWN is configured to do this. Example hostapd.conf:
interface=ath2 driver=madwifi logger_syslog=-1 logger_syslog_level=1 logger_stdout=0 logger_stdout_level=0 debug=0 dump_file=/tmp/hostapd.ath2.dump ssid=eduroam-wep ieee8021x=1 wep_key_len_broadcast=13 wep_key_len_unicast=13 eapol_key_index_workaround=1 own_ip_addr=10.13.128.114 nas_identifier=node258.sown.org.uk auth_server_addr=10.13.0.252 auth_server_port=1812