doc/rfc/rfc2869.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           C. Rigney
   8 Request for Comments: 2869                                     Livingston
   9 Category: Informational                                        W. Willats
  10                                                         Cyno Technologies
  11                                                                P. Calhoun
  12                                                          Sun Microsystems
  13                                                                 June 2000
  14
  15
  16                            RADIUS Extensions
  17
  18 Status of this Memo
  19
  20    This memo provides information for the Internet community.  It does
  21    not specify an Internet standard of any kind.  Distribution of this
  22    memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  27
  28 Abstract
  29
  30    This document describes additional attributes for carrying
  31    authentication, authorization and accounting information between a
  32    Network Access Server (NAS) and a shared Accounting Server using the
  33    Remote Authentication Dial In User Service (RADIUS) protocol
  34    described in RFC 2865 [1] and RFC 2866 [2].
  35
  36 Table of Contents
  37
  38    1.     Introduction ..........................................    2
  39       1.1       Specification of Requirements ...................    3
  40       1.2       Terminology .....................................    3
  41    2.     Operation .............................................    4
  42       2.1       RADIUS support for Interim Accounting Updates....    4
  43       2.2       RADIUS support for Apple Remote Access
  44                 Protocol ........................................    5
  45       2.3       RADIUS Support for Extensible Authentication
  46                 Protocol (EAP) ..................................   11
  47          2.3.1  Protocol Overview ...............................   11
  48          2.3.2  Retransmission ..................................   13
  49          2.3.3  Fragmentation ...................................   14
  50          2.3.4  Examples ........................................   14
  51          2.3.5  Alternative uses ................................   19
  52    3.     Packet Format .........................................   19
  53    4.     Packet Types ..........................................   19
  54    5.     Attributes ............................................   20
  55
  56
  57
  58 Rigney, et al.               Informational                      [Page 1]
  59 \f
  60 RFC 2869                   RADIUS Extensions                   June 2000
  61
  62
  63       5.1       Acct-Input-Gigawords ............................   22
  64       5.2       Acct-Output-Gigawords ...........................   23
  65       5.3       Event-Timestamp .................................   23
  66       5.4       ARAP-Password ...................................   24
  67       5.5       ARAP-Features ...................................   25
  68       5.6       ARAP-Zone-Access ................................   26
  69       5.7       ARAP-Security ...................................   27
  70       5.8       ARAP-Security-Data ..............................   28
  71       5.9       Password-Retry ..................................   28
  72       5.10      Prompt ..........................................   29
  73       5.11      Connect-Info ....................................   30
  74       5.12      Configuration-Token .............................   31
  75       5.13      EAP-Message .....................................   32
  76       5.14      Message-Authenticator ...........................   33
  77       5.15      ARAP-Challenge-Response .........................   35
  78       5.16      Acct-Interim-Interval ...........................   36
  79       5.17      NAS-Port-Id .....................................   37
  80       5.18      Framed-Pool .....................................   37
  81       5.19      Table of Attributes .............................   38
  82    6.     IANA Considerations ...................................   39
  83    7.     Security Considerations ...............................   39
  84       7.1       Message-Authenticator Security ..................   39
  85       7.2       EAP Security ....................................   39
  86          7.2.1  Separation of EAP server and PPP authenticator ..   40
  87          7.2.2  Connection hijacking ............................   41
  88          7.2.3  Man in the middle attacks .......................   41
  89          7.2.4  Multiple databases ..............................   41
  90          7.2.5  Negotiation attacks .............................   42
  91    8.     References ............................................   43
  92    9.     Acknowledgements ......................................   44
  93    10.    Chair's Address .......................................   44
  94    11.    Authors' Addresses ....................................   45
  95    12.    Full Copyright Statement ..............................   47
  96
  97 1.  Introduction
  98
  99    RFC 2865 [1] describes the RADIUS Protocol as it is implemented and
 100    deployed today, and RFC 2866 [2] describes how Accounting can be
 101    performed with RADIUS.
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Rigney, et al.               Informational                      [Page 2]
 115 \f
 116 RFC 2869                   RADIUS Extensions                   June 2000
 117
 118
 119    This memo suggests several additional Attributes that can be added to
 120    RADIUS to perform various useful functions.  These Attributes do not
 121    have extensive field experience yet and should therefore be
 122    considered experimental.
 123
 124    The Extensible Authentication Protocol (EAP) [3] is a PPP extension
 125    that provides support for additional authentication methods within
 126    PPP.  This memo describes how the EAP-Message and Message-
 127    Authenticator attributes may be used for providing EAP support within
 128    RADIUS.
 129
 130    All attributes are comprised of variable length Type-Length-Value 3-
 131    tuples.  New attribute values can be added without disturbing
 132    existing implementations of the protocol.
 133
 134 1.1.  Specification of Requirements
 135
 136    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 137    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 138    document are to be interpreted as described in RFC 2119 [4].
 139
 140    An implementation is not compliant if it fails to satisfy one or more
 141    of the must or must not requirements for the protocols it implements.
 142    An implementation that satisfies all the must, must not, should and
 143    should not requirements for its protocols is said to be
 144    "unconditionally compliant"; one that satisfies all the must and must
 145    not requirements but not all the should or should not requirements
 146    for its protocols is said to be "conditionally compliant."
 147
 148    A NAS that does not implement a given service MUST NOT implement the
 149    RADIUS attributes for that service.  For example, a NAS that is
 150    unable to offer ARAP service MUST NOT implement the RADIUS attributes
 151    for ARAP.  A NAS MUST treat a RADIUS access-request requesting an
 152    unavailable service as an access-reject instead.
 153
 154 1.2.  Terminology
 155
 156    This document uses the following terms:
 157
 158    service   The NAS provides a service to the dial-in user, such as PPP
 159              or Telnet.
 160
 161    session   Each service provided by the NAS to a dial-in user
 162              constitutes a session, with the beginning of the session
 163              defined as the point where service is first provided and
 164              the end of the session defined as the point where service
 165
 166
 167
 168
 169
 170 Rigney, et al.               Informational                      [Page 3]
 171 \f
 172 RFC 2869                   RADIUS Extensions                   June 2000
 173
 174
 175              is ended.  A user may have multiple sessions in parallel or
 176              series if the NAS supports that, with each session
 177              generating a separate start and stop accounting record.
 178
 179    silently discard
 180              This means the implementation discards the packet without
 181              further processing.  The implementation SHOULD provide the
 182              capability of logging the error, including the contents of
 183              the silently discarded packet, and SHOULD record the event
 184              in a statistics counter.
 185
 186 2.  Operation
 187
 188    Operation is identical to that defined in RFC 2865 [1] and RFC 2866
 189    [2].
 190
 191 2.1.  RADIUS support for Interim Accounting Updates
 192
 193    When a user is authenticated, a RADIUS server issues an Access-Accept
 194    in response to a successful Access-Request. If the server wishes to
 195    receive interim accounting messages for the given user it must
 196    include the Acct-Interim-Interval RADIUS attribute in the message,
 197    which indicates the interval in seconds between interim messages.
 198
 199    It is also possible to statically configure an interim value on the
 200    NAS itself. Note that a locally configured value on the NAS MUST
 201    override the value found in an Access-Accept.
 202
 203    This scheme does not break backward interoperability since a RADIUS
 204    server not supporting this extension will simply not add the new
 205    Attribute. NASes not supporting this extension will ignore the
 206    Attribute.
 207
 208    Note that all information in an interim message is cumulative (i.e.
 209    number of packets sent is the total since the beginning of the
 210    session, not since the last interim message).
 211
 212    It is envisioned that an Interim Accounting record (with Acct-
 213    Status-Type = Interim-Update (3)) would contain all of the attributes
 214    normally found in an Accounting Stop message with the exception of
 215    the Acct-Term-Cause attribute.
 216
 217    Since all the information is cumulative, a NAS MUST ensure that only
 218    a single generation of an interim Accounting message for a given
 219    session is present in the retransmission queue at any given time.
 220
 221
 222
 223
 224
 225
 226 Rigney, et al.               Informational                      [Page 4]
 227 \f
 228 RFC 2869                   RADIUS Extensions                   June 2000
 229
 230
 231    A NAS MAY use a fudge factor to add a random delay between Interim
 232    Accounting messages for separate sessions. This will ensure that a
 233    cycle where all messages are sent at once is prevented, such as might
 234    otherwise occur if a primary link was recently restored and many
 235    dial-up users were directed to the same NAS at once.
 236
 237    The Network and NAS CPU load of using Interim Updates should be
 238    carefully considered, and appropriate values of Acct-Interim-Interval
 239    chosen.
 240
 241 2.2.  RADIUS support for Apple Remote Access Protocol
 242
 243    The RADIUS (Remote Authentication Dial-In User Service) protocol
 244    provides a method that allows multiple dial-in Network Access Server
 245    (NAS) devices to share a common authentication database.
 246
 247    The Apple Remote Access Protocol (ARAP) provides a method for sending
 248    AppleTalk network traffic over point-to-point links, typically, but
 249    not exclusively, asynchronous and ISDN switched-circuit connections.
 250    Though Apple is moving toward ATCP on PPP for future remote access
 251    services, ARAP is still a common way for the installed base of
 252    Macintosh users to make remote network connections, and is likely to
 253    remain so for some time.
 254
 255    ARAP is supported by several NAS vendors who also support PPP, IPX
 256    and other protocols in the same NAS. ARAP connections in these
 257    multi-protocol devices are often not authenticated with RADIUS, or if
 258    they are, each vendor creates an individual solution to the problem.
 259
 260    This section describes the use of additional RADIUS attributes to
 261    support ARAP. RADIUS client and server implementations that implement
 262    this specification should be able to authenticate ARAP connections in
 263    an interoperable manner.
 264
 265    This section assumes prior knowledge of RADIUS, and will go into some
 266    detail on the operation of ARAP before entering a detailed discussion
 267    of the proposed ARAP RADIUS attributes.
 268
 269    There are two features of ARAP this document does not address:
 270
 271       1. User initiated password changing. This is not part of RADIUS,
 272          but can be implemented through a software process other than
 273          RADIUS.
 274
 275       2. Out-of-Band messages. At any time, the NAS can send messages to
 276          an ARA client which appear in a dialog box on the dial-in
 277          user's screen.  These are not part of authentication and do not
 278          belong here. However, we note that a Reply-Message attribute in
 279
 280
 281
 282 Rigney, et al.               Informational                      [Page 5]
 283 \f
 284 RFC 2869                   RADIUS Extensions                   June 2000
 285
 286
 287          an Access-Accept may be sent down to the user as a sign-on
 288          message of the day string using the out-of-band channel.
 289
 290    We have tried to respect the spirit of the existing RADIUS protocol
 291    as much as possible, making design decisions compatible with prior
 292    art.  Further, we have tried to strike a balance between flooding the
 293    RADIUS world with new attributes, and hiding all of ARAP operation
 294    within a single multiplexed ARAP attribute string or within Extended
 295    Authentication Protocol (EAP) [3] machinery.
 296
 297    However, we feel ARAP is enough of a departure from PPP to warrant a
 298    small set of similarly named attributes of its own.
 299
 300    We have assumed that an ARAP-aware RADIUS server will be able to do
 301    DES encryption and generate security module challenges.  This is in
 302    keeping with the general RADIUS goal of smart server / simple NAS.
 303
 304    ARAP authenticates a connection in two phases. The first is a "Two-
 305    Way DES" random number exchange, using the user's password as a key.
 306    We say "Two-Way" because the ARAP NAS challenges the dial-in client
 307    to authenticate itself, and the dial-in client challenges the ARAP
 308    NAS to authenticate itself.
 309
 310    Specifically, ARAP does the following:
 311
 312       1. The NAS sends two 32-bit random numbers to the dial-in client
 313          in an ARAP msg_auth_challenge packet.
 314
 315       2. The dial-in client uses the user's password to DES encrypt the
 316          two random numbers sent to it by the NAS. The dial-in client
 317          then sends this result, the user's name and two 32-bit random
 318          numbers of its own back to the NAS in an ARAP msg_auth_request
 319          packet.
 320
 321       3. The NAS verifies the encrypted random numbers sent by the
 322          dial-in client are what it expected. If so, it encrypts the
 323          dial-in client's challenge using the password and sends it back
 324          to the dial-in client in an ARAP msg_auth_response packet.
 325
 326    Note that if the dial-in client's response was wrong,  meaning the
 327    user has the wrong password, the server can initiate a retry sequence
 328    up to the maximum amount of retries allowed by the NAS. In this case,
 329    when the dial-in client receives the ARAP msg_auth_response packet it
 330    will acknowledge it with an ARAP msg_auth_again packet.
 331
 332    After this first "DES Phase" the ARAP NAS MAY initiate a secondary
 333    authentication phase using what Apple calls "Add-In Security
 334    Modules."  Security Modules are small pieces of code which run on
 335
 336
 337
 338 Rigney, et al.               Informational                      [Page 6]
 339 \f
 340 RFC 2869                   RADIUS Extensions                   June 2000
 341
 342
 343    both the client and server and are allowed to read and write
 344    arbitrary data across the communications link to perform additional
 345    authentication functions.  Various security token vendors use this
 346    mechanism to authenticate ARA callers.
 347
 348    Although ARAP allows security modules to read and write anything they
 349    like, all existing security modules use simple challenge and response
 350    cycles, with perhaps some overall control information.  This document
 351    assumes all existing security modules can be supported with one or
 352    more challenge/response cycles.
 353
 354    To complicate RADIUS and ARAP integration, ARAP sends down some
 355    profile information after the DES Phase and before the Security
 356    Module phase.  This means that besides the responses to challenges,
 357    this profile information must also be present, at somewhat unusual
 358    times.  Fortunately the information is only a few  pieces of numeric
 359    data related to passwords, which this document packs into a single
 360    new attribute.
 361
 362    Presenting an Access-Request to RADIUS on behalf of an ARAP
 363    connection is straightforward. The ARAP NAS generates the random
 364    number challenge, and then receives the dial-in client's response,
 365    the dial-in client's challenge, and the user's name. Assuming the
 366    user is not a guest, the following information is forwarded in an
 367    Access-Request packet:  User-Name (up to 31 characters long),
 368    Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional
 369    attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id,
 370    NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
 371
 372    The Request Authenticator is a NAS-generated 16 octet random number.
 373    The low-order 8 octets of this number are sent to the dial-in user as
 374    the two 4 octet random numbers required in the ARAP
 375    msg_auth_challenge packet. Octets 0-3 are the first random number and
 376    Octets 4-7 are the second random number.
 377
 378    The ARAP-Password in the Access-Request contains a 16 octet random
 379    number field, and is used to carry the dial-in user's response to the
 380    NAS challenge and the client's own challenge to the NAS.  The high-
 381    order octets contain the dial-in user's challenge to the NAS (2 32-
 382    bit numbers, 8 octets) and the low-order octets contain the dial-in
 383    user's response to the NAS challenge (2 32-bit numbers, 8 octets).
 384
 385    Only one of User-Password, CHAP-Password, or ARAP-Password needs to
 386    be present in an Access-Request, or one or more EAP-Messages.
 387
 388    If the RADIUS server does not support ARAP it SHOULD return an
 389    Access-Reject to the NAS.
 390
 391
 392
 393
 394 Rigney, et al.               Informational                      [Page 7]
 395 \f
 396 RFC 2869                   RADIUS Extensions                   June 2000
 397
 398
 399    If the RADIUS server does support ARAP, it should verify the user's
 400    response using the Challenge (from the lower order 8 octets of the
 401    Request Authenticator) and the user's response (from the low order 8
 402    octets of the ARAP-Password).
 403
 404    If that authentication fails, the RADIUS server should return an
 405    Access-Reject packet to the NAS, with optional Password-Retry and
 406    Reply-Messages attributes.  The presence of Password-Retry indicates
 407    the ARAP NAS MAY choose to initiate another challenge-response cycle,
 408    up to a total number of times equal to the integer value of the
 409    Password-Retry attribute.
 410
 411    If the user is authenticated, the RADIUS server should return an
 412    Access-Accept packet (Code 2) to the NAS, with ID and Response
 413    Authenticator as usual, and attributes as follows:
 414
 415       Service-Type of Framed-Protocol.
 416
 417       Framed-Protocol of ARAP (3).
 418
 419       Session-Timeout with the maximum connect time for the user in
 420       seconds.  If the user is to be given unlimited time,
 421       Session-Timeout should not be included in the Access-Accept
 422       packet, and ARAP will treat that as an unlimited timeout (-1).
 423
 424       ARAP-Challenge-Response, containing 8 octets with the response to
 425       the dial-in client's challenge. The RADIUS server calculates this
 426       value by taking the dial-in client's challenge from the high order
 427       8 octets of the ARAP-Password attribute and  performing DES
 428       encryption on this value with the authenticating user's password
 429       as the key. If the user's password is less than 8 octets in
 430       length, the password is padded at the end with NULL octets to a
 431       length of 8 before using it as a key. If the user's password is
 432       greater than 8 octets in length, an Access-Reject MUST be sent
 433       instead.
 434
 435       ARAP-Features, containing information that the NAS should send to
 436       the user in an ARAP "feature flags" packet.
 437
 438          Octet 0: If zero, user cannot change their password. If non-
 439          zero user can.  (RADIUS does not handle the password changing,
 440          just the attribute which indicates whether ARAP indicates they
 441          can.)
 442
 443          Octet 1: Minimum acceptable password length (0-8).
 444
 445
 446
 447
 448
 449
 450 Rigney, et al.               Informational                      [Page 8]
 451 \f
 452 RFC 2869                   RADIUS Extensions                   June 2000
 453
 454
 455          Octet 2-5: Password creation date in Macintosh format, defined
 456          as 32 bits unsigned representing seconds since Midnight GMT
 457          January 1, 1904.
 458
 459          Octet 6-9 Password Expiration Delta from create date in
 460          seconds.
 461
 462          Octet 10-13: Current RADIUS time in Macintosh format
 463
 464       Optionally, a single Reply-Message with a text string up to 253
 465       characters long which MAY be sent down to the user to be displayed
 466       in a sign-on/message of the day dialog.
 467
 468       Framed-AppleTalk-Network may be included.
 469
 470       Framed-AppleTalk-Zone, up to 32 characters in length, may be
 471       included.
 472
 473       ARAP defines the notion of a list of zones for a user.  Along with
 474       a list of zone names, a Zone Access Flag is defined (and used by
 475       the NAS) which says how to use the list of zone names. That is,
 476       the dial-in user may only be allowed to see the Default Zone, or
 477       only the zones in the zone list (inclusive) or any zone except
 478       those in the zone list (exclusive).
 479
 480       The ARAP NAS handles this by having a named filter which contains
 481       (at least) zone names.  This solves the problem where a single
 482       RADIUS server is managing disparate NAS clients who may not be
 483       able to "see" all of the zone names in a user zone list.  Zone
 484       names only have meaning "at the NAS." The disadvantage of this
 485       approach is that zone filters must be set up on the NAS somehow,
 486       then referenced by the RADIUS Filter-Id.
 487
 488       ARAP-Zone-Access contains an integer which specifies how the "zone
 489       list" for this user should be used.  If this attribute is present
 490       and the value is 2 or 4 then a Filter-Id must also be present to
 491       name a zone list filter to apply the access flag to.
 492
 493       The inclusion of a Callback-Number or Callback-Id attribute in the
 494       Access-Accept MAY cause the ARAP NAS to disconnect after sending
 495       the Feature Flags to begin callback processing in an ARAP specific
 496       way.
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Rigney, et al.               Informational                      [Page 9]
 507 \f
 508 RFC 2869                   RADIUS Extensions                   June 2000
 509
 510
 511    Other attributes may be present in the Access-Accept packet as well.
 512
 513    An ARAP NAS will need other information to finish bringing up the
 514    connection to the dial in client, but this information can be
 515    provided by the ARAP NAS without any help from RADIUS, either through
 516    configuration by SNMP, a NAS administration program, or deduced by
 517    the AppleTalk stack in the NAS. Specifically:
 518
 519       1. AppearAsNet and AppearAsNode values, sent to the client to tell
 520          it what network and node numbers it should use in its datagram
 521          packets.  AppearAsNet can be taken from the Framed-AppleTalk-
 522          Network attribute or from the configuration or AppleTalk stack
 523          onthe NAS.
 524
 525       2. The "default" zone - that is the name of the AppleTalk zone in
 526          which the dial-in client will appear.  (Or can be specified
 527          with the Framed-AppleTalk-Zone attribute.)
 528
 529       3. Other very NAS specific stuff such as the name of the NAS, and
 530          smartbuffering information.  (Smartbuffering is an ARAP
 531          mechanism for replacing common AppleTalk datagrams with small
 532          tokens, to improve slow link performance in a few common
 533          traffic situations.)
 534
 535       4. "Zone List" information for this user.  The ARAP specification
 536          defines a "zone count" field which is actually unused.
 537
 538    RADIUS supports ARAP Security Modules in the following manner.
 539
 540    After DES authentication has been completed, the RADIUS server may
 541    instruct the ARAP NAS to run one or more security modules for the
 542    dial-in user. Although the underlying protocol supports executing
 543    multiple security modules in series, in practice all current
 544    implementations only allow executing one.  Through the use of
 545    multiple Access-Challenge requests, multiple modules can be
 546    supported, but this facility will probably never be used.
 547
 548    We also assume that, even though ARAP allows a free-form dialog
 549    between security modules on each end of the point-to-point link, in
 550    actual practice all security modules can be reduced to a simple
 551    challenge/response cycle.
 552
 553    If the RADIUS server wishes to instruct the ARAP NAS to run a
 554    security module, it should send an Access-Challenge packet to the NAS
 555    with (optionally) the State attribute, plus the ARAP-Challenge-
 556    Response, ARAP-Features, and two more attributes:
 557
 558
 559
 560
 561
 562 Rigney, et al.               Informational                     [Page 10]
 563 \f
 564 RFC 2869                   RADIUS Extensions                   June 2000
 565
 566
 567    ARAP-Security: a four octet security module signature, containing a
 568    Macintosh OSType.
 569
 570    ARAP-Security-Data, a string to carry the actual security module
 571    challenge and response.
 572
 573    When the security module finishes executing, the security module
 574    response is passed  in an ARAP-Security-Data attribute from the NAS
 575    to the RADIUS server in a second Access-Request, also including the
 576    State from the Access-Challenge.  The authenticator field contains no
 577    special information in this case, and this can be discerned by the
 578    presence of the State attribute.
 579
 580 2.3.  RADIUS Support for Extensible Authentication Protocol (EAP)
 581
 582    The Extensible Authentication Protocol (EAP), described in [3],
 583    provides a standard mechanism for support of additional
 584    authentication methods within PPP.  Through the use of EAP, support
 585    for a number of authentication schemes may be added, including smart
 586    cards, Kerberos, Public Key, One Time Passwords, and others.  In
 587    order to provide for support of EAP within RADIUS, two new
 588    attributes, EAP-Message and Message-Authenticator, are introduced in
 589    this document. This section describes how these new attributes may be
 590    used for providing EAP support within RADIUS.
 591
 592    In the proposed scheme, the RADIUS server is used to shuttle RADIUS-
 593    encapsulated EAP Packets between the NAS and a backend security
 594    server. While the conversation between the RADIUS server and the
 595    backend security server will typically occur using a proprietary
 596    protocol developed by the backend security server vendor, it is also
 597    possible to use RADIUS-encapsulated EAP via the EAP-Message
 598    attribute.  This has the advantage of allowing the RADIUS server to
 599    support EAP without the need for authentication-specific code, which
 600    can instead reside on the backend security server.
 601
 602 2.3.1.  Protocol Overview
 603
 604    The EAP conversation between the authenticating peer (dial-in user)
 605    and the NAS begins with the negotiation of EAP within LCP.  Once EAP
 606    has been negotiated, the NAS MUST send an EAP-Request/Identity
 607    message to the authenticating peer, unless identity is determined via
 608    some other means such as Called-Station-Id or Calling-Station-Id.
 609    The peer will then respond with an EAP-Response/Identity which the
 610    the NAS will then forward to the RADIUS server in the EAP-Message
 611    attribute of a RADIUS Access-Request packet. The RADIUS Server will
 612    typically use the EAP-Response/Identity to determine which EAP type
 613    is to be applied to the user.
 614
 615
 616
 617
 618 Rigney, et al.               Informational                     [Page 11]
 619 \f
 620 RFC 2869                   RADIUS Extensions                   June 2000
 621
 622
 623    In order to permit non-EAP aware RADIUS proxies to forward the
 624    Access-Request packet, if the NAS sends the EAP-Request/Identity, the
 625    NAS MUST copy the contents of the EAP-Response/Identity into the
 626    User-Name attribute and MUST include the EAP-Response/Identity in the
 627    User-Name attribute in every subsequent Access-Request. NAS-Port or
 628    NAS-Port-Id SHOULD be included in the attributes issued by the NAS in
 629    the Access-Request packet, and either NAS-Identifier or NAS-IP-
 630    Address MUST be included.  In order to permit forwarding of the
 631    Access-Reply by EAP-unaware proxies, if a User-Name attribute was
 632    included in an Access-Request, the RADIUS Server MUST include the
 633    User-Name attribute in subsequent Access-Accept packets. Without the
 634    User-Name attribute, accounting and billing becomes very difficult to
 635    manage.
 636
 637    If identity is determined via another means such as Called-Station-Id
 638    or Calling-Station-Id, the NAS MUST include these identifying
 639    attributes in every Access-Request.
 640
 641    While this approach will save a round-trip, it cannot be universally
 642    employed.  There are circumstances in which the user's identity may
 643    not be needed (such as when authentication and accounting is handled
 644    based on Called-Station-Id or Calling-Station-Id), and therefore an
 645    EAP-Request/Identity packet may not necessarily be issued by the NAS
 646    to the authenticating peer. In cases where an EAP-Request/Identity
 647    packet will not be sent, the NAS will send to the RADIUS server a
 648    RADIUS Access-Request packet containing an EAP-Message attribute
 649    signifying EAP-Start. EAP-Start is indicated by sending an EAP-
 650    Message attribute with a length of 2 (no data). However, it should be
 651    noted that since no User-Name attribute is included in the Access-
 652    Request, this approach is not compatible with RADIUS as specified in
 653    [1], nor can it easily be applied in situations where proxies are
 654    deployed, such as roaming or shared use networks.
 655
 656    If the RADIUS server supports EAP, it MUST respond with an Access-
 657    Challenge packet containing an EAP-Message attribute. If the RADIUS
 658    server does not support EAP, it MUST respond with an Access-Reject.
 659    The EAP-Message attribute includes an encapsulated EAP packet which
 660    is then passed on to the authenticating peer.  In the case where the
 661    NAS does not initially send an EAP-Request/Identity message to the
 662    peer, the Access-Challenge typically will contain an EAP-Message
 663    attribute encapsulating an EAP-Request/Identity message, requesting
 664    the dial-in user to identify themself. The NAS will then respond with
 665    a RADIUS Access-Request packet containing an EAP-Message attribute
 666    encapsulating an EAP-Response.  The conversation continues until
 667    either a RADIUS Access-Reject or Access-Accept packet is received.
 668
 669
 670
 671
 672
 673
 674 Rigney, et al.               Informational                     [Page 12]
 675 \f
 676 RFC 2869                   RADIUS Extensions                   June 2000
 677
 678
 679    Reception of a RADIUS Access-Reject packet, with or without an EAP-
 680    Message attribute encapsulating EAP-Failure, MUST result in the NAS
 681    issuing an LCP Terminate Request to the authenticating peer.  A
 682    RADIUS Access-Accept packet with an EAP-Message attribute
 683    encapsulating EAP-Success successfully ends the authentication phase.
 684    The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
 685    all of the expected attributes which are currently returned in an
 686    Access-Accept packet.
 687
 688    The above scenario creates a situation in which the NAS never needs
 689    to manipulate an EAP packet.  An alternative may be used in
 690    situations where an EAP-Request/Identity message will always be sent
 691    by the NAS to the authenticating peer.
 692
 693    For proxied RADIUS requests there are two methods of processing.  If
 694    the domain is determined based on the Called-Station-Id, the RADIUS
 695    Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
 696    domain is determined based on the user's identity, the local RADIUS
 697    Server MUST respond with a RADIUS Access-Challenge/EAP-Identity
 698    packet.  The response from the authenticating peer MUST be proxied to
 699    the final authentication server.
 700
 701    For proxied RADIUS requests, the NAS may receive an Access-Reject
 702    packet in response to its Access-Request/EAP-Identity packet.  This
 703    would occur if the message was proxied to a RADIUS Server which does
 704    not support the EAP-Message extension. On receiving an Access-Reject,
 705    the NAS MUST send an LCP Terminate Request to the authenticating
 706    peer, and disconnect.
 707
 708 2.3.2.  Retransmission
 709
 710    As noted in [3], the EAP authenticator (NAS) is responsible for
 711    retransmission of packets between the authenticating peer and the
 712    NAS.  Thus if an EAP packet is lost in transit between the
 713    authenticating peer and the NAS (or vice versa), the NAS will
 714    retransmit. As in RADIUS [1], the RADIUS client is responsible for
 715    retransmission of packets between the RADIUS client and the RADIUS
 716    server.
 717
 718    Note that it may be necessary to adjust retransmission strategies and
 719    authentication timeouts in certain cases. For example, when a token
 720    card is used additional time may be required to allow the user to
 721    find the card and enter the token. Since the NAS will typically not
 722    have knowledge of the required parameters, these need to be provided
 723    by the RADIUS server. This can be accomplished by inclusion of
 724    Session-Timeout and Password-Retry attributes within the Access-
 725    Challenge packet.
 726
 727
 728
 729
 730 Rigney, et al.               Informational                     [Page 13]
 731 \f
 732 RFC 2869                   RADIUS Extensions                   June 2000
 733
 734
 735    If Session-Timeout is present in an Access-Challenge packet that also
 736    contains an EAP-Message, the value of the Session-Timeout provides
 737    the NAS with the maximum number of seconds the NAS should wait for an
 738    EAP-Response before retransmitting the EAP-Message to the dial-in
 739    user.
 740
 741 2.3.3.  Fragmentation
 742
 743    Using the EAP-Message attribute, it is possible for the RADIUS server
 744    to encapsulate an EAP packet that is larger than the MTU on the link
 745    between the NAS and the peer. Since it is not possible for the RADIUS
 746    server to use MTU discovery to ascertain the link MTU, the Framed-MTU
 747    attribute may be included in an Access-Request packet containing an
 748    EAP-Message attribute so as to provide the RADIUS server with this
 749    information.
 750
 751 2.3.4.  Examples
 752
 753    The example below shows the conversation between the authenticating
 754    peer, NAS, and RADIUS server, for the case of a One Time Password
 755    (OTP) authentication. OTP is used only for illustrative purposes;
 756    other authentication protocols could also have been used, although
 757    they might show somewhat different behavior.
 758
 759 Authenticating Peer     NAS                    RADIUS Server
 760 -------------------     ---                    -------------
 761
 762                         <- PPP LCP Request-EAP
 763                         auth
 764 PPP LCP ACK-EAP
 765 auth ->
 766                         <- PPP EAP-Request/
 767                         Identity
 768 PPP EAP-Response/
 769 Identity (MyID) ->
 770                         RADIUS
 771                         Access-Request/
 772                         EAP-Message/
 773                         EAP-Response/
 774                         (MyID) ->
 775                                                 <- RADIUS
 776                                                 Access-Challenge/
 777                                                 EAP-Message/EAP-Request
 778                                                 OTP/OTP Challenge
 779                         <- PPP EAP-Request/
 780                         OTP/OTP Challenge
 781 PPP EAP-Response/
 782 OTP, OTPpw ->
 783
 784
 785
 786 Rigney, et al.               Informational                     [Page 14]
 787 \f
 788 RFC 2869                   RADIUS Extensions                   June 2000
 789
 790
 791                         RADIUS
 792                         Access-Request/
 793                         EAP-Message/
 794                         EAP-Response/
 795                         OTP, OTPpw ->
 796                                                  <- RADIUS
 797                                                  Access-Accept/
 798                                                  EAP-Message/EAP-Success
 799                                                  (other attributes)
 800                         <- PPP EAP-Success
 801 PPP Authentication
 802 Phase complete,
 803 NCP Phase starts
 804
 805 In the case where the NAS first sends an EAP-Start packet to the
 806 RADIUS server,  the conversation would appear as follows:
 807
 808 Authenticating Peer     NAS                    RADIUS Server
 809 -------------------     ---                    -------------
 810
 811                         <- PPP LCP Request-EAP
 812                         auth
 813 PPP LCP ACK-EAP
 814 auth ->
 815                         RADIUS
 816                         Access-Request/
 817                        EAP-Message/Start ->
 818                                                <- RADIUS
 819                                                Access-Challenge/
 820                                                EAP-Message/Identity
 821                         <- PPP EA-Request/
 822                         Identity
 823 PPP EAP-Response/
 824 Identity (MyID) ->
 825                         RADIUS
 826                         Access-Request/
 827                         EAP-Message/
 828                         EAP-Response/
 829                         (MyID) ->
 830                                                 <- RADIUS
 831                                                 Access-Challenge/
 832                                                 EAP-Message/EAP-Request
 833                                                 OTP/OTP Challenge
 834                         <- PPP EAP-Request/
 835                         OTP/OTP Challenge
 836 PPP EAP-Response/
 837 OTP, OTPpw ->
 838
 839
 840
 841
 842 Rigney, et al.               Informational                     [Page 15]
 843 \f
 844 RFC 2869                   RADIUS Extensions                   June 2000
 845
 846
 847                         RADIUS
 848                         Access-Request/
 849                         EAP-Message/
 850                         EAP-Response/
 851                         OTP, OTPpw ->
 852                                                  <- RADIUS
 853                                                  Access-Accept/
 854                                                  EAP-Message/EAP-Success
 855                                                  (other attributes)
 856                         <- PPP EAP-Success
 857 PPP Authentication
 858 Phase complete,
 859 NCP Phase starts
 860
 861 In the case where the client fails EAP authentication, the
 862 conversation would appear as follows:
 863
 864 Authenticating Peer     NAS                    RADIUS Server
 865 -------------------     ---                    -------------
 866
 867                         <- PPP LCP Request-EAP
 868                         auth
 869 PPP LCP ACK-EAP
 870 auth ->
 871                         Access-Request/
 872                         EAP-Message/Start ->
 873                                                <- RADIUS
 874                                                Access-Challenge/
 875                                                EAP-Message/Identity
 876                         <- PPP EAP-Request/
 877                         Identity
 878 PPP EAP-Response/
 879 Identity (MyID) ->
 880                         RADIUS
 881                         Access-Request/
 882                         EAP-Message/
 883                         EAP-Response/
 884                         (MyID) ->
 885                                                 <- RADIUS
 886                                                 Access-Challenge/
 887                                                 EAP-Message/EAP-Request
 888                                                 OTP/OTP Challenge
 889                         <- PPP EAP-Request/
 890                         OTP/OTP Challenge
 891 PPP EAP-Response/
 892 OTP, OTPpw ->
 893                         RADIUS
 894                         Access-Request/
 895
 896
 897
 898 Rigney, et al.               Informational                     [Page 16]
 899 \f
 900 RFC 2869                   RADIUS Extensions                   June 2000
 901
 902
 903                         EAP-Message/
 904                         EAP-Response/
 905                         OTP, OTPpw ->
 906                                                  <- RADIUS
 907                                                  Access-Reject/
 908                                                  EAP-Message/EAP-Failure
 909
 910                         <- PPP EAP-Failure
 911                         (client disconnected)
 912
 913 In the case that the RADIUS server or proxy does not support
 914 EAP-Message, the conversation would appear as follows:
 915
 916 Authenticating Peer     NAS                       RADIUS Server
 917 -------------------     ---                       -------------
 918
 919                         <- PPP LCP Request-EAP
 920                         auth
 921 PPP LCP ACK-EAP
 922 auth ->
 923                         RADIUS
 924                         Access-Request/
 925                         EAP-Message/Start ->
 926                                                   <- RADIUS
 927                                                   Access-Reject
 928                         <- PPP LCP Terminate
 929                         (User Disconnected)
 930
 931 In the case where the local RADIUS Server does support EAP-Message,
 932 but the remote RADIUS Server does not, the conversation would appear
 933 as follows:
 934
 935 Authenticating Peer     NAS                       RADIUS Server
 936 -------------------     ---                       -------------
 937
 938                         <- PPP LCP Request-EAP
 939                         auth
 940 PPP LCP ACK-EAP
 941 auth ->
 942                         RADIUS
 943                         Access-Request/
 944                         EAP-Message/Start ->
 945                                                   <- RADIUS
 946                                                   Access-Challenge/
 947                                                   EAP-Message/Identity
 948                         <- PPP EAP-Request/
 949                         Identity
 950
 951
 952
 953
 954 Rigney, et al.               Informational                     [Page 17]
 955 \f
 956 RFC 2869                   RADIUS Extensions                   June 2000
 957
 958
 959 PPP EAP-Response/
 960 Identity
 961 (MyID) ->
 962                         RADIUS
 963                         Access-Request/
 964                         EAP-Message/EAP-Response/
 965                         (MyID) ->
 966                                                   <- RADIUS
 967                                                   Access-Reject
 968                                                   (proxied from remote
 969                                                    RADIUS Server)
 970                         <- PPP LCP Terminate
 971                         (User Disconnected)
 972
 973 In the case where the authenticating peer does not support EAP, but
 974 where EAP is required for that user, the conversation would appear as
 975 follows:
 976
 977 Authenticating Peer     NAS                       RADIUS Server
 978 -------------------     ---                       -------------
 979
 980                         <- PPP LCP Request-EAP
 981                         auth
 982 PPP LCP NAK-EAP
 983 auth ->
 984                         <- PPP LCP Request-CHAP
 985                         auth
 986 PPP LCP ACK-CHAP
 987 auth ->
 988                         <- PPP CHAP Challenge
 989 PPP CHAP Response ->
 990                         RADIUS
 991                         Access-Request/
 992                         User-Name,
 993                         CHAP-Password ->
 994                                                   <- RADIUS
 995                                                   Access-Reject
 996                         <-  PPP LCP Terminate
 997                         (User Disconnected)
 998
 999 In the case where the NAS does not support EAP, but where EAP is
