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

Versions: 00                                                            
<draft-yamanouchi-radius-ext-00.txt>           N. Yamanouchi, IBM Japan
                                               N. Ishikawa, NTT
                                               O. Takahashi, NTT

                                               March  12,   1998
                                               Expires in six months



           RADIUS Extension for Multicast Router Authentication



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 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 view the entire   list of current Internet-Drafts,  please check
     the  "1id-abstracts.txt" listing  contained in  the Internet-Drafts
     Shadow  Directories    on  ftp.is.co.za  (Africa),    ftp.nordu.net
     (Europe),  munnari.oz.au  (Pacific Rim),  ds.internic.net (US  East
     Coast), or ftp.isi.edu (US West Coast).

Abstract

     This memo describes an  extension of RADIUS authentication protocol
     (RFC2138)   and RADIUS accounting    protocol (RFC2139) to  provide
     authentication service about multicast receivers and senders to the
     ingress and egress routers, and to  keep track of the receiving and
     sending  clients for multicast data   feed service management.  New
     services and  attributes are added  to the RADIUS definitions while
     the   authentication transaction  mechanisms   are preserved.   The
     authentication server  authenticates the multicast  receiver/sender
     by using the  CHAP-based  mechanism.  The account  server  logs the
     start and stop points of multicast route  usage.  This extension is
     intended  to  be used in  conjunction  with the  IGMP extension for
     multicast receiver and sender authentication.









Yamanouchi, Ishikawa, Takahashi                                [Page  1]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


Table of Contents

   1.  Introduction ............................................  2

   2.  Operation ...............................................  3

   3.  Packet Format ...........................................  3

   4.  Packet Types ............................................  5
       4.1   Access-Request ....................................  5
       4.2   Access-Accept......................................  6
       4.3   Access-Reject......................................  7
       4.4   Accounting-Request.................................  8
       4.5   Accounting-Response................................  9

   5.  Attributes .............................................. 10
       5.1   User-Name ......................................... 12
       5.2   CHAP-Password ..................................... 12
       5.3   NAS-IP-Address .................................... 13
       5.4   Service-Type ...................................... 14
       5.5   Reply-Message ..................................... 15
       5.6   Vendor-Specific ................................... 16
       5.7   Acct-Status-Type .................................. 17
       5.8   Acct-Session-ID ................................... 18
       5.9   Mcast-Group-Address ............................... 18
       5.10  Validity-Period ................................... 19
       5.11  LAN-IP-Address .................................... 20
       5.12  LAN-Netmask ....................................... 20
       5.13  Table of Attributes ............................... 21

   6.  Examples  ............................................... 22

   7.  Issues  ................................................. 22

   Security Considerations ..................................... 22

   References .................................................. 22

   Author's Addresses .......................................... 23

   A.  Appendix A .............................................. 24
       A.1   Introduction ...................................... 24
       A.2   Receiver JOIN Authentication Process .............. 25
       A.3   Detailed Receiver Authentication Process .......... 25
       A.4   Detailed Sender Authentication Process ............ 28








Yamanouchi, Ishikawa, Takahashi                                [Page  2]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


1.  Introduction

The rapid deployment of IP multicast over the Internet has been realized
by MBone, an  experimental IP multicast network  over the Internet.   IP
multicast  is  still at  an experimental  stage.   In  order to  make IP
multicast  a commercial service, many enhancements  to  IP multicast are
required.  Among them security is one of the most important enhancements
to IP multicast.  There  are no security functions  in IGMPv2.  Any host
can send IP multicast datagrams  to a host group.  Any  host can join  a
host group and receive IP multicast datagrams which are sent to the host
group.    There are no means to   know who are  the  current sending and
receiving hosts.

An extension  to IGMP-v2   is  proposed in   [1] for  multicast security
enhancement.    This document describes   the RADIUS  interface that the
security mechanisms in [1] uses for getting authentication information.

RADIUS  (Remote Authentication   Dial  In User  Service) was  originally
designed for implementing centralized database for serial line and modem
pool authentication [3]  and accounting [4].   This memo extends the use
of the RADIUS protocol  framework to allow  the IGMP security control to
gmaintain a single, centralized  authentication database, and at the same
time, to maintain the usage information at a RADIUS accounting server.

The authentication  server must  be  able to provide the  authentication
service requested by the routers.  The router will provide a user ID and
a password for authentication.  For network security, a challenge- based
authentication is required.  Authentication should be per service, i.e.,
per  multicast  group address.  Other  authentication  requirements  are
identical to the RADIUS terminal authentication.

The use of RADIUS is optional to the security-enhanced routers.

If    a security-enhanced  router   is  configured  to  use  RADIUS  for
authentication, it expects  the RADIUS server  to provide authentication
service.   This mechanism is identical  to  the authentication of serial
line users/terminals, but some additional attributes are needed.

If the ISPs and   content service providers want to   keep track of  the
usage of  the multicast-ed service,  they   set the routers  to log  the
authentication transaction information  at a centralized logging server.
This  logging  information transaction  may again be  implemented by the
RADIUS accounting protocol by slightly extending attributes.


Network Security

Transactions  between     the client  multicast    router   and   RADIUS
authentication and accounting  servers are authenticated through the use
of a shared secret, which is never sent over the network.



