Internet Engineering Task Force Daisuke Andou, NTT INTERNET-DRAFT Takako Sato, NTT April, 2002 Tsunemasa Hayashi, NTT Expires: October, 2002 Akihiro Tanabe, NTT Kaori Izutsu, NTT Yoshinori Goto, NTT Yukikuni Nishida, NTT Wataru Inoue, NTT IGMP for user Authentication Protocol (IGAP) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo describes IGAP, which allows user IP user clients and IP routers or network access servers to verify whether they can participate in a multicast group they hope and transport some information about it. IGAP is derived from IGMPv2, which can make users join a multicast group, who has the claim to participate a multicast group in a service. It's important for service providers to protect their revenue source. 1. Introduction IGMP for user Authentication Protocol (IGAP) allows user clients to connect to network gateways for access-controlled multicast services. These gateways (such as routers and called "authGW" hereafter) have the ability to authenticate the user client's authority to join/leave a multicast group. The security functions offered by IGAP will Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 1] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 encourage the development of new commercial services. This memo describes only the operations between user client and authGW, and omits those about between authGW and authentication servers. 2. Aspects of IGAP IGAP is designed to transport the information for user authentication and accounting, based on IGMPv2 [IGMPv2], for IP Multicast services. IGAP basically adopts the IGMPv2 message format and extends it only slightly. Details not clearly specified in this document are taken to follow the IGMPv2 equivalents. For example, all IGAP messages described in this document are sent via IP TTL 1, and use the IP Router Alert option [IPRA] in their IP header as per the IGMPv2 requirements. IGAP messages are encapsulated in IP datagrams the same as IGMPv2, and the IP protocol number in the IP header is 2, the same as IGMPv2. Note that the value in the IGAP Type field in the header, which is also used by IGMPv2, differs from that of IGMPv2. User clients and routers can distinguish IGAP from IGMPv2 by this field. IGAP can support the use of any security/authentication system. As an example, the user authentication information can include encrypted user passwords. IGAP supports both PAP [PAP] and CHAP [CHAP] mechanisms. IGAP must be implemented on all user clients wishing to join a protected multicast service and all authGWs. AuthGWs support both IGMPv2 and IGAP. The processing of IGAP packets has no impact on the processing of IGMPv2 packets. 3. IGAP Header Format IGAP messages have the following format. 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 (bit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Max Resp Time | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Report Type | Reserved | CHAP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Account Size | Message Size | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | User Account | | | Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 2] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Upper 8 bytes of the header are equal to those of IGMPv2. This part is called "IGMPv2 compatible part". Lower 40 bytes are the fields that include new information defined in IGAP. Upper 2 bytes of this area, called the "IGAP standard part", are used by all IGAP packet types and carry Version, Report Type, Reserved, and CHAP ID field. Lower 38 bytes are used to carry the information needed for authentication and accounting. This part is called "IGAP optional part". Some IGAP header fields are not used in some processes. Note that IGAP messages may be longer than 48 bytes, especially future versions of IGAP. Any future IGAP implementation must recognize the first ten bytes. The IGAP checksum is always computed over the whole IP payload, not just the first 48 bytes. This chapter describes all of the fields. 3.1. Type Currently, there are three types of IGAP messages. 0x40 = IGAP Membership Report (IGAP Join) This type, sent from user client to authGW, is used to join a multicast group, and to reply to a IGAP Membership Query sent from authGW. Source address of IP header is IP address of the user client sending the packet, and destination address of IP header is desired Group Address. Other details basically follow those of IGMPv2 Membership report. 0x41 = IGAP Membership Query This type, sent from authGW to user client, asks for the current status of multicast packet reception and Group Address. As in IGMPv2, there are two sub-types: General Query and Group Specific Query. The destination address of the former is the all-system multicast group (224.0.0.1). For the latter, it's Group Address which user clients are now receiving. The features of these sub-types are same as per IGMPv2. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 3] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 0x42 = IGAP Leave Group This type, sent from user client to authGW, is used to leave a multicast group. The IP Header includes source address (IP address of the user client sending the packet), and destination address (224.0.0.2). Other details basically follow those of IGMPv2 Membership report. 3.2. Max Response Time The Max Response Time field is meaningful only for Membership Query messages (Type 0x41), and specifies the maximum allowed time before sending a response; the units are 0.1 seconds. In all other messages, it is set to zero by the sender and ignored by receivers. To prevent excessive burstiness of IGAP traffic on a subnet, the user clients on the subnet should choose a random delay time less than the Max Response Time, and send their Membership Report after this time. 3.3. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the whole IGAP message (the entire IP payload). This algorithm equals that of IGMPv2. 3.4. Group Address In a Membership Query message, the group address field is set to the group address being queried. In a Membership Report or Leave Group message, the group address field holds the IP multicast group address of interest or the group being left. 3.5. Version Version field is set to 0x10 as the value to identify IGAP packets. 3.6. Report Type Report Type field indicates the type of message transferred within the IGAP packet. Usage of this field is described in Chapter 4. In Type 0x40 (IGAP Join), there are four Report Types as follows. 0x01 : Basic Join 0x02 : PAP Join Authentication Request 0x03 : CHAP Join Challenge Request Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 4] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 0x04 : CHAP Join Response In Type 0x41 (IGAP Query), there are seven Report Types as follows. 0x21 : Basic Query 0x22 : User Specific Query 0x23 : CHAP Challenge 0x24 : Authentication Message 0x25 : Accounting Message 0x26 : Notification Message 0x27 : Error Message In Type 0x42 (IGAP Leave), there are four Report Types as follows. 0x41 : Basic Leave 0x42 : PAP Leave Authentication Request 0x43 : CHAP Leave Challenge Request 0x44 : CHAP Leave Response 3.7. Reserved This field is set to 0xff unless used in a service. 3.8. CHAP ID CHAP ID field is meaningful only when CHAP Authentication is used. AuthGW sets it when sending a CHAP Challenge packet to a user client. User client uses the value in this field in order to create the CHAP Response to reply to the CHAP Challenge. AuthGWs use the value of this field to check the correspondence between CHAP Response and CHAP Challenge. If this field is not used, it is set to the default value of 0x00. 3.9. Account Size This field indicates the size of User Account field in units of bytes. If this field is not used, it is set to the default value of 0x00. 3.10. Message Size This field indicates the size of Message field in units of bytes. If this field is not used, it is set to the default value of 0x00. 3.11. Reserved Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 5] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 This field is set to 0xff unless used in a service. 3.12. User Account This field indicates the user account to be authenticated. The size of this field is 16 bytes. If the size value occupies less than 16 bytes, the value is followed by 0xff. 3.13 Message This field is used according to Report Type. If this field is used for authentication, it carries user password. If CHAP is used, the password is encrypted. The size of this field is 16 bytes. If the value of the size of a message occupies less than 16 bytes, the value is followed by 0xff. 4. IGAP Packet Type IGAP Packet type is determined by the Report Type field. In the following descriptions, fields that are not specifically mentioned are assumed to be "unused". Regardless of the values in unused fields, authGWs should process the packet correctly. Chapter.3 provides details about the fields not shown in this chapter. 4.1. Basic Join Type : 0x40 Group Address : connected group address Report Type : 0x01 User Account : user ID Message : (unused) This packet type is used in the case which the join process does not require the authentication process. 4.2. PAP Join Authentication Request Type : 0x40 Group Address : connected group address Report Type : 0x02 User Account : user ID Message : user password (not encrypted) This packet type is used in the case which the join process require PAP authentication process. Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 6] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 4.3. CHAP Join Challenge Request Type : 0x40 Group Address : connected group address Report Type : 0x03 User Account : user ID Message : (unused) This packet type is used to initiate the challenge process for CHAP authentication. AuthGW received this packet issues CHAP Challenge packet described in Chapter 4.7. 4.4. CHAP Join Response Type : 0x40 Group Address : connected group address Report Type : 0x04 User Account : user ID Message : Response Value This packet type is used to respond to the CHAP Challenge issued by the authGW. The Response Value is determined from two parameters. One is the Challenge Value, which is in the CHAP Challenge packet, described in chapter 4.7. The other is the value calculated from the user password by MD5 [MD5]. 4.5. Basic Query This packet type is used in the case which authGW checks whether the user client(s) are receiving multicast traffic at regular intervals, and authGW confirms the user client's request to leave a multicast group. There are two sub-types of Basic Query, as described in section 3.1. In the case of General Query, i.e. destination address of IP header is the all-systems multicast group (224.0.0.1), it's called the General-and-Basic Query. In this sub-type, the value of Group Address field is set to zero. In the case of Group Specific Query, i.e. destination address of IP header is the desired group address, it's called the Group-Specific-and-Basic Query. In this sub-type, the value of Group Address field is equal to the value of the desired destination address. This packet type doesn't have to have IGAP optional part. 4.5.1. General-and-Basic Query Type : 0x41 Group Address : (set to zero) MaxRespTime : given value (default : 0x64) Report Type : 0x21 Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 7] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 IGAP optional part : (unused) 4.5.2. Group-Specific-and-Basic Query Type : 0x41 Group Address : connected group address MaxRespTime : given value (default : 0x64) Report Type : 0x21 IGAP optional part : (unused) 4.6. User-Specific Query This packet type is used on similar case of Basic Query, but this packet type has IGAP optional part, so authGW can identify the user(s) who is receiving a multicast packet, or leaving. There are also two sub-types as Basic Query. For General Query the first sub-type is called the General-and-User-Specific Query. In this sub-type, the value of Group Address field is set to zero. For Group Specific Query, the sub-type is called the Group-and-User-Specific Query. In this sub-type, the value of Group Address field is equal to the value of the desired destination address. 4.6.1. General-and-User-Specific Query Type : 0x41 Group Address : (set to zero) MaxRespTime : given value (default : 0x64) Report Type : 0x22 User Account : user ID Message : (unused) 4.6.2. Group-and-User-Specific Query Type : 0x41 Group Address : connected group address MaxRespTime : given value (default : 0x64) Report Type : 0x22 User Account : user ID Message : (unused) 4.7. CHAP Challenge Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x23 Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 8] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 User Account : user ID Message : Challenge Value This packet type is used in the case which authGW responds to CHAP Join Challenge Request from user client. AuthGW sends this packet to notify Challenge Value. User client received this packet issues CHAP Join Response packet described in Chapter 4.4. 4.8. Authentication Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x24 User Account : user ID Message : 0x11 (Authentication Success) or 0x21 (Authentication Reject) or other value (vendor specific) This packet type is used in the case which authGW provides information about the result of authentication. The Message field holds one of two values: either authentication succeed or authentication reject. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. Vendors may add their own specific values to the Message field, but the values used must not impact any other IGAP process. 4.9. Accounting Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x25 User Account : user ID Message : 0x11 (Accounting Start) or 0x21 (Accounting Stop) or other value (vendor specific) This packet type is used in the case which authGW provides information about accounting status. The Message field holds one of two values: one indicates the start of accounting, and the other indicates the termination of accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The same is true for the vendor-specified values. 4.10. Notification Message Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 9] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x26 User Account : user ID Message : vendor specific value This packet type is used in the case which authGW provides information about an correct status in IGAP process, except authentication and accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The value of Message field in this packet type isn't defined in this document. Vendors may add their own specific values to the Message field, but the values used must not impact any other IGAP process. 4.11. Error Message Type : 0x41 MaxRespTime : given value (default : 0x64) Group Address : connected group address Report Type : 0x27 User Account : user ID Message : vendor specific value This packet type is used in the case which authGW provides information about an error status in IGAP process, except authentication and accounting. The process adopted by the user client upon receiving this packet type is up to implementation, however, neither value must impact other IGAP process. The value of Message field in this packet type isn't defined in this document. The same is true for the vendor-specified values. 4.12. Basic Leave Type : 0x42 Group Address : connected group address Report Type : 0x41 User Account : user ID Message : (unused) This packet type is used in the case which the leave process does not require the authentication process. 4.13. PAP Leave Authentication Request Type : 0x42 Group Address : connected group address Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 10] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 Report Type : 0x42 User Account : user ID Message : user password (not encrypted) This packet type is used in the case which the leave process require PAP authentication process. 4.14. CHAP Leave Challenge Request Type : 0x42 Group Address : connected group address Report Type : 0x43 User Account : user ID Message : (unused) This packet type is used to initiate the challenge process for CHAP authentication. AuthGW received this packet issues CHAP Challenge packet described in Chapter 4.7. 4.15. CHAP Leave Response Type : 0x42 Group Address : connected group address Report Type : 0x44 User Account : user ID Message : Response Value This packet type is used to respond to the CHAP Challenge issued by the authGW. The algorithm used to calculate the Response value is the same method of CHAP Join Response. References [IGMPv2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, Xerox PARC, November 1997. [PAP] B.Lloyd, W. Simson, "PPP Authentication Protocols", RFC 1334, Octover, 1992. [CHAP] W. Simson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [IPRA] D. Katz, "IP Router Alert Option", RFC 2113, Cisco Systems, Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 11] Internet Draft draft-andou-igmp-auth-00.txt April, 2002 February 1997. [MD5] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RADIUS] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RADACCT] C. Rigney, "RADIUS Accounting", RFC 2866, Livingston, June 2000. Author's Addresses Daisuke Andou, Takako Satou, Akihiro Tanabe, Kaori Izutsu, Yoshinori Gotou NTT Access Network Service Systems Laboratories 1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan Phone : +81 43 211 2115 Email : {dandou, t-sato, atanabe, izutsu, goto}@ansl.ntt.co.jp Tsunemasa Hayashi NTT Network Innovation Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone : +81 468 59 8790 Email : hayashi@exa.onlab.ntt.co.jp Yukikuni Nishida, Wataru Inoue NTT Cyber Solutions Laboratories 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan Phone : +81 468 59 3496 Email : {nishida.yukikuni, inoue.wataru}@lab.ntt.co.jp Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 12]