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