Network Working Group                                   Murtaza S. Chiba
INTERNET-DRAFT                                             Gopal Dommety
Category: Informational                                      Mark Eklund
<draft-chiba-radius-dynamic-authorization-12.txt>    Cisco Systems, Inc.
8 April 2003                                                David Mitton
                                                  Circular Logic, UnLtd.
                                                           Bernard Aboba
                                                   Microsoft Corporation


Dynamic Authorization Extensions to Remote Authentication Dial In User
                            Service (RADIUS)

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

This document describes a currently deployed extension to the RADIUS
protocol, allowing dynamic changes to a user session, as implemented by
network access server products. This includes support for disconnecting
users and changing authorizations applicable to a user session.










Chiba, et al.                 Informational                     [Page 1]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Table of Contents

1.     Introduction ..........................................    3
   1.1       Terminology .....................................    3
   1.2       Requirements language ...........................    3
2.     Overview  .............................................    4
   2.1       Disconnect Messages (DM) ........................    4
   2.2       Change-of-Authorization Messages (CoA) ..........    4
   2.3       Packet format ...................................    5
3.     Attributes ............................................    8
   3.1       Error-Cause .....................................   10
   3.2       Table of Attributes .............................   12
4.     IANA Considerations ...................................   15
5.     Security considerations ...............................   16
   5.1       Authorization issues ............................   16
   5.2       Impersonation ...................................   16
   5.3       IPsec usage guidelines ..........................   17
   5.4       Replay protection ...............................   20
6.     Example traces ........................................   20
7.     Normative references ..................................   20
8.     Informative references ................................   21
ACKNOWLEDGMENTS ..............................................   22
AUTHORS' ADDRESSES ...........................................   22
Intellectual property statement ..............................   23
Full Copyright Statement .....................................   24


























Chiba, et al.                 Informational                     [Page 2]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


1.  Introduction

The RADIUS protocol, defined in [RFC2865], does not support unsolicited
messages sent from the RADIUS server to the Network Access Server (NAS).

However, there are many instances in which it is desirable for changes
to be made to session characteristics, without requiring the NAS to
initiate the exchange. For example, it may be desirable for
administrators to be able to terminate a user session in progress.
Alternatively, if the user changes authorization level, this may require
that authorization attributes be added/deleted from a user session.

To overcome these limitations, several vendors have implemented
additional RADIUS commands in order to be able to support unsolicited
messages sent from the RADIUS server to the NAS. These extended commands
provide support for Disconnect and Change-of-Authorization (CoA)
messages.  Disconnect messages cause a user session to be terminated
immediately, whereas Change-of-Authorization messages modify session
authorization attributes such as data filters.

1.1.  Terminology

This document frequently uses the following terms:

Network Access Server (NAS)
          The device providing access to the network.

service   The NAS provides a service to the user, such as IEEE 802 or
          PPP.

session   Each service provided by the NAS to a user constitutes a
          session, with the beginning of the session defined as the
          point where service is first provided and the end of the
          session defined as the point where service is ended.  A user
          may have multiple sessions in parallel or series if the NAS
          supports that.

silently discard
          This means the implementation discards the packet without
          further processing.  The implementation SHOULD provide the
          capability of logging the error, including the contents of the
          silently discarded packet, and SHOULD record the event in a
          statistics counter.

1.2.  Requirements language

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.  The key words



Chiba, et al.                 Informational                     [Page 3]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119].

2.  Overview

This section describes the most commonly implemented features of
Disconnect and Change-of-Authorization messages.

2.1.  Disconnect Messages (DM)

A Disconnect-Request packet is sent by the RADIUS server in order to
terminate a user session on a NAS, and discard all associated session
context.  The Disconnect-Request packet is sent to UDP port TBD, and
identifies the NAS as well as the user session to be terminated by
inclusion of the identification attributes described in Section 3.

+----------+   Disconnect-Request     +----------+
|          |   <--------------------  |          |
|    NAS   |                          |  Client  |
|          |   Disconnect-Response    |          |
|          |   ---------------------> |          |
+----------+                          +----------+

A Disconnect-Request packet is followed by a response of either
Disconnect-ACK, if all associated session context is discarded and the
user session is no longer connected, or a Disconnect-NAK, if the NAS was
unable to disconnect the session and discard all associated session
context.  A Disconnect-ACK MAY contain the attribute Acct-Terminate-
Cause (49) [RFC2866] with the value set to 6 for Admin-Reset.

2.2.  Change-of-Authorization Messages (CoA)

CoA-Request packets contain information for dynamically changing session
authorizations.  Typically this is used to change data filters. The data
filters can be of either the ingress or egress kind, and are sent in
addition to the identification attributes as described in section 3.
The port used, and packet format (described in Section 2.3), are the
same as that for Disconnect-Request Messages.

The following attribute MAY be sent in a CoA-Request:

Filter-ID (11) - Indicates the name of a data filter list to be
                 applied for the session that the identification
                 attributes map to.






Chiba, et al.                 Informational                     [Page 4]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


+----------+      CoA-Request         +----------+
|          |  <--------------------   |          |
|   NAS    |                          |  Client  |
|          |     CoA-Response         |          |
|          |   ---------------------> |          |
+----------+                          +----------+

