File Service AAA Server and the File Server is an internal one that
will not require a formal protocol (although some standard API might
be useful).
The concept of a Resource Manager (see [2]) has some interesting
twists relative to IPP. Once started, the user is not involved in
the service, but until printing is complete it seems useful that any
of the parties in the authorization process be allowed to query for
status or to cancel the print session. The user needs a way to
"bind" to a particular session, and may have to reauthorize to be
allowed to access Resource Manager information.
6. Electronic Commerce
This section describes the authorization aspects of an e-commerce
architecture typically used in Europe. We will use this model to
identify contractual and trust relationships and message exchanges.
We will then identify a set of authorization requirements for e-
commerce.
Whereas most e-commerce protocols focus on authentication and message
integrity, e-commerce exchanges as described by the Internet Open
Trading Protocol (trade) Working Group in [15] also involve
authorization. This section will examine one e-commerce protocol
called SET (Secure Electronic Transaction) that provides for credit
and debit card payments. We will analyze the authorization aspects
from an architectural viewpoint. We will apply concepts and terms
defined in [2].
We are not here proposing SET as a standard authorization protocol.
Rather, we are examining the SET model as a way of understanding the
e-commerce problem domain so that we can derive requirements that an
authorization protocol would have to meet in order to be used in that
domain.
E-commerce protocols and mechanisms such as those described in [16]
may not only be important to allow customers to shop safely in
Cyberspace, but may also be important for purchases of Internet
services as well. With emerging technologies allowing Internet
transport services to be differentiated, an inherently more complex
pricing model will be required as well as additional payment methods.
Flexible authorization of services will be an important aspect to
allow, for example, globally roaming users ad hoc allocation of
premium bandwidth with an ISP who is authorized to accept certain
credit card brands.
6.1. Model Description
The establishment of a model involves four steps:
1. identification of the components that are involved and what they
are called in this specific environment,
2. identification of the relationships between the involved parties
that are based on some form of agreement,
3. identification of the relationships that are based on trust, and
4. consideration of the sequence of messages exchanged between
components.
6.1.1. Identification of Components
We will consider the components of an electronic commerce transaction
in the context of the conceptual entities defined in [2].
- The Cardholder (User) -- the person or organization that is to
receive and pay for the goods or services after a request to
purchase has been received. In SET terms this is called a
Cardholder.
- The Issuer (User Home Organization) -- the financial organization
that guarantees to pay for authorized transactions to purchase
goods or services on behalf of the User when using a debit or
credit card it issues. The financial organization (typically a
bank or Brand Organization) will transfer money from the user
account to the account the party to which the User instructs it to
send the payment. The issued card authorizes the User to use the
card for payments to merchants who are authorized to accept the
card. In SET terms this organization is called the Issuer. This
organization is considered "home" to the Cardholder.
- The Merchant (Service Provider) -- the organization from whom the
purchase is being made and who is legally responsible for
providing the goods or services and receives the benefit of the
payment made. In SET terms this organization is called a
Merchant. The Cardholder is considered to be "foreign" to the
Merchant.
- The Acquirer (Broker) -- the organization that processes credit or
debit card transactions. Although in reality this function may be
rather complex and may span several organizations, we will simply
assume this organization to be a Brand Organization fulfilling the
role of the Acquirer as defined in SET. The Acquirer establishes
an account with the Merchant. The Acquirer operates a Payment
Gateway that will accept payment authorization requests from
authorized merchants and provide responses from the issuer. The
Acquirer will forward an authorization request to the Issuer. The
Acquirer is considered "home" to the Merchant.
As the SET document [16] notes, a Brand Organization (credit card
organization) may handle both the Issuer function and Acquirer
function that operates a Payment Gateway. For simplicity, we
therefore assume that the authorization role of Broker (Acquirer) and
User Home Organization (Issuer) both belong to the Brand
Organization.
In order to be more descriptive we now use the SET terms. In the
requirements section these terms are mapped back into the
authorization framework terms again.
6.1.2. Identification of Contractual Relationships
Contractual relationships are illustrated in figure 15, below.
- The Cardholder has a contractual relationship with the card
Issuer. The Cardholder holds an account with the Issuer and
obtains an account number.
- The Merchant has a contractual relationship with the Acquirer.
The Merchant obtains a Merchant ID from the Acquirer.
- In the real world there may be no direct contractual relationship
between the Issuer and the Acquirer. The contractual
relationships allowing an Acquirer to relay a payment
authorization request to an Issuer may be very complex and
distributed over multiple organizations. For simplicity, however,
we assume there are contracts in place allowing an Acquirer to
request payment authorization from an Issuer. These contracts are
facilitated by the Brand Organization. Therefore, in our
simplified example, the Acquirer and Issuer belong to the same
Brand Organization. The Acquirer operates a Payment Gateway for
which it needs a Bank Identification Number (BIN).
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
Fig. 15 -- SET Contractual Relationships
6.1.3. Identification of Trust Relationships
It is important to recognize that there are two kinds of trust
relationships: static and dynamic trust relationships. Static trust
relationships in SET are established by means of a registration
process that will request a certificate to be issued to the party
that needs to be trusted and authorized to be part of a SET
transaction. Dynamic trust is created at the time of a payment
transaction and its subsequent authorization request. Note that at
the issue phase of a certificate, based on identification and
registration, the user of the certificate gets an implicit static
authorization and a means of authenticating and securing messages.
For this purpose a Certificate Authority (CA) will issue certificates
that are used to sign and/or encrypt messages exchanged according to
the SET protocol.
6.1.3.1. Static Trust Relationships
In the discussion that follows, refer to figure 16, below.
+-------+
| Root |
| CA |
+-------+ CA = Certificate Authority
| {C} = Certificate
|
+-----------------+
| Brand |
| CA |
+-----------------+
| | |
| | +-------+
| | |Payment|
+----------------+ | | |Gateway| +----------------------+
| Issuer | | | | CA | | Acquirer |
| (User Home | +----------+ | +-------+ | (Broker) |
| Organization) | |Cardholder| | | | +----------------+ |
| | | CA | | +------+--+-{C} Payment | |
| | +----------+ | 3 | | Gateway | |
| | | | | +----------------+ |
| | | +---------+ | |
+----------------+ | | Merchant| +----------------------+
| | CA |
| +---------+
| |
+----------------+ | | +--------------------+
| Cardholder | | | | Merchant |
| (User) | | | | (Service Provider) |--+
| {C}-+-----+ | | | |
| | 1 +-----------+-{C} | |
| | 2 | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +---------------------+
Fig. 16 -- SET Trust Relationships within a Brand Domain
- The Brand Organization operates a Brand CA and is therefore the
holder of the common trust within the described domain. All
involved parties (Cardholder, Issuer, Merchant and Acquirer) are
members of the same trust domain. We will identify three separate
CA's which issue a certificate on behalf of the Issuer, the
Acquirer and the Brand Organization. The Brand CA, according to a
tree like hierarchy, certifies all underlying CA's. The Brand CA
obtains its trust from a single Root Certificate Authority.
Before any party can obtain a Certificate from a CA, the party
must have some form of contractual relationship.
- After an account has been established with the Issuer, the
Cardholder has to register with a Cardholder CA (CCA) through a
series of registration steps (1) as defined in the SET protocol.
If the CCA approves the registration, the Cardholder will obtain a
Cardholder Certificate. The CCA may be operated by the Brand
Organization on behalf of the Issuer. The Cardholder Certificate
is an electronic representation of the payment card. This process
creates a trust relationship between the Cardholder and the Brand.
After the cardholder has received the Cardholder Certificate, the
Cardholder is authorized to perform payments to an authorized
Merchant.
- After the Merchant has obtained a Merchant ID from the Acquirer,
the Merchant has to register with the Merchant CA (MCA) through a
series of registration steps (2) as defined in the SET protocol.
If the MCA approves the registration, the Merchant will obtain a
Merchant Certificate. This process creates a trust relationship
between the Merchant and the Brand. The MCA may be operated by
the Brand Organization on behalf of the Acquirer. After
registration, the Merchant is authorized to accept payment
requests from Cardholders and to send authorization requests to
the Acquirer's Payment Gateway.
- After the Acquirer has obtained a valid Bank Identification Number
(BIN), the Acquirer must register with the Payment Gateway CA
(PCA) in order to obtain a Payment Gateway Certificate (3). The
Payment Gateway Certificate authorizes the Gateway to accept
payment authorization requests originating from Merchants within
its trust domain.
- The Acquirer and Issuer have a trust relationship via the Brand
Organization. The trust relationship is not ensured by procedures
or a mechanism defined by SET, as this is a problem solved by
agreements between financial organizations facilitating the
payment service. Again, for simplicity, we assume that the
relationship ensures that payment authorization requests received
by the Acquirer's gateway will be forwarded in a secure and
efficient way to the Issuer and its response is handled in the
same way.
6.1.3.2. Dynamic Trust Relationships
Note that there is no prior established static trust relationship
between the Cardholder and the Merchant, as a Cardholder does not
have to register with a Merchant or vice versa. The trust
relationship is dynamically created during the communication process
and is based on the common relationship with the Brand. By means of
digital signatures using public key cryptography, the Cardholder's
software is able to verify that the Merchant is authorized to accept
the Brand Organization's credit card. The merchant is able to verify
that the Cardholder has been authorized to use the Brand
Organization's credit card.
6.1.4. Communication Model
The purchase request from Cardholder to Merchant and subsequent
payment authorization exchange between Merchant and Acquirer is
illustrated in figure 17 and described below.
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |<------+--| Payment | |
| | 5 | | Gateway | |
| |-------+->| | |
| | 6 | +------------------+ |
| | | /|\ | |
+----------------+ +---------+---+----------+
|4 |7
| \|/
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| |------>| | |
| | 1 | | |
| |<------| | |
| | 2 | | |
| |------>| | |
| | 3 | | |
| |<------| | |
| | 8 | | |
| | | | | |
| | +-----------------+--+ |
| | | |9 |
| |<--------| Fulfillment \|/ |
| | 10 | |
+----------------+ +----------------------+
Fig. 17 -- Communication Sequence
1. The Cardholder shops and decides to purchase some goods at
merchant.com. The Cardholder has selected a list of goods and the
Merchant's software has subsequently prepared an order form for
the Cardholder indicating the price, the terms and conditions, and
the accepted payment methods. The SET transaction starts at the
moment the Cardholder indicates that he or she wants to pay for
the goods using a certain payment brand. The Cardholder software
sends a request to the Merchant that initiates the payment
process.
2. The Merchant checks the order and signs it and returns it to the
Cardholder including a certificate from the Acquirer's Gateway
that allows the Cardholder to encrypt payment instructions that
are only relevant to the Gateway and not to the Merchant (e.g.,
the Cardholder's credit card information). The Cardholder also
includes his or her own certificate.
3. The Cardholder now verifies both certificates (the software has
the CA's root certificate). The Cardholder software generates a
message containing the order information and the payment
instructions that is signed by the Cardholder. Using the Gateway
Certificate, it will encrypt the Payment Instruction so that it
will only be readable by the Gateway. The Cardholder will include
his or her certificate.
4. The Merchant verifies the Cardholder certificate and checks the
message integrity. He or she will now process the payment and
issue a payment authorization request to the gateway. The payment
authorization request contains the Cardholder's certificate and
both Merchant certificates.
5. The Gateway verifies the Merchant's signature certificate and that
the Merchant signed the authorization request. Next it will
obtain the account information and payment instructions and will
check the message integrity and the Cardholder's certificate. If
everything is in proper order it will send an authorization
request to the Issuer via a secure bank network.
6. The issuer returns the authorization.
7. The Acquirer's Gateway generates an authorization response which
includes the gateway's certificate.
8. The Merchant checks the authorization response and completes the
process by forwarding a purchase response to the Cardholder.
9. The Merchant software authorizes the delivery of the purchased
goods.
10. The Cardholder receives the purchased goods.
6.2. Multi Domain Model
In the previous "single" domain case we already assume that there are
multiple Cardholders, Merchants, Issuers and Acquirers. However all
these parties belong to a single trust domain as there is only a
single CCA, MCA and PCA. The trust relationship between multiple
cardholders and multiple Issuers go via a single CCA in the same way
as the trust relationship between an Acquirer and a Merchant uses the
same MCA. The multi-domain case arises when there are multiple
domains of CCA's, MCA's and PCA's. In SET these domains reside under
a particular Geopolitical CA (GCA) which is illustrated in figure 18.
+-----------+
| Root CA |
| |
+-----------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Brand CA | |
| |-+
+-----------------------------------------------------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Geopolitical CA | |
| |-+
+-----------------------------------------------------+
| | |
| | |
+----|--------+ +---|-------+ +-------|----------+
+------------+ | +----------+ | +-----------------+ |
| Cardholder | | | Merchant | | | Payment Gateway | |
| CA |-+ | CA |-+ | CA |-+
+------------+ +----------+ +-----------------+
Fig. 18 -- SET Certificate Management Architecture
A GCA may represent a country or region. The architecture defines a
trust hierarchy needed to manage and verify SET Certificates as these
need to be issued, renewed or revoked. Each geopolitical region may
have different policies for issuing, renewing or revoking
certificates. However once certificates have been issued, Cardholders
and Merchants belonging to different GCA's can still be recognized as
belonging to the same Brand. This will allow a European Cardholder
to purchase goods in the U.S. The U.S. Acquirer's gateway will
recognize that the Cardholder belongs to the same Brand and will
therefore accept a payment authorization request.
6.3. Requirements
Many e-commerce environments do not use SET. Other mechanisms exist
based on SSL, XML, and S/MIME. Also a mechanism that uses SET only
for the payment authorization to the Gateway exists and is known as
half SET. However, using the model described in this document, we
can derive a fairly comprehensive set of protocol requirements for
e-commerce. In these requirements, the SET terms are replaced again
by the descriptive model terms:
Cardholder = User
Merchant = Service Provider
Issuer = User Organization
Acquirer = Broker
1. The Authorization mechanism must allow trust relationships to be
established before any requests can be made from the User to the
Service Provider and from the Service Provider via a Broker to the
User Organization. This process will enable the parties to
communicate securely by creating an authenticated channel and, by
so doing, implicitly authorizing its usage.
2. Upon receipt of any request or response, entities need to be able
to verify whether the transmitting party is still authorized to
send this request or response.
3. The User must be able to authorize the Service Provider to request
an authorization from the User Home Organization.
4. The User must be able to authorize fulfillment of a proposed
service offer from the Service Provider.
Other requirements related to the authorization process:
Integrity
5. For any authorization request or response, the receiving party
needs to verify that the content of the message has not been
altered.
Confidentiality/Privacy
6. The User must be able to pass information relevant to the session
authorization process to the User Home Organization via a Broker
and the Service Provider without allowing the Broker or the
Service Provider to examine its content.
7. The User Home Organization must be able to communicate information
relevant to the session authorization via the Broker and the
Service Provider to the User without allowing the Broker or the
Service Provider to examine its content.
Nonrepudiation
8. There is a need for a recorded, authenticated and authorized
agreement about the request for and delivery of service.
7. Computer Based Education and Distance Learning
This section describes the authorization aspects of computer based
distance learning environments. In this section we will model the
relationships and working practices in a hypothetical university
environment where a student enrolls in courses, attends lectures, and
takes the corresponding exams from remote locations (distance
learning) or via computer equipment (computer based education). When
completed successfully, a student is authorized to enroll in a set of
subsequent courses according to his or her curriculum requirements.
Completion of required courses with passing grades results in
graduation.
Although this section specifically describes an example of a student
taking courses at a faculty (department) of the university, the
resulting requirements should also be valid for other applications in
similar environments, e.g. library loans, electronic abstract and
reprint services, computer and network access, use of copy machines,
budget management, store retrievals, use of coffee machines and
building access.
It is important to recognize that the AAA environment we are
describing also needs to be managed. For example, for an application
such as budget management, it is necessary to delegate budget
authority from a central financial department to budget managers in
education or faculty groups. An AAA environment must allow creation
of policy rules either by certain individuals or by other AAA servers
with authorization to do so.
7.1. Model Description
The establishment of the model involves four steps:
1. identification of the components that are involved and what they
are called in this specific environment,
2. identification of the contractual relationships between the
involved parties,
3. identification of the relationships that are based on trust, and
4. consideration of the sequence of messages exchanged between
components.
7.1.1. Identification of Components
We will consider the components of a distance learning environment in
the context of the conceptual entities defined in [2].
- The Student (User) -- the person enrolling in a course (Service)
and taking the corresponding exam.
- The Educator (Service Equipment) -- the education content server
for which the content is delivered by the Professor.
- The Educator Authorization Module (Service Provider AAA Server).
This module must check at the service access point whether the
student complies with the requirements for enrolling in the
course. The authorization may be based on both local (by the
professor) and remote policies (originating from the faculty).
Rules must allow enough flexibility to prevent students from being
falsely denied access to courses. Strict rules must only be
applied at graduation time.
- The Faculty (Service Provider) -- the organization (department in
U.S. terms) which controls the Service "Equipment" of which the
Educator is one example.
- The Curriculum Commission (Part of User Home Organization) -- body
responsible for creating rules by which a student is allowed to
enroll in a certain course and how this course will count toward
his or her graduation requirements. Students may legally take any
course available at any time, however the Curriculum Commission
will decide whether this course will contribute towards their
graduation. When a Student registers with a certain Educator, the
Educator may check with the Curriculum Commission AAA server
whether the course will count towards graduation and confirm this
with the student.
- The Student Administration (Part of User Home Organization) -- the
administrative organization that authorizes students to enroll in
courses if certain criteria, including financial criteria, are
met. Next to the student, the Student Administration will keep
track of any exam results for the student and will issue a
graduation certificate when all criteria are met.
7.1.2. Identification of Contractual Relationships
Contractual relationships are illustrated in figure 19, below. Based
on contract relationships,specific trust relationships are created as
required.
Although not shown in figure 19, it is assumed that the university
has contractual relationships with the faculties in which every
faculty is allowed and obligated to build, maintain and present one
or more specific studies.
+---------------------------------------------+
| +-----------------------------------------+ |
| | Faculty administration | |
| |+----------------+ +----------------+| |
| |O Student | | Curriculum || |
| *| Administration O*****O Commission || |
|*|| AAA Server | | AAA Server || |
*/|+---O------O-----+ +-----O------O---+| |
*//| * * * * | |
*// +----*---------*-----------*---------*----+ |
*//| * || * * || * |
*// | * || * * || * |
*// | * || * || * |
*// | * || * * || * |
*// | * || * * || * |
*// | +----*---------*--+ +--*---------*----+ |
*// | | * * | | * * |
*// | |+---O------O----+| |+----O------O---+| |
*// | || Educator A || || Educator B || |
*// | || AAA Server || || AAA Server || |
*// | || Service admin.|| || Service admin.|| |
*// | |+---O-----------+| |+-----------O---+| |
*// | | * | | * | |
+-O-------+ | | * | | * | |
| | | |+---O-----------+| |+-----------O---+| |
| Student | | || Educator || || Educator || |
| | | || Course A || || Course B || |
| | | |+---------------+| |+---------------+| |
+---------+ | +-----------------+ +-----------------+ |
| Faculty |
+---------------------------------------------+
// = contractual relationship
** = trust relationship
Fig. 19 -- Contractual relationships - single domain case
As shown in figure 19, the Student has a contractual relationship
with the Faculty. The contract allows the Student to pursue a course
of study consisting of a set of courses. Courses are presented to
the Students by the Educators. A course of study may consist of
courses from different Faculties.
Faculties have contracts among them allowing Students from one
Faculty to enroll in courses from other Faculties.
Faculties instantiate Educators based on a contract between the
Faculty Administration and the professor implementing and managing
the Educator. Authorization is based on policy rules defined by one
or more parties in the contractual relationships. For example, a
professor has a policy to give the course only in the afternoon and
the Faculty has a policy to give the course to their own students and
students from faculty-x but not, when oversubscribed, to faculty-y
students.
7.1.3. Identification of Trust Relationships
Figure 19 illustrates relevant trust relationships which statically
enable AAA entities to communicate certain attributes in our
simplified example. However, in order for the illustrated entities to
work, other trust relationships that are not illustrated must already
be in existence:
- A trust relationship based on a contract between the Faculty and
the university enables a faculty to create and teach specific
courses belonging to a course of study.
- Although not further detailed in this example, it is worth noting
that trust relationships between faculties authorize students from
one faculty to enroll in courses with other faculties.
- A professor responsible for the content of the Educator has a
trust relationship with the administration of the faculty.
Through this relationship, the faculty enables the professor to
teach one or more courses fitting the requirements of the
Curriculum Commission.
Figure 19 illustrates the following trust relationships:
- When a person wants to become a Student of a Faculty, the contract
requires the Student to register with the Student Administration
of the Faculty. If the requirements for registration are met, a
trust relationship with the Faculty enables the Student to
register for courses. For this purpose, the Student
Administration will issue a student card which contains a student
ID and information about the Faculty he or she is admitted to.
The Student Administration will only admit Students who pay the
necessary fees and have met certain prerequisites. The Student
Administration will also keep track of Student grades and will
ultimately issue a certificate at graduation. The Student
Administration AAA server has access to relevant student data and
will only issue grade information and other student-related
information to authorized parties which have a specified means of
authenticating.
- The Curriculum Commission AAA server needs a trust relationship
with the Student Administration AAA server in order to obtain
grade information to check whether a student has met the required
course prerequisites. The Curriculum Commission creates certain
rules within its AAA server which are evaluated when a particular
student attempts to register for a particular course in order to
give an advisory to the student.
- The Educator AAA server needs a trust relationship with the
Student Administrator AAA server in order to verify whether this
particular Student is in good standing with the Faculty. Only
authorized Educator AAA servers may send requests to the Student
Administration AAA server.
- The Educator AAA server needs a trust relationship with the
Curriculum Commission AAA server in order to allow the Educator to
obtain an advisory for the Student whether this course is
consistent with his or her curriculum or whether the student meets
the course prerequisites. Only authorized Educator AAA servers
may send requests to the Curriculum AAA Server.
7.1.4. Sequence of Requests
For the sake of simplicity, we take the example of a student from the
same faculty as the professor.
In this example the following interactions take place for a
hypothetical course (see figure 20).
+----------------------------------------------+
| |
| +----------------+ 6 +----------------+ |
| | Student |----->| Curriculum | |
| | Administration |<-----| Commission | |
| | AAA Server | 5 | AAA Server | |
| +----------------+ _ +----------------+ |
| /|\ | /|/ |
| | | / / |
| 2,8| |3 / /6 |
| | | 4/ / |
| | | / / |
| | | / / |
| | \|/ /|/ |
| +---------------+ -- +---------------+ |
| | Educator A | | Educator B | |
| | AAA Server | | AAA Server | |
| +---------------+ +---------------+ |
| /|\ | |
|2,4,8| |3,6 |
+---------+ | | \|/ |
| | 1,7 | +---------------+ +---------------+ |
| Student |------->| Educator | | Educator | |
| |<-------| Course A | | Course B | |
| | 7,8 | +---------------+ +---------------+ |
+---------+ | Faculty |
+----------------------------------------------+
Fig. 20 -- AAA transactions - single domain case
1. After the Professor has set up the Service Equipment (Educator)
students come to it presenting their ID (college card,
name+faculty) and ask to be admitted to the course.
2. The Educator checks the ID to determine it is indeed dealing with
a student from the faculty. This can include a check with the
Student Administration.
3. The Student Administration replies to the Educator AAA Server, and
the Educator AAA Server replies to the Educator.
4. The Educator checks the request of the Student against its own
policy (courses only in the afternoon) and checks with the
Curriculum Commission whether this student is advised to take the
course. The necessary information is not normally known to or
maintained by the professor.
5. The Curriculum Commission may check against the Student
Administration to see if the Student had the necessary grades for
the previous courses according to the policies set by the
Curriculum Commission.
6. The Student Administration replies to the Curriculum Commission,
the Curriculum Commission replies to the Educator AAA Server, and
the Educator AAA Server replies to the Educator.
7. If now authorized, the Student is presented the material and the
Student returns completed exams.
8. If the Student passes the tests, the Educator informs both the
Student and the Student Administration that the Student has
passed.
7.2. Requirements
We identify the following requirements for an AAA server environment
for this example:
1. It must be possible to delegate authority to contracted partners.
Although this requirement is not explicit in the limited example,
the relationship between University and Faculty may require
delegation of authority regarding the curriculum to the Faculty.
In the case of budget management, this requirement is evident.
2. A system to manage the delegated authority must be established.
It is possible that this is just another AAA server environment.
This comes from the fact that one partner requires the presence of
specific rules to be in the AAA server of another partner. For
example, the Faculty must be sure that certain checks are
performed by the Educator's AAA server.
3. AAA requests must either be evaluated at the AAA server queried or
else parts of the request must be forwarded to another AAA server
which can decide further on the request. As such, it must be
possible to build a network of AAA servers in which each makes the
decisions it is authorized to make by the relationships among the
entities, e.g., a request from the Educator to the Curriculum
Commission may result in a request to the Student Administration.
4. Transaction logs must be maintained to support non-repudiation for
the grades of the students. This recording should be time-stamped
and allow signing by authorized entities. A student should sign
for taking an exam and this should be kept by the Educator's AAA
server. After grading, the professor should be able to sign a
grade and send it to the Student Administrator and the Student
Administrator's AAA server should log and timestamp this event.
5. Three types of AAA messages are required:
- authorization requests and responses for obtaining
authorization,
- notification messages for accounting purposes, and
- information requests and responses for getting information
regarding the correct construction of requests and for querying
the database of notifications.
8. Security Considerations
The authorization applications discussed in this document are modeled
on the framework presented in [2]. Security considerations relative
to the authorization framework are discussed in [2].
Specific security aspects of each authorization application presented
in this document are discussed in the relevant section, above.
Security aspects of the applications, themselves, are discussed in
the references cited below.
Glossary
Attribute Certificate -- structure containing authorization
attributes which is digitally signed using public key
cryptography.
Contract Relationship -- a relation established between two or more
business entities where terms and conditions determine the
exchange of goods or services.
Distributed Service -- a service that is provided by more than one
Service Provider acting in concert.
Dynamic Trust Relationship -- a secure relationship which is
dynamically created between two entities who may never have had
any prior relationship. This relationship can be created if the
involved entities have a mutually trusted third party. Example: A
merchant trusts a cardholder at the time of a payment transaction
because they both are known by a credit card organization.
Policy Decision Point (PDP) -- The point where policy decisions are
made.
Policy Enforcement Point (PEP) -- The point where the policy
decisions are actually enforced.
Resource Manager -- the component of an AAA Server which tracks the
state of sessions associated with the AAA Server or its associated
Service Equipment and provides an anchor point from which a
session can be controlled, monitored, and coordinated.
Roaming -- An authorization transaction in which the Service Provider
and the User Home Organization are two different organizations.
(Note that the dialin application is one for which roaming has
been actively considered, but this definition encompasses other
applications as well.)
Security Association -- a collection of security contexts, between a
pair of nodes, which may be applied to protocol messages exchanged
between them. Each context indicates an authentication algorithm
and mode, a secret (a shared key, or appropriate public/private
key pair), and a style of replay protection in use. [14]
Service Equipment -- the equipment which provides a service.
Service Provider -- an organization which provides a service.
Static Trust Relationship -- a pre-established secure relationship
between two entities created by a trusted party. This
relationship facilitates the exchange of AAA messages with a
certain level of security and traceability. Example: A network
operator (trusted party) who has access to the wiring closet
creates a connection between a user's wall outlet and a particular
network port. The user is thereafter trusted -- to a certain
level -- to be connected to this particular network port.
User -- the entity seeking authorization to use a resource or a
service.
User Home Organization (UHO) -- An organization with whom the User
has a contractual relationship which can authenticate the User and
may be able to authorize access to resources or services.
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC2026, October 1996.
[2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
Authorization Framework", RFC2904, August 2000.
[3] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
Authorization Requirements", RFC2906, August 2000.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[5] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC2477, January 1999.
[6] Beadles, Mark Anthony, and David Mitton, "Criteria for
Evaluating Network Access Server Protocols", Work in Progress.
[7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[8] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138, April
1997.
[9] Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization
Requirements", Work in Progress.
[10] Perkins, C., "IP Mobility Support", RFC2002, October 1996.
[11] Glass, Steven, et al, "Mobile IP Authentication, Authorization,
and Accounting Requirements", Work in Progress.
[12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for
AAA", Work in Progress.
[13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares,
"A Discussion of Bandwidth Broker Requirements for Internet2
Qbone Deployment", ver. 0.7, August 1999,
http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.
[14] deBry, R., "Internet Printing Protocol/1.0: Model and
Semantics", RFC2566, April 1999.
[15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC2801,
April 2000.
[16] "SET Secure Electronic Transaction Specification Book 1:
Business Description", Version 1.0, May 31, 1997,
http://www.setco.org/class/download/set_bk1.pdf.
Authors' Addresses
John R. Vollbrecht
Interlink Networks, Inc.
775 Technology Drive, Suite 200
Ann Arbor, MI 48108
USA
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
Stephen Farrell
Baltimore Technologies
61 Fitzwilliam Lane
Dublin 2
Ireland
Phone: +353 1 647 7406
Fax: +353 1 647 7499
EMail: stephen.farrell@baltimore.ie
Leon Gommans
Enterasys Networks EMEA
Kerkplein 24
2841 XM Moordrecht
The Netherlands
Phone: +31 182 379279
email: gommans@cabletron.com
or at University of Utrecht:
l.h.m.gommans@phys.uu.nl
George M. Gross
Lucent Technologies
184 Liberty Corner Road, m.s. LC2N-D13
Warren, NJ 07059
USA
Phone: +1 908 580 4589
Fax: +1 908-580-4991
EMail: gmgross@lucent.com
Betty de Bruijn
Interpay Nederland B.V.
Eendrachtlaan 315
3526 LB Utrecht
The Netherlands
Phone: +31 30 2835104
EMail: betty@euronet.nl
Cees T.A.M. de Laat
Physics and Astronomy dept.
Utrecht University
Pincetonplein 5,
3584CC Utrecht
Netherlands
Phone: +31 30 2534585
Phone: +31 30 2537555
EMail: delaat@phys.uu.nl
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
EMail: matt@ipverse.com
David W. Spence
Interlink Networks, Inc.
775 Technology Drive, Suite 200
Ann Arbor, MI 48108
USA
Phone: +1 734 821 1203
Fax: +1 734 821 1235
EMail: dspence@interlinknetworks.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.