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

Versions: 00                                                            
RADIUS Working Group                                       Sumit A. Vakil
INTERNET DRAFT                                             Pat R. Calhoun
Category: Internet Draft                                 3Com Corporation
Title: draft-ietf-radius-ipsec-00.txt
Date: November 1997



                            RADIUS IP Security Extensions


Status of this Memo

   This  document  is  an  Internet-Draft.  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.
   Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
   documents at any time.  It is not appropriate to  use  Internet-Drafts
   as  reference  material  or  to  cite  them  other than as a ``working
   draft'' or ``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,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.

Abstract

   The RADIUS Authentication/Authorization protocol defines  a  mechanism
   which is used by a Network Access Server (NAS) to authenticate dial-up
   users. IP Security defines a mechanism of establishing a  secure  link
   between two entities over a network.

   This document defines a mechanism for RADIUS to inform the NAS of  the
   security policies required for secure communication with a host.

Table of Contents

      1.0 Introduction
      1.1 Conventions
      2.0 Operation
      2.1 Login User
      2.2 Tunneled User
      3.0 Policy Building
      4.0 Security Gateway Support
      5.0 Packet Format
      6.0 Packet Types


Vakil, Calhoun             expires May 1998                      [Page 1]


INTERNET DRAFT                                              November 1997


      7.0 RADIUS Attributes
      7.1 Transform
      7.2 Encryption-Algorithm
      7.3 Authentication-Algorithm
      7.4 Authentication-Method
      7.5 SA-Life-Seconds
      7.6 SA-Life-Kbs
      7.7 DH-Group
      7.8 Key-Length
      7.9 Key-Round
      7.10 Enapsulation-Mode
      7.11 Local-Id
      7.12 Remote-Id
      7.13 SA-Destination
      7.14 Policy
      7.15 Next-Hop
      7.16 SA-Direction
      7.17 Table of Attributes
      8.0 Chair's Address
      9.0 Author's Address
      10.0 References

1.0 Introduction

   RADIUS is widely used as a mechanism to send  to  the  NAS  connection
   information.  This  is  particularly important for "login" or tunneled
   users, where the NAS initiates a connection to  a  specified  host  on
   behalf of the user [1][2]. However the only current security mechanism
   used to secure the connection is to rely  on  the  source  IP  address
   (which is a very weak protection).

   The IP Security (IPSEC) protocol suite is used by entities in order to
   communicate  in  a  secure fashion over an untrusted network. In order
   for the NAS to be able to establish a secure link with  a  destination
   host  or  network it requires a set of security policies which defines
   the target as well as the different transforms which are  to  be  used
   during  the communication. These policies need to be pre-configured on
   the NAS prior to establishing the secure link.

   Since particular users can connect to a  variety  of  hosts  over  the
   internet,  it  becomes  very  difficult  to statically configure these
   policies for every host which  dial-up  users  may  connect  to.  This
   document  defines  new  RADIUS attributes which are used to "download"
   security policies for the host which the user may connect to.


1.1 Conventions

   The following language conventions are used in the items  of  specifi-
   cation in this document:


Vakil, Calhoun             expires May 1998                      [Page 2]


INTERNET DRAFT                                              November 1997


         o  MUST, SHALL, or MANDATORY -- This item is an absolute
            requirement of the specification.

         o  SHOULD or RECOMMEND -- This item should generally be followed
            for all but exceptional circumstances.

         o  MAY or OPTIONAL -- This item is truly optional and may be
            followed or ignored according to the needs of the
            implementor.











































Vakil, Calhoun             expires May 1998                      [Page 3]


INTERNET DRAFT                                              November 1997


2.0  Operation

   In this section we will examine two possible types of  users.  In  the
   first  example  we  will  describe  a  login user, and the second will
   define how a tunneled user would  use  the  extensions  used  in  this
   document.

