--- 1/draft-ietf-radext-rfc3576bis-12.txt 2007-10-21 09:12:11.000000000 +0200 +++ 2/draft-ietf-radext-rfc3576bis-13.txt 2007-10-21 09:12:11.000000000 +0200 @@ -1,24 +1,24 @@ Network Working Group Murtaza S. Chiba INTERNET-DRAFT Gopal Dommety Obsoletes: 3576 Mark Eklund Category: Informational Cisco Systems, Inc. -Expires: April 25, 2008 David Mitton +Expires: April 21, 2008 David Mitton RSA Security, Inc. Bernard Aboba Microsoft Corporation - 18 October 2007 + 20 October 2007 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) - draft-ietf-radext-rfc3576bis-12.txt + draft-ietf-radext-rfc3576bis-13.txt By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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. @@ -27,21 +27,21 @@ 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. - This Internet-Draft will expire on April 25, 2008. + This Internet-Draft will expire on April 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). All Rights Reserved. Abstract This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access @@ -63,25 +63,25 @@ 3.2 Authorize Only .................................. 13 3.3 State ........................................... 14 3.4 Message-Authenticator ........................... 15 3.5 Error-Cause ..................................... 16 3.6 Table of Attributes ............................. 19 4. Diameter Considerations ............................... 22 5. IANA Considerations ................................... 25 6. Security Considerations ............................... 25 6.1 Authorization Issues ............................ 25 6.2 IPsec Usage Guidelines .......................... 26 - 6.3 Replay Protection ............................... 27 + 6.3 Replay Protection ............................... 26 7. Example Traces ........................................ 27 8. References ............................................ 28 8.1 Normative References ............................ 28 - 8.2 Informative References .......................... 29 + 8.2 Informative References .......................... 28 ACKNOWLEDGMENTS .............................................. 29 AUTHORS' ADDRESSES ........................................... 30 Appendix A - Changes from RFC 3576 ........................... 31 Full Copyright Statement ..................................... 33 Intellectual Property ........................................ 33 1. Introduction The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network @@ -199,21 +199,21 @@ Client in order to terminate user session(s) on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session(s) to be terminated by inclusion of the identification attributes described in Section 3. +----------+ +----------+ | | Disconnect-Request | | | | <-------------------- | | | NAS | | DAC | - | | Disconnect-Response | | + | | Disconnect-ACK/NAK | | | | ---------------------> | | +----------+ +----------+ The NAS responds to a Disconnect-Request packet sent by a Dynamic Authorization Client with a Disconnect-ACK if all associated session context is discarded and the user session(s) are no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect one or more sessions 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. @@ -234,21 +234,21 @@ identification attributes map to. NAS-Filter-Rule (92) - Provides a filter list to be applied for the session(s) that the identification attributes map to [RFC4849]. +----------+ +----------+ | | CoA-Request | | | | <-------------------- | | | NAS | | DAC | - | | CoA-Response | | + | | CoA-ACK/NAK | | | | ---------------------> | | +----------+ +----------+ The NAS responds to a CoA-Request sent by a Dynamic Authorization Client with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session(s), or a CoA-NAK if the CoA- Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" SHOULD be included. @@ -1220,29 +1220,20 @@ For Dynamic Authorization Clients implementing this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the Dynamic Authorization Client to initiate IPsec when sending Dynamic Authorization traffic to any Dynamic Authorization Server. If some Dynamic Authorization Servers contacted by the Dynamic Authorization Client do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 3799". - Where IPsec is used for security, and no RADIUS shared secret is - configured, it is important that the DAC and DAS perform an - authorization check. Before enabling a host to act as a DAS, the DAC - SHOULD check whether the host is authorized to act in that role. - - Similarly, before enabling a host to act as a DAC, the DAS SHOULD - check whether the host is authorized for that role, utilizing the - mechanisms described in [RFC3579] Section 4.2. - 6.3. Replay Protection Where IPsec replay protection is not used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- NAK, Disconnect-ACK and Disconnect-NAK packets. When the Event-Timestamp attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that the Event-Timestamp Attribute is current within an acceptable