extensions to provide end-to-end security.
9. Streamlined Authorization Process
The techniques described above allow for great flexibility in
distributing the components required for authentication and
authorization. However, working groups such as Roamops and MobileIP
have identified requirements to minimize Internet traversals in order
to reduce latency. To support these requirements, data fields
necessary for both authentication and authorization SHOULD be able to
be carried in a single message set. This is especially important
when there are intermediate servers (such as Brokers) in the AAA
chain.
Furthermore, it should be possible for the Brokers to allow end-to-
end (direct) authentication and authorization. This can be done as
follows. The User Home Organization generates a ticket which is
signed using the UHO's private key. The ticket is carried in the
accounting messages. The accounting messages must flow through the
Broker since the Broker is acting as the settlement agent and
requires this information. There are Brokers that will require to be
in the authentication and authorization path as well since they will
use this information to detect fraudulent activity, so the above
should be optional.
In order for end-to-end authentication and authorization to occur, it
may be necessary for the Broker to act as a certificate authority.
All members of the roaming consortium would be able to trust each
other (to an extent) using the certificates. A Service Provider's
AAA server that sends a request to the Broker should be able to
receive a redirect message which would allow the two peers (Service
Provider and UHO) to interact directly. The redirect message from
the Broker should include the UHO's certificate, which eliminates the
Service Provider from accessing the certificate archive. The request
from the Service Provider could include its own certificate, and a
token from the Broker's redirect message that is timestamped and
guarantees that the Service Provider is in good standing with the
Broker. This eliminates the home domain from accessing the
Certificate Revocation List (CRL).
10. Summary of the Authorization Framework
The above has introduced the basic players in an authorization
transaction as User, User Home Organization, Service Provider's AAA
Server, and Service Equipment. It has discussed relationships
between entities based on agreements or contracts, and on "trust".
Examples of authorization sequences have been given.
Concepts of roaming and distributed services have been briefly
described. Combination of roaming and distributed services was also
considered and the concept of a "wholesaler" or Broker was
introduced. We have considered the use of policies and attribute
certificates to store and transmit authorization data. We discussed
the problem of managing the resources to which access has been
authorized including the problem of tracking state information for
session-oriented services, and we defined the Resource Manager
component of a AAA Server. We considered the problem of forwarding
AAA messages among servers in possibly different administrative
domains. We considered the need for end-to-end security of portions
of the payload of authorization messages that pass through
intermediate AAA Servers. Finally we stressed the need for support
of a streamlined authorization process that minimizes delay for
latency-sensitive applications.
The intent is that this will provide support for discussing and
understanding requirements of specific applications that need
authorization services.
11. Security Considerations
Authorization is itself a security mechanism. As such, it is
important that authorization protocols cannot easily be abused to
circumvent the protection they are intended to ensure. It is the
responsibility of protocol designers to design their protocols to be
resilient against well-known types of attacks. The following are
some considerations that may guide protocol designers in the
development of authorization protocols.
Authorization protocols must not be susceptible to replay attacks.
If authentication data is carried with the authorization data, for
example, the authentication protocol used must either be impervious
to replay or else the confidentiality of the authentication data must
be protected.
If proxying is required, the authorization protocol must not be
susceptible to man-in-the-middle attacks.
If the push model is used, the confidentiality of the authorization
data must be ensured so that it may not be hijacked by third parties
and used to obtain a service fraudulently.
If the agent model is used, the binding between the authorization and
the service itself must be protected to prevent service authorized to
one party from being fraudulently received by another.
In addition to guarding against circumvention, authorization
protocols designed according to this framework will have some
intrinsic security requirements. These are included among the
requirements in [2] and summarized briefly below.
Among the intrinsic security needs is the fact that authorization
protocols may carry sensitive information. It is necessary to
protect such information from disclosure to unauthorized parties
including (as discussed in section 8) even certain parties involved
in the authorization decision.
We have discussed the use of multi-party trust chains involving
relaying of authorization data through brokers or other parties. In
such cases, the integrity of the chain must be maintained. It may be
necessary to protect the data exchanged between parties using such
mechanisms as encryption and digital signatures.
Finally, because authorization will be necessary to gain access to
many Internet services, a denial of service attack against an
authorization server can be just as effective as a denial of service
attack against the service equipment itself in preventing access to
Internet services.
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. [12]
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] 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.
[3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross,
G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA
Authorization Application Examples", RFC2905, August 2000.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[5] Stevens, M., "Policy Framework", Work in Progress.
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core
Information Model -- Version 1 Specification", Work in Progress.
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema",
Work in Progress.
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute
Certificate Profile for Authorization", Work in Progress.
[9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure -- Certificate and CRL Profile", RFC
2459, January 1999.
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC2607, June 1999.
[11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138, April
1997.
[12] Perkins, C., "IP Mobility Support", RFC2002, October 1996.
[13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for
Policy-based Admission Control", RFC2753, January 2000.
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
Mail: 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.