From SOWNWiki
Jump to: navigation, search


Update Needed
This page needs to be updated

Need to check compliance of all points. It is likely the compliance doument has been updated since this was last checked.

SOWN is now peered directly with the eduroam(UK) NRPS and our service complies with the base level engineering standards. This is a case study regarding what services we provide and the considerations undertaken with regards to our peering. The requirements listed here are all taken from the eduroam(UK) Technical Specification, Version 1.2

Common Requirements and Recommendations (2)

Technical Contact (2.2)

4.     Participants MUST designate a technical contact that 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 of a named technical contact owing to eventualities such as illness and

SOWN can be contacted directly via ECS and/or via our contact form. Details of who is available for direct support within SOWN can be provided on request.

Logging (2.3)

5.     Every log entry MUST state the date and time it was logged, derived from a
       reliable time source. The timestamp MUST be in GMT.
6.     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 and dates are included in this data.

RADIUS Hosts (2.4)

7.     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.

8.     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 the ECS GPS controlled time server and are peered with ISS stratum 2 servers which obtain their time from JANET stratum 1 time servers.

9.     Participants MUST deploy at least one ORPS (organisational RADIUS proxy

SOWN operates a local ORPS for SOWN community accounts. In addition, SOWN peers with ECS RADIUS servers which is in turn peered with the University of Southampton RADIUS servers, which provide ORPS services for ECS and University of Southampton users respectively.

10.    Participants’ ORPSs MUST be reachable from the eduroam(UK) RADIUS Proxy
       Servers (NRPS) on either port UDP/1812 and port UDP/1813 (recommended), or
       port UDP/1645 and port UDP/1646 (if required by the participating Organisation).
       ORPS using RadSec MUST be reachable from the NRPSs on TCP port 2083.

SOWN RADIUS servers are NOT currently accessible, pending further configuration. Once complete, they will be available on UDP ports 1812 and 1813.

11.    Participants using RadSec MUST use X.509 certificates provided by the
       GÉANT eduPKI service to identify their ORPSs.
12.    If the ORPS's RADIUS implementations support it, both the NRPS and eduroam(UK)
       Support Server MUST be able to receive responses to Internet Control
       Message Protocol (ICMP) Echo Requests they send to participants' ORPSs.

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.

13.    The following RADIUS attributes MUST be forwarded by participants’ ORPSs if
       present in RADIUS Access-Request, Access-Challenge, Access-Accept or
       Access-Reject messages.
       13.1.    User-Name
       13.2.    Reply-Message
       13.3.    State
       13.4.    Class
       13.5.    Message-Authenticator
       13.6.    Proxy-State
       13.7.    EAP-Message
       13.8.    MS-MPPE-Send-Key
       13.9.    MS-MPPE-Recv-Key
       13.10.   Calling-Station-Id
       13.11.   Operator-Name
       13.12.   Chargeable-User-Identity

This has not yet been reviewed, but is believed to be true.

14.    The following RADIUS attributes MUST be forwarded by participants’ ORPSs if
       present in RADIUS Accounting messages.
       13.1.    User-Name
       13.2.    Acct-Status-Type
       13.3.    Acct-Session-ID
       13.4.    Proxy-State
       13.5.    Class

This has not yet been reviewed, but is believed to be true.

15.    Participants’ ORPSs MUST log all RADIUS authentication requests exchanged
       with the NRPS; the following information must be recorded.
       15.1.    The value of the user name attribute in the request.
       15.2.    The value of the Calling-Station-Id attribute in the request.

This has not yet been reviewed.

16.    Participants MUST log all RADIUS accounting requests exchanged with the
       NRPS; the following information must be recorded.
       16.1.    The value of the user name attribute in the request.
       16.2.    The value of the accounting session identifier.
       16.3.    The value of the request’s accounting status type.

This has not yet been reviewed.

eduroam Service Information Website (2.5)

17.    Participants MUST publish an eduroam service information website which must
       be generally accessible from the Internet and, if applicable, within the organisation
       to allow visitors to access it easily on site. The website MUST include the following
       information as a minimum.
       17.1.   The text of, or a link to, the participant’s acceptable use policy (AUP),
               where applicable.
       17.2.   A link to the eduroam(UK) Policy.
       17.3.   The eduroam logo linking to the website.
       17.4.   The type of service offered where the scope of the eduroam service is
               limited, such as Visited-only or Home-only; and the operational
               status of the service if the web page is published before the service
               becomes operational.
       17.5.   A link to the eduroam(UK) sites listing and location web page.

Our eduroam web page needs to be updated to fulfil this role.

Home Organisation Requirements and Recommendations (3)

SOWN currently acts solely as a Visited Organisation, and as such, compliance with this section is not yet required of SOWN. The points have been considered and SOWN is compliant with all the requirements in case SOWN becomes a Home Organisation in the future.

User Names (3.1)

Home organisations’ eduroam user names MUST conform to the Network Access Identifier (NAI) specification (RFC 4282 [13]), i.e. comprise identity name @ and realm components.

18.    Home organisations’ eduroam user names MUST conform to the Network
       Access Identifier (NAI) specification (RFC 4282), i.e. comprise identity name
       @ and realm components.

SOWN usernames take form [A-Za-z0-9_.-]{1,20} which is compliant with RFC 4282.

19.    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 
       Home organisation administers, either directly or by delegation.

SOWN controls, and any pertinant hosts are delegated on request of ECS hostmaster.

Logging (3.2)

20.    Home organisations MUST log all authentication attempts; the following 
       information MUST be recorded.
       20.1.    The time that the authentication request was received.
       20.2.    The authentication result returned by the authentication database.
       20.3.    The reason given, if any, if the authentication was denied or failed.
       20.4.    User-ID in the outer-EAP and the User-ID from the inner-EAP
               (if a tunnelled EAP method is used).
       20.5.    Chargeable-User-Identity (CUI) if one was generated.
       20.6.    Calling-Station-ID.

SOWN logs all authentication traffic. See appendix for details.

EAP Authentication (3.3)

21.    Home organisations MUST configure their RADIUS server to authenticate one or
       more Extensible Authentication Protocol (EAP) types.
22.    Home organisations MUST select an EAP type, or EAP 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.

Test Account (3.4)

23.    Home organisations MUST create an authenticatable test account. If the Home
       organisation has chosen to support PEAP or TTLS type methods, these MUST
       be supported by the test account, else PAP may be used.
24.    eduroam Support MUST 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 eduroam(UK)
       Service Roaming 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.

User Security Awareness (3.5)

There are no requirements in this subsection.

RADIUS Hosts (3.6)

25.    Home organisations MUST attempt to authenticate all authentication requests forwarded from the NRPS.

Visited Organisation Requirements and Recommendations (4)

Network Presentation (4.1)

26.    Visited organisations MUST implement the base level engineering standards
       defined in this specification.

SOWN complies with the base level engineering standards.

27.    Visited organisations MUST ensure that is not possible for a non-eduroam service
       to be mistaken by visitors for the participant’s eduroam service.
28.    The word ‘eduroam’ MUST NOT be used in an SSID for a non-compliant network.

iSolutions 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 iSolutions 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.

29.    Visited organisations' eduroam networks MUST NOT be shared with any other network service.

SOWN allocates a subnet to each node. This subnet it not shared with any other network service.

30.    Visited organisations that provide access to eduroam for local users, or visitors
       from organisations not participating in eduroam, MUST ensure that the user has
       read and agreed to the eduroam(UK) Policy.

SOWN's AUP is conditional on accepting ECS, iSolutions and the eduroam(UK) AUP. Links are provided to all three on our public website.

31.    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 iSolutions.

RADIUS Forwarding (4.2)

32.    Visited organisations MUST forward RADIUS requests originating from eduroam
       Network Access Servers (NASs) which contain user names with non-local realms
       to a NRPS via an ORPS.
       31.1.    RADIUS Access-Requests must be sent to port UDP/1812.
       31.2. Access-Requests using RadSec MUST be sent to port TCP/2083.
       31.3.    RADIUS Accounting-Requests must be addressed to port UDP/1813.
       31.4. Accounting-Requests using RadSec MUST be sent to port TCP/2083.

It needs to be confirmed that the SOWN ORPS communicates on the UDP ports as specified.

33.    Visited organisations MUST NOT forward RADIUS requests containing user
       names which do not include a realm nor any which are non-NAI compliant..

This needs to be checked.

34.    Visited organisations MUST NOT forward requests that have originated from
       NASs that do not conform with the requirements of this specification.

This needs to be checked.

35.    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.

36.    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 participating organisation
       administers (either directly, or by delegation).
37.    Visited organisations MUST NOT otherwise forward requests to other eduroam

This needs to be checked following our recent (Oct 2010) changes.

NAS Requirements (4.3)

38.    NASs MUST implement IEEE 802.1X authentication.

The SOWN NASs implement this standard.

39.    On receipt of a RADIUS Access-Accept, the NAS and network MUST
       immediately forward traffic to, and from, the visitor according to the requirements
       set out in section 4.5; no form of local authorisation is permitted that would deny
       this to the visitor except in the case where network abuse has been detected.

SOWN does not use any form of local authorisation.

40.    Wireless IEEE 802.11 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.

MSCHAPv2 uses symmetric keys, transfered in the MPPE fields of the RADIUS message. MSCHAPv2 works on sown, so SOWN meets this requirement.

41.    A NAS port MUST NOT connect more than one user unless the NAS is not capable
       of being configured other than to use the same port for the connection of multiple
       users and the NAS maintains client traffic separation by other means.

This needs to be checked, but is believed to be true. All NASs that are deployed by Visited organisations to support eduroam MUST include the following RADIUS attributes within Access-Request packets.

42.    All NASs that are deployed by Visited organisations to support eduroam
       MUST include the following RADIUS attributes within Access-Request packets.
       42.1.    Calling-Station-ID attribute containing the supplicant’s MAC address.
       42.2.    NAS-IP-Address attribute containing the NAS’s IP address.

See specific configuration for details, However SOWN does pass this information.

IP Filtering (4.5)

43.    Visited organisations MAY implement IPv4 and IPv6 filtering between the visitor
       network and other external networks, providing that this permits the forwarding of
       the following mandatory protocols.
       43.1.    IPv6 Tunnel Broker NAT traversal: UDP/3653; TCP/3653 egress and
       43.2     IPv6 Tunnel Broker Service: IP protocol 41 egress and established.
       43.3.    IPSec NAT traversal: UDP/4500 egress and established.
       43.4.    Cisco IPSec NAT traversal: UDP/10000; TCP/10000 egress and
       43.5.    PPTP: IP protocol 47 (GRE) egress and established; TCP/1723 
                egress and established.
       43.6.    OpenVPN: UDP/1194; TCP/1194 egress and established.
       43.7.    NTP: UDP/123 egress and established.
       43.8.    SSH: TCP/22 egress and established.
       43.9.    HTTP: TCP/80 egress and established.
       43.10.   HTTPS: TCP/443 egress and established.
       43.11.   LDAP: TCP/389 egress and established.
       43.12.   LDAPS: TCP/636 egress and established.
       43.13.   IMSP: TCP/406 egress and established.
       43.14.   IMAP4: TCP/143 egress and established.
       43.15.   IMAP3: TCP/220 egress and established.
       43.16.   IMAPS: TCP/993 egress and established.
       43.17.   POP: TCP/110 egress and established.
       43.18.   POP3S: TCP/995 egress and established.
       43.19.   Passive (S)FTP: TCP/21 egress and established.
       43.20.   SMTPS: TCP/465 egress and established.
       43.21.   Message submission: TCP/587 egress and established.
       43.22.   RDP: TCP/3389 egress and established.
       43.23.   VNC: TCP/5900 egress and established.
       43.24.   Citrix: TCP/1494 egress and established.
       43.25.   AFS: UDP/7000 through UDP/7007 inclusive egress and established.
       43.26.   ESP: IP protocol 50 egress and established
       43.27.   AH: IP protocol 51 egress and established
       43.28.   ISAKMP: and IKE: UDP/500 egress
       43.29.   SQUID Proxy: TCP/3128 egress and established
       43.30.   HTTP Proxy: TCP/8080 egress and established

SOWN's IPv6/IPv4 outbound traffic filter will not affect these ports beyond the requirement to establish QOS. Need to check this for 43.2, 43.26, 43.27, 43.28, 43.29 and 43.30.

Application and Interception Proxies (4.6)

44.    Visited organisations deploying application or ‘interception’ proxies on the visitor
       network MUST publish this fact on their eduroam service information website.
45.    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.

eduroam Service Information Website (4.7)

46.    In addition to the requirements detailed in section 2.5, Visited organisations’
       eduroam service information websites MUST state:
       46.1.    Sufficient information to enable visitors to identify and access the
                service; at a minimum this must include the locations covered.
       46.2.    Where applicable, the information specified in section 4.6 regarding
                application and interception proxies.

SOWN provides a map of the locations of its access points, and this map is linked to from its eduroam page.

SSIDs (4.8)

47.    A broadcast SSID of ‘eduroam’ in lower case characters only MUST be used for
       operational eduroam wireless network services as described in this specification.
48.    Organisations that are in the process of developing Home or Visited services
       but are not yet offering operational services MUST limit broadcast of the ‘eduroam’
       SSID to small development environments.

SOWN uses a broadcast SSID of 'eduroam' on its nodes.

Network Addressing (4.9)

49.    eduroam networks MAY make use of NAT.
50.    Visited organisations MUST allocate IPv4 addresses to visitors using DHCP.
51.    Visited organisations MUST log the IPv4 addresses allocated to visitors and the
       corresponding MAC addresses.
52.    Visited organisations MUST log NAT address mappings, if NAT is used as part
       of an eduroam implementation.

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))


All translations mappings are logged via dhcp-event script (a convenient side effect).

WPA (4.10)

53.    Existing eduroam deployments MAY provide WPA with the use of the TKIP algorithm
       until the end of December 2014.

This needs to be checked.

WPA2 (4.11)

54.    Visited organisations’ eduroam networks MUST implement WPA2 with the use of the CCMP
       (AES) algorithm. New organisations joining eduroam MUST only implement WPA2/AES.

This needs to be checked.

... more about "Eduroam/compliance"
Need to check compliance of all points. It is likely the compliance doument has been updated since this was last checked. +