2.1  Login User

   In this section we will look an at example of a login user. The  user,
   named  joe,  dials  into  a  NAS which authenticates the user with the
   assistance of a local RADIUS Server.  The  user's  RADIUS  profile  is
   shown below:

      joe     Password = password
              Service-Type = Login,
              Login-Service = Telnet,
              Login-IP-Host = 10.1.1.1,
              Login-Port = 23

   As the user's profile depicts, once the user is authenticated the  NAS
   will  create a telnet session to target host 10.1.1.1 on behalf of the
   user. In this case the NAS is used as a terminal server and sends  all
   of  the  user's  asynchronous data to the target encapsulated within a
   telnet session.

                                       +-----+
                                       |     |
                                    +--| RAD |
       +-----+            +-----+   |  |     |
       |     |    PSTN    |     |   |  +-----+
       | Joe |------------| NAS |---|
       |     |            |     |   |
       +-----+            +-----+   |  +-----+
                                    |  |     |
                                    +--|Targ.|
                                       |     |
                                  IP   +-----+

   As stated above IPSEC is a mechanism used by the NAS and the target to
   establish  a  secure telnet connection for the user. Traditionally the
   NAS must have security policies defined locally which state  that  all
   communication  with  the target host for the user must be secured, and
   more importantly how secure the communication must be.


2.2  Tunneled User

   Document [3] defines a protocol which is used by a NAS to "tunnel" all
   PPP  data  from  the user to a destination host. This encapsulation is


Vakil, Calhoun             expires May 1998                      [Page 4]


INTERNET DRAFT                                              November 1997


   done in order to allow a user to connect to a destination network from
   the internet as well as to allow multi-protocol over an IP network.

   Document [2] defines RADIUS attributes which  may  be  sent  from  the
   RADIUS  Server to the NAS which contain tunneling information, such as
   the target tunnel endpoint.

   In this example we will examine a user named bill which dials  into  a
   NAS  which  authenticates  the  user  using a local RADIUS Server. The
   RADIUS Server informs the NAS that tunneling must occur for  the  user
   as shown in the user's profile below.

      bill    Password = password
              Service-Type = Framed,
              Framed-Protocol = PPP,
              Framed-IP-Netmask = 255.255.255.255,
              Framed-MTU = 1500,
              Framed-IP-Address = 2.3.4.5 ,
              Tunnel-Type = L2TP,
              Tunnel-Medium-Type = IP,
              Tunnel-Server-Endpoint = 10.1.1.2,
              Tunnel-Password = password

   As the user's profile states, once the user is authenticated  the  NAS
   will  create  an L2TP tunnel with the target tunnel endpoint 10.1.1.2.
   Once the tunnel is established all PPP traffic  will  be  encapsulated
   and forwarded to the target.

                                       +-----+
                                       |     |
                                    +--| RAD |
       +-----+            +-----+   |  |     |
       |     |    PSTN    |     |   |  +-----+
       | Bill|------------| NAS |---|
       |     |            |     |   |
       +-----+            +-----+   |  +-----+
                                    |  |     |
                                    +--|Targ.|
                                       |     |
                                  IP   +-----+

   As stated above IPSEC is a mechanism used by the NAS and the target to
   establish  a  secure  tunnel  for the user. Traditionally the NAS must
   have  security  policies  defined  locally  which   state   that   all
   communication  with  the target host for the user must be secured, and
   more importantly how secure the communication must be.


3.0 Policy Building



Vakil, Calhoun             expires May 1998                      [Page 5]


INTERNET DRAFT                                              November 1997


   This section will define how Policies are built, and most  importantly
   why this is so complex.

   ISAKMP has the ability for an initiator to offer  multiple  protection
   suites  (a.k.a.  proposals),  with preferences associated to them. The
   idea is that the peer has the  ability  to  choose  from  one  of  the
   proposals  offerred.  In  addition  it  is  possible for a proposal to
   contain more than one transform for a given protocol (analogous  to  a
   sub-proposal defined below) which the peer can use.

   The following is an example of a complex, yet valid ISAKMP proposal:


               +-- Protection Suite 1 --+
               |               +-----+  |
               |           +---|SHA-1|  |
               |   +----+  |   +-----+  |
               | +-| AH |--+ OR         |
               | | +----+  |   +-----+  |
               | |         +---| MD5 |  |
         +-----|-+ AND         +-----+  |
         |     | |                      |
         |     | | +----+   +-----+     |
         |     | +-| ESP|---| DES |     |
         |     |   +----+   +-----+     |
         |     +------------------------+
     +---+ OR
         |
         |     +-- Protection Suite 2 --+
         |     |   +----+   +-----+     |
         +-----|---| ESP|---| 3DES|     |
               |   +----+   +-----+     |
               +------------------------+

   In this scenario a requestor proposes two different protection suites,
   one  which  consists  of  both  AH  and  ESP, however note that the AH
   proposal can use either SHA-1 OR MD5 (note that a preference would  be
   assigned to them). In addition ESP must be used with DES.

   The requestor also proposes  a  second  protection  suite  which  only
   consists of ESP using 3DES.

   This type of complexity was not initially  designed  in  the  existing
   RADIUS   protocol,  since  it  is  not  necessary  to  correlate  many
   attributes to form a single "proposal".  However,  document  [2]  does
   introduce this complexity with the use of the tag field. This document
   will  make  use  of  this  mechanism,  but  also  requires  additional
   information   within   the  RADIUS  attribute  to  include  preference
   information.



