[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

Network Working Group                                            G. Zorn
Internet-Draft                                            Aruba Networks
Updates: 2865 5176                                               A. Lior
(if approved)                                        Bridgewater Systems
Intended status: Informational                         February 21, 2008
Expires: August 24, 2008


                    User Session Tracking in RADIUS
                    draft-zorn-radius-logoff-11.txt

Status of this Memo

   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.

   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.

   This Internet-Draft will expire on August 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines a set of new messages and attributes designed
   to allow RADIUS servers to cleanly track user sessions.







Zorn & Lior              Expires August 24, 2008                [Page 1]


Internet-Draft       User Session Tracking in RADIUS       February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  3
   3.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Packet Types . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  User-Session-Notification  . . . . . . . . . . . . . . . .  6
     4.2.  User-Session-Acknowledgement . . . . . . . . . . . . . . .  8
   5.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Session-Id . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  Session-Notification-Type  . . . . . . . . . . . . . . . . 10
     5.3.  Table of Attributes  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 14
































Zorn & Lior              Expires August 24, 2008                [Page 2]


Internet-Draft       User Session Tracking in RADIUS       February 2008


1.  Introduction

   RFC 2865 defines a "session" as a service provided to a user 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.  Many remote access deployments require the
   tracking/counting of user sessions, for example to limit the number
   of simultaneous logins.  Note that this is explicitly an
   authorization issue.  Currently, however, the only way to track the
   number or even the existence of user sessions is via RADIUS
   Accounting [RFC2866]; the RADIUS server has no way of knowing if user
   sessions (as defined above) have actually begun or ended.  This fact
   causes an unnecessarily tight binding between RADIUS [RFC2865] and
   RADIUS Accounting, forcing implementers to combine both protocols in
   a single server, devise a method to quickly search accounting logs,
   etc. and implement RADIUS Accounting even if they would not otherwise
   do so.

   This document defines a pair of message exchanges and associated
   Attributes that can be used to notify a RADIUS server that a user
   session has begun or ended.

   Discussion of this draft may be directed to the authors.


2.  Specification of Requirements

   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].


3.  Packet Format

   Exactly one RADIUS packet is encapsulated in the UDP Data field
   [RFC0768] where the UDP Destination Port field indicates 1812
   (decimal).

   When a reply is generated, the source and destination ports are
   reversed.

   A summary of the RADIUS data format is shown below.  The fields are
   transmitted from left to right.








Zorn & Lior              Expires August 24, 2008                [Page 3]


Internet-Draft       User Session Tracking in RADIUS       February 2008


       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.

      The RADIUS Codes (decimal) defined in this document are as
      follows:

         <MSG1> User-Session-Notification

         <MSG2> User-Session-Acknowledgement

   Identifier

      The Identifier field is one octet, and aids in matching requests
      and replies.  The RADIUS server can detect a duplicate request if
      it has the same client source IP address, source UDP port and
      Identifier within a short span of time.

   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 reply from the RADIUS server.



Zorn & Lior              Expires August 24, 2008                [Page 4]


Internet-Draft       User Session Tracking in RADIUS       February 2008


      Notification Authenticator

         In User-Session-Notification packets, the Authenticator value
         is a 16 octet random number, called the Notification
         Authenticator.  The value SHOULD be unpredictable and unique
         over the lifetime of a secret (the password shared between the
         client and the RADIUS server), since repetition of an
         authenticator value in conjunction with the same secret would
         permit an attacker to reply with a previously intercepted
         response.  Since it is expected that the same secret MAY be
         used to authenticate with servers in disparate geographic
         regions, the Notification Authenticator field SHOULD exhibit
         global and temporal uniqueness.

         The Authenticator value in an User-Session-Notification packet
         SHOULD also be unpredictable, lest an attacker trick a server
         into responding to a predicted future request, and then use the
         response to masquerade as that server to a future notification
         packet.

         Although protocols such as RADIUS are incapable of protecting
         against theft of an authenticated session via realtime active
         wiretapping attacks, generation of unique unpredictable
         requests can protect against a wide range of active attacks
         against authentication.

      Acknowledgement Authenticator

         The value of the Authenticator field in the User-Session-
         Acknowledgement packet is called the Acknowledgement
         Authenticator, and contains a one-way MD5 hash calculated over
         a stream of octets consisting of: the RADIUS packet, beginning
         with the Code field, including the Identifier, the Length, the
         Notification Authenticator field from the User-Session-
         Notification packet, and the response Attributes, followed by
         the shared secret.  That is,

         Acknowledgement Auth =
               MD5(Code+ID+Length+NotificationAuth+Attributes+Secret)
         where '+' denotes concatenation.

   Administrative Note

      The secret shared between the client and the RADIUS server SHOULD
      be at least as large and unguessable as a well- chosen password.
      It is preferred that the secret be at least 16 octets.  This is to
      ensure a sufficiently large range for the secret to provide
      protection against exhaustive search attacks.  The secret MUST NOT



