One document matched: draft-chiba-radius-dynamic-authorization-18.txt
Differences from draft-chiba-radius-dynamic-authorization-17.txt
Network Working Group Murtaza S. Chiba
INTERNET-DRAFT Gopal Dommety
Category: Informational Mark Eklund
<draft-chiba-radius-dynamic-authorization-18.txt> Cisco Systems, Inc.
23 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 23 April 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Applicability ................................... 3
1.2 Requirements language ........................... 4
1.3 Terminology ..................................... 4
2. Overview ............................................. 5
2.1 Disconnect Messages (DM) ........................ 5
2.2 Change-of-Authorization Messages (CoA) .......... 5
2.3 Packet format ................................... 6
3. Attributes ............................................ 10
3.1 Error-Cause ..................................... 11
3.2 Table of Attributes ............................. 14
4. IANA Considerations ................................... 17
5. Security considerations ............................... 17
5.1 Authorization issues ............................ 17
5.2 Impersonation ................................... 18
5.3 IPsec usage guidelines .......................... 19
5.4 Replay protection ............................... 22
6. Example traces ........................................ 22
7. Normative references .................................. 22
8. Informative references ................................ 23
ACKNOWLEDGMENTS .............................................. 24
AUTHORS' ADDRESSES ........................................... 25
Intellectual property statement .............................. 26
Full Copyright Statement ..................................... 26
Chiba, et al. Informational [Page 2]
INTERNET-DRAFT Dynamic Authorization Extensions 23 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 CoA messages modify session
authorization attributes such as data filters.
1.1. Applicability
This protocol is being recommended for publication as an Informational
RFC rather than as a standards-track RFC due to problems which can't be
fixed without creating incompatibilities with deployed implementations.
This includes security vulnerabilities as well as semantic ambiguities
resulting from the design of the Change-of-Authorization (CoA) commands.
While fixes to the security vulnerabilities are recommended, these
cannot be made mandatory since this would be incompatible with existing
implementations.
Existing implementations of this protocol do not support authorization
checks, so that an ISP sharing a NAS with another ISP could disconnect
or change authorizations for another ISP's users. In order to remedy
this problem a "Reverse Path Forwarding" check is recommended. See
Section 5.1 for details.
Existing implementations utilize per-packet authentication and integrity
protection algorithms with known weaknesses [MD5Attack]. To provide
stronger per-packet authentication and integrity protection, the use of
IPsec is recommended. See Section 5.3 for details.
Existing implementations lack replay protection. In order to support
replay detection, it is recommended that the Event-Timestamp attribute
be added to all messages in situations where IPsec replay protection is
not employed. Implementations should be configurable to silently
discard messages lacking the Event-Timestamp attribute. See Section 5.4
for details.
Chiba, et al. Informational [Page 3]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
The approach taken with the CoA commands results in a semantic
ambiguity. A CoA-Request both identifies the affected session as well
as supplying the authorization changes. Since RADIUS attributes
included within the CoA-Request can be used either for session
identification or authorization change, it may not be clear which
function a given attribute is serving. In order to provide
clarification, attribute usage is specified in detail in Section 3.
The problem does not exist within [Diameter], in which authorization
change is requested by a command using Attribute Value Pairs (AVPs)
solely for identification, resulting in initiation of a standard
Request/Response sequence where authorization changes are supplied. As
a result, in no command can Diameter AVPs have multiple potential
meanings.
Due to differences in handling change-of-authorization requests in
RADIUS and Diameter, may not be possible to successfully gateway
Diameter authorization changes to RADIUS. For example, a Diameter
command attempting to change any attribute used for identification
within a RADIUS CoA-Request is untranslatable, since such an
authorization change is impossible to carry out within the protocol
specified in this document. Similarly, translation of a RADIUS CoA-
Request to an equivalent Diameter command is tricky because a single
RADIUS command will need to be translated to multiple Diameter commands.
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
"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].
1.3. 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
Chiba, et al. Informational [Page 4]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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.
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 | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a RADIUS server
with a 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
Chiba, et al. Informational [Page 5]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
applied for the session that the identification
attributes map to.
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a RADIUS server with a CoA-ACK
if the NAS is able to successfully change the authorizations for the
user session, or a CoA-NAK if the Request is unsuccessful.
2.3. Packet format
For either Disconnect-Request or CoA-Request messages 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. Packets received with an invalid Code field MUST be silently
discarded. RADIUS codes (decimal) for this extension are assigned as
Chiba, et al. Informational [Page 6]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
follows:
40 - Disconnect-Request [RFC2882]
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. Dynamic
estimation of the retransmission timer, described in [RFC2988], is
RECOMMENDED. The Identifier field MUST be changed whenever the
content of the Attributes field changes, or 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. Issues relating to failover algorithms are
described in [AAATransport]. 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
Chiba, et al. Informational [Page 7]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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.
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-Request or CoA-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
Chiba, et al. Informational [Page 8]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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.
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-Request 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-Request 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-Request 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.
Chiba, et al. Informational [Page 9]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
3. Attributes
In Disconnect-Request and CoA-Request packets, certain attributes are
used to uniquely identify the NAS as well as a user session on the NAS.
All NAS identification attributes included in a Request message MUST
match in order for a Disconnect-Request or CoA-Request to be successful;
otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. For session
identification attributes, the User-Name and Acct-Session-Id attributes,
if included, MUST match in order for a Disconnect-Request or CoA-Request
to be successful; other session identification attributes SHOULD match.
Where a mismatch of session identification attributes is detected, a
Disconnect-NAK or CoA-Nak SHOULD 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 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
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
Chiba, et al. Informational [Page 10]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
from which a session
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-Request 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-Request or CoA-Request packets; the NAS-
Identifier attribute MAY be present in addition.
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.
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
Chiba, et al. Informational [Page 11]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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
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
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
"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 Request contains
an attribute (such as a Vendor-Specific or EAP-Message attribute)
that is not supported.
Chiba, et al. Informational [Page 12]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
"Missing Attribute" is a fatal error sent if critical attributes
(such as NAS or session identification attributes) are missing from a
Request.
"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 Request.
"Invalid Request" is a fatal error sent if some other aspect of the
Request is invalid, such as if one or more attributes (such as EAP-
Message attribute(s)) are not formatted properly.
"Unsupported Service" is a fatal error sent if a Service-Type
attribute included with the Request is sent with an invalid or
unsupported value.
"Unsupported Extension" is a fatal error sent due to lack of support
for an extension such as Disconnect and/or CoA messages. This will
typically be sent by a proxy receiving an ICMP port unreachable
message after attempting to forward a Request to the NAS.
"Administratively Prohibited" is a fatal error sent if the NAS is
configured to prohibit honoring of 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 Request to the NAS.
For example, this can occur if the required entries are not present
in the proxy's realm routing table.
"Session Context Not Found" is a fatal error sent 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
Request that could not be processed by a proxy, for reasons other
than routing.
"Resources Unavailable" is a fatal error sent when a Request could
not be honored due to lack of available NAS resources (memory, non-
volatile storage, etc.)
Chiba, et al. Informational [Page 13]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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]
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]
Request ACK NAK # Attribute
Chiba, et al. Informational [Page 14]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
Request ACK NAK # Attribute
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
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]
Request ACK NAK # Attribute
Chiba, et al. Informational [Page 15]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
Request ACK NAK # Attribute
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-Request 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).
[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 Class
attribute is not processed.
[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.
Chiba, et al. Informational [Page 16]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
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-Request or CoA-Requests affecting
the sessions of another provider.
Chiba, et al. Informational [Page 17]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
To prevent this, the RADIUS proxy SHOULD perform a "reverse path
forwarding" (RPF) check to verify that a Disconnect-Request or CoA-
Request is originating from an authorized RADIUS server. In a network
model where a proxy is employed to forward Disconnect-Request or CoA-
Request messages, the NAS MUST accept these messages only from proxies
that it is configured to trust. Requests from untrusted sources MUST be
silently discarded.
To perform the RPF check, the proxy uses the session identification
attributes included in Disconnect-Request or CoA-Request messages, in
order to determine the RADIUS server(s) to which an equivalent Access-
Request would be routed. If this matches the source address of the
Disconnect-Request 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-Request 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
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
Chiba, et al. Informational [Page 18]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
could fool the RADIUS server into sending Disconnect-Request 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 one or more attributes do not
match, Disconnect-Request or CoA-Request messages SHOULD be silently
discarded.
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 security vulnerabilities unique to Disconnect or CoA
messages, the protocol exchanges described in this document 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 IPsec ESP with a non-null
encryption transform and authentication support SHOULD be used to
provide per-packet confidentiality, authentication, integrity and replay
protection. IKE SHOULD be used 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
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.
Chiba, et al. Informational [Page 19]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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
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
Certificate Authority (CA) exists for RADIUS clients, then the RADIUS
server can configure this CA as a trust anchor [RFC3280] for use with
Chiba, et al. Informational [Page 20]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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 trust anchor 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
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].
Chiba, et al. Informational [Page 21]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
5.4. Replay protection
Where IPsec replay protection is not used, the Event-Timestamp (55)
attribute [RFC2869] SHOULD be included within all messages. When this
attribute is present, both the NAS and the RADIUS server MUST check that
the Event-Timestamp is current within an acceptable time window. If the
Event-Timestamp is not current, then the message MUST be silently
discarded. 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].
Both the NAS and the RADIUS server SHOULD be configurable to silently
discard messages lacking an Event-Timestamp attribute. 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.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
Chiba, et al. Informational [Page 22]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2401] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"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. and P. Calhoun, "RADIUS
Extensions", RFC 2869, June 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RADIANA] Aboba, B., "IANA Considerations for RADIUS", Internet
draft (work in progress), draft-aboba-radius-iana-06.txt,
April 2003.
8. Informative references
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended
RADIUS Practices", RFC 2882, July 2000.
Chiba, et al. Informational [Page 23]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
2983, October 2000.
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting Transport Profile", draft-ietf-aaa-
transport-12.txt, Internet draft (work in progress),
January 2003.
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", draft-
ietf-aaa-diameter-17.txt, Internet draft (work in
progress), December 2002.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes Vol.2 No.2, Summer 1996.
[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>,
Steve Bellovin <smb@research.att.com>
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>.
Russ Housley <housley@vigilsec.com>
Chiba, et al. Informational [Page 24]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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
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
Chiba, et al. Informational [Page 25]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
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.
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.
Chiba, et al. Informational [Page 26]
INTERNET-DRAFT Dynamic Authorization Extensions 23 April 2003
Expiration Date
This memo is filed as <draft-chiba-radius-dynamic-authorization-18.txt>,
and expires November 19, 2003.
Chiba, et al. Informational [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-22 22:48:38 |