A flexible framework for registration and key distribution for online distance education.

The power and utility of the Internet have been proven in many commercial, industrial, and corporate sectors. However, the effective application of the Internet in educational sectors is still being explored. Universities and commercial service providers must collaborate to offer distance education and teleteaching that can reach a wide audience. This requires a flexible and secure framework with regard to registration, certification, validation, and data distribution. Currently, few tools are available to fulfill these requirements. Therefore, a project was undertaken to develop an innovative approach that uses the existing multicast capabilities of the Internet to provide online distance education. This paper discusses a proposed framework and compares it with the existing Distributed Registration and Key Distribution (DiRK) model.

SECTION 1 -- INTRODUCTION

Recent developments in computer-supported communication systems have been enormous due to the tremendous advancements in Internet technology. The growing number of Internet applications has influenced the personal lives of people worldwide, and has led to increased numbers of users and of systems attached to the Internet. Extraordinary changes are taking place in communication systems because of the move from point-to-point communication to group communication using multicast transmission. Multicast transmission extends the broadcast concept of one-to-many by allowing the sending of one transmission to many users in a defined group, but not necessarily to all users in that group. This capability within networks is enabling these changes. There is little doubt that multicast communication will become the communication paradigm of all future networks, especially the Internet.

The Internet, which originally provided no support for group communication, now has an experimental network--the multicast backbone (MBone)--that includes some support. Initial work on multicast communications paved the way for group communication (Deering, 1989). Deering proposed class D addresses that could be integrated into the Internet protocol to enable group communication.

Many changes have since taken place to exploit the Internet for e-commerce applications. Using the multicast capabilities of the Internet in a secure manner for such applications requires efficient and flexible mechanisms. However, for applications such as online distance education, little effort has been made to provide a practical solution. The demand for quality education is increasing. Unfortunately, the services of universities are not made available to many who are underprivileged and/or located in very remote areas. Moreover, universities have high operating costs. It is imperative that they be able to deliver their services worldwide, at a nominal cost, and to a wide audience.

Using current technological advancements in the Internet, this is possible without sacrificing quality of education. Universities and commercial service providers must collaborate to offer distance education programs. To accomplish this, the enforcement of logical security mechanisms using a flexible framework is critical. Interconnected networks located in very remote areas can be used to connect Professors to Student sites, enabling these Professors to deliver University lectures. The multicast capabilities of the Internet can be exploited to enable only registered Students to participate in these lectures.

Existing MBone tools such as vat (visual audio tool), nv (network video), vic (video conferencing), and wb (white board) allow multicast conferences that are intended for very specific applications (Wittmann & Zitterbart, 2001). Currently, IP networks and some corporate ATM networks use multicast capabilities for their own applications. Universities could use commercial service providers to disseminate lecture materials to a wide audience. This requires a scalable multicast security framework that permits only registered members to use the services. The approach proposed requires only a multicast-capable router to support the underlying network. This paper proposes:

* A suitable framework for online distance education.

* A design for the modules and the corresponding protocol steps to enforce security.

Section 2 provides the problem description. Section 3 introduces the model and the notations used and discusses suitable protocol steps. Section 4 discusses the comparison of the existing DiRK with that of the proposed solution. Section 5 provides conclusions.

SECTION 2 -- PROBLEM DESCRIPTION

University lectures are typically held by registered Professors/lecturers and are attended by Students. In this context, the role of the University is two-fold (Oppliger & Albanese, 1996).

* The University must provide the platform or infrastructure that allows Professors and Students to interact, exchange views, and share materials.

* The University must also issue official and legally binding documents that certify the Students, evaluate their performance, and award degrees to eligible candidates.

This is the existing model traditionally followed by universities. Online distance education systems must be able to use the same model. To accomplish this, they must exploit the existing Internet multicast backbone architecture. To enable a wide audience to access distance education, the universities could use commercial service providers such as telecommunications, cable television, or satellite companies, or Internet service providers (ISPs).

The advantages of using commercial service providers are:

* Effective utilization of network service provider infrastructures for public service.

* Increased offerings by the providers, including coverage to remote locations.