Yamanouchi, Ishikawa, Takahashi                                [Page  3]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


2.  Operation

When a client multicast router is configured to  use RADIUS with account
support, at the  start of multicast service  it will generate an Account
Start  packet describing  the type   of  service (multicast receiver  or
sender)  being      delivered, and   will send    that    to the  RADIUS
Mcast-Accounting  server, which will send  back  an acknowledgement that
the packet has been received.  At the end of service delivery the client
multicast router  will generate  an  Account Stop  packet describing the
type of service that was  delivered.  It will  send  that to the  RADIUS
Mcast-Accounting  server, which will send   back an acknowledgement that
the packet has been received.

When  a  client router  receives an  IGMP-Join  request, it  requests an
authentication to the  RADIUS Mcast Authentication  server by sending an
Access-Request   to the   RADIUS  Mcast-Authentication  server   via the
network. At the receipt  of  positive response   from the  RADIUS  Mcast
Authentication  server, the client  router  requests to the RADIUS Mcast
Account server with an Account-Request/Start to start accounting.

When a client router receives an IGMP-Leave  request, it simply requests
to  the Mcast  Account   server with  an  Account-Request/Stop  to  stop
accounting.

A detailed process of a few sample transactions is described in Appendix
A.

It is  recommended that the  client router continues attempting  to send
the Access-Request packet  until  it receives an  acknowledgement, using
some  form of back-off.  If  no response is returned  within a length of
time, the request is re- sent a number of times.

The RADIUS Mcast Accounting server MAY make requests of other servers in
order to satisfy the request, in which case it acts as a client.

If the  RADIUS  accounting server  is unable  to successfully record the
accounting packet it MUST NOT send an Accounting-Response acknowledgment
to the client.


3.  Packet Format

Packet format is identical to RADIUS and RADIUS accounting.

Exactly one RADIUS Accounting  packet is  encapsulated  in the UDP  Data
field [1], where the UDP  Destination Port field indicates 1812  (RADIUS
Authentication service) and 1813 (RADIUS Accounting service) (decimal).

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



Yamanouchi, Ishikawa, Takahashi                                [Page  4]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


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

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


Code

   The Code  field  is one octet,  and   identifies the type   of RADIUS
   packet.  When a packet is received with an  invalid Code field, it is
   silently discarded.

   The  following  Code  values  of  RADIUS  is  used for Multicast User
   Authentication Codes (decimal):
      1       Access-Request
      2       Access-Accept
      3       Access-Reject

   and for Multicast User Accounting Codes (decimal):
      4       Accounting-Request
      5       Accounting-Response

Identifier

   The Identifier field is one octet, and aids  in matching requests and
   replies.  This is identical to RADIUS.

Length

   This part  is the same  as that of RADIUS.  The  Length  field is two
   octets.  It  indicates the length of  the  packet including the Code,
   Identifier, Length,    Authenticator and  Attribute  fields.   Octets
   outside the  range of the Length  field should be  treated as padding
   and should be  ignored on reception.  If the  packet is  shorter than
   the Length field indicates,  it  should be  silently discarded.   The
   minimum length is 20 and maximum length is 4096.

Authenticator

   This part is the same as that of  RADIUS.  The Authenticator field is


Yamanouchi, Ishikawa, Takahashi                                [Page  5]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


   sixteen  (16) octets.   The   most significant octet  is  transmitted
   first.  This value  is used to authenticate  the messages between the
   client and RADIUS accounting server.

Request Authenticator

   This  part is the same   as that  of  RADIUS.  In  Accounting-Request
   Packets, the  Authenticator value  is a  16  octet MD5 [5]  checksum,
   called the Request Authenticator.

   The NAS  and RADIUS  accounting server  share  a secret.  The Request
   Authenticator field in Accounting-Request packets contains a one- way
   MD5 hash calculated over a stream of octets  consisting of the Code +
   Identifier + Length  + 16 zero octets  + request  attributes + shared
   secret (where + indicates   concatenation).  The  16 octet  MD5  hash
   value is stored in the  Authenticator field of the Accounting-Request
   packet.

Response Authenticator

   This part is the same as that  of RADIUS.  The Authenticator field in
   an Accounting-Response packet  is called  the Response Authenticator,
   and  contains a one-way MD5 hash  calculated over  a stream of octets
   consisting of the Accounting-  Response Code, Identifier, Length, the
   Request Authenticator field from  the Accounting-Request packet being
   replied   to, and  the response attributes    if any, followed by the
   shared secret.  The resulting  16 octet MD5 hash  value is  stored in
   the Authenticator field of the Accounting-Response packet.

Attributes

   This   part  is the same  as  that  of  RADIUS.   Attributes may have
   multiple instances, in such a  case  the order  of attributes of  the
   same type SHOULD be preserved.  The  order of attributes of different
   types is not required to be preserved.

4.  Packet Types

   This section is   the same as  that  of RADIUS  and RADIUS accounting
   documents except for the items described below.

4.1.  Access-Request

   Description

      An Access-Request   SHOULD  contain  a   NAS-IP-Address attribute.
      NAS-Identifier attribute is prohibited in the case of IP multicast
      user authentication.  It    MUST  CHAP-Password attribute.    User
      password attribute is   prohibited.  A  NAS-Port  or NAS-Port-Type
      attribute is not used.



