idnits 2.17.1 draft-yamanouchi-radius-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 266 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 7 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 175: '...ccounting server MAY make requests of ...' RFC 2119 keyword, line 179: '...unting packet it MUST NOT send an Acco...' RFC 2119 keyword, line 279: '... same type SHOULD be preserved. The...' RFC 2119 keyword, line 291: '...Access-Request SHOULD contain a ...' RFC 2119 keyword, line 293: '...tication. It MUST CHAP-Password a...' (39 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...ocument is a...' == Line 18 has weird spacing: '...ths and may ...' == Line 20 has weird spacing: '...aterial or t...' == Line 23 has weird spacing: '... entire list...' == Line 24 has weird spacing: '...listing conta...' == (261 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2138 (ref. '3') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '5') Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 N. Yamanouchi, IBM Japan 2 N. Ishikawa, NTT 3 O. Takahashi, NTT 5 March 12, 1998 6 Expires in six months 8 RADIUS Extension for Multicast Router Authentication 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This memo describes an extension of RADIUS authentication protocol 32 (RFC2138) and RADIUS accounting protocol (RFC2139) to provide 33 authentication service about multicast receivers and senders to the 34 ingress and egress routers, and to keep track of the receiving and 35 sending clients for multicast data feed service management. New 36 services and attributes are added to the RADIUS definitions while 37 the authentication transaction mechanisms are preserved. The 38 authentication server authenticates the multicast receiver/sender 39 by using the CHAP-based mechanism. The account server logs the 40 start and stop points of multicast route usage. This extension is 41 intended to be used in conjunction with the IGMP extension for 42 multicast receiver and sender authentication. 44 Yamanouchi, Ishikawa, Takahashi [Page 1] 45 Table of Contents 47 1. Introduction ............................................ 2 49 2. Operation ............................................... 3 51 3. Packet Format ........................................... 3 53 4. Packet Types ............................................ 5 54 4.1 Access-Request .................................... 5 55 4.2 Access-Accept...................................... 6 56 4.3 Access-Reject...................................... 7 57 4.4 Accounting-Request................................. 8 58 4.5 Accounting-Response................................ 9 60 5. Attributes .............................................. 10 61 5.1 User-Name ......................................... 12 62 5.2 CHAP-Password ..................................... 12 63 5.3 NAS-IP-Address .................................... 13 64 5.4 Service-Type ...................................... 14 65 5.5 Reply-Message ..................................... 15 66 5.6 Vendor-Specific ................................... 16 67 5.7 Acct-Status-Type .................................. 17 68 5.8 Acct-Session-ID ................................... 18 69 5.9 Mcast-Group-Address ............................... 18 70 5.10 Validity-Period ................................... 19 71 5.11 LAN-IP-Address .................................... 20 72 5.12 LAN-Netmask ....................................... 20 73 5.13 Table of Attributes ............................... 21 75 6. Examples ............................................... 22 77 7. Issues ................................................. 22 79 Security Considerations ..................................... 22 81 References .................................................. 22 83 Author's Addresses .......................................... 23 85 A. Appendix A .............................................. 24 86 A.1 Introduction ...................................... 24 87 A.2 Receiver JOIN Authentication Process .............. 25 88 A.3 Detailed Receiver Authentication Process .......... 25 89 A.4 Detailed Sender Authentication Process ............ 28 91 Yamanouchi, Ishikawa, Takahashi [Page 2] 92 1. Introduction 94 The rapid deployment of IP multicast over the Internet has been realized 95 by MBone, an experimental IP multicast network over the Internet. IP 96 multicast is still at an experimental stage. In order to make IP 97 multicast a commercial service, many enhancements to IP multicast are 98 required. Among them security is one of the most important enhancements 99 to IP multicast. There are no security functions in IGMPv2. Any host 100 can send IP multicast datagrams to a host group. Any host can join a 101 host group and receive IP multicast datagrams which are sent to the host 102 group. There are no means to know who are the current sending and 103 receiving hosts. 105 An extension to IGMP-v2 is proposed in [1] for multicast security 106 enhancement. This document describes the RADIUS interface that the 107 security mechanisms in [1] uses for getting authentication information. 109 RADIUS (Remote Authentication Dial In User Service) was originally 110 designed for implementing centralized database for serial line and modem 111 pool authentication [3] and accounting [4]. This memo extends the use 112 of the RADIUS protocol framework to allow the IGMP security control to 113 gmaintain a single, centralized authentication database, and at the same 114 time, to maintain the usage information at a RADIUS accounting server. 116 The authentication server must be able to provide the authentication 117 service requested by the routers. The router will provide a user ID and 118 a password for authentication. For network security, a challenge- based 119 authentication is required. Authentication should be per service, i.e., 120 per multicast group address. Other authentication requirements are 121 identical to the RADIUS terminal authentication. 123 The use of RADIUS is optional to the security-enhanced routers. 125 If a security-enhanced router is configured to use RADIUS for 126 authentication, it expects the RADIUS server to provide authentication 127 service. This mechanism is identical to the authentication of serial 128 line users/terminals, but some additional attributes are needed. 130 If the ISPs and content service providers want to keep track of the 131 usage of the multicast-ed service, they set the routers to log the 132 authentication transaction information at a centralized logging server. 133 This logging information transaction may again be implemented by the 134 RADIUS accounting protocol by slightly extending attributes. 136 Network Security 138 Transactions between the client multicast router and RADIUS 139 authentication and accounting servers are authenticated through the use 140 of a shared secret, which is never sent over the network. 142 Yamanouchi, Ishikawa, Takahashi [Page 3] 143 2. Operation 145 When a client multicast router is configured to use RADIUS with account 146 support, at the start of multicast service it will generate an Account 147 Start packet describing the type of service (multicast receiver or 148 sender) being delivered, and will send that to the RADIUS 149 Mcast-Accounting server, which will send back an acknowledgement that 150 the packet has been received. At the end of service delivery the client 151 multicast router will generate an Account Stop packet describing the 152 type of service that was delivered. It will send that to the RADIUS 153 Mcast-Accounting server, which will send back an acknowledgement that 154 the packet has been received. 156 When a client router receives an IGMP-Join request, it requests an 157 authentication to the RADIUS Mcast Authentication server by sending an 158 Access-Request to the RADIUS Mcast-Authentication server via the 159 network. At the receipt of positive response from the RADIUS Mcast 160 Authentication server, the client router requests to the RADIUS Mcast 161 Account server with an Account-Request/Start to start accounting. 163 When a client router receives an IGMP-Leave request, it simply requests 164 to the Mcast Account server with an Account-Request/Stop to stop 165 accounting. 167 A detailed process of a few sample transactions is described in Appendix 168 A. 170 It is recommended that the client router continues attempting to send 171 the Access-Request packet until it receives an acknowledgement, using 172 some form of back-off. If no response is returned within a length of 173 time, the request is re- sent a number of times. 175 The RADIUS Mcast Accounting server MAY make requests of other servers in 176 order to satisfy the request, in which case it acts as a client. 178 If the RADIUS accounting server is unable to successfully record the 179 accounting packet it MUST NOT send an Accounting-Response acknowledgment 180 to the client. 182 3. Packet Format 184 Packet format is identical to RADIUS and RADIUS accounting. 186 Exactly one RADIUS Accounting packet is encapsulated in the UDP Data 187 field [1], where the UDP Destination Port field indicates 1812 (RADIUS 188 Authentication service) and 1813 (RADIUS Accounting service) (decimal). 190 When a reply is generated, the source and destination ports are 191 reversed. 193 Yamanouchi, Ishikawa, Takahashi [Page 4] 194 A summary of the RADIUS data format is shown below. The fields are 195 transmitted from left to right. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Code | Identifier | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | | 203 | Authenticator | 204 | | 205 | | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Attributes ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+- 210 Code 212 The Code field is one octet, and identifies the type of RADIUS 213 packet. When a packet is received with an invalid Code field, it is 214 silently discarded. 216 The following Code values of RADIUS is used for Multicast User 217 Authentication Codes (decimal): 218 1 Access-Request 219 2 Access-Accept 220 3 Access-Reject 222 and for Multicast User Accounting Codes (decimal): 223 4 Accounting-Request 224 5 Accounting-Response 226 Identifier 228 The Identifier field is one octet, and aids in matching requests and 229 replies. This is identical to RADIUS. 231 Length 233 This part is the same as that of RADIUS. The Length field is two 234 octets. It indicates the length of the packet including the Code, 235 Identifier, Length, Authenticator and Attribute fields. Octets 236 outside the range of the Length field should be treated as padding 237 and should be ignored on reception. If the packet is shorter than 238 the Length field indicates, it should be silently discarded. The 239 minimum length is 20 and maximum length is 4096. 241 Authenticator 243 This part is the same as that of RADIUS. The Authenticator field is 245 Yamanouchi, Ishikawa, Takahashi [Page 5] 246 sixteen (16) octets. The most significant octet is transmitted 247 first. This value is used to authenticate the messages between the 248 client and RADIUS accounting server. 250 Request Authenticator 252 This part is the same as that of RADIUS. In Accounting-Request 253 Packets, the Authenticator value is a 16 octet MD5 [5] checksum, 254 called the Request Authenticator. 256 The NAS and RADIUS accounting server share a secret. The Request 257 Authenticator field in Accounting-Request packets contains a one- way 258 MD5 hash calculated over a stream of octets consisting of the Code + 259 Identifier + Length + 16 zero octets + request attributes + shared 260 secret (where + indicates concatenation). The 16 octet MD5 hash 261 value is stored in the Authenticator field of the Accounting-Request 262 packet. 264 Response Authenticator 266 This part is the same as that of RADIUS. The Authenticator field in 267 an Accounting-Response packet is called the Response Authenticator, 268 and contains a one-way MD5 hash calculated over a stream of octets 269 consisting of the Accounting- Response Code, Identifier, Length, the 270 Request Authenticator field from the Accounting-Request packet being 271 replied to, and the response attributes if any, followed by the 272 shared secret. The resulting 16 octet MD5 hash value is stored in 273 the Authenticator field of the Accounting-Response packet. 275 Attributes 277 This part is the same as that of RADIUS. Attributes may have 278 multiple instances, in such a case the order of attributes of the 279 same type SHOULD be preserved. The order of attributes of different 280 types is not required to be preserved. 282 4. Packet Types 284 This section is the same as that of RADIUS and RADIUS accounting 285 documents except for the items described below. 287 4.1. Access-Request 289 Description 291 An Access-Request SHOULD contain a NAS-IP-Address attribute. 292 NAS-Identifier attribute is prohibited in the case of IP multicast 293 user authentication. It MUST CHAP-Password attribute. User 294 password attribute is prohibited. A NAS-Port or NAS-Port-Type 295 attribute is not used. 297 Yamanouchi, Ishikawa, Takahashi [Page 6] 298 An Access-Request MAY contain additional attributes as a hint to 299 the server, but the server is not required to honor the hint. 301 A summary of the Access-Request packet format is shown below. The 302 fields are transmitted from left to right. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Code | Identifier | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 | Request Authenticator | 311 | | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Attributes ... 315 +-+-+-+-+-+-+-+-+-+-+-+-+- 317 Code 319 1 for Access-Request. 321 Identifier 323 The Identifier field MUST be changed whenever the content of the 324 Attributes field changes, and whenever a valid reply has been 325 received for a previous request. For retransmissions, the 326 Identifier MUST remain unchanged. 328 Request Authenticator 330 The Request Authenticator value MUST be changed each time a new 331 Identifier is used. 333 Attributes 335 The Attribute field is variable in length, and contains the list 336 of Attributes that are required for the type of service, as well 337 as any desired optional Attributes. 339 4.2. Access-Accept 341 Description 343 Access-Accept packets are sent by the RADIUS server. If all 344 Attribute values received in an Access-Request are acceptable then 345 the RADIUS implementation MUST transmit a packet with the Code 346 field set to 2 (Access-Accept). 348 On reception of an Access-Accept, the Identifier field is matched 350 Yamanouchi, Ishikawa, Takahashi [Page 7] 351 with a pending Access-Request. Additionally, the Response 352 Authenticator field MUST contain the correct response for the 353 pending Access-Request. Invalid packets are silently discarded. 355 A summary of the Access-Accept packet format is shown below. The 356 fields are transmitted from left to right. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Code | Identifier | Length | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | Response Authenticator | 365 | | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Attributes ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+- 371 Code 373 2 for Access-Accept. 375 Identifier 377 The Identifier field is a copy of the Identifier field of the 378 Access-Request which caused this Access-Accept. 380 Response Authenticator 382 The Response Authenticator value is calculated from the Access- 383 Request value, as described earlier. 385 Attributes 387 The Attribute field is variable in length, and contains a list of 388 zero or more Attributes. 390 4.3. Access-Reject 392 Description 394 If any value of the received Attributes is not acceptable, then 395 the RADIUS server MUST transmit a packet with the Code field set 396 to 3 (Access-Reject). It MAY include one or more Reply-Message 397 Attributes with a text message which the NAS MAY display to the 398 user. 400 A summary of the Access-Reject packet format is shown below. The 401 fields are transmitted from left to right. 403 Yamanouchi, Ishikawa, Takahashi [Page 8] 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Code | Identifier | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 | Response Authenticator | 411 | | 412 | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Attributes ... 415 +-+-+-+-+-+-+-+-+-+-+-+-+- 417 Code 419 3 for Access-Reject. 421 Identifier 423 The Identifier field is a copy of the Identifier field of the 424 Access-Request which caused this Access-Reject. 426 Response Authenticator 428 The Response Authenticator value is calculated from the Access- 429 Request value, as described earlier. 431 Attributes 433 The Attribute field is variable in length, and contains a list of 434 zero or more Attributes. 436 4.4. Accounting-Request 438 Description 440 Accounting-Request packets are sent from a client (typically a 441 Network Access Server or its proxy) to a RADIUS accounting server, 442 and convey information used to provide accounting for a service 443 provided to a user. The client transmits a RADIUS packet with the 444 Code field set to 4 (Accounting-Request). 446 Upon receipt of an Accounting-Request, the server MUST transmit an 447 Accounting-Response reply if it successfully records the 448 accounting packet, and MUST NOT transmit any reply if it fails to 449 record the accounting packet. 451 Any attribute valid in a RADIUS Access-Request or Access-Accept 452 packet is valid in a RADIUS Accounting-Request packet, except that 453 the following attributes MUST NOT be present in an Accounting- 455 Yamanouchi, Ishikawa, Takahashi [Page 9] 456 Request: User-Password, CHAP-Password, Reply-Message, State. 457 Either NAS-IP-Address or NAS-Identifier MUST be present in a 458 RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- 459 Port-Type attribute or both unless the service does not involve a 460 port or the NAS does not distinguish among its ports. 462 A summary of the Accounting-Request packet format is shown below. 463 The fields are transmitted from left to right. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Code | Identifier | Length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 | Request Authenticator | 472 | | 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Attributes ... 476 +-+-+-+-+-+-+-+-+-+-+-+-+- 478 Code 480 4 for Accounting-Request. 482 Identifier 484 The Identifier field MUST be changed whenever the content of the 485 Attributes field changes, and whenever a valid reply has been 486 received for a previous request. For retransmissions where the 487 contents are identical, the Identifier MUST remain unchanged. 489 Request Authenticator 491 The Request Authenticator of an Accounting-Request contains a 16- 492 octet MD5 hash value calculated according to the method described 493 in "Request Authenticator" above. 495 Attributes 497 The Attributes field is variable in length, and contains a list of 498 Attributes. 500 4.5. Accounting-Response 502 Description 504 Accounting-Response packets are sent by the RADIUS accounting 505 server to the client to acknowledge that the Accounting-Request 506 has been received and recorded successfully. If the Accounting- 507 Request was recorded successfully then the RADIUS accounting 508 server MUST transmit a packet with the Code field set to 5 509 (Accounting-Response). On reception of an Accounting-Response by 510 the client, the Identifier field is matched with a pending 511 Accounting-Request. Invalid packets are silently discarded. 513 A RADIUS Accounting-Response is not required to have any 514 attributes in it. 516 A summary of the Accounting-Response packet format is shown below. 517 The fields are transmitted from left to right. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Code | Identifier | Length | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 | Response Authenticator | 526 | | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Attributes ... 530 +-+-+-+-+-+-+-+-+-+-+-+-+- 532 Code 534 5 for Accounting-Response. 536 Identifier 538 The Identifier field is a copy of the Identifier field of the 539 Accounting-Request which caused this Accounting-Response. 541 Response Authenticator 543 The Response Authenticator of an Accounting-Response contains a 544 16-octet MD5 hash value calculated according to the method 545 described in "Response Authenticator" above. 547 Attributes 549 The Attributes field is variable in length, and contains a list of 550 zero or more Attributes. 552 5. Attributes 554 This section is the same as that of RADIUS and RADIUS accounting 555 documents except for the items described below. 557 A summary of the Attribute format is shown below. The fields are 558 transmitted from left to right. 560 0 1 2 561 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 563 | Type | Length | Value ... 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 566 Type 568 The Type field is one octet. Up-to-date values of the RADIUS Type 569 field are specified in the most recent "Assigned Numbers" RFC. 570 Values 192-223 are reserved for experimental use, values 224-240 571 are reserved for implementation-specific use, and values 241-255 572 are reserved and should not be used. The multicast user 573 authentication specification concerns the following values: 575 1 User-Name 576 3 CHAP-Password 577 4 NAS-IP-Address 578 6 Service-Type 579 18 Reply-Message 580 26 Vendor-Specific ? 581 40 Acct-Status-Type 582 44 Acct-Session-Id 584 Length 586 The Length field is one octet, and indicates the length of this 587 Attribute including the Type, Length and Value fields. If an 588 Attribute is received in an Access-Request but with an invalid 589 Length, an Access-Reject SHOULD be transmitted. If an Attribute 590 is received in an Access-Accept, Access-Reject or Access-Challenge 591 packet with an invalid length, the packet MUST either be treated 592 an Access-Reject or else silently discarded. If an attribute is 593 received in an Accounting-Request with an invalid Length, the 594 entire request should be silently discarded. 596 Value 598 The Value field is zero or more octets and contains information 599 specific to the Attribute. The format and length of the Value 600 field is determined by the Type and Length fields. 602 Note that a "string" in RADIUS does not require termination by an 603 ASCII NUL because the Attribute already has a length field. 605 The format of the value field is one of four data types. 607 string 0-253 octets 608 address 32 bit value, most significant octet first. 610 integer 32 bit value, most significant octet first. 612 time 32 bit value, most significant octet first -- seconds 613 since 00:00:00 GMT, January 1, 1970. The standard 614 Attributes do not use this data type but it is presented 615 here for possible use within Vendor-Specific attributes. 617 5.1. User-Name 619 Description 621 This Attribute indicates the name of the user to be authenticated. 622 It is only used in Access-Request packets. 624 A summary of the User-Name Attribute format is shown below. The 625 fields are transmitted from left to right. 627 0 1 2 628 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 630 | Type | Length | String ... 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 633 Type 635 1 for User-Name. 637 Length 639 >= 3 641 String 643 The String field is one or more octets. The NAS may limit the 644 maximum length of the User-Name but the ability to handle at least 645 63 octets is recommended. 647 5.2. CHAP-Password 649 Description 651 This Attribute indicates the response value provided by a PPP 652 Challenge-Handshake Authentication Protocol (CHAP) user in 653 response to the challenge. It is only used in Access-Request 654 packets. 656 The CHAP challenge value is found in the CHAP-Challenge Attribute 657 (60) if present in the packet, otherwise in the Request 658 Authenticator field. 660 A summary of the CHAP-Password Attribute format is shown below. The 661 fields are transmitted from left to right. 663 0 1 2 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 666 | Type | Length | CHAP Ident | String ... 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 669 Type 671 3 for CHAP-Password. 673 Length 675 19 677 CHAP Ident 679 This field is one octet, and contains the CHAP Identifier from the 680 user's CHAP Response. 682 String 684 The String field is 16 octets, and contains the CHAP Response from 685 the user. 687 5.3. NAS-IP-Address 689 Description 691 This Attribute indicates the identifying IP Address of the NAS 692 which is requesting authentication of the user. It is only used 693 in Access-Request packets. Either NAS-IP-Address or NAS- 694 Identifier SHOULD be present in an Access-Request packet. 696 A summary of the NAS-IP-Address Attribute format is shown below. The 697 fields are transmitted from left to right. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Type | Length | Address 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Address (cont) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Type 708 4 for NAS-IP-Address. 710 Length 712 6 714 Address 716 The Address field is four octets. 718 5.4. Service-Type 720 Description 722 This Attribute indicates the type of service the user has 723 requested, or the type of service to be provided. It MAY be used 724 in both Access-Request and Access-Accept packets. A NAS is not 725 required to implement all of these service types, and MUST treat 726 unknown or unsupported Service-Types as though an Access-Reject 727 had been received instead. 729 A summary of the Service-Type Attribute format is shown below. The 730 fields are transmitted from left to right. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Type | Length | Value 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Value (cont) | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Type 742 6 for Service-Type. 744 Length 746 6 748 Value 750 The Value field is four octets. 752 10 Mcast-Sender 753 11 Mcast-Receiver 755 The service types designate the kind of services the user would 756 like to receive. In the original RADIUS they are used to indicate 757 the services the NAS should provide to the user, and if used in an 758 Access- Accept, they should be considered to be a hint to the 759 RADIUS server that the NAS has reason to believe the user would 760 prefer the kind of service indicated. 762 Mcast-Sender The user would like to be authenticated as 763 a multicast sender. 765 Mcast-Receiver The user would like to be authenticated as 766 a multicast receiver. 768 5.5. Reply-Message 770 Description 772 This Attribute indicates text which MAY be displayed to the user. 774 When used in an Access-Accept, it is the success message. 776 When used in an Access-Reject, it is the failure message. It MAY 777 indicate a dialog message to prompt the user before another 778 Access-Request attempt. 780 Multiple Reply-Message's MAY be included and if any are displayed, 781 they MUST be displayed in the same order as they appear in the 782 packet. 784 A summary of the Reply-Message Attribute format is shown below. The 785 fields are transmitted from left to right. 787 0 1 2 788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 790 | Type | Length | String ... 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 793 Type 795 18 for Reply-Message. 797 Length 799 >= 3 801 String 803 The String field is one or more octets, and its contents are 804 implementation dependent. It is intended to be human readable, 805 and MUST NOT affect operation of the protocol. It is recommended 806 that the message contain displayable ASCII characters from the 807 range 10, 13, and 32 through 126 decimal. Mechanisms for 808 extension to other character sets are beyond the scope of this 809 specification. 811 5.6. Vendor-Specific 813 Description 815 This Attribute is available to allow vendors to support their own 816 extended Attributes not suitable for general usage. It MUST not 817 affect the operation of the RADIUS protocol. 819 Servers not equipped to interpret the vendor-specific information 820 sent by a client MUST ignore it (although it may be reported). 821 Clients which do not receive desired vendor-specific information 822 SHOULD make an attempt to operate without it, although they may do 823 so (and report they are doing so) in a degraded mode. 825 A summary of the Vendor-Specific Attribute format is shown below. 826 The fields are transmitted from left to right. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | Vendor-Id 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Vendor-Id (cont) | String... 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 836 Type 838 26 for Vendor-Specific. 840 Length 842 >= 7 844 Vendor-Id 846 The high-order octet is 0 and the low-order 3 octets are the SMI 847 Network Management Private Enterprise Code of the Vendor in 848 network byte order, as defined in the Assigned Numbers RFC. 850 String 852 The String field is one or more octets. The actual format of the 853 information is site or application specific, and a robust 854 implementation SHOULD support the field as undistinguished octets. 856 The codification of the range of allowed usage of this field is 857 outside the scope of this specification. 859 It SHOULD be encoded as a sequence of vendor type / vendor length 860 / value fields, as follows. The Attribute-Specific field is 861 dependent on the vendor's definition of that attribute. An 862 example encoding of the Vendor-Specific attribute using this 863 method follows: 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Type | Length | Vendor-Id 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 Vendor-Id (cont) | Vendor type | Vendor length | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Attribute-Specific... 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 875 5.7. Acct-Status-Type 877 Description 879 This attribute indicates whether this Accounting-Request marks the 880 beginning of the user service (Start) or the end (Stop). 882 It MAY be used by the client to mark the start of accounting (for 883 example, upon booting) by specifying Accounting-On and to mark the 884 end of accounting (for example, just before a scheduled reboot) by 885 specifying Accounting-Off. 887 A summary of the Acct-Status-Type attribute format is shown below. 888 The fields are transmitted from left to right. 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Type | Length | Value 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 Value (cont) | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 Type 900 40 for Acct-Status-Type. 902 Length 904 6 906 Value 908 The Value field is four octets. 910 1 Start 911 2 Stop 912 7 Accounting-On 913 8 Accounting-Off 915 5.8. Acct-Session-Id 917 Description 919 This attribute is a unique Accounting ID to make it easy to match 920 start and stop records in a log file. The start and stop records 921 for a given session MUST have the same Acct-Session-Id. It is 922 strongly recommended that the Acct-Session-Id be a printable ASCII 923 string. 925 For example, one implementation uses a string with an 8-digit 926 upper case hexadecimal number, the first two digits increment on 927 each reboot (wrapping every 256 reboots) and the next 6 digits 928 counting from 0 for the first person logging in after a reboot up 929 to 2^24-1, about 16 million. Other encodings are possible. 931 A summary of the Acct-Session-Id attribute format is shown below. 932 The fields are transmitted from left to right. 934 0 1 2 935 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Type | Length | String ... 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 Type 942 44 for Acct-Session-Id. 944 Length 946 >= 3 948 String 950 The String field SHOULD be a string of printable ASCII characters. 952 5.9. Mcast-Group-Address 954 Description 956 This attribute indicates the multicast group IP address (class-D 957 address) on which the routing is to be authenticated. This 958 attribute is passed from the router for per-service authentication 959 purpose. 961 A summary of the Mcast-Group-Address attribute format is shown below. 962 The fields are transmitted from left to right. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Length | Address 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Address (cont) | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Type 974 90 for Mcast-Group-Address 976 Length 978 6 980 Address 982 The Address field is four octets. 984 5.10. Validity-Period 986 Description 988 This attribute indicates the length of the time period in which 989 the authentication is valid. The authentication expires after the 990 period designated in this attribute, and the NAS router initiates 991 a re-authentication process of the user terminal. 993 A summary of the Mcast-Group-Address attribute format is shown below. 994 The fields are transmitted from left to right. 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Type | Length | Value 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 Value (cont) | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Type 1006 93 for Validity-Period 1008 Length 1010 6 1012 Value 1014 The Value field is four octets in the unit of seconds. 1016 5.11. LAN-IP-Address 1018 Description 1020 This attribute indicates the IP address of the LAN adapter where 1021 the user terminal is connected to. This attribute is used only 1022 for LAN-connected terminals. It is passed from the router to the 1023 multicast user authentication server so that the server stores it 1024 in association with the terminal entry. It will be used to find 1025 out all the terminals connected to the LAN which failed in 1026 re-authentication. 1028 A summary of the LAN-IP-Address attribute format is shown below. The 1029 fields are transmitted from left to right. 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length | Address 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Address (cont) | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Type 1041 91 for LAN-IP-Address 1043 Length 1045 6 1047 Address 1049 The Address field is four octets. 1051 5.12. LAN-NetMask 1053 Description 1055 This attribute indicates the NetMask value of the LAN where the 1056 terminal is connected to. This attribute is used only for 1057 LAN-connected terminals. It is passed from the router to the 1058 multicast user authentication server so that the server stores it 1059 in association with the terminal entry. It will be used to find 1060 out all the terminals connected to the LAN which failed in 1061 re-authentication. 1063 A summary of the LAN-NetMask attribute format is shown below. The 1064 fields are transmitted from left to right. 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type | Length | Address 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 Address (cont) | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Type 1076 92 for LAN-NetMask 1078 Length 1080 6 1082 Address 1084 The Address field is four octets. 1086 5.13. Table of Attributes 1088 The following table provides a guide to which attributes may be found 1089 in which kinds of packets, and in what quantity. 1091 Request Accept Reject AcctReq Acct-Resp # Attribute 1092 1 0 0 0 0 1 User-Name 1093 1 0 0 0 0 3 CHAP-Password 1094 1 0 0 0 0 4 NAS-IP-Address 1095 1 0 0 0 0 6 Service-Type 1096 0 0+ 0+ 0+ 0 18 Reply-Message 1097 0+ 0+ 0 0+ 0 26 Vendor-Specific 1098 0 0 0 1 0 40 Acct-Status-Type 1099 0 0 0 1 0 44 Acct-Session-ID 1100 1 0 0 0 0 Mcast-Group- 1101 Address 1102 0 1 0 0 0 Validity-Period 1103 0+ 0 0 0 0 LAN-IP-Address 1104 0+ 0 0 0 0 LAN-NetMask 1106 Request Accept Reject AcctReq Acct-Resp # Attribute 1107 The following table defines the meaning of the above table entries. 1109 0 This attribute MUST NOT be present in packet. 1110 0+ Zero or more instances of this attribute MAY be present in packet. 1111 0-1 Zero or one instance of this attribute MAY be present in packet. 1112 1 Exactly one instance of this attribute MUST be present in packet. 1114 6. Examples 1116 A few examples are presented in Appendix A to illustrate the flow of 1117 packets and use of typical attributes. These examples are not 1118 intended to be exhaustive, many others are possible. 1120 7. Issues 1122 1) There is a controversy about whether the multicast authentication 1123 should be a part of RADIUS service or a separate service. This 1124 document follows the idea of the same RADIUS server to serve as a 1125 multicast authentication server, but it would also be possible to 1126 have a totally separate server for multicast authentication. This 1127 difference affects the port number assignment of the server. Other 1128 protocol definitions will not change. 1130 2) The idea of separating the authentication transaction and the 1131 accounting transaction is controversial. In the multicast 1132 authentication case the accounting transaction described in this memo 1133 is intended to keep track of the joined terminals, which actually can 1134 be traced by looking at the authentication transactions. A merit of 1135 avoiding separate accounting transaction is that it would reduce the 1136 risk of inappropriate logging caused by any interruption between the 1137 authentication and accounting transactions. 1139 Security Considerations 1141 Security issues are the primary topic of this document. 1143 References 1145 [1] Ishikawa, N. et al, "Security Extensions for IGMP Version 2" 1147 [2] Fenner, W., "Internet Group Management Protocol, Version 2", 1148 RFC 2236, November 1997. 1150 [3] Rigney, C. et al, "Remote Authentication Dial In User 1151 Service (RADIUS)", RFC 2138, April 1997. 1153 [4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 1155 [5] Rivest, R. and Dusse, S., "The MD5 Message-Digest Algorithm", 1156 RFC 1321, April 1992. 1158 Author's Addresses 1160 Nagatsugu Yamanouchi 1161 yamanouc@trl.ibm.co.jp 1162 IBM Research, Tokyo Research Laboratory 1163 IBM Japan 1164 1623-14 Shimotsuruma, Yamato-shi, Kanagawa 242 Japan 1166 Norihiro Ishikawa 1167 isic@isl.ntt.co.jp 1168 NTT Information and Communication Systems Laboratories 1169 1-1 Hikarinooka, Yokosuka, Kanagawa 239 Japan 1171 Osamu Takahashi 1172 osamu@isl.ntt.co.jp 1173 NTT Information and Communication Systems Laboratories 1174 1-1 Hikarinooka, Yokosuka, Kanagawa 239 Japan 1176 Appendix A. 1178 A.1 Introduction 1180 Background 1182 In short, the INGRESS router get authentication about multicast 1183 routing setup from the network administrator in order for the 1184 administrator to gain control over multicast routing. This allows 1185 receiver authentication of mcast routing. This mechanism is defined 1186 in [1] as an extension of IGMP functions. 1188 The authentication information may be centrally maintained at a RADIUS 1189 server by employing the RADIUS mechanism, so that the network 1190 administrator need not maintain the user authentication information 1191 database in many INGRESS routers. 1193 A similar authentication to the mcast sender is useful to avoid 1194 uncontrolled mcast transmission. 1196 At the same time, the centralized RADIUS server(s) may keep track of 1197 the terminal information in order to measure subscription. This 1198 subscription information may be used to estimate the number of 1199 audience of the program, the number of multicast subscribers, and 1200 possibly traffic bandwidth. 1202 These authentication and subscriber measurement may be implemented by 1203 extending the RADIUS interface framework [2], [3]. 1205 Additional Technical Considerations 1207 Keeping track of terminals require additional considerations to the 1208 multicast-routing authentication proposed in [1]. In the case of 1209 (shared media) LAN-connected terminals the router only controls mcast 1210 routing to the LAN. The delivery control to a specific terminal is 1211 implemented by the broadcast mechanism of the underlying LAN. This 1212 implies that the mcast authentication can neither control data 1213 delivery nor maintain the terminal/subscriber information in the case 1214 of LAN-connected terminals. 1216 The mechanism in [1] forces all terminals on the LAN to obtain 1217 authentication even if the router opens up the mcast route to the LAN 1218 by the first requesting terminal. This operational rule allows the 1219 router to register the terminal as a subscriber. An additional 1220 consideration is necessary for unsubscribing. [1] forces terminals to 1221 issue IGMP LEAVE (IGMP v2) at leaving from subscription, and the 1222 router recognizes the status change of the terminal. Only the garbage 1223 cleanup, i.e., the terminals that have left without LEAVE notification 1224 for such reasons as system crash, requires an additional 1225 consideration. 1227 A similar garbage cleanup operation is needed in mcast routing 1228 control, and the subscription measurement mechanism cleans the garbage 1229 by using this operation as a trigger. An additional interface to 1230 RADIUS is used to pass information necessary for the cleanup. Such a 1231 cleanup operation is invoked by a failure of a terminal 1232 re-authentication, which provides the ID of the failed terminal. The 1233 RADIUS server maintains a table of tuples 1234 so that it can extract the key for cleanup, (router, LAN_ID). Those 1235 terminals that share the same (router, LAN_ID) key are to be cleaned 1236 up. Note that LAN_ID here is used to determine the LAN in the case 1237 where two or more LANs are connected to the router. LAN_ID is 1238 identified by the IP address assigned to the LAN adapter in the 1239 router, plus the netmask. 1241 A.2 Receiver JOIN Authentication Process 1243 The authentication process is summarized as follows: 1245 Terminal -Membership Report-> Router 1246 (UserID) Router generates 1247 a challenge(16B). 1248 Terminal <------Challenge---- Router 1249 (Challenge, UserID) 1250 Terminal ---User Response---> Router ----Access-Request----> RADIUS 1251 (Response, UserID) (UserID, McastAddr, 1252 Challenge, Response) 1253 Terminal <-------Success----- Router <---Access-Accept------ RADIUS 1254 (Validity Period) (Validity Period) 1256 In addition to the authentication above, the following process is 1257 added to maintain the subscriber list in the RADIUS server. This 1258 process uses RADIUS Accounting (RFC2139) functions. 1260 Router ----AcctStatus Start--> RADIUS 1261 (User ID, McastAddr, 1262 LAN-IP-Addr, LAN-NetMask) 1263 Router <---------OK----------- RADIUS 1264 (OK) 1266 We expect that the terminal issues IGMP-Leave when leaving from the 1267 multicast service. At the time of Leave, the router notifies the 1268 RADIUS server the termination of the receiver by RADIUS Accounting 1269 Status Stop command. 1271 A.3 Detailed Receiver Authentication Process 1273 Following scenarios are the detailed transactions for multicast 1274 receiver authentication. 1276 Router Initialization Process 1277 Router ----AcctStatus ON----> RADIUS 1278 Transaction ID(assigned by Router) 1279 Radius Code(4)(Accting Request) 1280 Acct-Status-Type Acct ON(7) 1281 Acct-SessionID(assigned by Router) 1282 NAS-IP-Address (Router IP address) 1283 Router <-----------OK-------- RADIUS 1284 Transaction ID 1285 Radius Code(6)(Accting Response) 1287 Receiver JOIN Process 1288 Terminal--Membership Request-->Router 1289 (UserID, mcast Address) 1290 (UserID) Router generates 1291 a challenge(16B). 1292 Terminal <------Challenge----- Router 1293 (Challenge, UserID) 1294 Terminal ----User Response---> Router ----Access-Request---> RADIUS 1295 (Challenge Response, UserID) 1296 Transaction ID(assigned by Router) 1297 Radius Code(1)(Access Request) 1298 Request Authenticator (Challenge) 1299 User-Name (UserID) 1300 CHAP-Password(CHAPID+UserResponse) 1301 NAS-IP-Address (Router IP address) 1302 Service-Type Mcast-Receiver(11) 1303 Mcast-Group-Address 4-octets 1305 RADIUS Server authenticates by 1306 UserID,Challenge,User Response 1308 Terminal <------Success------- Router <-----Access-Accept-- RADIUS 1309 Transaction ID 1310 Radius Code(2) (Access Accept) 1311 Validity-Period 4-octets(seconds) 1312 (Validity Period) 1313 Router ---AcctStatus Start--> RADIUS 1314 Transaction ID(assigned by Router) 1315 Radius Code(4)(Accting Request) 1316 Acct-Status-Type Start(1) 1317 Acct-Session-ID 1318 User-Name (User ID) 1319 NAS-IP-Address (Router IP address) 1320 Service-Type Mcast-Receiver(11) 1321 Mcast-Group-Address 4-octets 1322 Only for LAN-connected receivers: 1323 LAN-IP-Address 4-octets 1324 LAN-NetMask 4-octets 1325 Router <---------OK---------- RADIUS 1326 Transaction ID 1327 Radius Code(6)(Accting Response) 1329 Authentication failure case: 1331 Terminal <-------Fail--------- Router <----Access-Accept---- RADIUS 1332 Transaction ID 1333 Radius Code(3) (Access Reject) 1335 Receiver Leave Process 1337 Terminal ----Leave Request---> Router 1338 (UserID, mcast Address) 1339 Router ---AcctStatus Stop---> RADIUS 1340 Transaction ID(assigned by Router) 1341 Radius Code(4)(Accting Request) 1342 Acct-Status-Type Stop(2) 1343 Acct-Session-ID 1344 User-Name (UserID) 1345 NAS-IP-Address (Router IP address) 1346 Service-Type Mcast-Receiver(11) 1347 Mcast-Group-Address 4-octets 1348 Only for LAN connected receivers: 1349 LAN-IP-Address 4-octets 1350 LAN-NetMask 4-octets 1351 Router <----------OK----------RADIUS 1352 Transaction ID 1353 Radius Code(6) (Accting Response) 1355 Receiver Re-Authentication Process 1357 Terminal <-Grp Specific Query- Router 1358 Terminal -Membership Request-> Router 1359 Terminal <------Challenge----- Router 1360 Terminal ----User Response---> Router ----Access-Request---> RADIUS 1361 Terminal <------Success------- Router <----Access-Accept---- RADIUS 1362 Router ---AcctStatus Start--> RADIUS 1363 Router <----------OK--------- RADIUS 1365 Receiver Re-Authentication Failure Process 1366 Terminal <-Grp Specific Query- Router 1367 (NO RESPONSE) 1368 Router ---AcctStatus Stop---> RADIUS 1369 Transaction ID(assigned by Router) 1370 Radius Code(4)(Accting Request) 1371 Acct-Status-Type Stop(2) 1372 Acct-Session-ID 1373 User-Name (User ID) = "********" 1374 Wildcard to designate all. 1375 NAS-IP-Address(Router IP address) 1376 Service-Type Mcast-Receiver(11) 1377 Mcast-Group-Address 4-octets 1378 Only for LAN connected receivers: 1380 LAN-IP-Address 4-octets 1381 LAN-NetMask 4-octets 1382 Router <----------OK--------- RADIUS 1383 Transaction ID 1384 Radius Code(6)(Accting Response) 1386 Router Termination Process 1387 Router ----AcctStatus OFF---> RADIUS 1388 Transaction ID (assigned by Router) 1389 Radius Code(4)(Accting Request) 1390 Acct-Status-Type Acct OFF(8) 1391 Acct-SessionID (assigned by Router) 1392 NAS-IP-Address(Router IP address) 1393 Router <----------OK--------- RADIUS 1394 Radius Transaction ID 1395 Radius Code = 6 (Accounting Response) 1397 A.4 Detailed Sender Authentication Process 1399 Sender JOIN Process 1401 The interface to the RADIUS server is almost identical to that of 1402 receivers. 1404 Terminal -Membership Request-> Router 1405 Terminal <-------Challenge---- Router 1406 Terminal -----User Response--> Router ----Access-Request---> RADIUS 1407 Transaction ID (assigned by Router) 1408 Radius Code(1) (Access Request) 1409 Request Authenticator (Challenge) 1410 User-Name (User ID) 1411 CHAP-Password (CHAPID+UserResponse) 1412 NAS-IP-Address(Router IP address) 1413 Service-Type Mcast-Sender(10) 1414 Mcast-Group-Address 4-octets 1416 RADIUS Server authenticates by 1417 UserID,Challenge,User Response 1419 Terminal <------Success------- Router <----Access-Accept--- RADIUS 1420 Transaction ID 1421 Radius Code(2) (Access Accept) 1422 Validity-Period 4-octets(seconds) 1423 (Validity Period) 1425 Router ---AcctStatus Start--> RADIUS 1426 Transaction ID(assigned by Router) 1427 Radius Code(4) (Accting Request) 1428 Acct-Status-Type Start(1) 1429 Acct-Session-ID 1430 User-Name (User ID) 1431 NAS-IP-Address (Router IP address) 1432 Service-Type Mcast-Sender(10) 1433 Mcast-Group-Address 4-octets 1434 (*)LAN-based participation is not expected. 1436 Router <---------OK---------- RADIUS 1437 Transaction ID 1438 Radius Code(6) (Accting Response) 1440 Authentication failure case: 1441 Terminal <-------Fail--------- Router <----Access-Reject---- RADIUS 1442 Transaction ID 1443 Radius Code(3) (Access Reject) 1445 Receiver Leave Process 1447 Terminal ----Leave Request---> Router 1448 (User ID, mcast Address) 1449 Router ---AcctStatus Stop---> RADIUS 1450 TransactionID(assigned by Router) 1451 Radius Code(4)(Accting Request) 1452 Acct-Status-Type Stop(2) 1453 Acct-Session-ID 1454 User-Name (User ID) 1455 NAS-IP-Address(Router IP address) 1456 Service-Type Mcast-Sender (10) 1457 Mcast-Group-Address 4-octets 1459 Router <---------OK---------- RADIUS 1460 Transaction ID 1461 Radius Code(6) (Accting Response) 1463 Sender Re-Authentication Process 1465 Terminal <--one-to-one Query-- Router 1466 Terminal -Membership Request-> Router 1467 Terminal <------Challenge----- Router 1468 Terminal ----User Response---> Router ----Access-Request---> RADIUS 1469 Terminal <-------Success------ Router <----Access-Accept---- RADIUS 1470 Router ---AcctStatus Start--> RADIUS 1471 Router <----------OK--------- RADIUS 1473 Receiver Re-Authentication Failure Process 1474 Terminal <--one-to-one Query-- Router 1475 (NO RESPONSE) 1476 Router ---AcctStatus Stop--> RADIUS 1477 TransactionID (assigned by Router) 1478 Radius Code(4) (Accting Request) 1479 Acct-Status-Type Stop(2) 1480 Acct-Session-ID 1481 User-Name (User ID) 1482 (*)UserID recorded in the Router. 1483 NAS-IP-Address (Router IP address） 1484 Service-Type Mcast-Sender(10) 1485 Mcast-Group-Address 4-octets 1486 Router <----------OK--------- RADIUS 1487 Radius Transaction ID 1488 Radius Code(6) (Accting Response)