1000 required for that user, the conversation would appear as follows:
1001
1002 Authenticating Peer     NAS                       RADIUS Server
1003 -------------------     ---                       -------------
1004
1005                         <- PPP LCP Request-CHAP
1006                         auth
1007
1008
1009
1010 Rigney, et al.               Informational                     [Page 18]
1011 \f
1012 RFC 2869                   RADIUS Extensions                   June 2000
1013
1014
1015 PP LCP ACK-CHAP
1016 auth ->
1017                         <- PPP CHAP Challenge
1018 PPP CHAP Response ->
1019                         RADIUS
1020                         Access-Request/
1021                         User-Name,
1022                         CHAP-Password ->
1023
1024                                                  <- RADIUS
1025                                                  Access-Reject
1026                         <-  PPP LCP Terminate
1027                         (User Disconnected)
1028
1029 2.3.5.  Alternative uses
1030
1031    Currently the conversation between the backend security server and
1032    the RADIUS server is proprietary because of lack of standardization.
1033    In order to increase standardization and provide interoperability
1034    between Radius vendors and backend security vendors, it is
1035    recommended that RADIUS-encapsulated EAP be used for this
1036    conversation.
1037
1038    This has the advantage of allowing the RADIUS server to support EAP
1039    without the need for authentication-specific  code within the RADIUS
1040    server. Authentication-specific code can then reside on a backend
1041    security server instead.
1042
1043    In the case where RADIUS-encapsulated EAP is used in a conversation
1044    between a RADIUS server and a backend security server, the security
1045    server will typically return an Access-Accept/EAP-Success message
1046    without inclusion of the expected attributes currently returned in an
1047    Access-Accept. This means that the RADIUS server MUST add these
1048    attributes prior to sending an Access-Accept/EAP-Success message to
1049    the NAS.
1050
1051 3.  Packet Format
1052
1053    Packet Format is identical to that defined in RFC 2865 [1] and 2866
1054    [2].
1055
1056 4.  Packet Types
1057
1058    Packet types are identical to those defined in RFC 2865 [1] and 2866
1059    [2].
1060
1061    See "Table of Attributes" below to determine which types of packets
1062    can contain which attributes defined here.
1063
1064
1065
1066 Rigney, et al.               Informational                     [Page 19]
1067 \f
1068 RFC 2869                   RADIUS Extensions                   June 2000
1069
1070
1071 5.  Attributes
1072
1073    RADIUS Attributes carry the specific authentication, authorization
1074    and accounting details for the request and response.
1075
1076    Some attributes MAY be included more than once.  The effect of this
1077    is attribute specific, and is specified in each attribute
1078    description.  The order of attributes of the same type SHOULD be
1079    preserved.  The order of attributes of different types is not
1080    required to be preserved.
1081
1082    The end of the list of attributes is indicated by the Length of the
1083    RADIUS packet.
1084
1085    A summary of the attribute format is the same as in RFC 2865 [1] but
1086    is included here for ease of reference.  The fields are transmitted
1087    from left to right.
1088
1089     0                   1                   2
1090     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1091    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1092    |     Type      |    Length     |  Value ...
1093    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1094
1095
1096    Type
1097
1098       The Type field is one octet.  Up-to-date values of the RADIUS Type
1099       field are specified in the most recent "Assigned Numbers" RFC [5].
1100       Values 192-223 are reserved for experimental use, values 224-240
1101       are reserved for implementation-specific use, and values 241-255
1102       are reserved and should not be used.  This specification concerns
1103       the following values:
1104
1105            1-39   (refer to RFC 2865 [1], "RADIUS")
1106           40-51   (refer to RFC 2866 [2], "RADIUS Accounting")
1107           52      Acct-Input-Gigawords
1108           53      Acct-Output-Gigawords
1109           54      Unused
1110           55      Event-Timestamp
1111           56-59   Unused
1112           60-63   (refer to RFC 2865 [1], "RADIUS")
1113           64-67   (refer to [6])
1114           68      (refer to [7])
1115           69      (refer to [6])
1116           70      ARAP-Password
1117           71      ARAP-Features
1118           72      ARAP-Zone-Access
1119
1120
1121
1122 Rigney, et al.               Informational                     [Page 20]
1123 \f
1124 RFC 2869                   RADIUS Extensions                   June 2000
1125
1126
1127           73      ARAP-Security
1128           74      ARAP-Security-Data
1129           75      Password-Retry
1130           76      Prompt
1131           77      Connect-Info
1132           78      Configuration-Token
1133           79      EAP-Message
1134           80      Message-Authenticator
1135           81-83   (refer to [6])
1136           84      ARAP-Challenge-Response
1137           85      Acct-Interim-Interval
1138           86      (refer to [7])
1139           87      NAS-Port-Id
1140           88      Framed-Pool
1141           89      Unused
1142           90-91   (refer to [6])
1143           92-191  Unused
1144
1145    Length
1146
1147       The Length field is one octet, and indicates the length of this
1148       attribute including the Type, Length and Value fields.  If an
1149       attribute is received in a packet with an invalid Length, the
1150       entire request should be silently discarded.
1151
1152    Value
1153
1154       The Value field is zero or more octets and contains information
1155       specific to the attribute.  The format and length of the Value
1156       field is determined by the Type and Length fields.
1157
1158       Note that none of the types in RADIUS terminate with a NUL (hex
1159       00).  In particular, types "text" and "string" in RADIUS do not
1160       terminate with a NUL (hex 00).  The Attribute has a length field
1161       and does not use a terminator.  Text contains UTF-8 encoded 10646
1162       [8] characters and String contains 8-bit binary data.  Servers and
1163       servers and clients MUST be able to deal with embedded nulls.
1164       RADIUS implementers using C are cautioned not to use strcpy() when
1165       handling strings.
1166
1167       The format of the value field is one of five data types.  Note
1168       that type "text" is a subset of type "string."
1169
1170       text      1-253 octets containing UTF-8 encoded 10646 [8]
1171                 characters. Text of length zero (0) MUST NOT be sent;
1172                 omit the entire attribute instead.
1173
1174
1175
1176
1177
1178 Rigney, et al.               Informational                     [Page 21]
1179 \f
1180 RFC 2869                   RADIUS Extensions                   June 2000
1181
1182
1183       string    1-253 octets containing binary data (values 0 through
1184                 255 decimal, inclusive). Strings of length zero (0) MUST
1185                 NOT be sent; omit the entire attribute instead.
1186
1187       address   32 bit unsigned value, most significant octet first.
1188
1189       integer   32 bit unsigned value, most significant octet first.
1190
1191       time      32 bit unsigned value, most significant octet first --
1192                    seconds since 00:00:00 UTC, January 1, 1970.
1193
1194 5.1.  Acct-Input-Gigawords
1195
1196    Description
1197
1198       This attribute indicates how many times the Acct-Input-Octets
1199       counter has wrapped around 2^32 over the course of this service
1200       being provided, and can only be present in Accounting-Request
1201       records where the Acct-Status-Type is set to Stop or Interim-
1202       Update.
1203
1204    A summary of the Acct-Input-Gigawords attribute format is shown
1205    below.  The fields are transmitted from left to right.
1206
1207     0                   1                   2                   3
1208     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1209    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1210    |     Type      |    Length     |             Value
1211    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1212               Value (cont)         |
1213    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1214
1215    Type
1216
1217       52 for Acct-Input-Gigawords.
1218
1219    Length
1220
1221       6
1222
1223    Value
1224
1225       The Value field is four octets.
1226
1227
1228
1229
1230
1231
1232
1233
1234 Rigney, et al.               Informational                     [Page 22]
1235 \f
1236 RFC 2869                   RADIUS Extensions                   June 2000
1237
1238
1239 5.2.  Acct-Output-Gigawords
1240
1241    Description
1242
1243       This attribute indicates how many times the Acct-Output-Octets
1244       counter has wrapped around 2^32 in the course of delivering this
1245       service, and can only be present in Accounting-Request records
1246       where the Acct-Status-Type is set to Stop or Interim-Update.
1247
1248    A summary of the Acct-Output-Gigawords attribute format is shown
1249    below.  The fields are transmitted from left to right.
1250
1251     0                   1                   2                   3
1252     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1253    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1254    |     Type      |    Length     |             Value
1255    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1256               Value (cont)         |
1257    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1258
1259    Type
1260
1261       53 for Acct-Output-Gigawords.
1262
1263    Length
1264
1265       6
1266
1267    Value
1268
1269       The Value field is four octets.
1270
1271 5.3.  Event-Timestamp
1272
1273    Description
1274
1275       This attribute is included in an Accounting-Request packet to
1276       record the time that this event occurred on the NAS, in seconds
1277       since January 1, 1970 00:00 UTC.
1278
1279    A summary of the Event-Timestamp attribute format is shown below.
1280    The fields are transmitted from left to right.
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Rigney, et al.               Informational                     [Page 23]
1291 \f
1292 RFC 2869                   RADIUS Extensions                   June 2000
1293
1294
1295     0                   1                   2                   3
1296     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1297    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1298    |     Type      |    Length     |             Value
1299    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1300               Value (cont)         |
1301    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1302
1303    Type
1304
1305       55 for Event-Timestamp
1306
1307    Length
1308
1309       6
1310
1311    Value
1312
1313       The Value field is four octets encoding an unsigned integer with
1314       the number of seconds since January 1, 1970 00:00 UTC.
1315
1316 5.4.  ARAP-Password
1317
1318    Description
1319
1320       This attribute is only present in an Access-Request packet
1321       containing a Framed-Protocol of ARAP.
1322
1323       Only one of User-Password, CHAP-Password, or ARAP-Password needs
1324       to be present in an Access-Request, or one or more EAP-Messages.
1325
1326    A summary of the ARAP-Password attribute format is shown below.  The
1327    fields are transmitted from left to right.
1328
1329     0                   1                   2                   3
1330     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1331    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1332    |     Type      |    Length     |             Value1
1333    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1334                                    |             Value2
1335    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1336                                    |             Value3
1337    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1338                                    |             Value4
1339    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1340                                    |
1341    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1342
1343
1344
1345
1346 Rigney, et al.               Informational                     [Page 24]
1347 \f
1348 RFC 2869                   RADIUS Extensions                   June 2000
1349
1350
1351    Type
1352
1353       70 for ARAP-Password.
1354
1355    Length
1356
1357       18
1358
1359    Value
1360
1361       This attribute contains a 16 octet string, used to carry the
1362       dial-in user's response to the NAS challenge and the client's own
1363       challenge to the NAS.  The high-order octets (Value1 and Value2)
1364       contain the dial-in user's challenge to the NAS (2 32-bit numbers,
1365       8 octets) and the low-order octets (Value3 and Value4) contain the
1366       dial-in user's response to the NAS challenge (2 32-bit numbers, 8
1367       octets).
1368
1369 5.5.  ARAP-Features
1370
1371    Description
1372
1373       This attribute is sent in an Access-Accept packet with Framed-
1374       Protocol of ARAP, and includes password information that the NAS
1375       should sent to the user in an ARAP "feature flags" packet.
1376
1377    A summary of the ARAP-Features attribute format is shown below.  The
1378    fields are transmitted from left to right.
1379
1380     0                   1                   2                   3
1381     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1382    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1383    |     Type      |    Length     |     Value1    |    Value2     |
1384    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1385    |                           Value3                              |
1386    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1387    |                           Value4                              |
1388    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1389    |                           Value5                              |
1390    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1391
1392    Type
1393
1394       71 for ARAP-Features.
1395
1396    Length
1397
1398       16
1399
1400
1401
1402 Rigney, et al.               Informational                     [Page 25]
1403 \f
1404 RFC 2869                   RADIUS Extensions                   June 2000
1405
1406
1407    Value
1408
1409       The Value field is a compound string containing information the
1410       NAS should send to the user in the ARAP "feature flags" packet.
1411
1412          Value1: If zero, user cannot change their password. If non-zero
1413          user can.  (RADIUS does not handle the password changing, just
1414          the attribute which indicates whether ARAP indicates they can.)
1415
1416          Value2: Minimum acceptable password length, from 0 to 8.
1417
1418          Value3: Password creation date in Macintosh format, defined as
1419          32 unsigned bits representing seconds since Midnight GMT
1420          January 1, 1904.
1421
1422          Value4: Password Expiration Delta from create date in seconds.
1423
1424          Value5: Current RADIUS time in Macintosh format.
1425
1426 5.6.  ARAP-Zone-Access
1427
1428    Description
1429
1430       This attribute is included in an Access-Accept packet with
1431       Framed-Protocol of ARAP to indicate how the ARAP zone list for the
1432       user should be used.
1433
1434    A summary of the ARAP-Zone-Access attribute format is shown below.
1435    The fields are transmitted from left to right.
1436
1437     0                   1                   2                   3
1438     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1439    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1440    |     Type      |    Length     |             Value
1441    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1442               Value (cont)         |
1443    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1444
1445
1446    Type
1447
1448       72 for ARAP-Zone-Access.
1449
1450    Length
1451
1452       6
1453
1454
1455
1456
1457
1458 Rigney, et al.               Informational                     [Page 26]
1459 \f
1460 RFC 2869                   RADIUS Extensions                   June 2000
1461
1462
1463    Value
1464
1465       The Value field is four octets encoding an integer with one of the
1466       following values:
1467
1468       1      Only allow access to default zone
1469       2      Use zone filter inclusively
1470       4      Use zone filter exclusively
1471
1472
1473       The value 3 is skipped, not because these are bit flags, but
1474       because 3 in some ARAP implementations means "all zones" which is
1475       the same as not specifying a list at all under RADIUS.
1476
1477       If this attribute is present and the value is 2 or 4 then a
1478       Filter-Id must also be present to name a zone list filter to apply
1479       the access flag to.
1480
1481 5.7.  ARAP-Security
1482
1483    Description
1484
1485       This attribute identifies the ARAP Security Module to be used in
1486       an Access-Challenge packet.
1487
1488    A summary of the ARAP-Security attribute format is shown below.  The
1489    fields are transmitted from left to right.
1490
1491     0                   1                   2                   3
1492     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1493    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1494    |     Type      |    Length     |             Value
1495    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1496               Value (cont)         |
1497    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1498
1499    Type
1500
1501       73 for ARAP-Security.
1502
1503    Length
1504
1505       6
1506
1507
1508
1509
1510
1511
1512
1513
1514 Rigney, et al.               Informational                     [Page 27]
1515 \f
1516 RFC 2869                   RADIUS Extensions                   June 2000
1517
1518
1519    Value
1520
1521       The Value field is four octets, containing an integer specifying
1522       the security module signature, which is a Macintosh OSType.
1523       (Macintosh OSTypes are 4 ascii characters cast as a 32-bit
1524       integer)
1525
1526 5.8.  ARAP-Security-Data
1527
1528    Description
1529
1530       This attribute contains the actual security module challenge or
1531       response, and can be found in Access-Challenge and Access-Request
1532       packets.
1533
1534    A summary of the ARAP-Security-Data attribute format is shown below.
1535    The fields are transmitted from left to right.
1536
1537     0                   1                   2
1538     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1539    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1540    |     Type      |    Length     |     String...
1541    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1542
1543    Type
1544
1545       74 for ARAP-Security-Data.
1546
1547    Length
1548
1549       >=3
1550
1551    String
1552
1553       The String field contains the security module challenge or
1554       response associated with the ARAP Security Module specified in
1555       ARAP-Security.
1556
1557 5.9.  Password-Retry
1558
1559    Description
1560
1561       This attribute MAY be included in an Access-Reject to indicate how
1562       many authentication attempts a user may be allowed to attempt
1563       before being disconnected.
1564
1565       It is primarily intended for use with ARAP authentication.
1566
1567
1568
1569
1570 Rigney, et al.               Informational                     [Page 28]
1571 \f
1572 RFC 2869                   RADIUS Extensions                   June 2000
1573
1574
1575    A summary of the Password-Retry attribute format is shown below.  The
1576    fields are transmitted from left to right.
1577
1578     0                   1                   2                   3
1579     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1580    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1581    |     Type      |    Length     |             Value
1582    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1583               Value (cont)         |
1584    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1585
1586    Type
1587
1588       75 for Password-Retry.
1589
1590    Length
1591
1592       6
1593
1594    Value
1595
1596       The Value field is four octets, containing an integer specifying
1597       the number of password retry attempts to permit the user.
1598
1599 5.10.  Prompt
1600
1601    Description
1602
1603       This attribute is used only in Access-Challenge packets, and
1604       indicates to the NAS whether it should echo the user's response as
1605       it is entered, or not echo it.
1606
1607
1608    A summary of the Prompt attribute format is shown below.  The fields
1609    are transmitted from left to right.
1610
1611     0                   1                   2                   3
1612     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1613    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1614    |     Type      |    Length     |             Value
1615    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1616               Value (cont)         |
1617    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1618
1619    Type
1620
1621       76 for Prompt.
1622
1623
1624
1625
1626 Rigney, et al.               Informational                     [Page 29]
1627 \f
1628 RFC 2869                   RADIUS Extensions                   June 2000
1629
1630
1631    Length
1632
1633       6
1634
1635    Value
1636
1637       The Value field is four octets.
1638
1639        0      No Echo
1640        1      Echo
1641
1642 5.11.  Connect-Info
1643
1644    Description
1645
1646       This attribute is sent from the NAS to indicate the nature of the
1647       user's connection.
1648
1649       The NAS MAY send this attribute in an Access-Request or
1650       Accounting-Request to indicate the nature of the user's
1651       connection.
1652
1653    A summary of the Connect-Info attribute format is shown below.  The
1654    fields are transmitted from left to right.
1655
1656     0                   1                   2
1657     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1658    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1659    |     Type      |    Length     |     Text...
1660    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1661
1662    Type
1663
1664       77 for Connect-Info.
1665
1666    Length
1667
1668       >= 3
1669
1670    Text
1671
1672       The Text field consists of UTF-8 encoded 10646 [8] characters.
1673       The connection speed SHOULD be included at the beginning of the
1674       first Connect-Info attribute in the packet.  If the transmit and
1675       receive connection speeds differ, they may both be included in the
1676       first attribute with the transmit speed first (the speed the NAS
1677       modem transmits at), a slash (/), the receive speed, then
1678       optionally other information.
1679
1680
1681
1682 Rigney, et al.               Informational                     [Page 30]
1683 \f
1684 RFC 2869                   RADIUS Extensions                   June 2000
1685
1686
1687       For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
1688
1689       More than one Connect-Info attribute may be present in an
1690       Accounting-Request packet to accommodate expected efforts by ITU
1691       to have modems report more connection information in a standard
1692       format that might exceed 252 octets.
1693
1694 5.12.  Configuration-Token
1695
1696    Description
1697
1698       This attribute is for use in large distributed authentication
1699       networks based on proxy.  It is sent from a RADIUS Proxy Server to
1700       a RADIUS Proxy Client in an Access-Accept to indicate a type of
1701       user profile to be used.  It should not be sent to a NAS.
1702
1703    A summary of the Configuration-Token attribute format is shown below.
1704    The fields are transmitted from left to right.
1705
1706     0                   1                   2
1707     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1708    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1709    |     Type      |    Length     |  String ...
1710    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1711
1712    Type
1713
1714       78 for Configuration-Token.
1715
1716    Length
1717
1718       >= 3
1719
1720    String
1721
1722       The String field is one or more octets.  The actual format of the
1723       information is site or application specific, and a robust
1724       implementation SHOULD support the field as undistinguished octets.
1725
1726       The codification of the range of allowed usage of this field is
1727       outside the scope of this specification.
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738 Rigney, et al.               Informational                     [Page 31]
1739 \f
1740 RFC 2869                   RADIUS Extensions                   June 2000
1741
1742
1743 5.13.  EAP-Message
1744
1745    Description
1746
1747       This attribute encapsulates Extended Access Protocol [3] packets
1748       so as to allow the NAS to authenticate dial-in users via EAP
1749       without having to understand the EAP protocol.
1750
1751       The NAS places any EAP messages received from the user into one or
1752       more EAP attributes and forwards them to the RADIUS Server as part
1753       of the Access-Request, which can return EAP messages in Access-
1754       Challenge, Access-Accept and Access-Reject packets.
1755
1756       A RADIUS Server receiving EAP messages that it does not understand
1757       SHOULD return an Access-Reject.
1758
1759       The NAS places EAP messages received from the authenticating peer
1760       into one or more EAP-Message attributes and forwards them to the
1761       RADIUS Server within an Access-Request message.  If multiple EAP-
1762       Messages are contained within an Access-Request or Access-
1763       Challenge packet, they MUST be in order and they MUST be
1764       consecutive attributes in the Access-Request or Access-Challenge
1765       packet.  Access-Accept and Access-Reject packets SHOULD only have
1766       ONE EAP-Message attribute in them, containing EAP-Success or EAP-
1767       Failure.
1768
1769       It is expected that EAP will be used to implement a variety of
1770       authentication methods, including methods involving strong
1771       cryptography. In order to prevent attackers from subverting EAP by
1772       attacking RADIUS/EAP, (for example, by modifying the EAP-Success
1773       or EAP-Failure packets) it is necessary that RADIUS/EAP provide
1774       integrity protection at least as strong as those used in the EAP
1775       methods themselves.
1776
1777       Therefore the Message-Authenticator attribute MUST be used to
1778       protect all Access-Request, Access-Challenge, Access-Accept, and
1779       Access-Reject packets containing an EAP-Message attribute.
1780
1781       Access-Request packets including an EAP-Message attribute without
1782       a Message-Authenticator attribute SHOULD be silently discarded by
1783       the RADIUS server.  A RADIUS Server supporting EAP-Message MUST
1784       calculate the correct value of the Message-Authenticator and
1785       silently discard the packet if it does not match the value sent.
1786       A RADIUS Server not supporting EAP-Message MUST return an Access-
1787       Reject if it receives an Access-Request containing an EAP-Message
1788       attribute. A RADIUS Server receiving an EAP-Message attribute that
1789       it does not understand MUST return an Access-Reject.
1790
1791
1792
1793
1794 Rigney, et al.               Informational                     [Page 32]
1795 \f
1796 RFC 2869                   RADIUS Extensions                   June 2000
1797
1798
1799       Access-Challenge, Access-Accept, or Access-Reject packets
1800       including an EAP-Message attribute without a Message-Authenticator
1801       attribute SHOULD be silently discarded by the NAS. A NAS
1802       supporting EAP-Message MUST calculate the correct value of the
1803       Message-Authenticator and silently discard the packet if it does
1804       not match the value sent.
1805
1806    A summary of the EAP-Message attribute format is shown below.  The
1807    fields are transmitted from left to right.
1808
1809     0                   1                   2
1810     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1811    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1812    |     Type      |    Length     |     String...
1813    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1814
1815    Type
1816
1817       79 for EAP-Message.
1818
1819    Length
1820
1821       >= 3
1822
1823    String
1824
1825       The String field contains EAP packets, as defined in [3].  If
1826       multiple EAP-Message attributes are present in a packet their
1827       values should be concatenated; this allows EAP packets longer than
1828       253 octets to be passed by RADIUS.
1829
1830 5.14.  Message-Authenticator
1831
1832    Description
1833
1834       This attribute MAY be used to sign Access-Requests to prevent
1835       spoofing Access-Requests using CHAP, ARAP or EAP authentication
1836       methods.  It MAY be used in any Access-Request.  It MUST be used
1837       in any Access-Request, Access-Accept, Access-Reject or Access-
1838       Challenge that includes an EAP-Message attribute.
1839
1840       A RADIUS Server receiving an Access-Request with a Message-
1841       Authenticator Attribute present MUST calculate the correct value
1842       of the Message-Authenticator and silently discard the packet if it
1843       does not match the value sent.
1844
1845
1846
1847
1848
1849
1850 Rigney, et al.               Informational                     [Page 33]
1851 \f
1852 RFC 2869                   RADIUS Extensions                   June 2000
1853
1854
1855       A RADIUS Client receiving an Access-Accept, Access-Reject or
1856       Access-Challenge with a Message-Authenticator Attribute present
1857       MUST calculate the correct value of the Message-Authenticator and
1858       silently discard the packet if it does not match the value sent.
1859
1860       Earlier drafts of this memo used "Signature" as the name of this
1861       attribute, but Message-Authenticator is more precise.  Its
1862       operation has not changed, just the name.
1863
1864    A summary of the Message-Authenticator attribute format is shown
1865    below.  The fields are transmitted from left to right.
1866
1867     0                   1                   2
1868     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
1869    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1870    |     Type      |    Length     |     String...
1871    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1872
1873    Type
1874
1875       80 for Message-Authenticator
1876
1877    Length
1878
1879       18
1880
1881    String
1882
1883       When present in an Access-Request packet, Message-Authenticator is
1884       an HMAC-MD5 [9] checksum of the entire Access-Request packet,
1885       including Type, ID, Length and authenticator, using the shared
1886       secret as the key, as follows.
1887
1888       Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
1889       Request Authenticator, Attributes)
1890
1891       When the checksum is calculated the signature string should be
1892       considered to be sixteen octets of zero.
1893
1894       For Access-Challenge, Access-Accept, and Access-Reject packets,
1895       the Message-Authenticator is calculated as follows, using the
1896       Request-Authenticator from the Access-Request this packet is in
1897       reply to:
1898
1899       Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
1900       Request Authenticator, Attributes)
1901
1902
1903
1904
1905
1906 Rigney, et al.               Informational                     [Page 34]
1907 \f
1908 RFC 2869                   RADIUS Extensions                   June 2000
1909
1910
1911       When the checksum is calculated the signature string should be
1912       considered to be sixteen octets of zero.  The shared secret is
1913       used as the key for the HMAC-MD5 hash.  The is calculated and
1914       inserted in the packet before the Response Authenticator is
1915       calculated.
1916
1917       This attribute is not needed if the User-Password attribute is
1918       present, but is useful for preventing attacks on other types of
1919       authentication.  This attribute is intended to thwart attempts by
1920       an attacker to setup a "rogue" NAS, and perform online dictionary
1921       attacks against the RADIUS server.  It does not afford protection
1922       against "offline" attacks where the attacker intercepts packets
1923       containing (for example) CHAP challenge and response, and performs
1924       a dictionary attack against those packets offline.
1925
1926       IP Security will eventually make this attribute unnecessary, so it
1927       should be considered an interim measure.
1928
1929 5.15.  ARAP-Challenge-Response
1930
1931    Description
1932
1933       This attribute is sent in an Access-Accept packet with Framed-
1934       Protocol of ARAP, and contains the response to the dial-in
1935       client's challenge.
1936
1937    A summary of the ARAP-Challenge-Response attribute format is shown
1938    below.  The fields are transmitted from left to right.
1939
1940     0                   1                   2                   3
1941     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1942    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1943    |     Type      |    Length     |     Value...
1944    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1945
1946    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1947                                    |
1948    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1949
1950    Type
1951
1952       84 for ARAP-Challenge-Response.
1953
1954    Length
1955
1956       10
1957
1958
1959
1960
1961
1962 Rigney, et al.               Informational                     [Page 35]
1963 \f
1964 RFC 2869                   RADIUS Extensions                   June 2000
1965
1966
1967    Value
1968
1969       The Value field contains an 8 octet response to the dial-in
1970       client's challenge. The RADIUS server calculates this value by
1971       taking the dial-in client's challenge from the high order 8 octets
1972       of the ARAP-Password attribute and  performing DES encryption on
1973       this value with the authenticating user's password as the key. If
1974       the user's password is less than 8 octets in length, the password
1975       is padded at the end with NULL octets to a length of 8 before
1976       using it as a key.
1977
1978 5.16.  Acct-Interim-Interval
1979
1980    Description
1981
1982       This attribute indicates the number of seconds between each
1983       interim update in seconds  for this specific session. This value
1984       can only appear in the Access-Accept message.
1985
1986    A summary of the Acct-Interim-Interval attribute  format  is  shown
1987    below. The fields are transmitted from left to right.
1988
1989    0                   1                   2                   3
1990    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1991    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1992    |     Type      |    Length     |             Value
1993    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1994    |          Value (cont)         |
1995    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1996
1997    Type
1998
1999       85 for Acct-Interim-Interval.
2000
2001    Length
2002
2003       6
2004
2005    Value
2006
2007       The Value field contains the number of seconds between each
2008       interim update to be sent from the NAS for this session. The value
2009       MUST NOT be smaller than 60.  The value SHOULD NOT be smaller than
2010       600, and careful consideration should be given to its impact on
2011       network traffic.
2012
2013
2014
2015
2016
2017
2018 Rigney, et al.               Informational                     [Page 36]
2019 \f
2020 RFC 2869                   RADIUS Extensions                   June 2000
2021
2022
2023 5.17.  NAS-Port-Id
2024
2025    Description
2026
2027       This Attribute contains a text string which identifies the port of
2028       the NAS which is authenticating the user.  It is only used in
2029       Access-Request and Accounting-Request packets.  Note that this is
2030       using "port" in its sense of a physical connection on the NAS, not
2031       in the sense of a TCP or UDP port number.
2032
2033       Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-
2034       Request packet, if the NAS differentiates among its ports.  NAS-
2035       Port-Id is intended for use by NASes which cannot conveniently
2036       number their ports.
2037
2038    A summary of the NAS-Port-Id Attribute format is shown below.  The
2039    fields are transmitted from left to right.
2040
2041     0                   1                   2
2042     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
2043    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2044    |     Type      |    Length     |     Text...
2045    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2046
2047
2048    Type
2049
2050       87 for NAS-Port-Id.
2051
2052    Length
2053
2054       >= 3
2055
2056    Text
2057
2058       The Text field contains the name of the port using UTF-8 encoded
2059       10646 [8] characters.
2060
2061 5.18.  Framed-Pool
2062
2063    Description
2064
2065       This Attribute contains the name of an assigned address pool that
2066       SHOULD be used to assign an address for the user.  If a NAS does
2067       not support multiple address pools, the NAS should ignore this
2068       Attribute.  Address pools are usually used for IP addresses, but
2069       can be used for other protocols if the NAS supports pools for
2070       those protocols.
2071
2072
2073
2074 Rigney, et al.               Informational                     [Page 37]
2075 \f
2076 RFC 2869                   RADIUS Extensions                   June 2000
2077
2078
2079    A summary of the Framed-Pool Attribute format is shown below.  The
2080    fields are transmitted from left to right.
2081
2082     0                   1                   2
2083     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
2084    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2085    |     Type      |    Length     |     String...
2086    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2087
2088    Type
2089
2090       88 for Framed-Pool
2091
2092    Length
2093
2094       >= 3
2095
2096    String
2097
2098       The string field contains the name of an assigned address pool
2099       configured on the NAS.
2100
2101 5.19.  Table of Attributes
2102
2103    The following table provides a guide to which attributes may be found
2104    in which kind of packets.  Acct-Input-Gigawords, Acct-Output-
2105    Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
2106    an Accounting-Request packet.  Connect-Info may have 0+ instances in
2107    an Accounting-Request packet.  The other attributes added in this
2108    document must not be present in an Accounting-Request.
2109
2110 Request  Accept  Reject  Challenge   #    Attribute
2111 0-1      0       0       0           70   ARAP-Password [Note 1]
2112 0        0-1     0       0-1         71   ARAP-Features
2113 0        0-1     0       0           72   ARAP-Zone-Access
2114 0-1      0       0       0-1         73   ARAP-Security
2115 0+       0       0       0+          74   ARAP-Security-Data
2116 0        0       0-1     0           75   Password-Retry
2117 0        0       0       0-1         76   Prompt
2118 0-1      0       0       0           77   Connect-Info
2119 0        0+      0       0           78   Configuration-Token
2120 0+       0+      0+      0+          79   EAP-Message [Note 1]
2121 0-1      0-1     0-1     0-1         80   Message-Authenticator [Note 1]
2122 0        0-1     0       0-1         84   ARAP-Challenge-Response
2123 0        0-1     0       0           85   Acct-Interim-Interval
2124 0-1      0       0       0           87   NAS-Port-Id
2125 0        0-1     0       0           88   Framed-Pool
2126 Request  Accept  Reject  Challenge   #    Attribute
2127
2128
2129
2130 Rigney, et al.               Informational                     [Page 38]
2131 \f
2132 RFC 2869                   RADIUS Extensions                   June 2000
2133
2134
2135    [Note 1] An Access-Request that contains either a User-Password or
2136    CHAP-Password or ARAP-Password or one or more EAP-Message attributes
2137    MUST NOT contain more than one type of those four attributes.  If it
2138    does not contain any of those four attributes, it SHOULD contain a
2139    Message-Authenticator.  If any packet type contains an EAP-Message
2140    attribute it MUST also contain a Message-Authenticator.
2141
2142    The following table defines the above table entries.
2143
2144       0     This attribute MUST NOT be present
2145       0+    Zero or more instances of this attribute MAY be present.
2146       0-1   Zero or one instance of this attribute MAY be present.
2147       1     Exactly one instance of this attribute MUST be present.
2148
2149 6.  IANA Considerations
2150
2151    The Packet Type Codes, Attribute Types, and Attribute Values defined
2152    in this document are registered by the Internet Assigned Numbers
2153    Authority (IANA) from the RADIUS name spaces as described in the
2154    "IANA Considerations" section of [1], in accordance with BCP 26 [10].
2155
2156 7.  Security Considerations
2157
2158    The attributes other than Message-Authenticator and EAP-Message in
2159    this document have no additional security considerations beyond those
2160    already identified in [1].
2161
2162 7.1.  Message-Authenticator Security
2163
2164    Access-Request packets with a User-Password establish the identity of
2165    both the user and the NAS sending the Access-Request, because of the
2166    way the shared secret between NAS and RADIUS server is used.
2167    Access-Request packets with CHAP-Password or EAP-Message do not have
2168    a User-Password attribute, so the Message-Authenticator attribute
2169    should be used in access-request packets that do not have a User-
2170    Password, in order to establish the identity of the NAS sending the
2171    request.
2172
2173 7.2.  EAP Security
2174
2175    Since the purpose of EAP is to provide enhanced security for PPP
2176    authentication, it is critical that RADIUS support for EAP be secure.
2177    In particular, the following issues must be addressed:
2178
2179       Separation of EAP server and PPP authenticator
2180       Connection hijacking
2181       Man in the middle attacks
2182       Multiple databases
2183
2184
2185
2186 Rigney, et al.               Informational                     [Page 39]
2187 \f
2188 RFC 2869                   RADIUS Extensions                   June 2000
2189
2190
2191       Negotiation attacks
2192
2193 7.2.1.  Separation of EAP server and PPP authenticator
2194
2195    It is possible for the EAP endpoints to mutually authenticate,
2196    negotiate a ciphersuite, and derive a session key for subsequent use
2197    in PPP encryption.
2198
2199    This does not present an issue on the peer, since the peer and EAP
2200    client reside on the same machine; all that is required is for the
2201    EAP client module to pass the session key to the PPP encryption
2202    module.
2203
2204    The situation is more complex when EAP is used with RADIUS, since the
2205    PPP authenticator will typically not reside on the same machine as
2206    the EAP server. For example, the EAP server may be a backend security
2207    server, or a module residing on the RADIUS server.
2208
2209    In the case where the EAP server and PPP authenticator reside on
2210    different machines, there are several implications for security.
2211    Firstly, mutual authentication will occur between the peer and the
2212    EAP server, not between the peer and the authenticator. This means
2213    that it is not possible for the peer to validate the identity of the
2214    NAS or tunnel server that it is speaking to.
2215
2216    As described earlier, when EAP/RADIUS is used to encapsulate EAP
2217    packets, the Message-Authenticator attribute is required in
2218    EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the
2219    RADIUS server. Since the Message-Authenticator attribute involves a
2220    HMAC-MD5 hash, it is possible for the RADIUS server to verify the
2221    integrity of the Access-Request as well as the NAS or tunnel server's
2222    identity.  Similarly, Access-Challenge packets sent from the RADIUS
2223    server to the NAS are also authenticated and integrity protected
2224    using an HMAC-MD5 hash, enabling the NAS or tunnel server to
2225    determine the integrity of the packet and verify the identity of the
2226    RADIUS server.  Moreover, EAP packets sent via methods that contain
2227    their own integrity protection cannot be successfully modified by a
2228    rogue NAS or tunnel server.
2229
2230    The second issue that arises in the case of an EAP server and PPP
2231    authenticator residing on different machines is that the session key
2232    negotiated between the peer and EAP server will need to be
2233    transmitted to the authenticator.  Therefore a mechanism needs to be
2234    provided to transmit the session key from the EAP server to the
2235    authenticator or tunnel server that needs to use the key. The
2236    specification of this transit mechanism is outside the scope of this
2237    document.
2238
2239
2240
2241
2242 Rigney, et al.               Informational                     [Page 40]
2243 \f
2244 RFC 2869                   RADIUS Extensions                   June 2000
2245
2246
2247 7.2.2.  Connection hijacking
2248
2249    In this form of attack, the attacker attempts to inject packets into
2250    the conversation between the NAS and the RADIUS server, or between
2251    the RADIUS server and the backend security server. RADIUS does not
2252    support encryption, and as described in [1], only Access-Reply and
2253    Access-Challenge packets are integrity protected. Moreover, the
2254    integrity protection mechanism described in [1] is weaker than that
2255    likely to be used by some EAP methods, making it possible to subvert
2256    those methods by attacking EAP/RADIUS.
2257
2258    In order to provide for authentication of all packets in the EAP
2259    exchange, all EAP/RADIUS packets MUST be authenticated using the
2260    Message-Authenticator attribute, as described previously.
2261
2262 7.2.3.  Man in the middle attacks
2263
2264    Since RADIUS security is based on shared secrets, end-to-end security
2265    is not provided in the case where authentication or accounting
2266    packets are forwarded along a proxy chain.  As a result, attackers
2267    gaining control of a RADIUS proxy will be able to modify EAP packets
2268    in transit.
2269
2270 7.2.4.  Multiple databases
2271
2272    In many cases a backend security server will be deployed along with a
2273    RADIUS server in order to provide EAP services. Unless the backend
2274    security server also functions as a RADIUS server, two separate user
2275    databases will exist, each containing information about the security
2276    requirements for the user. This represents a weakness, since security
2277    may be compromised by a successful attack on either of the servers,
2278    or their backend databases. With multiple user databases, adding a
2279    new user may require multiple operations, increasing the chances for
2280    error.  The problems are further magnified in the case where user
2281    information is also being kept in an LDAP server. In this case, three
2282    stores of user information may exist.
2283
2284    In order to address these threats, consolidation of databases is
2285    recommended.  This can be achieved by having both the RADIUS server
2286    and backend security server store information in the same backend
2287    database; by having the backend security server provide a full RADIUS
2288    implementation; or by consolidating both the backend security server
2289    and the RADIUS server onto the same machine.
2290
2291
2292
2293
2294
2295
2296
2297
2298 Rigney, et al.               Informational                     [Page 41]
2299 \f
2300 RFC 2869                   RADIUS Extensions                   June 2000
2301
2302
2303 7.2.5.  Negotiation attacks
2304
2305    In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
2306    RADIUS server causes the authenticating peer to choose a less secure
2307    authentication method so as to make it easier to obtain the user's
2308    password. For example, a session that would normally be authenticated
2309    with EAP would instead authenticated via CHAP or PAP; alternatively,
2310    a connection that would normally be authenticated via one EAP type
2311    occurs via a less secure EAP type, such as MD5. The threat posed by
2312    rogue devices, once thought to be remote, has gained currency given
2313    compromises of telephone company switching systems, such as those
2314    described in [11].
2315
2316    Protection against negotiation attacks requires the elimination of
2317    downward negotiations. This can be achieved via implementation of
2318    per-connection policy on the part of the authenticating peer, and
2319    per-user policy on the part of the RADIUS server.
2320
2321    For the authenticating peer, authentication policy should be set on a
2322    per-connection basis. Per-connection policy allows an authenticating
2323    peer to negotiate EAP when calling one service, while negotiating
2324    CHAP for another service, even if both services are accessible via
2325    the same phone number.
2326
2327    With per-connection policy, an authenticating peer will only attempt
2328    to negotiate EAP for a session in which EAP support is expected. As a
2329    result, there is a presumption that an authenticating peer selecting
2330    EAP requires that level of security. If it cannot be provided, it is
2331    likely that there is some kind of misconfiguration, or even that the
2332    authenticating peer is contacting the wrong server. Should the NAS
2333    not be able to negotiate EAP, or should the EAP-Request sent by the
2334    NAS be of a different EAP type than what is expected, the
2335    authenticating peer MUST disconnect. An authenticating peer expecting
2336    EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
2337
2338    For a NAS, it may not be possible to determine whether a user is
2339    required to authenticate with EAP until the user's identity is known.
2340    For example, for shared-uses NASes it is possible for one reseller to
2341    implement EAP while another does not. In such cases, if any users of
2342    the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for
2343    every call. This avoids forcing an EAP-capable client to do more than
2344    one authentication, which weakens security.
2345
2346    If CHAP is negotiated, the NAS will pass the User-Name and CHAP-
2347    Password attributes to the RADIUS Server in an Access-Request packet.
2348    If the user is not required to use EAP, then the RADIUS Server will
2349    respond with an Access-Accept or Access-Reject packet as appropriate.
2350    However, if CHAP has been negotiated but EAP is required, the RADIUS
2351
2352
2353
2354 Rigney, et al.               Informational                     [Page 42]
2355 \f
2356 RFC 2869                   RADIUS Extensions                   June 2000
2357
2358
2359    server MUST respond with an Access-Reject, rather than an Access-
2360    Challenge/EAP-Message/EAP-Request packet.  The authenticating peer
2361    MUST refuse to renegotiate authentication, even if the renegotiation
2362    is from CHAP to EAP.
2363
2364    If EAP is negotiated but is not supported by the RADIUS proxy or
2365    server, then the server or proxy MUST respond with an Access-Reject.
2366    In these cases, the NAS MUST send an LCP-Terminate and disconnect the
2367    user.  This is the correct behavior since the authenticating peer is
2368    expecting EAP to be negotiated, and that expectation cannot be
2369    fulfilled. An EAP-capable authenticating peer MUST refuse to
2370    renegotiate the authentication protocol if EAP had initially been
2371    negotiated.  Note that problems with a non-EAP capable RADIUS proxy
2372    could prove difficult to diagnose, since a user dialing in from one
2373    location (with an EAP-capable proxy) might be able to successfully
2374    authenticate via EAP, while the same user dialing into another
2375    location (and encountering an EAP-incapable proxy) might be
2376    consistently disconnected.
2377
2378 8.  References
2379
2380    [1]  Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
2381         Authentication Dial In User Service (RADIUS)", RFC 2865, June
2382         2000.
2383
2384    [2]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
2385
2386    [3]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
2387         Protocol (EAP)", RFC 2284, March 1998.
2388
2389    [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
2390         Levels", BCP 14, RFC 2119, March, 1997.
2391
2392    [5]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
2393         October 1994.
2394
2395    [6]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.  and
2396         I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2397         2868, June 2000.
2398
2399    [7]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
2400         Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
2401
2402    [8]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2403         2279, January 1998.
2404
2405
2406
2407
2408
2409
2410 Rigney, et al.               Informational                     [Page 43]
2411 \f
2412 RFC 2869                   RADIUS Extensions                   June 2000
2413
2414
2415    [9]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
2416         for Message Authentication", RFC 2104, February 1997.
2417
2418    [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
2419         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
2420
2421    [11] Slatalla, M., and  Quittner, J., "Masters of Deception."
2422         HarperCollins, New York, 1995.
2423
2424 9.  Acknowledgements
2425
2426    RADIUS and RADIUS Accounting were originally developed by Livingston
2427    Enterprises (now part of Lucent Technologies) for their PortMaster
2428    series of Network Access Servers.
2429
2430    The section on ARAP is adopted with permission from "Using RADIUS to
2431    Authenticate Apple Remote Access Connections" by Ward Willats of Cyno
2432    Technologies (ward@cyno.com).
2433
2434    The section on Acct-Interim-Interval is adopted with permission from
2435    an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark
2436    Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
2437
2438    The section on EAP is adopted with permission from an earlier work in
2439    progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit
2440    Network, and Bernard Aboba of Microsoft.  Thanks also to Dave Dawson
2441    and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of
2442    Microsoft for useful discussions of this problem space.
2443
2444 10.  Chair's Address
2445
2446    The RADIUS working group can be contacted via the current chair:
2447
2448    Carl Rigney
2449    Livingston Enterprises
2450    4464 Willow Road
2451    Pleasanton, California  94588
2452
2453    Phone: +1 925 737 2100
2454    EMail: cdr@telemancy.com
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466 Rigney, et al.               Informational                     [Page 44]
2467 \f
2468 RFC 2869                   RADIUS Extensions                   June 2000
2469
2470
2471 11.  Authors' Addresses
2472
2473    Questions about this memo can also be directed to:
2474
2475    Carl Rigney
2476    Livingston Enterprises
2477    4464 Willow Road
2478    Pleasanton, California  94588
2479
2480    EMail: cdr@telemancy.com
2481
2482    Questions on ARAP and RADIUS may be directed to:
2483
2484    Ward Willats
2485    Cyno Technologies
2486    1082 Glen Echo Ave
2487    San Jose, CA 95125
2488
2489    Phone: +1 408 297 7766
2490    EMail: ward@cyno.com
2491
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 Rigney, et al.               Informational                     [Page 45]
2523 \f
2524 RFC 2869                   RADIUS Extensions                   June 2000
2525
2526
2527    Questions on EAP and RADIUS may be directed to any of the following:
2528
2529    Pat R. Calhoun
2530    Network and Security Research Center
2531    Sun Microsystems, Inc.
2532    15 Network Circle
2533    Menlo Park, CA 94025
2534
2535    Phone: +1 650 786 7733
2536    EMail: pcalhoun@eng.sun.com
2537
2538
2539    Allan C. Rubens
2540    Tut Systems, Inc.
2541    220 E. Huron, Suite 260
2542    Ann Arbor, MI 48104
2543
2544    Phone: +1 734 995 1697
2545    EMail: arubens@tutsys.com
2546
2547
2548    Bernard Aboba
2549    Microsoft Corporation
2550    One Microsoft Way
2551    Redmond, WA 98052
2552
2553    Phone: +1 425 936 6605
2554    EMail: bernarda@microsoft.com
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578 Rigney, et al.               Informational                     [Page 46]
2579 \f
2580 RFC 2869                   RADIUS Extensions                   June 2000
2581
2582
2583 12.  Full Copyright Statement
2584
2585    Copyright (C) The Internet Society (2000).  All Rights Reserved.
2586
2587    This document and translations of it may be copied and furnished to
2588    others, and derivative works that comment on or otherwise explain it
2589    or assist in its implementation may be prepared, copied, published
2590    and distributed, in whole or in part, without restriction of any
2591    kind, provided that the above copyright notice and this paragraph are
2592    included on all such copies and derivative works.  However, this
2593    document itself may not be modified in any way, such as by removing
2594    the copyright notice or references to the Internet Society or other
2595    Internet organizations, except as needed for the purpose of
2596    developing Internet standards in which case the procedures for
2597    copyrights defined in the Internet Standards process must be
2598    followed, or as required to translate it into languages other than
2599    English.
2600
2601    The limited permissions granted above are perpetual and will not be
2602    revoked by the Internet Society or its successors or assigns.
2603
2604    This document and the information contained herein is provided on an
2605    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2606    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2607    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2608    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2609    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2610
2611 Acknowledgement
2612
2613    Funding for the RFC Editor function is currently provided by the
2614    Internet Society.
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634 Rigney, et al.               Informational                     [Page 47]
2635 \f