Yamanouchi, Ishikawa, Takahashi                                [Page  6]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      An  Access-Request MAY contain  additional attributes as a hint to
      the server, but the server is not required to honor the hint.

   A summary of the  Access-Request packet format  is shown below.   The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Request Authenticator                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      1 for Access-Request.

   Identifier

      The Identifier  field MUST be  changed whenever the content of the
      Attributes  field changes,  and  whenever a valid  reply has  been
      received  for   a  previous request.   For   retransmissions,  the
      Identifier MUST remain unchanged.

   Request Authenticator

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

   Attributes

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

4.2.  Access-Accept

   Description

      Access-Accept packets   are  sent by  the  RADIUS server.   If all
      Attribute values received in an Access-Request are acceptable then
      the RADIUS implementation MUST  transmit  a packet with the   Code
      field set to 2 (Access-Accept).

      On reception of an  Access-Accept, the Identifier field is matched


Yamanouchi, Ishikawa, Takahashi                                [Page  7]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      with  a   pending   Access-Request.  Additionally,  the   Response
      Authenticator field MUST  contain  the  correct response for   the
      pending Access-Request.  Invalid packets are silently discarded.

   A summary  of the Access-Accept  packet format is  shown  below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      2 for Access-Accept.

   Identifier

      The Identifier field  is a  copy of the  Identifier field  of  the
      Access-Request which caused this Access-Accept.

   Response Authenticator

      The  Response Authenticator value  is calculated  from the Access-
      Request value, as described earlier.

   Attributes

      The Attribute field is variable in length, and  contains a list of
      zero or more Attributes.

4.3.  Access-Reject

   Description

      If any value  of the received Attributes  is not  acceptable, then
      the RADIUS server MUST transmit  a packet with  the Code field set
      to 3 (Access-Reject).  It   MAY include one or more  Reply-Message
      Attributes with a  text message which the  NAS MAY display  to the
      user.

   A  summary  of the Access-Reject packet   format is shown below.  The
   fields are transmitted from left to right.


Yamanouchi, Ishikawa, Takahashi                                [Page  8]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      3 for Access-Reject.

   Identifier

      The  Identifier field is a   copy of the   Identifier field of the
      Access-Request which caused this Access-Reject.

   Response Authenticator

      The Response Authenticator   value is calculated from  the Access-
      Request value, as described earlier.

   Attributes

      The Attribute field is variable in length,  and contains a list of
      zero or more Attributes.

4.4.  Accounting-Request

   Description

      Accounting-Request packets   are sent from  a  client (typically a
      Network Access Server or its proxy) to a RADIUS accounting server,
      and  convey information used to   provide accounting for a service
      provided to a user.  The client transmits a RADIUS packet with the
      Code field set to 4 (Accounting-Request).

      Upon receipt of an Accounting-Request, the server MUST transmit an
      Accounting-Response  reply   if    it successfully  records    the
      accounting packet, and MUST NOT transmit any  reply if it fails to
      record the accounting packet.

      Any attribute valid in  a  RADIUS Access-Request or  Access-Accept
      packet is valid in a RADIUS Accounting-Request packet, except that
      the  following  attributes MUST NOT be   present in an Accounting-


Yamanouchi, Ishikawa, Takahashi                                [Page  9]
INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      Request:  User-Password,   CHAP-Password,  Reply-Message,   State.
      Either  NAS-IP-Address   or NAS-Identifier MUST   be present  in a
      RADIUS Accounting-Request.  It SHOULD  contain a NAS-Port or  NAS-
      Port-Type attribute or both unless the service  does not involve a
      port or the NAS does not distinguish among its ports.

   A summary of  the  Accounting-Request packet  format is  shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Request Authenticator                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      4 for Accounting-Request.

   Identifier

      The Identifier field  MUST be changed whenever  the content of the
      Attributes  field changes,  and whenever  a  valid reply has  been
      received for a previous  request.   For retransmissions where  the
      contents are identical, the Identifier MUST remain unchanged.

   Request Authenticator

      The Request Authenticator  of an Accounting-Request contains a 16-
      octet MD5 hash value calculated  according to the method described
      in "Request Authenticator" above.

   Attributes

      The Attributes field is variable in length, and contains a list of
      Attributes.

4.5.  Accounting-Response

   Description

      Accounting-Response  packets are   sent by  the  RADIUS accounting
      server to the  client  to acknowledge that the  Accounting-Request
      has been received and recorded successfully.  If the Accounting-


Yamanouchi, Ishikawa, Takahashi                                [Page 10]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      Request  was  recorded successfully  then  the  RADIUS  accounting
      server  MUST transmit   a packet with   the Code  field set  to  5
      (Accounting-Response).  On  reception of an Accounting-Response by
      the  client, the  Identifier   field is  matched  with  a  pending
      Accounting-Request.  Invalid packets are silently discarded.

      A   RADIUS Accounting-Response    is not required    to  have  any
      attributes in it.

   A summary of  the Accounting-Response packet  format is shown  below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      5 for Accounting-Response.

   Identifier

      The  Identifier field is  a  copy of the   Identifier field of the
      Accounting-Request which caused this Accounting-Response.

   Response Authenticator

      The Response Authenticator  of  an Accounting-Response  contains a
      16-octet    MD5 hash value    calculated  according to the  method
      described in "Response Authenticator" above.

   Attributes

      The Attributes field is variable in length, and contains a list of
      zero or more Attributes.

