idnits 2.17.1
draft-wierenga-ietf-eduroam-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (August 21, 2014) is 3535 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2866' is defined on line 1442, but no explicit
reference was found in the text
== Unused Reference: 'RFC4279' is defined on line 1448, but no explicit
reference was found in the text
== Unused Reference: 'RFC5176' is defined on line 1455, but no explicit
reference was found in the text
== Unused Reference: 'RFC5246' is defined on line 1460, but no explicit
reference was found in the text
== Unused Reference: 'RFC5247' is defined on line 1463, but no explicit
reference was found in the text
== Unused Reference: 'RFC5280' is defined on line 1467, but no explicit
reference was found in the text
== Unused Reference: 'RFC6066' is defined on line 1480, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-radext-dtls' is defined on line 1502, but no
explicit reference was found in the text
== Unused Reference: 'MD5-attacks' is defined on line 1516, but no explicit
reference was found in the text
== Unused Reference: 'RFC3539' is defined on line 1521, but no explicit
reference was found in the text
== Unused Reference: 'RFC4107' is defined on line 1535, but no explicit
reference was found in the text
== Unused Reference: 'RFC4346' is defined on line 1538, but no explicit
reference was found in the text
== Unused Reference: 'RFC4953' is defined on line 1541, but no explicit
reference was found in the text
== Unused Reference: 'RFC6125' is defined on line 1544, but no explicit
reference was found in the text
== Unused Reference: 'RFC6421' is defined on line 1550, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
== Outdated reference: A later version (-15) exists of
draft-ietf-radext-dynamic-discovery-11
== Outdated reference: A later version (-15) exists of
draft-ietf-radext-nai-06
-- Obsolete informational reference (is this intentional?): RFC 3588
(Obsoleted by RFC 6733)
-- Obsolete informational reference (is this intentional?): RFC 4346
(Obsoleted by RFC 5246)
-- Obsolete informational reference (is this intentional?): RFC 6125
(Obsoleted by RFC 9525)
Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Wierenga
3 Internet-Draft Cisco Systems
4 Intended status: Informational S. Winter
5 Expires: February 22, 2015 RESTENA
6 T. Wolniewicz
7 Nicolaus Copernicus University
8 August 21, 2014
10 The eduroam architecture for network roaming
11 draft-wierenga-ietf-eduroam-04.txt
13 Abstract
15 This document describes the architecture of the eduroam service for
16 federated (wireless) network access in academia. The combination of
17 IEEE 802.1X, EAP and RADIUS that is used in eduroam provides a
18 secure, scalable and deployable service for roaming network access.
19 The successful deployment of eduroam over the last decade in the
20 educational sector may serve as an example for other sectors, hence
21 this document. In particular the initial architectural and standards
22 choices and the changes that were prompted by operational experience
23 are highlighted.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on February 22, 2015.
42 Copyright Notice
44 Copyright (c) 2014 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
62 1.3. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
63 1.4. Solutions that were considered . . . . . . . . . . . . . 5
64 2. Classic Architecture . . . . . . . . . . . . . . . . . . . . 5
65 2.1. Authentication . . . . . . . . . . . . . . . . . . . . . 6
66 2.1.1. IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . 6
67 2.1.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . 7
68 2.2. Federation Trust Fabric . . . . . . . . . . . . . . . . . 9
69 2.2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . 9
70 3. Issues with initial Trust Fabric . . . . . . . . . . . . . . 11
71 3.1. Server Failure Handling . . . . . . . . . . . . . . . . . 12
72 3.2. No error condition signalling . . . . . . . . . . . . . . 13
73 3.3. Routing table complexity . . . . . . . . . . . . . . . . 14
74 3.4. UDP Issues . . . . . . . . . . . . . . . . . . . . . . . 14
75 3.5. Insufficient payload encryption and EAP server validation 15
76 4. New Trust Fabric . . . . . . . . . . . . . . . . . . . . . . 17
77 4.1. RADIUS with TLS . . . . . . . . . . . . . . . . . . . . . 17
78 4.2. Dynamic Discovery . . . . . . . . . . . . . . . . . . . . 19
79 4.2.1. Discovery of responsible server . . . . . . . . . . . 19
80 4.2.2. Verifying server authorisation . . . . . . . . . . . 20
81 4.2.3. Operational Experience . . . . . . . . . . . . . . . 21
82 4.2.4. Possible Alternatives . . . . . . . . . . . . . . . . 21
83 5. Abuse prevention and incident handling . . . . . . . . . . . 21
84 5.1. Incident Handling . . . . . . . . . . . . . . . . . . . . 22
85 5.1.1. Blocking users on the SP side . . . . . . . . . . . . 23
86 5.1.2. Blocking users on the IdP side . . . . . . . . . . . 24
87 5.1.3. Communicating account blocking to the end user . . . 24
88 5.2. Operator Name . . . . . . . . . . . . . . . . . . . . . . 25
89 5.3. Chargeable User Identity . . . . . . . . . . . . . . . . 26
90 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
91 6.1. Collusion of Service Providers . . . . . . . . . . . . . 27
92 6.2. Exposing user credentials . . . . . . . . . . . . . . . . 27
93 6.3. Track location of users . . . . . . . . . . . . . . . . . 28
94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
95 7.1. Man in the middle and Tunneling Attacks . . . . . . . . . 28
96 7.1.1. Verification of Server Name not supported . . . . . . 28
97 7.1.2. Neither Specification of CA nor Server Name checks
98 during bootstrap . . . . . . . . . . . . . . . . . . 29
99 7.1.3. User does not configure CA or Server Name checks . . 29
100 7.1.4. Tunneling authentication traffic to obfuscate user
101 origin . . . . . . . . . . . . . . . . . . . . . . . 29
102 7.2. Denial of Service Attacks . . . . . . . . . . . . . . . . 30
103 7.2.1. Intentional DoS by malign individuals . . . . . . . . 30
104 7.2.2. DoS as a side-effect of expired credentials . . . . . 31
105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
106 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
107 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
108 9.2. Informative References . . . . . . . . . . . . . . . . . 33
109 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36
110 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 36
111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
113 1. Introduction
115 In 2002 the European Research and Education community set out to
116 create a network roaming service for students and employees in
117 academia [eduroam-start]. Now over 10 years later this service has
118 grown to more than 10,000 service locations, serving millions of
119 users on all continents with the exception of Antarctica.
121 This memo serves to explain the considerations for the design of
122 eduroam as well as to document operational experience and resulting
123 changes that led to IETF standardization effort like RADIUS over TCP
124 [RFC6613] and RADIUS with TLS [RFC6614] and that promoted alternative
125 uses of RADIUS like in ABFAB [I-D.ietf-abfab-arch]. Whereas the
126 eduroam service is limited to academia, the eduroam architecture can
127 easily be reused in other environments.
129 First this memo describes the original architecture of eduroam. Then
130 a number of operational problems are presented that surfaced when
131 eduroam gained wide-scale deployment. Lastly, enhancements to the
132 eduroam architecture that mitigate the aforementioned issues are
133 discussed.
135 1.1. Terminology
137 This document uses identity management and privacy terminology from
138 [RFC6973]. In particular, this document uses the terms Identity
139 Provider, Service Provider and identity management.
141 1.2. Notational Conventions
143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
145 document are to be interpreted as described in RFC 2119 [RFC2119].
147 Note: Also the policy that eduroam participants subscribe to,
148 expresses the requirements for participation in RFC 2119 language.
150 1.3. Design Goals
152 The guiding design considerations for eduroam were as follows:
154 - Unique identification of users at the edge of the network
156 The access Service Provider (SP) needs to be able to determine
157 whether a user is authorized to use the network resources.
158 Furthermore, in case of abuse of the resources, there is a
159 requirement to be able to identify the user uniquely (with the
160 cooperation of the user's Identity Provider (IdP) operator).
162 - Enable (trusted) guest use
164 In order to enable roaming it should be possible for users of
165 participating institutions to get seamless access to the networks of
166 other institutions.
168 Note: traffic separation between guest users and normal users is
169 possible (for example through the use of VLANs), and indeed widely
170 used in eduroam.
172 - Scalable
174 The infrastructure that is created should scale to a large number of
175 users and organizations without requiring a lot of coordination and
176 other administrative procedures (possibly with the exception of an
177 initial set up). Specifically, it should not be necessary for a user
178 that visits another organization to go through an administrative
179 process.
181 - Easy to install and use
183 It should be easy for both organizations and users to participate in
184 the roaming infrastructure as that may otherwise inhibit wide scale
185 adoption. In particular, there should be no or easy client
186 installation and only one-off configuration.
188 - Secure
189 An important design criterion has been that there needs to be a
190 security association between the end-user and their Identity
191 Provider, eliminating the possibility of credentials theft. The
192 minimal requirements for security are specified in the eduroam policy
193 and subject to change over time. As an additional protection against
194 user errors and negligence, it should be possible for participating
195 Identity Providers to set their own additional requirements for the
196 quality of authentication of their own users without the need for the
197 infrastructure as a whole to implement the same standard.
199 - Privacy preserving
201 The design of the system should provide for user anonymization, i.e.
202 a possibility to hide the user's identity from any third parties,
203 including Service Providers.
205 - Standards based
207 In an infrastructure in which many thousands of organizations
208 participate it is obvious that it should be possible to use equipment
209 from different vendors, therefore it is important to base the
210 infrastructure on open standards.
212 1.4. Solutions that were considered
214 Three architectures were trialed: one based on the use of VPN-
215 technology (deemed secure but not-scalable), one Web captive-portal
216 based (scalable but not secure) and IEEE 802.1X-based, the latter
217 being the basis of what is now the eduroam architecture
218 ([nrenroaming-select]).
220 The chosen architecture is based on:
222 o IEEE 802.1X ([dot1X-standard]) as port based authentication
223 framework using
225 o EAP ([RFC3748]) for integrity and confidentially protected
226 transport of credentials and a
228 o RADIUS ([RFC2865]) hierarchy as trust fabric.
230 2. Classic Architecture
232 Federations, like eduroam, implement essentially two types of direct
233 trust relations (and one indirect). The trust relation between an
234 end-user and the IdP (operated by the home organization of the user)
235 and between the IdP and the SP (in eduroam the operator of the
236 network at the visited location). In eduroam the trust relation
237 between user and IdP is through mutual authentication. IdPs and SP
238 establish trust through the use of a RADIUS hierarchy.
240 These two forms of trust relations in turn provide the transitive
241 trust relation that makes the SP trust the user to use its network
242 resources.
244 2.1. Authentication
246 Authentication in eduroam is achieved by using a combination of IEEE
247 802.1X [dot1X-standard] and EAP [RFC4372] (the latter carried over
248 RADIUS, see below).
250 2.1.1. IEEE 802.1X
252 By using the IEEE 802.1X [dot1X-standard] framework for port-based
253 network authentication, organizations that offer network access (SPs)
254 for visiting (and local) eduroam users can make sure that only
255 authorized users get access. The user (or rather the user's
256 supplicant) sends an access request to the authenticator (wireless
257 access point or switch) at the SP, the authenticator forwards the
258 access request to the authentication server of the SP which in turn
259 proxies the request through the RADIUS hierarchy to the
260 authentication server of the user's home organization (the IdP, see
261 below).
263 Note: The security of the connections between local wireless
264 infrastructure and local RADIUS servers is a part of the local
265 network of each SP, therefore it is out of scope for this document.
266 For completeness it should be stated that security between access
267 points and their controllers is vendor specific, security between
268 controllers (or standalone access points) and local RADIUS servers is
269 based on the typical RADIUS shared secret mechanism.
271 In order for users to be aware of the availability of the eduroam
272 service, an SP that offers wireless network access MUST broadcast the
273 SSID 'eduroam', unless that conflicts with the SSID of another
274 eduroam SP, in which case an SSID starting with "eduroam-" MAY be
275 used. The downside of the latter is that clients will not
276 automatically connect to that SSID, thus losing the seamless
277 connection experience.
279 Note: A direct implication of the common eduroam SSID is that the
280 users cannot distinguish between a connection to the home network and
281 a guest network at another eduroam institution (IEEE 802.11-2012 does
282 have the so-called "Interworking" extensions to make that
283 distinction, but these are not widely implemented yet). Therefore,
284 users should be made aware that they should not assume data
285 confidentiality in the eduroam infrastructure.
287 To protect over-the-air user data confidentiality, IEEE 802.11
288 wireless networks of eduroam SP's MUST deploy WPA2+AES, and MAY
289 additionally support WPA/TKIP as a courtesy to users of legacy
290 hardware.
292 2.1.2. EAP
294 The use of the Extensible Authentication Protocol (EAP) [RFC4372]
295 serves 2 purposes. In the first place a properly chosen EAP-method
296 allows for integrity and confidentiality protected transport of the
297 user credentials to the home organization. Secondly, by having all
298 RADIUS servers transparently proxy access requests regardless of the
299 EAP-method inside the RADIUS packet, the choice of EAP-method is
300 between the 'home' organization of the user and the user, in other
301 words, in principle every authentication form that can be carried
302 inside EAP can be used in eduroam, as long as they adhere to minimal
303 requirements as set forth in the eduroam Service Definition
304 [eduroam-service-definition].
306 +-----+
307 / \
308 / \
309 / \
310 / \
311 ,----------\ | | ,---------\
312 | SP | | eduroam | | IdP |
313 | +----+ trust fabric +---+ |
314 `------+---' | | '-----+---'
315 | | | |
316 | \ / |
317 | \ / |
318 | \ / |
319 | \ / |
320 +----+ +-----+ +----+
321 | |
322 | |
323 +---+--+ +--+---+
324 | | | |
325 +-+------+-+ ___________________________ | |
326 | | O__________________________ ) +------+
327 +----------+
328 Host (supplicant) EAP tunnel Authentication server
330 Figure 1: Tunneled EAP
332 Proxying of access requests is based on the outer identity in the
333 EAP-message. Those outer identities MUST be a valid user identifier
334 with a mandatory realm as per [I-D.ietf-radext-nai], i.e. be of the
335 form something@realm or just @realm, where the realm part is the
336 domain name of the domain that the IdP belongs to. In order to
337 preserve credentials protection, participating organizations MUST
338 deploy EAP-methods that provide mutual authentication. For EAP
339 methods that support outer identity, anonymous outer identities are
340 recommended. Most commonly used in eduroam are the so-called
341 tunneled EAP-methods, that first create a server authenticated TLS
342 tunnel through which the user credentials are transmitted. As
343 depicted in Figure 1, the use of a tunneled EAP-method creates a
344 direct logical connection between the supplicant and the
345 authentication server, even though the actual traffic flows through
346 the RADIUS-hierarchy.
348 2.2. Federation Trust Fabric
350 The eduroam federation trust fabric is based on RADIUS. RADIUS trust
351 is based on shared secrets between RADIUS peers. In eduroam any
352 RADIUS message originating from a trusted peer is implicitly assumed
353 to originate from a member of the roaming consortium.
355 2.2.1. RADIUS
357 The eduroam trust fabric consists of a proxy hierarchy of RADIUS
358 servers (organizational, national, global), loosely based on the DNS
359 hierarchy. That is, typically an organizational RADIUS server agrees
360 on a shared secret with a national server and the national server in
361 turn agrees on a shared secret with the root server. Access requests
362 are routed through a chain of RADIUS proxies towards the Identity
363 Provider of the user, and the access accept (or reject) follows the
364 same path back.
366 Note: In some circumstances there are more levels of RADIUS servers,
367 like for example regional or continental servers, but that doesn't
368 change the general model. Also, the packet exchange that is
369 described below requires in reality several round-trips.
371 +-------+
372 | |
373 | . |
374 | |
375 +---+---+
376 / | \
377 +----------------/ | \---------------------+
378 | | |
379 | | |
380 | | |
381 +--+---+ +--+--+ +----+---+
382 | | | | | |
383 | .edu | . . . | .nl | . . . | .ac.uk |
384 | | | | | |
385 +--+---+ +--+--+ +----+---+
386 / | \ | \ |
387 / | \ | \ |
388 / | \ | \ |
389 +-----+ | +-----+ | +------+ |
390 | | | | | |
391 | | | | | |
392 +---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
393 | | | | | | | | | | | |
394 |utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
395 | | | | | | | | | | | |
396 +----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
397 | |
398 | |
399 +--+--+ +--+--+
400 | | | |
401 +-+-----+-+ | |
402 | | +-----+
403 +---------+
404 user: paul@surfnet.nl surfnet.nl Authentication server
406 Figure 2: eduroam RADIUS hierarchy
408 Routing of access requests to the home IdP is done based on the realm
409 part of the outer identity. For example (see: Figure 2), when user
410 paul@surfnet.nl of SURFnet (surfnet.nl) tries to gain wireless
411 network access at the University of Tennessee at Knoxville (utk.edu)
412 the following happens:
414 o Paul's supplicant transmits an EAP access request to the Access
415 Point (Authenticator) at UTK with outer identity say
416 anonymous@surfnet.nl
418 o The Access Point forwards the EAP message to its Authentication
419 Server (the UTK RADIUS server)
421 o The UTK RADIUS server checks the realm to see if it is a local
422 realm, since it isn't the request is proxied to the .edu RADIUS
423 server
425 o The .edu RADIUS server verifies the realm, and since it is not a
426 in a .edu subdomain it proxies the request to the root server
428 o The root RADIUS server proxies the request to the .nl RADIUS
429 server
431 o The .nl RADIUS server proxies the request to the surfnet.nl server
433 o The surfnet.nl RADIUS server decapsulates the EAP message and
434 verifies the user credentials
436 o The surfnet.nl RADIUS server informs the utk.edu server of the
437 outcome of the authentication request (Access-Accept or Access-
438 Reject) by proxying the outcome through the RADIUS hierarchy in
439 reverse order.
441 o The UTK RADIUS server instructs the UTK Access Point to either
442 accept or reject access based on the outcome of the
443 authentication.
445 Note: The depiction of the root RADIUS server is a simplification.
446 In reality the root server is distributed over 3 continents and each
447 maintains a list of the top level realms that a specific root server
448 is responsible for. This also means that, for intercontinental
449 roaming, there is an extra proxy step from one root server to the
450 other.
452 3. Issues with initial Trust Fabric
454 While the hierarchical RADIUS architecture described in the previous
455 section has served as the basis for eduroam operations for an entire
456 decade, the exponential growth of authentications is expected to lead
457 to, and has in fact in some cases already led to, performance and
458 operations bottlenecks on the aggregation proxies. The following
459 sections describe some of the shortcomings, and the resulting
460 remedies.
462 3.1. Server Failure Handling
464 In eduroam, authentication requests for roaming users are statically
465 routed through pre-configured proxies. The number of proxies varies:
466 in a national roaming case, the number of proxies is typically 1 or 2
467 (some countries deploy regional proxies, which are in turn aggregated
468 by a national proxy); in international roaming, 3 or 4 proxy servers
469 are typically involved (the number may be higher along some routes).
471 RFC2865 [RFC2865] does not define a failover algorithm. In
472 particular, the failure of a server needs to be deduced from the
473 absence of a reply. Operational experience has shown that this has
474 detrimental effects on the infrastructure and end user experience:
476 1. Authentication failure: the first user whose authentication path
477 is along a newly-failed server will experience a long delay and
478 possibly timeout
480 2. Wrongly deduced states: since the proxy chain is longer than 1
481 hop, a failure further along in the authentication path is
482 indistinguishable from a failure in the next hop.
484 3. Inability to determine recovery of a server: only a "live"
485 authentication request sent to a server which is believed
486 inoperable can lead to the discovery that the server is in
487 working order again. This issue has been resolved with RFC5997
488 [RFC5997].
490 The second point can have significant impact on the operational state
491 of the system in a worst-case scenario: Imagine one realm's home
492 server being inoperable. A user from that realm is trying to roam
493 internationally and tries to authenticate. The RADIUS server on the
494 hotspot location will assume its own national proxy is down, because
495 it does not reply. That national server, being perfectly alive, in
496 turn will assume that the international aggregation proxy is down;
497 which in turn will believe the home country proxy national server is
498 down. None of these assumptions are true. Worse yet: should any of
499 these servers trigger a failover to a redundant backup RADIUS server,
500 it will still not receive a reply, because the request will still be
501 routed to the same defunct home server. Within a short time, all
502 redundant aggregation proxies might be considered defunct by their
503 preceding hop.
505 In the absence of proper next-hop state derivation, some interesting
506 concepts have been introduced by eduroam participants; the most
507 noteworthy being a failover logic which considers up/down states not
508 per next-hop RADIUS peer, but instead per realm (See [dead-realm] for
509 details). As of recent, RFC5997 [RFC5997] implementations and
510 cautious failover parameters make such a worst-case scenario very
511 unlikely to happen, but are still an important issue to consider.
513 3.2. No error condition signalling
515 The RADIUS protocol lacks signalling of error conditions, and the
516 IEEE 802.1X protocol does not allow to convey extended failure
517 reasons to the end-user's device. For eduroam, this creates issues
518 in a twofold way:
520 o The home server may have an operational problem, for example its
521 authentication decisions may depend on an external data source
522 such as ActiveDirectory or an SQL server, and the external data
523 source is unavailable. If the RADIUS interface is still
524 functional, there are two options how to reply to an Access-
525 Request which can't be serviced due to such error conditions:
527 1. Do Not Reply: the inability to reach a conclusion can be
528 treated by not replying to the request. The upside of this
529 approach is that the end-user's software doesn't come to wrong
530 conclusions and won't give unhelpful hints such as "maybe your
531 password is wrong". The downside is that intermediate proxies
532 may come to wrong conclusions because their downstream RADIUS
533 server isn't responding.
535 2. Reply with Reject: in this option, the inability to reach a
536 conclusion is treated like an authentication failure. The
537 upside of this approach is that intermediate proxies maintain
538 a correct view on the reachability state of their RADIUS peer.
539 The downside is that EAP supplicants on end-user devices often
540 react with either false advice ("your password is wrong") or
541 even trigger permanent configuration changes (e.g. the Windows
542 built-in supplicant will delete the credential set from its
543 registry, prompting the user for their password on the next
544 connection attempt). The latter case of Windows is a source
545 of significant helpdesk activity; users may have forgotten
546 their password after initially storing it, but are suddenly
547 prompted again.
549 There have been epic discussions in the eduroam community which of
550 the two approaches is more appropriate; but they were not conclusive.
552 o Similar considerations as above apply when an intermediate proxy
553 does not receive a reply from a downstream RADIUS server. The
554 proxy may either choose not to reply to the original request,
555 leading to retries and its upstream peers coming to wrong
556 conclusions about its own availability; or it may decide to reply
557 with Access-Reject to indicate its own liveliness, but again with
558 implications for the end user.
560 The ability to send Status-Server watchdog requests is only of use
561 after the fact, in case a downstream server doesn't reply (or hasn't
562 been contacted in a long while, so that it's previous working state
563 is stale). The active link-state monitoring of the TCP connection
564 with e.g. RADIUS/TLS (see below) gives a clearer indication whether
565 there is an alive RADIUS peer, but does not solve the defunct backend
566 problem. An explicit ability to send Error-Replies, on the RADIUS
567 (for other RADIUS peer information) and EAP level (for end-user
568 supplicant information), would alleviate these problems but is
569 currently not available.
571 3.3. Routing table complexity
573 The aggregation of RADIUS requests based on the structure of the
574 user's realm implies that realms ending with the same top-level
575 domain are routed to the same server; i.e. to a common administrative
576 domain. While this is true for country code Top Level Domains
577 (ccTLDs), which map into national eduroam federations, it is not true
578 for realms residing in generic Top Level Domains (gTLDs). Realms in
579 gTLDs were historically discouraged because the automatic mapping
580 "realm ending" -> "eduroam federation's server" could not be applied.
581 However, with growing demand from eduroam realm administrators, it
582 became necessary to create exception entries in the forwarding rules;
583 such realms need to be mapped on a realm-by-realm basis to their
584 eduroam federations. Example: "kit.edu" (Karsruher Institut fuer
585 Technologie) needs to be routed to the German federation server,
586 whereas "iu.edu" (Indiana University) needs to be routed to the USA
587 federation server.
589 While the ccTLDs occupy only approx. 50 routing entries in total (and
590 have a upper bound of approx. 200), the potential size of the routing
591 table becomes virtually unlimited if it needs to accomodate all
592 individual entries in .edu, .org, etc.
594 In addition to that, all these routes need to be synchronised between
595 three international root servers, and the updates need to be applied
596 manually to RADIUS server configuration files. The frequency of the
597 required updates makes this approach fragile and error-prone as the
598 number of entries grows.
600 3.4. UDP Issues
602 RADIUS is based on UDP, which was a reasonable choice when its main
603 use was with simple PAP requests which required only exactly one
604 packet exchange in each direction.
606 When transporting EAP over RADIUS, the EAP conversations requires
607 multiple round-trips; depending on the total payload size, 8-10
608 round-trips are not uncommon. The loss of a single UDP packet will
609 lead to user-visible delays and might result in servers being marked
610 as dead due to the absence of a reply. The proxy path in eduroam
611 consists of several proxies, all of which introduce a very small
612 packet loss probability; i.e. the more proxies are needed, the higher
613 the failure rate is going to be.
615 For some EAP types, depending on the exact payload size they carry,
616 RADIUS servers and/or supplicants may choose to fill as much EAP data
617 into a single RADIUS packet as the supplicant's layer 2 medium allows
618 for, typically 1500 Bytes. In that case, the RADIUS encapsulation
619 around the EAP-Message will add more bytes to the overall RADIUS
620 payload size and in the end exceed the 1500 Byte limit, leading to
621 fragmentation of the UDP datagram on the IP layer. While this is not
622 a problem in theory, practice has shown evidence of misbehaving
623 firewalls which erroneously discard non-first UDP fragments, which
624 ultimately leads to a denial of service for users with such EAP types
625 and that specific configuration.
627 One EAP type proved to be particularly problematic: EAP-TLS. While
628 it is possible to configure the EAP server to send smaller chunks of
629 EAP payload to the supplicant (e.g. 1200 Bytes, to allow for another
630 300 Bytes of RADIUS overhead without fragmentation), very often the
631 supplicants which send the client certificate do not expose such a
632 configuration detail to the user. Consequently, when the client
633 certificate is beyond 1500 Bytes in size, the EAP-Message will always
634 make use of the maximum possible layer-2 chunk size, which introduces
635 the fragmentation on the path from EAP peer to EAP server.
637 Both of the previously mentioned sources of errors (packet loss,
638 fragment discard) lead to significant frustration for the affected
639 users. Operational experience of eduroam shows that such cases are
640 hard to debug since they require coordinated cooperation of all
641 eduroam administrators on the authentication path. For that reason
642 the eduroam community is developing monitoring tools that help to
643 locate fragmentation problems.
645 3.5. Insufficient payload encryption and EAP server validation
647 The RADIUS protocol's design foresaw only the encryption of select
648 RADIUS attributes, most notably User-Password. With EAP methods
649 conforming to the requirements of [RFC4017], the user's credential is
650 not transmitted using the User-Password attribute, and stronger
651 encryption than the one for RADIUS' User-Password is in use
652 (typically TLS).
654 Still, the use of EAP does not encrypt all personally identifiable
655 details of the user session as some are carried inside clear-text
656 RADIUS attributes. In particular, the user's device can be
657 identified by inspecting the Calling-Station-ID attribute; and the
658 user's location may be derived from observing NAS-IP-Address, NAS-
659 Identifier or Operator-Name attributes. Since these attributes are
660 not encrypted, even IP-layer third parties can harvest the
661 corresponding data. In a worst-case scenario, this enables the
662 creation of mobility profiles. Pervasive passive surveillance using
663 this connection metadata such as the recently uncovered NSA/GCHQ
664 incidents becomes possible by tapping RADIUS traffic from an IP hop
665 near a RADIUS aggregation proxy. While this is possible, the authors
666 are not aware whether this has actually been done.
668 These profiles are not necessarily linkable to an actual user because
669 EAP allows for the use of anonymous outer identities and protected
670 credential exchanges. However, practical experience has shown that
671 many users neglect to configure their supplicants in a privacy-
672 preserving way or their supplicant doesn't support that. In
673 particular, for EAP-TLS users, the use of EAP-TLS identity protection
674 is not usually implemented and cannot be used. In eduroam, concerned
675 individuals and IdPs which use EAP-TLS are using pseudonymous client
676 certificates to provide for better privacy.
678 One way out, at least for EAP types involving a username, is to
679 pursue the creation and deployment of pre-configured supplicant
680 configurations which makes all the required settings in user devices
681 prior to their first connection attempt; this depends heavily on the
682 remote configuration possibilities of the supplicants though.
684 A further threat involves the verification of the EAP server's
685 identity. Even though the cryptographic foundation, TLS tunnels, is
686 sound, there is a weakness in the supplicant configuration: many
687 users do not understand or are willing to invest time into the
688 inspection of server certificates or the installation of a trusted
689 CA. As a result, users may easily be tricked into connecting to an
690 unauthorized EAP server, ultimately leading to a leak of their
691 credentials to that unauthorized third party.
693 Again, one way out of this particular threat is to pursue the
694 creation and deployment of pre-configured supplicant configurations
695 which makes all the required settings in user devices prior to their
696 first connection attempt.
698 Note: there are many different and vendor-proprietary ways to pre-
699 configure a device with the necessary EAP parameters (examples
700 include Apple, Inc's "mobileconfig" and Microsoft's "EAPHost" XML
701 schema). Some manufacturers even completely lack any means to
702 distribute EAP configuration data. We believe there is value in
703 defining a common EAP configuration metadata format which could be
704 used across manufacturers, ideally leading to a situation where IEEE
705 802.1X network end-users merely need to apply this configuration file
706 to configure any of their devices securely with the required
707 connection properties.
709 Another possible privacy threat involves transport of user-specific
710 attributes in a Reply-Message. If, for example, a RADIUS server
711 sends back a hypothetical RADIUS Vendor-Specific-Attribute "User-Role
712 = Student of Computer Science" (e.g. for consumption of an SP RADIUS
713 server and subsequent assignment into a "student" VLAN), this
714 information would also be visible for third parties and could be
715 added to the mobility profile.
717 The only way out to mitigate all information leakage to third parties
718 is by protecting the entire RADIUS packet payload so that IP-layer
719 third parties cannot extract privacy-relevant information. RFC2865
720 RADIUS does not offer this possibility though.
722 4. New Trust Fabric
724 The operational difficulties with an ever increasing number of
725 participants, as documented in the previous section, have led to a
726 number of changes to the eduroam architecture that in turn have, as
727 mentioned in the introduction, led to standardization effort.
729 Note: The enhanced architecture components are fully backwards
730 compatible with the existing installed base, and are in fact
731 gradually replacing those parts of it where problems may arise.
733 Whereas the user authentication using IEEE 802.1X and EAP has
734 remained unchanged (i.e. no need for end-users to change any
735 configurations), the issues as reported above have resulted in a
736 major overhaul of the way EAP messages are transported from the
737 RADIUS server of the SP to that of the IdP and back. The two
738 fundamental changes are the use of TCP instead of UDP and reliance on
739 TLS instead of shared secrets between RADIUS peers.
741 4.1. RADIUS with TLS
743 The deficiencies of RADIUS over UDP as described in Section 3.4
744 warranted a search for a replacement of RFC2865 [RFC2865] for the
745 transport of EAP. By the time this need was understood, the
746 designated successor protocol to RADIUS, Diameter [RFC3588], was
747 already specified by the IETF. However, within the operational
748 constraints of eduroam:
750 o reasonably cheap to deploy on many administrative domains
752 o supporting NASREQ Application
754 o supporting EAP Application
756 o supporting Diameter Redirect
758 o supporting validation of authentication requests of the most
759 popular EAP types (EAP-TTLS, PEAP, and EAP-TLS)
761 o possibility to retrieve these credentials from popular backends
762 such as Microsoft ActiveDirectory, MySQL
764 no single implementation could be found. In addition to that, no
765 Wireless Access Points at the disposal of eduroam participants
766 supported Diameter, nor did any of the manufacturers have a roadmap
767 towards Diameter support. This led to the open question of lossless
768 translation from RADIUS to Diameter and vice versa; a question not
769 satisfactorily answered by NASREQ.
771 After monitoring the Diameter implementation landscape for a while,
772 it became clear that a solution with better compatibility and a
773 plausible upgrade path from the existing RADIUS hierarchy was needed.
774 The eduroam community actively engaged in the IETF towards the
775 specification of several enhancements to RADIUS to overcome the
776 limitations mentioned in Section 3. The outcome of this process was
777 [RFC6614] and [I-D.ietf-radext-dynamic-discovery].
779 With its use of TCP instead of UDP, and with its full packet
780 encryption, while maintaining full packet format compatibility with
781 RADIUS/UDP, RADIUS/TLS [RFC6614] allows to upgrade any given RADIUS
782 link in eduroam without the need of a "flag day".
784 In a first upgrade phase, the classic eduroam hierarchy (forwarding
785 decision taken by inspecting the realm) remains intact. That way,
786 RADIUS/TLS merely enhances the underlying transport of the RADIUS
787 datagrams. But this already provides some key advantages:
789 o explicit peer reachability detection using long-lived TCP sessions
791 o protection of user credentials and all privacy-relevant RADIUS
792 attributes
794 RADIUS/TLS connections for the static hierarchy could be realised
795 with the TLS-PSK operation mode (which effectively provides a 1:1
796 replacement for RADIUS/UDP's "shared secrets"), but since this
797 operation mode is not widely supported as of yet, all RADIUS/TLS
798 links in eduroam are secured by TLS with X.509 certificates from a
799 set of accredited CAs.
801 This first deployment phase does not yet solve the routing table
802 complexity problem (see (Section 3.3); this aspect is covered by
803 introducing dynamic discovery for RADIUS/TLS servers.
805 4.2. Dynamic Discovery
807 When introducing peer discovery, two separate issues had to be
808 addressed:
810 1. How to find the network address of a responsible RADIUS server
811 for a given realm?
813 2. How to verify that this realm is an authorized eduroam
814 participant?
816 4.2.1. Discovery of responsible server
818 Issue 1 can relatively simply be addressed by putting eduroam-
819 specific service discovery information into the global DNS tree. In
820 eduroam this is done by using Naming Authority Pointer (NAPTR)
821 records as per the S-NAPTR specification [RFC3958] with a private-use
822 NAPTR service tag ("x-eduroam:radius.tls"). The usage profile of
823 that NAPTR resource record is that exclusively "S" type delegations
824 are allowed, and that no regular expressions are allowed.
826 A subsequent lookup of the resulting SRV records will eventually
827 yield hostnames and IP addresses of the authoritative server(s) of a
828 given realm.
830 Example (wrapped for readability):
832 > dig -t naptr education.example.
834 ;; ANSWER SECTION:
835 education.example. 43200 IN NAPTR 100 10 "s"
836 "x-eduroam:radius.tls" ""
837 _radsec._tcp.eduroam.example.
839 > dig -t srv _radsec._tcp.eduroam.example.
841 ;; ANSWER SECTION:
842 _radsec._tcp.eduroam.example. 43200 IN SRV 0 0 2083
843 tld1.eduroam.example.
845 > dig -t aaaa tld1.eduroam.example.
847 ;; ANSWER SECTION:
848 tld1.eduroam.example. 21751 IN AAAA 2001:db8:1::2
850 Figure 3: SRV record lookup
852 From the operational experience with this mode of operation, eduroam
853 is pursuing standardisation of this approach for generic AAA use
854 cases. The current radext working group document for this is
855 [I-D.ietf-radext-dynamic-discovery].
857 4.2.2. Verifying server authorisation
859 Any organisation can put "x-eduroam" NAPTR entries into their Domain
860 Name Server, pretending to be eduroam Identity Provider for the
861 corresponding realm. Since eduroam is a service for a heterogeneous,
862 but closed, user group, additional sources of information need to be
863 consulted to verify that a realm with its discovered server is
864 actually an eduroam participant.
866 The eduroam consortium has chosen to deploy a separate PKI
867 infrastructure which issues certificates only to authorised eduroam
868 Identity Providers and eduroam Service Providers. Since certificates
869 are needed for RADIUS/TLS anyway, this was a straightforward
870 solution. The PKI fabric allows multiple CAs as trust roots
871 (overseen by a Policy Management Authority), and requires that
872 certificates which were issued to verified eduroam participants are
873 marked with corresponding "X509v3 Policy OID" fields; eduroam RADIUS
874 servers and clients need to verify the existence of these OIDs in the
875 incoming certificates.
877 The policies and OIDs can be retrieved from the "eduPKI Trust Profile
878 for eduroam Certificates" ([edupki]).
880 4.2.3. Operational Experience
882 The discovery model as described above is currently deployed in
883 approximately 10 countries that participate in eduroam, making more
884 than 100 realms discoverable via their NAPTR records. Experience has
885 shown that the model works and scales as expected; the only drawback
886 being that the additional burden of operating a PKI which is not
887 local to the national eduroam administrators creates significant
888 administrative complexities. Also, the presence of multiple CAs and
889 regular updates of Certificate Revocation Lists makes the operation
890 of RADIUS servers more complex.
892 4.2.4. Possible Alternatives
894 There are two alternatives to the above approach which are monitored
895 by the eduroam community:
897 1. DNSSEC + DANE TLSA records
899 2. ABFAB Trust Router
901 For DNSSEC+DANE TLSA, its biggest advantage is that the certificate
902 data itself can be stored in the DNS - possibly obsoleting the PKI
903 infrastructure *if* a new place for the server authorization checks
904 can be found. Its most significant downside is that the DANE
905 specifications only include client-to-server certificate checks,
906 while RADIUS/TLS requires also server-to-client verification.
908 For the ABFAB Trust Router, the biggest advantage is that it would
909 work without certificates altogether (by negotiating TLS-PSK keys ad-
910 hoc). The downside is that it is currently not formally specified
911 and not as thoroughly understood as any of the other solutions.
913 5. Abuse prevention and incident handling
915 Since the eduroam service is a confederation of autonomous networks,
916 there is little justification for transferring accounting information
917 from the Service Provider to any other in general, or in particular
918 to the Identity Provider of the user. Accounting in eduroam is
919 therefore considered to be a local matter of the Service Provider.
920 The eduroam compliance statement ([eduroam-compliance]) in fact
921 specifies that accounting traffic SHOULD NOT be forwarded.
923 The static routing infrastructure of eduroam acts as a filtering
924 system blocking accounting traffic from misconfigured local RADIUS
925 servers. Proxy servers are configured to terminate accounting
926 request traffic by answering to Accounting-Requests with an
927 Accounting-Response in order to prevent the retransmission of
928 orphaned Accounting-Request messages. With dynamic discovery,
929 Identity Providers which are discoverable via DNS will need to apply
930 these filtering measures themselves. This is an increase in
931 complexity of the Identity Provider RADIUS configuration.
933 Roaming creates accountability problems, as identified by [RFC4372]
934 (Chargeable User Identity). Since the NAS can only see the (likely
935 anonymous) outer identity of the user, it is impossible to correlate
936 usage with a specific user (who may use multiple devices). A NAS
937 that supports this can request the Chargeable-User-Identity and, if
938 supplied by the authenticating RADIUS server in the Access-Accept
939 message, add this value to corresponding Access-Request packets.
940 While eduroam does not have any charging mechanisms, it may still be
941 desirable to identify traffic originating from one particular user.
942 One of the reasons is to prevent abuse of guest access by users
943 living nearby university campuses. Chargeable User Identity (see
944 below) supplies the perfect answer to this problem, however at the
945 moment of writing, to our knowledge only one hardware vendor (Meru
946 Networks) implements RFC4372 on their Access Points. For all other
947 vendors, requesting the Chargeable-User-Identity attribute needs to
948 happen on the RADIUS server to which the Access Point is connected
949 to. FreeRADIUS supports this ability in the latest distribution, and
950 Radiator can be retrofitted to do the same.
952 5.1. Incident Handling
954 10 years of experience with eduroam have not exposed any serious
955 incident. This may be taken as evidence for proper security design
956 as well as suggest that awareness of users that they are
957 identifiable, acts as an effective deterrent. It could of course
958 also mean that eduroam operations lack the proper tools or insight
959 into the actual use and potential abuse of the service. In any case,
960 many of the attack vectors that exist in open networks or networks
961 where access control is based on shared secrets are not present,
962 arguably leading to a much more secure system.
964 The European eduroam policy Service Definition
965 [eduroam-service-definition], as an example, describes incident
966 scenarios and actions to be taken, in this document we present the
967 relevant technical issues.
969 The initial implementation has been lacking reliable tools for an SP
970 to make it's own decision or for an IdP to introduce a conditional
971 rule applying only to a given SP. The introduction of support for
972 Operator-Name and Chargeable-User-Identity (see below) to eduroam
973 makes both of these scenarios possible.
975 5.1.1. Blocking users on the SP side
977 The first action in the case of an incident is to block the user's
978 access to eduroam at the Service Provider. Since the roaming user's
979 true identity is likely hidden behind an anonymous/fake outer
980 identity, the Service Provider can only rely on the realm of the user
981 and his MAC address; if the Identity Provider has already sent a
982 Chargeable-User-Identity (see Section 5.3 for details), then this
983 extra information can be used to identify the user more reliably.
985 A first attempt at the SP side may be to block based on the MAC
986 address or outer identity. This blocking can be executed before the
987 EAP authentication occurs - typically in the first datagram, acting
988 on the RADIUS attributes EAP-Message/EAP-Response/Identity and
989 Calling-Station-ID. The datagram can either be dropped (supplicant
990 notices a time-out) or replied-to with a RADIUS Access-Reject
991 containing an EAP-Failure. Since malicious users can change both
992 their MAC addresses and the local part of their outer identity
993 between connection attempts, this first attempt is not sufficient to
994 lock out a determined user.
996 As a second measure, the SP can let the EAP authentication proceed as
997 normal, and verify whether the final Access-Accept response from the
998 RADIUS server contains a Chargeable-User-Identity (CUI). If so, the
999 SP RADIUS server can be configured to turn all future Access- Accepts
1000 for this CUI into an Access-Reject/EAP-Failure. This measure is
1001 effective and efficient: it locks out exactly the one user which is
1002 supposed to be locked out, and has no side-effects on other users,
1003 even from the same realm.
1005 If the EAP authentication does not reveal a CUI, the SP can not
1006 reliably determine the user in question. The only reliable
1007 information to act upon is then the realm portion of the outer
1008 identity of the user. The SP will need to resort to blocking the
1009 entire realm that the offending user belongs to. This can be done at
1010 the EAP-Message/EAP-Repsonse/Identity stage as described above).
1011 This is effective, but not efficient: it locks out the user in
1012 question, but has a DoS side-effect on all other visiting users from
1013 the same realm.
1015 In the absence of a CUI handle, SPs which are not willing to take the
1016 drastic step of blocking an entire realm will be forced to contact
1017 the Identity Provider in question and demand that the user be blocked
1018 at the IdP side. This involves human interaction between SP and IdP
1019 is not possible in real-time.
1021 5.1.2. Blocking users on the IdP side
1023 The IdP has the power to disable a user account altogether, thus
1024 blocking this user from accessing eduroam in all sites. If blocking
1025 the user is done due a request of an SP (as per the previous
1026 section), there may be a more fine-grained possibility to block
1027 access to a specific SP - if the SP in question sends the Operator-
1028 Name attribute along with his Access-Requests (see Section 5.2 for
1029 details).
1031 If the IdP decides to block the user globally, this is typically done
1032 by treating the login attempt as if the credentials were wrong: the
1033 entire EAP conversation needs to be executed to the point where the
1034 true inner identity is revealed (before that, the IdP does not know
1035 yet which user is attempting to authenticate). This typically
1036 coincides with the point in time where credentials are exchanged.
1037 Instead, or in addition to, checking the credential for validity, the
1038 Identity Provider also checks whether the user's account is (still)
1039 eligible for eduroam use and will return an Access- Reject/EAP-
1040 Failure if not.
1042 There may well be cases where opinions between the SP desiring a user
1043 lockout and the IdP of the user differ. E.g. an SP might consider
1044 massive amounts of up-/downloads with file sharing protocols
1045 unacceptable as per local policy, and desire blocking of users that
1046 create too much traffic - but the IdP does not take offense on such
1047 actions and would not want to lock his user out of eduroam globally
1048 because of this one SP's opinion.
1050 In the absence of the Operator-Name attribute, there is no way to
1051 apply a login restriction only for a given SP and not eduroam as a
1052 whole; eduroam eligibility is an all-or-nothing decision for the IdP.
1054 If the Operator-Name attribute is present, the IdP can use this
1055 information to fail the authentication attempt only if the attempt
1056 originated from SPs which desire such blocking. Even though the
1057 Operator-Name attribute is available from the first RADIUS Access-
1058 Request datagram onwards, the EAP authentication needs to be carried
1059 out until the true inner identity is known just as in the global
1060 blocking case above. The Operator-Name is simply an additional piece
1061 of information which the IdP can use to make its decision.
1063 5.1.3. Communicating account blocking to the end user
1065 All the measures above alter the EAP conversation. They either
1066 create a premature rejection or timeout at the start of the
1067 conversation, or change the outcome of the authentication attempt at
1068 the very end of the conversation.
1070 On the supplicant side, these alterations are undistinguishable from
1071 an infrastructure failure: a premature rejection or timeout could be
1072 due to a RADIUS server being unresponsive, and a rejection at the end
1073 of the conversation could be either user error (wrong password) or
1074 server error (credential lookup failed). For the supplicant, it is
1075 thus difficult to communicate a meaningful error to the user. The
1076 newly specified EAP type TEAP, "Tunnel Extensible Authentication
1077 Protocol" [RFC7170] has a means to transport fine-grained error
1078 reason codes to the supplicant; this has the potential to improve the
1079 situation in the future.
1081 The EAP protocol foresees one mechanism to provide such user-
1082 interactive communication: the EAP state machine contains states
1083 which allow user-visible communication: an extra round of EAP-
1084 Request/Notification and the corresponding acknowledgement can be
1085 injected before the final EAP-Failure.
1087 However, anecdotal evidence suggests that supplicants typically do
1088 not implement this part of the EAP state machine at all. One
1089 supplicant is reported to support it, but only logs the contents of
1090 the notification in a log file - which is not at all helpful for the
1091 end user.
1093 The discovery of reasons and scope of account blocking are thus left
1094 as an out-of-band action. The eduroam user support process requires
1095 that users with authentication problems contact their Identity
1096 Provider as a first measure (via unspecified means, e.g. they could
1097 phone their IdP or send an email via a 3G backup link). If the
1098 Identity Provider is the one which blocked their access, the user
1099 will immediately be informed by them. If the reason for blocking is
1100 at the SP side, the Identity Provider will instead inform the user
1101 that the account is in working order and that the user needs to
1102 contact the SP IT support to get further insight. In that case, that
1103 SP-side IT support will notify the users about the reasons for
1104 blocking.
1106 5.2. Operator Name
1108 The Operator-Name attribute is defined in [RFC5580] as a means of
1109 unique identification of the access site.
1111 The Proxy infrastructure of eduroam makes it impossible for home
1112 sites to tell where their users roam to. While this may be seen as a
1113 positive aspect enhancing user's privacy, it also makes user support,
1114 roaming statistics and blocking offending user's access to eduroam
1115 significantly harder.
1117 Sites participating in eduroam are encouraged to add the Operator-
1118 Name attribute using the REALM namespace, i.e. sending a realm name
1119 under control of the given site.
1121 The introduction of Operator-Name in eduroam has identified one
1122 operational problem - the identifier 126 assigned to this attribute
1123 has been previously used by some vendors for their specific purposes
1124 and has been included in attribute dictionaries of several RADIUS
1125 server distributions. Since the syntax of this hijacked attribute
1126 had been set to Integer, this introduces a syntax clash with the the
1127 RFC definition (OctetString). Operational tests in eduroam have
1128 shown that servers using the Integer syntax for attribute 126 may
1129 either truncate the value to 4 octets or even drop the entire RADIUS
1130 packet (thus making authentication impossible). The eduroam
1131 monitoring and eduroam test tools try to locate problematic sites.
1133 When a Service Provider sends its Operator-Name value, it creates a
1134 possibility for the home sites to set up conditional blocking rules,
1135 depriving certain users of access to selected sites. Such action
1136 will cause much less concern than blocking users from all of eduroam.
1138 In eduroam the Operator Name is also used for the generation of
1139 Chargeable User Identity values.
1141 The addition of Operator-Name is a straightforward configuration of
1142 the RADIUS server and may be easily introduced on a large scale.
1144 5.3. Chargeable User Identity
1146 The Chargeable-User-Identity (CUI) attribute is defined by RFC4372
1147 [RFC4372] as an answer to accounting problems caused by the use of
1148 anonymous identity in some EAP methods. In eduroam the primary use
1149 of CUI is in incident handling, but it can also enhance local
1150 accounting.
1152 The eduroam policy requires that a given user's CUI generated for
1153 requests originating from different sites should be different (to
1154 prevent collusion attacks). The eduroam policy thus mandates that a
1155 CUI request be accompanied by the Operator-Name attribute, which is
1156 used as one of the inputs for the CUI generation algorithm. The
1157 Operator-Name requirement is considered to be the "business
1158 requirement" described in Section 2.1 of RFC4372 [RFC4372] and hence
1159 conforms to the RFC.
1161 When eduroam started considering using CUI, there were no NAS
1162 implementations, therefore the only solution was moving all CUI
1163 support to the RADIUS server.
1165 CUI request generation requires only the addition of NUL CUI
1166 attributes to outgoing Access-Requests, however the real strength of
1167 CUI comes with accounting. Implementation of CUI based accounting in
1168 the server requires that the authentication and accounting RADIUS
1169 servers used directly by the NAS are actually the same or at least
1170 have access to a common source of information. Upon processing of an
1171 Access-Accept the authenticating RADIUS server must store the
1172 received CUI value together with the device's Calling-Station-Id in a
1173 temporary database. Upon receipt of an Accounting-Request, the
1174 server needs to update the packet with the CUI value read from the
1175 database.
1177 A wide introduction of CUI support in eduroam will significantly
1178 simplify incident handling at Service Providers. Introducing local,
1179 per-user access restriction will be possible. Visited sites will
1180 also be able to notify the home site about the introduction of such a
1181 restriction, pointing to the CUI value and thus making it possible
1182 for the home site to identify the user. When the user reports the
1183 problem at his home support, the reason will be already known.
1185 6. Privacy Considerations
1187 The eduroam architecture has been designed with protection of user
1188 credentials in mind as may be clear from the discussion above.
1189 However, operational experience has revealed some more subtle points
1190 with regards to privacy.
1192 6.1. Collusion of Service Providers
1194 If users use anonymous outer identities, SPs cannot easily collude by
1195 linking outer identities to users that are visiting their campus.
1196 This poses however problems with remediation of abuse or
1197 misconfiguration. It is impossible to find the user that exhibits
1198 unwanted behaviour or whose system has been compromised.
1200 For that reason the Chargeable-User-Identity has been introduced in
1201 eduroam, constructed so that only the IdP of the user can uniquely
1202 identify the user. In order to prevent collusion attacks that CUI is
1203 required to be unique per user per Service Provider.
1205 6.2. Exposing user credentials
1207 Through the use of EAP, user credentials are not visible to anyone
1208 but the IdP of the user. That is, if a sufficiently secure EAP-
1209 method is chosen.
1211 There is one privacy sensitive user attribute that is necessarily
1212 exposed to third parties and that is the realm the user belongs to.
1214 Routing in eduroam is based on the realm part of the user identifier,
1215 so even though the outer identity in a tunneled EAP-method may be set
1216 to an anonymous identifier it MUST contain the realm of the user, and
1217 may thus lead to identifying the user if the realm in question
1218 contains few users. This is considered a reasonable trade-of between
1219 user privacy and usability.
1221 6.3. Track location of users
1223 Due to the fact that access requests (potentially) travel through a
1224 number of proxy RADIUS servers, the home IdP of the user typically
1225 cannot tell where a user roams to.
1227 The introduction of Operator-Name and dynamic lookups (i.e. direct
1228 connections between IdP and SP) however, give the home IdP insight
1229 into the location of the user.
1231 7. Security Considerations
1233 This section addresses only security considerations associated with
1234 the use of eduroam. For considerations relating to IEEE 802.1X,
1235 RADIUS and EAP in general, the reader is referred to the respective
1236 specification and to other literature.
1238 7.1. Man in the middle and Tunneling Attacks
1240 The security of user credentials in eduroam ultimately lies within
1241 the EAP server verification during the EAP conversation. Therefore,
1242 the eduroam policy mandates that only EAP types capable of mutual
1243 authentication are allowed in the infrastructure, and requires that
1244 IdPs publish all information that is required to uniquely identify
1245 the server (i.e. usually the EAP server's CA certificate and its
1246 Common Name or subjectAltName:dNSName).
1248 While this in principle makes Man-in-the-middle attacks impossible,
1249 practice has shown that several attack vectors exist nonetheless.
1250 Most of these deficiencies are due to implementation shortcomings in
1251 EAP supplicants. Examples:
1253 7.1.1. Verification of Server Name not supported
1255 Some supplicants only allow to specify which CA issues the EAP server
1256 certificate; it's name is not checked. As a result, any entity that
1257 is able to get a server certificate from the same CA can create its
1258 own EAP server and trick the end user to submit his credentials to
1259 that fake server.
1261 As a mitigation to that problem, eduroam Operations suggests the use
1262 of a private CA which exclusively issues certificates to the
1263 organisation's EAP servers. In that case, no other entity will get a
1264 certificate from the CA and the above supplicant shortcoming does not
1265 present a security threat any more.
1267 7.1.2. Neither Specification of CA nor Server Name checks during
1268 bootstrap
1270 Some supplicants allow for insecure bootstrapping in that they allow
1271 to simply select a network and accept the incoming server
1272 certificate, identified by its fingerprint. The certificate is then
1273 saved as trusted for later re-connection attempts. If users are near
1274 a fake hotspot during initial provisioning, they may be tricked to
1275 submit their credentials to a fake server; and furthermore will be
1276 branded to trust only that fake server in the future.
1278 eduroam Identity Providers are advised to provide their users with
1279 complete documentation for setup of their supplicants without the
1280 shortcut of insecure bootstrapping. In addition, eduroam Operations
1281 has created a tool which makes correct, complete and secure settings
1282 on many supplicants: eduroam CAT ([eduroam-cat] ).
1284 7.1.3. User does not configure CA or Server Name checks
1286 Unless automatic provisioning tools such as eduroam CAT are used, it
1287 is cumbersome for users to initially configure an EAP supplicant
1288 securely. User Inferfaces of supplicants often invite the users to
1289 take shortcuts ("Don't check server certificate") which are easier to
1290 setup or hide important security settings in badly accessible sub-
1291 menus. Such shortcuts or security parameter ommissions make the user
1292 subject to man-in-the-middle attacks.
1294 eduroam IdPs are advised to educate their users regarding the
1295 necessary steps towards a secure setup. eduroam Research and
1296 Development is in touch with supplicant developers to improve their
1297 User Interfaces.
1299 7.1.4. Tunneling authentication traffic to obfuscate user origin
1301 There is no link between the EAP outer ("anonymous") identity and the
1302 EAP inner ("real") identity. In particular, they can both contain a
1303 realm name, and the realms need not be identical. It is possible to
1304 craft packets with an outer identity of user@RealmB, and an inner
1305 identity of user@realmA. With the eduroam request routing, a Service
1306 Provider would assume that the user is from realmB and send the
1307 request there. The server at realm B inspects the inner user name,
1308 and if proxying is not explicitly disabled for tunneled request
1309 content, may decide to send the tunneled EAP payload to realmA, where
1310 the user authenticates. A CUI value would likely be generated by the
1311 server at realmB, even though this is not its user.
1313 Users can craft such packets to make their identification harder;
1314 usually, the eduroam SP would assume the troublesome user to
1315 originate from realmB and demand there that the user be blocked. The
1316 operator of realmB however has no control over the user, and can only
1317 trace back the user to his real origin if logging of proxied requests
1318 is also enabled for EAP tunnel data.
1320 eduroam Identity Providers are advised to explicitly disable proxying
1321 on the parts of their RADIUS server configuration which processes EAP
1322 tunnel data.
1324 7.2. Denial of Service Attacks
1326 Since eduroam's roaming infrastructure is based on IP and RADIUS, it
1327 suffers from the usual DoS attack vectors that apply to these
1328 protocols.
1330 The eduroam hotspots are susceptible to typical attacks on consumer
1331 edge networks, such as rogue RA, rogue DHCP servers, and others.
1332 Notably, eduroam hotspots are more robust against malign users' DHCP
1333 pool exhaustion than typical open or "captive portal" hotspots,
1334 because a DHCP address is only leased after a successful
1335 authentication, which reduces the pool of possible attackers to
1336 eduroam account holders (as opposed to the general public).
1337 Furthermore, attacks involving ARP spoofing or ARP flooding are also
1338 reduced to authenticated users, because an attacker needs to be in
1339 possession of a valid WPA2 session key to be able to send traffic on
1340 the network.
1342 This section does not discuss standard threats to consumer edge
1343 networks and IP networks in general. The following sections describe
1344 attack vectors specific to eduroam.
1346 7.2.1. Intentional DoS by malign individuals
1348 The eduroam infrastructure is more robust against Distributed DoS
1349 attacks than typical services which are reachable on the internet
1350 because triggering authentication traffic can only be done when
1351 physically being in proximity of an eduroam hotspot (be it a wired
1352 IEEE 802.1X enabled socket or a Wi-Fi Access Point).
1354 However, when being in the vicinity, it is easy to craft
1355 authentication attempts that traverse the entire international
1356 eduroam infrastructure; an attacker merely needs to choose a realm
1357 from another world region than his physical location to trigger
1358 Access-Requests which need to be processed by the SP, then SP-side
1359 national, then world region, then target world region, then target
1360 national, then target IdP server. So long as the realm actually
1361 exists, this will be followed by an entire EAP conversation on that
1362 path. Not having actual credentials, the request will ultimately be
1363 rejected; but it consumed processing power and bandwidth across the
1364 entire infrastructure, possibly affecting all international
1365 authentication traffic.
1367 EAP is a lock-step protocol. A single attacker at an eduroam hotspot
1368 can only execute one EAP conversation after another, and is thus
1369 rate-limited by round-trip times of the RADIUS chain.
1371 Currently eduroam processes several hundred thousands of successful
1372 international roaming authentications per day (and, incidentally,
1373 approximately 1.5 times as many Access-Rejects). With the
1374 requirement of physical proximity, and the rate-limiting induced by
1375 EAP's lock-step nature, it requires a significant amount of attackers
1376 and a time-coordinated attack to produce significant load. So far
1377 eduroam Operations has not yet observed critical load conditions
1378 which could reasonably be attributed to such an attack.
1380 The introduction of dynamic discovery further eases this problem, as
1381 authentications will then not traverse all infrastructure servers,
1382 removing the world-region aggregation servers as obvious bottlenecks.
1383 Any attack would then be limited between an SP and IdP directly.
1385 7.2.2. DoS as a side-effect of expired credentials
1387 In eduroam Operations it is observed that a significant portion of
1388 (failed) eduroam authentications is due to user accounts which were
1389 once valid, but have in the meantime been de-provisioned (e.g. if a
1390 student has left the university after graduation). Configured
1391 eduroam accounts are often retained on the user devices, and when in
1392 the vicinity of an eduroam hotspot, the user device's operating
1393 system will attempt to connect to this network.
1395 As operation of eduroam continues, the amount of devices with left-
1396 over configurations is growing, effectively creating a pool of
1397 devices which produce unwanted network traffic whenever they can.
1399 Up until recently, this problem did not emerge with much prominence,
1400 because there is also a natural shrinking of that pool of devices due
1401 to users finally de-commissioning their old computing hardware.
1403 As of recent, particularly smartphones are programmed to make use of
1404 cloud storage and online backup mechanisms which save most, or all,
1405 configuration details of the device with a third-party. When
1406 renewing their personal computing hardware, users can restore the old
1407 settings onto the new device. It has been observed that expired
1408 eduroam accounts can survive perpetually on user devices that way.
1409 If this trend continues, it can be pictured that an always-growing
1410 pool of devices will clog up eduroam infrastructure with doomed-to-
1411 fail authentication requests.
1413 There is not currently a useful remedy to this problem, other than
1414 instructing users to manually delete their configuration in due time.
1415 Possible approaches to this problem are:
1417 o Creating a culture of device provisioning where the provisioning
1418 profile contains a "ValidUntil" property, after which the
1419 configuration needs to be re-validated or disabled. This requires
1420 a data format for provisioning as well as implementation support.
1422 o Improvements to supplicant software so that it maintains state
1423 over failed authentications. E.g. if a previously known-working
1424 configuration failed to authenticate consistently for 30 calendar
1425 days, it should be considered stale and be disabled.
1427 8. IANA Considerations
1429 There are no IANA Considerations
1431 9. References
1433 9.1. Normative References
1435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1436 Requirement Levels", BCP 14, RFC 2119, March 1997.
1438 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1439 "Remote Authentication Dial In User Service (RADIUS)", RFC
1440 2865, June 2000.
1442 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1444 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1445 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
1446 3748, June 2004.
1448 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
1449 for Transport Layer Security (TLS)", RFC 4279, December
1450 2005.
1452 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
1453 "Chargeable User Identity", RFC 4372, January 2006.
1455 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
1456 Aboba, "Dynamic Authorization Extensions to Remote
1457 Authentication Dial In User Service (RADIUS)", RFC 5176,
1458 January 2008.
1460 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1461 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1463 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
1464 Authentication Protocol (EAP) Key Management Framework",
1465 RFC 5247, August 2008.
1467 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1468 Housley, R., and W. Polk, "Internet X.509 Public Key
1469 Infrastructure Certificate and Certificate Revocation List
1470 (CRL) Profile", RFC 5280, May 2008.
1472 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
1473 Aboba, "Carrying Location Objects in RADIUS and Diameter",
1474 RFC 5580, August 2009.
1476 [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote
1477 Authentication Dial In User Service (RADIUS) Protocol",
1478 RFC 5997, August 2010.
1480 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
1481 Extension Definitions", RFC 6066, January 2011.
1483 [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
1485 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
1486 "Transport Layer Security (TLS) Encryption for RADIUS",
1487 RFC 6614, May 2012.
1489 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
1490 Morris, J., Hansen, M., and R. Smith, "Privacy
1491 Considerations for Internet Protocols", RFC 6973, July
1492 2013.
1494 9.2. Informative References
1496 [I-D.ietf-abfab-arch]
1497 Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
1498 Schaad, "Application Bridging for Federated Access Beyond
1499 Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
1500 in progress), July 2014.
1502 [I-D.ietf-radext-dtls]
1503 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft-
1504 ietf-radext-dtls-13 (work in progress), July 2014.
1506 [I-D.ietf-radext-dynamic-discovery]
1507 Winter, S. and M. McCauley, "NAI-based Dynamic Peer
1508 Discovery for RADIUS/TLS and RADIUS/DTLS", draft-ietf-
1509 radext-dynamic-discovery-11 (work in progress), March
1510 2014.
1512 [I-D.ietf-radext-nai]
1513 DeKok, A., "The Network Access Identifier", draft-ietf-
1514 radext-nai-06 (work in progress), June 2014.
1516 [MD5-attacks]
1517 Black, J., Cochran, M., and T. Highland, "A Study of the
1518 MD5 Attacks: Insights and Improvements", October 2006,
1519 .
1521 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
1522 Accounting (AAA) Transport Profile", RFC 3539, June 2003.
1524 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
1525 Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
1527 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
1528 Service Location Using SRV RRs and the Dynamic Delegation
1529 Discovery Service (DDDS)", RFC 3958, January 2005.
1531 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
1532 Authentication Protocol (EAP) Method Requirements for
1533 Wireless LANs", RFC 4017, March 2005.
1535 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
1536 Key Management", BCP 107, RFC 4107, June 2005.
1538 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1539 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1541 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
1542 4953, July 2007.
1544 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1545 Verification of Domain-Based Application Service Identity
1546 within Internet Public Key Infrastructure Using X.509
1547 (PKIX) Certificates in the Context of Transport Layer
1548 Security (TLS)", RFC 6125, March 2011.
1550 [RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote
1551 Authentication Dial-In User Service (RADIUS)", RFC 6421,
1552 November 2011.
1554 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
1555 "Tunnel Extensible Authentication Protocol (TEAP) Version
1556 1", RFC 7170, May 2014.
1558 [dead-realm]
1559 Tomasek, J., "Dead-realm marking feature for Radiator
1560 RADIUS servers", 2006,
1561 .
1563 [dot1X-standard]
1564 IEEE, "IEEE std 802.1X-2010", February 2010,
1565 .
1568 [edupki] Delivery of Advanced Network Technology to Europe,
1569 "eduPKI", 2012, .
1572 [eduroam-cat]
1573 Delivery of Advanced Network Technology to Europe,
1574 "eduroam CAT", 2012, .
1576 [eduroam-compliance]
1577 Trans-European Research and Education Networking
1578 Association, "eduroam compliance statement", 2011,
1579 .
1582 [eduroam-homepage]
1583 Trans-European Research and Education Networking
1584 Association, "eduroam Homepage", 2007,
1585 .
1587 [eduroam-policy]
1588 Delivery of Advanced Network Technology to Europe,
1589 "European Confederation eduroam policy", 2011,
1590 .
1593 [eduroam-service-definition]
1594 Delivery of Advanced Network Technology to Europe,
1595 "European eduroam policy Service Definition", 2011,
1596 .
1599 [eduroam-start]
1600 Wierenga, K., "Initial proposal for what is now called
1601 eduroam", 2002, .
1604 [geant2] Delivery of Advanced Network Technology to Europe,
1605 "European Commission Information Society and Media:
1606 GEANT2", 2008, .
1608 [nrenroaming-select]
1609 Trans-European Research and Education Networking
1610 Association, "Preliminary selection for inter-NREN
1611 roaming", 2003, .
1614 [radsec-whitepaper]
1615 Open System Consultants, "RadSec - a secure, reliable
1616 RADIUS Protocol", May 2005,
1617 .
1619 [radsecproxy-impl]
1620 Venaas, S., "radsecproxy Project Homepage", 2007,
1621 .
1623 [terena] TERENA, "Trans-European Research and Education Networking
1624 Association", 2008, .
1626 Appendix A. Acknowledgments
1628 The authors would like to thank the participants in the TERENA Task
1629 Force on Mobility and Network Middleware as well as the Geant project
1630 for their reviews and contributions. Special thanks go to Jim Schaad
1631 for doing an excellent review of the first version.
1633 The eduroam trademark is registered by TERENA.
1635 Appendix B. Changes
1637 This section to be removed prior to publication.
1639 o 00 Initial Revision
1640 o 01 Added Dynamic Discovery, addressed review comments
1642 o 02 Cosmetic changes
1644 o 03 Even More Cosmetic Changes
1646 o 04 Included review comments from Jim Schaad
1648 Authors' Addresses
1650 Klaas Wierenga
1651 Cisco Systems
1652 Haarlerbergweg 13-19
1653 Amsterdam 1101 CH
1654 The Netherlands
1656 Phone: +31 20 357 1752
1657 Email: klaas@cisco.com
1659 Stefan Winter
1660 Fondation RESTENA
1661 6, rue Richard Coudenhove-Kalergi
1662 Luxembourg 1359
1663 Luxembourg
1665 Phone: +352 424409 1
1666 Fax: +352 422473
1667 Email: stefan.winter@restena.lu
1668 URI: http://www.restena.lu.
1670 Tomasz Wolniewicz
1671 Nicolaus Copernicus University
1672 pl. Rapackiego 1
1673 Torun
1674 Poland
1676 Phone: +48-56-611-2750
1677 Fax: +48-56-622-1850
1678 Email: twoln@umk.pl
1679 URI: http://www.home.umk.pl/~twoln/