One document matched: draft-chiba-radius-dynamic-authorization-08.txt
Differences from draft-chiba-radius-dynamic-authorization-07.txt
Network Working Group Murtaza S. Chiba
INTERNET-DRAFT Gopal Dommety
Category: Informational Mark Eklund
<draft-chiba-radius-dynamic-authorization-08.txt> Cisco Systems, Inc.
22 March 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 data filters applicable to a user session.
Chiba, et al. Informational [Page 1]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
Table of Contents
1. Introduction .......................................... 3
1.1 Terminology ..................................... 3
1.2 Requirements language ........................... 4
1.3 Packet format ................................... 4
1.4 Retransmission .................................. 7
2. Current Practices .................................... 7
2.1 Disconnect Messages (DM) ........................ 7
2.2 Change-of-Filters Messages (CoF) ................ 8
3. Attributes ............................................ 8
3.1 Error-Cause ..................................... 8
3.2 Table of Attributes ............................. 11
4. IANA Considerations ................................... 12
5. Security considerations ............................... 12
5.1 Proxy issues .................................... 12
5.2 IPsec usage guidelines .......................... 13
5.3 Replay protection ............................... 15
5.4 Impersonation ................................... 16
6. Example traces ........................................ 16
7. Normative references .................................. 17
8. Informative references ................................ 18
ACKNOWLEDGMENTS .............................................. 18
AUTHORS' ADDRESSES ........................................... 18
Intellectual property statement .............................. 19
Full Copyright Statement ..................................... 20
Chiba, et al. Informational [Page 2]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
1. Introduction
The RADIUS protocol, defined in [RFC2865], does not support unsolicited
messages sent from the RADIUS server to the 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 data filters 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:
1) Disconnect messages and
2) Change of Filters messages
Disconnect messages cause a user session to be terminated immediately,
whereas change of filter 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.
Chiba, et al. Informational [Page 3]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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. Packet format
For either type of request (Disconnect, or Change of Filters), 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]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoF-Request [RFC2882]
Chiba, et al. Informational [Page 4]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
44 - CoF-ACK [RFC2882]
45 - CoF-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.
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.
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.
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.
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 client and RADIUS server.
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 CoF-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 Change-of-Filters Request .
Response Authenticator
Chiba, et al. Informational [Page 5]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
The Authenticator field in a Response packet (e.g. Disconnect-ACK,
Disconnect-NAK, CoF-ACK, or CoF-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.
Attributes
Attributes may have multiple instances, in such a case the order of
attributes of the same type SHOULD be preserved. The order of
attributes of different types is not required to be preserved.
Attributes are used to uniquely identify the NAS as well as a user
session on the NAS. One or more of the NAS-IP-Address, NAS-
IPv6-Address or NAS-Identifier attributes SHOULD be present in
Disconnect or Change-of-Filters messages. Similarly, one or more of
the session identification attributes SHOULD also be present. The set
of attributes includes the following:
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 user
connection is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Calling-Station-Id 30 [RFC2865] The link address associated
with the session.
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.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
Chiba, et al. Informational [Page 6]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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.
The ability to use all/some of the identifiers to map to
unique/multiple sessions is beyond the scope of this document.
1.4. Retransmission
Unlike RADIUS as defined in [RFC2865], the responsibility for
retransmission of Disconnect-Request and CoF-Request messages lies with
the RADIUS server. If after sending these messages, the RADIUS server
does not receive a response, it will retransmit. For retransmissions,
the Identifier MUST remain unchanged. If the contents of any attribute
is changed, a new Authenticator is needed, and therefore a new
Identifier.
If the RADIUS server is retransmitting a Disconnect-Request or CoF-
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.
2. Current Practices
This section outlines the details for Disconnect Messages and Change-of-
Filters Messages that are commonly implemented.
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 attributes described in Section 1.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
Chiba, et al. Informational [Page 7]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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-Filters Messages (CoF)
CoF-Request packets contain information for dynamically changing the
session authorization. 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 1.3. The port used, and packet format, are the same as that for
Disconnect-Request Messages.
The following attribute SHOULD be sent in a CoF-Request:
Filter-ID (11) - Indicates the name of a data filter list to be
applied for the session that the identification
attributes map to.
+----------+ CoF-Request +----------+
| | <-------------------- | |
| NAS | | Client |
| | CoF Response | |
| | ---------------------> | |
+----------+ +----------+
A CoF-Request is followed by a response of either CoF-ACK if the NAS is
able to successfully change the authorizations for the user session or a
CoF-NAK if it does not succeed.
3. Attributes
3.1. Error-Cause
Description
It is possible that the NAS cannot honor Disconnect-Request or CoF-
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 CoF-NAK messages and is logged by
the RADIUS server.
Chiba, et al. Informational [Page 8]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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 MUST
NOT be sent within a Disconnect-NAK or CoF-NAK. Values 400-499
represent fatal errors committed by the RADIUS server, so that they
MUST NOT be sent within CoF-ACK or Disconnect-ACK messages. Values
500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so
that they also MUST NOT be sent within CoF-ACK or Disconnect-ACK
messages. Illegal Error-Cause values are logged by the RADIUS server,
but otherwise ignored. Error-Code values include:
# Value
--- -----
201 Session Context Removed
401 Unsupported Attribute
402 Missing Attribute
403 Invalid Request
501 Administratively Prohibited
502 Request Not Routable
503 Session Inactive
504 Session Context Not Removable
"Session Context Removed" is sent in response to a Disconnect-Request
if the user session is no longer active, but session context that had
been remaining has been successfully removed. This value is only sent
within a Disconnect-ACK and MUST NOT be sent within a CoF-ACK or CoF-
NAK.
Chiba, et al. Informational [Page 9]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
"Unsupported Attribute" is a fatal error sent if a CoF-Request or
Disconnect-Request message contains an attribute (such as a Vendor-
Specific attribute) that is not supported.
"Missing Attribute" is a fatal error sent if a critical attribute
(such as NAS or session identification attributes) is missing.
"Invalid Request" is a fatal error sent if some other aspect of the
message is invalid, such as if one or more attributes are not
formatted properly.
"Administratively Prohibited" is a fatal error sent if the NAS is
configured to prohibit honoring of Disconnect-Request or CoF-Request
messages for this user 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
CoF-Request message to the NAS. For example, this can occur if the
required entries are not present in the proxy's realm routing table.
"Session Inactive" is a fatal error sent in response to a CoF-Request
if the user session is not currently active on the NAS, or in
response to a Disconnect-Request message if the user session is
currently not active on the NAS and all session context has already
been removed.
"Session Context Not Removable" is a fatal error sent in response to
a Disconnect-Request if the NAS could not completely remove the
session context for some reason. It MUST NOT be sent within a CoF-
ACK, CoF-NAK or Disconnect-ACK.
Chiba, et al. Informational [Page 10]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
3.2. Table of Attributes
The following table provides a guide to which attributes may be found in
which kinds of packets, and in what quantity.
Disconnect Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name
0-1 0 0 4 NAS-IP-Address
0-1 0 0 5 NAS-Port
0-1 0 0 8 Framed-IP-Address
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Calling-Station-Id
0-1 0 0 32 NAS-Identifier
0-1 0-1 0-1 33 Proxy-State
0-1 0 0 44 Acct-Session-Id
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id
0-1 0 0 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type
0-1 0 0 95 NAS-IPv6-Address
0-1 0 0 96 Framed-Interface-Id
0-1 0 0 97 Framed-IPv6-Prefix
0 0-1 0-1 TBD Error-Cause
Request ACK NAK # Attribute
Change-of-Filters Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name
0-1 0 0 4 NAS-IP-Address
0-1 0 0 5 NAS-Port
0-1 0 0 8 Framed-IP-Address
0+ 0 0 11 Filter-ID
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Calling-Station-Id
0-1 0 0 32 NAS-Identifier
0-1 0-1 0-1 33 Proxy-State
0-1 0 0 44 Acct-Session-Id
0-1 0 0 50 Acct-Multi-Session-Id
0-1 0 0 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type
0-1 0 0 95 NAS-IPv6-Address
0-1 0 0 96 Framed-Interface-Id
0-1 0 0 97 Framed-IPv6-Prefix
0 0 0-1 TBD Error-Cause
Request ACK NAK # Attribute
Chiba, et al. Informational [Page 11]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
Note: Other attributes SHOULD NOT be included by an implementation.
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 - CoF-Request
44 - CoF-ACK
45 - CoF-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 with the following
values:
# Value
--- -----
201 Session Context Removed
401 Unsupported Attribute
402 Missing Attribute
403 Invalid Request
501 Administratively Prohibited
502 Request Not Routable
503 Session Inactive
504 Session Context Not Removable
5. Security Considerations
The protocol exchanges described are susceptible to the same
vulnerabilities as RADIUS and it is recommended that IPsec be employed
to afford better security.
5.1. Proxy issues
If the Request to a primary proxy fails, a secondary proxy must be
queried if available. However, where the RADIUS server is sending
directly to the client, failover typically does not make sense, since
Disconnect or CoF messages need to be delivered to the NAS where the
user resides.
Chiba, et al. Informational [Page 12]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
In a network model where a proxy is employed to forward the disconnect
requests, the NAS MUST accept requests from proxies that it trusts, all
other requests from untrusted sources SHOULD be silently discarded.
Routing such requests via proxies and creating trust relationships, are
considered to be outside the scope of this document. Attribute ordering
MUST remain unchanged, although new attributes (e.g. Proxy-State) MAY be
added.
Proxy-State attributes are handled similarly to [RFC2865]. If there are
any Proxy-State attributes in a Disconnect-Reqeust or CoF-Request
received from the server, the forwarding client MUST include those
Proxy-State attributes in its reply to the server. The forwarding
client MAY include the Proxy-State attributes in the Disconnect-Request
or CoF-Request when it forwards the request, or MAY omit them in the
forwarded request. If the forwarding client omits the Proxy-State
attributes in the forwarded Disconnect-Request or CoF-Request, it MUST
attach them to the response before sending it to the server.
5.2. IPsec usage guidelines
Implementations of this specification SHOULD support IPsec [RFC2401]
along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with
non-null transform, and per-packet 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
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
Chiba, et al. Informational [Page 13]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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 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
Chiba, et al. Informational [Page 14]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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
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.3. 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
Chiba, et al. Informational [Page 15]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
can be achieved by a variety of means, including secure NTP, as
described in [NTPAUTH]. A default time window of 300 seconds is
recommended.
5.4. Impersonation
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
NAS-IPv6-Address attributes may not correspond to the source address.
Since the NAS-Identifier attribute need not contain an FQDN, it also may
not correspond to the source address, even indirectly. [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.
This implies that it is 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. This could result in
Disconnect or CoF messages being sent to the wrong NAS. Since the rogue
NAS is authenticated by the RADIUS proxy or server purely based on the
source address, other mechanisms are required to detect the forgery. In
addition, it is possible for attributes such as the Called-Station-Id
and Calling-Station-Id to be forged as well.
To address these vulnerabilities RADIUS proxies SHOULD check whether the
NAS-IP-Address or NAS-IPv6-Address attributes match the source address
of packets originating from the NAS. If the NAS-Identifier attribute is
used instead, such a check may not be possible since the NAS-Identifier
may not correspond to an FQDN, and therefore 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 server, checking the NAS-IP-Address
or NAS-IPv6-Address attributes may not be feasible.
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
Chiba, et al. Informational [Page 16]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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.
[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.
[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.
Chiba, et al. Informational [Page 17]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
[RADIANA] Aboba, B., "IANA Considerations for RADIUS", Internet
draft (work in progress), draft-aboba-radius-iana-02.txt,
March 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.
[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> and
Anurag Batta <Anurag_Batta@3com.com>.
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.
Chiba, et al. Informational [Page 18]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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
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
Chiba, et al. Informational [Page 19]
INTERNET-DRAFT Dynamic Authorization Extensions 22 March 2003
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."
Expiration Date
This memo is filed as <draft-chiba-radius-dynamic-authorization-08.txt>,
and expires August 19, 2003.
Chiba, et al. Informational [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 03:09:30 |