5.  Attributes

   This section is   the same as  that  of RADIUS and  RADIUS accounting
   documents except for the items described below.




Yamanouchi, Ishikawa, Takahashi                                [Page 11]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


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

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

   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.
      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.  The   multicast  user
      authentication specification concerns the following values:

          1      User-Name
          3      CHAP-Password
          4      NAS-IP-Address
          6      Service-Type
         18      Reply-Message
         26      Vendor-Specific ?
         40      Acct-Status-Type
         44      Acct-Session-Id

   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 an  Access-Request  but with an  invalid
      Length, an Access-Reject  SHOULD be transmitted.   If an Attribute
      is received in an Access-Accept, Access-Reject or Access-Challenge
      packet with  an invalid length, the packet  MUST either be treated
      an Access-Reject  or else silently  discarded.  If an attribute is
      received in an   Accounting-Request  with an invalid  Length,  the
      entire request should be silently discarded.

   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.

      Note that a "string" in RADIUS does not  require termination by an
      ASCII NUL because the Attribute already has a length field.

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

      string    0-253 octets


Yamanouchi, Ishikawa, Takahashi                                [Page 12]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998



      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 but it is presented
                here for possible use within Vendor-Specific attributes.


5.1.  User-Name

   Description

      This Attribute indicates the name of the user to be authenticated.
      It is only used in Access-Request packets.

   A summary of the User-Name Attribute format is shown below.  The
   fields are transmitted from left to right.

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

   Type

      1 for User-Name.

   Length

      >= 3

   String

      The String field is  one or more  octets.   The NAS may  limit the
      maximum length of the User-Name but the ability to handle at least
      63 octets is recommended.

5.2.  CHAP-Password

   Description

      This Attribute indicates the   response  value provided by a   PPP
      Challenge-Handshake     Authentication Protocol   (CHAP) user   in
      response to the challenge.     It is only used in   Access-Request
      packets.

      The CHAP challenge value is found  in the CHAP-Challenge Attribute


Yamanouchi, Ishikawa, Takahashi                                [Page 13]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      (60)   if   present  in  the  packet,   otherwise  in the  Request
      Authenticator field.

   A summary of the CHAP-Password Attribute format  is shown below.  The
   fields are transmitted from left to right.

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

   Type

      3 for CHAP-Password.

   Length

      19

   CHAP Ident

      This field is one octet, and contains the CHAP Identifier from the
      user's CHAP Response.

   String

      The String field is 16 octets, and contains the CHAP Response from
      the user.

5.3.  NAS-IP-Address

   Description

      This  Attribute indicates the   identifying IP Address  of the NAS
      which is  requesting authentication of  the user.  It is only used
      in    Access-Request packets.   Either   NAS-IP-Address   or  NAS-
      Identifier SHOULD be present in an Access-Request packet.

   A summary of the NAS-IP-Address 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     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Yamanouchi, Ishikawa, Takahashi                                [Page 14]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

      The Address field is four octets.

5.4.  Service-Type

   Description

      This  Attribute indicates    the  type of  service   the  user has
      requested, or the type of service to be provided.   It MAY be used
      in both  Access-Request and Access-Accept packets.   A NAS  is not
      required to  implement all of these  service types, and MUST treat
      unknown  or  unsupported Service-Types as though  an Access-Reject
      had been received instead.

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

   Type

      6 for Service-Type.

   Length

      6

   Value

      The Value field is four octets.

      10      Mcast-Sender
      11      Mcast-Receiver


      The service  types designate the kind  of services  the user would


Yamanouchi, Ishikawa, Takahashi                                [Page 15]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      like to receive.  In the original RADIUS they are used to indicate
      the services the NAS should provide to the user, and if used in an
      Access-  Accept,  they should be  considered  to be a  hint to the
      RADIUS  server that the  NAS has reason  to believe the user would
      prefer the kind of service indicated.

      Mcast-Sender        The user would like to be authenticated as
                          a multicast sender.

      Mcast-Receiver      The user would like to be authenticated as
                          a multicast receiver.

5.5.  Reply-Message

   Description

      This Attribute indicates text which MAY be displayed to the user.

      When used in an Access-Accept, it is the success message.

      When used in an Access-Reject, it is the  failure message.  It MAY
      indicate  a   dialog message to  prompt   the user  before another
      Access-Request attempt.

      Multiple Reply-Message's MAY be included and if any are displayed,
      they MUST be displayed  in the same  order as  they appear  in the
      packet.

   A summary of the Reply-Message Attribute format is shown below.   The
   fields are transmitted from left to right.

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


   Type

      18 for Reply-Message.

   Length

      >= 3

   String

      The  String field  is  one or more  octets,  and  its contents are
      implementation dependent.   It is intended  to  be human readable,
      and MUST NOT affect operation of  the protocol.  It is recommended


Yamanouchi, Ishikawa, Takahashi                                [Page 16]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      that  the message  contain  displayable ASCII  characters from the
      range   10, 13,  and   32  through  126  decimal.   Mechanisms for
      extension to  other character  sets are  beyond the  scope of this
      specification.