Zorn & Lior              Expires August 24, 2008                [Page 5]


Internet-Draft       User Session Tracking in RADIUS       February 2008


      be empty (length 0) since this would allow packets to be trivially
      forged.

      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 using a forwarding proxy, the proxy must be able to alter the
      packet as it passes through in each direction - when the proxy
      forwards the request, the proxy MAY add a Proxy-State Attribute,
      and when the proxy forwards a response, it MUST remove its Proxy-
      State Attribute if it added one.  Proxy-State is always added or
      removed after any other Proxy-States, but no other assumptions
      regarding its location within the list of attributes can be made.
      Since Access-Accept and Access-Reject replies are authenticated on
      the entire packet contents, the stripping of the Proxy-State
      attribute invalidates the signature in the packet - so the proxy
      has to re-sign it.

      Further details of RADIUS proxy implementation are outside the
      scope of this document.


4.  Packet Types

   The RADIUS Packet type is determined by the Code field in the first
   octet of the Packet.

4.1.  User-Session-Notification

   Description

      User-Session-Notification packets are sent to a RADIUS server as
      an indication that a previously authorized session has ended.  A
      RADIUS client wishing to indicate the end of a user session MUST
      transmit a RADIUS packet with the Code field set to <MSG1> (User-
      Session-Notification).

      Upon receipt of an User-Session-Notification packet from a valid
      client, the server MUST reply using either a User-Session-
      Acknowledgement message or an Error-Notification message [ERRMSG].

      A User-Session-Notification message MUST contain either a NAS-IP-
      Address Attribute [RFC2865] or a NAS-Identifier Attribute
      [RFC2865] or both.

      A User-Session-Notification message MUST contain a Session-Id
      Attribute (see below) if one was returned from the server in the



Zorn & Lior              Expires August 24, 2008                [Page 6]


Internet-Draft       User Session Tracking in RADIUS       February 2008


      Access-Accept message for the session; if no Session-Id Attribute
      is included, the packet MUST contain a User-Name Attribute and
      such additional Attributes as are necessary to positively identify
      a given user session (e.g., Service-Type [RFC2865], Calling-
      Station-Id [RFC2865], etc.).

      A User-Session-Notification message MUST include the Session-
      Notification-Type Attribute with the Value field set appropriately
      (see below).

      To help avoid spoofing attacks, a User-Session-Notification
      message SHOULD contain a Message-Authenticator Attribute
      [RFC2869].

      A summary of the User-Session-Notification packet 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   Notification Authenticator                  |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      <MSG1> for User-Session-Notification

   Identifier

      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, the
      Identifier MUST remain unchanged.

   Notification Authenticator

      The Notification Authenticator value MUST be changed each time a
      new Identifier is used.





Zorn & Lior              Expires August 24, 2008                [Page 7]


Internet-Draft       User Session Tracking in RADIUS       February 2008


   Attributes

      The Attribute field is variable in length, and contains the list
      of required Attributes, as well as any desired optional
      Attributes.

4.2.  User-Session-Acknowledgement

   Description

      User-Session-Acknowledgement packets are sent by a RADIUS server
      as an acknowldgement that a previously authorized session has
      ended.  A RADIUS server wishing to acknowledge the end of a user
      session MUST transmit a RADIUS packet with the Code field set to
      <MSG2> (User-Session-Acknowledgement).

      No Attributes are required in a User-Session-Acknowledgement
      packet.

      A summary of the User-Session-Acknowledgement packet 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |  Identifier   |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                  Acknowledgement Authenticator                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Attributes ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      <MSG2> for User-Session-Acknowledgement

   Identifier

      The Identifier field is a copy of the Identifier field of the
      User-Session-Notification packet which caused this User-Session-
      Acknowledgement packet to be created. .






Zorn & Lior              Expires August 24, 2008                [Page 8]


Internet-Draft       User Session Tracking in RADIUS       February 2008


   Acknowledgement Authenticator

      The Acknowledgement Authenticator value is calculated from the
      User-Session-Notification packet, as described above.

   Attributes

      The Attribute field is variable in length, and contains any
      desired optional Attributes.


