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/ |