5.6.  Vendor-Specific

   Description

      This Attribute is available to allow  vendors to support their own
      extended  Attributes not suitable for  general usage.  It MUST not
      affect the operation of the RADIUS protocol.

      Servers not equipped to  interpret the vendor-specific information
      sent  by a client MUST  ignore  it (although it  may be reported).
      Clients which do  not receive desired vendor-specific  information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   A summary  of the  Vendor-Specific  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       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific.

   Length

       >= 7

   Vendor-Id

      The high-order octet is  0 and the low-order 3  octets are the SMI
      Network  Management  Private  Enterprise Code   of  the Vendor  in
      network byte order, as defined in the Assigned Numbers RFC.

   String

      The String field is one or more octets.  The  actual format of the
      information    is  site or application    specific,   and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification  of the range of allowed  usage  of this field is


Yamanouchi, Ishikawa, Takahashi                                [Page 17]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      outside the scope of this specification.

      It SHOULD be encoded as a sequence of vendor  type / vendor length
      /  value   fields, as follows.    The Attribute-Specific  field is
      dependent   on the vendor's    definition of  that attribute.   An
      example   encoding of   the Vendor-Specific  attribute  using this
      method 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       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


5.7.  Acct-Status-Type

   Description

      This attribute indicates whether this Accounting-Request marks the
      beginning of the user service (Start) or the end (Stop).

      It MAY be used by the client to mark the  start of accounting (for
      example, upon booting) by specifying Accounting-On and to mark the
      end of accounting (for example, just before a scheduled reboot) by
      specifying Accounting-Off.

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

   Type

      40 for Acct-Status-Type.

   Length

      6




Yamanouchi, Ishikawa, Takahashi                                [Page 18]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


   Value

      The Value field is four octets.

       1      Start
       2      Stop
       7      Accounting-On
       8      Accounting-Off

5.8.  Acct-Session-Id

   Description

      This attribute is a unique Accounting ID to make  it easy to match
      start and stop records in a log file.   The start and stop records
      for a  given  session MUST have  the  same Acct-Session-Id.  It is
      strongly recommended that the Acct-Session-Id be a printable ASCII
      string.

      For  example, one implementation uses   a  string with an  8-digit
      upper case hexadecimal number,  the first two digits  increment on
      each reboot (wrapping  every 256 reboots) and   the next 6  digits
      counting from 0 for the first person logging in  after a reboot up
      to 2^24-1, about 16 million.  Other encodings are possible.

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

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

   Type

      44 for Acct-Session-Id.

   Length

      >= 3

   String

      The String field SHOULD be a string of printable ASCII characters.

5.9. Mcast-Group-Address

   Description

      This attribute indicates  the multicast group IP address  (class-D


Yamanouchi, Ishikawa, Takahashi                                [Page 19]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      address)  on  which the   routing is  to be   authenticated.  This
      attribute is passed from the router for per-service authentication
      purpose.

   A  summary of the Mcast-Group-Address 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     |             Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      90 for Mcast-Group-Address

   Length

      6

   Address

      The Address field is four octets.


5.10. Validity-Period

   Description

      This attribute indicates the  length of the  time period  in which
      the authentication is valid.  The authentication expires after the
      period designated in this attribute,  and the NAS router initiates
      a re-authentication process of the user terminal.

    A summary of the Mcast-Group-Address 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     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      93 for Validity-Period


Yamanouchi, Ishikawa, Takahashi                                [Page 20]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


   Length

      6

   Value

      The Value field is four octets in the unit of seconds.

5.11. LAN-IP-Address

   Description

      This attribute  indicates the IP  address of the LAN adapter where
      the  user terminal is connected to.   This attribute  is used only
      for LAN-connected terminals.  It is passed from  the router to the
      multicast user authentication server so that  the server stores it
      in association with  the terminal entry.   It will be used to find
      out all   the  terminals connected  to  the LAN   which  failed in
      re-authentication.

   A summary of the LAN-IP-Address 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     |             Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      91 for LAN-IP-Address

   Length

      6

   Address

      The Address field is four octets.



5.12. LAN-NetMask

   Description

      This attribute indicates  the NetMask value  of the LAN where  the
      terminal is   connected  to.   This attribute  is   used  only for


Yamanouchi, Ishikawa, Takahashi                                [Page 21]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


      LAN-connected  terminals.   It is passed from  the   router to the
      multicast user authentication server so  that the server stores it
      in association with the  terminal entry.  It  will be used to find
      out  all  the terminals  connected  to  the LAN  which   failed in
      re-authentication.

   A summary of  the LAN-NetMask 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     |             Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      92 for LAN-NetMask

   Length

      6

   Address

      The Address field is four octets.

5.13.  Table of Attributes

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

   Request   Accept   Reject   AcctReq  Acct-Resp   #    Attribute
   1         0        0        0        0           1   User-Name
   1         0        0        0        0           3   CHAP-Password
   1         0        0        0        0           4   NAS-IP-Address
   1         0        0        0        0           6   Service-Type
   0         0+       0+       0+       0          18   Reply-Message
   0+        0+       0        0+       0          26   Vendor-Specific
   0         0        0        1        0          40   Acct-Status-Type
   0         0        0        1        0          44   Acct-Session-ID
   1         0        0        0        0               Mcast-Group-