* Enrollment of many Students in the same program/class, allowing universities to reach a wider audience.

* Flexibility by Students to choose the course, time, or module of lectures based on convenience and availability; this meets the requirements of a rural population.

To ensure the reliability of the service providers, universities should enter into a legal agreement with them. Service providers must be trusted third parties who can perform registration, access control, certification, validation, and key distribution on behalf of the University. The University may run many courses and Students may enroll in multiple courses simultaneously with some prerequisites. Each course is divided into various modules. A Professor may be in charge of many courses, and subsequently of many modules. At any particular time, however, that Professor will be participating in only one module. In the same way, Students may enroll in different courses, but take only one module at a time. Since the Internet has multicast capabilities, these capabilities could be exploited; the only problem to be addressed is security. Therefore, this problem could be addressed as a multicast security problem.

This multicast security problem has numerous aspects, many of which are still to be explored. (Moyer, Rao, & Rohatgi, 1999; Sandro & Hutchison, 2003; Wade, Song, Poovendran, & Liu, 2003).

SECTION 3 -- PROPOSED APPROACH

The multicast security problems are addressed in different ways (Eriksson, 1994; Moyer, Rao, & Rohatgi, 1999; Wade et al., 2003). The approaches adopted thus far are application dependent. Some adopt centralized approaches; some follow distributed approaches, depending on the characteristics and requirements of the problem. The proposed approach is innovative in that it follows a layering mechanism by adopting a different grouping of members.

Grouping Mechanism

The grouping mechanism differentiates between the major entities--Professor and Student. Generally, the University, along with the service provider, is responsible for access control, group management, and security management. The proposed approach follows a different approach. The elements of the system are arranged in three different layers, with the service provider and the University occupying the top two layers. The Professors are considered as static members and are arranged in the middle layer; the Students as dynamic members are arranged at the bottom layer. The static members are the sub-group heads. They are responsible for partial key control operations of the sub-group members. Figure 1 explains the grouping mechanism that is followed.

Initially, the University identifies a particular service provider and enters into a legal agreement. After adopting the formal authentication mechanisms, the University certifies the service provider. According to Eriksson, in any multicast security solution, there must be a secure delivery mechanism to distribute the data and keys. Because they are the permanent members of the multicast group for a particular module, the Professors occupy the core routing position of the distribution tree with the dynamic members occupying the leaf positions.

The Students are attached to a particular static member for a particular module. The proposed model uses the cryptographic capabilities of the communicating parties. It uses a public key cryptosystem that requires a public key to encrypt the entire message at the sender's side and a private key to decrypt it at the receiver's side. All Student requests are directed to the University authority through the static members. The service provider is considered as the central controller and is responsible for these functions. The controller has two components: registrar and key manager. Figure 2 explains the controller components. The registrar performs all the initial registration and authentication functions, including issuing tokens to eligible members. The registrar also classifies the members based on the details, and groups them under different layers. The key manager receives the membership join/leave requests for particular modules, generates keys, and distributes them to the members at the beginning of the session. The keys must be changed as the members of each module or session change over time. This is done to maintain the forward and backward security, which is a requirement of any security architecture (Moyer, Rao, & Rohatgi, 1999; Sandro & Hutchison, 2003; Wade, Song, Poovendran, & Liu, 2003).

[FIGURE 1 OMITTED]

[FIGURE 2 OMITTED]

Keys Used

Two keys are used in this protocol: the session keys and the sub-group keys. Session data is encrypted with the session key and each sub-group has a sub-group key. The sub-group key is issued to a member if it is a member of the sub-group. The grouping mechanism followed does not allow overlapping of sub-groups, as the members at a particular instance will be part of only one module. The central controller issues encryption keys to the static members to decrypt the session key and the static members issue the sub-group keys to the dynamic members. The dynamic members can decrypt the session key only with the help of the sub-group keys. This is done to enforce strict security. The sub-group key changes on a join/leave operation of any member.

Protocols

The system uses four protocols: course announcement, registration, validation, and certification. Table 1 shows the major notations used in the protocols.

The important points to be noted in the design are:

* The University could offer different courses.

* Each course could be associated with a fixed number of modules.

