eduroam(UK) Technical Specification - Beyond v1.3

The purpose of this document is to call for ideas from the community and to provide space for contributions towards development of the eduroam(UK) Technical Specification beyond the current 1.3 which was released in June 2013. In the last 2 and a half years a number of issues have arisen and technical evolution has taken place. Version 1.4 will incorporate relatively minor updates that have been identified, but we are still open to suggestions for change. It is planned to release 1.4 during Q1 of 2016.

A major reworking of the specification to incorporate RadSec awaits implementation and field testing of technical advances into RADIUS products so we are looking at a 2-year timeframe for the release of v2.0.

The changes introduced in v.1.2 from 1.1 were described in https://community.ja.net/groups/dot1x-sig/document/eduroamuk-tech-spec-12-changes-v11

The changes introduced in v1.3 from 1,2 were described in a similar document!

This is a 'straw man' document. Contributution of ideas is welcomed - please add below.

For version 1.4

Housekeeping

Changes to references to 'Janet' necessitated by organisational change from Janet to Jisc.

All references to ‘Janet’ in an organisational context changed to ‘Jisc’; references to Janet in the context of the network and network-related documentation remain unaltered.  Done

Removal of no longer relevant material

Removal of residual references to JRS tiers in the introducory paragraph of section 4.  Done

Clarification of responsibility of participants to declare and keep up to date service level and compliance assertions

Further to the tidying up of section 4 introduction, the requirement for participating organisations to assert the operational service level of their services has been formalised via new mandatory requirement:

"4. Using the eduroam(UK) Support web portal, Participating organisations MUST assert the type of service being provided or being worked towards and the current level of compliance of such a service with this Technical Specification. The current operational level of the service MUST also be asserted."   Done

Reference to 'GMT' to be changed to the more correct 'UTC' term

Applies to requirement 5. Done

Clarification of requirements

Requirement 19: reference to ‘User ID’ changed to ‘User-Name’ to clarify need for all parts of  the user name to be logged. Done

Alignment of logging requirements with recommended best practice Operator-Name injection

New requirement 19.7 needed to require logging of Operator-Name if one was present in Access-Request. Done

Requirements relating to Test Account

Evolution of the Support Server monitoring system has resulted in only PEAP and TTLS methods being supported in the Nagios system on the Support server. PAP is no longer supported in the Nagios system although it is still available as an on-demand test. Therefore the mandatory requirement for the test account to support PAP can be dropped and the requirement reworded to align with current capability of the Support server.  Done

Password administration for the test account is now managed through the Support server with no manual involvement by the eduroam(UK) Support team. The wording in relation to advising eduroam(UK) of changes to the password and the actions to be taken in the event of suspected compromise of the test user account password therefore needs to be brought into line with current practice.  Done

New requirement necessitated by introduction of Status-Server monitor system on HRPS

New requirement 39 needed: the setting on the Support server web portal to enable Status-Server requests sending from the NRPS to an ORPS MUST NOT be enabled if the ORPS cannot correctly respond to such requests.  Done

New recommendations needed relating to utilisation of and response to Status-Server queries if ORPS have such capability. Done

Updates needed to reflect internet connectivity can be provided by services other than Janet

Recommendation 4.5.2 updated to specify ‘the Internet’ rather than specifically ‘Janet’ since Visited services may be provided with network services providing access to the Internet other than via Janet.

SSID requirement needs clarification and discussion mentioning XP to be removed.

Done

RADIUS Hosts section updates

Chargeable User Identity response recommendation needs rewording to imporve readability.  Done

Discussion expanding on requirement that Home organisations must attempt to authentication all requests forwarded by the NRPS regardless of lack of attributes needs to include Service-Type in addition to NAS-Port-Type. Done

RADIUS Accounting to be dropped

References to accounting appear throughout the document. These will have to be comprehensively stripped out.

Requirement 10 to be revised to remove requirement for ORPS to be reachable on accounting ports UDP/1813 or UDP/1646 since NRPS no longer forward accounting requests to ORPS, and wording updated to more RFC conventional style. Done

Requirement 14 to be deleted because whilst the NRPS will continue to respond to accounting requests if forward to them, the content of the requests is not important as they are not forwarded onwards. Subsequent requirements numbering decremented by 1.  Done

Requirement 16 deleted because provided that the requirements relating to logging are satisfied, exactly how organisations do this is outside the scope of this specification. It is for the organisation to determine what logging of RADIUS accounting requests and attributes are appropriate.   Done