Address
   0         1        0        0        0               Validity-Period
   0+        0        0        0        0               LAN-IP-Address
   0+        0        0        0        0               LAN-NetMask

   Request   Accept   Reject   AcctReq  Acct-Resp   #    Attribute



Yamanouchi, Ishikawa, Takahashi                                [Page 22]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


   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.
 1     Exactly one instance of this attribute MUST be present in packet.

6.  Examples

   A few examples are presented in Appendix A  to illustrate the flow of
   packets  and  use  of typical  attributes.  These   examples  are not
   intended to be exhaustive, many others are possible.

7.  Issues

 1) There is a   controversy about whether  the multicast authentication
   should  be a part of   RADIUS service or  a  separate service.   This
   document follows the  idea of  the same RADIUS  server to  serve as a
   multicast authentication  server,  but it  would also be  possible to
   have a totally  separate  server for multicast  authentication.  This
   difference affects the port number  assignment of the server.   Other
   protocol definitions will not change.

 2) The  idea  of separating   the  authentication  transaction and  the
   accounting  transaction    is  controversial.     In  the   multicast
   authentication case the accounting transaction described in this memo
   is intended to keep track of the joined terminals, which actually can
   be traced by looking at the authentication  transactions.  A merit of
   avoiding separate accounting transaction is  that it would reduce the
   risk of inappropriate logging caused  by any interruption between the
   authentication and accounting transactions.

Security Considerations

   Security issues are the primary topic of this document.

References

   [1]   Ishikawa, N. et al, "Security Extensions for IGMP Version 2"

   [2]   Fenner, W., "Internet Group Management Protocol, Version 2",
         RFC 2236, November 1997.

   [3]   Rigney, C. et al, "Remote Authentication Dial In User
         Service (RADIUS)", RFC 2138, April 1997.

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

   [5]   Rivest, R. and Dusse, S., "The MD5 Message-Digest Algorithm",
         RFC 1321, April 1992.



Yamanouchi, Ishikawa, Takahashi                                [Page 23]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


Author's Addresses

  Nagatsugu Yamanouchi
  yamanouc@trl.ibm.co.jp
  IBM Research, Tokyo Research Laboratory
  IBM Japan
  1623-14 Shimotsuruma, Yamato-shi, Kanagawa 242 Japan

  Norihiro Ishikawa
  isic@isl.ntt.co.jp
  NTT Information and Communication Systems Laboratories
  1-1 Hikarinooka, Yokosuka, Kanagawa 239 Japan

  Osamu Takahashi
  osamu@isl.ntt.co.jp
  NTT Information and Communication Systems Laboratories
  1-1 Hikarinooka, Yokosuka, Kanagawa 239 Japan




































Yamanouchi, Ishikawa, Takahashi                                [Page 24]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998



Appendix A.

A.1  Introduction

Background

  In  short, the  INGRESS   router  get authentication about   multicast
  routing setup     from the network administrator      in order for the
  administrator  to gain control over   multicast routing.  This  allows
  receiver authentication of mcast routing.   This mechanism is  defined
  in [1] as an extension of IGMP functions.

  The authentication information may be centrally maintained at a RADIUS
  server   by  employing  the RADIUS  mechanism,    so that the  network
  administrator need not   maintain the user authentication  information
  database in many INGRESS routers.

  A similar    authentication to the  mcast  sender  is useful  to avoid
  uncontrolled mcast transmission.

  At  the same time, the centralized  RADIUS server(s) may keep track of
  the  terminal  information in  order to   measure  subscription.  This
  subscription  information  may  be  used   to  estimate the number  of
  audience  of the  program, the number  of  multicast  subscribers, and
  possibly traffic bandwidth.

  These authentication and  subscriber measurement may be implemented by
  extending the RADIUS interface framework [2], [3].

Additional Technical Considerations

  Keeping track of  terminals  require additional considerations to  the
  multicast-routing authentication proposed   in [1].   In  the case  of
  (shared media) LAN-connected  terminals the router only controls mcast
  routing to the  LAN.  The delivery  control to a  specific terminal is
  implemented by  the broadcast mechanism of  the  underlying LAN.  This
  implies that  the   mcast authentication   can neither control    data
  delivery nor maintain the  terminal/subscriber information in the case
  of LAN-connected terminals.

  The  mechanism  in  [1] forces all  terminals   on  the LAN to  obtain
  authentication even if the router opens up  the mcast route to the LAN
  by  the first requesting terminal.   This  operational rule allows the
  router   to register the  terminal  as  a  subscriber.  An  additional
  consideration is necessary for unsubscribing.  [1] forces terminals to
  issue IGMP  LEAVE  (IGMP v2) at  leaving  from  subscription,  and the
  router recognizes the status change of the terminal.  Only the garbage
  cleanup, i.e., the terminals that have left without LEAVE notification
  for    such reasons  as      system  crash, requires    an  additional
  consideration.


