draft-ietf-radext-rfc3576bis-11.txt   draft-ietf-radext-rfc3576bis-12.txt 
Network Working Group Murtaza S. Chiba Network Working Group Murtaza S. Chiba
INTERNET-DRAFT Gopal Dommety INTERNET-DRAFT Gopal Dommety
Obsoletes: 3576 Mark Eklund Obsoletes: 3576 Mark Eklund
Category: Informational Cisco Systems, Inc. Category: Informational Cisco Systems, Inc.
Expires: April 25, 2008 David Mitton Expires: April 25, 2008 David Mitton
RSA Security, Inc. RSA Security, Inc.
Bernard Aboba Bernard Aboba
Microsoft Corporation Microsoft Corporation
17 October 2007 18 October 2007
Dynamic Authorization Extensions to Remote Authentication Dial In User Dynamic Authorization Extensions to Remote Authentication Dial In User
Service (RADIUS) Service (RADIUS)
draft-ietf-radext-rfc3576bis-11.txt draft-ietf-radext-rfc3576bis-12.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1 Proxy State ..................................... 13 3.1 Proxy State ..................................... 13
3.2 Authorize Only .................................. 13 3.2 Authorize Only .................................. 13
3.3 State ........................................... 14 3.3 State ........................................... 14
3.4 Message-Authenticator ........................... 15 3.4 Message-Authenticator ........................... 15
3.5 Error-Cause ..................................... 16 3.5 Error-Cause ..................................... 16
3.6 Table of Attributes ............................. 19 3.6 Table of Attributes ............................. 19
4. Diameter Considerations ............................... 22 4. Diameter Considerations ............................... 22
5. IANA Considerations ................................... 25 5. IANA Considerations ................................... 25
6. Security Considerations ............................... 25 6. Security Considerations ............................... 25
6.1 Authorization Issues ............................ 25 6.1 Authorization Issues ............................ 25
6.2 Impersonation ................................... 26 6.2 IPsec Usage Guidelines .......................... 26
6.3 IPsec Usage Guidelines .......................... 27 6.3 Replay Protection ............................... 27
6.4 Replay Protection ............................... 30 7. Example Traces ........................................ 27
7. Example Traces ........................................ 30 8. References ............................................ 28
8. References ............................................ 31 8.1 Normative References ............................ 28
8.1 Normative References ............................ 31 8.2 Informative References .......................... 29
8.2 Informative References .......................... 32 ACKNOWLEDGMENTS .............................................. 29
ACKNOWLEDGMENTS .............................................. 33 AUTHORS' ADDRESSES ........................................... 30
AUTHORS' ADDRESSES ........................................... 34 Appendix A - Changes from RFC 3576 ........................... 31
Appendix A - Changes from RFC 3576 ........................... 35 Full Copyright Statement ..................................... 33
Full Copyright Statement ..................................... 37 Intellectual Property ........................................ 33
Intellectual Property ........................................ 37
1. Introduction 1. Introduction
The RADIUS protocol, defined in [RFC2865], does not support The RADIUS protocol, defined in [RFC2865], does not support
unsolicited messages sent from the RADIUS server to the Network unsolicited messages sent from the RADIUS server to the Network
Access Server (NAS). Access Server (NAS).
However, there are many instances in which it is desirable for However, there are many instances in which it is desirable for
changes to be made to session characteristics, without requiring the changes to be made to session characteristics, without requiring the
NAS to initiate the exchange. For example, it may be desirable for NAS to initiate the exchange. For example, it may be desirable for
skipping to change at page 3, line 47 skipping to change at page 3, line 47
Existing implementations of this protocol do not support Existing implementations of this protocol do not support
authorization checks, so that an ISP sharing a NAS with another ISP authorization checks, so that an ISP sharing a NAS with another ISP
could disconnect or change authorizations for another ISP's users. could disconnect or change authorizations for another ISP's users.
In order to remedy this problem, a "Reverse Path Forwarding" check is In order to remedy this problem, a "Reverse Path Forwarding" check is
described; see Section 6.1. for details. described; see Section 6.1. for details.
Existing implementations utilize per-packet authentication and Existing implementations utilize per-packet authentication and
integrity protection algorithms with known weaknesses [MD5Attack]. integrity protection algorithms with known weaknesses [MD5Attack].
To provide stronger per-packet authentication and integrity To provide stronger per-packet authentication and integrity
protection, the use of IPsec is recommended. See Section 6.3 for protection, the use of IPsec is recommended. See Section 6.2 for
details. details.
Existing implementations lack replay protection. In order to support Existing implementations lack replay protection. In order to support
replay detection, it is recommended that an Event-Timestamp Attribute replay detection, it is recommended that an Event-Timestamp Attribute
be added to all packets in situations where IPsec replay protection be added to all packets in situations where IPsec replay protection
is not employed. See Section 6.4 for details. is not employed. See Section 6.3 for details.
The approach taken with CoA commands in existing implementations The approach taken with CoA commands in existing implementations
results in a semantic ambiguity. Existing implementations of the results in a semantic ambiguity. Existing implementations of the
CoA-Request identify the affected session, as well as supply the CoA-Request identify the affected session, as well as supply the
authorization changes. Since RADIUS Attributes included within authorization changes. Since RADIUS Attributes included within
existing implementations of the CoA-Request can be used for session existing implementations of the CoA-Request can be used for session
identification or authorization change, it may not be clear which identification or authorization change, it may not be clear which
function a given attribute is serving. function a given attribute is serving.
The problem does not exist within the Diameter protocol [RFC3588], in The problem does not exist within the Diameter protocol [RFC3588], in
skipping to change at page 12, line 13 skipping to change at page 12, line 13
Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
present in a CoA-Request or Disconnect-Request, it is possible that present in a CoA-Request or Disconnect-Request, it is possible that
the the User-Name or Chargeable-User-Identity attributes will not be the the User-Name or Chargeable-User-Identity attributes will not be
sufficient to uniquely identify a single session (e.g. if the same sufficient to uniquely identify a single session (e.g. if the same
user has multiple sessions on the NAS, or if the privacy NAI is user has multiple sessions on the NAS, or if the privacy NAI is
used). In this case if it is desired to identify a single session, used). In this case if it is desired to identify a single session,
session identification MAY be performed by using one or more of the session identification MAY be performed by using one or more of the
Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes. Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes.
To address security concerns described in Section 6.2, one or more of To assist RADIUS proxies in routing Request packets to their
the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present destination, one or more of the NAS-IP-Address or NAS-IPv6-Address
in CoA-Request and Disconnect-Request packets; the NAS-Identifier Attributes SHOULD be present in CoA-Request and Disconnect-Request
Attribute MAY be present. packets; the NAS-Identifier Attribute MAY be present. Impersonation
issues with NAS Identification attributes are discussed in [RFC3579]
Section 4.3.7.
A Disconnect-Request MUST contain only NAS and session identification A Disconnect-Request MUST contain only NAS and session identification
attributes. If other attributes are included in a Disconnect- attributes. If other attributes are included in a Disconnect-
Request, implementations MUST send a Disconnect-NAK; an Error-Cause Request, implementations MUST send a Disconnect-NAK; an Error-Cause
Attribute with value "Unsupported Attribute" MAY be included. Attribute with value "Unsupported Attribute" MAY be included.
The DAC may require access to data from RADIUS authentication or The DAC may require access to data from RADIUS authentication or
accounting packets. It uses this data to compose compliant CoA- accounting packets. It uses this data to compose compliant CoA-
Request or Disconnect-Request packets. For example, as described in Request or Disconnect-Request packets. For example, as described in
Section 3.3, a CoA-Request packet containing a Service-Type Attribute Section 3.3, a CoA-Request packet containing a Service-Type Attribute
skipping to change at page 26, line 23 skipping to change at page 26, line 23
NAS if it maintains its own a realm routing table. If the NAS does NAS if it maintains its own a realm routing table. If the NAS does
not maintain a realm routing table (e.g. it selects forwarding not maintain a realm routing table (e.g. it selects forwarding
proxies based on primary/secondary configuration and/or liveness proxies based on primary/secondary configuration and/or liveness
checks), then an RPF check cannot be performed. checks), then an RPF check cannot be performed.
Since authorization to send a Disconnect-Request or CoA-Request is Since authorization to send a Disconnect-Request or CoA-Request is
determined based on the source address and the corresponding shared determined based on the source address and the corresponding shared
secret, the Dynamic Authorization Server SHOULD configure a different secret, the Dynamic Authorization Server SHOULD configure a different
shared secret for each Dynamic Authorization Client. shared secret for each Dynamic Authorization Client.
6.2. Impersonation 6.2. IPsec Usage Guidelines
[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 Access-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 attributes such as the Called-
Station-Id, Calling-Station-Id, or Originating-Line-Info [RFC4005].
This could fool the Dynamic Authorization Client into sending CoA-
Request or Disconnect-Request packets containing forged session
identification attributes to a NAS targeted by an attacker.
To address these vulnerabilities RADIUS proxies one hop from the NAS
SHOULD check whether NAS identification attributes (see Section 3)
match the packet source address. Where one or more attributes do not
match, Access-Request packets 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.
6.3. IPsec Usage Guidelines
In addition to security vulnerabilities unique to Disconnect or CoA In addition to security vulnerabilities unique to Disconnect or CoA
packets, the protocol exchanges described in this document are packets, the protocol exchanges described in this document are
susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is
RECOMMENDED that IPsec be employed to afford better security. RECOMMENDED that IPsec be employed to afford better security,
utilizing the profile described in [RFC3579] Section 4.2.
Implementations of this specification SHOULD support IPsec [RFC4301]
along with IKEv1 [RFC2409] for key management. IPsec ESP [RFC4303]
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 Dynamic Authorization Server and the
Dynamic Authorization Client may not be configured. In this case, a
shared secret of zero length MUST be assumed. However, a Dynamic
Authorization Client 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, per-packet authentication,
integrity and replay protection MUST be used. 3DES-CBC MUST be
supported as an encryption transform and AES-CBC SHOULD be supported.
AES-CBC SHOULD be offered as a preferred encryption transform if
supported. HMAC-SHA1-96 MUST be supported as an authentication
transform. DES-CBC SHOULD NOT be used as the encryption transform.
A typical IPsec policy for an IPsec-capable RADIUS client is
"Initiate IPsec, from me to any destination port UDP 1812". This
IPsec policy causes an IPsec SA to be set up by the RADIUS client
prior to sending a RADIUS Access-Request to a RADIUS server. If some
RADIUS servers contacted by the RADIUS 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 Dynamic Authorization Server implementing this specification
the policy would be "Accept IPsec, from any to me, destination port
UDP 3799". This causes the Dynamic Authorization Server to accept
(but not require) use of IPsec. It may not be appropriate to require
IPsec for all Dynamic Authorization Clients connecting to an IPsec-
enabled Dynamic Authorization Server, since some Dynamic
Authorization Clients may not support IPsec.
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept For Dynamic Authorization Servers implementing this specification the
IPsec, from any to me, destination port 1812". This causes the IPsec policy would be "Require IPsec, from any to me, destination
RADIUS server to accept (but not require) use of IPsec. It may not port UDP 3799". This causes the Dynamic Authorization Server to
be appropriate to require IPsec for all RADIUS clients connecting to require use of IPsec. If some Dynamic Authorization Clients do not
an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec, then a more granular policy will be required: "Require
support IPsec. IPsec, from IPsec-Capable-DAC to me."
For Dynamic Authorization Clients implementing this specification, For Dynamic Authorization Clients implementing this specification,
the policy would be "Initiate IPsec, from me to any, destination port the IPsec policy would be "Initiate IPsec, from me to any,
UDP 3799". This causes the Dynamic Authorization Client to initiate destination port UDP 3799". This causes the Dynamic Authorization
IPsec when sending Dynamic Authorization traffic to any Dynamic Client to initiate IPsec when sending Dynamic Authorization traffic
Authorization Server. If some Dynamic Authorization Servers to any Dynamic Authorization Server. If some Dynamic Authorization
contacted by the Dynamic Authorization Client do not support IPsec, Servers contacted by the Dynamic Authorization Client do not support
then a more granular policy will be required, such as "Initiate IPsec, then a more granular policy will be required, such as
IPsec, from me to IPsec-capable-Dynamic-Authorization-Server, "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP
destination port UDP 3799". 3799".
Where IPsec is used for security, and no RADIUS shared secret is Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that the Dynamic Authorization Server and configured, it is important that the DAC and DAS perform an
Dynamic Authorization Client perform an authorization check. Before authorization check. Before enabling a host to act as a DAS, the DAC
enabling a host to act as a Dynamic Authorization Server, the Dynamic SHOULD check whether the host is authorized to act in that role.
Authorization Client SHOULD check whether the host is authorized to
act in that role. Similarly, before enabling a host to act as a
Dynamic Authorization Client, the Dynamic Authorization Server SHOULD
check whether the host is authorized for that role.
Dynamic Authorization Clients can be configured with the IP addresses
(for IKEv1 Aggressive Mode with pre-shared keys) or FQDNs (for
certificate authentication) of Dynamic Authorization Servers.
Alternatively, if a separate Certification Authority (CA) exists for
Dynamic Authorization Servers, then the Dynamic Authorization Client
can configure this CA as a trust anchor [RFC3280] for use with IKEv1.
Similarly, Dynamic Authorization Servers can be configured with the
IP addresses (for IKEv1 Aggressive Mode with pre-shared keys) or
FQDNs (for certificate authentication) of Dynamic Authorization
Clients. Alternatively, if a separate CA exists for Dynamic
Authorization Clients, then the Dynamic Authorization Server can
configure this CA as a trust anchor for use with IKEv1.
Since unlike SSL/TLS, IKEv1 does not permit certificate policies to
be set on a per-port basis, certificate policies need to apply to all
uses of IKEv1 on Dynamic Authorization Servers and Dynamic
Authorization Clients. In a deployment supporting only certificate
authentication, a management station initiating an IPsec-protected
telnet session to the Dynamic Authorization Client would need to
obtain a certificate chaining to the Dynamic Authorization Server CA.
Issuing such a certificate might not be appropriate if the management
station was not authorized as a Dynamic Authorization Server.
Where Dynamic Authorization Servers obtain their IP address
dynamically (such as an Access Point supporting DHCP), IKEv1 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 Dynamic Authorization Server addresses are
statically assigned either IKEv1 Aggressive Mode or Main Mode MAY be
used. With certificate authentication, IKEv1 Main Mode SHOULD be
used.
Care needs to be taken with IKEv1 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 Dynamic Authorization Client and Dynamic Authorization Server to
configure themselves based on the fully qualified domain name of
their peers.
Note that with IPsec, security services are negotiated at the Similarly, before enabling a host to act as a DAC, the DAS SHOULD
granularity of an IPsec SA, so that exchanges requiring a set of check whether the host is authorized for that role, utilizing the
security services different from those negotiated with existing IPsec mechanisms described in [RFC3579] Section 4.2.
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].
6.4. Replay Protection 6.3. Replay Protection
Where IPsec replay protection is not used, an Event-Timestamp (55) Where IPsec replay protection is not used, an Event-Timestamp (55)
[RFC2869] Attribute SHOULD be included within CoA-Request and [RFC2869] Attribute SHOULD be included within CoA-Request and
Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- Disconnect-Request packets, and MAY be included within CoA-ACK, CoA-
NAK, Disconnect-ACK and Disconnect-NAK packets. NAK, Disconnect-ACK and Disconnect-NAK packets.
When the Event-Timestamp attribute is present, both the Dynamic When the Event-Timestamp attribute is present, both the Dynamic
Authorization Server and the Dynamic Authorization Client MUST check Authorization Server and the Dynamic Authorization Client MUST check
that the Event-Timestamp Attribute is current within an acceptable that the Event-Timestamp Attribute is current within an acceptable
time window. If the Event-Timestamp Attribute is not current, then time window. If the Event-Timestamp Attribute is not current, then
skipping to change at page 31, line 26 skipping to change at page 28, line 26
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000. RFC 2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
3162, August 2001. 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.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July
2003. 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
8.2. Informative References 8.2. Informative References
[MD5Attack] [MD5Attack]
Dobbertin, H., "The Status of MD5 After a Recent Attack", Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes Vol.2 No.2, Summer 1996. CryptoBytes Vol.2 No.2, Summer 1996.
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol and I. Goyret, "RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting Transport Profile", RFC 3539, June 2003. Accounting Transport Profile", RFC 3539, June 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication "Dynamic Authorization Extensions to Remote Authentication
Dial In User Service (RADIUS)", RFC 3576, July 2003. Dial In User Service (RADIUS)", RFC 3576, July 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006. IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for
Virtual LAN and Priority Support", RFC 4675, September 2006. Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
skipping to change at page 36, line 22 skipping to change at page 32, line 22
o Use of Vendor-Specific Attributes (VSAs) for session identification o Use of Vendor-Specific Attributes (VSAs) for session identification
and authorization change has been clarified (Section 3.6). and authorization change has been clarified (Section 3.6).
o Added Note 6 on the use of the CoA-Request for renumbering, and o Added Note 6 on the use of the CoA-Request for renumbering, and
Note 7 on the use of Vendor-Specific attributes (Section 3.6). Note 7 on the use of Vendor-Specific attributes (Section 3.6).
o Added Diameter Considerations (Section 4). o Added Diameter Considerations (Section 4).
o Event-Timestamp Attribute should not be recalculated on o Event-Timestamp Attribute should not be recalculated on
retransmission. The implications for replay and duplicate detection retransmission. The implications for replay and duplicate detection
are discussed (Section 6.4). are discussed (Section 6.3).
o Operation of the Reverse Path Forwarding (RPF) check has been o Operation of the Reverse Path Forwarding (RPF) check has been
clarified. Use of the RPF check is optional rather than recommended clarified. Use of the RPF check is optional rather than recommended
by default (Section 6.1). by default (Section 6.1).
o Text on impersonation (included in [RFC3579] Section 4.3.7) and
IPsec operation (included in [RFC3579] Section 4.2) has been removed,
and is now referenced.
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 End of changes. 20 change blocks. 
207 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/