[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 rfc2868                            
Network Working Group                                            G. Zorn
Internet-Draft                                     Microsoft Corporation
Updates: RFC 2058, RFC 2059                                    D. Leifer
Category: Standards Track                          Ascend Communications
<draft-ietf-radius-tunnel-auth-02.txt>                      John Shriver
                                                       Shiva Corporation
                                                               July 1997




             RADIUS Attributes for Tunnel Protocol Support



11..  Status of this Memo

This  document  is an Internet-Draft.  Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and  its
working groups.  Note that other groups may also distribute working doc-
uments 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.''

To  learn  the  current  status  of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in  the  Internet-Drafts  Shadow
Directories  on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

The distribution of this memo is unlimited.  It is filed as <draft-ietf-
radius-tunnel-auth-02.txt>,  and  expires February 1, 1997.  Please send
comments to the RADIUS  Working  Group  mailing  list  (ietf-radius@liv-
ingston.com)  or  to  the  authors  (liefer@del.com,  jas@shiva.com  and
glennz@microsoft.com).


22..  Abstract

This document defines a set of RADIUS attributes designed to support the
provision   of   compulsory   tunneling  in  dial-up  networks.   RADIUS
attributes for both authorization and accounting are specified.







Zorn, Leifer & Shriver                                          [Page 1]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


33..  Motivation

Many applications of tunneling protocols such as PPTP and  L2TP  involve
dial-up network access.  Some, such as the provision of secure access to
corporate intranets via the Internet,  are  characterized  by  voluntary
tunneling:  the  tunnel is created at the request of the user for a spe-
cific purpose.  Other applications  involve  compulsory  tunneling:  the
tunnel  is created without any action from the user and without allowing
the user any choice in the matter.  Examples of applications that  might
be  implemented  using  compulsory tunnels are Internet software upgrade
servers, software registration servers and banking services.  These  are
all services which, without compulsory tunneling, would probably be pro-
vided using dedicated networks or  at  least  dedicated  network  access
servers  (NAS),  since  they are characterized by the need to limit user
access to specific hosts.  Given the existence of widespread support for
compulsory tunneling, however, these types of services could be accessed
via any Internet service provider (ISP).   The  most  popular  means  of
authorizing dial-up network users today is through the RADIUS  protocol.
The use of RADIUS allows the dial-up users' authorization and  authenti-
cation  data to be maintained in a central location, rather than on each
NAS.  It makes sense to use RADIUS to  centrally  administer  compulsory
tunneling,  since  RADIUS  is  widely deployed and was designed to carry
this type of information.  In order to provide this  functionality,  new
RADIUS attributes are needed to carry the tunneling information from the
RADIUS server to the NAS and to transfer accounting data from the NAS to
the  RADIUS  accounting  server; this document defines those attributes.
Specific recommendations for, and examples of, the application of  these
attributes  for  the L2TP and PPTP protocols can be found in draft-ietf-
radius-tunnel-imp-XX.txt.




44..  Specification of Requirements

In this document, several words are used to signify the requirements  of
the specification.  These words are often capitalized.

   MUST      This word, or the adjective "required", means that the
             definition is an absolute requirement of the specification.

   MUST NOT  This phrase means that the definition is an absolute
             prohibition of the specification.

   SHOULD    This word, or the adjective "recommended", means that there
             may exist valid reasons in particular circumstances to
             ignore this item, but the full implications must be
             understood and carefully weighed before choosing a



Zorn, Leifer & Shriver                                          [Page 2]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


             different course.

   SHOULD NOT
             This phrase means that there may exist valid reasons in par-
             ticular circumstances when the particular behavior is
             acceptable or even useful, but the full implications should
             be understood and the case carefully weighed before imple-
             menting any behavior described with this label.

   MAY       This word, or the adjective "optional", means that this
             item is one of an allowed set of alternatives.  An
             implementation which does not include this option MUST be
             prepared to interoperate with another implementation which
             does include the option.


55..  Attributes

Multiple  instances  of  each  of  the  attributes  defined below may be
included in a single RADIUS packet.  In this case, the attributes to  be
applied  to  any given tunnel SHOULD all contain the same value in their
respective Tag fields.


55..11..  Tunnel-Type

   Description

      This Attribute indicates the tunneling protocol(s) to be used.  It
      MAY  be  included in Access-Request, Access-Accept and Accounting-
      Request packets.  If the Tunnel-Type Attribute is  present  in  an
      Access-Request  packet, it SHOULD be taken as a hint to the RADIUS
      server as to the tunnelling protocols supported by  the  NAS;  the
      RADIUS server MAY ignore the hint, however.  A NAS is not required
      to implement any of these tunnel  types;  if  a  NAS  receives  an
      Access-Accept  packet  which  contains only unknown or unsupported
      Tunnel-Types, the NAS MUST behave as though an  Access-Reject  had
      been received instead.

   A  summary  of  the Tunnel-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     |     Tag       |     Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |



Zorn, Leifer & Shriver                                          [Page 3]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      64 for Tunnel-Type

   Length

      Always 6.

   Tag

      The Tag field is one octet in length and is intended to provide  a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the Tag field is unused, it MUST be zero.

   Value

      The Value field is three octets and contains one of the  following
      values, indicating the type of tunnel to be started.

       1      Point-to-Point Tunneling Protocol (PPTP)
       2      Layer Two Forwarding (L2F)
       3      Layer Two Tunneling Protocol (L2TP)
       4      Ascend Tunnel Management Protocol (ATMP)
       5      Virtual Tunneling Protocol (VTP)
       6      IP Authentication Header in the Tunnel-mode (AH)
       7      IP-in-IP Encapsulation (IP-IP)
       8      Minimal IP-in-IP Encapsulation (MIN-IP-IP)
       9      IP Encapsulating Security Payload in the Tunnel-mode (ESP)
       10     Generic Route Encapsulation (GRE)
       11     Bay Dial Virtual Services (DVS)


55..22..  Tunnel-Medium-Type

   Description

      The  Tunnel-Medium-Type Attribute indicates which transport medium
      to use when creating a tunnel for those protocols (such  as  L2TP)
      that  can operate over multiple transports.  It MAY be included in
      both Access-Request and Access-Accept packets; if it is present in
      an  Access-Request  packet,  it  SHOULD  be taken as a hint to the
      RADIUS server as to the tunnel mediums supported by the NAS.   The
      RADIUS server MAY ignore the hint, however.

   A  summary of the Tunnel-Medium-Type Attribute format is given below.
   The fields are transmitted left to right.



Zorn, Leifer & Shriver                                          [Page 4]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


    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     |      Tag      |    Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      65 for Tunnel-Medium-Type

   Length

      6

   Tag

      The Tag field is one octet in length and is intended to provide  a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If  the  Tag  field  is  unused,  it  MUST  be  zero
      (0x0000).

   Value

      The  Value  field is three octets nd contains one of the following
      values:

       1      IP
       2      X.25
       3      ATM
       4      Frame Relay


55..33..  Acct-Tunnel-Client-Endpoint

   Description

      This Attribute contains the address of the NAS end of the  tunnel.
      It  SHOULD be included in Accounting-Request packets which contain
      Acct-Status-Type attributes with values of either Start  or  Stop.
      This  Attribute,  along  with the Tunnel-Server-Endpoint and Acct-
      Tunnel-Connection-ID attributes, may be used to provide a globally
      unique means to identify a tunnel for accounting and auditing pur-
      poses.

   A summary of  the  Acct-Tunnel-Client-Endpoint  Attribute  format  is
   shown below.  The fields are transmitted from left to right.



Zorn, Leifer & Shriver                                          [Page 5]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


    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     |           String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      66 for Acct-Tunnel-Client-Endpoint.

   Length

      >= 2

   String
      The  format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IP (1), then this string  is  either  the
      fully  qualified  domain  name,  or  it  is  a "dotted-decimal" IP
      address.

      If Tunnel-Medium-Type is X.25 (2), ATM (3), or  Frame  Relay  (4),
      this  string is a tag referring to configuration data local to the
      RADIUS client that describes  the  interface  and  medium-specific
      address to use.


55..44..  Tunnel-Server-Endpoint

   Description

      This Attribute indicates the address of the server end of the tun-
      nel.  The Tunnel-Server-Endpoint Attribute MAY be included  (as  a
      hint  to  the RADIUS server) in the Access-Request packet and MUST
      be included in the Access-Accept packet if  the  initiation  of  a
      tunnel  is  desired.   It SHOULD be included in Accounting-Request
      packets which contain Acct-Status-Type attributes with  values  of
      either  Start  or  Stop  and  which pertain to a tunneled session.
      This Attribute,  along  with  the  Acc-Tunnel-Client-Endpoint  and
      Acct-Tunnel-Connection-ID  attributes,  may  be  used to provide a
      globally unique means to identify  a  tunnel  for  accounting  and
      auditing purposes.

   A  summary  of  the  Tunnel-Server-Endpoint Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3



Zorn, Leifer & Shriver                                          [Page 6]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


    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     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      67 for Tunnel-Server-Endpoint.

   Length

      >= 3

   Tag

      The Tag field is one octet in length and is intended to provide  a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If  the  Tag  field  is  unused,  it  MUST  be  zero
      (0x0000).

   String
      The  format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IP (1), then this string  is  either  the
      fully  qualified  domain  name,  or  it  is  a "dotted-decimal" IP
      address.

      If Tunnel-Medium-Type is X.25 (2), ATM (3), or  Frame  Relay  (4),
      this  string is a tag referring to configuration data local to the
      RADIUS client that describes  the  interface  and  medium-specific
      address to use.


55..55..  Acct-Tunnel-Connection

   Description

      This  Attribute indicates the identifier assigned to the call.  It
      SHOULD be included in  Accounting-Request  packets  which  contain
      Acct-Status-Type  attributes  with values of either Start or Stop.
      This attribute, along  with  the  Acct-Tunnel-Client-Endpoint  and
      Tunnel-Server-Endpoint  attributes, may be used to provide a glob-
      ally unique means to identify a call for accounting  and  auditing
      purposes.

   A  summary  of  the  Acct-Tunnel-Connection Attribute format is shown
   below.  The fields are transmitted from left to right.



Zorn, Leifer & Shriver                                          [Page 7]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


    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     |            String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      68 for Acct-Tunnel-Connection

   Length

      >= 2

   String
      The format of the  identifier  represented  by  the  String  field
      depends upon the value of the Tunnel-Type attribute.


55..66..  Tunnel-Private-Group-ID

   Description

      This  Attribute  indicates  the group ID for a particular tunneled
      session.  The Tunnel-Private-Group-ID Attribute MAY be included in
      the  Access-Request  packet if the NAS can pre-determine the group
      resulting from a particular connection and SHOULD be  included  in
      the Access-Reply packet if this tunnel session is to be treated as
      belonging to a particular private group.  Private  groups  may  be
      used  to  associate  a tunneled session with a particular group of
      users.  For example, it may  be  used  to  facilitate  routing  of
      unregistered  IP  addresses  through  a  particular interface.  It
      SHOULD be included in  Accounting-Request  packets  which  contain
      Acct-Status-Type  attributes  with  values of either Start or Stop
      and which pertain to a tunneled session.


   A summary of the Tunnel-Private-Group-ID 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     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type




Zorn, Leifer & Shriver                                          [Page 8]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


      ?? for Tunnel-Private-Group-ID.

   Length

      >= 3

   Tag

      The  Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same  tunnel.   If  the  Tag  field  is  unused,  it  MUST be zero
      (0x0000).

   String
      This field must be present.   The  group  is  represented  by  the
      String field.  There is no restriction on the format of group IDs.


66..  Table of Attributes

The following table provides a guide to which of  the  above  attributes
may be found in which kinds of packets, and in what quantity.

   Request Accept Reject Challenge Acct-Request #  Attribute
   0+      0+     0      0         0-1          64 Tunnel-Type
   0+      0+     0      0         0-1          65 Tunnel-Medium-Type
   0       0      0      0         0-1          66 Acct-Tunnel-Client-Endpoint
   0+      0+     0      0         0-1          67 Tunnel-Server-Endpoint
   0       0      0      0         0-1          68 Acct-Tunnel-Connection
   0+      0+     0      0         0-1          ?? Tunnel-Private-Group-ID

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

   0     This attribute MUST NOT be present in packet.
   0+    Zero or more instances of this attribute MAY be present in packet.
   0-1   Zero or one instance of this attribute MAY be present in packet.


77..  Security Considerations

None (submissions welcome).


88..  Acknowledgements

Thanks  (in  no  particular  order)  to  Kory  Hamzeh (kory@ascend.com),
Bertrand Buclin (Bertrand.Buclin@att.ch), Dave  Mitton  (dmitton@baynet-
works.com),    Andy    Valencia   (vandys@cisco.com),   Bill   Westfield



Zorn, Leifer & Shriver                                          [Page 9]


INTERNET-DRAFT          RADIUS Tunnel Attributes               July 1997


(billw@cisco.com), Kris Michielsen (kmichiel@cisco.com),  Gurdeep  Singh
Pall  (gurdeep@microsoft.com),  Ran  Atkinson (rja@home.net) and Bernard
Aboba (aboba@internaut.com) for salient input and review.


99..  Chair's Address

The RAQDIUS Working Group can be contacted via the current chair:

   Carl Rigney
   Livingston Enterprises
   6920 Koll Center Parkway, Suite 220
   Pleasanton, California  94566

   Phone: +1 510 426 0770
   E-Mail: cdr@livingston.com


1100..  Author's Address

Questions about this memo can also be directed to:

   Glen Zorn
   Microsoft Corporation
   One Microsoft Way
   Redmond, Washington 98052

   Phone:  +1 206 703 1559
   E-Mail: glennz@microsoft.com


   Dory Leifer
   Ascend Communications
   1678 Broadway
   Ann Arbor, MI 48105

   Phone:  +1 313 747 6152
   E-Mail: leifer@ascend.com


  John Shriver
  Shiva Corporation
  28 Crosby Drive
  Bedford, MA  01730

  Phone:  +1 617 270 8329
  E-Mail: jas@shiva.com




Zorn, Leifer & Shriver                                         [Page 10]