Vakil, Calhoun             expires May 1998                      [Page 6]


INTERNET DRAFT                                              November 1997


   The new header format as described in  section  5.0  is  necessary  in
   order  to  be able to "build" policies as defined above. Such a policy
   could be represented as follow:

      Tag = 1
          Protocol = AH / Preference = 1,
                Transform = SHA-1,
                Auth-Algorithm HMAC-SHA-1,
                SA-Life-Seconds = 28800,
                Encapsulation-Mode = Tunnel
          Protocol = AH / Preference = 2,
                Transform MD5,
                Auth-Algorithm HMAC-MD5,
                SA-Life-Kbs = 1024,
                Encapsulation-Mode = Tunnel
          Protocol = ESP / Preference = 1
                Transform DES,
                SA-Life-Seconds = 57600,
                Encapsulation-Mode = Tunnel

      Tag = 2
          Protocol = ESP / Preference = 1
                Transform = 3DES,
                Auth-Algorithm DES-MAC,
                SA-Life-Seconds = 57600,
                SA-Life-Kbs = 2048,
                Encapsulation-Mode = Tunnel

      Tag = 3
          Protocol = ESP / Preference = 1
                Transform = 3DES,
                Auth-Algorithm HMAC-SHA-1,
                SA-Life-Seconds = 57600,
                SA-Life-Kbs = 2048,
                Encapsulation-Mode = Transport

   The above defined policy states that Tag #1 has two AH transforms, the
   preferred  using SHA-1, the alternate using MD5. In addition ESP is to
   be used with DES as the transform. The second proposal is to only  use
   ESP  with  3DES  as  the  transform.  The  third proposal is added for
   completeness and depicts a simple policy using only ESP with  3DES  in
   transport mode.

   Note that since both the Protocol and the Preference fields  are  used
   to "classify" groups of attributes to form a single sub-proposal it is
   not possible to have  more  than  one  protocol  type  with  the  same
   preference number within a given tag.


4.0 Security Gateway Support


Vakil, Calhoun             expires May 1998                      [Page 7]


INTERNET DRAFT                                              November 1997


   The IPSEC Architecture specification[11]  defines  the  concept  of  a
   security  gateway,  which  is an intermediate node which provides some
   security functions. This means that although security from the NAS  to
   the  target host may be required, it also means that security from the
   NAS to the intermediate node is also required.

   This functionality further complicates this document since support for
   such devices must be included.

   Consider the following diagram which depicts such a configuration:

                                       +-----+
                                       |     |
                                    +--| RAD |
       +-----+            +-----+   |  |     |
       |     |    PSTN    |     |   |  +-----+
       | Bill|------------| NAS |---|
       |     |            |     |   |
       +-----+            +-----+   |  +-----+    +-----+
                                    |  |     |    |     |
                                    +--| S G |----|Targ.|
                                       |     |    |     |
                                  IP   +-----+    +-----+

   In this scenario the NAS is informed that it must first  establish  an
   ESP  tunnel to the Security Gateway (SG), and then use AH in transport
   mode to the target host shown above.

   Due to this requirement, it must now be possible to associate the peer
   with a given policy (as shown in section 3.0). Although it is possible
   to create a new header format to support the above case  it  would  be
   preferable to simply use the format defined in section 5.0.

   Using the header format defined in section 5.0 it is now  possible  to
   define a security hierarchy as shown below:

   Tag = 4
         Flag = First Host,
                SA-Destination = SG,
                Direction = Initiator,
                Remote-ID = foo,
                Policy = 1 / Preference = 1,
                Policy = 2 / Preference = 2,
                Next Hop = Target

   Tag = 5
         Flag = NULL
                SA-Destination = Target,
                SA-Direction = Initiator,
                Remote-ID = bar,


Vakil, Calhoun             expires May 1998                      [Page 8]