Discussion 2.4.3: paragraph 3, 4 and 6 edited to remove references to accounting ports (1813 and 1646) and accounting. New paragraph to be appended to explain reasoning behind deprecation of forwarding of accounting requests and notice of future mandatory requirement to not forward such requests to the NRPS.  Done

Requirement 32.3 and 32.4 to be deleted since requirements relating to accounting packet forwarding are being removed form the specification.

Need to clarify that TLS/SSL interception proxies, sucha s require a visitor to install a local visited sites CA certificate are not permitted on Visitor network services.

New requirement needed: Transport Layer Security (TLS)/Secure Sockets Layer (SSL) interception proxies MUST NOT be applied to network services for eduroam visitors.  Done

Discussion section to emphasis the security flaw this represents whilst saying that this restriction does not apply to the network that users at their Home site may be connected to. Done, but could be expanded on.

Updates necessitated by expiry of concession for legacy TKIP to be supported

Base level engineering standards table is updated and redunant text removed

Version 1.3 allowed mixed TKIP/AES deployments for services implemented prior to 2012, but 2012 and onwards implementations could only support WPA2/AES. The base level engineering standards table is updated to 'MUST NOT' support WPA/TKIP. Text relating to WPA/TKIP has been deleted from the introductory paragraph.   Done

Section 4.10 updates

Requirement 55 reworded to explicitly disallow WPA and TKIP.   Done

Recommendation paragragh 4.10.2 and Recommendation 22 removed as no longer applicable.    Done

Discussion paragraph 4.10.2 removed since text on WPA and the transition period no longer relevant.  Done

Discussion 4.11.2 altered to reflect specification that WPA2/AES is the only standard and cipher permitted in the UK, although noting that in some countries mixed TKIP/AES environments may be encountered.    Done

Requirement 55 worded to improve reability and clarity.  Done

IPv6

Use of IP6 to be uprated to MAY rather than SHOULD - base engineering standard table to be updated.  Done

Discussion 4.9.4 is out of date and need refreshing.  Done

Particpating organisations using IPv6 transit - communication to the NRPS must be native - no 6in4/TEREDO access via dynamic addresses permitted.

ICMPv6

Sites should pay attention to RFC4890 when configuring filtering of ICMPv6, the following types should be permitted:

                - Destination Unreachable (Type 1) - All codes

                - Packet Too Big (Type 2)

                - Time Exceeded (Type 3) - Code 0 only

                - Parameter Problem (Type 4) - Codes 1 and 2 only

                - Echo Request (Type 128)

                - Echo Reply (Type 129)

Use of eduroam VSAs

This could be quite a big topic, affecting Home and Visited sites.

Obviously the attributes that must NOT be filtered in the Common Requirements, RADIUS Hosts section, would need to include the specific attribute names or a more generic 'all eduroam specifi VSAs published at xxxx'

Recommendation to create NAPTR records in DNS

The creation of NAPTR records in DNS is to enable RADIUS/TLS over TCP (RadSec) to be utilised to pass authentication requests directly between the national proxies of NRENs, cutting out the European top level RADIUS servers, thus reducing the number of proxy hops and improving the performance of international authentications. 

Although this is relevant to Home IdP organisations since it benefits users roaming outside the UK, there is already a reference to RadSec under heading 2.4 in the Common Requirements and Recommendations chapter. It is proposed that a new heading 2.6 will be needed. A new recommendation needs to go under this heading since there is nothing about DNS in the Tech Spec. To enable the heading to be expanded in the future, it could be named 'Support for RadSec'.

Since eduroam Operations no longer configure tailored RADIUS routing on the top level European RADIUS servers such that non-country specific realms can be correctly routed, organisations wishing to use such realms have to set up NAPTR records to enable RADIUS routing lookups to be performed by the ETLRs and those FLRS which support RadSec. Therefore a new mandatory requirement will be added to cover this scenario.

Ports/protocols that MUST be open on eduroam networks

Visited service IP forwarding: list of ports and protocols that must as a minimum be permitted updated to remove LDAP and POP.

Clarification of provision of eduroam credential for conference delegates/contractors (requiring adjustment of username format)

Clarification of web content filtering

Question: does this belong in 4.5.2 or in the application proxies section below IP forwarding?

Suggested text:

Visited organisations MAY implement web content filtering, but since this can impede research are discouraged from doing so.

OR

