[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                                24 March 1997
Category: Standards Track         <draft-ietf-radius-tunnel-auth-01.txt>



             RADIUS Attributes for Tunnel Protocol Support



1.  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-01.txt>,  and  expires  October 1, 1997.  Please send
comments   to   the   RADIUS   Working   Group   mailing   list   (ietf-
radius@livingston.com) or to the author (glennz@microsoft.com).


2.  Abstract

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



3.  Introduction

Many of the most interesting applications of tunneling protocols such as
PPTP [PPTP] and L2TP [L2TP] involve dial-up network access.  Some,  such
as  the provision of secure access to corporate intranets via the Inter-
net, are characterized by voluntary tunneling: the tunnel is created  at



Zorn                                                            [Page 1]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


the request of the user for a specific purpose.  Other, potentially more
compelling, applications involve compulsory  tunneling:  the  tunnel  is
created  automatically, without any action from the user and more impor-
tantly, 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 tun-
neling, would probably be provided 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 virtually 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 authentication data to be maintained in
a central location, rather than being subject to  manual  configuration.
It  makes sense to use RADIUS to centrally administer compulsory tunnel-
ing, 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 server; this document defines those attributes.


4.  Specification of Requirements

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

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



Zorn                                                            [Page 2]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


             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.


5.  Attributes

Multiple instances of each  of  the  attributes  defined  below  may  be
included  in a single RADIUS packet.  If this is done, the attributes to
be applied to each distinct tunnel SHOULD all contain the same value  in
their respective Tag fields.


5.1.  Tunnel-Type

   Description

      This Attribute indicates the tunneling protocol(s) to be used.  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
      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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      64 for Tunnel-Type

   Length




Zorn                                                            [Page 3]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


      Always 4.

   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.

   Value

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

       1      PPTP
       2      L2F
       3      L2TP
       4      ATMP
       5      VTP
       6      AH
       7      IP-IP


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

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


   Type

      65 for Tunnel-Medium-Type




Zorn                                                            [Page 4]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


   Length

      4

   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.

   Value

      The Value field is one octet.

       1      IP
       2      X.25
       3      ATM
       4      Frame Relay


5.3.  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 purposes.

   A  summary  of  the  Acct-Tunnel-Client-Endpoint  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

      66 for Acct-Tunnel-Client-Endpoint.

   Length

      >= 3



Zorn                                                            [Page 5]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


   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.

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


5.4.  Tunnel-Server-Endpoint

   Description

      This Attribute indicates the address of the server end of the tun-
      nel.  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  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  pur-
      poses.

   A  summary  of  the  Tunnel-Server-Endpoint 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

      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.

   String



Zorn                                                            [Page 6]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


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



5.5.  Acct-Tunnel-Connection-ID

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

   A summary of the Acct-Tunnel-Connection-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

      68 for Acct-Tunnel-Connection-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.

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








Zorn                                                            [Page 7]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


5.6.  Tunnel-Password

   Description

      This Attribute may contain a key or  password.   It  may  only  be
      included in an Access-Accept packet.

   A  summary  of  the  Tunnel-Password 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

      69 for Tunnel-Password

   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.

   String

      If this field is present, it MUST be hidden in the same fashion as
      the User-Password Attribute, with the exception that the Response-
      Authenticator MUST be used in place of  the  Request-Authenticator
      (see RFC 2058, Section 5.2).


6.  Security Considerations

The  Tunnel-Password Attribute may contain information which should only
be known to a tunnel endpoint.  The method used to hide the value of the
attribute,  however,  is  such that intervening RADIUS proxies will have
knowledge  of  the  contents.   For  this  reason,  the  Tunnel-Password
Attribute SHOULD NOT be included in Access-Accept packets which may pass
through (relatively) untrusted RADIUS proxies.




Zorn                                                            [Page 8]


INTERNET-DRAFT          RADIUS Tunnel Attributes              March 1997


7.  Acknowledgements

Thanks to Kory Hamzeh of Ascend Communications; Bertrand Buclin of  AT&T
Laboratries Europe; Andy Valencia, Bill Westfield and Kris Michielsen of
cisco Systems; amd Gurdeep Singh Pall and  Bernard  Aboba  of  Microsoft
Corporation for salient input and review.


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


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



















Zorn                                                            [Page 9]