A CoA-Request is followed by a response of either CoA-ACK if the NAS is
able to successfully change the authorizations for the user session or a
CoA-NAK if it does not succeed.

2.3.  Packet format

For either type of request (Disconnect, or Change-of-Authorization), the
UDP port TBD is used as the destination port.  For responses, the source
and destination ports are reversed. Exactly one RADIUS packet is
encapsulated in the UDP Data field.

A summary of the data format is shown below. The fields are transmitted
from left to right.

The packet format consists of the fields: Code, Identifier, Length,
Authenticator, and Attributes in Type:Length:Value (TLV) format.  All
fields hold the same meaning as those described in RADIUS [RFC2865].
The Authenticator field MUST be calculated in the same way as is
specified for an Accounting-Request in [RFC2866].

 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         Authenticator                         |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

   The Code field is one octet, and identifies the type of RADIUS
   packet.  When a packet is received with an invalid Code field, it is
   silently discarded. RADIUS codes (decimal) for this extension are
   assigned as follows:

   40 - Disconnect-Request [RFC2882]



Chiba, et al.                 Informational                     [Page 5]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


   41 - Disconnect-ACK [RFC2882]
   42 - Disconnect-NAK [RFC2882]
   43 - CoA-Request [RFC2882]
   44 - CoA-ACK [RFC2882]
   45 - CoA-NAK [RFC2882]

Identifier

   The Identifier field is one octet, and aids in matching requests and
   replies. The RADIUS client can detect a duplicate request if it has
   the same server source IP address and source UDP port and Identifier
   within a short span of time.

   Unlike RADIUS as defined in [RFC2865], the responsibility for
   retransmission of Disconnect-Request and CoA-Request messages lies
   with the RADIUS server.  If after sending these messages, the RADIUS
   server does not receive a response, it will retransmit. The
   Identifier field MUST be changed whenever the content of the
   Attributes field changes, and whenever a valid reply has been
   received for a previous request.  For retransmissions where the
   contents are identical, the Identifier MUST remain unchanged.

   If the RADIUS server is retransmitting a Disconnect-Request or CoA-
   Request to the same client as before, and the attributes haven't
   changed, the same Request Authenticator, Identifier and source port
   MUST be used. If any attributes have changed, a new Authenticator and
   Identifier MUST be used.

   Note that if the Event-Timestamp attribute is included, it will be
   updated when the packet is retransmitted, changing the content of the
   Attributes field and requiring a new Identifier and Request
   Authenticator.

   If the Request to a primary proxy fails, a secondary proxy must be
   queried if available. Since this represents a new request, a new
   Request Authenticator and Identifier MUST be used.  However, where
   the RADIUS server is sending directly to the client, failover
   typically does not make sense, since Disconnect or CoA messages need
   to be delivered to the NAS where the session resides.

Length

   The Length field is two octets.  It indicates the length of the
   packet including the Code, Identifier, Length, Authenticator and
   Attribute fields.  Octets outside the range of the Length field MUST
   be treated as padding and ignored on reception.  If the packet is
   shorter than the Length field indicates, it MUST be silently
   discarded.  The minimum length is 20 and maximum length is 4096.