Yamanouchi, Ishikawa, Takahashi                                [Page 25]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998



  A  similar  garbage   cleanup  operation is  needed  in  mcast routing
  control, and the subscription measurement mechanism cleans the garbage
  by using this  operation as  a trigger.   An  additional interface  to
  RADIUS is used to pass information necessary  for the cleanup.  Such a
  cleanup operation  is     invoked   by a   failure    of  a   terminal
  re-authentication, which provides the ID  of the failed terminal.  The
  RADIUS server maintains a table of tuples <Terminal$B!"(B(Router$B!"(BLAN_ID)>
  so that  it can extract the key  for cleanup, (router, LAN_ID).  Those
  terminals that  share the same (router,  LAN_ID) key are to be cleaned
  up.  Note that LAN_ID here  is used to determine  the LAN in the  case
  where two  or   more LANs are    connected to the   router.  LAN_ID is
  identified  by  the IP address  assigned  to the   LAN  adapter in the
  router, plus the netmask.

A.2  Receiver JOIN Authentication Process

  The authentication process is summarized as follows:

    Terminal -Membership Report-> Router
                    (UserID)   Router generates
                               a challenge(16B).
    Terminal <------Challenge---- Router
              (Challenge, UserID)
    Terminal ---User Response---> Router ----Access-Request----> RADIUS
              (Response, UserID)           (UserID, McastAddr,
                                            Challenge, Response)
    Terminal <-------Success----- Router <---Access-Accept------ RADIUS
               (Validity Period)             (Validity Period)

  In  addition  to the  authentication above,  the  following process is
  added to  maintain  the subscriber list  in  the RADIUS server.   This
  process uses RADIUS Accounting (RFC2139) functions.

                                  Router ----AcctStatus Start--> RADIUS
                                           (User ID, McastAddr,
                                         LAN-IP-Addr, LAN-NetMask)
                                  Router <---------OK----------- RADIUS
                                                  (OK)

  We expect that the  terminal issues IGMP-Leave  when leaving from  the
  multicast service.  At  the  time of  Leave,  the router notifies  the
  RADIUS server the termination   of the receiver by   RADIUS Accounting
  Status Stop command.

A.3 Detailed Receiver Authentication Process

  Following  scenarios  are  the  detailed   transactions  for multicast
  receiver authentication.