* Each module is covered in different sessions.

* A Professor may be in charge of various courses/modules.

* A Student with the necessary prerequisites may register for more than one course.

* The central controller performs registration, access control, validation, and certification in conjunction with the University and the Professor.

Course Announcement

Initially the University authenticates the service provider, recognizes the Professors who are qualified to conduct courses, and issues the identification numbers. The University advertises the courses offered. Each course consists of various modules. The session announcement message consists of lists of courses to be conducted and the modules covered, with the sponsor certificates issued. The University digitally signs the sponsor certificates and the message.

<Service provider id., [U.sub.i][much less than]SP[much greater than]> [k.sub.Ui.sup.-1].

<[U.sub.i] [much less than][P.sub.i][much greater than], prof.id> [k.sub.Ui.sup.-1].

<[C.sub.i], [M.sub.ij], {[U.sub.i] [much less than][M.sub.ij][much greater than]}>[k.sub.Ui.sup.-1].

Registration

Professors may be permanent entities who have already registered with the University. However, a Professor, Pi, who wishes to conduct a particular module, registers with the University. Pi randomly selects a key pair ([k.sub.Pi], [k.sub.Pi.sup.-1]) for the module, [M.sub.ij], and sends a registration request message, REG_REQ_AS_PROF. The registration request message includes the public key and the certificate issued to the Professor by the University. For authentication purposes and to ascertain the message origin, the message is digitally signed with the corresponding private key [k.sub.Pi.sup.-1]. The University sends a confirmation message. The messages exchanged during this phase are:

[P.sub.i] _ [U.sub.i] : REG_REQ_AS_PROF (<prof.id, [U.sub.i] [much less than][P.sub.i][much greater than], [M.sub.ij] >[k.sub.Pi.sup.-1]).

[U.sub.i] _ [P.sub.i] : REG_CONF_AS_PROF(<prof.id, [U.sub.i][much less than][M.sub.ij][much greater than]>[k.sub.Ui.sup.-1]).

If a Student, [S.sub.i], wants to register for a module, that Student also sends a registration request message, REG_REQ_AS_STUDENT, to the multicast channel associated with the lecture. A Student can register for a particular course only if he/she has fulfilled the prerequisites.

The registrar verifies this request and issues a token. Based on this, the University issues an admit message, which is the confirmation message.

[S.sub.i] _ [C.sub.i] : REG_REQ_AS_STUDENT (details).

[U.sub.i] _ [S.sub.i] : REG_CONF_AS_STUDENT (stud.id, [C.sub.i], [U.sub.i]<stud.id, [M.sub.ij]>)[k.sub.Ui.sup.-1].

The University sends the Students the details on the Professor of the particular module; it also sends the Professor a list of eligible Students for that module.

[U.sub.i] _ [S.sub.i] : (service provider id, prof.id, [M.sub.ij])[k.sub.Ui.sup.-1].

[U.sub.i] _ [P.sub.i] : ELIGIBLE_LIST (service provider id, stud.id, [M.sub.ij])[k.sub.Ui.sup.-1].

The Student establishes communication with the Professor in charge of the course through the service provider. The Professor delivers the modules through the selected service provider. Initially the Professor exchanges the sub-group key with the Student. The Professor can also verify the Student list when a request from a Student for message delivery is received. Generally, the key manager component of the controller handles the requests for keying and rekeying. The static members also have key management capabilities. The materials delivered to the Students are encrypted with the session key, which can be decrypted only with the sub-group key issued by the Professor, the sub-group head. Changing the sub-group key in a scalable manner provides for dynamic membership management. The method is very efficient because it only affects the sub-group.

Validation Protocol

Both the static and dynamic members periodically send a registration validation request message, REG_VAL, to the multicast channel that is associated with the session.

The validation messages include the registration certificates along with the timestamp, T, which is digitally signed by the University's private key.

[P.sub.i] _ [M.sub.ij] : REG_VAL(prof.id, [U.sub.i]<[P.sub.i], [M.sub.ij]>, {T}[U.sub.i.sup.-1]).

