Add compile option to disable internal handling of fatal signals
[strongswan.git] / doc / standards / rfc3579.txt
1
2
3
4
5
6
7 Network Working Group                                           B. Aboba
8 Request for Comments: 3579                                     Microsoft
9 Updates: 2869                                                 P. Calhoun
10 Category: Informational                                        Airespace
11                                                           September 2003
12
13
14           RADIUS (Remote Authentication Dial In User Service)
15           Support For Extensible Authentication Protocol (EAP)
16
17 Status of this Memo
18
19    This memo provides information for the Internet community.  It does
20    not specify an Internet standard of any kind.  Distribution of this
21    memo is unlimited.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2003).  All Rights Reserved.
26
27 Abstract
28
29    This document defines Remote Authentication Dial In User Service
30    (RADIUS) support for the Extensible Authentication Protocol (EAP), an
31    authentication framework which supports multiple authentication
32    mechanisms.  In the proposed scheme, the Network Access Server (NAS)
33    forwards EAP packets to and from the RADIUS server, encapsulated
34    within EAP-Message attributes.  This has the advantage of allowing
35    the NAS to support any EAP authentication method, without the need
36    for method-specific code, which resides on the RADIUS server.  While
37    EAP was originally developed for use with PPP, it is now also in use
38    with IEEE 802.
39
40    This document updates RFC 2869.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Aboba & Calhoun              Informational                      [Page 1]
59 \f
60 RFC 3579                      RADIUS & EAP                September 2003
61
62
63 Table of Contents
64
65    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
66        1.1.  Specification of Requirements. . . . . . . . . . . . . .  3
67        1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
68    2.  RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . .  4
69        2.1.  Protocol Overview. . . . . . . . . . . . . . . . . . . .  5
70        2.2.  Invalid Packets. . . . . . . . . . . . . . . . . . . . .  9
71        2.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . 10
72        2.4.  Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
73        2.5.  Alternative uses . . . . . . . . . . . . . . . . . . . . 11
74        2.6.  Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
75    3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
76        3.1.  EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
77        3.2.  Message-Authenticator. . . . . . . . . . . . . . . . . . 16
78        3.3.  Table of Attributes. . . . . . . . . . . . . . . . . . . 18
79    4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 19
80        4.1.  Security Requirements. . . . . . . . . . . . . . . . . . 19
81        4.2.  Security Protocol. . . . . . . . . . . . . . . . . . . . 20
82        4.3.  Security Issues. . . . . . . . . . . . . . . . . . . . . 22
83    5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
84    6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
85        6.1.  Normative References . . . . . . . . . . . . . . . . . . 30
86        6.2.  Informative References . . . . . . . . . . . . . . . . . 32
87    Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
88    Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
89    Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
90    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
91    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
92    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
93
94 1.  Introduction
95
96    The Remote Authentication Dial In User Service (RADIUS) is an
97    authentication, authorization and accounting protocol used to control
98    network access.  RADIUS authentication and authorization is specified
99    in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS
100    over IPv6 is specified in [RFC3162].
101
102    The Extensible Authentication Protocol (EAP), defined in [RFC2284],
103    is an authentication framework which supports multiple authentication
104    mechanisms.  EAP may be used on dedicated links, switched circuits,
105    and wired as well as wireless links.
106
107    To date, EAP has been implemented with hosts and routers that connect
108    via switched circuits or dial-up lines using PPP [RFC1661].  It has
109    also been implemented with bridges supporting [IEEE802].  EAP
110    encapsulation on IEEE 802 wired media is described in [IEEE8021X].
111
112
113
114 Aboba & Calhoun              Informational                      [Page 2]
115 \f
116 RFC 3579                      RADIUS & EAP                September 2003
117
118
119    RADIUS attributes are comprised of variable length Type-Length-Value
120    3-tuples.  New attribute values can be added without disturbing
121    existing implementations of the protocol.  This specification
122    describes RADIUS attributes supporting the Extensible Authentication
123    Protocol (EAP): EAP-Message and Message-Authenticator.  These
124    attributes now have extensive field experience.  The purpose of this
125    document is to provide clarification and resolve interoperability
126    issues.
127
128    As noted in [RFC2865], a Network Access Server (NAS) that does not
129    implement a given service MUST NOT implement the RADIUS attributes
130    for that service.  This implies that a NAS that is unable to offer
131    EAP service MUST NOT implement the RADIUS attributes for EAP.  A NAS
132    MUST treat a RADIUS Access-Accept requesting an unavailable service
133    as an Access-Reject instead.
134
135 1.1.  Specification of Requirements
136
137    In this document, several words are used to signify the requirements
138    of the specification.  These words are often capitalized.  The key
139    words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
140    "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document
141    are to be interpreted as described in [RFC2119].
142
143 1.2.  Terminology
144
145    This document frequently uses the following terms:
146
147    authenticator
148              The end of the link requiring the authentication.  Also
149              known as the Network Access Server (NAS) or RADIUS client.
150              Within IEEE 802.1X terminology, the term Authenticator is
151              used.
152
153    peer      The other end of the point-to-point link (PPP),
154              point-to-point LAN segment (IEEE 802.1X) or wireless link,
155              which is being authenticated by the authenticator.  In IEEE
156              802.1X, this end is known as the Supplicant.
157
158    authentication server
159              An authentication server is an entity that provides an
160              authentication service to an authenticator (NAS).  This
161              service verifies from the credentials provided by the peer,
162              the claim of identity made by the peer; it also may provide
163              credentials allowing the peer to verify the identity of the
164              authentication server.  Within this document it is assumed
165              that the NAS operates as a pass-through, forwarding EAP
166              packets between the RADIUS server and the EAP peer.
167
168
169
170 Aboba & Calhoun              Informational                      [Page 3]
171 \f
172 RFC 3579                      RADIUS & EAP                September 2003
173
174
175              Therefore the RADIUS server operates as an authentication
176              server.
177
178    silently discard
179              This means the implementation discards the packet without
180              further processing.  The implementation SHOULD provide the
181              capability of logging the error, including the contents of
182              the silently discarded packet, and SHOULD record the event
183              in a statistics counter.
184
185    displayable message
186              This is interpreted to be a human readable string of
187              characters, and MUST NOT affect operation of the protocol.
188              The message encoding MUST follow the UTF-8 transformation
189              format [RFC2279].
190
191    Network Access Server (NAS)
192              The device providing access to the network.  Also known as
193              the Authenticator (IEEE 802.1X or EAP terminology) or
194              RADIUS client.
195
196    service   The NAS provides a service to the user, such as IEEE 802 or
197              PPP.
198
199    session   Each service provided by the NAS to a peer constitutes a
200              session, with the beginning of the session defined as the
201              point where service is first provided and the end of the
202              session defined as the point where service is ended.  A
203              peer may have multiple sessions in parallel or series if
204              the NAS supports that, with each session generating a
205              separate start and stop accounting record.
206
207 2.  RADIUS Support for EAP
208
209    The Extensible Authentication Protocol (EAP), described in [RFC2284],
210    provides a standard mechanism for support of additional
211    authentication methods without the NAS to be upgraded to support each
212    new method.  Through the use of EAP, support for a number of
213    authentication schemes may be added, including smart cards, Kerberos
214    [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and
215    others.
216
217    One of the advantages of the EAP architecture is its flexibility.
218    EAP is used to select a specific authentication mechanism.  Rather
219    than requiring the NAS to be updated to support each new
220    authentication method, EAP permits the use of an authentication
221    server implementing authentication methods, with the NAS acting as a
222    pass-through for some or all methods and peers.
223
224
225
226 Aboba & Calhoun              Informational                      [Page 4]
227 \f
228 RFC 3579                      RADIUS & EAP                September 2003
229
230
231    A NAS MAY authenticate local peers while at the same time acting as a
232    pass-through for non-local peers and authentication methods it does
233    not implement locally.  A NAS implementing this specification is not
234    required to use RADIUS to authenticate every peer.  However, once the
235    NAS begins acting as a pass-through for a particular session, it can
236    no longer perform local authentication for that session.
237
238    In order to support EAP within RADIUS, two new attributes,
239    EAP-Message and Message-Authenticator, are introduced in this
240    document.  This section describes how these new attributes may be
241    used for providing EAP support within RADIUS.
242
243 2.1.  Protocol Overview
244
245    In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP
246    Packets between the NAS and an authentication server.
247
248    The authenticating peer and the NAS begin the EAP conversation by
249    negotiating use of EAP.  Once EAP has been negotiated, the NAS SHOULD
250    send an initial EAP-Request message to the authenticating peer.  This
251    will typically be an EAP-Request/Identity, although it could be an
252    EAP-Request for an authentication method (Types 4 and greater).  A
253    NAS MAY be configured to initiate with a default authentication
254    method.  This is useful in cases where the identity is determined by
255    another means (such as Called-Station-Id, Calling-Station-Id and/or
256    Originating-Line-Info); where a single authentication method is
257    required, which includes its own identity exchange; where identity
258    hiding is desired, so that the identity is not requested until after
259    a protected channel has been set up.
260
261    The peer replies with an EAP-Response.  The NAS MAY determine from
262    the Response that it should proceed with local authentication.
263    Alternatively, the NAS MAY act as a pass-through, encapsulating the
264    EAP-Response within EAP-Message attribute(s) sent to the RADIUS
265    server within a RADIUS Access-Request packet.  If the NAS sends an
266    EAP-Request/Identity message as the initial packet, the peer responds
267    with an EAP-Response/Identity.  The NAS may determine that the peer
268    is local and proceed with local authentication.  If no match is found
269    against the list of local users, the NAS encapsulates the
270    EAP-Response/Identity message within an EAP-Message attribute,
271    enclosed within an Access-Request packet.
272
273    On receiving a valid Access-Request packet containing EAP-Message
274    attribute(s), a RADIUS server compliant with this specification and
275    wishing to authenticate with EAP MUST respond with an
276    Access-Challenge packet containing EAP-Message attribute(s).  If the
277    RADIUS server does not support EAP or does not wish to authenticate
278    with EAP, it MUST respond with an Access-Reject.
279
280
281
282 Aboba & Calhoun              Informational                      [Page 5]
283 \f
284 RFC 3579                      RADIUS & EAP                September 2003
285
286
287    EAP-Message attribute(s) encapsulate a single EAP packet which the
288    NAS decapsulates and passes on to the authenticating peer.  The peer
289    then responds with an EAP-Response packet, which the NAS encapsulates
290    within an Access-Request containing EAP-Message attribute(s).  EAP is
291    a 'lock step' protocol, so that other than the initial Request, a new
292    Request cannot be sent prior to receiving a valid Response.
293
294    The conversation continues until either a RADIUS Access-Reject or
295    Access-Accept packet is received from the RADIUS server.  Reception
296    of a RADIUS Access-Reject packet MUST result in the NAS denying
297    access to the authenticating peer.  A RADIUS Access-Accept packet
298    successfully ends the authentication phase.  The NAS MUST NOT
299    "manufacture" a Success or Failure packet as the result of a timeout.
300    After a suitable number of timeouts have elapsed, the NAS SHOULD
301    instead end the EAP conversation.
302
303    Using RADIUS, the NAS can act as a pass-through for an EAP
304    conversation between the peer and authentication server, without
305    needing to implement the EAP method used between them.  Where the NAS
306    initiates the conversation by sending an EAP-Request for an
307    authentication method, it may not be required that the NAS fully
308    implement the EAP method reflected in the initial EAP-Request.
309    Depending on the initial method, it may be sufficient for the NAS to
310    be configured with the initial packet to be sent to the peer, and for
311    the NAS to act as a pass-through for subsequent messages.  Note that
312    since the NAS only encapsulates the EAP-Response in its initial
313    Access-Request, the initial EAP-Request within the authentication
314    method is not available to the RADIUS server.  For the RADIUS server
315    to be able to continue the conversation, either the initial
316    EAP-Request is vestigial, so that the RADIUS server need not be aware
317    of it, or the relevant information from the initial EAP-Request (such
318    as a nonce) is reflected in the initial EAP-Response, so that the
319    RADIUS server can obtain it without having received the initial
320    EAP-Request.
321
322    Where the initial EAP-Request sent by the NAS is for an
323    authentication Type (4 or greater), the peer MAY respond with a Nak
324    indicating that it would prefer another authentication method that is
325    not implemented locally.  In this case, the NAS SHOULD send
326    Access-Request encapsulating the received EAP-Response/Nak.  This
327    provides the RADIUS server with a hint about the authentication
328    method(s) preferred by the peer, although it does not provide
329    information on the Type of the original Request.  It also provides
330    the server with the Identifier used in the initial EAP-Request, so
331    that Identifier conflicts can be avoided.
332
333
334
335
336
337
338 Aboba & Calhoun              Informational                      [Page 6]
339 \f
340 RFC 3579                      RADIUS & EAP                September 2003
341
342
343    In order to evaluate whether the alternatives preferred by the
344    authenticating peer are allowed, the RADIUS server will typically
345    respond with an Access-Challenge containing EAP-Message attribute(s)
346    encapsulating an EAP-Request/Identity (Type 1).  This allows the
347    RADIUS server to determine the peer identity, so as to be able to
348    retrieve the associated authentication policy.  Alternatively, an
349    EAP-Request for an authentication method (Type 4 or greater) could be
350    sent.  Since the RADIUS server may not be aware of the Type of the
351    initial EAP-Request, it is possible for the RADIUS server to choose
352    an unacceptable method, and for the peer to respond with another Nak.
353
354    In order to permit non-EAP aware RADIUS proxies to forward the
355    Access-Request packet, if the NAS initially sends an
356    EAP-Request/Identity message to the peer, the NAS MUST copy the
357    contents of the Type-Data field of the EAP-Response/Identity received
358    from the peer into the User-Name attribute and MUST include the
359    Type-Data field of the EAP-Response/Identity in the User-Name
360    attribute in every subsequent Access-Request.  Since RADIUS proxies
361    are assumed to act as a pass-through, they cannot be expected to
362    parse an EAP-Response/Identity encapsulated within EAP-Message
363    attribute(s).  If the NAS initially sends an EAP-Request for an
364    authentication method, and the peer identity cannot be determined
365    from the EAP-Response, then the User-Name attribute SHOULD be
366    determined by another means.  As noted in [RFC2865] Section 5.6, it
367    is recommended that Access-Requests use the value of the
368    Calling-Station-Id as the value of the User-Name attribute.
369
370    Having the NAS send the initial EAP-Request packet has a number of
371    advantages:
372
373    [1]  It saves a round trip between the NAS and RADIUS server.
374
375    [2]  An Access-Request is only sent to the RADIUS server if the
376         authenticating peer sends an EAP-Response, confirming that it
377         supports EAP.  In situations where peers may be EAP unaware,
378         initiating a RADIUS Access-Request on a "carrier sense" or
379         "media up" indication may result in many authentication
380         exchanges that cannot complete successfully.  For example, on
381         wired networks [IEEE8021X] Supplicants typically do not initiate
382         the 802.1X conversation with an EAPOL-Start.  Therefore an IEEE
383         802.1X-enabled bridge may not be able to determine whether the
384         peer supports EAP until it receives a Response to the initial
385         EAP-Request.
386
387    [3]  It allows some peers to be authenticated locally.
388
389
390
391
392
393
394 Aboba & Calhoun              Informational                      [Page 7]
395 \f
396 RFC 3579                      RADIUS & EAP                September 2003
397
398
399    Although having the NAS send the initial EAP-Request packet has
400    substantial advantages, this technique cannot be universally
401    employed.  There are circumstances in which the peer identity is
402    already known (such as when authentication and accounting is handled
403    based on Called-Station-Id, Calling-Station-Id and/or
404    Originating-Line-Info), but where the appropriate EAP method may vary
405    based on that identity.
406
407    Rather than sending an initial EAP-Request packet to the
408    authenticating peer, on detecting the presence of the peer, the NAS
409    MAY send an Access-Request packet to the RADIUS server containing an
410    EAP-Message attribute signifying EAP-Start.  The RADIUS server will
411    typically respond with an Access-Challenge containing EAP-Message
412    attribute(s) encapsulating an EAP-Request/Identity (Type 1).
413    However, an EAP-Request for an authentication method (Type 4 or
414    greater) can also be sent by the server.
415
416    EAP-Start is indicated by sending an EAP-Message attribute with a
417    length of 2 (no data).  The Calling-Station-Id SHOULD be included in
418    the User-Name attribute.  This may result in a RADIUS Access-Request
419    being sent by the NAS to the RADIUS server without first confirming
420    that the peer supports EAP.  Since this technique can result in a
421    large number of uncompleted RADIUS conversations, in situations where
422    EAP unaware peers are common, or where peer support for EAP cannot be
423    determined on initial contact (e.g. [IEEE8021X] Supplicants not
424    initiating the conversation with an EAPOL-Start) it SHOULD NOT be
425    employed by default.
426
427    For proxied RADIUS requests, there are two methods of processing.  If
428    the domain is determined based on the Calling-Station-Id,
429    Called-Station-Id and/or Originating-Line-Info, the RADIUS server may
430    proxy the initial RADIUS Access-Request/EAP-Start.  If the realm is
431    determined based on the peer identity, the local RADIUS server MUST
432    respond with a RADIUS Access-Challenge including an EAP-Message
433    attribute encapsulating an EAP-Request/Identity packet.  The response
434    from the authenticating peer SHOULD be proxied to the final
435    authentication server.
436
437    If an Access-Request is sent to a RADIUS server which does not
438    support the EAP-Message attribute, then an Access-Reject MUST be sent
439    in response.  On receiving an Access-Reject, the NAS MUST deny access
440    to the authenticating peer.
441
442
443
444
445
446
447
448
449
450 Aboba & Calhoun              Informational                      [Page 8]
451 \f
452 RFC 3579                      RADIUS & EAP                September 2003
453
454
455 2.2.  Invalid Packets
456
457    While acting as a pass-through, the NAS MUST validate the EAP header
458    fields (Code, Identifier, Length) prior to forwarding an EAP packet
459    to or from the RADIUS server.  On receiving an EAP packet from the
460    peer, the NAS checks the Code (2) and Length fields, and matches the
461    Identifier value against the current Identifier, supplied by the
462    RADIUS server in the most recently validated EAP-Request.  On
463    receiving an EAP packet from the RADIUS server (encapsulated within
464    an Access-Challenge), the NAS checks the Code (1) and Length fields,
465    then updates the current Identifier value.  Pending EAP Responses
466    that do not match the current Identifier value are silently discarded
467    by the NAS.
468
469    Since EAP method fields (Type, Type-Data) are typically not validated
470    by a NAS operating as a pass-through, despite these checks it is
471    possible for a NAS to forward an invalid EAP packet to or from the
472    RADIUS server.  A RADIUS server receiving EAP-Message attribute(s) it
473    does not understand SHOULD make the determination of whether the
474    error is fatal or non-fatal based on the EAP Type.  A RADIUS server
475    determining that a fatal error has occurred MUST send an
476    Access-Reject containing an EAP-Message attribute encapsulating
477    EAP-Failure.
478
479    A RADIUS server determining that a non-fatal error has occurred MAY
480    send an Access-Challenge to the NAS including EAP-Message
481    attribute(s) as well as an Error-Cause attribute [RFC3576] with value
482    202 (decimal), "Invalid EAP Packet (Ignored)".  The Access-Challenge
483    SHOULD encapsulate within EAP-Message attribute(s) the most recently
484    sent EAP-Request packet (including the same Identifier value).  On
485    receiving such an Access-Challenge, a NAS implementing previous
486    versions of this specification will decapsulate the EAP-Request and
487    send it to the peer, which will retransmit the EAP-Response.
488
489    A NAS compliant with this specification, on receiving an
490    Access-Challenge with an Error-Cause attribute of value 202 (decimal)
491    SHOULD discard the EAP-Response packet most recently transmitted to
492    the RADIUS server and check whether additional EAP-Response packets
493    have been received matching the current Identifier value.  If so, a
494    new EAP-Response packet, if available, MUST be sent to the RADIUS
495    server within an Access-Request, and the EAP-Message attribute(s)
496    included within the Access-Challenge are silently discarded.  If no
497    EAP-Response packet is available, then the EAP-Request encapsulated
498    within the Access-Challenge is sent to the peer, and the
499    retransmission timer is reset.
500
501
502
503
504
505
506 Aboba & Calhoun              Informational                      [Page 9]
507 \f
508 RFC 3579                      RADIUS & EAP                September 2003
509
510
511    In order to provide protection against Denial of Service (DoS)
512    attacks, it is advisable for the NAS to allocate a finite buffer for
513    EAP packets received from the peer, and to discard packets according
514    to an appropriate policy once that buffer has been exceeded.  Also,
515    the RADIUS server is advised to permit only a modest number of
516    invalid EAP packets within a single session, prior to terminating the
517    session with an Access-Reject.  By default a value of 5 invalid EAP
518    packets is recommended.
519
520 2.3.  Retransmission
521
522    As noted in [RFC2284], if an EAP packet is lost in transit between
523    the authenticating peer and the NAS (or vice versa), the NAS will
524    retransmit.
525
526    It may be necessary to adjust retransmission strategies and
527    authentication timeouts in certain cases.  For example, when a token
528    card is used additional time may be required to allow the user to
529    find the card and enter the token.  Since the NAS will typically not
530    have knowledge of the required parameters, these need to be provided
531    by the RADIUS server.  This can be accomplished by inclusion of
532    Session-Timeout attribute within the Access-Challenge packet.
533
534    If Session-Timeout is present in an Access-Challenge packet that also
535    contains an EAP-Message, the value of the Session-Timeout is used to
536    set the EAP retransmission timer for that EAP Request, and that
537    Request alone.  Once the EAP-Request has been sent, the NAS sets the
538    retransmission timer, and if it expires without having received an
539    EAP-Response corresponding to the Request, then the EAP-Request is
540    retransmitted.
541
542 2.4.  Fragmentation
543
544    Using the EAP-Message attribute, it is possible for the RADIUS server
545    to encapsulate an EAP packet that is larger than the MTU on the link
546    between the NAS and the peer.  Since it is not possible for the
547    RADIUS server to use MTU discovery to ascertain the link MTU, the
548    Framed-MTU attribute may be included in an Access-Request packet
549    containing an EAP-Message attribute so as to provide the RADIUS
550    server with this information.  A RADIUS server having received a
551    Framed-MTU attribute in an Access-Request packet MUST NOT send any
552    subsequent packet in this EAP conversation containing EAP-Message
553    attributes whose values, when concatenated, exceed the length
554    specified by the Framed-MTU value, taking the link type (specified by
555    the NAS-Port-Type attribute) into account.  For example, as noted in
556    [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the
557
558
559
560
561
562 Aboba & Calhoun              Informational                     [Page 10]
563 \f
564 RFC 3579                      RADIUS & EAP                September 2003
565
566
567    RADIUS server may send an EAP packet as large as Framed-MTU minus
568    four (4) octets, taking into account the additional overhead for the
569    IEEE 802.1X Version (1), Type (1) and Body Length (2) fields.
570
571 2.5.  Alternative Uses
572
573    Currently the conversation between security servers and the RADIUS
574    server is often proprietary because of lack of standardization.  In
575    order to increase standardization and provide interoperability
576    between RADIUS vendors and  security vendors, it is recommended that
577    RADIUS- encapsulated EAP be used for this conversation.
578
579    This has the advantage of allowing the RADIUS server to support EAP
580    without the need for authentication-specific code within the RADIUS
581    server.  Authentication-specific code can then reside on a security
582    server instead.
583
584    In the case where RADIUS-encapsulated EAP is used in a conversation
585    between a RADIUS server and a security server, the security server
586    will typically return an Access-Accept message without inclusion of
587    the expected attributes currently returned in an Access-Accept.  This
588    means that the RADIUS server MUST add these attributes prior to
589    sending an Access-Accept message to the NAS.
590
591 2.6.  Usage Guidelines
592
593 2.6.1.  Identifier Space
594
595    In EAP, each session has its own unique Identifier space.  RADIUS
596    server implementations MUST be able to distinguish between EAP
597    packets with the same Identifier existing within distinct sessions,
598    originating on the same NAS.  For this purpose, sessions can be
599    distinguished based on NAS and session identification attributes.
600    NAS identification attributes include NAS-Identifier,
601    NAS-IPv6-Address and NAS-IPv4-Address.  Session identification
602    attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id,
603    Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
604
605 2.6.2.  Role Reversal
606
607    Since EAP is a peer-to-peer protocol, an independent and simultaneous
608    authentication may take place in the reverse direction.  Both peers
609    may act as authenticators and authenticatees at the same time.
610
611    However, role reversal is not supported by this specification.  A
612    RADIUS server MUST respond to an Access-Request encapsulating an
613    EAP-Request with an Access-Reject.  In order to avoid retransmissions
614
615
616
617
618 Aboba & Calhoun              Informational                     [Page 11]
619 \f
620 RFC 3579                      RADIUS & EAP                September 2003
621
622
623    by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
624    packet indicating no preferred method, encapsulated within
625    EAP-Message attribute(s).
626
627 2.6.3.  Conflicting Messages
628
629    The NAS MUST make its access control decision based solely on the
630    RADIUS Packet Type (Access-Accept/Access-Reject).  The access control
631    decision MUST NOT be based on the contents of the EAP packet
632    encapsulated in one or more EAP-Message attributes, if present.
633
634    Access-Accept packets SHOULD have only one EAP-Message attribute in
635    them, containing EAP Success; similarly, Access-Reject packets SHOULD
636    have only one EAP-Message attribute in them, containing EAP Failure.
637
638    Where the encapsulated EAP packet does not match the result implied
639    by the RADIUS Packet Type, the combination is likely to cause
640    confusion, because the NAS and peer will arrive at different
641    conclusions as to the outcome of the authentication.
642
643    For example, if the NAS receives an Access-Reject with an
644    encapsulated EAP Success, it will not grant access to the peer.
645    However, on receiving the EAP Success, the peer will be lead to
646    believe that it authenticated successfully.
647
648    If the NAS receives an Access-Accept with an encapsulated EAP
649    Failure, it will grant access to the peer.  However, on receiving an
650    EAP Failure, the peer will be lead to believe that it failed
651    authentication.  If no EAP-Message attribute is included within an
652    Access-Accept or Access-Reject, then the peer may not be informed as
653    to the outcome of the authentication, while the NAS will take action
654    to allow or deny access.
655
656    As described in [RFC2284], the EAP Success and Failure packets are
657    not acknowledged, and these packets terminate the EAP conversation.
658    As a result, if these packets are encapsulated within an
659    Access-Challenge, no response will be received, and therefore the NAS
660    will send no further Access-Requests to the RADIUS server for the
661    session.  As a result, the RADIUS server will not indicate to the NAS
662    whether to allow or deny access, while the peer will be informed as
663    to the outcome of the authentication.
664
665
666
667
668
669
670
671
672
673
674 Aboba & Calhoun              Informational                     [Page 12]
675 \f
676 RFC 3579                      RADIUS & EAP                September 2003
677
678
679    To avoid these conflicts, the following combinations SHOULD NOT be
680    sent by a RADIUS server:
681
682       Access-Accept/EAP-Message/EAP Failure
683       Access-Accept/no EAP-Message attribute
684       Access-Accept/EAP-Start
685       Access-Reject/EAP-Message/EAP Success
686       Access-Reject/no EAP-Message attribute
687       Access-Reject/EAP-Start
688       Access-Challenge/EAP-Message/EAP Success
689       Access-Challenge/EAP-Message/EAP Failure
690       Access-Challenge/no EAP-Message attribute
691       Access-Challenge/EAP-Start
692
693    Since the responsibility for avoiding conflicts lies with the RADIUS
694    server, the NAS MUST NOT "manufacture" EAP packets in order to
695    correct contradictory messages that it receives.  This behavior,
696    originally mandated within [IEEE8021X], will be deprecated in the
697    future.
698
699 2.6.4.  Priority
700
701    A RADIUS Access-Accept or Access-Reject packet may contain EAP-
702    Message attribute(s). In order to ensure the correct processing of
703    RADIUS packets, the NAS MUST first process the attributes, including
704    the EAP-Message attribute(s), prior to processing the Accept/Reject
705    indication.
706
707 2.6.5.  Displayable Messages
708
709    The Reply-Message attribute, defined in [RFC2865], Section 5.18,
710    indicates text which may be displayed to the peer.  This is similar
711    in concept to EAP Notification, defined in [RFC2284].  When sending a
712    displayable message to a NAS during an EAP conversation, the RADIUS
713    server MUST encapsulate displayable messages within
714    EAP-Message/EAP-Request/Notification attribute(s).  Reply-Message
715    attribute(s) MUST NOT be included in any RADIUS message containing an
716    EAP-Message attribute.  An EAP-Message/EAP-Request/Notification
717    SHOULD NOT be included within an Access-Accept or Access-Reject
718    packet.
719
720    In some existing implementations, a NAS receiving Reply-Message
721    attribute(s) copies the Text field(s) into the Type-Data field of an
722    EAP-Request/Notification packet, fills in the Identifier field, and
723    sends this to the peer.  However, several issues arise from this:
724
725
726
727
728
729
730 Aboba & Calhoun              Informational                     [Page 13]
731 \f
732 RFC 3579                      RADIUS & EAP                September 2003
733
734
735    [1]  Unexpected Responses.  On receiving an EAP-Request/Notification,
736         the peer will send an EAP-Response/Notification, and the NAS
737         will pass this on to the RADIUS server, encapsulated within
738         EAP-Message attribute(s).  However, the RADIUS server may not be
739         expecting an Access-Request containing an
740         EAP-Message/EAP-Response/Notification attribute.
741
742         For example, consider what happens when a Reply-Message is
743         included within an Access-Accept or Access-Reject packet with no
744         EAP-Message attribute(s) present.  If the value of the
745         Reply-Message attribute is copied into the Type-Data of an
746         EAP-Request/Notification and sent to the peer, this will result
747         in an Access-Request containing an
748         EAP-Message/EAP-Response/Notification attribute being sent by
749         the NAS to the RADIUS server.  Since an Access-Accept or
750         Access-Reject packet terminates the RADIUS conversation, such an
751         Access-Request would not be expected, and could be interpreted
752         as the start of another conversation.
753
754    [2]  Identifier conflicts.  While the EAP-Request/Notification is an
755         EAP packet containing an Identifier field, the Reply-Message
756         attribute does not contain an Identifier field.  As a result, a
757         NAS receiving a Reply-Message attribute and wishing to translate
758         this to an EAP-Request/Notification will need to choose an
759         Identifier value.  It is possible that the chosen Identifier
760         value will conflict with a value chosen by the RADIUS server for
761         another packet within the EAP conversation, potentially causing
762         confusion between a new packet and a retransmission.
763
764    To avoid these problems, a NAS receiving a Reply-Message attribute
765    from the RADIUS server SHOULD silently discard the attribute, rather
766    than attempting to translate it to an EAP Notification Request.
767
768 3.  Attributes
769
770    The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS
771    in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
772    or NAS-IPv6-Address attributes MUST be included.  In order to permit
773    forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name
774    attribute was included in an Access-Request, the RADIUS server MUST
775    include the User-Name attribute in subsequent Access-Accept packets.
776    Without the User-Name attribute, accounting and billing becomes
777    difficult to manage.  The User-Name attribute within the Access-
778    Accept packet need not be the same as the User-Name attribute in the
779    Access-Request.
780
781
782
783
784
785
786 Aboba & Calhoun              Informational                     [Page 14]
787 \f
788 RFC 3579                      RADIUS & EAP                September 2003
789
790
791 3.1.  EAP-Message
792
793    Description
794
795       This attribute encapsulates EAP [RFC2284] packets so as to allow
796       the NAS to authenticate peers via EAP without having to understand
797       the EAP method it is passing through.
798
799       The NAS places EAP messages received from the authenticating peer
800       into one or more EAP-Message attributes and forwards them to the
801       RADIUS server within an Access-Request message.  If multiple
802       EAP-Message attributes are contained within an Access-Request or
803       Access-Challenge packet, they MUST be in order and they MUST be
804       consecutive attributes in the Access-Request or Access-Challenge
805       packet.  The RADIUS server can return EAP-Message attributes in
806       Access-Challenge, Access-Accept and Access-Reject packets.
807
808       When RADIUS is used to enable EAP authentication, Access-Request,
809       Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
810       contain one or more EAP-Message attributes.  Where more than one
811       EAP-Message attribute is included, it is assumed that the
812       attributes are to be concatenated to form a single EAP packet.
813
814       Multiple EAP packets MUST NOT be encoded within EAP-Message
815       attributes contained within a single Access-Challenge,
816       Access-Accept, Access-Reject or Access-Request packet.
817
818       It is expected that EAP will be used to implement a variety of
819       authentication methods, including methods involving strong
820       cryptography.  In order to prevent attackers from subverting EAP
821       by attacking RADIUS/EAP, (for example, by modifying EAP Success or
822       EAP Failure packets) it is necessary that RADIUS provide
823       per-packet authentication and integrity protection.
824
825       Therefore the Message-Authenticator attribute MUST be used to
826       protect all Access-Request, Access-Challenge, Access-Accept, and
827       Access-Reject packets containing an EAP-Message attribute.
828
829       Access-Request packets including EAP-Message attribute(s) without
830       a Message-Authenticator attribute SHOULD be silently discarded by
831       the RADIUS server.  A RADIUS server supporting the EAP-Message
832       attribute MUST calculate the correct value of the
833       Message-Authenticator and MUST silently discard the packet if it
834       does not match the value sent.  A RADIUS server not supporting the
835       EAP-Message attribute MUST return an Access-Reject if it receives
836       an Access-Request containing an EAP-Message attribute.
837
838
839
840
841
842 Aboba & Calhoun              Informational                     [Page 15]
843 \f
844 RFC 3579                      RADIUS & EAP                September 2003
845
846
847       Access-Challenge, Access-Accept, or Access-Reject packets
848       including EAP-Message attribute(s) without a Message-Authenticator
849       attribute SHOULD be silently discarded by the NAS.  A NAS
850       supporting the EAP-Message attribute MUST calculate the correct
851       value of the Message-Authenticator and MUST silently discard the
852       packet if it does not match the value sent.
853
854       A summary of the EAP-Message attribute format is shown below.  The
855       fields are transmitted from left to right.
856
857        0                   1                   2
858        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
859       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
860       |     Type      |    Length     |     String...
861       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
862
863    Type
864
865       79 for EAP-Message
866
867    Length
868
869       >= 3
870
871    String
872
873       The String field contains an EAP packet, as defined in [RFC2284].
874       If multiple EAP-Message attributes are present in a packet their
875       values should be concatenated; this allows EAP packets longer than
876       253 octets to be transported by RADIUS.
877
878 3.2.  Message-Authenticator
879
880    Description
881
882       This attribute MAY be used to authenticate and integrity-protect
883       Access-Requests in order to prevent spoofing.  It MAY be used in
884       any Access-Request.  It MUST be used in any Access-Request,
885       Access-Accept, Access-Reject or Access-Challenge that includes an
886       EAP-Message attribute.
887
888       A RADIUS server receiving an Access-Request with a
889       Message-Authenticator attribute present MUST calculate the correct
890       value of the Message-Authenticator and silently discard the packet
891       if it does not match the value sent.
892
893
894
895
896
897
898 Aboba & Calhoun              Informational                     [Page 16]
899 \f
900 RFC 3579                      RADIUS & EAP                September 2003
901
902
903       A RADIUS client receiving an Access-Accept, Access-Reject or
904       Access-Challenge with a Message-Authenticator attribute present
905       MUST calculate the correct value of the Message-Authenticator and
906       silently discard the packet if it does not match the value sent.
907
908       This attribute is not required in Access-Requests which include
909       the User-Password attribute, but is useful for preventing attacks
910       on other types of authentication.  This attribute is intended to
911       thwart attempts by an attacker to setup a "rogue" NAS, and perform
912       online dictionary attacks against the RADIUS server.  It does not
913       afford protection against "offline" attacks where the attacker
914       intercepts packets containing (for example) CHAP challenge and
915       response, and performs a dictionary attack against those packets
916       offline.
917
918       A summary of the Message-Authenticator attribute format is shown
919       below.  The fields are transmitted from left to right.
920
921        0                   1                   2
922        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
923       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
924       |     Type      |    Length     |     String...
925       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
926
927    Type
928
929       80 for Message-Authenticator
930
931    Length
932
933       18
934
935    String
936
937       When present in an Access-Request packet, Message-Authenticator is
938       an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
939       including Type, ID, Length and Authenticator, using the shared
940       secret as the key, as follows.
941
942       Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
943       Request Authenticator, Attributes)
944
945       When the message integrity check is calculated the signature
946       string should be considered to be sixteen octets of zero.
947
948
949
950
951
952
953
954 Aboba & Calhoun              Informational                     [Page 17]
955 \f
956 RFC 3579                      RADIUS & EAP                September 2003
957
958
959       For Access-Challenge, Access-Accept, and Access-Reject packets,
960       the Message-Authenticator is calculated as follows, using the
961       Request-Authenticator from the Access-Request this packet is in
962       reply to:
963
964       Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
965       Request Authenticator, Attributes)
966
967       When the message integrity check is calculated the signature
968       string should be considered to be sixteen octets of zero.  The
969       shared secret is used as the key for the HMAC-MD5 message
970       integrity check.  The Message-Authenticator is calculated and
971       inserted in the packet before the Response Authenticator is
972       calculated.
973
974 3.3.  Table of Attributes
975
976    The following table provides a guide to which attributes may be found
977    in packets including EAP-Message attribute(s), and in what quantity.
978    The EAP-Message and Message-Authenticator attributes specified in
979    this document MUST NOT be present in an Accounting-Request.  If a
980    table entry is omitted, the values found in [RFC2548], [RFC2865],
981    [RFC2868], [RFC2869] and [RFC3162] should be assumed.
982
983 Request  Accept  Reject  Challenge   #    Attribute
984 0-1      0-1     0       0            1   User-Name
985 0        0       0       0            2   User-Password [Note 1]
986 0        0       0       0            3   CHAP-Password [Note 1]
987 0        0       0       0           18   Reply-Message
988 0        0       0       0           60   CHAP-Challenge
989 0        0       0       0           70   ARAP-Password [Note 1]
990 0        0       0       0           75   Password-Retry
991 1+       1+      1+      1+          79   EAP-Message [Note 1]
992 1        1       1       1           80   Message-Authenticator [Note 1]
993 0-1      0       0       0           94   Originating-Line-Info [Note 3]
994 0        0       0-1     0-1        101   Error-Cause [Note 2]
995 Request  Accept  Reject  Challenge   #    Attribute
996
997    [Note 1] An Access-Request that contains either a User-Password or
998    CHAP-Password or ARAP-Password or one or more EAP-Message attributes
999    MUST NOT contain more than one type of those four attributes.  If it
1000    does not contain any of those four attributes, it SHOULD contain a
1001    Message-Authenticator.  If any packet type contains an EAP-Message
1002    attribute it MUST also contain a Message-Authenticator.  A RADIUS
1003    server receiving an Access-Request not containing any of those four
1004    attributes and also not containing a Message-Authenticator attribute
1005    SHOULD silently discard it.
1006
1007
1008
1009
1010 Aboba & Calhoun              Informational                     [Page 18]
1011 \f
1012 RFC 3579                      RADIUS & EAP                September 2003
1013
1014
1015    [Note 2] The Error-Cause attribute is defined in [RFC3576].
1016
1017    [Note 3] The Originating-Line-Info attribute is defined in [NASREQ].
1018
1019    The following table defines the meaning of the above table entries.
1020
1021    0     This attribute MUST NOT be present.
1022    0+    Zero or more instances of this attribute MAY be present.
1023    0-1   Zero or one instance of this attribute MAY be present.
1024    1     Exactly one instance of this attribute MUST be present.
1025    1+    One or more of these attributes MUST be present.
1026
1027 4.  Security Considerations
1028
1029 4.1.  Security Requirements
1030
1031    RADIUS/EAP is used in order to provide authentication and
1032    authorization for network access.  As a result, both the RADIUS and
1033    EAP portions of the conversation are potential targets of an attack.
1034    Threats are discussed in [RFC2607], [RFC2865], and [RFC3162].
1035    Examples include:
1036
1037    [1]  An adversary may attempt to acquire confidential data and
1038         identities by snooping RADIUS packets.
1039
1040    [2]  An adversary may attempt to modify packets containing RADIUS
1041         messages.
1042
1043    [3]  An adversary may attempt to inject packets into a RADIUS
1044         conversation.
1045
1046    [4]  An adversary may launch a dictionary attack against the RADIUS
1047         shared secret.
1048
1049    [5]  An adversary may launch a known plaintext attack, hoping to
1050         recover the key stream corresponding to a Request Authenticator.
1051
1052    [6]  An adversary may attempt to replay a RADIUS exchange.
1053
1054    [7]  An adversary may attempt to disrupt the EAP negotiation, in
1055         order to weaken the authentication, or gain access to peer
1056         passwords.
1057
1058    [8]  An authenticated NAS may attempt to forge NAS or session
1059         identification attributes,
1060
1061    [9]  A rogue (unauthenticated) NAS may attempt to impersonate a
1062         legitimate NAS.
1063
1064
1065
1066 Aboba & Calhoun              Informational                     [Page 19]
1067 \f
1068 RFC 3579                      RADIUS & EAP                September 2003
1069
1070
1071    [10] An attacker may attempt to act as a man-in-the-middle.
1072
1073    To address these threats, it is necessary to support confidentiality,
1074    data origin authentication, integrity, and replay protection on a
1075    per-packet basis.  Bi-directional authentication between the RADIUS
1076    client and server also needs to be provided.  There is no requirement
1077    that the identities of RADIUS clients and servers be kept
1078    confidential (e.g., from a passive eavesdropper).
1079
1080 4.2.  Security Protocol
1081
1082    To address the security vulnerabilities of RADIUS/EAP,
1083    implementations of this specification SHOULD support IPsec [RFC2401]
1084    along with IKE [RFC2409] for key management.  IPsec ESP [RFC2406]
1085    with non-null transform SHOULD be supported, and IPsec ESP with a
1086    non-null encryption transform and authentication support SHOULD be
1087    used to provide per-packet confidentiality, authentication, integrity
1088    and replay protection.  IKE SHOULD be used for key management.
1089
1090    Within RADIUS [RFC2865], a shared secret is used for hiding of
1091    attributes such as User-Password, as well as in computation of the
1092    Response Authenticator.  In RADIUS accounting [RFC2866], the shared
1093    secret is used in computation of both the Request Authenticator and
1094    the Response Authenticator.
1095
1096    Since in RADIUS a shared secret is used to provide confidentiality as
1097    well as integrity protection and authentication, only use of IPsec
1098    ESP with a non-null transform can provide security services
1099    sufficient to substitute for RADIUS application-layer security.
1100    Therefore, where IPSEC AH or ESP null is used, it will typically
1101    still be necessary to configure a RADIUS shared secret.
1102
1103    Where RADIUS is run over IPsec ESP with a non-null transform, the
1104    secret shared between the NAS and the RADIUS server MAY NOT be
1105    configured.  In this case, a shared secret of zero length MUST be
1106    assumed.  However, a RADIUS server that cannot know whether incoming
1107    traffic is IPsec-protected MUST be configured with a non-null RADIUS
1108    shared secret.
1109
1110    When IPsec ESP is used with RADIUS, per-packet authentication,
1111    integrity and replay protection MUST be used.  3DES-CBC MUST be
1112    supported as an encryption transform and AES-CBC SHOULD be supported.
1113    AES-CBC SHOULD be offered as a preferred encryption transform if
1114    supported.  HMAC-SHA1-96 MUST be supported as an authentication
1115    transform.  DES-CBC SHOULD NOT be used as the encryption transform.
1116
1117
1118
1119
1120
1121
1122 Aboba & Calhoun              Informational                     [Page 20]
1123 \f
1124 RFC 3579                      RADIUS & EAP                September 2003
1125
1126
1127    A typical IPsec policy for an IPsec-capable RADIUS client is
1128    "Initiate IPsec, from me to any destination port UDP 1812".  This
1129    causes an IPsec SA to be set up by the RADIUS client prior to sending
1130    RADIUS traffic.  If some RADIUS servers contacted by the client do
1131    not support IPsec, then a more granular policy will be required:
1132    "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
1133    port UDP 1812".
1134
1135    For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
1136    IPsec, from any to me, destination port 1812".  This causes the
1137    RADIUS server to accept (but not require) use of IPsec.  It may not
1138    be appropriate to require IPsec for all RADIUS clients connecting to
1139    an IPsec-enabled RADIUS server, since some RADIUS clients may not
1140    support IPsec.
1141
1142    Where IPsec is used for security, and no RADIUS shared secret is
1143    configured, it is important that the RADIUS client and server perform
1144    an authorization check.  Before enabling a host to act as a RADIUS
1145    client, the RADIUS server SHOULD check whether the host is authorized
1146    to provide network access.  Similarly, before enabling a host to act
1147    as a RADIUS server, the RADIUS client SHOULD check whether the host
1148    is authorized for that role.
1149
1150    RADIUS servers can be configured with the IP addresses (for IKE
1151    Aggressive Mode with pre-shared keys) or FQDNs (for certificate
1152    authentication) of RADIUS clients.  Alternatively, if a separate
1153    Certification Authority (CA) exists for RADIUS clients, then the
1154    RADIUS server can configure this CA as a trust anchor [RFC3280] for
1155    use with IPsec.
1156
1157    Similarly, RADIUS clients can be configured with the IP addresses
1158    (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
1159    certificate authentication) of RADIUS servers.  Alternatively, if a
1160    separate CA exists for RADIUS servers, then the RADIUS client can
1161    configure this CA as a trust anchor for use with IPsec.
1162
1163    Since unlike SSL/TLS, IKE does not permit certificate policies to be
1164    set on a per-port basis, certificate policies need to apply to all
1165    uses of IPsec on RADIUS clients and servers.  In IPsec deployments
1166    supporting only certificate authentication, a management station
1167    initiating an IPsec-protected telnet session to the RADIUS server
1168    would need to obtain a certificate chaining to the RADIUS client CA.
1169    Issuing such a certificate might not be appropriate if the management
1170    station was not authorized as a RADIUS client.
1171
1172    Where RADIUS clients may obtain their IP address dynamically (such as
1173    an Access Point supporting DHCP), IKE Main Mode with pre-shared keys
1174    [RFC2409] SHOULD NOT be used, since this requires use of a group
1175
1176
1177
1178 Aboba & Calhoun              Informational                     [Page 21]
1179 \f
1180 RFC 3579                      RADIUS & EAP                September 2003
1181
1182
1183    pre-shared key; instead, Aggressive Mode SHOULD be used.  IKEv2, a
1184    work in progress, may address this issue in the future.  Where RADIUS
1185    client addresses are statically assigned, either Aggressive Mode or
1186    Main Mode MAY be used.  With certificate authentication, Main Mode
1187    SHOULD be used.
1188
1189    Care needs to be taken with IKE Phase 1 Identity Payload selection in
1190    order to enable mapping of identities to pre-shared keys even with
1191    Aggressive Mode.  Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
1192    Payloads are used and addresses are dynamically assigned, mapping of
1193    identities to keys is not possible, so that group pre-shared keys are
1194    still a practical necessity.  As a result, the ID_FQDN identity
1195    payload SHOULD be employed in situations where Aggressive mode is
1196    utilized along with pre-shared keys and IP addresses are dynamically
1197    assigned.  This approach also has other advantages, since it allows
1198    the RADIUS server and client to configure themselves based on the
1199    fully qualified domain name of their peers.
1200
1201    Note that with IPsec, security services are negotiated at the
1202    granularity of an IPsec SA, so that RADIUS exchanges requiring a set
1203    of security services different from those negotiated with existing
1204    IPsec SAs will need to negotiate a new IPsec SA.  Separate IPsec SAs
1205    are also advisable where quality of service considerations dictate
1206    different handling RADIUS conversations.  Attempting to apply
1207    different quality of service to connections handled by the same IPsec
1208    SA can result in reordering, and falling outside the replay window.
1209    For a discussion of the issues, see [RFC2983].
1210
1211 4.3.  Security Issues
1212
1213    This section provides more detail on the vulnerabilities identified
1214    in Section 4.1., and how they may be mitigated.  Vulnerabilities
1215    include:
1216
1217    Privacy issues
1218    Spoofing and hijacking
1219    Dictionary attacks
1220    Known plaintext attacks
1221    Replay attacks
1222    Negotiation attacks
1223    Impersonation
1224    Man in the middle attacks
1225    Separation of authenticator and authentication server
1226    Multiple databases
1227
1228
1229
1230
1231
1232
1233
1234 Aboba & Calhoun              Informational                     [Page 22]
1235 \f
1236 RFC 3579                      RADIUS & EAP                September 2003
1237
1238
1239 4.3.1.  Privacy Issues
1240
1241    Since RADIUS messages may contain the User-Name attribute as well as
1242    NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
1243    RADIUS traffic may be able to determine the geographic location of
1244    peers in real time.  In wireless networks, it is often assumed that
1245    RADIUS traffic is physically secure, since it typically travels over
1246    the wired network and that this limits the release of location
1247    information.
1248
1249    However, it is possible for an authenticated attacker to spoof ARP
1250    packets [RFC826] so as to cause diversion of RADIUS traffic onto the
1251    wireless network.  In this way an attacker may obtain RADIUS packets
1252    from which it can glean peer location information, or which it can
1253    subject to a known plaintext or offline dictionary attack.  To
1254    address these vulnerabilities, implementations of this specification
1255    SHOULD use IPsec ESP with non-null transform and per-packet
1256    encryption, authentication, integrity and replay protection to
1257    protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
1258    traffic, as described in Section 4.2.
1259
1260 4.3.2.  Spoofing and Hijacking
1261
1262    Access-Request packets with a User-Password attribute establish the
1263    identity of both the user and the NAS sending the Access-Request,
1264    because of the way the shared secret between the NAS and RADIUS
1265    server is used.  Access-Request packets with CHAP-Password or
1266    EAP-Message attributes do not have a User-Password attribute.  As a
1267    result, the Message-Authenticator attribute SHOULD be used in
1268    Access-Request packets that do not have a User-Password attribute, in
1269    order to establish the identity of the NAS sending the request.
1270
1271    An attacker may attempt to inject packets into the conversation
1272    between the NAS and the RADIUS server, or between the RADIUS server
1273    and the security server.  RADIUS [RFC2865] does not support
1274    encryption other than attribute hiding.  As described in [RFC2865],
1275    only Access-Reply and Access-Challenge packets are integrity
1276    protected.  Moreover, the per-packet authentication and integrity
1277    protection mechanism described in [RFC2865] has known weaknesses
1278    [MD5Attack], making it a tempting target for attackers looking to
1279    subvert RADIUS/EAP.
1280
1281    To provide stronger security, the Message-Authenticator attribute
1282    MUST be used in all RADIUS packets containing an EAP-Message
1283    attribute.  Implementations of this specification SHOULD use IPsec
1284    ESP with non-null transform and per-packet encryption,
1285    authentication, integrity and replay protection, as described in
1286    Section 4.2.
1287
1288
1289
1290 Aboba & Calhoun              Informational                     [Page 23]
1291 \f
1292 RFC 3579                      RADIUS & EAP                September 2003
1293
1294
1295 4.3.3.  Dictionary Attacks
1296
1297    The RADIUS shared secret is vulnerable to offline dictionary attack,
1298    based on capture of the Response Authenticator or
1299    Message-Authenticator attribute.  In order to decrease the level of
1300    vulnerability, [RFC2865] recommends:
1301
1302       The secret (password shared between the client and the RADIUS
1303       server) SHOULD be at least as large and unguessable as a
1304       well-chosen password.  It is preferred that the secret be at least
1305       16 octets.
1306
1307    The risk of an offline dictionary attack can be further reduced by
1308    employing IPsec ESP with non-null transform in order to encrypt the
1309    RADIUS conversation, as described in Section 4.2.
1310
1311 4.3.4.  Known Plaintext Attacks
1312
1313    Since EAP [RFC2284] does not support PAP, the RADIUS User-Password
1314    attribute is not used to carry hidden user passwords within
1315    RADIUS/EAP conversations.  The User-Password hiding mechanism,
1316    defined in [RFC2865] utilizes MD5, defined in [RFC1321], in order to
1317    generate a key stream based on the RADIUS shared secret and the
1318    Request  Authenticator.  Where PAP is in use, it is possible to
1319    collect key streams corresponding to a given Request Authenticator
1320    value, by capturing RADIUS conversations corresponding to a PAP
1321    authentication attempt, using a known password.  Since the
1322    User-Password is known, the key stream corresponding to a given
1323    Request Authenticator can be determined and stored.
1324
1325    Since the key stream may have been determined previously from a known
1326    plaintext attack, if the Request Authenticator repeats, attributes
1327    encrypted using the RADIUS attribute hiding mechanism should be
1328    considered compromised.  In addition to the User-Password attribute,
1329    which is not used with EAP, this includes attributes such as
1330    Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and
1331    MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a
1332    Salt field as part of the hiding algorithm.
1333
1334    To avoid this, [RFC2865], Section 3 advises:
1335
1336       Since it is expected that the same secret MAY be used to
1337       authenticate with servers in disparate geographic regions, the
1338       Request Authenticator field SHOULD exhibit global and temporal
1339       uniqueness.
1340
1341
1342
1343
1344
1345
1346 Aboba & Calhoun              Informational                     [Page 24]
1347 \f
1348 RFC 3579                      RADIUS & EAP                September 2003
1349
1350
1351    Where the Request Authenticator repeats, the Salt field defined in
1352    [RFC2548], Section 2.4 does not provide protection against
1353    compromise.  This is because MD5 [RFC1321], rather than HMAC-MD5
1354    [RFC2104], is used to generate the key stream, which is calculated
1355    from the 128-bit RADIUS shared secret (S), the  128-bit Request
1356    Authenticator (R), and the Salt field (A), using the formula b(1) =
1357    MD5(S + R + A).  Since the Salt field is placed at the end, if the
1358    Request Authenticator were to repeat on a network where PAP is in
1359    use, then the salted keystream could be calculated from the
1360    User-Password keystream by continuing the MD5 calculation based on
1361    the Salt field (A), which is sent in the clear.
1362
1363    Even though EAP does not support PAP authentication, a security
1364    vulnerability can still exist where the same RADIUS shared secret is
1365    used for hiding User-Password as well as other attributes.  This can
1366    occur, for example, if the same RADIUS proxy handles authentication
1367    requests for both EAP and PAP.
1368
1369    The threat can be mitigated by protecting RADIUS with IPsec ESP with
1370    non-null transform, as described in Section 4.2.  Where RADIUS shared
1371    secrets are configured, the RADIUS shared secret used by a NAS
1372    supporting EAP MUST NOT be reused by a NAS utilizing the
1373    User-Password attribute, since improper shared secret hygiene could
1374    lead to compromise of hidden attributes.
1375
1376 4.3.5.  Replay Attacks
1377
1378    The RADIUS protocol provides only limited support for replay
1379    protection.  RADIUS Access-Requests include liveness via the 128-bit
1380    Request Authenticator.  However, the Request Authenticator is not a
1381    replay counter.  Since RADIUS servers may not maintain a cache of
1382    previous Request Authenticators, the Request Authenticator does not
1383    provide replay protection.
1384
1385    RADIUS accounting [RFC2866] does not support replay protection at the
1386    protocol level.  Due to the need to support failover between RADIUS
1387    accounting servers, protocol-based replay protection is not
1388    sufficient to prevent duplicate accounting records.  However, once
1389    accepted by the accounting server, duplicate accounting records can
1390    be detected by use of the the Acct-Session-Id [RFC2866, section 5.5]
1391    and Event-Timestamp [RFC2869, section 5.3] attributes.
1392
1393    Unlike RADIUS authentication, RADIUS accounting does not use the
1394    Request Authenticator as a nonce.  Instead, the Request Authenticator
1395    contains an MD5 hash calculated over the Code, Identifier, Length,
1396    and request attributes of the Accounting Request packet, plus the
1397    shared secret.  The Response Authenticator also contains an MD5 hash
1398    calculated over the Code, Identifier and Length, the Request
1399
1400
1401
1402 Aboba & Calhoun              Informational                     [Page 25]
1403 \f
1404 RFC 3579                      RADIUS & EAP                September 2003
1405
1406
1407    Authenticator field from the Accounting-Request packet being replied
1408    to, the response attributes and the shared secret.
1409
1410    Since the Accounting Response Authenticator depends in part on the
1411    Accounting Request Authenticator, it is not possible to replay an
1412    Accounting-Response unless the Request Authenticator repeats.  While
1413    it is possible to utilize EAP methods such as EAP TLS [RFC2716] which
1414    include liveness checks on both sides, not all EAP messages will
1415    include liveness so that this provides incomplete protection.
1416
1417    Strong replay protection for RADIUS authentication and accounting can
1418    be provided by enabling IPsec replay protection with RADIUS, as
1419    described in Section 4.2.
1420
1421 4.3.6.  Negotiation Attacks
1422
1423    In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or
1424    RADIUS server attempts to cause the authenticating peer to choose a
1425    less secure authentication method.  For example, a session that would
1426    normally be authenticated with EAP would instead be authenticated via
1427    CHAP or PAP; alternatively, a connection that would normally be
1428    authenticated via a more secure EAP method such as EAP-TLS [RFC2716]
1429    might be made to occur via a less secure EAP method, such as
1430    MD5-Challenge.  The threat posed by rogue devices, once thought to be
1431    remote, has gained currency given compromises of telephone company
1432    switching systems, such as those described in [Masters].
1433
1434    Protection against negotiation attacks requires the elimination of
1435    downward negotiations.  The RADIUS exchange may be further protected
1436    by use of IPsec, as described in Section 4.2.  Alternatively, where
1437    IPsec is not used, the vulnerability can be mitigated via
1438    implementation of per-connection policy on the part of the
1439    authenticating peer, and per-peer policy on the part of the RADIUS
1440    server.  For the authenticating peer, authentication policy should be
1441    set on a per-connection basis.  Per-connection policy allows an
1442    authenticating peer to negotiate a strong EAP method when connecting
1443    to one service, while negotiating a weaker EAP method for another
1444    service.
1445
1446    With per-connection policy, an authenticating peer will only attempt
1447    to negotiate EAP for a session in which EAP support is expected.  As
1448    a result, there is a presumption that an authenticating peer
1449    selecting EAP requires that level of security.  If it cannot be
1450    provided, it is likely that there is some kind of misconfiguration,
1451    or even that the authenticating peer is contacting the wrong server.
1452    Should the NAS not be able to negotiate EAP, or should the
1453    EAP-Request sent by the NAS be of a different EAP type than what is
1454    expected, the authenticating peer MUST disconnect.  An authenticating
1455
1456
1457
1458 Aboba & Calhoun              Informational                     [Page 26]
1459 \f
1460 RFC 3579                      RADIUS & EAP                September 2003
1461
1462
1463    peer expecting EAP to be negotiated for a session MUST NOT negotiate
1464    a weaker method, such as CHAP or PAP.  In wireless networks, the
1465    service advertisement itself may be spoof-able, so that an attacker
1466    could fool the peer into negotiating an authentication method
1467    suitable for a less secure network.
1468
1469    For a NAS, it may not be possible to determine whether a peer is
1470    required to authenticate with EAP until the peer's identity is known.
1471    For example, for shared-uses NASes it is possible for one reseller to
1472    implement EAP while another does not.  Alternatively, some peer might
1473    be authenticated locally by the NAS while other peers are
1474    authenticated via RADIUS.  In such cases, if any peers of the NAS
1475    MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
1476    session.  This avoids forcing a peer to support more than one
1477    authentication type, which could weaken security.
1478
1479    If CHAP is negotiated, the NAS will pass the User-Name and
1480    CHAP-Password attributes to the RADIUS server in an Access-Request
1481    packet.  If the peer is not required to use EAP, then the RADIUS
1482    server will respond with an Access-Accept or Access-Reject packet as
1483    appropriate.  However, if CHAP has been negotiated but EAP is
1484    required, the RADIUS server MUST respond with an Access-Reject,
1485    rather than an Access-Challenge/EAP-Message/EAP-Request packet.  The
1486    authenticating peer MUST refuse to renegotiate authentication, even
1487    if the renegotiation is from CHAP to EAP.
1488
1489    If EAP is negotiated but is not supported by the RADIUS proxy or
1490    server, then the server or proxy MUST respond with an Access-Reject.
1491    In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect
1492    the peer.  This is the correct behavior since the authenticating peer
1493    is expecting EAP to be negotiated, and that expectation cannot be
1494    fulfilled.  An EAP-capable authenticating peer MUST refuse to
1495    renegotiate the authentication protocol if EAP had initially been
1496    negotiated.  Note that problems with a non-EAP capable RADIUS proxy
1497    could prove difficult to diagnose, since a peer connecting from one
1498    location (with an EAP-capable proxy) might be able to successfully
1499    authenticate via EAP, while the same peer connecting at another
1500    location (and encountering an EAP-incapable proxy) might be
1501    consistently disconnected.
1502
1503 4.3.7.  Impersonation
1504
1505    [RFC2865] Section 3 states:
1506
1507       A RADIUS server MUST use the source IP address of the RADIUS UDP
1508       packet to decide which shared secret to use, so that RADIUS
1509       requests can be proxied.
1510
1511
1512
1513
1514 Aboba & Calhoun              Informational                     [Page 27]
1515 \f
1516 RFC 3579                      RADIUS & EAP                September 2003
1517
1518
1519    When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
1520    NAS-IPv6-Address attributes may not match the source address.  Since
1521    the NAS-Identifier attribute need not contain an FQDN, this attribute
1522    also may not correspond to the source address, even indirectly, with
1523    or without a proxy present.
1524
1525    As a result, the authenticity check performed by a RADIUS server or
1526    proxy does not verify the correctness of NAS identification
1527    attributes.  This makes it possible for a rogue NAS to forge
1528    NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
1529    a RADIUS Access-Request in order to impersonate another NAS.  It is
1530    also possible for a rogue NAS to forge session identification
1531    attributes such as Called-Station-Id, Calling-Station-Id, and
1532    Originating-Line-Info.
1533
1534    This could fool the RADIUS server into subsequently sending
1535    Disconnect or CoA-Request messages [RFC3576] containing forged
1536    session identification attributes to a NAS targeted by an attacker.
1537
1538    To address these vulnerabilities RADIUS proxies SHOULD check whether
1539    NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
1540    NAS-Identifier) match the source address of packets originating from
1541    the NAS.  Where a match is not found, an Access-Reject SHOULD be
1542    sent, and an error SHOULD be logged.
1543
1544    However, such a check may not always be possible.  Since the
1545    NAS-Identifier attribute need not correspond to an FQDN, it may not
1546    be resolvable to an IP address to be matched against the source
1547    address.  Also, where a NAT exists between the RADIUS client and
1548    proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may
1549    not be feasible.
1550
1551    To allow verification of NAS and session identification parameters,
1552    EAP methods can support the secure exchange of these parameters
1553    between the EAP peer and EAP server.  NAS identification attributes
1554    include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
1555    session identification attributes include User-Name and
1556    Calling-Station-Id.  The secure exchange of these parameters between
1557    the EAP peer and server enables the RADIUS server to check whether
1558    the attributes provided by the NAS match those provided by the peer;
1559    similarly, the peer can check the parameters provided by the NAS
1560    against those provided by the EAP server.  This enables detection of
1561    a rogue NAS.
1562
1563
1564
1565
1566
1567
1568
1569
1570 Aboba & Calhoun              Informational                     [Page 28]
1571 \f
1572 RFC 3579                      RADIUS & EAP                September 2003
1573
1574
1575 4.3.8.  Man in the Middle Attacks
1576
1577    RADIUS only provides security on a hop-by-hop basis, even where IPsec
1578    is used.  As a result, an attacker gaining control of a RADIUS proxy
1579    could attempt to modify EAP packets in transit.  To protect against
1580    this, EAP methods SHOULD incorporate their own per-packet integrity
1581    protection and authentication mechanisms.
1582
1583 4.3.9.  Separation of Authenticator and Authentication Server
1584
1585    As noted in [RFC2716], it is possible for the EAP peer and
1586    authenticator to mutually authenticate, and derive a Master Session
1587    Key (MSK) for a ciphersuite used to protect subsequent data traffic.
1588    This does not present an issue on the peer, since the peer and EAP
1589    client reside on the same machine; all that is required is for the
1590    EAP client module to derive and pass a Transient Session Key (TSK) to
1591    the ciphersuite module.
1592
1593    The situation is more complex when EAP is used with RADIUS, since the
1594    authenticator and authentication server may not reside on the same
1595    host.
1596
1597    In the case where the authenticator and authentication server reside
1598    on different machines, there are several implications for security.
1599    First, mutual authentication will occur between the peer and the
1600    authentication server, not between the peer and the authenticator.
1601    This means that it is not possible for the peer to validate the
1602    identity of the NAS or tunnel server that it is speaking to, using
1603    EAP alone.
1604
1605    As described in Section 4.2, when RADIUS/EAP is used to encapsulate
1606    EAP packets, IPsec SHOULD be used to provide per-packet
1607    authentication, integrity, replay protection and confidentiality.
1608    The Message-Authenticator attribute is also required in RADIUS
1609    Access-Requests containing an EAP-Message attribute sent from the NAS
1610    or tunnel server to the RADIUS server.  Since the
1611    Message-Authenticator attribute involves an HMAC-MD5 message
1612    integrity check, it is possible for the RADIUS server to verify the
1613    integrity of the Access-Request as well as the NAS or tunnel server's
1614    identity, even where IPsec is not used.  Similarly, Access-Challenge
1615    packets containing an EAP-Message attribute sent from the RADIUS
1616    server to the NAS are also authenticated and integrity protected
1617    using an HMAC-MD5 message integrity check, enabling the NAS or tunnel
1618    server to determine the integrity of the packet and verify the
1619    identity of the RADIUS server, even where IPsec is not used.
1620    Moreover, EAP packets sent using methods that contain their own
1621    integrity protection cannot be successfully modified by a rogue NAS
1622    or tunnel server.
1623
1624
1625
1626 Aboba & Calhoun              Informational                     [Page 29]
1627 \f
1628 RFC 3579                      RADIUS & EAP                September 2003
1629
1630
1631    The second issue that arises where the authenticator and
1632    authentication server reside on separate hosts is that the EAP Master
1633    Session Key (MSK) negotiated between the peer and authentication
1634    server will need to be transmitted to the authenticator.  Therefore a
1635    mechanism needs to be provided to transmit the MSK from the
1636    authentication server to the NAS or tunnel server that needs it.  The
1637    specification of the key transport and wrapping mechanism is outside
1638    the scope of this document.  However, it is expected that the
1639    wrapping mechanism will provide confidentiality, integrity and replay
1640    protection, and data origin authentication.
1641
1642 4.3.10.  Multiple Databases
1643
1644    In many cases a security server will be deployed along with a RADIUS
1645    server in order to provide EAP services.  Unless the security server
1646    also functions as a RADIUS server, two separate user databases will
1647    exist, each containing information about the security requirements
1648    for the user.  This represents a weakness, since security may be
1649    compromised by a successful attack on either of the servers, or their
1650    databases.  With multiple user databases, adding a new user may
1651    require multiple operations, increasing the chances for error.  The
1652    problems are further magnified in the case where user information is
1653    also being kept in an LDAP server.  In this case, three stores of
1654    user information may exist.
1655
1656    In order to address these threats, consolidation of databases is
1657    recommended.  This can be achieved by having both the RADIUS server
1658    and security server store information in the same database; by having
1659    the security server provide a full RADIUS implementation; or by
1660    consolidating both the  security server and the RADIUS server onto
1661    the same machine.
1662
1663 5.  IANA Considerations
1664
1665    This specification does not create any new registries, or define any
1666    new RADIUS attributes or values.
1667
1668 6.  References
1669
1670 6.1.  Normative References
1671
1672    [RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1673                   1321, April 1992.
1674
1675    [RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
1676                   Keyed-Hashing for Message Authentication", RFC 2104,
1677                   February 1997.
1678
1679
1680
1681
1682 Aboba & Calhoun              Informational                     [Page 30]
1683 \f
1684 RFC 3579                      RADIUS & EAP                September 2003
1685
1686
1687    [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
1688                   Requirement Levels", BCP 14, RFC 2119, March 1997.
1689
1690    [RFC2279]      Yergeau, F., "UTF-8, a transformation format of ISO
1691                   10646", RFC 2279, January 1998.
1692
1693    [RFC2284]      Blunk, L. and J. Vollbrecht, "PPP Extensible
1694                   Authentication Protocol (EAP)", RFC 2284, March 1998.
1695
1696    [RFC2401]      Atkinson, R. and S. Kent, "Security Architecture for
1697                   the Internet Protocol", RFC 2401, November 1998.
1698
1699    [RFC2406]      Kent, S. and R. Atkinson, "IP Encapsulating Security
1700                   Payload (ESP)", RFC 2406, November 1998.
1701
1702    [RFC2409]      Harkins, D. and D. Carrel, "The Internet Key Exchange
1703                   (IKE)", RFC 2409, November 1998.
1704
1705    [RFC2486]      Aboba, B. and M. Beadles, "The Network Access
1706                   Identifier", RFC 2486, January 1999.
1707
1708    [RFC2865]      Rigney, C., Willens, S., Rubens, A. and W. Simpson,
1709                   "Remote Authentication Dial In User Service (RADIUS)",
1710                   RFC 2865, June 2000.
1711
1712    [RFC2988]      Paxson, V. and M. Allman, "Computing TCP's
1713                   Retransmission Timer", RFC 2988, November 2000.
1714
1715    [RFC3162]      Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
1716                   RFC 3162, August 2001.
1717
1718    [RFC3280]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1719                   X.509 Public Key Infrastructure Certificate and
1720                   Certificate Revocation List (CRL) Profile", RFC 3280,
1721                   April 2002.
1722
1723    [RFC3576]      Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
1724                   Aboba, "Dynamic Authorization Extensions to Remote
1725                   Authentication Dial In User Service (RADIUS)", RFC
1726                   3576, July 2003.
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738 Aboba & Calhoun              Informational                     [Page 31]
1739 \f
1740 RFC 3579                      RADIUS & EAP                September 2003
1741
1742
1743 6.2.  Informative References
1744
1745    [RFC826]       Plummer, D., "An Ethernet Address Resolution
1746                   Protocol", STD 37, RFC 826, November 1982.
1747
1748    [RFC1510]      Kohl, J. and C. Neuman, "The Kerberos Network
1749                   Authentication Service (V5)", RFC 1510, September
1750                   1993.
1751
1752    [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)", STD
1753                   51, RFC 1661, July 1994.
1754
1755    [RFC2548]      Zorn, G., "Microsoft Vendor-specific RADIUS
1756                   Attributes", RFC 2548, March 1999.
1757
1758    [RFC2607]      Aboba, B. and J. Vollbrecht, "Proxy Chaining and
1759                   Policy Implementation in Roaming", RFC 2607, June
1760                   1999.
1761
1762    [RFC2716]      Aboba, B. and D. Simon,"PPP EAP TLS Authentication
1763                   Protocol", RFC 2716, October 1999.
1764
1765    [RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1766
1767    [RFC2867]      Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
1768                   Modifications for Tunnel Protocol Support", RFC 2867,
1769                   June 2000.
1770
1771    [RFC2868]      Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
1772                   Holdrege, M. and I. Goyret, "RADIUS Attributes for
1773                   Tunnel Protocol Support", RFC 2868, June 2000.
1774
1775    [RFC2869]      Rigney, C., Willats, W. and P. Calhoun, "RADIUS
1776                   Extensions", RFC 2869, June 2000.
1777
1778    [RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
1779                   2983, October 2000.
1780
1781    [RFC3580]      Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
1782                   Roese, "IEEE 802.1X Remote Authentication Dial In User
1783                   Service (RADIUS) Usage Guidelines", RFC 3580,
1784                   September 2003.
1785
1786    [IEEE802]      IEEE Standards for Local and Metropolitan Area
1787                   Networks:  Overview and Architecture, ANSI/IEEE Std
1788                   802, 1990.
1789
1790
1791
1792
1793
1794 Aboba & Calhoun              Informational                     [Page 32]
1795 \f
1796 RFC 3579                      RADIUS & EAP                September 2003
1797
1798
1799    [IEEE8021X]    IEEE Standards for Local and Metropolitan Area
1800                   Networks:  Port based Network Access Control, IEEE Std
1801                   802.1X-2001, June 2001.
1802
1803    [MD5Attack]    Dobbertin, H., "The Status of MD5 After a Recent
1804                   Attack", CryptoBytes Vol.2 No.2, Summer 1996.
1805
1806    [Masters]      Slatalla, M. and  J. Quittner, "Masters of Deception."
1807                   HarperCollins, New York, 1995.
1808
1809    [NASREQ]       Calhoun, P., et al., "Diameter Network Access Server
1810                   Application", Work in Progress.
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Aboba & Calhoun              Informational                     [Page 33]
1851 \f
1852 RFC 3579                      RADIUS & EAP                September 2003
1853
1854
1855 Appendix A - Examples
1856
1857    The examples below illustrate conversations between an authenticating
1858    peer, NAS, and RADIUS server.  The OTP and EAP-TLS protocols are used
1859    only for illustrative purposes; other authentication protocols could
1860    also have been used, although they might show somewhat different
1861    behavior.
1862
1863    Where the NAS sends an EAP-Request/Identity as the initial packet,
1864    the exchange appears as follows:
1865
1866 Authenticating peer     NAS                    RADIUS server
1867 -------------------     ---                    -------------
1868                         <- EAP-Request/
1869                         Identity
1870 EAP-Response/
1871 Identity (MyID) ->
1872                         RADIUS Access-Request/
1873                         EAP-Message/EAP-Response/
1874                         (MyID) ->
1875                                                <- RADIUS
1876                                                Access-Challenge/
1877                                                EAP-Message/EAP-Request
1878                                                OTP/OTP Challenge
1879                         <- EAP-Request/
1880                         OTP/OTP Challenge
1881 EAP-Response/
1882 OTP, OTPpw ->
1883                         RADIUS Access-Request/
1884                         EAP-Message/EAP-Response/
1885                         OTP, OTPpw ->
1886                                                 <- RADIUS
1887                                                 Access-Accept/
1888                                                 EAP-Message/EAP-Success
1889                                                 (other attributes)
1890                         <- EAP-Success
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Aboba & Calhoun              Informational                     [Page 34]
1907 \f
1908 RFC 3579                      RADIUS & EAP                September 2003
1909
1910
1911    In the case where the NAS initiates with an EAP-Request for EAP TLS
1912    [RFC2716], and the identity is determined based on the contents of
1913    the client certificate, the exchange will appear as follows:
1914
1915 Authenticating peer     NAS                    RADIUS server
1916 -------------------     ---                    -------------
1917                         <- EAP-Request/
1918                         EAP-Type=EAP-TLS
1919                         (TLS Start, S bit set)
1920 EAP-Response/
1921 EAP-Type=EAP-TLS
1922 (TLS client_hello)->
1923                         RADIUS Access-Request/
1924                         EAP-Message/EAP-Response/
1925                         EAP-Type=EAP-TLS->
1926                                               <-RADIUS Access-Challenge/
1927                                               EAP-Message/
1928                                               EAP-Request/
1929                                               EAP-Type=EAP-TLS
1930                          <- EAP-Request/
1931                          EAP-Type=EAP-TLS
1932                          (TLS server_hello,
1933                          TLS certificate,
1934                    [TLS server_key_exchange,]
1935                    [TLS certificate_request,]
1936                        TLS server_hello_done)
1937 EAP-Response/
1938 EAP-Type=EAP-TLS
1939 (TLS certificate,
1940 TLS client_key_exchange,
1941 [TLS certificate_verify,]
1942 TLS change_cipher_spec,
1943 TLS finished)->
1944                         RADIUS Access-Request/
1945                         EAP-Message/EAP-Response/
1946                         EAP-Type=EAP-TLS->
1947                                               <-RADIUS Access-Challenge/
1948                                               EAP-Message/
1949                                               EAP-Request/
1950                                               EAP-Type=EAP-TLS
1951                         <- EAP-Request/
1952                         EAP-Type=EAP-TLS
1953                         (TLS change_cipher_spec,
1954                         TLS finished)
1955
1956
1957
1958
1959
1960
1961
1962 Aboba & Calhoun              Informational                     [Page 35]
1963 \f
1964 RFC 3579                      RADIUS & EAP                September 2003
1965
1966
1967 EAP-Response/
1968 EAP-Type=EAP-TLS ->
1969                         RADIUS Access-Request/
1970                         EAP-Message/EAP-Response/
1971                         EAP-Type=EAP-TLS->
1972                                               <-RADIUS Access-Accept/
1973                                               EAP-Message/EAP-Success
1974                                               (other attributes)
1975                         <- EAP-Success
1976
1977    In the case where the NAS first sends an EAP-Start packet to the
1978    RADIUS server,  the conversation would appear as follows:
1979
1980 Authenticating peer     NAS                    RADIUS server
1981 -------------------     ---                    -------------
1982                         RADIUS Access-Request/
1983                         EAP-Message/Start ->
1984                                                <- RADIUS
1985                                                Access-Challenge/
1986                                                EAP-Message/EAP-Request/
1987                                                Identity
1988                         <- EAP-Request/
1989                         Identity
1990 EAP-Response/
1991 Identity (MyID) ->
1992                         RADIUS Access-Request/
1993                         EAP-Message/EAP-Response/
1994                         Identity (MyID) ->
1995                                                 <- RADIUS
1996                                                 Access-Challenge/
1997                                                 EAP-Message/EAP-Request/
1998                                                 OTP/OTP Challenge
1999                         <- EAP-Request/
2000                         OTP/OTP Challenge
2001 EAP-Response/
2002 OTP, OTPpw ->
2003                         RADIUS Access-Request/
2004                         EAP-Message/EAP-Response/
2005                         OTP, OTPpw ->
2006                                                 <- RADIUS
2007                                                 Access-Accept/
2008                                                 EAP-Message/EAP-Success
2009                                                 (other attributes)
2010                         <- EAP-Success
2011
2012
2013
2014
2015
2016
2017
2018 Aboba & Calhoun              Informational                     [Page 36]
2019 \f
2020 RFC 3579                      RADIUS & EAP                September 2003
2021
2022
2023    In the case where the NAS initiates with an EAP-Request for EAP TLS
2024    [RFC2716], but the peer responds with a Nak, indicating that it would
2025    prefer another method not implemented locally on the NAS, the
2026    exchange will appear as follows:
2027
2028 Authenticating peer     NAS                    RADIUS server
2029 -------------------     ---                    -------------
2030                         <- EAP-Request/
2031                         EAP-Type=EAP-TLS
2032                         (TLS Start, S bit set)
2033 EAP-Response/
2034 EAP-Type=Nak
2035 (Alternative(s))->
2036                         RADIUS Access-Request/
2037                         EAP-Message/EAP-Response/
2038                         Nak ->
2039                                                <- RADIUS
2040                                                Access-Challenge/
2041                                                EAP-Message/EAP-Request/
2042                                                Identity
2043                         <- EAP-Request/
2044                         Identity
2045 EAP-Response/
2046 Identity (MyID) ->
2047                         RADIUS Access-Request/
2048                         EAP-Message/EAP-Response/
2049                         (MyID) ->
2050                                                <- RADIUS
2051                                                Access-Challenge/
2052                                                EAP-Message/EAP-Request
2053                                                OTP/OTP Challenge
2054                         <- EAP-Request/
2055                         OTP/OTP Challenge
2056 EAP-Response/
2057 OTP, OTPpw ->
2058                         RADIUS Access-Request/
2059                         EAP-Message/EAP-Response/
2060                         OTP, OTPpw ->
2061                                                 <- RADIUS
2062                                                 Access-Accept/
2063                                                 EAP-Message/EAP-Success
2064                                                 (other attributes)
2065                         <- EAP-Success
2066
2067
2068
2069
2070
2071
2072
2073
2074 Aboba & Calhoun              Informational                     [Page 37]
2075 \f
2076 RFC 3579                      RADIUS & EAP                September 2003
2077
2078
2079    In the case where the authenticating peer attempts to authenticate
2080    the NAS, the conversation would appear as follows:
2081
2082 Authenticating peer     NAS                    RADIUS Server
2083 -------------------     ---                    -------------
2084 EAP-Request/
2085 Challenge, MD5 ->
2086                         RADIUS Access-Request/
2087                         EAP-Message/EAP-Request/
2088                         Challenge, MD5 ->
2089                                                 <- RADIUS
2090                                                 Access-Reject/
2091                                                 EAP-Message/
2092                                                 EAP-Response/
2093                                                 Nak (no alternative)
2094
2095                         <- EAP-Response/Nak
2096                          (no alternative)
2097 EAP-Failure ->
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130 Aboba & Calhoun              Informational                     [Page 38]
2131 \f
2132 RFC 3579                      RADIUS & EAP                September 2003
2133
2134
2135    In the case where an invalid EAP Response is inserted by an attacker,
2136    the conversation would appear as follows:
2137
2138 Authenticating peer     NAS                    RADIUS server
2139 -------------------     ---                    -------------
2140                         <- EAP-Request/
2141                         EAP-Type=Foo
2142 EAP-Response/
2143 EAP-Type=Foo ->
2144                         RADIUS Access-Request/
2145                         EAP-Message/EAP-Response/
2146                         EAP-Type=Foo ->
2147                                                <- RADIUS
2148                                                Access-Challenge/
2149                                                EAP-Message/EAP-Request/
2150                                                EAP-Type=Foo
2151                         <- EAP-Request/
2152                         EAP-Type=Foo
2153 Attacker spoof:
2154 EAP-Response/
2155 EAP-Type=Bar ->
2156
2157 Good guy:
2158 EAP-Response/
2159 EAP-Type=Foo ->
2160                         RADIUS Access-Request/
2161                         EAP-Message/EAP-Response/
2162                         EAP-Type=Bar ->
2163
2164                                                <- RADIUS
2165                                                Access-Challenge/
2166                                                EAP-Message/EAP-Request/
2167                                                EAP-Type=Foo,
2168                                                Error-Cause="Invalid EAP
2169                                                 Packet (Ignored)"
2170                         RADIUS Access-Request/
2171                         EAP-Message/EAP-Response/
2172                         EAP-Type=Foo ->
2173                                                <- Access-Accept/
2174                                                EAP-Message/Success
2175                         <- EAP Success
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186 Aboba & Calhoun              Informational                     [Page 39]
2187 \f
2188 RFC 3579                      RADIUS & EAP                September 2003
2189
2190
2191    In the case where the client fails EAP authentication, and an error
2192    message is sent prior to disconnection, the conversation would appear
2193    as follows:
2194
2195 Authenticating peer     NAS                    RADIUS server
2196 -------------------     ---                    -------------
2197                         RADIUS Access-Request/
2198                         EAP-Message/Start ->
2199                                                <- RADIUS
2200                                                Access-Challenge/
2201                                                EAP-Message/EAP-Response/
2202                                                Identity
2203                         <- EAP-Request/
2204                         Identity
2205 EAP-Response/
2206 Identity (MyID) ->
2207                         RADIUS Access-Request/
2208                         EAP-Message/EAP-Response/
2209                         (MyID) ->
2210                                                 <- RADIUS
2211                                                 Access-Challenge/
2212                                                 EAP-Message/EAP-Request
2213                                                 OTP/OTP Challenge
2214                         <- EAP-Request/
2215                         OTP/OTP Challenge
2216 EAP-Response/
2217 OTP, OTPpw ->
2218                         RADIUS Access-Request/
2219                         EAP-Message/EAP-Response/
2220                         OTP, OTPpw ->
2221                                                 <- RADIUS
2222                                                 Access-Challenge/
2223                                                 EAP-Message/EAP-Request/
2224                                                 Notification
2225                         <- EAP-Request/
2226                            Notification
2227
2228 EAP-Response/
2229 Notification ->
2230                         RADIUS Access-Request/
2231                         EAP-Message/EAP-Response/
2232                         Notification ->
2233                                                  <- RADIUS
2234                                                  Access-Reject/
2235                                                  EAP-Message/EAP-Failure
2236                         <- EAP-Failure
2237                         (client disconnected)
2238
2239
2240
2241
2242 Aboba & Calhoun              Informational                     [Page 40]
2243 \f
2244 RFC 3579                      RADIUS & EAP                September 2003
2245
2246
2247    In the case that the RADIUS server or proxy does not support EAP-
2248    Message, but no error message is sent, the conversation would appear
2249    as follows:
2250
2251 Authenticating peer     NAS                       RADIUS server
2252 -------------------     ---                       -------------
2253                         RADIUS Access-Request/
2254                         EAP-Message/Start ->
2255                                                   <- RADIUS
2256                                                   Access-Reject
2257                         (User Disconnected)
2258
2259 In the case where the local RADIUS server does support EAP-Message, but
2260 the remote RADIUS server does not, the conversation would appear as
2261 follows:
2262
2263 Authenticating peer     NAS                       RADIUS server
2264 -------------------     ---                       -------------
2265                         RADIUS Access-Request/
2266                         EAP-Message/Start ->
2267                                                   <- RADIUS
2268                                                   Access-Challenge/
2269                                                   EAP-Message/
2270                                                   EAP-Response/
2271                                                   Identity
2272                         <- EAP-Request/
2273                         Identity
2274
2275 EAP-Response/
2276 Identity
2277 (MyID) ->
2278                         RADIUS Access-Request/
2279                         EAP-Message/EAP-Response/
2280                         (MyID) ->
2281                                                   <- RADIUS
2282                                                   Access-Reject
2283                                                   (proxied from remote
2284                                                    RADIUS server)
2285                         (User Disconnected)
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Aboba & Calhoun              Informational                     [Page 41]
2299 \f
2300 RFC 3579                      RADIUS & EAP                September 2003
2301
2302
2303    In the case where PPP is the link and the authenticating peer does
2304    not support EAP, but where EAP is required for that user, the
2305    conversation would appear as follows:
2306
2307 Authenticating peer     NAS                       RADIUS server
2308 -------------------     ---                       -------------
2309                         <- PPP LCP Request-EAP
2310                         auth
2311 PPP LCP NAK-EAP
2312 auth ->
2313                         <- PPP LCP Request-CHAP
2314                         auth
2315 PPP LCP ACK-CHAP
2316 auth ->
2317                         <- PPP CHAP Challenge
2318 PPP CHAP Response ->
2319                         RADIUS Access-Request/
2320                         User-Name,
2321                         CHAP-Password ->
2322                                                   <- RADIUS
2323                                                   Access-Reject
2324                         <-  PPP LCP Terminate
2325                         (User Disconnected)
2326
2327 In the case where PPP is the link, the NAS does not support EAP, but
2328 where EAP is required for that user, the conversation would appear as
2329 follows:
2330
2331 Authenticating peer     NAS                       RADIUS server
2332 -------------------     ---                       -------------
2333                         <- PPP LCP Request-CHAP
2334                         auth
2335
2336 PP LCP ACK-CHAP
2337 auth ->
2338                         <- PPP CHAP Challenge
2339 PPP CHAP Response ->
2340                         RADIUS Access-Request/
2341                         User-Name,
2342                         CHAP-Password ->
2343
2344                                                  <- RADIUS
2345                                                  Access-Reject
2346                         <-  PPP LCP Terminate
2347                         (User Disconnected)
2348
2349
2350
2351
2352
2353
2354 Aboba & Calhoun              Informational                     [Page 42]
2355 \f
2356 RFC 3579                      RADIUS & EAP                September 2003
2357
2358
2359 Appendix B - Change Log
2360
2361    The following changes have been made from RFC 2869:
2362
2363    A NAS may simultaneously support both local authentication and
2364    pass-through; once the NAS enters pass-through mode within a session,
2365    it cannot revert back to local authentication.  Also EAP is
2366    explicitly described as a 'lock step' protocol. (Section 2).
2367
2368    The NAS may initiate with an EAP-Request for an authentication Type.
2369    If the Request is NAK'd, the NAS should send an initial
2370    Access-Request with an EAP-Message attribute containing an
2371    EAP-Response/Nak.
2372
2373    The RADIUS server may treat an invalid EAP Response as a non-fatal
2374    error (Section 2.2)
2375
2376    For use with RADIUS/EAP, the Password-Retry (Section 2.3) and
2377    Reply-Message (2.6.5) attributes are deprecated.
2378
2379    Each EAP session has a unique Identifier space (Section 2.6.1).
2380
2381    Role reversal is not supported (Section 2.6.2).
2382
2383    Message combinations (e.g. Access-Accept/EAP-Failure) that conflict
2384    are discouraged (Section 2.6.3).
2385
2386    Only a single EAP packet may be encapsulated within a RADIUS message
2387    (Section 3.1).
2388
2389    An Access-Request lacking explicit authentication as well as a
2390    Message- Authenticator attribute SHOULD be silently discarded
2391    (Section 3.3).
2392
2393    The Originating-Line-Info attribute is supported (Section 3.3).
2394
2395    IPsec ESP with non-null transform SHOULD be used and the usage model
2396    is described in detail (Section 4.2).
2397
2398    Additional discussion of security vulnerabilities (Section 4.1) and
2399    potential fixes (Section 4.3).
2400
2401    Separated normative (Section 6.1) and informative (Section 6.2)
2402    references.
2403
2404
2405
2406
2407
2408
2409
2410 Aboba & Calhoun              Informational                     [Page 43]
2411 \f
2412 RFC 3579                      RADIUS & EAP                September 2003
2413
2414
2415    Added additional examples (Appendix A): a NAS initiating with an
2416    EAP-Request for an authentication Type; attempted role reversal.
2417
2418 Intellectual Property Statement
2419
2420    The IETF takes no position regarding the validity or scope of any
2421    intellectual property or other rights that might be claimed to
2422    pertain to the implementation or use of the technology described in
2423    this document or the extent to which any license under such rights
2424    might or might not be available; neither does it represent that it
2425    has made any effort to identify any such rights.  Information on the
2426    IETF's procedures with respect to rights in standards-track and
2427    standards-related documentation can be found in BCP-11.  Copies of
2428    claims of rights made available for publication and any assurances of
2429    licenses to be made available, or the result of an attempt made to
2430    obtain a general license or permission for the use of such
2431    proprietary rights by implementors or users of this specification can
2432    be obtained from the IETF Secretariat.
2433
2434    The IETF invites any interested party to bring to its attention any
2435    copyrights, patents or patent applications, or other proprietary
2436    rights which may cover technology that may be required to practice
2437    this standard.  Please address the information to the IETF Executive
2438    Director.
2439
2440 Acknowledgments
2441
2442    Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco
2443    Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and
2444    Narendra Gidwani of Microsoft for useful discussions of this problem
2445    space.  The authors would also like to acknowledge Tony Jeffree,
2446    Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues
2447    in IEEE 802.1X-2001.
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466 Aboba & Calhoun              Informational                     [Page 44]
2467 \f
2468 RFC 3579                      RADIUS & EAP                September 2003
2469
2470
2471 Authors' Addresses
2472
2473    Bernard Aboba
2474    Microsoft Corporation
2475    One Microsoft Way
2476    Redmond, WA 98052
2477
2478    Phone:  +1 425 706 6605
2479    Fax:    +1 425 936 7329
2480    EMail:   bernarda@microsoft.com
2481
2482
2483    Pat R. Calhoun
2484    Airespace
2485    110 Nortech Parkway
2486    San Jose, California, 95134
2487    USA
2488
2489    Phone:  +1 408 635 2023
2490    Fax:    +1 408 635 2020
2491    EMail:  pcalhoun@airespace.com
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522 Aboba & Calhoun              Informational                     [Page 45]
2523 \f
2524 RFC 3579                      RADIUS & EAP                September 2003
2525
2526
2527 Full Copyright Statement
2528
2529    Copyright (C) The Internet Society (2003).  All Rights Reserved.
2530
2531    This document and translations of it may be copied and furnished to
2532    others, and derivative works that comment on or otherwise explain it
2533    or assist in its implementation may be prepared, copied, published
2534    and distributed, in whole or in part, without restriction of any
2535    kind, provided that the above copyright notice and this paragraph are
2536    included on all such copies and derivative works.  However, this
2537    document itself may not be modified in any way, such as by removing
2538    the copyright notice or references to the Internet Society or other
2539    Internet organizations, except as needed for the purpose of
2540    developing Internet standards in which case the procedures for
2541    copyrights defined in the Internet Standards process must be
2542    followed, or as required to translate it into languages other than
2543    English.
2544
2545    The limited permissions granted above are perpetual and will not be
2546    revoked by the Internet Society or its successors or assignees.
2547
2548    This document and the information contained herein is provided on an
2549    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2550    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2551    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2552    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2553    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2554
2555 Acknowledgement
2556
2557    Funding for the RFC Editor function is currently provided by the
2558    Internet Society.
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578 Aboba & Calhoun              Informational                     [Page 46]
2579 \f