5.  Attributes

5.1.  Session-Id

   Description

      This attribute contains a unique identifier assigned by the RADIUS
      server to uniquely identify and track user sessions.  In order to
      enable session tracking, this Attribute SHOULD be included in both
      the Access-Accept packet [RFC2865] the associated User-Session-
      Notification packet.  The value of the Attribute in both messages
      MUST be the same.

      The client MAY include this Attribute in the Access-Request packet
      as a hint to the server regarding the value to be used in
      subsequent messages; however, the server is not required to honor
      the hint.

      Because the Session-Id Attribute completely identifies the session
      in question, it MAY also be used as a replacement for the session
      identication attributes discussed in [RFC5176].

      The Identifier field of the Session-Id Attribute SHOULD contain
      UTF-8 encoded 10646 characters [RFC3629].

      A summary of the Session-Id attribute format is shown below.  The
      fields are transmitted from left to right.


       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |    Identifier...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Zorn & Lior              Expires August 24, 2008                [Page 9]


Internet-Draft       User Session Tracking in RADIUS       February 2008


   Type

      <ATR1> for Session-Id.

   Length

      >= 3

   Identifier

      The Identifier field SHOULD be a string of UTF-8 encoded 10646
      characters [RFC3629].

5.2.  Session-Notification-Type

   Description

      This attribute contains an integer that identifies the type of
      notification contained in the User-Session-Notification packet.
      This Arribute MUST be present in any User-Session-Notification
      packet.

      A summary of the Session-Notification-Type 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     |       Notification-Type
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Notification-Type (cont'd.) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      <ATR2> for Session-Notification-Type.

   Length

      6

   Notification-Type

      The Notification-Type field in a 32-bit unsigned integer.  The
      following values are defined for this field:





Zorn & Lior              Expires August 24, 2008               [Page 10]


Internet-Draft       User Session Tracking in RADIUS       February 2008


         0 Start

         1 End

5.3.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity; note that since none
   of the Attributes described here may be present in the either the
   Access-Reject or Access-Challenge packets, those columns have been
   omitted from the table.


   Accept Notify-Req Notify-Ack CoA-Req    #    Attribute
   0-1    0-1        0-1        0-1       ATR1  Session-Id
   0      1          0-1        0         ATR2  Notification-Type


   The following table defines the meaning of the above table entries.

   0      This Attribute MUST NOT be present in packet.

   0-1    Zero or one instances of this Attribute MAY be present in
          packet.


6.  IANA Considerations

   This document requires the allocation of four new numbers: two RADIUS
   Packet Type Codes (denoted herein as <MSG1> and <MSG2>) and two
   RADIUS Attribute Types (denoted as <ATR1> and <ATR2>).  The criteria
   to be used by the Internet Assigned Numbers Authority (IANA) for
   assignment of these are identical to those given in [RFC3575].


7.  Security Considerations

   If the User-Session-Notification packet is unauthenticated or if the
   shared secret is compromised, an attacker might be able to convince
   the server that user sessions had been initiated (if the
   Notification-Type is "Start") or completed (if the Notification-Type
   is "Stop" when they had not.  If the server was limiting the number
   of simultaneous sessions, this could enable one or more users to
   exceed their session quota and possibly lead to service being denied
   to legitimate users.


8.  References



Zorn & Lior              Expires August 24, 2008               [Page 11]


Internet-Draft       User Session Tracking in RADIUS       February 2008


8.1.  Normative References

   [ERRMSG]   Zorn, G., "RADIUS Error Messages",
              draft-zorn-radius-err-msg-09.txt (work in progress),
              February 2008.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, June 2000.

   [RFC3575]  Aboba, B., "IANA Considerations for RADIUS (Remote
              Authentication Dial In User Service)", RFC 3575,
              July 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 5176,
              January 2008.

8.2.  Informative References

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.


Authors' Addresses

   Glen Zorn
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   USA

   Email: gwz@arubanetworks.com






Zorn & Lior              Expires August 24, 2008               [Page 12]


Internet-Draft       User Session Tracking in RADIUS       February 2008


   Avi Lior
   Bridgewater Systems
   303 Terry Fox Drive
   Ottawa, ON  K2K 3J1
   Canada

   Phone: +1 (613) 591-6655
   Email: avi@bridgewatersystems.com











































Zorn & Lior              Expires August 24, 2008               [Page 13]


Internet-Draft       User Session Tracking in RADIUS       February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Zorn & Lior              Expires August 24, 2008               [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/