Chiba, et al.                 Informational                     [Page 6]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Authenticator

   The Authenticator field is sixteen (16) octets.  The most significant
   octet is transmitted first.  This value is used to authenticate the
   messages between the RADIUS server and client.

   Request Authenticator

      In  Request packets, the Authenticator value is a 16 octet MD5
      [RFC1321] checksum, called the Request Authenticator.  The Request
      Authenticator is calculated the same way as for an Accounting-
      Request, specified in [RFC2866].

      Note that the Request Authenticator of a Disconnect or CoA-Request
      cannot be done the same way as the Request Authenticator of a
      RADIUS Access-Request, because there is no User-Password attribute
      in a Disconnect or Change-of-Authorization Request.

   Response Authenticator

      The Authenticator field in a Response packet (e.g. Disconnect-ACK,
      Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response
      Authenticator, and contains a one-way MD5 hash calculated over a
      stream of octets consisting of the Code, Identifier, Length, the
      Request Authenticator field from the packet being replied to, and
      the response attributes if any, followed by the shared secret.
      The resulting 16 octet MD5 hash value is stored in the
      Authenticator field of the Response packet.

   Administrative note: As noted in [RFC2865], Section 3 the secret
   (password shared between the client and the RADIUS server) SHOULD be
   at least as large and unguessable as a well-chosen password.  RADIUS
   clients MUST use the source IP address of the RADIUS UDP packet to
   decide which shared secret to use, so that requests can be proxied.

Attributes

   In Disconnect and CoA-Request messages, all attributes are treated as
   mandatory.  A NAS MUST respond to a CoA-Request containing one or
   more unsupported attributes with a CoA-NAK; a Disconnect-Request
   containing one or more unsupported attributes MUST be answered with a
   Disconnect-NAK. State changes resulting from a CoA-Request MUST be
   atomic: if the Request is successful, a CoA-ACK is sent, and all
   requested authorization changes MUST be made. If the CoA-Request is
   unsuccessful, a CoA-NAK MUST be sent, and the requested authorization
   changes MUST NOT be made. Similarly, a state change MUST NOT occur as
   a result of an unsuccessful Disconnect-Request; here a Disconnect-NAK
   MUST be sent.



Chiba, et al.                 Informational                     [Page 7]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


   Since within this specification attributes may be used for
   identification, authorization or other purposes, even if a NAS
   implements an attribute for use with RADIUS authentication and
   accounting, it may not support inclusion of that attribute within
   Disconnect or CoA-Request messages, given the difference in attribute
   semantics.  This is true even for attributes specified within
   [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as allowable within
   Access-Accept messages.

   As a result, attributes beyond those specified in Section 3.2 SHOULD
   NOT be included within Disconnect or CoA messages, since this could
   produce unpredictable results.  Potential semantic confusion between
   identification and authorization attributes does not exist within
   [Diameter] where server-initiated re-authorization messages are used
   for identification only and are followed by a conventional Access
   Request/Response exchange.

   When using a forwarding proxy, the proxy must be able to alter the
   packet as it passes through in each direction. When the proxy
   forwards a Disconnect or CoA-Request, it MAY add a Proxy-State
   Attribute, and when the proxy forwards a response, it MUST remove its
   Proxy-State Attribute if it added one.  Proxy-State is always added
   or removed after any other Proxy-States, but no other assumptions
   regarding its location within the list of attributes can be made.
   Since Disconnect and CoA responses are authenticated on the entire
   packet contents, the stripping of the Proxy-State attribute
   invalidates the integrity check - so the proxy needs to recompute it.
   A forwarding proxy MUST NOT modify existing Proxy-State, State, or
   Class attributes present in the packet.

   If there are any Proxy-State attributes in a Disconnect or CoA-
   Request received from the server, the forwarding proxy MUST include
   those Proxy-State attributes in its response to the server. The
   forwarding proxy MAY include the Proxy-State attributes in the
   Disconnect or CoA-Request when it forwards the request, or it MAY
   omit them in the forwarded request.  If the forwarding proxy omits
   the Proxy-State attributes in the request, it MUST attach them to the
   response before sending it to the server.

3.  Attributes

In Disconnect and CoA-Request packets, certain attributes are used to
uniquely identify the NAS as well as a user session on the NAS.  All NAS
and session identification attributes SHOULD match in order for a
Disconnect or CoA-Request to be successful; otherwise a Disconnect-NAK
or CoA-NAK MUST be sent.  The ability to use NAS or session
identification attributes to map to unique/multiple sessions is beyond
the scope of this document.  Identification attributes include NAS and



Chiba, et al.                 Informational                     [Page 8]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


session identification attributes, as described below.

   NAS identification attributes

   Attribute             #    Reference  Description
   ---------            ---   ---------  -----------
   NAS-IP-Address        4    [RFC2865]  The IPv4 address of the NAS.
   NAS-Identifier       32    [RFC2865]  String identifying the NAS.
   NAS-IPv6-Address     95    [RFC3162]  The IPv6 address of the NAS.

   Session identification attributes

   Attribute              #    Reference  Description
   ---------             ---   ---------  -----------
   User-Name              1    [RFC2865]  The name of the user
                                          associated with the session.
   NAS-Port               5    [RFC2865]  The port on which the session
                                          is terminated.
   Framed-IP-Address      8    [RFC2865]  The IPv4 address associated
                                          with the session.
   Called-Station-Id     30    [RFC2865]  The link address to which the
                                          session is connected.
   Calling-Station-Id    31    [RFC2865]  The link address from which the
                                          session is connected.
   Acct-Session-Id       44    [RFC2866]  The identifier uniquely identifying
                                          the session on the NAS.
   Acct-Multi-Session-Id 50    [RFC2866]  The identifier uniquely identifying
                                          related sessions.
   NAS-Port-Type         61    [RFC2865]  The type of port used.
   NAS-Port-Id           87    [RFC2869]  String identifying the port on
                                          which the session is terminated.
   Originating-Line-Info 94    [NASREQ]   Provides information on the
                                          characteristics of the line from
                                          which a call originated.
   Framed-Interface-Id   96    [RFC3162]  The IPv6 Interface Identifier
                                          associated with the session; always
                                          sent with Framed-IPv6-Prefix.
   Framed-IPv6-Prefix    97    [RFC3162]  The IPv6 prefix associated with
                                          the session, always sent with
                                          Framed-Interface-Id.

To address security concerns described in Section 5.1, the User-Name
attribute SHOULD be present in Disconnect or CoA-Request packets; one or
more additional session identification attributes MAY also be present.
To address security concerns described in Section 5.2, one or more of
the NAS-IP-Address or NAS-IPv6-Address attributes SHOULD be present in
Disconnect or CoA-Request packets; the NAS-Identifier attribute MAY be
present in addition.



Chiba, et al.                 Informational                     [Page 9]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


As enumerated in Section 3.2, CoA-Request messages may also contain
attributes representing requested authorization changes.  If one or more
authorization changes specified in a CoA-Request cannot be carried out,
or if one or more attributes is unsupported, a CoA-NAK MUST be sent.

3.1.  Error-Cause

Description

   It is possible that the NAS cannot honor Disconnect-Request or CoA-
   Request messages for some reason. The Error-Cause attribute provides
   more detail on the cause of the problem. It MAY be included within
   Disconnect-ACK, Disconnect-NAK and CoA-NAK messages and is logged by
   the RADIUS server.

   A summary of the Error-Cause attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

   TBD for Error-Cause

Length

   6

Value

   The Value field is four octets, containing an integer specifying the
   cause of the  error. Values 0-199 and 300-399 are reserved.  Values
   200-299 represent successful completion, so that these values may
   only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be
   sent within a Disconnect-NAK or CoA-NAK.  Values 400-499 represent
   fatal errors committed by the RADIUS server, so that they MAY be sent
   within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent
   within CoA-ACK or Disconnect-ACK messages.  Values 500-599 represent
   fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be
   sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent
   within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD
   be logged by the RADIUS server.  Error-Code values (expressed in



Chiba, et al.                 Informational                    [Page 10]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


   decimal) include:

    #     Value
   ---    -----
   201    Residual Session Context Removed
   202    Invalid EAP Packet (Ignored)
   401    Unsupported Attribute
   402    Missing Attribute
   403    NAS Identification Mismatch
   404    Invalid Request
   501    Administratively Prohibited
   502    Request Not Routable (Proxy)
   503    Session Context Not Found
   504    Session Context Not Removable
   505    Other Proxy Processing Error

   "Residual Session Context Removed" is sent in response to a
   Disconnect-Request if the user session is no longer active, but
   residual session context was found, and successfully removed.  This
   value is only sent within a Disconnect-ACK and MUST NOT be sent
   within a CoA-ACK, Disconnect-NAK or CoA-NAK.

   "Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be
   sent by implementations of this specification.

   "Unsupported Attribute" is a fatal error sent if a CoA-Request or
   Disconnect-Request message contains an attribute (such as a Vendor-
   Specific or EAP-Message attribute) that is not supported.

   "Missing Attribute" is a fatal error sent if critical attributes
   (such as NAS or session identification attributes) are missing.

   "NAS Identification Mismatch" is a fatal error sent if one or more
   NAS identification attributes (see Section 3) do not match the
   identity of the NAS receiving the Disconnect-Request or CoA-Request.

   "Invalid Request" is a fatal error sent if some other aspect of the
   message is invalid, such as if one or more attributes (such as EAP-
   Message attribute(s)) are not formatted properly.

   "Administratively Prohibited" is a fatal error sent if the NAS is
   configured to prohibit honoring of Disconnect-Request or CoA-Request
   messages for the specified session.

   "Request Not Routable" is a fatal error which MAY be sent by a RADIUS
   proxy and MUST NOT be sent by a NAS.  It indicates that the RADIUS
   proxy was unable to determine how to route the Disconnect-Request or
   CoA-Request message to the NAS. For example, this can occur if the



Chiba, et al.                 Informational                    [Page 11]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


   required entries are not present in the proxy's realm routing table.

   "Session Context Not Found" is a fatal error sent in response to a
   CoA-Request or Disconnect-Request if the session context identified
   in the Request does not exist on the NAS.

   "Session Context Not Removable" is a fatal error sent in response to
   a Disconnect-Request if the NAS was able to locate the session
   context, but could not remove it for some reason.  It MUST NOT be
   sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a
   Disconnect-NAK.

   "Other Proxy Processing Error" is a fatal error sent in response to a
   Disconnect or CoA-Request that could not be processed by a proxy, for
   reasons other than routing.

3.2.  Table of Attributes

The following table provides a guide to which attributes may be found in
which packets, and in what quantity.

Change-of-Authorization Messages

Request   ACK      NAK   #   Attribute
0-1       0        0     1   User-Name [Note 1]
0-1       0        0     4   NAS-IP-Address [Note 1]
0-1       0        0     5   NAS-Port [Note 1]
0-1       0        0     7   Framed-Protocol [Note 3]
0-1       0        0     8   Framed-IP-Address [Note 1]
0-1       0        0     9   Framed-IP-Netmask [Note 3]
0-1       0        0    10   Framed-Routing [Note 3]
0+        0        0    11   Filter-ID [Note 3]
0-1       0        0    12   Framed-MTU [Note 3]
0+        0        0    13   Framed-Compression [Note 3]
0+        0        0    14   Login-IP-Host [Note 3]
0-1       0        0    15   Login-Service [Note 3]
0-1       0        0    16   Login-TCP-Port [Note 3]
0+        0        0    18   Reply-Message [Note 2]
0-1       0        0    19   Callback-Number [Note 3]
0-1       0        0    20   Callback-Id [Note 3]
0+        0        0    22   Framed-Route [Note 3]
0-1       0        0    23   Framed-IPX-Network [Note 3]
0-1       0        0    24   State [Note 3]
0+        0        0    25   Class [Note 3]
0+        0        0    26   Vendor-Specific [Note 3]
Request   ACK      NAK   #   Attribute





Chiba, et al.                 Informational                    [Page 12]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Request   ACK      NAK   #   Attribute
0-1       0        0    27   Session-Timeout [Note 3]
0-1       0        0    28   Idle-Timeout [Note 3]
0-1       0        0    29   Termination-Action [Note 3]
0-1       0        0    30   Called-Station-Id [Note 1]
0-1       0        0    31   Calling-Station-Id [Note 1]
0-1       0        0    32   NAS-Identifier [Note 1]
0+        0+       0+   33   Proxy-State
0-1       0        0    34   Login-LAT-Service [Note 3]
0-1       0        0    35   Login-LAT-Node [Note 3]
0-1       0        0    36   Login-LAT-Group [Note 3]
0-1       0        0    37   Framed-AppleTalk-Link [Note 3]
0+        0        0    38   Framed-AppleTalk-Network [Note 3]
0-1       0        0    39   Framed-AppleTalk-Zone [Note 3]
0-1       0        0    44   Acct-Session-Id [Note 1]
0-1       0        0    50   Acct-Multi-Session-Id [Note 1]
0-1       0-1      0-1  55   Event-Timestamp
0-1       0        0    61   NAS-Port-Type [Note 1]
0-1       0        0    62   Port-Limit [Note 3]
0-1       0        0    63   Login-LAT-Port [Note 3]
0+        0        0    64   Tunnel-Type [Note 5]
0+        0        0    65   Tunnel-Medium-Type [Note 5]
0+        0        0    66   Tunnel-Client-Endpoint [Note 5]
0+        0        0    67   Tunnel-Server-Endpoint [Note 5]
0+        0        0    69   Tunnel-Password [Note 5]
0-1       0        0    71   ARAP-Features [Note 3]
0-1       0        0    72   ARAP-Zone-Access [Note 3]
0+        0        0    78   Configuration-Token [Note 3]
0+        0-1      0    79   EAP-Message [Note 2]
0-1       0-1      0-1  80   Message-Authenticator
0+        0        0    81   Tunnel-Private-Group-ID [Note 5]
0+        0        0    82   Tunnel-Assignment-ID [Note 5]
0+        0        0    83   Tunnel-Preference [Note 5]
0-1       0        0    85   Acct-Interim-Interval [Note 3]
0-1       0        0    87   NAS-Port-Id [Note 1]
0-1       0        0    88   Framed-Pool [Note 3]
0+        0        0    90   Tunnel-Client-Auth-ID [Note 5]
0+        0        0    91   Tunnel-Server-Auth-ID [Note 5]
0-1       0        0    94   Orginating-Line-Info [Note 1]
0-1       0        0    95   NAS-IPv6-Address [Note 1]
0-1       0        0    96   Framed-Interface-Id [Note 1]
0+        0        0    97   Framed-IPv6-Prefix [Note 1]
0+        0        0    98   Login-IPv6-Host [Note 3]
0+        0        0    99   Framed-IPv6-Route [Note 3]
0-1       0        0   100   Framed-IPv6-Pool [Note 3]
0         0        0+  TBD   Error-Cause
Request   ACK      NAK   #   Attribute




Chiba, et al.                 Informational                    [Page 13]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Disconnect Messages

Request   ACK      NAK   #   Attribute
0-1       0        0     1   User-Name [Note 1]
0-1       0        0     4   NAS-IP-Address [Note 1]
0-1       0        0     5   NAS-Port [Note 1]
0-1       0        0     8   Framed-IP-Address [Note 1]
0+        0        0    18   Reply-Message [Note 2]
0+        0        0    25   Class [Note 4]
0+        0        0    26   Vendor-Specific
0-1       0        0    30   Called-Station-Id [Note 1]
0-1       0        0    31   Calling-Station-Id [Note 1]
0-1       0        0    32   NAS-Identifier [Note 1]
0+        0+       0+   33   Proxy-State
0-1       0        0    44   Acct-Session-Id [Note 1]
0-1       0-1      0    49   Acct-Terminate-Cause
0-1       0        0    50   Acct-Multi-Session-Id [Note 1]
0-1       0-1      0-1  55   Event-Timestamp
0-1       0        0    61   NAS-Port-Type [Note 1]
0+        0-1      0    79   EAP-Message [Note 2]
0-1       0-1      0-1  80   Message-Authenticator
0-1       0        0    87   NAS-Port-Id [Note 1]
0-1       0        0    94   Orginating-Line-Info [Note 1]
0-1       0        0    95   NAS-IPv6-Address [Note 1]
0-1       0        0    96   Framed-Interface-Id [Note 1]
0+        0        0    97   Framed-IPv6-Prefix [Note 1]
0         0+       0+  TBD   Error-Cause
Request   ACK      NAK   #   Attribute

[Note 1] Where NAS or session identification attributes are included in
Disconnect-Request or CoA-Request messages, they are used for
identification purposes only.  These attributes MUST NOT be used for
purposes other than identification (e.g. within CoA-Request messages to
request authorization changes).

[Note 2] The Reply-Message attribute is used to present a displayable
message to the user. The message is only displayed as a result of a
successful Disconnect or CoA-Request (where a Disconnect-ACK or CoA-ACK
is subsequently sent).  Where EAP is used for authentication, an EAP-
Message/Notification-Request attribute is sent instead, and Disconnect-
ACK or CoA-ACK messages contain an EAP-Message/Notification-Response.

[Note 3] When included within a CoA-Request, these attributes represent
an authorization change request. When one of these attributes is omitted
from a CoA-Request, the NAS assumes that the attribute value is to
remain unchanged. Attributes included in a CoA-Request replace all
existing value(s) of the same attribute(s).




Chiba, et al.                 Informational                    [Page 14]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


[Note 4] When included within a successful Disconnect-Request (where a
Disconnect-ACK is subsequently sent), the Class attribute SHOULD be sent
unmodified by the client to the accounting server in the Accounting Stop
packet. If the Disconnect-Request is unsuccessful, then the the Class
attribute is ignored.

[Note 5] When included within a CoA-Request, these attributes represent
an authorization change request. Where tunnel attribute(s) are sent
within a successful CoA-Request, all existing tunnel attributes are
removed and replaced by the new attribute(s).

The following table defines the meaning of the above table entries.

0     This attribute MUST NOT be present in packet.
0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.
1     Exactly one instance of this attribute MUST be present in packet.

4.  IANA Considerations

This draft uses the RADIUS [RFC2865] namespace, see
<http://www.iana.org/assignments/radius-types>.  There are six updates
for the section: RADIUS Packet Type Codes.  These Packet Types are
allocated in [RADIANA]:

40 - Disconnect-Request
41 - Disconnect-ACK
42 - Disconnect-NAK
43 - CoA-Request
44 - CoA-ACK
45 - CoA-NAK

This draft also uses the UDP [RFC768] namespace, see
<http://www.iana.org/assignments/port-numbers>.  The authors request a
port assignment from the Registered ports range. Finally, this
specification allocates the Error-Cause attribute (TBD) with the
following decimal values:

 #     Value
---    -----
201    Residual Session Context Removed
202    Invalid EAP Packet (Ignored)
401    Unsupported Attribute
402    Missing Attribute
403    NAS Identification Mismatch
404    Invalid Request
501    Administratively Prohibited
502    Request Not Routable (Proxy)



Chiba, et al.                 Informational                    [Page 15]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


503    Session Context Not Found
504    Session Context Not Removable
505    Other Proxy Processing Error

5.  Security Considerations

5.1.  Authorization issues

Where a NAS is shared by multiple providers, it is undesirable for one
provider to be able to send Disconnect or CoA-Requests affecting the
sessions of another provider.

To prevent this, the RADIUS proxy SHOULD perform a "reverse path
forwarding" (RPF) check to verify that a Disconnect or CoA-Request is
originating from an authorized RADIUS server.  In a network model where
a proxy is employed to forward Disconnect or CoA Requests, the NAS MUST
accept Disconnect or CoA-Requests from only from proxies that it is
configured to trust for those requests. Requests from untrusted sources
SHOULD be silently discarded.

To perform the RPF check, the proxy uses the session identification
attributes included in the Disconnect or CoA-Request to determine the
RADIUS server(s) to which an equivalent Access-Request would be routed.
If this matches the source address of the Disconnect or CoA-Request,
then the Request is forwarded; otherwise it SHOULD be silently
discarded.

Typically the proxy will extract the realm from the Network Access
Identifier [RFC2486] included within the User-Name attribute, and
determine the corresponding RADIUS servers in the proxy routing tables.
The RADIUS servers for that realm  are then compared against the source
address of the packet.  Where no RADIUS proxy is present, the RPF check
will need to be performed by the NAS itself.

Since authorization to send a Disconnect or CoA-Request is determined
based on the source address and the corresponding shared secret, the
NASes or proxies SHOULD configure a different shared secret for each
RADIUS server.

5.2.  Impersonation

[RFC2865] Section 3 states:

   A RADIUS server MUST use the source IP address of the RADIUS
   UDP packet to decide which shared secret to use, so that
   RADIUS requests can be proxied.

When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or



Chiba, et al.                 Informational                    [Page 16]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


NAS-IPv6-Address attributes will typically not match the source address
observed by the RADIUS server. Since the NAS-Identifier attribute need
not contain an FQDN, this attribute may not be resolvable to the source
address observed by the RADIUS server, even when no proxy is present.

As a result, the authenticity check performed by a RADIUS server or
proxy does not verify the correctness of NAS identification attributes.
This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-
IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request
in order to impersonate another NAS. It is also possible for a rogue NAS
to forge session identification attributes such as the Called-Station-Id
Calling-Station-Id, or Originating-Line-Info [NASREQ].  This could fool
the RADIUS server into sending Disconnect or CoA-Request messages
containing forged session identification attributes to a NAS targeted by
an attacker.

To address these vulnerabilities RADIUS proxies SHOULD check whether NAS
identification attributes (see Section 3) match the source address of
packets originating from the NAS. Where a match is not found, Disconnect
or CoA-Request messages SHOULD be silently discarded.

However, such a check may not always be possible. Since the NAS-
Identifier attribute need not correspond to an FQDN, it may not be
resolvable to an IP address to be matched against the source address.
Also, where a NAT exists between the RADIUS client and proxy, checking
the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible.

5.3.  IPsec usage guidelines

In addition to the security vulnerabilities discussed earlier, the
protocol exchanges described are susceptible to the same vulnerabilities
as RADIUS [RFC2865]. It is recommended that IPsec be employed to afford
better security.

Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with
non-null transform SHOULD be supported, and per-packet encryption,
authentication, integrity and replay protection SHOULD be used, along
with IKE for key management.

Within RADIUS [RFC2865], a shared secret is used for hiding of
attributes such as User-Password, as well as in computation of the
Response Authenticator. In RADIUS accounting [RFC2866], the shared
secret is used in computation of both the Request Authenticator and the
Response Authenticator.

Since in RADIUS a shared secret is used to provide confidentiality as
well as integrity protection and authentication, only use of IPsec ESP



Chiba, et al.                 Informational                    [Page 17]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


with a non-null transform can provide security services sufficient to
substitute for RADIUS application-layer security.  Therefore, where
IPSEC AH or ESP null is used, it will typically still be necessary to
configure a RADIUS shared secret.

Where RADIUS is run over IPsec ESP with a non-null transform, the secret
shared between the NAS and the RADIUS server may not be configured.  In
this case, a shared secret of zero length MUST be assumed.  However, a
RADIUS server that cannot know whether incoming traffic is IPsec-
protected MUST be configured with a non-null RADIUS shared secret.

When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the
encryption transform, and per-packet authentication, integrity and
replay protection MUST be used. A typical IPsec policy for an IPsec-
capable RADIUS client is "Initiate IPsec, from me to any destination
port UDP 1812".

This causes an IPsec SA to be set up by the RADIUS client prior to
sending RADIUS traffic. If some RADIUS servers contacted by the client
do not support IPsec, then a more granular policy will be required:
"Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
port UDP 1812".

For a client implementing this specification the policy would be "Accept
IPsec, from any to me, destination port UDP TBD". This causes the RADIUS
client to accept (but not require) use of IPsec. It may not be
appropriate to require IPsec for all RADIUS servers connecting to an
IPsec-enabled RADIUS client, since some RADIUS servers may not support
IPsec.

For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
IPsec, from any to me, destination port 1812".  This causes the RADIUS
server to accept (but not require) use of IPsec. It may not be
appropriate to require IPsec for all RADIUS clients connecting to an
IPsec-enabled RADIUS server, since some RADIUS clients may not support
IPsec.

For servers implementing this specification, the policy would be
"Initiate IPsec, from me to any, destination port UDP TBD". This causes
the RADIUS server to initiate IPsec when sending RADIUS extension
traffic to any RADIUS client. If some RADIUS clients contacted by the
server do not support IPsec, then a more granular policy will be
required, such as "Initiate IPsec, from me to IPsec-capable-RADIUS-
client, destination port UDP TBD".

Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that trust be demonstrated between the
RADIUS client and RADIUS server by some means. For example, before



Chiba, et al.                 Informational                    [Page 18]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS
server should check whether the host is authorized to provide network
access. Similarly, before enabling an IKE-authenticated host to act as a
RADIUS server, the RADIUS client should check whether the host is
authorized for that role.

RADIUS servers can be configured with the IP addresses (for IKE
Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS clients.  Alternatively, if a separate CA
exists for RADIUS clients, then the RADIUS server can configure this CA
as a trusted root for use with IPsec.

Similarly, RADIUS clients can be configured with the IP addresses (for
IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS servers.  Alternatively, if a separate CA
exists for RADIUS servers, then the RADIUS client can configure this CA
as a trusted root for use with IPsec.

Since unlike SSL/TLS, IKE does not permit certificate policies to be set
on a per-port basis, certificate policies need to apply to all uses of
IPsec on RADIUS clients and servers. In IPsec deployment supporting only
certificate authentication, a management station initiating an IPsec-
protected telnet session to the RADIUS server would need to obtain a
certificate chaining to the RADIUS client CA. Issuing such a certificate
might  not be appropriate if the management station was not authorized
as a RADIUS client.

Where RADIUS clients may obtain their IP address dynamically (such as an
Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409]
SHOULD NOT be used, since this requires use of a group pre-shared key;
instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses
are statically assigned either Aggressive Mode or Main Mode MAY be used.
With certificate authentication, Main Mode SHOULD be used.

Care needs to be taken with IKE Phase 1 Identity Payload selection in
order to enable mapping of identities to pre-shared keys even with
Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
Payloads are used and addresses are dynamically assigned, mapping of
identities to keys is not possible, so that group pre-shared keys are
still a practical necessity. As a result, the ID_FQDN identity payload
SHOULD be employed in situations where Aggressive mode is utilized along
with pre-shared keys and IP addresses are dynamically assigned. This
approach also has other advantages, since it allows the RADIUS server
and client to configure themselves based on the fully qualified domain
name of their peers.

Note that with IPsec, security services are negotiated at the
granularity of an IPsec SA, so that RADIUS exchanges requiring a set of



Chiba, et al.                 Informational                    [Page 19]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


security services different from those negotiated with existing IPsec
SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also
advisable where quality of service considerations dictate different
handling RADIUS conversations. Attempting to apply different quality of
service to connections handled by the same IPsec SA can result in
reordering, and falling outside the replay window. For a discussion of
the issues, see [RFC2983].

5.4.  Replay protection

Where IPsec is not used, in order to provide replay protection, the
Event-Timestamp (55) attribute, described in [RFC2869] SHOULD be
included. When this attribute is present, the RADIUS server MUST check
that the Event-Timestamp is current within an acceptable time window.
This implies the need for time synchronization within the network, which
can be achieved by a variety of means, including secure NTP, as
described in [NTPAUTH].  A default time window of 300 seconds is
recommended.

6.  Example traces

Disconnect Request with User-Name:

   0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23    .B.....$.-(....#
  16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108    bL5C..U..U...^..
  32: 6d63 6869 6261

Disconnect Request with Acct-Session-ID:

   0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d    .B..... ~.(.....
  16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a    .SU.......N8w.,.
  32: 3930 3233 3435 3637                        90234567

Disconnect Request with Framed-IP-Address:

   0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda    .B....."2.(.....
  16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806    3.v[.....*/kQ...
  32: 0a00 0203

7.  Normative References

[RFC1305]      Mills, D. L., "Network Time Protocol (version 3)
               Specification, Implementation and Analysis, RFC 1305
               March, 1992.

[RFC1321]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
               April 1992.




Chiba, et al.                 Informational                    [Page 20]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


[RFC2104]      Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
               Hashing for Message Authentication", RFC 2104, February
               1997.

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, March 1997.]

[RFC2401]      Atkinson, R., Kent, S., "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

[RFC2406]      Kent, S., Atkinson, R., "IP Encapsulating Security
               Payload (ESP)", RFC 2406, November 1998

[RFC2409]      Harkins, D., Carrel, D., "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998

[RFC2434]      Alvestrand, H. and Narten, T., "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
               October 1998.

[RFC2486]      Aboba, B., Beadles, M., "The Network Access Identifier",
               RFC 2486, January 1999.

[RFC2865]      Rigney, C., Rubens, A., Simpson, W., Willens, S.,
               "Remote Authentication Dial In User Service (RADIUS)",
               RFC 2865, June 2000.

[RFC2866]      Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2869]      Rigney, C., Willats W., Calhoun P., "RADIUS Extensions",
               RFC 2869, June 2000.

[RFC3162]      Aboba, B., Zorn, G., Mitton, D., "RADIUS and IPv6", RFC
               3162, August 2001.

[RADIANA]      Aboba, B., "IANA Considerations for RADIUS", Internet
               draft (work in progress), draft-aboba-radius-iana-04.txt,
               April 2003.

8.  Informative references

[RFC2882]      Mitton, D., "Network Access Server Requirements: Extended
               RADIUS Practices", RFC 2882, July 2000.

[RFC2983]      Black, D. "Differentiated Services and Tunnels", RFC
               2983, October 2000.





Chiba, et al.                 Informational                    [Page 21]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


[Diameter]     Calhoun, P., et al., "Diameter Base Protocol", draft-
               ietf-aaa-diameter-17.txt, Internet draft (work in
               progress), December 2002.

[NASREQ]       Calhoun, P., et al., "Diameter Network Access Server
               Application", draft-ietf-aaa-diameter-nasreq-11.txt,
               Internet draft (work in progress), February 2003.

[NTPAUTH]      Mills, D., "Public Key Cryptography for the Network Time
               Protocol", Internet draft (work in progress), draft-ietf-
               stime-ntpauth-03.txt, February 2002.

Acknowledgments

Funding for the RFC Editor function is currently provided by the
Internet Society.

This protocol was first developed and distributed by Ascend
Communications.  Example code was distributed in their free server kit.

The authors would like to acknowledge the valuable suggestions and
feedback from the following people:

   Avi Lior <avi@bridgewatersystems.com>,
   Randy Bush <randy@psg.net>,
   Glen Zorn <gwz@cisco.com>,
   Mark Jones <mjones@bridgewatersystems.com>,
   Claudio Lapidus <clapidus@hotmail.com>,
   Anurag Batta <Anurag_Batta@3com.com>,
   Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
   Tim Moore <timmoore@microsoft.com>.

Authors' Addresses

Murtaza Chiba
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA, 95134

EMail: mchiba@cisco.com
Phone: +1 408 525 7198

Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134

EMail: gdommety@cisco.com



Chiba, et al.                 Informational                    [Page 22]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Phone: +1 408 525 1404

Mark Eklund
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134

EMail: meklund@cisco.com
Phone: +1 865 671 6255

David Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845

EMail: david@mitton.com
Phone: +1 978 683 1814

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax:   +1 425 936 7329

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementers or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.



Chiba, et al.                 Informational                    [Page 23]


INTERNET-DRAFT      Dynamic Authorization Extensions        8 April 2003


Full Copyright Statement

Copyright (C) The Internet Society (2003).  All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.  However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.  The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its
successors or assigns.  This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expiration Date

This memo is filed as <draft-chiba-radius-dynamic-authorization-12.txt>,
and  expires October 19, 2003.
























Chiba, et al.                 Informational                    [Page 24]