Yamanouchi, Ishikawa, Takahashi                                [Page 26]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


  Router Initialization Process
                                   Router ----AcctStatus ON----> RADIUS
                                     Transaction ID(assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type  Acct ON(7)
                                     Acct-SessionID(assigned by Router)
                                     NAS-IP-Address (Router IP address)
                                   Router <-----------OK-------- RADIUS
                                     Transaction ID
                                     Radius Code(6)(Accting Response)

  Receiver JOIN Process
    Terminal--Membership Request-->Router
          (UserID, mcast Address)
                    (UserID)   Router generates
                               a challenge(16B).
    Terminal <------Challenge----- Router
               (Challenge, UserID)
    Terminal ----User Response---> Router ----Access-Request---> RADIUS
      (Challenge Response, UserID)
                                     Transaction ID(assigned by Router)
                                     Radius Code(1)(Access Request)
                                     Request Authenticator (Challenge)
                                     User-Name      (UserID)
                                     CHAP-Password(CHAPID+UserResponse)
                                     NAS-IP-Address (Router IP address)
                                     Service-Type Mcast-Receiver(11)
                                     Mcast-Group-Address  4-octets

                                         RADIUS Server authenticates by
                                         UserID,Challenge,User Response

    Terminal <------Success------- Router <-----Access-Accept-- RADIUS
                                     Transaction ID
                                     Radius Code(2) (Access Accept)
                                     Validity-Period  4-octets(seconds)
                (Validity Period)
                                   Router ---AcctStatus Start--> RADIUS
                                     Transaction ID(assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type  Start(1)
                                     Acct-Session-ID
                                     User-Name (User ID)
                                     NAS-IP-Address (Router IP address)
                                     Service-Type  Mcast-Receiver(11)
                                     Mcast-Group-Address  4-octets
                                   Only for LAN-connected receivers:
                                     LAN-IP-Address  4-octets
                                     LAN-NetMask     4-octets
                                   Router <---------OK---------- RADIUS
                                     Transaction ID
                                     Radius Code(6)(Accting Response)

Yamanouchi, Ishikawa, Takahashi                                [Page 27]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998



  Authentication failure case:

    Terminal <-------Fail--------- Router <----Access-Accept---- RADIUS
                                     Transaction ID
                                     Radius Code(3) (Access Reject)

  Receiver Leave Process

    Terminal ----Leave Request---> Router
            (UserID, mcast Address)
                                   Router ---AcctStatus Stop---> RADIUS
                                     Transaction ID(assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type Stop(2)
                                     Acct-Session-ID
                                     User-Name (UserID)
                                     NAS-IP-Address (Router IP address)
                                     Service-Type  Mcast-Receiver(11)
                                     Mcast-Group-Address  4-octets
                                   Only for LAN connected receivers:
                                     LAN-IP-Address  4-octets
                                     LAN-NetMask     4-octets
                                   Router <----------OK----------RADIUS
                                     Transaction ID
                                     Radius Code(6) (Accting Response)

  Receiver Re-Authentication Process

    Terminal <-Grp Specific Query- Router
    Terminal -Membership Request-> Router
    Terminal <------Challenge----- Router
    Terminal ----User Response---> Router ----Access-Request---> RADIUS
    Terminal <------Success------- Router <----Access-Accept---- RADIUS
                                   Router ---AcctStatus Start--> RADIUS
                                   Router <----------OK--------- RADIUS

  Receiver Re-Authentication Failure Process
    Terminal <-Grp Specific Query- Router
                (NO RESPONSE)
                                   Router ---AcctStatus Stop---> RADIUS
                                     Transaction ID(assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type Stop(2)
                                     Acct-Session-ID
                                     User-Name (User ID) = "********"
                                       Wildcard to designate all.
                                     NAS-IP-Address(Router IP address)
                                     Service-Type Mcast-Receiver(11)
                                     Mcast-Group-Address  4-octets
                                   Only for LAN connected receivers:


Yamanouchi, Ishikawa, Takahashi                                [Page 28]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


                                     LAN-IP-Address  4-octets
                                     LAN-NetMask     4-octets
                                   Router <----------OK--------- RADIUS
                                     Transaction ID
                                     Radius Code(6)(Accting Response)

  Router Termination Process
                                   Router ----AcctStatus OFF---> RADIUS
                                     Transaction ID (assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type Acct OFF(8)
                                     Acct-SessionID (assigned by Router)
                                     NAS-IP-Address(Router IP address)
                                   Router <----------OK--------- RADIUS
                                     Radius Transaction ID
                                     Radius Code = 6 (Accounting Response)

A.4 Detailed Sender Authentication Process

  Sender JOIN Process

  The interface to  the RADIUS  server is  almost identical to  that  of
  receivers.

    Terminal -Membership Request-> Router
    Terminal <-------Challenge---- Router
    Terminal -----User Response--> Router ----Access-Request---> RADIUS
                                     Transaction ID (assigned by Router)
                                     Radius Code(1) (Access Request)
                                     Request Authenticator (Challenge)
                                     User-Name (User ID)
                                     CHAP-Password (CHAPID+UserResponse)
                                     NAS-IP-Address(Router IP address)
                                     Service-Type  Mcast-Sender(10)
                                     Mcast-Group-Address  4-octets

                                         RADIUS Server authenticates by
                                         UserID,Challenge,User Response

    Terminal <------Success------- Router <----Access-Accept--- RADIUS
                                     Transaction ID
                                     Radius Code(2) (Access Accept)
                                     Validity-Period  4-octets(seconds)
                (Validity Period)

                                   Router ---AcctStatus Start--> RADIUS
                                     Transaction ID(assigned by Router)
                                     Radius Code(4) (Accting Request)
                                     Acct-Status-Type  Start(1)
                                     Acct-Session-ID
                                     User-Name (User ID)


Yamanouchi, Ishikawa, Takahashi                                [Page 29]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


                                     NAS-IP-Address (Router IP address)
                                     Service-Type  Mcast-Sender(10)
                                     Mcast-Group-Address  4-octets
                            (*)LAN-based participation is not expected.

                                   Router <---------OK---------- RADIUS
                                     Transaction ID
                                     Radius Code(6) (Accting Response)

  Authentication failure case:
    Terminal <-------Fail--------- Router <----Access-Reject---- RADIUS
                                     Transaction ID
                                     Radius Code(3) (Access Reject)

  Receiver Leave Process

    Terminal ----Leave Request---> Router
           (User ID, mcast Address)
                                   Router ---AcctStatus Stop---> RADIUS
                                     TransactionID(assigned by Router)
                                     Radius Code(4)(Accting Request)
                                     Acct-Status-Type  Stop(2)
                                     Acct-Session-ID
                                     User-Name  (User ID)
                                     NAS-IP-Address(Router IP address)
                                     Service-Type  Mcast-Sender (10)
                                     Mcast-Group-Address  4-octets

                                   Router <---------OK---------- RADIUS
                                     Transaction ID
                                     Radius Code(6) (Accting Response)

  Sender Re-Authentication Process

    Terminal <--one-to-one Query-- Router
    Terminal -Membership Request-> Router
    Terminal <------Challenge----- Router
    Terminal ----User Response---> Router ----Access-Request---> RADIUS
    Terminal <-------Success------ Router <----Access-Accept---- RADIUS
                                   Router ---AcctStatus Start--> RADIUS
                                   Router <----------OK--------- RADIUS

  Receiver Re-Authentication Failure Process
    Terminal <--one-to-one Query-- Router
               (NO RESPONSE)
                                   Router ---AcctStatus Stop--> RADIUS
                                     TransactionID (assigned by Router)
                                     Radius Code(4) (Accting Request)
                                     Acct-Status-Type  Stop(2)
                                     Acct-Session-ID
                                     User-Name  (User ID)


Yamanouchi, Ishikawa, Takahashi                                [Page 30]


INTERNET-DRAFT   RADIUS Extension for MCast Authentication    March 1998


                                     (*)UserID recorded in the Router.
                                     NAS-IP-Address (Router IP address$B!K(B
                                     Service-Type  Mcast-Sender(10)
                                     Mcast-Group-Address  4-octets
                                   Router <----------OK--------- RADIUS
                                     Radius Transaction ID
                                     Radius Code(6) (Accting Response)














































Yamanouchi, Ishikawa, Takahashi                                [Page 31]