[S.sub.i] _ [M.sub.ij] : REG_VAL(stud.id, [U.sub.i]<[S.sub.i], [M.sub.ij]>, {T}[U.sub.i.sup.-1]).

Certification Protocol

Prior to taking the final examination, Student participants must get an attendance certificate from the Professor. The registration certificate issued to the Students is valid only for the life of a module. After the completion of the module, the Student is expected to apply for an attendance certificate, by sending an AC _ REQ.

[S.sub.i] _ [P.sub.i]: AC _ REQ(stud.id, [U.sub.i] <[S.sub.i], [M.sub.ij]>).

The registration certificate issued is stored and is verified by the Professor, if the Student has completed the requirements. The Professor sends a confirmation message AC _ CONF.

[P.sub.i] _ [S.sub.i]: AC _ CONF(stud.id).

After processing all attendance requests, the Professor, Pi, sends the University the list of eligible candidates with his/her digital signature.

[P.sub.i] _ [U.sub.i]: ELIGIBLE _ LIST(stud.id, [M.sub.ij])[k.sub.Pi.sup.-1].

SECTION 4 -- REVIEWS AND COMPARISON

The proposed approach is compared with that of the DiRK, as implemented by the University of Berne. DiRK uses four protocols. In the Oppliger approach, the service provider plays a major role in the certification and validation process. Moreover, the first registered service provider or the member performs most of the certification process; this could raise trust issues. It adapts a decentralized control that uses service providers. In the proposed approach, the message and communication control aspects are distributed between the service provider and the University. The Professors, the major course conductors, play a significant role in enforcing security, using partial key control operations. In any University or educational system, the Professors should be the trusted entities for evaluation and certification. Therefore, the proposed framework is more efficient and flexible when compared to the DiRK method. The double keying method followed enforces security more stringently. This double keying method can also be followed while issuing the certificates to the candidates who have completed courses. As far as key management is considered, the overhead is reasonable when compared to any hierarchical key distribution schemes. The key distribution method is also briefly discussed in comparison to DiRK because it is an important aspect of secure multicast models.

SECTION 5 -- CONCLUSION

This paper has briefly discussed the role of universities in distance education. Universities may collaborate with service providers to disseminate lectures to a wide audience. A flexible and secure multicast framework can help to achieve this. The role and cooperation of the service providers is important. The entire process is discussed in three phases--registration, validation, and certification. The existing Internet multicast backbone can be used to handle this in a distributed manner. A comparison with an existing model is provided to help the reader to understand the advantages of the framework.

References

Deering, S. (1989). Host extensions for IP multicast. IEEE, RFC1112.

Eriksson, H. (1994). MBONE: The multicast backbone. Communications of the ACM, 37(8), 54-60.

Moyer, M., Rao, J., & Rohatgi, P. (1999). A survey of security issues in multicast communications. Network, IEEE (13)6, 12-23.

Oppliger, R., & Albanese A. (1996). Distributed registration and key distribution (DiRK). 12th International conference on Information Security.

Wittmann, R., & Zitterbart, M. (2001). Multicast communication protocols and applications. San Francisco: Morgan Kaufman Publishers.

Sandro, R., & Hutchison, D. (2003). A survey of key management for secure group communication. ACM Computing Surveys, 35(3), 309-329.

Wade, T., Song, J., Poovendran, R., & Liu, K. J. (2003). Key management and distribution for secure multimedia multicast. IEEE Transactions on Multimedia, 5(4), 544-557.

ANNADURAI SAMUKUTTY

Government Engineering college, Tirunelveli, Tamil Nadu, INDIA

[e-mail]

PADMAVATHI GANAPATHI

Avinashilingam Deemed University, Coimbatore-641 043., Tamil Nadu, INDIA

[e-mail]

Table 1 Notations used in the protocol

[U.sub.i]                              University i
[P.sub.i]                              Professor i
SP                                     Service provider
[S.sub.i]                              Student i
[C.sub.i]                              Course i
[M.sub.ij]                             Module j for course i where i,
                                       j [greater than or equal to] 1
<x>y                                   Message x is encrypted with y.
(k,[k.sup.-1])                         Key pair
x[much less than]y[much greater than]  Certificate issued by x to y