Visited organisations SHOULD NOT implement web content filtering unless policy requirements dictate it since its imposition may impede legitimate research, however they MAY do so.

For Discussion section:

A wider diversity of organisations are now participating in eduroam(UK). Some As a result of this the user base may now include young people and vulnerable adults. Network access policy at some of these organisations may require only granting access via content filtered networks despite the widespread availability of unrestricted Internet access via home broadband, Internet café, 3G/4G etc. Therefore organisations MAY implement web content filtering although this is discouraged.

 

Need to clarify that TLS/SSL interception proxies, sucha s require a visitor to install a local visited sites CA certificate are not permitted on Visitor network services.

Discussion section to emphasis the security flaw this represents whilst saying that this restriction does not apply to the network that users at their Home site may be connected to.

To Support single SSID

Create new requirement 31 that Visited participants MAY place local users onto non-eduroam LAN  

OR 

make this a Recommendation (11).

For Discussion section 4.1.3

Include explanation as to why it is permissible to place local users onto a non-complaint network (to access local resources that the organisation does not wish to make accessible to guests from other organisations)

The 'notifying client of reason for failure to connect' issue

"No matter how hard we try, eduroam will suffer unfair criticism for as long as we are unable to give the client a reason for failure."
 
In a huge number of cases the reason for failure is simply - wrong credentials!

It has been discussed at DOT1XSIG many times - how to inform the user why they've been access-denied. We need to can try to decide: i) what we what to do about this ii) how it could be achieved iii) any measures that we as Janet/the DOT1XSIG/the community could take

Would it be appropriate to create a reommendation: 

Recommendation

Since all recent RADIUS servers are able to send back details to clients reporting the reason for rejection... It is recommended that the reason for a rejection is returned to the client in the Access-Reject, e.g. account has expired, username is not recognised, password is incorrect. The RADIUS server may need some extra config for this -  but this is not an eduroam issue, this is an 802.1X issue

The 'expired accounts resulting in doomed auth attempts' problem
 
In order to begin to reduce the size of this problem, on idea might be to introduce yet another requirement in section 2.5 for participants' eduroam info web sites - for them to state that once users leave the organisation them must remove the eduroam profile from their devices.
 
Possible Recommendation
a)....and how to enforce this with the vast majority of users? it might be worth noting that the SU1X tool does have an 'uninstall' option which also removes the eduroam profile.... other deployment tools dont have that ...yet(!)

b) Home organisations might also be prpompted to think about having 'now that you're leaving us'
documents updated to say 'please remove the 'eduroam' configuration from your device (see the following web site for more info http://blahblah) and good luck with your future life and career' etc

Applying Control over Quantity of Authentication Re-try Requests

It has been noticed in the national proxy logs that there are instances of a huge number of EAP retries being generated as the result of a single client failing authentication. This creates a large amount of unnecessary load on the NRPS. Most NAS devices that have been deployed have configuations that control the amount of retries by having a limit set on the number of authentication requests that may be made by a single client in a given time.

This issue is applicable to Visited participants and so it is proposed to add a new requirement 43 into section 4.3.1 that some limit must be set.

OR

If it is considered that some NAS that have been deployed are not capable of being so configured, then this would be added as a recommendation. E.g. Recommendation 15 - NASs SHOULD be configured such that the number of EAP retries that a client failing authentication can cause to be generated is limited to....  suggestions invited

(10 per minute and no more than 20 retries in five minutes..?)

Responsiveness of Participant's Technical Contact to Requests from eduroam(UK)

Since a participating organisation's RADIUS deployment forms part of the fabric of the eduroam service and can potentially cause harm to the service nationally, there may be occasions requiring dialogue between the the operators of the eduroam(UK) infrastructure and the administator of the eduroam service at a participanting organisation. Such occasions may result from situations requiring immediate attention or may arise where longer standing issues must be addressed.

The designated technical contact at participants must be reasonably responsive to requests from the operators of the national infrastructure adn so it is proposed that requirement 4 is beefed up to require a response within 4 working hours. 

For Release 1.6

Ports/protocols that MUST be open on eduroam networks

ICMPv6 to be added to list of mandatory ports and protocols permitted

Nb, ICMP is NOT currently in the list (4.5.1 requirement 43). Should it be?

Review of ports/protocols to be carried out based on feedback received.

For Future Release 1.7

Changes for RadSec? (sites using RadSec may not need ANY UDP 1812 stuff at all - just pure RadSec(!) and some monitoring facility to report into a central eduroam(UK) stats engine)