One document matched: draft-ietf-idmr-igmp-auth-00.txt
INTERNET-DRAFT Norihiro Ishikawa NTT
<draft-ietf-idmr-igmp-auth-00.txt> Nagatsugu Yamanouchi IBM
Expires: September 1998 Osamu Takahashi NTT
March 12, 1998
IGMP Extension for 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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The security enhancement is one of the most important enhancements
to IP multicast. There are no security functions in IGMP, version 2
(IGMPv2) [1]. 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. This document describes
the extensions to IGMPv2 for the authentication of sending and
receiving hosts which comply with IGMPv2.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 1]
INTERNET-DRAFT IGMP 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 at the experimental stage. In order to make
IP multicast a commercial service, many enhancements to IP multicast
are required. Among them, the security enhancement 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 regarding each host group.
This document describes the security extensions for IGMPv2.
2. Requirements
The requirements for the security functions of IP multicast are
described below.
(1) Group Membership Control: An Internet Service Provider (ISP) needs
to know who are the current sending and receiving hosts regarding
each host group, because of the various reasons (e.g. accounting and
network management). A sending host may request to know who are the
current receiving hosts regarding the host group.
(2) Authentication: An Internet Service Provider (ISP) needs to
authenticate sending and receiving hosts regarding each host group,
because of the various reasons (e.g. security and accounting).
A sending host may request to send IP multicast datagrams only to
receiving hosts that are authenticated.
(3) IP Multicast Routing Protocols: Various IP multicast routing
protocols such as DVMRP [2], PIM [3] and CBT [4] are being developed
within IETF. The security functions of IP multicast must not depend
on a specific IP multicast routing protocol.
NOTE: Other requirements on the security functions of IP Multicast
are for further study.
This document describes security extensions to IGMPv2, which satisfy
the above requirements.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 2]
INTERNET-DRAFT IGMP Authentication March, 1998
3. Architecture
The overall architecture for the security functions of IP multicast is
described below.
A sending host sends IP multicast datagrams to an ingress router in an
IP multicast network. IP multicast datagrams travel towards egress
routers through IP multicast routers within an IP multicast network.
An IP multicast routing is controlled by IP multicast routing
protocols such as DVMRP, PIM and CBT. An egress router sends IP
multicast datagrams to receiving hosts which join the host group.
This document describes the authentication functions of IP multicast,
using the Challenge-Response mechanism in a similar way as CHAP [5].
NOTE: Other mechanisms for the authentication functions of IP
Multicast are for further study.
An ingress router may optionally authenticate a sending host. When a
sending host wants to send IP multicast datagrams, it sends a Sender
Start message to an ingress router. When a ingress router receives a
Sender Start message, it sends a Challenge message to the sending
host which sent the Sender Start message. When a Challenge message is
received, a sending host sends a Response message to an ingress
router. When a Response message is received, an ingress router
compares the response value with the expected value for the
authentication of the sending host. Alternatively, an ingress router
may ask a RADIUS server to authenticate the sending host.
NOTE: The interaction between a multicast router and a RADIUS server
is described in Appendix A. The separate document [6] describes
the extensions to RADIUS [7] for the authentication of sending
and receiving hosts which comply with IGMPv2.
If the result of the authentication is successful, an ingress router
sends a Success message to a sending host. When a Success message is
received, a sending host starts to send IP multicast datagrams.
An egress router may optionally authenticate a receiving host. When a
receiving host wants to receive IP multicast datagrams, it sends a
Membership Report message to an egress router. When an egress router
receives a Membership Report message, it sends a Challenge message to
the receiving host which sent the Membership Report message. When a
Challenge message is received, a receiving host sends a Response
message to an egress router. When a Response message is received, an
egress router compares the response value with the expected value for
the authentication of the receiving host. Alternatively, an egress
router may ask a RADIUS server to authenticate the receiving host.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 3]
INTERNET-DRAFT IGMP Authentication March, 1998
If the result of the authentication is successful, an egress router
sends a Success message to a receiving host. When a Success message is
received, a receiving host starts to receive IP multicast datagrams.
There are two levels of multicast routers.
(1) Level 1: Unsecure Multicast Router
The multicast router complies with IGMPv2.
(2) Level 2: Secure Multicast Router
The multicast router complies with both IGMPv2 and this document.
All multicast routers in a subnetwork must be either secure or
unsecure. In other words, unsecure multicast routers and secure
multicast routers must not coexist in the same subnetwork.
4. Protocol Description
This section describes the mechanisms for the authentication functions
of IP multicast.
4.1 Procedures for Authentication of Sending Hosts
4.1.1 Operation of Sending hosts
When a sending host wants to send IP multicast datagrams, it sends a
Sender Start message to a multicast router. When [Retry Interval]
expires, a sending host resends a Sender Start message to a multicast
router, until a Challenge message is received, or [Retry Count]
expires.
When a Challenge message is received, A sending host sends a Response
message to a multicast router. When [Retry Interval] expires, a
sending host resends a Response message to a multicast router, until
a Success or Failure message is received, or [Retry Count] expires.
When a Success message is received, a sending host starts to send IP
multicast datagrams. When a Failure message is received, a sending
host is not allowed to send IP multicast datagrams.
After a sending host starts to send IP multicast datagrams, it may
receive a Challenge message. When a Challenge message is received,
a sending host sends a Response message to a multicast router. After a
sending host sends a Response message, it may receive the same
Challenge message. In this case, a sending host resends the same
Response message.
NOTE: This is the case where a Response message was lost.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 4]
INTERNET-DRAFT IGMP Authentication March, 1998
When [Retry Interval] expires, a sending host resends a Response
message to a multicast router, until a Success or Failure message is
received, or [Retry Count] expires.
When a Success message is received, a sending host can continue to
send IP multicast datagrams. When a Failure message is received, a
sending host stops to send IP multicast datagrams.
4.1.2 Operation of Multicast Routers
When a multicast router receives a Sender Start message, it sends a
Challenge message to the sending host which sent the Sender Start
message. After a multicast router sent the Challenge message, it may
receive the same Sender Start message. In this case, a multicast
router resends the same Challenge message.
NOTE: This is the case where a Challenge message was lost.
When a Response message is received, a multicast router compares the
response value with the expected value for the authentication of the
sending host. Alternatively, a multicast router may ask a RADIUS
server to authenticate the sending host.
If the result of the authentication is successful, a multicast router
sends a Success message to the sending host. If the result of the
authentication is not successful, a multicast router sends a Failure
message to the sending host. After a multicast router sent the Success
message, it may receive the same Response message. In this case, a
multicast router resends the same Success message.
NOTE: This is the case where a Success message was lost.
A multicast router manages a list of IP addresses of authenticated
sending hosts regarding each host group. When the authentication of
the sending host is successful, a multicast router adds its IP address
to the list.
When a multicast router receives an IP multicast datagram from a
sending host, it checks the source IP address of the received IP
multicast datagram. If the source IP address was registered in the
list of IP addresses of authenticated sending hosts, a multicast router
forwards the received IP multicast datagram. If the source IP address
was not registered in the list of IP addresses of authenticated sending
hosts, a multicast router silently discards the received IP multicast
datagram.
The [Validity Period] of the authentication of a sending host is set in
the authentication parameter of a Success message. If the [Validity
Period] expires, a multicast router may reauthenticate the sending host.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 5]
INTERNET-DRAFT IGMP Authentication March, 1998
When a multicast router reauthenticates the sending host, it sends a
Challenge message. When a [Retry Interval] expires, the multicast router
resends a Challenge message, until a Response message is received, or
[Retry Count] expires.
When a Response message is received, a multicast router compares the
response value with the expected value for the authentication of the
sending host. Alternatively, a multicast router may ask a RADIUS server
to authenticate the sending host.
If the result of the authentication is successful, a multicast router
sends a Success message to the sending host. If the result of the
authentication is not successful, a multicast router sends a Failure
message to the sending host. After a multicast router sent the Success
message, it may receive the same Response message. In this case, a
multicast router resends the same Success message.
NOTE: This is the case where a Success message was lost.
A multicast router deletes the IP address of a sending host from a
list of IP addresses of authenticated sending hosts, in the following
cases.
- When the [Validity Period] of the authentication of a sending host
expires, a multicast router does not want to reauthenticate the
sending host.
- The reauthentication of a sending host is not successful.
4.2 Procedures for Authentication of Receiving Hosts
4.2.1 Operation of Receiving Hosts
When a receiving host wants to receive IP multicast datagrams, it
sends a Membership Report message with an authentication parameter
to a multicast router. When [Retry Interval] expires, a receiving
host resends a Membership Report message to a multicast router,
until a Challenge message is received, or [Retry Count] expires.
When a Challenge message is received, a receiving host sends a
Response message to a multicast router. When [Retry Interval] expires,
a receiving host resends a Response message to a multicast router,
until a Success or Failure message is received, or [Retry Count]
expires.
When a Success message is received, a receiving host starts to receive
IP multicast datagrams. When a Failure message is received, a receiving
host is not allowed to receive IP multicast datagrams.
When a receiving host leaves the host group, it must send a Leave
message to a multicast router.
NOTE: The authentication procedure for a Leave message is for further
study.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 6]
INTERNET-DRAFT IGMP Authentication March, 1998
After a receiving host starts to receive IP multicast datagrams, it
may receive a Group-Specific Query message with a reason parameter
(reason = "reauthentication is required"). When a Group-Specific Query
message with a reason parameter (reason = "reauthentication is
required") is received, a receiving host sets a delay timer to a random
value selected from the range (0, Max Response Time) for the host group
being queried. Max Response Time is specified in the Group-Specific
Query message. If the receiving host receives another Membership Report
message with an authentication parameter while the timer is running, it
stops the timer for the host group and does not send a Membership
Report message with an authentication parameter, in order to suppress
duplicate Membership Report messages.
When the timer expires, the receiving host sends a Membership Report
message with an authentication parameter to a multicast router. When
[Retry Interval] expires, a receiving host resends a Membership Report
message to a multicast router, until a Challenge message is received,
or [Retry Count] expires.
When a Challenge message is received, a receiving host sends a Response
message to a multicast router. When [Retry Interval] expires, a
receiving host resends a Response message to a multicast router, until
a Success or Failure message is received, or [Retry Count] expires.
When a Success message is received, a receiving host can continue to
receive IP multicast datagrams. When a Failure message is received, a
sending host stops to receive IP multicast datagrams.
4.2.2 Operation of Multicast Routers
When a multicast router receives a Membership Report message with an
authentication parameter, it sends a Challenge message to the receiving
host which sent the Membership Report message. After a multicast router
sent the Challenge message, it may receive the same Membership Report
message. In this case, a multicast router resends the same Challenge
message.
NOTE: This is the case where a Challenge message was lost.
When a Response message is received, a multicast router compares the
response value with the expected value for the authentication of the
receiving host. Alternatively, a multicast router may ask a RADIUS
server to authenticate the receiving host.
If the result of the authentication is successful, a multicast router
sends a Success message to the receiving host. If the result of the
authentication is not successful, a multicast router sends a Failure
message to the receiving host. After a multicast router sent the
Success message, it may receive the same Response message. In this case,
a multicast router resends the same Success message.
NOTE: This is the case where a Success message was lost.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 7]
INTERNET-DRAFT IGMP Authentication March, 1998
A multicast router manages a list of group addresses of host groups
which have at least one authenticated receiving host for each of its
attached networks. When the authentication of the receiving host is
successful, a multicast router adds the address of the host group which
the receiving host wants to join to the list, unless the address is
already registered in the list.
The [Validity Period] of the authentication of a receiving host is set
in the authentication parameter of a Success message. If the [Validity
Period] expires, a multicast router may reauthenticate the receiving
host.
When a multicast router reauthenticates the receiving host, it sends a
Group-Specific Query message with a reason parameter ( reason =
"reauthentication is required"). The Group-Specific Query message has
the Max Response Time set to [Reauthentication Query Interval]. When a
[Reauthentication Query Interval] expires, the multicast router resends
the Group-Specific Query message, until a Membership Report message with
an authentication parameter is received, or a [Retry Count] expires.
When a multicast router receives a Membership Report message with an
authentication parameter, it sends a Challenge message to the receiving
host which sent the Membership Report message. After a multicast router
sent the Challenge message, it may receive the same Membership Report
message. In this case, a multicast router resends the same Challenge
message.
NOTE: This is the case where a Challenge message was lost.
When a Response message is received, a multicast router compares the
response value with the expected value for the authentication of the
receiving host. Alternatively, a multicast router may ask a RADIUS
server to authenticate the receiving host.
If the result of the authentication is successful, a multicast router
sends a Success message to the receiving host. If the result of the
authentication is not successful, a multicast router sends a Failure
message to the receiving host. When the result of the authentication
is not successful, the multicast router resends a Group-Specific Query
message with a reason parameter ( reason = "reauthentication is
required"), until the authentication succeeds, or [Retry Count] expires.
After a multicast router sent the Success message, it may receive the
same Response message. In this case, a multicast router resends the
same Success message.
NOTE: This is the case where a Success message was lost.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 8]
INTERNET-DRAFT IGMP Authentication March, 1998
A multicast router deletes the address of the host group from a list of
the addresses of host groups which have at least one authenticated
receiving host, in the following cases.
- When the [Validity Period] of the authentication of a receiving host
expires, a multicast router does not want to reauthenticate the
receiving host.
- The reauthentication of a receiving host is not successful.
- A multicast router finds that there are no local members for the
host group in accordance with IGMPv2.
When a multicast router receives a Membership Report message without an
authentication parameter, it silently discards the received Membership
Report message, if the group address set in the Membership Report
message is not registered in the list of the addresses of host groups
which have at least one authenticated receiving host.
NOTE: A multicast router receives a Membership Report message without
an authentication parameter as the response to a Membership
Query, in accordance with IGMPv2.
5. Compatibility with IGMPv2 Hosts
5.1 Compatibility with IGMPv2 Sending Hosts
A sending host which only complies with IGMPv2 sends IP multicast
datagrams without having any authentication procedures. In this case,
a multicast router which complies with this document silently discards
IP multicast datagrams received. A multicast router must be able to
manually register the address of a host group to the access control
list (i.e. the list of host group addresses to which an unauthenticated
host may send IP multicast datagrams) managed by the multicast router,
so that a sending host can send IP multicast datagrams to the host
group without having any authentication procedures.
5.2 Compatibility with IGMPv2 Receiving Hosts
A receiving host which only complies with IGMPv2 sends a Membership
Report message without having an authentication parameter. If there
exists at least one authenticated receiving host on the same subnetwork,
a multicast router treats this message as a valid Membership Report
message, and hence the receiving host starts to receive IP multicast
datagrams. If there exists no authenticated receiving host on the same
subnetwork, a multicast router silently discards this message, and hence
the receiving host can not receive IP multicast datagrams. A multicast
router must be able to manually register the address of a host group to
the access control list managed by the multicast router, so that a
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 9]
INTERNET-DRAFT IGMP Authentication March, 1998
receiving host can receive IP multicast datagrams sent to the host group
without having any authentication procedures. A multicast router treats
a Membership Report message without an authentication parameter as a
valid message, if its destination address (i.e. host group address) is
registered in the access control list.
6. Extensions to IGMPv2 Messages
The following messages and parameters are added to IGMPv2 for the
security extensions.
6.1 New Messages
The format of new messages is as follows.
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Max Resp Time | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) Type
The types of new messages are as follows:
0x21 = Sender Start
0x22 = Challenge
0x23 = Response
0x24 = Success
0x25 = Failure
(2) Max Response Time
The use of this field is same as specified in IGMPv2.
(3) Checksum
The use of this field is same as specified in IGMPv2.
(4) Group Address
In a Sender Start message, the address of the host group to which
a sending host wants to send IP multicast datagrams is set to the
group address field.
In a Challenge, Response, Success or Failure message, the group
address field is set to zero.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 10]
INTERNET-DRAFT IGMP Authentication March, 1998
6.2 Optional Parameters
The following optional parameters may be set following the fixed fields
of IGMP messages.
The format of the optional parameters is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option1 | Option2 | ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Thus, padding is added in the end, in order to complete them in 32-bit
boundary. The value of padding is zero.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Data Length | Option Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option Type: An 8-bit identifier of the option type
- Option Data Length: Length of the option data in octet (8 bits)
- Option Data: Data specific to each option with variable length
6.2.1 Optional Parameters for the Group-Specific Query Message
(1) Reason
This parameter specifies the reason why the Group-Specific Query
message is sent by a multicast router.
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+
Reason: This field is one octet (8 bits). This field specifies the
reason why the Group-Specific Query message is sent by a
multicast router.
1=a Leave Group message is received by a multicast router
2=a reauthentication is required
NOTE: If this parameter is omitted, Value 1 (a Leave Group message
is received) is assumed.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 11]
INTERNET-DRAFT IGMP Authentication March, 1998
6.2.2 Optional Parameters for the Version 2 Membership Report Message
and the Sender Start Message
(1) Authentication
This parameter of a Version 2 Membership Report message is used to
authenticate an user on a receiving host which wants to receive IP
multicast datagrams. This parameter of a Sender Start message is used
to authenticate an user on a sending host which wants to send IP
multicast datagrams.
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mechanism | Identifier | User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mechanism: An 8-bit identifier of the mechanism for the
authentication of a receiving or sending host.
1 = the authentication mechanism specified in this document
NOTE: Other authentication mechanisms are for further study.
Identifier: This field is one octet (8 bits). This field is used to
identify the sequence for the authentication of a
receiving or sending host. When a new authentication
starts, this field must be changed.
User-ID: The User-ID field is one or more octets representing the
identification of an user on a receiving or sending host
to be authenticated. An User-ID may be ASCII character
strings or an e-mail address of an user.
6.2.3 Optional Parameters for the Challenge Message and the Response
Message
(1) Authentication
This parameter of is used to authenticate an user on a receiving
host which wants to receive IP multicast datagrams and an user on a
sending host which wants to send IP multicast datagrams.
Option Type: 1
The format of the option data is as follows:
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 12]
INTERNET-DRAFT IGMP Authentication March, 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Value-Size | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier: This field is one octet (8 bits). When a Challenge
message is sent, this field must be copied from the
Identifier field of the preceding Version 2 Membership
Report or Sender Start message. When a Response message
is sent, this field must be copied from the Identifier
field of the preceding Challenge message.
Value-Size: This field is one octet and indicates the length of the
Value field.
Value: The Value field is one or more octets.
The Challenge Value is a variable stream of octets. Each
Challenge Value should be unique, since repetition of a
challenge value in conjunction with the same secret would
permit an attacker to reply with a previously intercepted
response. The Challenge Value must be changed each time a
Challenge message is sent. The length of the Challenge Value
depends upon the method used to generate the octets, and is
independent of the hash algorithm used.
The Response Value is the one-way hash calculated over a
stream of octets consisting of the Identifier, followed by
(concatenated with) the "secret", followed by (concatenated
with) the Challenge Value. The length of the Response Value
depends upon the hash algorithm used. MD5 [8] is used as the
hash algorithm. In the case of MD5, The length of the
Response Value is 16 octets.
The length of "secret" must be at least 1 octet. The "secret"
should be at least as large and unguessable as a well-chosen
password.
User-ID: The User-ID field is one or more octets representing the
identification of an user on a receiving or sending host
to be authenticated. An User-ID may be ASCII character
strings or an e-mail address of an user.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 13]
INTERNET-DRAFT IGMP Authentication March, 1998
6.2.4 Optional Parameters for the Success Message
(1) Authentication
This parameter is used to authenticate an user on a receiving host
which wants to receive IP multicast datagrams and an user on a
sending host which wants to send IP multicast datagrams.
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Validity-Period | Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identifier: This field is one octet (8 bits). When a Success or
Failure message is sent, this field must be copied from
the Identifier field of the preceding Response message.
Validity-Period: This field is four octets (32 bits). This field
specifies the period of the validity for the
authentication of an user on a receiving or sending
host in units of second. When a Success message is
sent, a multicast router specifies the validity
period for the authentication.
Message: The Message field is zero or more octets, and its contents
are implementation dependent. It is intended to be human
readable, and must not affect the operation of the protocol.
6.2.5 Optional Parameters for the Failure Message
(1) Authentication
This parameter is used to authenticate an user on a receiving host
which wants to receive IP multicast datagrams and an user on a
sending host which wants to send IP multicast datagrams.
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 14]
INTERNET-DRAFT IGMP Authentication March, 1998
Identifier: This field is one octet (8 bits). When a Success or
Failure message is sent, this field must be copied from
the Identifier field of the preceding Response message.
Message: The Message field is zero or more octets, and its contents
are implementation dependent. It is intended to be human
readable, and must not affect the operation of the protocol.
6.2.6 Optional Parameters for the Leave Group Message
(1) Authentication
This parameter is used to authenticate an user on a receiving host
which wants to receive IP multicast datagrams.
Option Type: 1
The format of the option data is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User-ID: The User-ID field is one or more octets representing the
identification of an user on a receiving host which was
authenticated when the receiving host joined the host
group. An User-ID may be ASCII character strings or an
e-mail address of an user.
7. List of Timers and Default Values
This document defines the following timers and their default values,
in addition to those defined in IGMPv2.
7.1 Retry Interval
The Retry Interval is the time between repetitions of a Sender Start
message, a Membership Report message, a Challenge message or a Response
message during the authentication phase. Default: 10 seconds ?.
7.2 Retry Count
The Retry Count is the number of Sender Start messages, Membership
Report messages, Group-Specific Query message, Challenge messages or
Response messages sent before the authentication procedure is abandoned.
Default: the Robustness Variable.
NOTE: The Robustness Variable is defined in IGMPv2.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 15]
INTERNET-DRAFT IGMP Authentication March, 1998
7.3 Validity Period
The Validity Period of the authentication of a sending or receiving host
sesage Destinations in a Success message.
7.4 Reauthentication Query Interval
The Reauthentication Query Interval is the Max Response Time set in a
Group-Specific Query message sent when the [Validity Period] of the
authentication of a receiving host expires. Default: 10 seconds ?.
8. Message Destinations
The destinations of messages defined in this document are summarized
below.
Message Type Destination
---------------- ---------------
Sender Start ALL-ROUTERS (224.0.0.2)
Challenge The sending host which sent a Sender Start
message, or the receiving host which sent a
Membership Report message with an
authentication parameter
Response The multicast router which sent a Challenge
message
Success The sending or receiving host which sent a
Response message
Failure The sending or receiving host which sent a
Response message
9. Security Considerations
This document describes the IGMPv2 extension for authentication.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 16]
INTERNET-DRAFT IGMP Authentication March, 1998
Appendix A. Interaction with the RADIUS Server
This appendix gives an outline of the interaction between a secure
multicast router and a RADIUS server. The detailed specifications of the
interaction between them are described in [6].
A.1 Interaction with the RADIUS Server for the Authentication of Sending
and Receiving Hosts
A.1.1 Interaction with the RADIUS Server for the Authentication of Sending
Hosts
When a multicast router receives a Response message from a sending host,
it sends an Access-Request message in RADIUS to a RADIUS server.
When the multicast router receives an Access-Accept message in RADIUS
from the RADIUS server, it sends a Success message to the sending host.
When the multicast router receives an Access-Reject message in RADIUS,
it sends a Failure message to the sending host.
A.1.2 Interaction with the RADIUS Server for the Authentication of Receiving
Hosts
When a multicast router receives a Response message from a receiving
host, it sends an Access-Request message in RADIUS to a RADIUS server.
When the multicast router receives an Access-Accept message in RADIUS
from the RADIUS server, it sends a Success message to the receiving host.
When the multicast router receives an Access-Reject message in RADIUS,
it sends a Failure message to the receiving host.
A.2 Interaction with the RADIUS Accounting Server for the Group Membership
Control of Receiving Hosts
A RADIUS accounting server [9] may be used for the group membership
control of receiving hosts.
The interaction between a multicast router and a RADIUS accounting
server is described below for the group membership control of receiving
hosts.
When the result of the authentication of a receiving host is successful,
a multicast router may send an Accounting-Request (start) message to a
RADIUS accounting server.
When the multicast router receives a Leave message from the receiving
host, it sends an Accounting-Request (stop) message to the RADIUS
accounting server, if it sent the Accounting-Request (start) message to
the RADIUS accounting server regarding the receiving host.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 17]
INTERNET-DRAFT IGMP Authentication March, 1998
Appendix B. Issues
B.1 Receiving Hosts on Shared Media Networks
Once one receiving host on a shred media network such as Ethernet is
is authenticated, a multicast router starts to send IP multicast
datagrams to the network. As a result, other receiving hosts on the
network can receive IP multicast datagrams, even if they are not
authenticated.
The most straightforward solution on this issue is the use of
encryption.
Encryption mechanisms for IP multicast are under development at the
IPsec WG. If Encryption mechanisms for IP multicast are standardized,
they could be integrated with the authentication mechanism
described in this document.
B.2 Granularity on Filtering of IP multicast Datagrams
An ingress router drops IP multicast datagrams sent from unauthenticated
sending hosts, based on only their source IP addresses, even if user-IDs
are used for authenticating sending hosts.
B.3 Quick detection of Sender Leave
When the reauthentication of a sending host fails, a multicast router
detects the leave of the sending host.
To detect the leave of a sending host more quickly, it is necessary to
define a new message (i.e. Sender Stop message). When a sending host stops
sending IP multicast datagrams, it sends a Sender Stop message to a
multicast router. When a multicast router receives a Sender Stop message
from a sending host, A multicast router detects the leave of a sending
host. This mechanism allows a multicast router to detect the leave of
a sending host more quickly.
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 18]
INTERNET-DRAFT IGMP Authentication March, 1998
References
[1] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236,
Xerox PARC, November 1997.
[2] D. Waitzman, C. Partridge, S. Deering, "Distance Vector Multicast
Routing Protocolモ, RFC 1075, November 1988.
[3] D. Estrin et al., "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specificationモ, RFC 2117, June 1997.
[4] A. Ballardie, "Core Based Tree (CBT version2) Multicast Routing:
Protocol Specificationモ, RFC 2189, September 1997.
[5] W. Simson, "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[6] N. Yamanouchi et al, "RADIUS Extension for Multicast Router
Authentication", Internet Draft, March 1998.
[7] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[8] R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[9] C. Rigney, "RADIUS Accounting", RFC 2139, Livingston, April 1997.
Acknowledgements
Authors' Address:
Norihiro Ishikawa
NTT Information and Communication Systems Laboratory
1-1 Hikarino-oka Yokosuka-Shi
Kanagawa 239 Japan
isic@isl.ntt.co.jp
+81 468 59 2434 (tel)
+81 468 59 3796 (fax)
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 19]
INTERNET-DRAFT IGMP Authentication March, 1998
Nagatsugu Yamanouchi
IBM Research, Tokyo Research Laboratory
IBM Japan, Ltd.
1623-14, Shimotsuruma, Yamato-shi,
Kanagawa 242, Japan
yamanouc@trl.ibm.co.jp
+81 462 73 5150 (tel)
+81 462 74 4282 (fax)
Osamu Takahashi
NTT Information and Communication Systems Laboratory
1-1 Hikarino-oka Yokosuka-Shi
Kanagawa 239 Japan
osamu@isl.ntt.co.jp
+81 468 59 2415 (tel)
+81 468 59 3796 (fax)
Ishikawa, Yamanouchi, Takahashi Expires September 1998 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 13:08:05 |