INTERNET DRAFT                                              November 1997


                Policy = 3 / Preference = 1

   The above example describes that a secure  link  must  be  established
   with  the Security Gateway using either Policy 1 or 2 (with preference
   given to #1). Once this is complete, a secure link must be established
   with  the  target  host using policy 3. Note that the Policy number is
   essentially the tag number  assigned  to  the  policies  described  in
   section 3.0

   Given the mechanism described  above  it  is  now  possible  to  build
   complex  hierarchies  of  security systems which must be penetrated in
   order to reach the target host.  Note  that  the  last  hop  will  not
   necessarily  be  the  target  host  since  a  Security  Gateway may be
   protecting the network instead.

   Since Phase 2 security association are unidirectional, it is neccesary
   to  specify  if  the  given  policy  is  for  the initiator or for the
   responder. In the example given above, the "policies" are what the NAS
   is to offer to the peer. When the SA-Direction is set to responder, it
   informs the NAS what policies it may accept from the peer.


5.0 Packet Format

   Packet Format is identical to that defined in RFC 2058 and 2059.


6.0 Packet Types

   Packet types are identical to those defined in RFC 2058 and 2059.

   See "Table of Attributes" below to determine which  types  of  packets
   can contain which attributes defined here.


7.0 Attributes

   This section will define the RADIUS Attributes which are used to  send
   Security  Policies or security hierarchies to the NAS for a given user
   connection.

   The new attribute format is shown below:

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |    Value...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Vakil, Calhoun             expires May 1998                      [Page 9]


INTERNET DRAFT                                              November 1997


    Type

      The Type field is one octet.  Up-to-date values of the RADIUS  Type
      field are specified in the most recent "Assigned Numbers" RFC [12].
      Values 192-223 are reserved for experimental  use,  values  224-240
      are  reserved  for  implementation-specific use, and values 241-255
      are reserved and should not be used.  This  specification  concerns
      the following values:

          1-39   (refer to [1])
         40-51   (refer to [8] )
         52-59   Unused
         60-63   (refer to [1] )
         64-68   (refer to [2] )
         69-79   (refer to [7] )
         80      Transform
         81      Encryption-Algorithm
         82      Hash-Algorithm
         83      Authentication-Mechanism
         84      SA-Life-Seconds
         85      SA-Life-Kbs
         86      DH-Group
         87      Key-Length
         88      Key-Round
         89      Encapsulation-Mode
         90      Initiator-Id
         91      Responder-Id
         92      SA-Destination
         93      Policy
         94      Next-Hop
         95      SA-Direction

    Length

      The Length field is one octet, and indicates  the  length  of  this
      attribute  including  the  Type,  Length  and  Value fields.  If an
      attribute is received in a  packet  with  an  invalid  Length,  the
      entire request should be silently discarded.

    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 policy or security hierarchy.

    Protocol

      A Protocol identifier. The following values are supported:
            1 - Authentication Header (AH)
            2 - Encapsulation Security Payload Header (ESP)


Vakil, Calhoun             expires May 1998                     [Page 10]


INTERNET DRAFT                                              November 1997


            3 - Internet Securit Association Key Management Protocol
                (ISAKMP)
            4 - IP Compression (IPCOMP)

      If the  protocol  identifier  in  the  attributes  is  ISAKMP,  the
      resulting  policy  is  meant  for  a  Phase  1 exchange.  A Phase 1
      exchange creates  ISAKMP  SAs  which  protect  further  negotiation
      traffic between the ISAKMP peers.

      If the protocol identifier in the  attribute  is  a  protocol  type
      other than ISAKMP, the resulting policy is meant for use in a Phase
      2 exchange.  A Phase 2 exchange happens under the protection  of  a
      pre-existing  Phase  1  SA,  and  negotiates  a SA for the protocol
      specified in the attribute.

    Flag

      The flag field contains information regarding the  content  of  the
      attribute. Note that each individual attribute description indicate
      whether the flag bit may be used.

      The following bits are defined:
             0x1 - (S bit) First Host in a chain

    Preference

      The specific preference for the stated protocol.

    Value

      The Value field is zero or more  octets  and  contains  information
      specific  to  the  attribute.   The  format and length of the Value
      field is determined by the Type and Length fields.

      The format of the value field is one of four data types.

      string    0-249 octets

      address   32 bit value, most significant octet first.

      integer   32 bit value, most significant octet first.

      time      32 bit value, most significant octet first -- seconds
                since 00:00:00 GMT, January 1, 1970.  The standard
                Attributes do not use this data type.


7.1 Transform

   This attributes states the desired transform for the protocol.


Vakil, Calhoun             expires May 1998                     [Page 11]


INTERNET DRAFT                                              November 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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      80 for Transform

    Length

      8

    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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      transform   within   the  proposal.  The  policy  with  the  lowest
      preference value is prefered.

    Value

      The value field contains the transform ID. Note that this field  is
      used  in  conjunction with the protocol ID in order to identify the
      specific transform. The following values are supported:
          0 - NULL (ESP Only)
          1 - DES (ESP and AH)
          2 - 3DES (ESP Only)
          3 - DES_IV64 (ESP Only)
          4 - RC5 (ESP Only)
          5 - IDEA (ESP Only)
          6 - CAST (ESP Only)
          7 - Blowfish (ESP Only)


Vakil, Calhoun             expires May 1998                     [Page 12]


INTERNET DRAFT                                              November 1997


          8 - 3IDEA (ESP Only)
          9 - DES_IV32 (ESP Only)
          10 - ARCFOUR (ESP Only)
          11 - MD5 (AH Only)
          12 - SHA-1 (AH Only)
          13 - Oakley (ISAKMP Only)
          14 - LZS (IPCOMP Only)
          15 - V.42bis (IPCOMP Only)
          16 - DEFLATE (IPCOMP Only)

      It is considered invalid to specify a value which is  not  relevant
      to the stated protocol ID in the attribute header.


7.2 Encryption-Algorithm

   This attribute states the  desired  encryption  algorithm  for  ISAKMP
   phase 1 exchange.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      81 for Encryption-Algorithm

    Length

      8

    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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field MUST be set to ISAKMP.

    Flag

      The Flag field has no meaning with this attribute.

    Preference


Vakil, Calhoun             expires May 1998                     [Page 13]


INTERNET DRAFT                                              November 1997


      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field contains the transform ID. Note that this field  is
      used  in  conjunction with the protocol ID in order to identify the
      specific transform. The following values are supported:
          1 - DES-CBC
          2 - IDEA-CBC
          3 - Blowfish-CBC
          4 - RC5-R16-B64-CBC
          5 - 3DES-CBC
          6 - CAST-CBC


7.3 Hash-Algorithm

   This attribute states the desired hash algorithm for  ISAKMP  phase  1
   exchange.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      82 for Hash-Algorithm

    Length

      8

    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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field MUST be set to ISAKMP.

    Flag

      The Flag field has no meaning with this attribute.


Vakil, Calhoun             expires May 1998                     [Page 14]


INTERNET DRAFT                                              November 1997


    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field contains the transform ID. Note that this field  is
      used  in  conjunction with the protocol ID in order to identify the
      specific transform. The following values are supported:
          1 - MD5
          2 - SHA
          3 - Tiger


7.4 Authentication-Method

   This attributes states the desired authentication  algorithm  for  the
   IPSEC protocols.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      83 for Authentication-Method

    Length

      8

    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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.


Vakil, Calhoun             expires May 1998                     [Page 15]


INTERNET DRAFT                                              November 1997


    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field contains the transform ID. Note that this field  is
      used  in  conjunction with the protocol ID in order to identify the
      specific transform. The following values are supported:
          1 - HMAC-MD5 (ESP and AH)
          2 - HMAC-SHA-1 (ESP and AH)
          3 - DES-MAC (ESP and AH)
          4 - Pre-Shared key (ISAKMP Only)
          5 - DSS-Signature (ISAKMP Only)
          6 - RSA-Signature (ISAKMP Only)
          7 - RSA-Encryption (ISAKMP Only)
          8 - Revised-RSA-Encryption (ISAKMP Only)
          9 - GSSAPI-Authentication (ISAKMP Only)
          10 - KPDK (AH Only - MUST be used with MD5 as transform only)

      It is considered invalid to specify a value which is  not  relevant
      to the stated protocol ID in the attribute header.


7.5 SA-Life-Seconds

   This  attributes  states  the  lifetime  for  the  generated  Security
   Association  for  the IPSEC protocol requested. This attribute defines
   the lifetime in the number of seconds once the SA is established.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      84 for SA-Life-Seconds

    Length

      8

    Tag

      The Tag field is one octet in length and is intended to provide   a


Vakil, Calhoun             expires May 1998                     [Page 16]


INTERNET DRAFT                                              November 1997


      means of grouping attributes in the same packet which refer to  the
      same policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field contains the number of seconds before the  Security
      Association must be renegotiated.


7.6 SA-Life-Kbs

   This  attributes  states  the  lifetime  for  the  generated  Security
   Association  for  the IPSEC protocol requested. This attribute defines
   the lifetime in the number of kilobytes transmitted  once  the  SA  is
   established.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      85 for SA-Life-Kbs

    Length

      8

    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


Vakil, Calhoun             expires May 1998                     [Page 17]


INTERNET DRAFT                                              November 1997


      same policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value  field  contains  the  number  of  kilobytes  before  the
      Security Association must be renegotiated.


7.7 DH-Group

   This attribute is used to indicate the Diffie-Hellman  group  for  the
   phase  2  exchange.   If  perfect  forward  secrecy  is  desired, this
   attribute must be included.  It allows for the negotiation of a  fresh
   DH  key  for  phase  2.   This  new  ephemeral DH key can then be used
   instead of the phase  1  DH  key,  to  derive  session  keys  for  the
   negotiated transforms.

   The attribute's format is as follows:

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      86 for DH-Group

    Length

      8

    Tag


Vakil, Calhoun             expires May 1998                     [Page 18]


INTERNET DRAFT                                              November 1997


      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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to  be used with as defined previously. This attribute is not valid
      for IPCOMP.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field contains the Diffie-Hellman group and may have  one
      of the following values:
          1 - First-Oakley-Group (MODP 768 bit)
          2 - Second-Oakley-Group (MODP 1024 bit)
          3 - Third-Oakley-Group (EC2N on GP[2^155])
          4 - Fourth-Oakley-Group (EC2N on GP[2^185])


7.8 Key-Length

   For transforms that take variable length keys, this attribute  can  be
   used to indicate the key length desired.  Its format is as follows:

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      87 for Key-Length

    Length

      8



Vakil, Calhoun             expires May 1998                     [Page 19]


INTERNET DRAFT                                              November 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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to  be used with as defined previously. This attribute is not valid
      for IPCOMP.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      This field contains a non-zero length for the key.


7.9 Key-Round

   For transforms that have varying number of rounds, this attribute  can
   be  used  to  indicate the desired number of rounds.  Its format is as
   follows:

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      88 for Key-Rounds

    Length

      8

    Tag



Vakil, Calhoun             expires May 1998                     [Page 20]


INTERNET DRAFT                                              November 1997


      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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to  be used with as defined previously. This attribute is not valid
      for IPCOMP.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      This field contains a non-zero key round value.


7.10 Encapsulation-Mode

   This  attribute  indicates  the  encapsulation  mode  for  the   given
   protocol. The attribute's format is as follows:

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      89 for Encapsulation-Mode

    Length

      8

    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 policy. This value is also used as a policy identifier.


Vakil, Calhoun             expires May 1998                     [Page 21]


INTERNET DRAFT                                              November 1997


    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    Value

      The value field may have one of the following values:
          1 - Tunnel-Mode
          2 - Transport-Mode


7.11 Initiator-Id

   This attribute is used to indicate the identity of the ISAKMP exchange
   initiator.

   If the protocol field is ISAKMP, the identity is meant for a  Phase  1
   exchange  (IDii  in  [4]).  If the NAS happens to be the initiator, it
   knows its local identity.  In this case, the attribute SHOULD  not  be
   sent  in  the Access-Accept.  However, if the attribute is sent in the
   Access-Accept, the NAS has an option of ignoring it.  If the attribute
   is not present in the Access-Accept, the NAS MUST assume that it is to
   provide its own identity.

   If the protocol field is anything but ISAKMP, the  attribute  provides
   the  user  identity on the initiator side for a Phase 2 exchange (IDui
   in [4]).

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |    ID Type    |   String...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      90 for Initiator-Id



Vakil, Calhoun             expires May 1998                     [Page 22]


INTERNET DRAFT                                              November 1997


    Length

      >8

    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 policy. This value is also used as a policy identifier.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to  be used with as defined previously. This attribute is not valid
      for ISAKMP.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    ID Type

      The ID Type field is one octet in length and represents the  format
      of the address. The following values are supported:
          1 - IPV4-Address (4 octets)
          2 - IPV6-Address (20 octets)
          3 - FQ-Domain-Name (e.g. 3com.com)
          4 - FQ-User-Name (e.g. lobo@3com.com)
          5 - IPV4-Subnet (4 octets address followed by 4 octets
              subnet mask)
          6 - IPV4-Range (4 octets start address followed by
              by a 4 octet end address)
          7 - X.500-Distinguished-Name
          8 - X.500-General-Name
          9 - Vendor-Specific (pre-shared key identity)

    String

      The string field contains the local identifier.


7.12 Responder-Id

   This attribute is used to indicate the identity of the ISAKMP exchange
   responder.


Vakil, Calhoun             expires May 1998                     [Page 23]


INTERNET DRAFT                                              November 1997


   If the protocol field is ISAKMP, the identity is meant for a  Phase  1
   exchange  (IDir  in  [4]).  If the NAS happens to be the responder, it
   knows its local identity.  In this case, the attribute SHOULD  not  be
   sent  in  the Access-Accept.  However, if the attribute is sent in the
   Access-Accept, the NAS has an option of ignoring it.  If the attribute
   is not present in the Access-Accept, the NAS MUST assume that it is to
   provide its own identity.

   If the protocol field is anything but ISAKMP, the  attribute  provides
   the  user  identity on the responder side for a Phase 2 exchange (IDur
   in [4]).

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |    ID Type    |   String...   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      91 for Remote-Id

    Length

      >8

    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 Security Association Endpoint.

    Protocol

      The Protocol field identifies for which protocol this attribute  is
      to be used with as defined previously.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field  identifies  the  preference  of  the  current
      policy. The policy with the lowest preference value is prefered.

    ID Type



Vakil, Calhoun             expires May 1998                     [Page 24]


INTERNET DRAFT                                              November 1997


      The ID Type field is one octet in length and represents the  format
      of the address. The following values are supported:
          1 - IPV4-Address (4 octets)
          2 - IPV6-Address (20 octets)
          3 - FQ-Domain-Name (e.g. 3com.com)
          4 - FQ-User-Name (e.g. lobo@3com.com)
          5 - IPV4-Subnet (4 octets address followed by 4 octets
              subnet mask)
          6 - IPV4-Range (4 octets start address followed by
              by a 4 octet end address)
          7 - X.500-Distinguished-Name
          8 - X.500-General-Name
          9 - Vendor-Specific (pre-shared key identity)

    Value

      The value field contains the remote identifier.


7.13 SA-Destination

   This  attributes  defines  the  destination  address  with  which  the
   Security Association will be established.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value...          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Value(cont)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      92 for SA-Destination

    Length

      10

    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 Security Association Endpoint.

    Protocol



Vakil, Calhoun             expires May 1998                     [Page 25]


INTERNET DRAFT                                              November 1997


      The Protocol field has no meaning for this attribute.

    Flag

      The Flag field field is used in order to identify the first host in
      a chain of Security Associations. The S bit is enabled if this host
      is the first security hop to the target. Note that this bit MUST be
      enabled even if the first hop is also the last hop.

    Preference

      The Preference field has no meaning for this attribute.

    Value

      The value field contains the  address  of  the  IPSEC  destination,
      which may be the target host or an intervening Security Gateway.


7.14 Policy

   This attribute is used to reference a specific policy  for  the  user.
   When more than a single instance of this attribute is present within a
   given tag, the preference field is  used  in  order  to  identify  the
   prefered policy.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      93 for Policy

    Length

      8

    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 Security Association Endpoint.

    Protocol



Vakil, Calhoun             expires May 1998                     [Page 26]


INTERNET DRAFT                                              November 1997


      The Protocol field has no meaning for this attribute.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference  field  identifies  the  preference  of  the  stated
      policy. The policy with the lowest preference value is prefered.

    Value

      The Value field contains the policy identifier as described  above.
      When  used  with  the  Preference  field  it  is  used  in order to
      associate preferred policies to use for a given SA-Destination.


7.15 Next-Hop

   This attribute is used in order to identify the next hop in a chain of
   security  associations. This attribute is used when it is necessary to
   establish a secure link with a security gateway in order  to  reach  a
   host using IPSEC or in the case of multiple security gateways.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Value(cont)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      94 for Next-Hop

    Length

      10

    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 Security Association Endpoint.

    Protocol


Vakil, Calhoun             expires May 1998                     [Page 27]


INTERNET DRAFT                                              November 1997


      The Protocol field has no meaning for this attribute.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field has no meaning with this attribute.

    Value

      The value field contains the address of the next hop.


7.16 SA-Direction

   A Phase 2 SA is unidirectional.  This means that a  pair  of  SAs  are
   required to secure a session.  If the NAS is initiating the Phase 2 SA
   exchange, it needs a set of protection suites that it can  propose  to
   its peer.

   On the other hand, if the NAS is responding to a Phase 2 SA  exchange,
   it receives a set of protection suites from its peer. In this case, it
   needs a set of local protection suites to compare the proposed  suites
   against.   Hence it becomes necessary to provide the NAS with two sets
   of protection suites; one for use when it is the  initiator,  and  the
   other when it is the responder.

     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      |   Protocol    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flag      |  Preference   |             Value             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type

      95 for SA-Direction

    Length

      8

    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 Security Association Endpoint.


Vakil, Calhoun             expires May 1998                     [Page 28]


INTERNET DRAFT                                              November 1997


    Protocol

      The Protocol field has no meaning for this attribute.

    Flag

      The Flag field has no meaning with this attribute.

    Preference

      The Preference field has no meaning with this attribute.

    Value

      The value field contains the direction of the Security Association.
      The following values are supported:
            1 - Initiator
            2 - Reponder


7.17 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+           80 Transform
    0       0+     0      0         0+           81 Encryption-Algorithm
    0       0+     0      0         0+           82 Hash-Algorithm
    0       0+     0      0         0+           83 Authentication-
                                                    Mechanism
    0       0+     0      0         0+           84 SA-Life-Seconds
    0       0+     0      0         0+           85 SA-Life-Kbs
    0       0+     0      0         0+           86 DH-Group
    0       0+     0      0         0+           87 Key-Length
    0       0+     0      0         0+           88 Key-Round
    0       0+     0      0         0+           89 Encapsulation-Mode
    0       0+     0      0         0+           90 Initiator-Id
    0       0+     0      0         0+           91 Responder-Id
    0       0+     0      0         0+           92 SA-Destination
    0       0+     0      0         0+           93 Policy
    0       0+     0      0         0+           94 Next-Hop
    0       0+     0      0         0+           95 SA-Direction

   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.


Vakil, Calhoun             expires May 1998                     [Page 29]


INTERNET DRAFT                                              November 1997


      0-1   Zero or one instance of this attribute MAY be present in
            packet.


8.0 Chair's Address

   The RADIUS 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.0 Author's Address

   Questions about this memo can also be directed to:

      Sumit A. Vakil
      3Com Corporation
      1800 W. Central Rd.
      Mount Prospect, Il, 60056
      svakil@usr.com
      (847) 342-6892

      Pat R. Calhoun
      3Com Corporation
      1800 W. Central Rd.
      Mount Prospect, Il, 60056
      pcalhoun@usr.com
      (847) 342-6898

10.0 References

   [1] C. Rigney , A. Rubens, W. Simpson, S. Willens, "Remote
       Authentication Dial In User Service (RADIUS)", RFC 2138,
       April 1997.

   [2] C. Zorn, D. Leifer, John Shriver, "RADIUS Attributes for
       Tunnel Protocol Support", Internet Draft, July 1997.

   [3] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud,
       A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter,
       A. Rubens "Layer Two Tunneling Protocol (L2TP)",
       Internet Draft, October 1997

   [4] D. Harkins D., D. Carrel, "The Resolution of ISAKMP with


Vakil, Calhoun             expires May 1998                     [Page 30]


INTERNET DRAFT                                              November 1997


       Oakley", Internet Draft, July 1997

   [5] D. Maughan, M. Schertler, M. Schneider, J. Turner,
       "Internet Security Association and Key Management Protocol
       (ISAKMP)", Internet Draft, July 1997

   [6] D. Piper, "The Internet IP Security Domain Of Interpretation
       for ISAKMP",Internet Draft, October 1997

   [7] C. Rigney, W Willats, "RADIUS Extensions", Internet Draft,
       January 1997

   [8] C. Rigney, "RADIUS Accounting", RFC 2139, April 1997

   [9] S. Kent, R. Atkinson, "IP Encapsulating Security Payload",
       Internet Draft, October 1997

   [10] S. Kent, R. Atkinson, "IP Authentication Header",
        Internet Draft, October 1997

   [11] R. Atkinson, "Security Architecture for the Internet Protocol",
        RFC 1825, August 1995

   [12] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        USC/Information Sciences Institute, October 1994



























Vakil, Calhoun             expires May 1998                     [Page 31]